Guide
Cisco Common Policy: One Policy Fabric From ISE to Cloud
Common Policy makes Cisco ISE the exchange hub that normalizes user, device, and workload context into Security Group Tags, so campus, firewall, SD-WAN, and data-center domains all enforce against one consistent set of group classifications.
Every segmentation project eventually hits the same wall: the campus knows a user is a contractor, the firewall knows an IP address, the data center knows an endpoint group, and none of them are describing the same thing the same way. Cisco Common Policy is Cisco’s answer to that translation problem. It makes Identity Services Engine the exchange hub that normalizes user, device, and application-workload context into Security Group Tags, then distributes those classifications to each enforcement domain — campus, firewall, SD-WAN edge, data center — so each domain’s access and segmentation policy can be written against the same groups, and a group means the same thing wherever it is enforced. Each domain still authors and operates its own policy; what the framework unifies is the classification those policies key on.
The Problem: Four Domains, Four Vocabularies
Group-based segmentation works because it separates classification from topology: policy names who and what, not subnets. Cisco TrustSec proved the model in the campus, where the Security Group Tag can travel inline with the traffic — or be derived from shared bindings where it cannot — and switches enforce SGACLs against it. But an enterprise’s traffic does not stay in the campus. It crosses a firewall that thinks in access control rules, an SD-WAN fabric that thinks in site policy, and a data center that thinks in endpoint groups and contracts. Historically each domain classified endpoints on its own, which meant four teams maintaining four mappings of the same reality — and drift between those mappings is precisely where segmentation projects go to die. Common Policy attacks the mapping problem directly: create context once, close to where it lives, and share it everywhere it is needed.
ISE as the Exchange Hub
The hub of the framework is Cisco ISE, which already holds deep access-layer identity and posture context: who authenticated, on what device, in what state of health. Common Policy extends what ISE knows beyond users and devices. Through its ACI Connector, ISE learns application-workload context from the data center; through its Cloud Connector, it learns workload attributes from vCenter and from AWS, Azure, and GCP. Workload classification rules on ISE then map those attributes into SGTs — the same group currency the campus already uses. The result is one system holding a normalized group model of users, devices, and workloads, wherever they run.
Distribution is deliberately unexciting, which is a compliment: it reuses the channels ISE ecosystems already trust. ISE publishes the resulting IP-to-SGT bindings to pxGrid destinations — Catalyst Center, SD-WAN Manager, Secure Firewall Management Center, and APIC — and shares them toward network devices over the Security Group Tag Exchange Protocol (SXP), which propagates IP-to-SGT bindings where inline tagging is not available. Per-domain sharing rules control which context flows where, so the firewall team can consume workload groups without ISE flooding every domain with every binding.
Translation at the Data-Center Boundary
The most instructive part of the design is the ACI boundary, because ACI has its own mature group abstraction. The translation is bidirectional: campus SGTs shared with ACI are represented there as External Endpoint Groups, so ACI contracts can reference campus groups natively, while context received from ACI is normalized as SGTs on ISE and shared onward to the other domains. Neither side abandons its model. That is the framework’s philosophy in miniature — Common Policy standardizes the classification layer and leaves each domain’s enforcement machinery alone.
Shared Context, Native Enforcement
That division of labor is the point to hold onto: Common Policy shares classification, not enforcement. A TrustSec-capable campus still enforces SGACLs. Secure Firewall still evaluates access control rules — now able to match on the same groups the campus uses. The SD-WAN edge applies identity-based firewall policy against bindings it receives. ACI enforces contracts between endpoint groups. What changes is that all four are keying on one consistent group model instead of four private ones, which is what lets a statement like “contractors never reach payment workloads” be expressed in each domain’s own policy with the same meaning end to end.
Two practical cautions before you sketch this on a whiteboard as done. First, Common Policy is an integration across products, and each participating platform carries its own minimum-release requirement — verify your ISE, controller, firewall, and APIC versions against Cisco’s current integration guide before committing to a design. Second, context sharing is only as good as the classification feeding it: profiling and workload classification rules deserve the same review rigor as the enforcement policy itself, because a wrong tag now propagates with authority to every domain the sharing rules permit.
Common Policy as a framework is not an exam blueprint topic, but its machinery is squarely on the blueprints: SISE 300-715 objective 2.6 has candidates configure Cisco TrustSec, and the SCOR 350-701 core exam covers network segmentation with SGTs. The SISE course builds the ISE side hands-on, from authentication policy through TrustSec — and engineers who understand how a tag is assigned, exchanged, and enforced are the ones who can evaluate a one-policy-fabric pitch on its mechanics rather than its marketing.
Frequently Asked Questions
Is Cisco Common Policy a product I install?
No. Common Policy is Cisco's framework for making existing products agree on context. Cisco ISE acts as the exchange hub, and the enforcement points — Catalyst switching, Secure Firewall, SD-WAN, ACI — are the participating products in the deployment. Adopting it is an integration exercise across those systems, not a new appliance.
How does Common Policy relate to Cisco TrustSec?
TrustSec supplies the currency: the Security Group Tag. Common Policy extends the reach of that currency beyond the campus by having ISE normalize workload and cloud context into SGTs and distribute the IP-to-SGT bindings to other domains over pxGrid and SXP. If you understand SGT-based segmentation, Common Policy is that idea applied across domains.
Does ISE enforce the policy in every domain?
No — ISE shares context; it does not push one rule set everywhere. Each domain keeps its native enforcement: SGACLs on TrustSec-capable switching, access control rules on Secure Firewall, identity-based policy at the SD-WAN edge, contracts in ACI. What Common Policy standardizes is the group classification those mechanisms all key on.