Access Control List (ACL)
Abbreviation: ACL
Pronunciation: AK-sess kun-TROHL LIST (A-C-L)
Also known as: ACL
Definition
An Access Control List (ACL) is a set of rules attached to a resource or enforcement point that specifies which users, roles, services, addresses, or other principals may perform defined operations. An ACL expresses permissions, while discretionary access control describes a governance model in which an authorized owner may grant or remove those permissions. Rules should use least privilege, explicit scope, stable identities, controlled inheritance, change approval, periodic review, conflict handling, and logging of both decisions and denied attempts.
Overview
An Access Control List (ACL) is a set of rules attached to a resource or enforcement point that specifies which users, roles, services, addresses, or other principals may perform defined operations. The control exists to ensure that only appropriately identified and authorized principals can access resources or approve actions at the required level of assurance. An ACL expresses permissions, while discretionary access control describes a governance model in which an authorized owner may grant or remove those permissions. It should be interpreted alongside Discretionary Access Control (DAC) because the concepts can affect the same decision without representing the same control, event, or risk.
The workflow establishes a trusted identity or service principal, binds authenticators, evaluates context, applies policy, and records the resulting access decision. Authorization must be enforced by the server or resource boundary on every relevant request and should not depend on hidden interface elements or untrusted client claims. In this context, rules should use least privilege, explicit scope, stable identities, controlled inheritance, change approval, periodic review, conflict handling, and logging of both decisions and denied attempts.
It should connect the term to Access Token where that relationship changes access, transaction treatment, investigation, communication, or recovery.
Records should capture principal, authenticator or credential type, assurance level, resource, action, policy version, contextual signals, decision, failures, recovery, grants, revocations, and administrative changes. Sensitive secrets and authentication content should not be copied unnecessarily into logs.
Useful measures include enrollment and recovery success, challenge rate, failure rate, unauthorized attempts, privilege age, dormant access, review completion, false rejection, compromise events, and time to revoke access.
The relationship with Credential Store should be documented where it affects residual risk or control ownership.
Key Takeaway
Rules should use least privilege, explicit scope, stable identities, controlled inheritance, change approval, periodic review, conflict handling, and logging of both decisions and denied attempts.
Sources
- Digital Identity Guidelines: Authentication and Authenticator Management, SP 800-63B-4 — NIST (2026-08-03)
- Security and Privacy Controls for Information Systems and Organizations, SP 800-53 Rev. 5 — NIST (2026-08-03)
- A07:2021 Identification and Authentication Failures — OWASP (2026-08-03)