ACLs start to break down when the number of users, permissions, or changes increases. Because permissions are tied directly to individual users, onboarding becomes manual and repetitive. Adding or removing a permission across the whole system can become burdensome, and the model does not scale well once access needs become more structured.
Where ACLs Start to Fray as an Application Grows
Access control lists work best when the access model is simple and the population is small. They become harder to manage when the application has more users, more roles in practice, more teams, and more frequent change. At that point, the challenge is not just adding entries. The real problem is that each exception becomes another place where access logic can drift from business intent, which makes review, troubleshooting, and ownership harder over time.
For security teams, the operational cost shows up first as manual work, then as inconsistent permissions, and finally as uncertainty about who should still have access. A flat ACL model also makes it difficult to express inherited, grouped, or context-based access cleanly, so organisations end up compensating with ad hoc exceptions that are difficult to audit. The control can remain technically functional while becoming practically unmanageable. In practice, many teams notice ACL fatigue only after permission cleanup has already turned into a recurring access-rights incident.
How ACL Complexity Affects Administration, Review, and Change
ACLs tie access decisions directly to specific subjects and resources. That is manageable when the system is small, but the model becomes expensive when every new user, service, team, or exception requires a direct edit. The main scalability problem is not the permission check itself. It is the growth in administrative surface area: each new object, each changed entitlement, and each deprovisioning event adds another item that must be reviewed and kept current.
This creates several practical failure modes. First, teams spend more time maintaining access than describing access intent. Second, the same permission pattern gets copied repeatedly across resources, which increases the chance of drift. Third, access reviews become harder because the reviewer must reason about many individual entries instead of a smaller set of roles or policy rules. As the application grows, the ACL can also become brittle during reorganisations, because a change to one user or one resource does not automatically propagate to the rest of the access model.
The broader governance issue is that ACLs are local by design. They answer “who can access this specific object?” well, but they do not naturally answer “what access should this function, team, or job category have across the system?” For that reason, many organisations eventually complement ACLs with role-based or policy-based controls when growth introduces repeated patterns. NIST’s control guidance is useful here because it treats access control as part of a managed system rather than a set of isolated permissions, and that perspective becomes more important as scale increases. NIST SP 800-53 Rev 5 Security and Privacy Controls
- Direct permissions work well for a few exceptions, but repeated patterns usually signal that the model needs abstraction.
- Manual edits scale poorly because they multiply review effort and increase the chance of stale access.
- Inheritance and grouping reduce repetition, but only if the application can express them without creating hidden privilege.
Once access decisions need to be reused, audited at scale, or changed in bulk, the ACL model starts to lose clarity and the process surrounding it becomes the real bottleneck.
When Flat Permissions Stop Matching Real Access Patterns
Tighter permission granularity often increases administrative overhead, requiring organisations to balance precision against maintainability.
One common edge case is a small application that is still simple in code but already complex in organisation. Even before user counts are high, ACLs can struggle if the same person needs access through multiple business contexts, because the model records identities and objects well but not necessarily the organisational relationships behind them. That is where teams often debate whether the problem is the ACL itself or the lack of a higher-level access model. The answer is that ACLs are not wrong; they are just a poor fit once access starts to reflect roles, functions, or delegated responsibility rather than one-off exceptions.
Another edge case is highly regulated or sensitive environments where per-resource precision is valuable. In those settings, ACLs may remain appropriate for a subset of controls even when they are not ideal as the primary model. The practical judgement is to keep ACLs where specificity matters most and move repeated access logic into a more governable layer where the organisation can see patterns, certify access, and remove it consistently. The model breaks down when the access structure becomes more complex than the team’s ability to explain and maintain it.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | 6.3 — Access Rights Management | ACL growth creates access review and removal burden across many identities. |
| 5.3 — Account Management | ACL-heavy environments rely on accurate user and account lifecycle handling. | |
| Recommendation — Use 6.3 to centralise access review and remove stale permissions at scale. Use 5.3 to keep account changes aligned with current business need. | ||
| NIST CSF 2.0 | PR.AC-4 — Access Permissions Are Managed | ACL sprawl is fundamentally about managing permissions as systems grow. |
| Recommendation — Apply PR.AC-4 to keep permissions governed, reviewed, and consistent as access expands. | ||
Practitioner Guidance
What to prioritise: Look for repetition, not just volume. If the same permission changes are being made across many users or objects, that is usually the signal that ACLs are becoming an administrative burden rather than a control advantage.
Decision rule: Keep ACLs for exceptions, object-specific protection, or tightly scoped resources; if access rules must be reused across teams or changed in bulk, treat that as a sign to introduce a higher-level access abstraction.
What to verify: Confirm whether the team can answer three questions quickly: who has access, why they have it, and how it is removed. If any one of those takes significant manual effort, the model is already stretching.
Practitioner takeaway: ACLs usually fail at scale because the organisation outgrows the maintenance model before it outgrows the technology, so the key judgement is whether the access structure is still understandable and governable after frequent change.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 8, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
