Least privilege is easy to say and hard to prove. AC-6 puts it in one sentence: allow only the authorized accesses that users, and processes acting for them, need to accomplish assigned tasks.
SP 800-53 binds US federal systems and, by contract, some suppliers. Others use it as a reference, and least privilege appears in nearly every serious framework and customer security review. Mappings vary by source, so verify the one you rely on.
What the control asks
Employ least privilege. The base control has no parameters. The guidance extends the idea in three directions: apply it to specific duties and systems, apply it to system processes so they run at no higher level than needed, and apply it across development, implementation and operation. It also says to create extra roles and accounts where that is what it takes to achieve least privilege.
What it means in practice
A developer who deploys code does not need billing admin. A build job that pushes images does not need the ability to delete the registry. A service reading one table does not need the whole database.
The enhancements give you the practical checklist:
- AC-6.1 Authorize Access to Security Functions
- AC-6.2 Non privileged Access for Nonsecurity Functions
- AC-6.3 Network Access to Privileged Commands
- AC-6.4 Separate Processing Domains
- AC-6.5 Privileged Accounts
- AC-6.6 Privileged Access by Non organizational Users
- AC-6.7 Review of User Privileges
- AC-6.8 Privilege Levels for Code Execution
AC-6.2 is the one most teams can act on today: administrators use a normal account for email and browsing, and a separate privileged one for admin tasks. AC-6.7 is the review that keeps everything honest.
Evidence to collect
- The list of privileged roles and who holds them, with approvals.
- Cloud IAM exports showing permissions per role, with wildcards flagged.
- Separate admin accounts for administrators.
- A privilege review with date, reviewer and removals made.
- Service account permissions, with owners.
- CI and deployment credentials scoped to what they need.
Common gaps
- Administrator rights granted as a convenience and never removed.
- Cloud policies using a wildcard for actions or resources.
- Shared root or owner accounts.
- Pipelines using a personal token with full scope.
- Reviews that confirm names but never look at what each role can do.
- Containers running as root with no reason.
How to implement it
Begin with an inventory of privileged access. For cloud, use your provider's access analysis to find permissions unused in the last ninety days, and remove them. Create narrow roles for repeat tasks rather than handing out broad ones.
Use time bound elevation for rare admin work, so rights expire on their own. Give each automation its own identity with a minimal scope. Schedule the AC-6.7 review at least yearly, and quarterly for the most privileged roles.
Least privilege applies to software too. A dependency that asks for broad permissions at install or run time widens your exposure. Reachability analysis helps you see which vulnerable code paths your application can actually hit, so you can focus on what matters.
Quick check
Does least privilege apply to processes?
Yes. The guidance says processes should operate at privilege levels no higher than necessary.
Which enhancement is the privilege review?
AC-6.7 Review of User Privileges.
Sources
- NIST SP 800-53 Rev 5, AC-6: https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=AC-6
- 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
