Cisco Security Group Tags (SGTs) are 16-bit labels used by Cisco TrustSec to represent the security role of a user, device, or workload independently of IP subnet. ISE assigns or distributes SGTs, capable network devices carry those tags in the data plane or maintain IP-to-SGT bindings, and enforcement devices apply Security Group ACLs (SGACLs) according to source and destination group. Current ISE 3.5 continues to use this model and adds current TrustSec operational enhancements around policy distribution and transport.
Within Cisco Network Engineering, SGTs turn identity and role into a policy label. TrustSec Scalable Group Tags introduces the architecture; this article focuses on assignment, propagation, and operational controls.
An SGT represents role, not location
A security group should describe what the endpoint is allowed to do—employee, contractor, point-of-sale, production server, PCI server, guest, quarantine—rather than which VLAN it happens to occupy.
This makes policy portable across campus, WAN, data center, and changing IP addressing.
Keep group taxonomy small enough that engineers can understand the role model.
ISE can assign SGTs dynamically through authorization
Authorization policy can assign a Security Group to a successfully authenticated user or endpoint.
The resulting SGT becomes part of the session’s policy context and can be downloaded to TrustSec-aware network devices.
Use dynamic assignment when identity or posture should determine the tag instead of static port or IP configuration.
Static mappings are useful for non-authenticating systems
ISE supports IP-to-SGT mappings for servers, infrastructure, or devices that cannot participate in the normal authentication workflow.
Current ISE supports large mapping sets and mapping groups for operational scale.
Static mappings should have owners and expiry because an IP address can be reassigned while the old security role remains.
Inline tagging carries the SGT with the packet
TrustSec-capable devices can insert the SGT into the data plane so downstream enforcement does not need to infer identity from IP.
Inline tagging is the cleanest propagation method when every relevant hop supports it.
Verify interfaces and devices are configured to trust or propagate tags only from expected TrustSec peers.
SXP propagates IP-to-SGT bindings where inline tags are unavailable
Security Group Tag Exchange Protocol (SXP) shares IP-SGT mappings between speakers and listeners over TCP for devices that cannot carry inline tags end to end.
SXP extends TrustSec across brownfield networks but introduces another control-plane dependency.
Monitor peer state and mapping freshness; stale SXP bindings can apply a previous endpoint’s role to a reused IP address.
SGACLs enforce source-group to destination-group policy
Security Group ACLs define the permitted protocols between groups.
ISE’s TrustSec matrix applies SGACLs to source/destination cells and can use default Permit/Deny behavior for unconfigured relationships.
Write SGACLs around application dependencies rather than “permit IP” everywhere, and include logging selectively where investigation value justifies it.
Policy distribution needs redundancy
TrustSec devices obtain environment data and policy from ISE TrustSec AAA/HTTPS services depending on supported design.
Current ISE 3.5 documentation supports configuring multiple ISE TrustSec servers for reliability and newer HTTPS transfer options for environment data on supported devices.
Test policy refresh during one ISE node failure before relying on tags for critical segmentation.
Change of Authorization accelerates policy refresh
ISE can trigger Environment or Policy CoA so network devices request updated TrustSec information after changes.
Use deployment/push operations deliberately; Cisco warns against unnecessary frequent pushes.
Batch matrix/SGACL changes and validate before forcing the whole TrustSec domain to refresh.
Tags should be observable end to end
When a flow is denied unexpectedly, verify the source endpoint’s assigned SGT, propagation method, device mapping table, destination group, SGACL downloaded, and enforcement hit.
Do not troubleshoot the SGACL first if the packet arrived with the wrong or unknown tag.
Operational dashboards should identify unknown/unmapped SGTs and stale bindings.
SGT taxonomy should survive network changes
Keep SGT numbers and names stable when VLANs, subnets, wireless controllers, or data-center fabrics change.
This is one of TrustSec’s biggest advantages: segmentation intent can remain role-based while addressing evolves.
Change a security group only when business role or trust level changes, not because the endpoint moved floors.
Cisco Security Group Tagging succeeds when labels remain accurate and enforceable
The mature design has a controlled SGT taxonomy, dynamic assignment where identity is known, static mappings only where necessary, monitored inline/SXP propagation, redundant policy distribution, and SGACLs aligned to real application dependencies.
Tags simplify segmentation only when the network can prove which tag a flow carried and why.
SGT values are globally meaningful only inside the TrustSec domain where policy owners keep the taxonomy consistent. Reusing the same numeric tag for a different role in another independently managed domain creates confusion during mergers or interconnects. Maintain one source of truth for SGT number, name, description, owner, and permitted use.
Trust boundaries should determine whether an incoming tag is accepted. A switch should not blindly trust SGT information from an untrusted access port or third-party device. Configure inline propagation only between known TrustSec-capable peers and classify traffic at ingress where identity is actually established. Otherwise an attacker could attempt to inject a more privileged tag.
Current ISE 3.5 can transfer TrustSec environment data using HTTPS on supported devices as an alternative to traditional RADIUS-based exchange. HTTPS can improve speed and reliability but introduces port 9603, credentials, certificate, and reachability dependencies. Treat policy-distribution transport as part of the control plane and monitor failures explicitly.
TrustSec deployment verification should be used after matrix or SGACL change. Current ISE provides dashboard alarms when configured TrustSec policy and network-device state differ. A successful policy edit in ISE is not proof that every enforcement device downloaded it; verify synchronization before relying on a newly tightened rule during an incident.
SXP scaling should be planned carefully in mixed networks. Speakers and listeners propagate IP-SGT bindings over TCP, and mapping churn can grow quickly in DHCP-heavy or roaming environments. Prefer inline tagging where supported and use SXP for the brownfield gaps it was designed to bridge rather than making one centralized SXP node the source of every binding.
Static IP-SGT mappings need conflict detection. If DHCP later assigns a statically mapped server IP to another endpoint, the tag can remain authoritative even though the asset changed. Reserve static addresses, monitor duplicate/overlapping mappings, and remove mappings as part of server retirement.
Security Group Tagging should integrate with wireless and VPN policy so a user’s role persists across access methods. The same employee or contractor can connect by campus 802.1X, wireless, or remote access. Where supported, use identity/authorization to assign the same business role instead of creating separate network-specific segmentation taxonomies.
SGACL logging should be selective because logging every permitted or denied flow can overwhelm devices and collectors. Log high-value denies, privileged management paths, or troubleshooting rules where evidence is useful. Use sampled or targeted logging rather than turning TrustSec into a packet-level audit system by default.
Change management should distinguish tag renaming from tag-number changes. Renaming a group for clarity is less disruptive than changing the numeric SGT that enforcement devices and mappings reference. Treat numeric changes as migrations: update assignments, policy matrix, static mappings, SXP bindings, and downstream consumers in a controlled sequence.
Metrics should include endpoints with Unknown/no tag, SXP peer health, policy synchronization alarms, matrix changes, SGACL denies, and stale static mappings. These operational signals tell whether the TrustSec label system remains trustworthy as the network changes.
Tag propagation across WAN or encryption boundaries should be validated explicitly. Some links can carry inline SGT, others require SXP or reclassification at the far side. Build a path map for important flows showing where the tag is inserted, preserved, translated, learned from IP mapping, or dropped so enforcement assumptions are visible.
SGT assignment and profiling can be combined carefully. ISE can use authenticated user/device attributes or profiling-derived logical groups as authorization conditions that assign SGTs. When profiling contributes to the decision, make the resulting access conservative because a mistaken device classification now becomes a network-wide role label.
Policy matrices should be reviewed for asymmetric intent. Source A to destination B may need HTTPS while B to A should have no initiated access. SGACL relationships are directional; do not assume a permit in one cell implies the reverse direction. Document stateful/firewall behavior at enforcement points that may make the observed traffic appear symmetric.
External integrations consuming SGTs should have version/change governance. Firewalls, SD-Access, wireless, and analytics products can use TrustSec context. Before renumbering or deleting a tag, inventory those consumers so one ISE cleanup does not break policy outside the campus switch where the change was tested.
Environment and policy data refresh should be rehearsed after ISE upgrades. Verify switches/routers can retrieve SGT/SGACL updates through the configured RADIUS or HTTPS path, then validate one live session end to end. Upgrade success is incomplete if administrative login works but TrustSec policy distribution is stale.
Security reviews should look for groups whose name no longer matches their effective privilege. A tag called ‘Contractor’ may gradually accumulate permits until it behaves like ‘Employee’. Review matrix relationships by business intent so SGT labels remain meaningful instead of becoming decorative names for legacy permissions.
