Network Segmentation: TrustSec, SGT and Micro-Segmentation Guide

Introduction

Imagine a flat enterprise network where every endpoint can reach every other endpoint freely. A single compromised device -- whether a contractor laptop, an IoT camera, or a rogue wireless client -- can move laterally across your entire infrastructure, accessing production servers, financial databases, and critical applications without any resistance. This scenario is not hypothetical; it plays out regularly in organizations that have not implemented network segmentation.

Network segmentation is the foundational practice of dividing a network into isolated zones to restrict lateral movement, enforce role-based access, and maintain compliance. But traditional segmentation approaches -- relying on VLANs, IP-based ACLs, and perimeter firewalls -- struggle to scale in modern hybrid environments that span campus networks, branch offices, data centers, and cloud workloads. Managing thousands of ACL entries across hundreds of switches is operationally unsustainable and prone to human error.

This is where Cisco TrustSec, Security Group Tags (SGTs), and micro-segmentation enter the picture. These technologies deliver software-defined segmentation that is identity-aware, topology-independent, and scalable across multi-domain environments. In this guide, we will explore how SGTs work, how they propagate across the network, how macro and micro segmentation strategies differ, and how firewalls integrate with SD-Access fabrics to provide stateful enforcement. Whether you are preparing for a CCNP certification or designing a segmentation strategy for your enterprise, this article provides the technical depth you need.

What Is Network Segmentation and Why Does It Matter?

Network segmentation is the practice of partitioning a network into smaller, isolated segments to control traffic flow between them. The goal is straightforward: limit the blast radius of a security breach, enforce least-privilege access between user groups and resources, and meet regulatory compliance requirements.

The Limitations of Traditional Segmentation

Traditional approaches to segmentation rely on three primary mechanisms:

VLANs: Separate broadcast domains at Layer 2, but do not inherently restrict Layer 3 communication between VLANs without additional ACLs.
IP-based ACLs: Filter traffic based on source and destination IP addresses. These are static, topology-dependent, and extremely difficult to maintain at scale.
Perimeter firewalls: Provide North/South traffic inspection but leave East/West traffic within the network largely unmonitored.

In a deployment with 200 or more sites and a wide variety of endpoints -- Windows, Linux, macOS, Docker containers, Kubernetes pods, and IoT devices -- managing IP-based ACLs becomes a nightmare. Every IP address change, subnet redesign, or new application deployment requires updating ACLs across potentially hundreds of devices. Errors in these policies directly affect user experience and can create security gaps.

The Case for Software-Defined Segmentation

Software-defined segmentation addresses these challenges by decoupling security policy from network topology. Instead of writing rules based on IP addresses, you define policies based on identity -- who or what is connecting to the network. This approach offers several advantages:

Hybrid deployment integrity: Maintain consistent security across Catalyst switches, Meraki platforms, wireless controllers, and SD-WAN routers.
Reduced policy duplication: Eliminate the need to replicate policies across multiple platforms manually.
Fewer errors: A single source of truth for policy management reduces the possibility of configuration mistakes.
Simplified operations: Centralized policy definition and enforcement through a unified management interface.

What Are Security Group Tags (SGTs)?

At the heart of Cisco TrustSec lies the Security Group Tag (SGT) -- a 16-bit value embedded in network traffic that identifies the role or classification of the source endpoint. SGTs are the building blocks of identity-based segmentation.

How SGTs Work

When an endpoint connects to the network, it is authenticated and authorized through Cisco Identity Services Engine (ISE). Based on the authentication result -- which can consider factors like Active Directory group membership, device type, posture compliance, and connection method -- ISE assigns an SGT to that endpoint. For example:

Employee = SGT 10
Contractor = SGT 20
Camera = SGT 5
BYOD = SGT 7
Lighting = SGT 20
HVAC = SGT 30

This SGT value travels with the traffic as it moves through the network. Enforcement points -- switches, routers, firewalls -- use the source and destination SGTs to look up the appropriate policy in an SGT-based access control matrix and determine whether to permit or deny the traffic.

The SGT in the Frame

The SGT is carried in the Cisco Meta Data (CMD) field within the Ethernet frame. The CMD header includes an EtherType, version, length, options, and the SGT value itself. This CMD field is inserted between the 802.1Q tag and the payload in the Ethernet frame:

Field	Description
DstMAC / SrcMAC	Standard Ethernet addressing
802.1Q	VLAN tag
CMD	Cisco Meta Data containing the SGT
ETYPE	EtherType field
PAYLOAD	Original packet data

This inline tagging approach means that every packet carries its security classification, making enforcement possible at any point in the network without requiring the enforcement device to query an external database for every flow.

How Does ISE Classify Endpoints for Network Segmentation?

Cisco ISE serves as the centralized policy engine for the entire segmentation architecture. It handles authentication, authorization, and SGT assignment for all endpoints connecting to the network.

Authentication Methods

ISE supports multiple authentication methods to classify endpoints:

802.1X with EAP: The primary method for user-facing endpoints. The endpoint presents credentials (certificate, password, or token) to the network access device, which forwards the request to ISE via RADIUS (UDP port 1812 for authentication, UDP port 1813 for accounting).
MAC Authentication Bypass (MAB): For devices that cannot perform 802.1X -- such as printers, cameras, and other IoT devices -- the switch sends the device's MAC address to ISE as the credential. ISE matches it against its profiling database and assigns the appropriate SGT.

Authorization Results

Upon successful authentication, ISE returns an authorization result that can include any combination of:

Authorization Attribute	Description
Dynamic VLAN	Assigns the endpoint to a specific VLAN (per port, per domain, or per MAC)
Downloadable ACL (dACL)	A granular ACL pushed to the switch for wired connections
Named ACL	Referenced ACL for wired and wireless connections
Security Group Tag	The 16-bit SGT value for group-based policy

For example, an Employee authorization profile might include:

! Authorization result for Employee
VLAN: 100
SGT: 10
dACL: permit ip any any

While a Contractor profile might be more restrictive:

! Authorization result for Contractor
SGT: 20
dACL: deny ip host <critical-server> any
       permit ip any any

SGT Classification Methods

Beyond dynamic RADIUS-based classification, SGTs can be assigned through several static methods across different parts of the network:

Classification Method	Use Case
VLAN to SGT	Map entire VLANs to an SGT on campus access switches
IP to SGT	Manually bind specific IP addresses to SGTs
Subnet to SGT	Assign SGTs to entire subnets
L3 Interface (SVI) to SGT	Tag all traffic on a specific Layer 3 interface
L2 Port to SGT	Tag all traffic on a specific switchport
VM (Port Profile) to SGT	Classify virtual machines on hypervisors

Pro Tip: Dynamic classification through ISE with Active Directory attributes is the most scalable approach. Static IP-to-SGT mappings should be reserved for infrastructure devices, servers, and network segments where dynamic authentication is not feasible.

How Are SGTs Propagated Across the Network?

Once an endpoint is classified and its SGT is assigned, that tag must travel with the traffic so that enforcement points downstream can apply the correct policy. There are two fundamentally different propagation methods.

Data Plane Propagation (Inline Tagging)

With inline tagging, the SGT is carried directly within the data traffic. The switch or router inserts the CMD header containing the SGT into every frame leaving the classified port. Downstream devices read the SGT from the frame and use it for policy lookup.

Inline tagging is supported across multiple encapsulation types:

Transport	How SGT Is Carried
Ethernet	CMD header in the Ethernet frame
MACSec	CMD within encrypted Ethernet
LISP/VXLAN	SGT in the VXLAN header (used in SD-Access)
IPSec	CMD within IPSec-encrypted traffic
DMVPN	CMD in GRE encapsulation
GETVPN	CMD in encrypted group VPN traffic

For example, when two switches are connected and inline tagging is enabled:

SW1 (10.1.1.1)  ------>  R1  ------>  SW2 (10.20.20.1)
SGT 5/Employees                       SGT 7/WebServers
[IP][SGT=5]         [IP][SGT=5]

The SGT value of 5 (Employees) is carried inline through every hop, and the destination switch (SW2) can enforce policy based on the source SGT 5 against the destination SGT 7 (WebServers).

Pro Tip: Inline tagging is the preferred propagation method because it scales better and provides enforcement at the destination without relying on control-plane databases. It eliminates TCAM exhaustion issues that can occur with SXP-based approaches.

Control Plane Propagation (SXP)

When network devices do not support inline tagging, the SGT Exchange Protocol (SXP) provides an alternative. SXP shares IP-to-SGT mapping data over a control-plane protocol between devices. The actual data packets do not carry the SGT -- instead, the enforcement device looks up the source IP address in its SXP-learned mapping table to determine the SGT.

SW1 (10.1.1.1)  ------>  SW2 (10.20.20.1)
SGT 5/Employees          SGT 7/WebServers
[IP only]                 SXP mapping: 10.1.1.1 = SGT 5

SXP also works through pxGrid, which allows ISE to share IP-to-SGT mappings with platforms like Cisco Secure Firewall Management Center (FMC).

SXP Scalability Considerations

While SXP provides a path for non-inline-capable devices, it has significant scalability limitations:

Each Catalyst 9K switch that uses SXP downloads the full source and destination TrustSec matrix, potentially leading to TCAM exhaustion.
ISE has a finite limit on how many SXP connections it can support. In real-world deployments, as few as 15% of a rollout has been observed to produce 950+ SXP connections, at which point SXP update stability becomes a concern.
Platform-specific maximum IP-to-SGT binding limits apply.
SXP can scale further using SXP reflectors, but managing hundreds of SXP connections adds operational complexity.

For these reasons, the recommended approach is to deploy inline tagging wherever possible and decommission SXP at sites where inline-capable hardware is available.

Macro vs. Micro Segmentation: Understanding the Network Segmentation Strategy

A comprehensive segmentation strategy uses two complementary layers: macro segmentation and micro segmentation.

Macro Segmentation with Virtual Networks (VNs)

Macro segmentation provides complete isolation between groups of endpoints by placing them in separate Virtual Networks (VNs). In an SD-Access fabric:

A Virtual Network (VN) equals a VRF equals a LISP Instance ID
There is complete isolation between VNs -- no communication is possible by default
The default policy between VNs is no communication

For example, an organization might define:

Virtual Network	Purpose	Endpoints
VN: Users	Corporate employees and contractors	Employee laptops, contractor devices
VN: IoT	Building automation systems	Cameras, HVAC systems, lighting
VN: Guest	Visitor internet access	Guest wireless devices

Layer 3 Virtual Networks use VRFs and LISP Instance IDs to maintain separate routing topologies, where endpoint IPv4/IPv6 addresses are routed within a specific L3VN. Layer 2 Virtual Networks use LISP Instance IDs and VLANs to maintain separate switching topologies, where endpoint MAC addresses are switched within an L2VN. Edge Nodes, Border Nodes, and Fabric APs add and remove Virtual Network assignments.

Micro Segmentation with SGTs

Within each Virtual Network, micro segmentation uses SGTs to provide granular, role-based access control. Key characteristics of SGT-based micro segmentation:

Location-independent policy: SGT-based rules apply regardless of where the endpoint connects.
Simple permit/deny contracts: Policies are defined as contracts (SGACLs) between source and destination SGT pairs.
Default policy flexibility: The default policy between SGTs can be set to either permit or deny all traffic.

Consider an IoT Virtual Network with these SGT assignments:

Source SGT	Destination SGT: Lighting (20)	Destination SGT: HVAC (30)
Camera (5)	Permit	Deny
BYOD (7)	Deny	Permit

In this matrix, cameras can communicate with lighting systems but not HVAC controllers, while BYOD devices can reach HVAC systems but not lighting controllers. This level of granularity is impossible to achieve with VLANs alone.

How Segmentation Operates in SD-Access

Within an SD-Access fabric, segmentation operates through three stages:

Classification: Dynamic assignment through ISE or static mappings
Propagation: SGT carried in the VXLAN header across the fabric overlay
Enforcement: Applied at the egress Fabric Edge node

The VXLAN encapsulation in SD-Access natively carries both the VRF (Virtual Network) and the SGT in the header, meaning no additional configuration is needed for SGT propagation within the fabric.

VXLAN Data Plane Propagation:
[ETHERNET][IP][UDP][VXLAN (VRF + SGT)][IP][ETHERNET][PAYLOAD]

SD-Access Fabric Architecture for Network Segmentation

The SD-Access fabric provides the infrastructure that enables scalable network segmentation. Understanding the fabric roles is essential for designing a segmentation strategy.

Fabric Roles and Terminology

Fabric Role	Description
Control-Plane Nodes	Map System that manages endpoint-to-device relationships
Fabric Edge Nodes	Access or distribution devices that connect wired endpoints to the fabric
Fabric Border Nodes	Core devices that connect external Layer 3 networks to the fabric
Fabric Wireless Controller	WLC that connects Fabric APs and wireless endpoints to the fabric
Intermediate Nodes (Underlay)	Transport devices that carry fabric traffic
Identity Services (ISE)	NAC and identity services for dynamic endpoint-to-group mapping and policy definition

Cisco Catalyst Center provides two critical functions on top of the fabric:

Network Automation: GUI and APIs for intent-based automation of wired and wireless fabric devices
Network Assurance: Data collectors that analyze endpoint-to-application flows and monitor fabric device status

ISE and Catalyst Center Integration

For the segmentation architecture to function, ISE and Catalyst Center must establish a trust relationship. This integration uses three communication channels:

Protocol	Port	Purpose
HTTPS	TCP/443	Establish trust relationship
ERS (External RESTful Services)	TCP/9060	Program ISE via REST API (read/write)
pxGrid	TCP/5222 & 8910	Exchange TrustSec metadata and context

To enable this integration, the following ISE services must be configured:

pxGrid Services: Enable under Administration > System > Deployment > Select ISE Host Name
ERS Settings: Enable ERS for Read/Write on the Primary Administration Node (PAN), and enable ERS for Read on all other nodes in a distributed deployment

Pro Tip: PSNs (Policy Service Nodes) can optionally be placed behind a load balancer and accessed via Load Balancer Virtual IP addresses (VIPs) for RADIUS authentication traffic.

Transit Options for SGT Propagation Between Fabric Sites

When an organization has multiple fabric sites, SGTs must be propagated between them. There are three transit options, each with different capabilities for preserving Virtual Networks and SGTs.

IP-Based Transit

With IP-based transit, each Layer 3 Virtual Network establishes per-VN eBGP peering to the external routing domain. Alternatively, LISP Extranet Provider VN eBGP peering can be used. The key consideration is that SGT propagation outside of the fabric requires suitable hardware and software that supports inline tagging.

! eBGP peering per Virtual Network
router bgp 64800
 address-family ipv4 vrf Users
  neighbor 172.16.1.1 remote-as 65000
 address-family ipv4 vrf IoT
  neighbor 172.16.2.1 remote-as 65000

For IP-based transit, SGTs can be maintained using either manual inline SGT tagging between the border nodes and WAN routers, or SXP connections.

SD-Access Transit

SD-Access transit uses LISP/VXLAN encapsulation between fabric sites. This is the richest option because it natively preserves both Layer 3 Virtual Networks and SGTs. It is also capable of serving as a fabric transit between external routing domains.

SD-WAN Transit

Cisco SD-WAN provides transit between fabric sites with the capability to preserve Layer 3 Virtual Networks and SGTs. A dedicated SD-WAN Edge is used for design flexibility. SD-WAN plays a critical role in supporting inline SGT propagation over the WAN, which helps eliminate the need for SXP at remote sites.

The recommended deployment approach is:

Roll out inline tagging between SDA Border Nodes and SD-WAN routers for SGT transportation across sites
Decommission SXP at remote SDA sites to address TCAM exhaustion
Leverage SD-WAN at remote sites for native SGT support and enhanced automation
Use static SGT tagging to account for unknown traffic
Within the SDA fabric itself, VXLAN natively carries SGTs -- no inline tagging configuration needed

Firewall Integration with Network Segmentation in SD-Access

Firewalls serve as the stateful enforcement layer in a segmented network. While SGT-based contracts (SGACLs) provide stateless permit/deny decisions within the fabric, firewalls add advanced capabilities that SGACLs cannot provide.

Why Firewalls Are Essential

Contract-based segmentation within the fabric provides:

Out-of-the-box functionality managed by NetOps
Stateless enforcement with limited logging
Intra-VN enforcement between SGT groups

Firewall enforcement adds:

Advanced firewall and IPS capabilities
TLS decryption for encrypted traffic inspection
Malware analysis and retrospection
Attribute-based policy with dynamic objects and identity
Extensive logging, correlation, and threat intelligence
Inter-VN enforcement (traffic between Virtual Networks)

Pro Tip: Flows may be subjected to enforcement by both SGACLs and the firewall at the same time. SGACLs handle East/West intra-VN traffic, while the firewall handles inter-VN and North/South traffic.

Firewall Deployment Modes

There are several options for how the firewall connects to the SDA fabric:

VN to Global Routing Table (GRT) Mapping: All VN routing tables merge into the firewall's global routing table. A single security policy governs inter-VN and egress traffic.

VN to VRF Mapping: Each VN is mapped to a separate VRF on the firewall, providing routing separation. The firewall leaks routes between VNs, shared services, and external networks. VRF-aware rules enable common firewall policy across VRFs.

! BGP configuration for VRF-based VN separation
router bgp 64800
 address-family ipv4 vrf B
  neighbor 172.16.1.1 remote-as 65000
  neighbor 172.16.1.1 allowas-in
 exit-address-family

Pro Tip: The firewall does not support BGP AS-override. When leaking routes between VNs sharing the same AS number, use neighbor allowas-in on the border switches to prevent BGP from rejecting routes that contain the local AS in the AS path.

VN to Instance Mapping: On Firepower 3100/4100/4200/9300 platforms, multiple logical firewall instances can be instantiated on a single appliance, with physical and logical separation at the Supervisor level. This provides full multi-tenancy where each instance can be managed by a different entity.

SGT Propagation to Firewalls

Firewalls learn SGT information through two methods:

Inline SGT (Data Plane): The firewall reads the CMD header containing the SGT from incoming traffic. Inline SGTs are applicable for source criteria only. This method does not consume the firewall's identity memory.
Control Plane (pxGrid/SXP): ISE shares IP-to-SGT mappings with the Firewall Management Center (FMC) via pxGrid. SXP can also be used, with mappings remaining in the FMC and firewall until explicitly deleted by an ISE update.

When both methods are active concurrently, both SXP and Session topic mappings are installed and handled independently.

Firewall IP-SGT Mapping Capacity

The number of IP-to-SGT mappings a firewall can support varies by platform:

FTD Model	Maximum Recommended IP-SGT Mappings
FTDv	64,000
Firepower 1000, 1100, 2110, 2120, 2130, 3105, 3110, 3120	64,000
Firepower 2140, 3130, 3140, 4112, 4115, 4125	150,000
Firepower 4145, 4215, 9300	300,000
Firepower 4225, 4245	315,000

The Management Center itself does not have hard limits on the number of IP-SGT or user mappings (limits apply to AD/LDAP/Entra ID realm user counts). Device-level mapping filters on the FMC can be used to filter out remote endpoint bindings that are not needed in a specific firewall's policy.

MTU Considerations for Inline Tagging

When inline SGT tagging is active, the CMD header adds 8 bytes to each frame. This impacts MTU calculations:

Firepower 4100/9300: L3 MTU = 9176 = L2 MTU (9206) - MAC (12B) - 802.1q (4B) - CMD (8B) - Type (2B) - FCS (4B)
Firepower 1100/2100: L3 MTU = 9186 = L2 MTU (9216) - MAC (12B) - 802.1q (4B) - CMD (8B) - Type (4B) - FCS (4B)

Adaptive Policy for Network Segmentation on Meraki Platforms

Meraki Adaptive Policy extends the segmentation architecture to Meraki-managed networks, providing consistent policy enforcement across both Catalyst and Meraki platforms using a common ISE deployment.

How Adaptive Policy Works

Meraki Adaptive Policy shares context over the data plane using inline Security Group Tags. This provides:

Organization-wide intent-based policy that is IP and topology agnostic
Consistent policy for both wired and wireless access
End-to-end SGT transport across the Meraki network

When an endpoint connects to a Meraki switch (MS) or access point (MR), ISE authenticates it and assigns an SGT. The Meraki device embeds the SGT in every packet from that endpoint:

Meraki MS Switch:
10.0.0.5 SGT=4 (Employees)
Every packet: [IP][CMD SGT=4]

Meraki Platform Capabilities

The Meraki platform supports significant scale for group-based policy:

Capability	Limit
SGTs	60
Policies	3,600
ACEs per policy	113
IP-to-SGT maps	8,000
Clients	Unlimited (limited by standard hardware endpoint scaling)

Cross-Site SGT Propagation with Meraki

Sites with Adaptive Policy enabled propagate SGTs to peer sites that also have the capability enabled. Sites without Adaptive Policy can still communicate within the AutoVPN topology -- SGT-capable peers strip the CMD header when sending to non-capable peers. This enables a phased rollout where sites can be gradually enabled for Adaptive Policy without disrupting existing connectivity.

ISE and Meraki Integration

ISE works with Meraki platforms including MS switches, MR wireless access points, and MX security appliances. Group policy on MS and MR supports:

Filter-ID: Maps to Dashboard group policy
Per-session 802.1X inbound ACL enforcement
Named ACL orchestration
On-the-fly ACL update: ACL changes apply without requiring RADIUS Change of Authorization (CoA)

Designing an End-to-End Network Segmentation Architecture

Bringing all these components together requires careful planning across classification, propagation, and enforcement at every point in the network.

Use-Case-Driven Design

A thorough segmentation design must document all possible traffic flows:

Intra-Site: VN A to VN A, VN A to VN B, VN A/B to DC, VN A/B to Internet, DC to VN A/B
Inter-Site: VN A Site 1 to VN A Site 2, VN A Site 1 to VN B Site 2, cross-site DC access
Site-to-Branch: VN A in Site to VN A in Branch, DC to branch VN A/B
Branch-to-Site: VN A in Branch to VN A in Site, branch to DC, branch to internet
Intra-Branch: VN A to VN A within a branch, VN A to VN B within a branch
Branch-to-Branch: VN A in Branch 1 to VN A in Branch 2, cross-branch inter-VN

Pro Tip: For each use case, consider enforcement in both directions. Traffic initiated from a remote site to the campus is a separate use case from campus-to-remote-site traffic. Always remember to account for return traffic and plan for the enforcement point's IP-SGT capacity for each use case.

Enforcement Strategies

Different enforcement strategies apply depending on the traffic flow:

Inline Tagging with Fusion Firewall (Inter-VN):

Scalable inter-VN policies using source SGT criteria only
pxGrid integration not mandatory
SGT information provided inline -- no identity memory utilization on the firewall
Endpoint count unbounded by firewall capacity

Attribute-Based Policy with Control Plane Propagation (Inter-VN):

Flexible attribute-based inter-VN policy
Identity attributes applicable in any direction
Policy based on any combination of source/destination SGTs, user groups, and dynamic attributes
Device-level mapping filters to manage capacity

DC/Cloud Access with Mixed Propagation:

Extremely scalable attribute-based policy for user-to-DC/cloud traffic
User identity provided inline with minimal firewall identity memory utilization
Integration with CSDAC (Cisco Secure Dynamic Attributes Connector) for cloud workload attributes

Scalable Branch-to-Branch Design:

Security policy enforced in the destination site
Firewalls learn bindings of endpoints in their local sites only
Non-local bindings filtered out with mapping filters
Remote bindings provided inline -- SGT propagation over WAN/IPSec required

Key Design Recommendations

Based on real-world large-scale deployments, these design recommendations emerge:

Deploy inline tagging between SDA Border Nodes and SD-WAN routers to transport SGTs across sites
Decommission SXP at remote sites to prevent TCAM exhaustion
Use Cisco Secure Firewall (FTD) for North/South enforcement -- it supports policy options mixing SGTs, IPs, URLs, ports, protocols, and applications
Use Catalyst 9500s in the data center to tag unknown traffic from North to South using IP-to-SGT mappings from ISE via SXP
Set default deny in the ISE policy matrix to improve security, scalability, and simplify onboarding of new SGTs
Leverage Active Directory attributes for dynamic SGT assignment to scale user classification
Deploy fabric-enabled wireless at remote sites for wired and wireless TrustSec support
Use Cisco Secure Network Analytics (SNA) for TrustSec flow reports to audit the efficacy of segmentation policies and respond to policy violations

Validation and Visibility

No segmentation architecture is complete without visibility and validation. Cisco Secure Network Analytics provides TrustSec reports that enable you to audit the efficacy of your segmentation design. This gives you the ability to see which SGT-to-SGT flows are occurring, whether policies are being enforced correctly, and where policy violations are happening -- providing critical East/West visibility that traditional monitoring tools cannot deliver.

Frequently Asked Questions

What is the difference between macro segmentation and micro segmentation?

Macro segmentation uses Virtual Networks (VNs), which correspond to VRFs and LISP Instance IDs, to provide complete isolation between groups of endpoints. No communication is possible between VNs by default. Micro segmentation uses Security Group Tags (SGTs) within a Virtual Network to enforce granular, role-based access control using permit/deny contracts (SGACLs). Most deployments use both: VNs for broad isolation (e.g., separating Users from IoT) and SGTs for fine-grained control within each VN.

How does SXP differ from inline SGT tagging?

SXP (SGT Exchange Protocol) shares IP-to-SGT mapping information over a control-plane protocol. The actual data packets do not carry the SGT, so the enforcement device must look up each source IP in its mapping table. Inline tagging embeds the SGT directly in the data frame using the Cisco Meta Data (CMD) header, so every packet self-identifies its security classification. Inline tagging scales better because it does not consume TCAM resources for IP-to-SGT lookups and is not limited by the number of SXP connections ISE can support.

Can third-party firewalls be used for SGT-based enforcement?

Third-party firewalls have limited to no TrustSec feature support, making them unsuitable for SGT-based enforcement in a TrustSec architecture. Key requirements for a firewall in this role include native SGT support, SXP and inline tagging capabilities, the ability to build access control policies using a mix of SGTs and traditional firewall constructs, and pxGrid integration with ISE. Cisco Secure Firewall (FTD) platforms meet all of these requirements.

What is the maximum number of SGTs supported?

The TrustSec architecture supports up to 4,000 SGTs. In practice, organizations must plan their SGT allocation strategy with this limit in mind, understanding that the need to scale should be balanced against the number of unique security roles required. On Meraki platforms specifically, the limit is 60 SGTs with up to 3,600 policies and 113 ACEs per policy.

How do I handle traffic from unknown or unclassified endpoints?

Static SGT tagging should be used to account for unknown traffic. For example, Catalyst 9500s in the data center can tag traffic coming from unclassified sources based on IP-to-SGT mappings pulled from ISE using SXP. Setting a default deny policy in the ISE TrustSec matrix ensures that any unclassified traffic is blocked until an explicit policy is created, improving security posture while simplifying the onboarding of new SGTs.

What should I consider before enabling enforcement in the TrustSec matrix?

Before enabling enforcement, you must carefully plan to avoid immediately denying legitimate traffic across the network. A crawl-walk-run approach is recommended: start with monitor mode to observe traffic flows and SGT assignments, validate policies using Cisco Secure Network Analytics TrustSec reports, and only enable enforcement once you have confirmed that all legitimate flows have corresponding permit policies. Considerations include TCAM capacity during transition, validating that all resources and hops are SGT-aware and can propagate tags, and ensuring that infrastructure devices have appropriate static SGT assignments.

Conclusion

Network segmentation using TrustSec, Security Group Tags, and micro-segmentation represents a fundamental shift from topology-dependent IP-based ACLs to identity-driven, software-defined security policy. By combining macro segmentation through Virtual Networks with micro segmentation through SGTs, organizations can achieve granular, scalable access control that follows endpoints regardless of where they connect.

The key takeaways from this guide are:

SGTs provide identity-based, topology-independent segmentation that scales across campus, branch, data center, and cloud environments
Inline tagging is the preferred propagation method, offering better scalability than SXP by eliminating TCAM exhaustion concerns
SD-Access natively supports SGT propagation in the VXLAN header, while SD-WAN extends SGT transport across the WAN
Firewalls complement SGACLs by providing stateful, attribute-based enforcement for inter-VN and North/South traffic
ISE serves as the single source of truth for identity, policy, and SGT assignment across all network domains
Meraki Adaptive Policy extends consistent segmentation to Meraki-managed networks using the same ISE infrastructure
Visibility through Cisco Secure Network Analytics is essential for validating and auditing segmentation effectiveness

Building a comprehensive segmentation architecture requires careful planning across all traffic flows, thorough hardware capability assessment, and a phased rollout approach. Start by defining your Virtual Networks and SGT taxonomy, deploy ISE as your centralized policy engine, enable inline tagging between sites, and layer in firewall enforcement for inter-VN and external traffic. With the right design, software-defined segmentation can transform your network security posture from a flat, vulnerable topology into a resilient, identity-aware infrastructure.

Explore the CCNP Enterprise and security courses available on NHPREP to deepen your hands-on skills with TrustSec, SD-Access, and network segmentation technologies.