What Is SGACL in Networking?
Also known as: SGACL, Security Group Access Control List, Cisco TrustSec, SGT, CCNP ENCOR SGACL
On This Page
Quick Definition
SGACL is a way to control traffic in a network by grouping devices into security groups and applying rules based on those groups. Instead of writing complex rules for each individual IP address, you assign devices to groups like HR or Finance and then decide what traffic is allowed between those groups. This makes network security policies easier to manage and more flexible when devices change or move.
Must Know for Exams
SGACL is a topic that appears frequently in the Cisco CCNP Security and CCNP Enterprise certification exams, specifically the ENCOR (350-401) and SCOR (350-701) exams. In the ENCOR exam, it is part of the 'Network Assurance' and 'Security' domains. Candidates must understand how TrustSec works, what an SGT is, how SGACL differs from traditional ACLs, and how to interpret policies. The exam may ask you to match SGTs to policies or to identify the correct rule order for a given scenario.
In the SCOR exam, SGACL is covered in more depth, including integration with Cisco ISE, SXP, and 802.1X. You may be asked to troubleshoot why a certain SGACL rule is not working, or to configure a basic policy. The exam objectives explicitly mention 'Security Group Access Control Lists' and 'TrustSec' as key technologies. You need to know the difference between SGT tagging methods (inline tagging vs. SXP) and how SGACL interacts with other security features like MACsec or VLAN ACLs.
Exam questions often present a scenario where a network administrator needs to restrict access between two departments. They will ask which technology is best suited, and the answer is often SGACL because it is identity-based rather than IP-based. Another common question type involves debugging: a user reports they cannot access a server, and you must determine if the problem is an SGACL rule or something else. Understanding the default deny behavior of SGACL is critical here. You might also see questions about the order of rules: like ACLs, SGACL rules are processed top-down, and the first match is applied.
To do well on these questions, you should memorize the key components of TrustSec: the role of ISE as the policy decision point, the switch as the policy enforcement point, the use of RADIUS for SGT assignment, and the use of SXP for propagating SGTs to switches that do not have inline tagging. You should also be comfortable with the concept of dynamic SGT assignments based on user authentication.
Simple Meaning
Imagine you work in a large office building with many different departments. Each department has its own color-coded badge. For example, everyone in Human Resources wears a blue badge, everyone in Finance wears a green badge, and everyone in IT wears a red badge. Now, suppose the building manager wants to make sure that only certain departments can enter specific areas. Instead of making a list of every single person’s name and checking it at every door, the manager simply puts a rule that says only blue badges can enter the HR filing room, only green badges can enter the finance vault, and red badges can access the server room. This is much easier to manage because if someone moves from HR to Finance, you just change their badge color rather than updating a long list of names on every door.
In computer networking, SGACL works the same way. Instead of writing long lists of IP addresses and port numbers for firewall rules, you put devices into security groups. A security group is like a badge color. For example, you might put all employee laptops in a group called Employees and all servers in a group called Servers. Then you write SGACL rules that say traffic from Employees to Servers is allowed on certain ports. If a new laptop is added, you just put it in the Employees group and the rules apply automatically. This is a huge time saver for network administrators, especially in large networks where devices are constantly being added, removed, or moved.
The real power of SGACL comes from Cisco TrustSec, which is the overall framework that uses security group tags (SGTs) to identify which group a device belongs to. Every packet leaving a device is tagged with an SGT that represents its group. The network switches then look at the tag and apply the SGACL rules. This is far more scalable than traditional access control lists (ACLs) because you can have thousands of devices but only a few dozen groups and rules.
Full Technical Definition
SGACL is a policy enforcement mechanism within the Cisco TrustSec architecture. Cisco TrustSec uses Security Group Tags (SGTs) to classify traffic based on the identity of the source and destination devices rather than their IP addresses. An SGT is a 16-bit value that is assigned to a device based on its role, location, or user identity. When a device sends a packet, the network infrastructure adds the source SGT to the packet. The destination device also has an SGT. The SGACL policy defines what traffic is allowed or denied between specific source and destination SGT pairs.
The process begins with authentication. When a user or device connects to the network, it authenticates via 802.1X, MAB (MAC Authentication Bypass), or web authentication. The Cisco Identity Services Engine (ISE) then assigns an SGT to that device based on policies defined by the administrator. This SGT is communicated to the network switch using protocols like RADIUS (with SGT attributes) or SXP (SGT Exchange Protocol). Once the device is tagged, the switch maintains a local SGACL table that maps source SGT to destination SGT and specifies the allowed actions (permit or deny) for various traffic types.
When a packet arrives at a switch, the switch looks up the source SGT (which was added by the ingress switch or carried in the packet) and the destination SGT (based on the destination IP address learned via SGT binding). It then checks the SGACL policy. The policy can be based on Layer 2, Layer 3, and Layer 4 information, including protocol type, source and destination ports, and even application-level criteria. If the policy allows the traffic, the switch forwards the packet. If not, it drops it. This is different from traditional ACLs because the rule is based on group membership, not IP addresses. Changing an IP address does not change the security policy if the device remains in the same group.
SGACL policies can be downloaded to switches from Cisco ISE using the RADIUS Change of Authorization (CoA) mechanism or through SXP. The policies are stored in a format that includes the source SGT, destination SGT, and a list of rules. Each rule has a priority, an action (permit or deny), and optional match criteria like IP protocol, ports, or DSCP values. The switch performs the match against the first rule that applies. If no rule matches, the default action is usually deny. SGACL can also be used in software-defined access (SD-Access) fabrics, where it integrates with LISP and VXLAN to provide end-to-end segmentation.
Real-Life Example
Think of a large university library. The library has several sections: the general reading room, the reference section, the rare books archive, and the computer lab. Each student, faculty member, and staff member gets a library card with a colored sticker. Undergraduate students have a yellow sticker, graduate students have a blue sticker, faculty have a red sticker, and staff have a green sticker. The library sets up doors that read the sticker color and decide if the person can enter.
The rare books archive has a rule that only red stickers (faculty) can enter. The computer lab allows yellow, blue, and red stickers but not green stickers. The reference section is open to everyone. Now, if a graduate student finishes their degree and becomes a faculty member, the library simply changes the sticker on their card from blue to red. The rules remain the same, and the person now has access to the rare books archive automatically. The library does not need to update a list of who is who at every door.
In networking, SGACL works exactly like this. The library card is the device’s identity. The sticker color is the SGT. The doors are the network switches. The rules on the doors are the SGACL policies. If a user moves from one department to another, the administrator changes the SGT assignment in ISE, and all switches automatically apply the new policies. This is far more efficient than rewriting ACLs on every switch. Also, if a new student enrolls, they get a yellow sticker and immediate access to the computer lab and reference section without any manual door changes.
Why This Term Matters
SGACL matters because it solves a fundamental problem in network security: scalability. In traditional networks, security policies are built around IP addresses. If a server moves or a user roams to a different subnet, the administrator must update every ACL that references the old IP address. This is error-prone and time-consuming, especially in large enterprises with thousands of devices. SGACL shifts the focus from 'where is the device' to 'what is the device' based on its group membership. This makes policies persistent even when the network topology changes.
For network administrators, SGACL simplifies policy management. Instead of managing hundreds of ACL entries on dozens of switches, you define a few group policies in a central policy server like Cisco ISE. The switches automatically receive the policies and enforce them. This reduces configuration errors and ensures consistent security across the network. When a new device is added, it is assigned to the correct group and inherits the appropriate policies without manual intervention.
From a security perspective, SGACL enables micro-segmentation. You can create very fine-grained policies between groups. For example, you can allow the HR group to access the payroll server only on port 443, while the finance group can access it on port 22 (SSH) and port 443. This is much more secure than allowing an entire subnet to access a server. Additionally, because the policy follows the device based on its identity, users who connect from different locations still get the same access rights, which is critical for mobile workforces.
In cloud and hybrid environments, SGACL can be extended to virtual switches and cloud routers, providing consistent policy enforcement regardless of where the workload runs. This is especially important for enterprises adopting SD-Access or software-defined networking (SDN), where mobility and automation are key. Overall, SGACL is a cornerstone of modern network segmentation and zero-trust architectures.
How It Appears in Exam Questions
In certification exams, SGACL appears in several question formats. One common format is the multiple-choice scenario. For example, a question might describe a company with a guest wireless network and an internal corporate network. The administrator wants to allow guest users to access only the internet, not internal servers. The correct answer might be to assign the guest network to an SGT for guests and then apply an SGACL that denies traffic from guest SGT to internal server SGTs. Another question might ask which protocol is used to communicate SGT information between switches, with answer choices including SXP, OSPF, BGP, or CDP. The correct answer is SXP.
Another type of question is the drag-and-drop or ordering question. The exam may show a list of steps for configuring SGACL and ask you to put them in the correct order: first, define SGTs in ISE; second, assign SGTs to devices via authentication; third, configure SGACL rules in ISE; fourth, download policies to switches; fifth, enforce the policies. You must understand the logical flow from policy definition to enforcement.
Troubleshooting questions are also common. The question may provide show command output from a switch, such as 'show cts role-based permissions' or 'show cts sgt-map'. You might see that a certain traffic flow is denied, and you need to identify why. For example, if the source SGT is not listed in the policy, the traffic will be denied by default. Or if the destination SGT is unknown, the switch cannot enforce the policy. These questions test your ability to read command output and apply logic.
Finally, there are configuration questions where you have to complete a command. For instance, you might be asked to configure an SGACL on a switch interface using the 'cts manual' or 'cts role-based' commands. You may need to know the syntax for defining a policy map and applying it to an SGT pair. Understanding the difference between 'cts role-based enforcement' and 'cts manual' is also tested. Manual mode requires configuring SGTs statically on the interface, while automatic mode uses ISE for dynamic assignment.
Study encor
Test your understanding with exam-style practice questions.
Example Scenario
A medium-sized company, BlueSky Inc., has a network with two main departments: Engineering and Sales. The Engineering department has a server that contains design files, and the Sales department has a server with customer data. The company wants to allow all employees to access the internet, but they want to ensure that Engineering employees cannot access the Sales server, and vice versa. They also want to allow both departments to access a shared printer.
The network administrator decides to use Cisco TrustSec with SGACL. They create three security groups in Cisco ISE: Engineering, Sales, and Shared. They configure 802.1X authentication on the network switches. When an Engineering employee plugs in their laptop, it authenticates and receives the Engineering SGT. The same happens for Sales employees. The shared printer is placed in the Shared SGT. The administrator then creates SGACL policies: from Engineering to Sales is denied, from Sales to Engineering is denied, from Engineering to Shared is permitted, from Sales to Shared is permitted, and from any group to the internet is permitted. The policies are downloaded to the switches. Now, even if an Engineering employee moves to a different subnet, they still get the Engineering SGT and the policies still apply. The network is secure without complex IP-based ACLs.
Common Mistakes
Thinking SGACL is the same as a traditional ACL based on IP addresses.
Traditional ACLs filter traffic based on source and destination IP addresses. SGACL uses security group tags (SGTs), which are identity-based and not tied to IP addresses. If a device’s IP changes, the SGACL policy still applies as long as the SGT stays the same.
Remember that SGACL works at the group level, not the IP level. Think of it as rules between groups, not between individual host IPs.
Assuming that SGACL rules are processed in a first-match-permit default, similar to standard ACLs.
SGACL policies have an implicit deny at the end, just like traditional ACLs. However, the default action can be changed in some configurations, but in most Cisco implementations, if no rule matches, the traffic is denied. Learners sometimes forget this and assume traffic will be allowed by default.
Always include explicit permit rules for all allowed traffic. If you want to allow traffic between two groups, you must define a permit rule. Otherwise, it will be denied.
Confusing SGT (Security Group Tag) with SGACL (Security Group Access Control List).
SGT is the tag attached to a device or packet to indicate its group membership. SGACL is the actual policy rule that determines what traffic is allowed between different SGTs. They are related but distinct concepts. Mixing them up can lead to incorrect answers in exam questions about which component does what.
Think of SGT as the badge (the label) and SGACL as the door rule (what the badge allows). You need both to enforce security.
Believing SGACL can only be used with Cisco ISE and 802.1X authentication.
While Cisco ISE is the most common policy server, SGACL can also be configured manually using static SGT assignments on the switch interface (cts manual mode). This does not require authentication or ISE. Also, SXP can propagate SGTs without full 802.1X. So SGACL is flexible and works in various deployment models.
Know that SGACL can be deployed in manual mode (static) or automatic mode (with ISE and 802.1X). Both are valid and tested in exams.
Assuming that SGACL policies apply to all traffic passing through a switch, including traffic that does not have an SGT.
If a device does not have an SGT (e.g., it is unauthenticated or the port is configured without TrustSec), the switch will have an unknown SGT for that device. By default, traffic with unknown SGTs may be dropped or treated based on a default policy. Not all traffic on a switch is subject to SGACL; only traffic that has been classified with an SGT or where the switch has a policy for that SGT pair.
Make sure you understand that SGACL only applies to traffic where both the source and destination SGT are known. For unknown traffic, other mechanisms like port ACLs (PACLs) or VLAN ACLs (VACLs) may still be used.
Exam Trap — Don't Get Fooled
The exam presents a scenario where a user is assigned to the wrong SGT due to a misconfiguration, but the problem appears to be a network connectivity issue. The candidate may focus on troubleshooting IP connectivity, routing, or VLANs instead of checking the SGT assignment and SGACL policies. Always keep in mind that in a TrustSec environment, the first thing to check when a user cannot access a resource is the SGT assignment and the SGACL policies.
Use commands like 'show cts role-based permissions' on the switch to see the active policies for the source and destination SGT. Verify that the user's device is in the correct SGT group. If the policy shows a deny for that SGT pair, that is the root cause.
Do not assume the problem is a network layer issue until you have ruled out the security policy.
Commonly Confused With
A traditional ACL filters traffic based on IP addresses, port numbers, and protocols. SGACL filters traffic based on security group tags (SGTs), which are identity-based and not tied to IP addresses. Traditional ACLs require updates when IP addresses change, while SGACL policies remain valid as long as the device stays in the same group.
If a server's IP address changes from 192.168.1.10 to 192.168.2.20, a traditional ACL must be updated everywhere that references 192.168.1.10. With SGACL, the server's SGT stays the same, so the policy does not need any changes.
VACL is a Cisco feature that filters traffic within a VLAN based on MAC addresses or IP addresses. SGACL is based on SGTs and works across VLANs and even across different network segments. VACL is static and tied to a specific VLAN, while SGACL can follow a user who moves to a different VLAN because the SGT is assigned dynamically.
If a user moves from VLAN 10 to VLAN 20, a VACL that only applies to VLAN 10 would no longer protect the user. With SGACL, the user's SGT remains the same, and the policy still applies regardless of the VLAN.
Cisco TrustSec is the overall security framework that includes SGTs, SGACL, and the policy server (ISE). SGACL is just one component of TrustSec, which specifically handles the access control rules. TrustSec also includes encryption (MACsec) and classification methods (inline tagging, SXP).
Think of TrustSec as the entire security system for a building, including the ID card system, the badge readers, the doors, and the security guards. SGACL is just the set of rules on the doors that decide who can enter based on the badge color.
802.1X is the authentication protocol that allows a user or device to prove its identity before accessing the network. SGACL uses the information from 802.1X (or other methods) to assign an SGT, but SGACL itself is not authentication. 802.1X is about 'who are you?', while SGACL is about 'what are you allowed to access?'.
A user authenticates via 802.1X with their username and password. After authentication, the switch knows the user is from the HR department and assigns the HR SGT. Then SGACL allows that user to access the HR server. If 802.1X fails, the user gets no SGT and is denied by SGACL.
Step-by-Step Breakdown
Classify Devices into Security Groups
The administrator defines security groups in Cisco ISE based on device roles, user roles, or location. For example, groups can be Employees, Guests, Servers, or specific departments like HR and Engineering. Each group is assigned a unique Security Group Tag (SGT), which is a 16-bit number.
Assign SGTs to Devices via Authentication
When a device connects to the network, it authenticates using 802.1X, MAB, or web authentication. ISE maps the authenticated identity to a security group and sends the SGT to the switch via RADIUS. The switch stores this SGT as the source SGT for traffic coming from that port.
Build SGT-to-IP Bindings
The switch learns the IP address of the authenticated device and creates a binding between the IP and the SGT. This binding is used to determine the destination SGT when traffic is sent to that IP. These bindings can be learned dynamically via SXP or by snooping DHCP/ARP.
Define SGACL Policies in ISE
The administrator creates SGACL rules in ISE that specify which traffic is allowed or denied between source and destination SGT pairs. Each rule can include conditions like protocol, source/destination ports, and even application types. The rules are ordered, and the first match is applied.
Distribute SGACL Policies to Switches
ISE downloads the SGACL policies to the switches using RADIUS CoA (Change of Authorization) messages or via SXP protocol. The switches store the policies locally in a table that maps source SGT, destination SGT, and the associated rule list.
Enforce SGACL on Ingress Traffic
When a packet arrives at a switch interface, the switch identifies the source SGT (from the port or from an inline tag in the packet) and looks up the destination SGT based on the destination IP address. It then checks the SGACL policy for that SGT pair. If the policy permits the traffic, the packet is forwarded. If it denies, the packet is dropped.
Monitor and Troubleshoot Policies
The administrator uses show commands like 'show cts role-based permissions' to verify active policies and 'show cts sgt-map' to check SGT bindings. Logs and syslog messages help identify denied traffic. Policies can be updated dynamically by ISE without manual switch configuration.
Practical Mini-Lesson
SGACL is a powerful tool for network segmentation, but implementing it correctly requires careful planning. First, you must decide which devices or users will be placed into which security groups. A common best practice is to start with broad groups like Employees, Guests, and Servers, and then add more specific groups later as needed. Overly granular groups can become unmanageable, so aim for a balance between security and simplicity.
Next, ensure that your network infrastructure supports Cisco TrustSec. Most modern Cisco Catalyst switches and routers support SGACL, but older models may require a software upgrade. You also need a policy server like Cisco ISE, which can be a physical appliance or a virtual machine. In a smaller network, you can use manual mode on the switch, where you statically assign SGTs to interfaces. This is simpler but less scalable.
Configuration involves several steps. On the switch, you must enable TrustSec globally with the 'cts' command. For dynamic SGT assignment, you configure 802.1X on the interfaces and point the switch to ISE as the RADIUS server. On ISE, you create authorization profiles that include the SGT value. Then you create SGACL rules under Policy > Security Group Access. The rules are written in a specific format: 'Source SGT > Destination SGT > Action > Conditions'. For example, a rule might say 'Employees > Payroll-Server > Permit > TCP port 443'.
A common challenge in practice is troubleshooting when a user cannot access a resource. The first step is to check the user’s SGT using 'show cts interface' on the switch. Then check the destination SGT by looking at the IP address of the target server. If the destination IP is not in the SGT map, the switch treats it as unknown SGT, and the default policy is deny. You can add a static binding for that server using the 'cts sgt-map' command. Also, ensure that the SGACL policy includes a permit rule for the SGT pair. Often, the problem is a missing rule or a rule that is ordered incorrectly.
Another practical tip: SGACL can coexist with traditional ACLs. You can apply a port ACL (PACL) or VLAN ACL (VACL) as a first line of filtering, and then SGACL as a second line. However, this can make troubleshooting complex. It is better to choose one method per traffic flow. In modern networks, SGACL is preferred because of its dynamic nature and central management. For exam purposes, remember that SGACL is part of the broader zero-trust architecture, where no device is trusted by default, and every access request is verified based on identity and policy.
Memory Tip
Think of SGACL as 'Security Group Access Control List' and remember the key difference from traditional ACLs: ‘Group over IP’ — it is about the badge, not the address.
Covered in These Exams
Related Glossary Terms
802.1X is a network access control standard that authenticates devices before they are allowed to connect to a wired or wireless network.
802.1Q is the networking standard that allows multiple virtual LANs (VLANs) to share a single physical network link by tagging Ethernet frames with VLAN identification information.
Two-factor authentication (2FA) is a security method that requires two different types of proof before granting access to an account or system.
Frequently Asked Questions
What is the difference between SGACL and a firewall ACL?
A firewall ACL typically filters traffic based on IP addresses, ports, and protocols at the network perimeter. SGACL is used inside the network on switches and routers to filter traffic based on security group membership, which is identity-based. Firewalls are often stateless or stateful, while SGACL is generally stateless but can be combined with stateful firewalls for deeper inspection.
Do I need Cisco ISE to use SGACL?
No, you do not absolutely need ISE. You can configure SGACL in manual mode on the switch by statically assigning SGTs to interfaces and defining policies locally. However, without ISE, you lose the dynamic assignment based on authentication and the central policy management, which is the main benefit of using TrustSec.
How does SGACL handle traffic that does not have an SGT?
Traffic from devices that have not been authenticated or do not have an SGT is treated as having an unknown SGT. By default, SGACL policies for unknown SGTs typically result in denial. However, you can define a specific SGACL rule for unknown SGTs if you want to allow certain traffic. This is useful for guest networks or legacy devices.
Can SGACL be used with wireless networks?
Yes, SGACL can be used with wireless networks. When a wireless client authenticates via 802.1X, the wireless LAN controller can assign an SGT to the client. The switch that the controller connects to then enforces SGACL policies based on that SGT. This allows consistent policy enforcement across wired and wireless networks.
What is SXP and how does it relate to SGACL?
SXP stands for SGT Exchange Protocol. It is used to propagate SGT-to-IP bindings between network devices that do not have inline tagging capabilities. For example, if a router does not support inline SGT, SXP can tell the router what SGT corresponds to a given IP address. This allows the router to enforce SGACL even without inline tags.
Does SGACL support IPv6?
Yes, Cisco TrustSec and SGACL support both IPv4 and IPv6 traffic. The SGT tagging and policy enforcement work the same way for IPv6. However, IPv6 support may require specific switch platforms and software versions. Always check the documentation for your specific hardware.
What happens if an SGACL rule is misconfigured?
If a rule is misconfigured, the default deny action may block legitimate traffic, causing connectivity issues for users. Alternatively, a misconfigured permit rule might allow unauthorized access. Using a central policy server like ISE helps audit rules before deployment. You can also use the 'show cts role-based policy' command to preview active rules on a switch.
Summary
SGACL, or Security Group Access Control List, is a Cisco technology that simplifies network security by controlling traffic based on the identity of devices rather than their IP addresses. By grouping devices into security groups and assigning them Security Group Tags, administrators can write policies that follow the device even when it moves to a different subnet or changes its IP. This is a major improvement over traditional ACLs, which are static and tied to IP addresses.
SGACL is a core component of Cisco TrustSec and is heavily featured in the CCNP ENCOR and SCOR exams. To master this topic, remember that SGACL is not just another ACL; it is a group-based policy system that integrates with authentication and central management via Cisco ISE. Understand the role of SGTs, the enforcement process on switches, and the default deny behavior.
By moving from IP-based rules to identity-based rules, you create a more scalable, secure, and manageable network that aligns with modern zero-trust principles.