AC-2 decides who should have access. AC-3 is where the system actually says yes or no. It is a short control with a lot riding on it: enforce approved authorizations for logical access to information and system resources, according to your access control policies.
SP 800-53 binds US federal systems and, through contract, some suppliers. For everyone else it is a reference that lines up closely with the "logical access" questions in SOC 2 and ISO 27001 reviews. Mappings vary by source, so check before you assume an exact match.
What the control asks
The statement is a single line. Approved authorizations must be enforced. The guidance explains the model: access control policies govern how subjects, meaning users or processes acting for them, reach objects, meaning devices, files, records and domains. Enforcement can happen at the system level and also at the application and service level for added protection. Physical access belongs to the PE family, not here.
What it means in practice
It means the permission you wrote down is the permission the system applies. If your policy says only the finance group reads the payroll export, the storage service must refuse everyone else, not rely on a hidden URL.
The enhancements name specific mechanisms, and you can use them as a menu:
- AC-3.1 Restricted Access to Privileged Functions
- AC-3.2 Dual Authorization
- AC-3.3 Mandatory Access Control
- AC-3.4 Discretionary Access Control
- AC-3.5 Security relevant Information
- AC-3.6 Protection of User and System Information
- AC-3.7 Role based Access Control
- AC-3.8 Revocation of Access Authorizations
For most commercial systems, AC-3.7 role based access control is the working answer, with AC-3.8 covering revocation. Dual authorization, AC-3.2, suits destructive actions such as deleting a production database.
Evidence to collect
- The access control policy and the role definitions it relies on.
- Configuration exports for each system that enforces access: cloud IAM policies, database grants, application permission tables.
- A negative test: a user without the right trying and failing, with the denial logged.
- For application level checks, a test suite or code review notes showing authorization checks on each route.
- Evidence that revoked access takes effect, such as a test after removal.
Common gaps
- Enforcement in the user interface only. The API still serves the data.
- Broad default permissions that people never narrow.
- Object storage buckets or links that are public by accident.
- Authorization checks that verify login but not ownership, so one customer can read another customer's records.
- No test for revocation, so sessions and tokens outlive the removal.
How to implement it
Pick one place to define roles and keep application checks consistent with it. Deny by default, and grant by role. Write tests that try to cross the lines: another tenant's data, an admin endpoint as a normal user. Run those tests in your pipeline so a change cannot quietly remove a check.
Then export the permission configuration on a schedule and keep it. That export is your evidence, and the diffs show change over time.
Quick check
How does AC-3 differ from AC-2?
AC-2 manages accounts and their approved privileges. AC-3 makes the system enforce those approved authorizations at the moment of access.
Does AC-3 cover physical access?
No. The guidance says physical access controls fall under the PE family.
Sources
- NIST SP 800-53 Rev 5, AC-3: https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=AC-3
- NIST OSCAL catalog of SP 800-53 Rev 5: https://raw.githubusercontent.com/usnistgov/oscal-content/main/nist.gov/SP800-53/rev5/json/NIST_SP-800-53_rev5_catalog.json
