Access control lists have been the backbone of network security for decades. Every router and switch in your environment probably runs dozens of them. But the networks they were designed for, fixed offices with predictable traffic flows, no longer exist. Users roam between home, branch offices and client sites. Applications live in multiple clouds. Devices that never had an IP stack now sit on your network.
This guide explains how ACLs work, where they still make sense, and why IT teams managing hybrid environments are replacing static rule sets with identity-based access policies. If you are running hundreds of ACL rules across multiple sites and struggling to keep them accurate, this article maps a practical path forward.
How to move from static ACLs to identity-based access
- Audit your current ACL estate and flag rules tied to decommissioned systems or users.
- Classify remaining rules by function: perimeter filtering, internal segmentation, or application access.
- Keep ACLs for basic perimeter hygiene on routers and switches.
- Replace application access rules with Zero Trust Network Access policies tied to user identity and device posture.
- Consolidate internal segmentation into a single policy console with central logging.
- Decommission orphaned and shadowed rules in phases, starting with the least critical segments.
What is an access control list in networking?
An ACL is a set of rules on a router or switch that decides whether to permit or deny a data packet. When traffic hits a network interface, the device checks each rule in order, top to bottom. The first match wins: the device either forwards or drops the packet and skips everything below. If no rule matches, an implicit deny at the bottom blocks the traffic by default.
This sequential, deny-by-default logic is the foundation of traditional network segmentation. A common example is separating a guest Wi-Fi network from internal servers, so a compromised guest device cannot reach your file shares or ERP system.
The criteria ACLs evaluate
| Criterion | What it checks | OSI layer |
|---|---|---|
| Source IP address | Where the packet originates | Layer 3 (Network) |
| Destination IP address | Where the packet is headed | Layer 3 (Network) |
| Protocol type | TCP, UDP, ICMP or other transport protocols | Layer 3/4 |
| Port numbers | Specific service ports, e.g. 443 for HTTPS, 22 for SSH | Layer 4 (Transport) |
These four parameters give network administrators a basic toolkit for filtering traffic. The problem is that all four are static properties of a packet header. None of them tell you who is sending the traffic, whether their device is secure, or what application they are actually trying to reach.
Three types of traditional ACLs
Not all ACLs offer the same level of control. Understanding the differences matters when you decide which rules to keep and which to replace.
Standard ACLs
Standard ACLs filter traffic based on the source IP address only. They are fast and lightweight but blunt. A standard ACL cannot distinguish between web traffic and SSH from the same IP address, so it either permits or blocks everything from that source. In older Cisco environments, these use numbered ranges 1-99.
Extended ACLs
Extended ACLs add destination IP, protocol and port numbers to the evaluation. This lets you write precise rules like “allow SSH from the admin workstation to the database server on port 22, deny everything else.” Extended ACLs give much finer control but also introduce more complexity. Each additional parameter is another thing to get wrong.
Named ACLs
Named ACLs replace cryptic number ranges with descriptive labels. Instead of “ACL 101” you get “FINANCE-TO-ERP” or “GUEST-WIFI-RESTRICT.” This improves readability, especially in environments with hundreds of rules across multiple devices. Named ACLs are the current standard in modern network gear, but the underlying logic remains the same: static rules evaluated top to bottom.
Why ACLs break down at scale
ACLs work well in small, stable networks. The trouble starts when your environment grows, users become mobile, and IP addresses stop being reliable identifiers.
Rule bloat and human error
Every time a new application launches, a team member changes role, or a contractor needs temporary access, someone adds ACL entries. Over months and years, this creates rule bloat. Three specific problems show up repeatedly.
Rule shadowing happens when a broad permit rule higher in the list overrides a more specific deny rule below it. The specific rule never fires, but it stays in the config, creating a false sense of control. Orphaned rules are entries for users, servers or subnets that no longer exist. They do not cause immediate harm, but each one is an unnecessary access path that an attacker could exploit. Complexity gaps emerge when overlapping rules across multiple devices make it nearly impossible to trace what is actually allowed end to end.
If you manage ACLs across ten branch-office routers, each with 200+ rules, the audit burden alone can consume days of work per quarter.
IP addresses are no longer reliable identifiers
Traditional ACLs assume that an IP address maps to a known device in a known location. That assumption held when everyone worked from a desk in the office. It does not hold when the same employee connects from home on a DHCP-assigned address in the morning, from a hotel in the afternoon, and from a mobile hotspot in between. Cloud workloads make this worse: virtual machines scale up and down, pick up new addresses, and disappear again, sometimes within minutes.
Maintaining ACLs for this kind of environment means constant manual updates. Miss one, and you either block legitimate users or leave a gap an attacker can walk through.
No context, no intelligence
An ACL sees a packet header. It does not know whether the person behind the source IP is a finance manager or an intern. It does not know whether the device is running a patched OS or a three-year-old build with known vulnerabilities. It does not know whether this access request is routine or a sign that an account has been compromised.
This lack of context is what makes ACLs insufficient as a primary security control in hybrid and cloud environments.
The real risk: lateral movement after initial access
Static ACLs are designed to keep attackers out at the perimeter. But the perimeter is not where most damage happens. The real problem is what occurs after an attacker gets in.
A phishing email lands in an employee’s inbox. They click a link, and the attacker gains a foothold on a single workstation. With a VPN or flat internal network, that workstation often has broad access to shared drives, internal applications and other segments. Internal ACLs exist, but they were written to enable business traffic, not to contain an intruder. The attacker moves laterally, harvests credentials, and reaches sensitive systems without triggering any ACL denials, because they are using the same permitted paths as legitimate users.
This is not a theoretical scenario. It is the operational reality behind most ransomware incidents. Network segmentation helps limit the blast radius, but only if it is granular enough and maintained continuously. Traditional ACL-based segmentation rarely meets that standard in practice.
From static rules to identity-based access
The shift away from IP-centric ACLs is not about abandoning them entirely. Routers still need basic packet filtering. The shift is about moving application-level access decisions from static rule sets to dynamic, identity-aware policies.
What changes with identity-based access
| Characteristic | Static layer 3 ACL | Identity-based access |
|---|---|---|
| Primary identifier | IP addresses and subnets | Users, roles and devices |
| Flexibility | Low, manual updates required | High, policies adapt dynamically |
| Context awareness | None | Location, behaviour, device posture |
| Manageability at scale | Degrades rapidly | Centrally managed |
| Security model | Perimeter-based | Zero Trust |
With identity-based access, a policy says “members of the finance team, on managed devices that pass posture checks, may access the invoicing application.” That policy follows the user regardless of their IP address, location, or network segment. If a device fails its posture check, access is denied before any traffic reaches the application.
The role of ZTNA in replacing ACL-based application access
Zero Trust Network Access is the practical mechanism for this shift. Instead of opening network paths and hoping ACLs are granular enough, ZTNA publishes individual applications to authenticated, authorised users. The network itself becomes invisible to anyone who has not passed identity verification and device posture checks.
This eliminates the “broad network access” problem that plagues VPNs and ACL-dependent architectures. A user who authenticates to reach the invoicing app cannot see or reach the HR database, even if both sit on the same physical network. Each application is its own micro-segment, governed by policy rather than packet filters.
A practical migration path for IT teams
Ripping out every ACL overnight is neither realistic nor advisable. The migration works best in phases that deliver quick wins while reducing operational risk.
Phase 1: audit and classify
Pull your ACL configurations from all routers, switches and firewalls. Categorise each rule into one of three buckets: perimeter filtering (keep), internal segmentation (consolidate), or application access (replace). Flag orphaned rules and shadowed entries for immediate cleanup. This step alone often removes 20-30% of the rule estate.
Phase 2: introduce identity-based access for high-value applications
Pick two or three applications that currently depend on ACL-based access, ideally ones with clear user groups and high business impact. Publish them through ZTNA with identity verification and device posture checks. Run both the old ACL path and the new ZTNA path in parallel for a change cycle, then disable the ACL rules once users have migrated.
Phase 3: extend to agentless and industrial devices
Printers, IoT sensors and industrial equipment cannot run agents, which is exactly why they tend to sit on flat network segments with broad ACL permits. Deploy NIAC hardware to isolate these devices and control their traffic flows without touching their firmware. This creates a secure bridge between IT and OT environments without disrupting production.
Phase 4: consolidate segmentation into one console
Replace the patchwork of per-device ACLs with centralised policy management. A single console that covers ZTNA, Secure Web Gateway, and SD-WAN means one place to define policies, review logs and demonstrate compliance. For teams managing multiple sites, this is where the operational time savings become significant.
Phase 5: retain ACLs only where they belong
Basic packet filtering on edge routers, infrastructure protection rules for management interfaces, and protocol-level controls on switches still benefit from ACLs. Keep these, document them clearly, and review them on a fixed schedule. Everything else, especially application-level access decisions, should live in your identity-based policy layer.
Common mistakes during migration
Replicating ACL logic in ZTNA. If your first ZTNA policies mirror your old subnet-based rules, you have not changed anything except the tool. Define policies per application and role, not per IP range.
Skipping device posture. Identity alone is not enough. A compromised device with valid credentials is still a risk. Require managed device status, current OS versions and disk encryption as minimum posture signals.
Ignoring agentless devices. Printers and IoT endpoints are the devices most likely to sit on permissive ACL rules. Isolate them with inline hardware that enforces allow-listed traffic flows.
Attempting a single cutover. Phase the migration by application and user group. Parallel running lets you catch edge cases before they become outages.
How Jimber simplifies the transition
Jimber delivers Real SASE in one cloud-managed platform, replacing the patchwork of ACLs, VPNs and point tools with unified, identity-based security.
ZTNA provides per-application access with identity verification and device posture checks, removing the need for broad network-level ACL rules. Secure Web Gateway and Firewall-as-a-Service handle web traffic policies centrally, so you do not need separate ACL sets for outbound filtering on each site. SD-WAN connects branches securely without the MPLS contracts and per-site firewall configs that traditionally come with multi-location ACL management.
For devices that cannot run agents, NIAC hardware provides inline isolation with default-deny behaviour. Printers, IoT sensors and industrial equipment get controlled access paths without manual ACL maintenance.
Everything runs from a single management console with transparent pricing and API-first integration. For MSPs managing multiple customer environments, the multi-tenant architecture means one platform instead of dozens of per-customer ACL estates to maintain.
FAQ
Are ACLs still relevant in modern networks?
Yes, for basic packet filtering on routers and switches. ACLs remain useful for infrastructure protection and protocol-level controls. They are no longer sufficient as the primary mechanism for application access or internal segmentation in hybrid environments.
What is the difference between an ACL and ZTNA?
An ACL filters packets based on static header fields like IP address and port number. ZTNA grants access based on verified identity, device posture and application context. ZTNA operates at the application layer and adapts dynamically, while ACLs are fixed rules that require manual updates.
Can I run ACLs and ZTNA in parallel?
Yes, and this is the recommended approach during migration. Keep ACLs active on legacy segments while progressively publishing applications through ZTNA. Disable ACL rules per application once ZTNA access is confirmed and stable.
How does identity-based access help with NIS2 compliance?
NIS2 requires demonstrable access governance, least-privilege enforcement and incident containment. Identity-based policies with central logging provide clear evidence of who accessed what, when, and from which device. This is difficult to produce from distributed ACL configurations across multiple network devices.
What about devices that cannot run a ZTNA agent?
Printers, IoT sensors and industrial controllers need inline isolation. NIAC hardware sits between the device and the network, enforcing allow-listed traffic flows without requiring software on the device itself. This brings agentless equipment under Zero Trust controls.
How long does a typical migration take for a mid-market organisation?
Most teams can complete the first two phases, auditing ACLs and publishing initial applications through ZTNA, within four to six weeks. Full migration across all applications and sites typically takes three to six months, depending on the number of legacy systems and agentless devices.
Start replacing static ACLs with identity-based access
Ready to move from manual rule management to a single policy console? Book a demo and see how Jimber makes the transition from ACLs to identity-based ZTNA practical for your team.
