[ Glossary ]

Network Access Control List (ACL)

A network access control list (ACL) is a user-ordered set of rules that permits or denies traffic based on criteria like source and destination IP address, port, or protocol. Routers, firewalls, and cloud platforms use ACLs to control which traffic can enter, leave, or move through a network segment.

What Is a Network Access Control List (ACL)?

Key takeaways

An ACL is made up of individual entries, often called access control entries (ACEs), each one matching specific traffic and applying an allow or deny action.
ACLs are evaluated in order, so rule sequence directly affects which traffic gets matched and how the device behaves.
ACLs exist on routers, firewalls, and cloud network controls like AWS network ACLs and Azure network security groups (NSGs).
A single ACL is a narrow, fast traffic filter, not a full picture of enterprise-wide access or risk.

A network access control list (ACL) is one of the oldest and most widely used tools in network security. It is a set of rules, configured on a router, firewall, switch, or cloud platform, that decides whether to allow or deny traffic based on fields like source IP address, destination IP address, port number, or protocol. Think of an ACL as a gatekeeper: it checks each packet against its list of rules, in order, and applies the first matching action.

Why Network ACLs Matter

Every network device that forwards traffic needs a way to decide what is allowed through and what is not. Without ACLs, networks would have no consistent way to restrict traffic between segments, block unwanted connections, or limit which systems can talk to which. ACLs give network and security teams a direct, granular way to control traffic flow at the device or interface level. They are foundational to segmentation, perimeter defense, and basic compliance requirements that call for documented, restrictive access.

How Network ACLs Work

An ACL is built from individual access control entries (ACEs). Each ACE specifies matching criteria, such as a source address range, a destination port, or a protocol, along with an action: permit or deny. When a device receives a packet, it checks the packet against the ACL's entries in sequence, from top to bottom. The first entry that matches determines the outcome. If no entry matches, most devices apply an implicit deny, blocking the traffic by default.

This ordering matters. A broad rule placed above a more specific one can prevent the specific rule from ever being evaluated, a common cause of misconfiguration. ACLs can operate at different layers: Layer 2 ACLs filter by MAC address, while Layer 3 and Layer 4 ACLs filter by IP address, port, and protocol, which is the most common use case in enterprise and cloud networks.

Key Components and Best Practices

A typical ACL includes:

An identifier, either a name or number, used to reference the list on the device.
Access control entries (ACEs), each with matching criteria and a permit or deny action.
Rule order, since devices process entries sequentially and stop at the first match.
An implicit deny, the default behavior when no rule matches.

Good ACL practice includes writing specific rules before broad ones, documenting the business purpose of each entry, removing rules that are no longer needed, and reviewing the list regularly as applications and infrastructure change. In cloud environments, this looks like network ACLs on a virtual private cloud (VPC) subnet or a network security group (NSG) attached to a virtual network, both of which apply the same permit-or-deny logic to cloud traffic.

Common Challenges

ACLs are simple in concept but difficult to manage at scale. A handful of rules on one router is manageable by hand. Thousands of rules spread across routers, firewalls, and cloud security groups, maintained by different teams over years, is not. Common problems include:

Rule sprawl: entries added for a one-time need that are never removed.
Shadowed rules: an earlier, broader entry that prevents a later, more specific one from ever being evaluated.
Lost context: no record of why a rule exists, who owns it, or whether it is still needed.
Inconsistent standards: different syntax and rule logic across vendors and platforms, making it hard to compare access or enforce a consistent policy.

These issues do not show up until something breaks, an audit asks for evidence, or an incident response team needs to understand what access actually existed at the time of a breach.

How This Connects to Network Security Policy Management and FireMon

A network ACL is a building block, one rule list on one device. Network security policy management (NSPM) is the discipline of governing those rule lists consistently across every router, firewall, cloud security group, and segmentation control in an environment, rather than reviewing each one in isolation.

FireMon, the founder of NSPM, gives teams a normalized view of ACLs and firewall rules across on-premises, virtual, and cloud environments, including AWS network ACLs and Azure NSGs. Instead of reviewing access list syntax device by device, teams can see rule usage, redundant or shadowed entries, and overly permissive access in one place, validate proposed changes before deployment, and maintain documentation that supports audit and compliance reviews. FireMon does not replace the routers, firewalls, or cloud controls that enforce ACLs; it governs the policy behind them.

Frequently Asked Questions

A network ACL is a specific rule list that permits or denies traffic based on matching criteria, while a firewall is a device or service that can apply ACLs along with other inspection capabilities, like stateful tracking or deep packet inspection. Many firewalls use ACL-style rules internally, but a firewall is generally a more comprehensive security control than a standalone ACL.

A standard ACL filters traffic based on source IP address only, which makes it simple but limited. An extended ACL can match on source and destination IP address, port number, and protocol, giving administrators far more granular control over what traffic is permitted or denied.

No. An ACL is a fast, rule-based filter that works at the network and transport layers; it does not inspect application-layer content, detect malware, or analyze encrypted traffic. It is one layer of defense, typically paired with firewalls, intrusion prevention systems, and other controls for deeper inspection.

Networks change constantly as applications, teams, and infrastructure evolve, but ACL entries often remain in place long after the access they permit is still needed. Regular review helps identify unused, redundant, or overly permissive rules before they turn into unnecessary exposure or compliance gaps.

They are related but not identical. Cloud security groups, like AWS security groups, are typically stateful and apply at the instance level, while network ACLs, like AWS network ACLs, are usually stateless and apply at the subnet level; both use permit-or-deny logic similar to traditional network ACLs.