How Do Cisco ISE and TrustSec Work?

Securing modern enterprise networks through traditional IP-based Access Control Lists (ACLs) and VLAN segmentation has become unsustainable. Dynamic workforces, cloud adoption, and mobile endpoints cause IP addresses to fluctuate constantly, resulting in sprawling ACL rule sets, frequent network changes, and elevated operational risk.

Cisco TrustSec addresses this challenge by decoupling access control from network topology. Built into Cisco Identity Services Engine (ISE) and enterprise network hardware, TrustSec replaces static IP and subnet dependencies with role-based microsegmentation. It classifies endpoints, assigns identity-based tags, and enforces granular access policies directly in network hardware—delivering consistent security across campus, branch, and data center environments.

Cisco TrustSec Architecture: The Classification, Propagation, and Enforcement Workflow

Cisco TrustSec operates as an identity-aware security framework coordinated by Cisco ISE as the central policy controller. The architecture functions through three sequential phases: Classification, Propagation, and Enforcement.

  +------------------+          +-------------------+          +--------------------+
  |  Classification  |  ----->  |    Propagation    |  ----->  |    Enforcement     |
  |  (Ingress NAD)   |          |  (Network Fabric) |          |    (Egress NAD)    |
  |  Identity -> SGT |          |   CMD / SXP / L3  |          | Match SGACL Matrix |
  +------------------+          +-------------------+          +--------------------+

1. Classification (Ingress)

Classification occurs at the ingress network access device (NAD)—such as a campus switch, wireless LAN controller (WLC), or VPN gateway—at the moment an endpoint connects:

1. Authentication: The endpoint authenticates via 802.1X, MAC Authentication Bypass (MAB), or Web Authentication.
2. Policy Evaluation: Cisco ISE matches the session against authentication and authorization policies, evaluating context such as user role, device posture, location, and group membership.
3. SGT Assignment: ISE returns a RADIUS Access-Accept containing the cisco-av-pair attribute specifying a 16-bit numeric identifier known as a Security Group Tag (SGT) (for example, cts:security-group-tag=0004-02).
4. Binding: The ingress switch binds the endpoint’s IP and MAC address to the assigned SGT in its local forwarding table. Alternatively, static classification can bind SGTs to VLANs, subnets, physical switch ports, or DNS domains.

2. Propagation (Network Fabric)

Once the packet enters the network, its identity context must travel alongside the payload from the source switch to the destination device. TrustSec handles this through two transport models:

• Inline Tagging: The ingress switch inserts a 16-bit SGT directly into the Layer 2/Layer 3 frame header using Cisco Metadata (CMD) or VXLAN encapsulation headers (in Cisco SD-Access environments). As the packet traverses intermediate routers and switches, the tag remains intact at wire speed without requiring stateful lookups on transit hops.
• SGT Exchange Protocol (SXP): On hops or legacy networks where hardware-level inline tagging is unsupported, switches share IP-to-SGT binding tables over a TCP control-plane session directly with other enforcement points or ISE.

3. Enforcement (Egress)

Enforcement occurs at the egress switch or firewall closest to the destination resource:

1. Lookup: The egress device inspects the inbound packet to identify the Source SGT (carried inline or resolved via an IP-to-SGT binding table).
2. Destination Resolution: The device resolves the Destination SGT assigned to the targeted resource using its own local bindings.
3. Policy Evaluation: The egress device checks the combination against the TrustSec Egress Policy Matrix downloaded locally from Cisco ISE.
4. Action: The switch applies the corresponding Security Group Access Control List (SGACL), permitting, denying, or logging the traffic at line rate directly within the device’s hardware Ternary Content-Addressable Memory (TCAM).

Cisco TrustSec vs. Traditional VLAN Segmentation: Key Differences

While traditional network segmentation relies on physical or logical topology (subnets, VLANs, and firewall interfaces), TrustSec implements software-defined microsegmentation that remains persistent regardless of where a device connects.

Step-by-Step: Configuring Cisco TrustSec and SGTs in Cisco ISE

Configuring Cisco TrustSec involves setting up network device authorization, defining security groups, creating SGACL rules, structuring the egress matrix, and deploying policies to network devices.

+-----------------------------------------------------------------------------------------+
| STEP 1: Enable TrustSec on NAD                                                         |
|         Administration > Network Resources > Network Devices                            |
+-----------------------------------------------------------------------------------------+
                                           |
                                           v
+-----------------------------------------------------------------------------------------+
| STEP 2: Define Security Group Tags (SGTs)                                              |
|         Work Centers > TrustSec > Components > Security Groups                          |
+-----------------------------------------------------------------------------------------+
                                           |
                                           v
+-----------------------------------------------------------------------------------------+
| STEP 3: Create Security Group Access Control Lists (SGACLs)                            |
|         Work Centers > TrustSec > Components > Security Group ACLs                      |
+-----------------------------------------------------------------------------------------+
                                           |
                                           v
+-----------------------------------------------------------------------------------------+
| STEP 4: Build the TrustSec Egress Policy Matrix                                         |
|         Work Centers > TrustSec > TrustSec Policy > Egress Policy                       |
+-----------------------------------------------------------------------------------------+
                                           |
                                           v
+-----------------------------------------------------------------------------------------+
| STEP 5: Map SGTs to Ingress Authorization Rules                                         |
|         Policy > Policy Sets > Authorization Policy                                     |
+-----------------------------------------------------------------------------------------+
                                           |
                                           v
+-----------------------------------------------------------------------------------------+
| STEP 6: Deploy and Verify Policy Provisioning                                           |
|         Trigger CTS Environment Data Download on Network Access Devices                 |
+-----------------------------------------------------------------------------------------+

Step 1: Enable TrustSec on the Network Access Device (NAD)

1. In Cisco ISE, navigate to Administration > Network Resources > Network Devices.
2. Select an existing switch or click Add to register a new device.
3. In the device profile, expand Advanced TrustSec Settings.
4. Check Device is TrustSec-Enabled.
5. Specify a Device ID and configure a secure Device Password (used for mutual authentication and Protected Access Credential [PAC] provisioning).
6. Enable Download environment data every X seconds (default: 86,400 seconds / 24 hours).

Step 2: Define Security Group Tags (SGTs)

1. Go to Work Centers > TrustSec > Components > Security Groups.
2. Click Add to create new identity containers.
3. Configure the parameters:
4. Name: Production_Servers
5. Tag Value: Select Auto-Generate or assign a manual decimal value (e.g., 10).
6. Description: “Core production server farms”.
7. Repeat the process to create operational groups such as Developers (Tag: 20) and Contractors (Tag: 30).

Step 3: Create Security Group Access Control Lists (SGACLs)

1. Navigate to Work Centers > TrustSec > Components > Security Group ACLs.
2. Click Add to build reusable policy contracts.
3. Enter an ACL Name (e.g., SGACL_RESTRICTED_DEV).
4. In the IP Version dropdown, select IPv4 (or IPv6/Agnostic).
5. Specify the rule logic using standard permit/deny statements:
   text
permit tcp dst eq 443
permit tcp dst eq 80
permit tcp dst eq 22
deny ip
6. Click Save.

Step 4: Build the TrustSec Egress Policy Matrix

1. Navigate to Work Centers > TrustSec > TrustSec Policy > Egress Policy > Matrix.
2. Locate the cell where the Source SGT row intersects with the Destination SGT column (e.g., Source: Developers, Destination: Production_Servers).
3. Click the cell and select Edit.
4. Assign the appropriate SGACL created in Step 3 (SGACL_RESTRICTED_DEV).
5. Set the Final Catch-All Rule (e.g., Deny All or Permit All).
6. Click Save. The cell changes from clear to active (highlighted with an assigned SGACL icon).

Step 5: Map SGTs to Ingress Authorization Rules

1. Navigate to Policy > Policy Sets, and open the active policy set (e.g., Campus Wired).
2. Expand the Authorization Policy section.
3. Create an authorization rule:
4. Condition: ActiveDirectory:ExternalGroups EQUALS engineering-team
5. Profile: PermitAccess
6. Security Group (SGT): Select Developers.
7. Save the policy set. When a developer authenticates, ISE returns the Developers SGT to the ingress switchport.

Step 6: Deploy and Verify Policy Provisioning

Network access devices automatically update their environment data on schedule, or you can force an immediate refresh directly from the switch CLI:

switch# cts refresh environment-data
switch# cts refresh policy

SGT Transport Mechanisms: Inline Tagging vs. SXP Peering

Transmitting identity across the enterprise requires an infrastructure strategy that matches hardware capabilities. Cisco TrustSec supports two primary methods: hardware-based Inline Tagging and software-based Security Group Tag Exchange Protocol (SXP).

INLINE TAGGING (Hardware-driven, hop-by-hop)
[Host] -> [ Switch A ] === SGT inside Ethernet/CMD Frame ===> [ Switch B ] -> [Server]
          (Applies Tag)                                        (Enforces Policy)

SXP PEERING (Software-driven, control-plane peering over legacy IP)
[Host] -> [ Switch A ] --------------- Standard IP Routing -------------> [ Switch B ] -> [Server]
                \                                                              /
                 \== TCP 64999 (SXP Peering: IP 10.1.1.5 <-> SGT 20) =========/

Inline Tagging (Cisco Meta Data – CMD)

Inline tagging embeds the SGT directly inside the data packet header at Layer 2 or Layer 3 as it leaves a switch port.

• Mechanism: The switch hardware modifies the frame by inserting a 16-bit field via a 802.1Q tag extension, an IEEE 802.1ae WAN MACsec header, or a Cisco Meta Data (CMD) shim header.
• Operation: Intermediate switches read the SGT directly from the frame without consulting software lookup tables or peering protocols. The tag travels with the packet across the entire native TrustSec fabric.
• Hardware Requirement: Requires Application-Specific Integrated Circuit (ASIC) support for CTS frame parsing on every intermediate link (e.g., Cisco Catalyst 9000 Series, Nexus 9000 Series).
• Advantage: Zero control plane overhead for host tracking; scales seamlessly across thousands of dynamic IP addresses without consuming software routing memory.

SGT Exchange Protocol (SXP – RFC 8320)

SXP is an IETF-standardized control-plane protocol that communicates over a TCP connection (port 64999). It transports identity-to-IP bindings when intermediate network equipment does not support hardware inline tagging.

• Mechanism: Network devices establish point-to-point SXP connections acting in one of two roles:
• SXP Speaker: Advertises locally learned IP-to-SGT mappings (e.g., an access switch that authenticated a host, or ISE itself).
• SXP Listener: Receives and stores IP-to-SGT mappings in its local forwarding table to enforce SGACL policies.
• Bi-directional: Nodes simultaneously advertise and receive bindings.
• Operation: When a host connects, the access switch sends an SXP update (IP 10.1.1.5 = SGT 20) across the routed network to the data center egress switch. When the host transmits standard IP packets, the intermediate network processes them normally. Upon arrival, the egress switch checks the source IP against its local SXP table, derives the SGT, and evaluates its SGACLs.
• Advantage: Enables TrustSec deployment over legacy switches, MPLS carrier backbones, and third-party network devices.
• Trade-Off: Higher memory usage on enforcement nodes, which must maintain IP-to-SGT binding tables for all tracked network endpoints.

Verifying and Troubleshooting TrustSec Operations

When identity propagation or SGACL enforcement breaks down, engineers must isolate whether the failure stems from PAC provisioning, authorization assignments, SXP control plane peering, or TCAM enforcement. Use the following diagnostic progression to pinpoint and resolve common issues:

+-----------------------------------------------------------------------------------+
| 1. CHECK TRUSTSEC CREDENTIALS & PAC                                               |
|    # show cts environment-data                                                    |
|    [FAIL] -> Verify RADIUS Secret / # test aaa group ...                          |
+-----------------------------------------------------------------------------------+
                                          |
                                       [PASS]
                                          v
+-----------------------------------------------------------------------------------+
| 2. VERIFY ENDPOINT SGT ASSIGNMENT                                                 |
|    # show authentication sessions interface <id> details                          |
|    [FAIL] -> Check ISE Authorization Policy & RADIUS Dictionaries                 |
+-----------------------------------------------------------------------------------+
                                          |
                                       [PASS]
                                          v
+-----------------------------------------------------------------------------------+
| 3. VALIDATE SXP PEERING & BINDINGS                                                |
|    # show cts sxp connections                                                     |
|    # show cts sxp sgt-map                                                         |
|    [FAIL] -> Verify TCP 64999 / Shared Password / Subnet Routing                  |
+-----------------------------------------------------------------------------------+
                                          |
                                       [PASS]
                                          v
+-----------------------------------------------------------------------------------+
| 4. VERIFY POLICY DOWNLOAD & COUNTERS                                              |
|    # show cts role-based permissions                                              |
|    # show cts role-based counters                                                 |
|    [DROPS] -> Audit SGACL rule logic, TCAM allocation, and catch-all policies     |
+-----------------------------------------------------------------------------------+

1. Verify Device Credentials and Environment Data

TrustSec devices must authenticate to Cisco ISE using a Protected Access Credential (PAC). If the switch cannot retrieve environment data, it cannot enforce policies:

switch# show cts environment-data
CTS Environment Data
====================
Current data state: COMPLETE
Authentication status: SUCCESSFUL
Last downloaded: 14:10:22 UTC Mon Mar 10 2026
Server list: 10.100.1.50:1812
Security Group Name: TrustSec_Switch
Security Group Tag: 2

• Troubleshooting Failures:
• If the status indicates FAILED or NEVER DOWNLOADED, verify the TrustSec credentials configured on the switch:
  text
switch(config)# cts credentials id <DEVICE_ID> password <PASSWORD>
switch# cts refresh environment-data
• Verify that RADIUS shared keys match between ISE and the device configuration (show run | section radius).

2. Confirm Ingress Endpoint SGT Assignment

Verify that the access switch successfully authenticated the client and tagged the active interface session:

switch# show authentication sessions interface GigabitEthernet1/0/1 details
            Interface:  GigabitEthernet1/0/1
          MAC Address:  0050.56a1.2b3c
         IPv4 Address:  192.168.10.45
            User-Name:  alice@enterprise.local
               Status:  Authorized
               Domain:  DATA
       Security Group:  20 (Developers)

• Troubleshooting Failures:
• If Security Group shows None or Unknown (0), examine ISE Live Logs (Operations > RADIUS > Live Logs).
• Confirm that the matching ISE Authorization Rule assigns an active SGT profile.
• Ensure the switch is configured to accept TrustSec attributes:
  text
switch(config)# aaa authorization network default group radius
switch(config)# cts role-based enforcement

3. Check SXP Peering and Binding States

For topologies utilizing SXP for propagation, confirm peer states and IP-to-SGT table mappings:

switch# show cts sxp connections
Peer IP          Local IP         Mode       State
--------------------------------------------------
10.100.1.50      10.200.1.1       Listener   ON
10.200.2.2       10.200.1.1       Speaker    ON

Inspect local IP-to-SGT bindings:

switch# show cts sxp sgt-map brief
IP Address        SGT     Source
---------------------------------
192.168.10.45     20      SXP
10.20.100.12      10      LOCAL

• Troubleshooting Failures:
• If the connection state remains stuck in PENDING_ON or OFF, verify network reachability over TCP port 64999 using telnet <peer-ip> 64999.
• Ensure the pre-shared MD5 password matches between both peers.

4. Inspect SGACL Downloads and Hardware Counters

On the egress enforcement switch, verify that the matrix cells have downloaded successfully and monitor hardware drop counts:

switch# show cts role-based permissions
From      To        SGACL-Name/State
========================================
20        10        SGACL_RESTRICTED_DEV
                    Active (Hardware programmed)
*         *         PERMIT_ALL_DEFAULT

Check hardware counters to determine if packets are dropped due to SGACL denies:

switch# show cts role-based counters
From SGT   To SGT     Hardware Permitted   Hardware Denied   Software Dropped
-----------------------------------------------------------------------------
20         10         104529               1420              0
30         10         0                    8921              0

• Troubleshooting Drops:
• If valid business traffic is dropped, check show cts role-based permissions from 20 to 10 to view the running access list line by line.
• Look for an implicit deny ip at the end of custom SGACL rules; add specific permit statements or adjust ISE matrix definitions accordingly.

Cisco Validated Design Standards, Sizing, and Hardware Compatibility

SGT Addressing Standards and Reserved Namespaces

The SGT field is a 16-bit integer supporting values from 0 to 65,535. Cisco reserves specific ranges to maintain fabric integrity:

• 0: Unknown / Untagged (Default status assigned to unmatched ingress traffic).
• 1: Default (Used for standard catch-all traffic classification).
• 2: TrustSec Device (Assigned to control-plane traffic originated by TrustSec infrastructure devices).
• 3: Network Infrastructure (Applied to management interfaces, switches, and ISE nodes).
• 4 – 65,519: User-Defined SGTs (Allocated for organizational roles, security zones, and microsegmentation policies).
• 65,520 – 65,535: Cisco Reserved (Reserved for internal routing architecture and future encapsulation protocols).

Platform Hardware Capability Matrix

Cisco Validated Design (CVD) Deployment Rules

Matrix Sizing Limits

Do not create a dense, fully populated $N \times N$ matrix. If an enterprise defines 200 SGTs, a fully saturated matrix produces 40,000 distinct policy cells, which exceeds the TCAM capacity of most access layer switches.

Instead, configure cells only for specific, necessary interactions and rely on default egress policies (Permit All for non-regulated traffic or Deny All in zero-trust enclaves) for unconfigured cells.

DENSE MATRIX (Anti-Pattern)              SPARSE MATRIX (CVD Best Practice)
Every cell defined -> TCAM Exhaustion    Only critical cells defined -> Scales smoothly

    SGT  10   20   30   40                   SGT  10   20   30   40
    10  [ACL][ACL][ACL][ACL]                 10  [   ][ACL][   ][   ]
    20  [ACL][ACL][ACL][ACL]                 20  [ACL][   ][ACL][   ]
    30  [ACL][ACL][ACL][ACL]                 30  [   ][   ][   ][ACL]
    40  [ACL][ACL][ACL][ACL]                 40  [   ][   ][   ][   ]
                                                 + Default Catch-All Rule

SXP Topology Sizing

When deploying SXP topologies without inline tagging:

• Deploy central SXP connection aggregators (such as pairs of Cisco Catalyst 9500s or dedicated Cisco ISE Policy Service Nodes [PSNs]) to minimize point-to-point mesh complexity.
• Adhere to individual platform scale limits: A single Cisco ISE 3.x PSN node supports up to 500,000 IP-to-SGT bindings and 2,000 active SXP connections.
• To prevent control-plane route churn, set SXP reconciliation timers to a minimum of 120 seconds in environments with high wireless client turnover.

Conclusion

Cisco ISE and TrustSec provide a scalable foundation for software-defined microsegmentation by breaking the dependency on static IP addresses and complex VLAN architectures. By abstracting network access into Classification (assigning SGTs at ingress), Propagation (transporting identity via Inline Tagging or SXP), and Enforcement (filtering traffic at egress via the SGACL matrix), organizations can deploy zero-trust security policies without redesigning their physical network topologies. When engineered according to Cisco Validated Designs, TrustSec minimizes switch TCAM consumption, simplifies policy management across enterprise fabrics, and ensures that identity context travels alongside every packet across the enterprise.

Please follow and like us: