Cisco TrustSec and SGTs: How They Integrate with 802.1X

TrustSec and 802.1X: Where They Intersect

802.1X authenticates an endpoint and places it in the right VLAN with the right per-port ACL (dACL). TrustSec assigns a Security Group Tag (SGT) to that authenticated session and uses the tag to enforce segmentation policies at the network layer — between segments, not just at the access port.

The intersection point is the RADIUS Access-Accept. When ISE authenticates an endpoint via 802.1X, the same Access-Accept that carries the VLAN assignment can also carry an SGT. The switch assigns the SGT to the session and either propagates it inline (in the frame headers between TrustSec-capable switches) or advertises it via SXP to non-TrustSec devices.

TrustSec does not replace 802.1X. It extends what 802.1X can enforce. Without 802.1X (or MAB) providing the authenticated identity, ISE has no basis on which to assign an SGT — every endpoint would be unknown and tagged with SGT 0 (unknown). The identity established by 802.1X is the input that makes the TrustSec SGT meaningful.

Security Group Tags: The Concept

An SGT is a 16-bit numeric tag (values 0-65535, with several reserved). Cisco ISE manages the SGT namespace. SGTs are assigned semantically — they represent the identity class of the authenticated endpoint, not a VLAN or a subnet:

• SGT 2: TrustSec devices (reserved)
• SGT 3: Network services
• SGT 4: Employees (custom example)
• SGT 5: Contractors (custom example)
• SGT 6: Corp-Phones (custom example)
• SGT 7: IoT-Devices (custom example)
• SGT 255: Unknown (catch-all for unclassified traffic)

The power of SGTs is that they are independent of IP addressing and VLAN structure. An employee working from the corporate office (VLAN 10) and the same employee connecting from a branch office (different VLAN, different subnet) both receive SGT 4. The SGACL enforcement policy applies identically in both locations because it is based on the tag, not the IP or VLAN.

Phase 1: Enabling TrustSec on IOS XE

TrustSec on a Cisco Catalyst 9300 requires the switch to be enrolled in the TrustSec domain. The switch authenticates to ISE using its own device credentials (PAC — Protected Access Credential) before it can tag and enforce SGT policy.

Switch Configuration — TrustSec Enrollment

! Enable CTS globally
cts authorization list ISE_SERVERS

! Apply to the RADIUS server group
aaa group server radius ISE_SERVERS
 server name ISE-PSN-1
 server name ISE-PSN-2

! CTS credentials — switch device ID and password
cts credentials id SW1-BLDG1 password TrustSecPwd!9300

! Enable TrustSec on the uplink interface (trunk to distribution)
interface TenGigabitEthernet1/1/1
 cts manual
  policy static sgt 2 trusted

The cts credentials command sets the identity that the switch presents when it authenticates to ISE to join the TrustSec domain. Navigate to Work Centers > TrustSec > Components > Network Devices in ISE and ensure the switch device definition includes TrustSec settings:

• Device Name: SW1-BLDG1
• TrustSec: Enabled
• Device ID: SW1-BLDG1
• Password: TrustSecPwd!9300
• Use Device ID for TrustSec Identification: Enabled

After configuring the credentials, the switch downloads its PAC from ISE:

SW1# cts credentials id SW1-BLDG1 password TrustSecPwd!9300

SW1# show cts credentials
CTS password is defined in keystore, device-id = SW1-BLDG1

Verifying TrustSec Device Authentication

SW1# show cts pac
AID: 1100E046659D4275B644BF946ECA258C
PAC-type = Cisco Trustsec
I-ID: SW1-BLDG1
A-ID-Info: Identity Services Engine
Credential Lifetime: 07:40:56 UTC Sat Mar 18 2027

The PAC has a validity period. Configure ISE to auto-provision new PACs before expiration to avoid authentication interruptions. Navigate to Work Centers > TrustSec > Network Devices and set the PAC TTL to 90 days with automatic re-provisioning enabled.

Phase 2: SGT Assignment via 802.1X

With the switch enrolled in TrustSec, ISE can now assign SGTs in the RADIUS Access-Accept alongside VLAN and dACL attributes.

ISE Security Group Configuration

Navigate to Work Centers > TrustSec > Components > Security Groups. Create the following groups for the lab environment:

ISE Authorization Profile with SGT

Navigate to Policy > Policy Elements > Results > Authorization > Authorization Profiles. Edit or create the profile for corporate employees:

• Profile Name: Corp-Employees-Full
• VLAN: 10
• Security Group: Employees (SGT 4)
• Downloadable ACL: CORP-USERS-ACL (optional, can be replaced by SGACL enforcement)

The Security Group field in the Authorization Profile is the SGT assignment mechanism. When ISE sends the Access-Accept, it includes the Cisco-AV-Pair attribute cts:security-group-tag=4 (SGT 4 for Employees).

Verifying SGT Assignment on the Switch

After an endpoint authenticates via 802.1X:

SW1# show authentication sessions interface GigabitEthernet1/0/1 details
            Interface:  GigabitEthernet1/0/1
          MAC Address:  a4b1.c2d3.e4f5
            User-Name:  CORP\jsmith
              Status:  Auth
              Domain:  DATA
      Security Policy:  Restrict
      Security Status:  Secured

Server Policies:
              Vlan Group:  Vlan: 10
               SGT:  0004-0

Method status list:
       Method           State
       dot1x            Authc Success

SGT: 0004-0 — the endpoint's session is tagged with SGT 4 (Employees). The -0 indicates the tag was assigned dynamically (not static). The switch now marks every packet from this endpoint's session with SGT 4 as it forwards traffic toward the distribution/core layer.

Phase 3: SGT Propagation

Once the access switch assigns an SGT, the tag must be carried through the network to the egress point where policy is enforced. There are two propagation methods:

Method 1: Inline Tagging (CTS/SXP Inline)

TrustSec-capable switches propagate SGTs inline in a proprietary field in the Ethernet frame (the CTS header). This requires all switches in the path from ingress to egress to support TrustSec inline tagging.

On the trunk interface between the access switch and distribution switch:

interface TenGigabitEthernet1/1/1
 description UPLINK-TO-DIST-SW1
 switchport mode trunk
 cts manual
  policy static sgt 2 trusted
  no propagate sgt

Wait — no propagate sgt sounds counterintuitive. The propagate sgt command controls whether the access switch propagates incoming SGT tags from the distribution switch downward. On access switches, the access-facing ports are where SGTs are assigned (from ISE), not received. The uplink toward distribution should have propagate sgt enabled (the default) so that SGTs assigned at the access layer travel upstream.

For the distribution switch's trunk interface facing the access switch:

interface TenGigabitEthernet1/1/2
 description DOWNLINK-TO-ACCESS-SW1
 switchport mode trunk
 cts manual
  policy static sgt 2 trusted

Verify inline tagging is operational:

SW1# show cts interface TenGigabitEthernet1/1/1
CTS Information for Interface TenGigabitEthernet1/1/1:
    Propagate SGT:      Enabled
    Trusted Port:       Enabled
    SGT:                2
    IFC state:          OPEN
    Authentication-mode: NO AUTH
    Dot1x role:         N/A
    CTS roles:          Peer role: CTS Responder

IFC state: OPEN and Propagate SGT: Enabled confirm inline tagging is active on this trunk.

Method 2: SXP (SGT Exchange Protocol)

SXP is used when some devices in the path do not support inline TrustSec tagging. SXP is an overlay protocol that maps IP-to-SGT bindings and distributes them to SXP peers. Non-TrustSec switches forward traffic normally; the SXP binding table tells the egress enforcement device what SGT to apply based on source IP.

SXP is typically used for:

• Legacy switches that cannot carry inline CTS headers
• Firewall integration (Cisco Firepower uses SXP to receive SGT bindings)
• Server VLANs where inline tagging is not supported

Configure an SXP connection from the access switch (SXP speaker) to ISE (SXP listener):

cts sxp enable
cts sxp default password SXPsecret456
cts sxp default source-ip 10.0.99.1
cts sxp connection peer 10.0.0.10 password default mode local speaker

In ISE, navigate to Work Centers > TrustSec > SXP > SXP Devices and enable SXP. ISE acts as an SXP listener by default, accepting bindings from all SXP speakers. Navigate to Work Centers > TrustSec > SXP > SXP Local Bindings to verify that ISE is receiving the IP-to-SGT mappings from the switch.

SW1# show cts sxp connections brief
SXP              : Enabled
Highest Version Supported: 5
Default Password : Set
Default Source IP: 10.0.99.1
Connection retry open period: 120 secs
Reconcile period: 120 secs
Retry open timer is not running
------------------------------------------
Peer IP          : 10.0.0.10
Source IP        : 10.0.99.1
Conn status      : On
Conn version     : 5
Local mode       : SXP Speaker
Connection inst# : 1
TCP conn fd      : 1
TCP conn password: default SXP password
Peer SXP on ISE  : Connected

Conn status: On and Peer SXP on ISE: Connected confirm the SXP session is established. Run show cts sxp sgt-map to see the IP-to-SGT bindings being shared:

SW1# show cts sxp sgt-map
Active IPv4-SGT Bindings Information
IP Address          SGT     Source
==========================================
192.168.10.101      4       LOCAL
192.168.10.102      4       LOCAL
192.168.10.103      6       LOCAL

Phase 4: SGACL Policy and Enforcement

SGACLs (Security Group ACLs) define what traffic is permitted between SGT pairs. They are configured in ISE and downloaded to enforcement devices (typically distribution or core switches, or next-generation firewalls).

SGACL Configuration in ISE

Navigate to Work Centers > TrustSec > Components > Security Group ACLs. Create an SGACL:

• Name: Employees-to-Servers
• ACL Content:

  permit tcp dst eq 443
  permit tcp dst eq 80
  permit tcp dst eq 22
  deny ip
  

Create another:

• Name: Contractors-to-Servers
• ACL Content:

  permit tcp dst eq 443
  permit tcp dst eq 80
  deny ip
  

TrustSec Egress Policy Matrix

Navigate to Work Centers > TrustSec > TrustSec Policy > Egress Policy > Matrix. The matrix is a grid of Source SGT × Destination SGT with an SGACL assigned to each cell.

Configure:

• Source: Employees (SGT 4) → Destination: Servers (SGT 9) → SGACL: Employees-to-Servers
• Source: Contractors (SGT 5) → Destination: Servers (SGT 9) → SGACL: Contractors-to-Servers
• Source: IoT-Devices (SGT 7) → Destination: Servers (SGT 9) → SGACL: Deny IP (implicit deny)
• Source: Guests (SGT 8) → Destination: Servers (SGT 9) → SGACL: Deny IP

The matrix approach means you define policy once in ISE and it is distributed to all enforcement points. Adding a new SGT (e.g., a new contractor group) requires only updating the ISE matrix — the policy distributes automatically.

Enforcement Switch Configuration

The distribution or core switch acts as the TrustSec enforcement point. It downloads the SGACL matrix from ISE and applies it to traffic flows.

! Enable role-based enforcement
cts role-based enforcement
cts role-based enforcement vlan-list 10,20,99

! Download policy from ISE
cts role-based monitor all

The cts role-based enforcement vlan-list command limits SGACL enforcement to specific VLANs. Start with your production VLANs after testing in monitor mode (cts role-based monitor all enables monitoring without enforcement — traffic is counted but not dropped).

Verifying SGACL Enforcement

DIST-SW1# show cts role-based permissions
IPv4 Role-based permissions default:
    Permit IP-00
IPv4 Role-based permissions from group 4:Employees to group 9:Servers:
    Employees-to-Servers-00
IPv4 Role-based permissions from group 5:Contractors to group 9:Servers:
    Contractors-to-Servers-00
IPv4 Role-based permissions from group 7:IoT-Devices to group 9:Servers:
    Deny IP-00

DIST-SW1# show cts role-based counters
Role-based IPv4 counters
From    To      SW-Denied  HW-Denied  SW-Permitted  HW-Permitted
4       9       0          0          14820         1204830
5       9       0          0          3421          284110
7       9       0          4821        0             0

SGT 7 (IoT-Devices) to SGT 9 (Servers) shows 4,821 HW-Denied packets — the IoT devices are being blocked from server access by the Deny IP SGACL. SGT 4 (Employees) and SGT 5 (Contractors) are passing traffic as expected by their respective SGACLs.

TrustSec Monitor Mode

Just as 802.1X has Monitor Mode (see Article 26: Monitor Mode vs Low-Impact Mode vs Closed Mode), TrustSec has a monitoring phase:

DIST-SW1# cts role-based monitor all

In TrustSec monitor mode, SGACL policy is evaluated but not enforced — traffic that would be denied is counted but passes. This lets you validate that the SGT policy is correct before enforcing it. Check the counters:

DIST-SW1# show cts role-based counters
Role-based IPv4 counters
From    To      SW-Denied  HW-Denied  SW-Permitted  HW-Permitted
7       9       0          0          0             4821

In monitor mode, IoT-to-Servers shows zero denied — all 4,821 packets passed (but would have been denied under enforcement). This gives you confidence that the policy will block the right traffic before you turn on enforcement.

To move to enforcement:

DIST-SW1# no cts role-based monitor all
DIST-SW1# cts role-based enforcement
DIST-SW1# cts role-based enforcement vlan-list 10,20

Practical Integration Points

TrustSec + dACL: Which Takes Precedence?

If an authorization profile in ISE assigns both a dACL and an SGT, both are applied:

• The dACL is enforced at the ingress port (per-session ACL on the access switch)
• The SGT is used for SGACL enforcement at the egress device

They serve different purposes and can coexist. The dACL controls what traffic the endpoint can send from its local port. The SGACL controls what traffic is permitted between SGT pairs anywhere in the network. As you mature your TrustSec deployment, you may find that SGACLs replace some dACL functions — particularly for east-west traffic control that dACLs cannot address (since dACLs only apply at the ingress port, not at intermediate switching points).

TrustSec and VLAN Assignment

Dynamic VLAN assignment (see Article 14: Dynamic VLAN Assignment with 802.1X and Cisco ISE) and SGT assignment are independent. A contractor endpoint can be placed in VLAN 10 with SGT 5. The VLAN controls broadcast domain membership and IP addressing. The SGT controls what the contractor can reach on the network — regardless of which VLAN they are in. This is the key advantage of TrustSec: two endpoints in the same VLAN with different SGTs can have completely different access policies enforced at the distribution layer.

Troubleshooting

Symptom: show cts role-based permissions shows no entries or only the default permit

Cause: The enforcement switch has not downloaded the SGACL policy from ISE, or the switch is not enrolled in TrustSec (no valid PAC). Check show cts pac — if no PAC is present, the switch cannot authenticate to ISE as a TrustSec device and will not receive policy.

Fix: Verify cts credentials id [id] password [password] is configured and matches the ISE network device definition. Run cts refresh policy to force a policy download. In ISE, navigate to Work Centers > TrustSec > Components > Network Devices and confirm the switch's TrustSec settings. Check that UDP 1812 and TCP 443 (ISE pxGrid, used for some TrustSec operations) are not blocked between the switch management VLAN and ISE.

Symptom: Endpoints are authenticated with an SGT visible in show authentication sessions, but show cts role-based counters shows no traffic counts

Cause: The SGACL policy has not been configured for those SGT pairs, or TrustSec enforcement is not enabled on the distribution switch VLANs carrying the traffic. If the source and destination SGTs have no policy entry in the ISE matrix, the default policy (permit) applies and no counters increment in a meaningful way for the specific pair.

Fix: In ISE, navigate to Work Centers > TrustSec > TrustSec Policy > Egress Policy > Matrix and verify the source/destination SGT cell has an SGACL assigned. Also verify cts role-based enforcement vlan-list on the distribution switch includes the VLANs carrying the source and destination traffic. If enforcement VLANs are not specified, run cts role-based enforcement globally (applies to all VLANs) — be aware this has broader impact and should be done in monitor mode first.

Symptom: SXP session shows Conn status: Off between the access switch and ISE

Cause: TCP port 64999 (SXP default) is being blocked between the switch management IP and ISE, or the SXP password does not match between the switch and ISE configuration.

Fix: Verify the SXP password matches on both sides. In ISE, navigate to Work Centers > TrustSec > SXP > SXP Devices and confirm the speaker entry for the switch shows the correct source IP. Verify TCP 64999 is permitted from the switch management VLAN to ISE. Run debug cts sxp on the switch for connection-level troubleshooting. Note: also confirm cts sxp enable is in the global configuration — without it, no SXP connections will establish regardless of the peer configuration.

What's Next: Article 30: 802.1X Scalability and High Availability Design for Large Enterprise Networks — TrustSec gives you identity-based segmentation. Article 30 brings together every element of this series — 802.1X, RADIUS redundancy, TrustSec, deployment modes, and phased rollout — into a unified design framework for large enterprise networks with thousands of ports and multiple ISE nodes.