An access control list (ACL) is an ordered list of rules on a network device, such as a router, switch or firewall, that says which traffic to permit and which to deny. Each rule typically matches on fields such as source and destination IP address, protocol and port. ACLs are one of the oldest and most widely used ways to restrict traffic between networks and segments, and they still sit underneath many modern firewall and cloud security controls.
Not to be confused with a physical access control system, which controls who can open doors. The term ACL is also used for file and application permissions; this entry covers the network meaning.
At a glance
- An ACL is a list of permit and deny rules, most commonly applied to traffic entering or leaving a device interface.
- Rules are usually checked top to bottom, the first match wins, and many platforms end with an implicit deny.
- Many ACLs are stateless: they look at each packet on its own, without tracking whether it belongs to an existing connection.
- ACLs are commonly used to separate network segments, protect management access and filter traffic at the edge.
- They are simple and fast, but large, undocumented rule sets become hard to audit and risky to change.
What problem it solves
Without some form of filtering, a device on one part of the network can often reach devices on other parts. Guest Wi-Fi users, cameras and building systems end up able to talk to finance servers. An attacker who compromises one device can move freely. An ACL lets the network team say, in specific terms, which traffic is allowed between two places and drop the rest.
ACLs are also used for housekeeping: limiting who can log in to a switch’s management interface, blocking known-bad address ranges at the internet edge, or deciding which routes a router accepts. Because they run on equipment most organizations already own, they are often the first control put in place when a network is split into segments.
How it works
Rules and matching. Each line in an ACL is a rule: permit or deny, plus the traffic it matches. A rule might permit TCP traffic from the voice VLAN to the call server on a specific port, or deny all traffic from the guest network to the internal address range. Depending on the platform, rules can also match on direction, protocol flags or time of day.
Order and the implicit deny. On most platforms the device reads the list from the top and acts on the first rule that matches. A rule placed too high can override everything below it. Many platforms add an invisible deny at the end, so anything not explicitly permitted is dropped. This is why a single misplaced line can cut off an application.
Where it is applied. ACLs are commonly attached to an interface in an inbound or outbound direction. Other attachment models, such as applying a list across a VLAN, to the device’s control plane or to management access, vary by platform. The same list can behave very differently depending on where and in which direction it is bound, so document each ACL’s binding and direction along with its rules.
Stateless versus stateful. A classic ACL examines each packet independently. To allow replies to an outbound connection, you write a rule for the return traffic too. A stateful network firewall tracks connections and permits replies automatically, which makes policies shorter and harder to get wrong. Some platforms offer reflexive or stateful ACL features that sit between the two.
In the cloud. Public cloud platforms provide network ACLs on subnets and security groups on resources. The rule logic is similar, though evaluation order and statefulness vary by provider.
If you want the rule base on routers, switches and firewalls designed, reviewed or run for you, our Managed Network Services page explains the options.
When it matters for buyers
- Segmenting the network. Network segmentation projects often rely on ACLs between VLANs, alongside firewalls for the more sensitive boundaries.
- Audits and compliance. Frameworks such as PCI DSS expect you to show how traffic to sensitive systems is restricted, and ACLs are frequently part of that evidence.
- Taking over a network. Inherited routers and switches may carry years of ACL entries nobody can explain. A review before changes reduces the risk of outages.
- Outsourcing network management. Change control for ACLs is a practical test of whether a managed provider documents and reviews its work.
- Moving to the cloud. Rules that lived on a data center firewall need equivalents in the cloud provider’s ACLs and security groups.
Questions to ask vendors
- Which devices in our environment carry ACLs today, and is there a current, documented copy of each list, including where it is bound and in which direction?
- Are these ACLs stateless or stateful on this platform, and how is return traffic handled?
- How are ACL changes requested, peer-reviewed, tested and rolled back?
- Do you audit for unused, shadowed or overly broad rules, and how often?
- Will you manage ACLs and firewall policy in one tool, or separately on each device?
- How are ACL hits logged, and can we see which rules are actually matching traffic?
How it differs from a network firewall
An ACL is a rule list; a network firewall is a device or service built around a policy engine. Classic ACLs filter individual packets by address, protocol and port, usually without tracking connections. Firewalls typically track connection state and often add application identification, user awareness, intrusion prevention and logging. In practice the two overlap: firewalls use ACL-like rules, and some switches offer stateful features. A common pattern is ACLs for simple internal separation and a firewall at the internet edge and around sensitive segments. Identity-driven controls such as network access control and role-based access control decide who or what gets access, and ACLs often enforce the network side of that decision.