RBAC answers who should generally have access based on role, but it cannot always express resource specific exceptions. ACLs fill that gap by assigning permissions to individual users or groups for a specific object. They are useful when access must vary by file, folder, database record, or service, especially where precise control matters more than broad consistency.
Why ACLs Still Matter When RBAC Is Already in Place
RBAC and ACLs solve different parts of the access problem. RBAC is strongest when access can be grouped by job function and kept consistent across many users. ACLs still matter when the exception is the rule, such as one-off access to a specific file, folder, database record, or service object that does not fit cleanly into a broad role.
The practical reason organisations keep both is that access control often needs two layers: broad role assignments for scale, and object-level permissions for precision. Ultimate Guide to NHIs and NHI lifecycle management both reflect this pattern in practice, because access rarely stays perfectly role-shaped over time.
That split is also why ACLs are common in systems that need fine-grained exceptions without creating a new role for every edge case. For example, a user may belong to a finance role, but only a subset of records should be visible; or an application may need read access to one path in a repository but not another. ACLs let the object owner or platform express that narrower rule directly.
Where ACLs Add Precision That RBAC Cannot
RBAC is efficient for standardised access, but it becomes awkward when the policy depends on the object itself. ACLs are useful when the permission decision depends on the specific item being accessed, the sharing context, or a temporary exception that should not be turned into a permanent role. In other words, ACLs preserve precision where RBAC preserves scale.
This matters most in environments with lots of exceptions, legacy applications, or mixed ownership models. A role can say who should generally be in the door, but an ACL can say which room they may enter, which file they may open, or which action they may take on one resource. That is why ACLs often show up alongside NIST Cybersecurity Framework 2.0 style governance and broader access controls, rather than as a replacement for them.
ACLs are also a better fit when the access decision is inherited, shared, or delegated in ways that would otherwise force role explosion. If each exception became a role, the role catalogue would grow faster than the business can govern it. ACLs reduce that pressure by keeping the exception attached to the object instead of turning it into a new organisational identity pattern.
Risk and Threat Considerations
ACLs solve a precision problem, but they can also create hidden complexity if ownership, inheritance, or review is weak. The risk is not that ACLs exist, it is that object-level exceptions become difficult to see, recertify, or remove, which can leave stale access in place long after the original need has passed.
Failure mechanism: Permissions drift when object owners add exceptions locally, inherited entries are misunderstood, or access is granted directly and never folded back into a role. Over time, the ACL becomes the real policy while the role becomes only a coarse approximation.
Impact: Organisations can end up with excess access, inconsistent enforcement, audit gaps, and higher blast radius if a single object or account is compromised. Where permissions are attached directly to sensitive resources, review discipline matters as much as the control model itself. The NHI research page also shows why this is a recurring issue in practice, with 97% of NHIs carrying excessive privileges and only 5.7% of organisations reporting full visibility into service accounts.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while CIS Controls v8, NIST CSF 2.0 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | 6 — Access Control Management | ACLs are the mechanism for resource-level permission exceptions. |
| Recommendation — Enforce access reviews and revoke direct object permissions that exceed business need. | ||
| NIST CSF 2.0 | PR.AA — Identity Management, Authentication and Access Control | RBAC and ACLs are both access-control mechanisms within governance and enforcement. |
| GV.RM — Risk Management Strategy | ACL sprawl creates governance and review risk when exceptions outgrow roles. | |
| Recommendation — Apply access-control governance that separates broad role assignment from object-level exceptions. Set a review cadence for direct permissions and exception-heavy access paths. | ||
| OWASP Non-Human Identity Top 10 | NHI-02 — Excessive Permissions | Direct ACL grants can create excessive object-level privileges, especially for service access. |
| NHI-05 — Lifecycle and Offboarding | ACL exceptions must be removed when access is no longer needed to avoid stale object grants. | |
| Recommendation — Minimise direct resource permissions and remove grants that are broader than the task requires. Revoke object-specific permissions during offboarding and access cleanup. | ||
| NIST SP 800-63 | Digital Identity Guidelines | Access decisions should remain bound to verified identity assurance where direct permissions exist. |
| Recommendation — Tie direct access grants to verified identities and review them when assurance changes. | ||
Practitioner Guidance
What to prioritise: Treat RBAC as the baseline and ACLs as the exception mechanism. If a permission is stable, reusable, and tied to a job function, it belongs in a role; if it is resource-specific, temporary, or unusually narrow, an ACL is usually the cleaner control.
What to verify: Make sure ACLs are actually reviewed at the object boundary, not just assumed to be covered by role recertification. The common failure is letting direct grants accumulate because teams trust the role model and forget the resource-level list.
Practitioner takeaway: The right question is not whether ACLs duplicate RBAC, but whether the organisation can govern exceptions without turning every exception into a permanent role.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 20, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
