AC-6: Least Privilege

AC-6 is one of the fastest ways an assessor will test whether your access control program is real or performative. Policies are not enough. Least privilege shows up in the day-to-day mechanics of provisioning, permission changes, admin access, service accounts, and the speed and completeness of deprovisioning. The control’s language is simple, but the operational scope is broad because it applies to both people and non-human identities (processes, service accounts, automations) that act on behalf of users.

For a Compliance Officer, CCO, or GRC lead, the shortest path to implementation is to translate “only what’s necessary” into: (1) a documented access model (roles and entitlements), (2) a workflow that enforces that model (requests, approvals, and change tracking), and (3) recurring validation (access reviews and exception cleanup). If you can’t show who approved access, why it was needed, what changed, and what you do when access is excessive, you will struggle to demonstrate AC-6 even if the environment is reasonably secure.

This page gives requirement-level guidance you can hand to IAM, IT, and system owners and then audit against.

Regulatory text

Requirement (AC-6): “Employ the principle of least privilege, allowing only authorized accesses for users (or processes acting on behalf of users) that are necessary to accomplish assigned organizational tasks.” ¹

Operator interpretation:
You need a governed method to grant, change, and remove access so permissions align to assigned duties. This includes:

• Human users (employees, contractors, admins).
• Non-human identities (service accounts, application integrations, robotic processes).
• Privileged functions (system administration, security administration, database administration).
• Access paths across systems (SSO roles, cloud IAM policies, database grants, SaaS permission sets).
  Control intent is met only when “necessary for tasks” is reflected in your access design and your evidence.

Plain-English interpretation (what AC-6 requires)

Least privilege means three things in practice:

1. Default deny, then grant narrowly. Access starts with nothing (or a minimal baseline). You grant specific privileges based on job tasks, not convenience.
2. Privileges match duties, not seniority. “Director” is not a permission set. Duties are the driver (approve invoices, deploy code, administer identity).
3. Privileges do not linger. When tasks end, privileges end. Temporary needs get time-bound access or a documented exception with an expiration and review.

Who it applies to

Entity types / context:
AC-6 is a core NIST SP 800-53 control used across federal information systems and contractor systems handling federal data ².

Operationally, you should apply AC-6 to:

• Identity providers and directories (workforce IAM, SSO).
• Cloud IAM (AWS/Azure/GCP roles and policies).
• SaaS applications that store or process sensitive data (ticketing, finance, HRIS, CRM).
• Infrastructure and platforms (endpoints, servers, Kubernetes, CI/CD).
• Data systems (databases, object storage, analytics platforms).
• Third-party access into your environment (support tools, MSP access, contractor accounts).

If you’re scoping for an assessment, include at least systems that process regulated data or mission-essential operations, plus the IAM systems that control access to them.

What you actually need to do (step-by-step)

Use this as an implementation checklist you can assign to control owners.

1) Assign ownership and write an implementation procedure

• Name a control owner (often IAM lead) and system control operators (app owners).
• Write a Least Privilege Standard / Procedure that defines:
  • How roles are created and approved.
  • How access is requested and approved.
  • How privileged access is granted (standing vs time-bound).
  • How service accounts are created, reviewed, and rotated.
  • How exceptions work (who can approve, duration, compensating controls).
    This directly supports the “prove it” requirement implied by AC-6’s assessment expectations ².

2) Build (or fix) your access model: roles + entitlements

• Create an application entitlement catalog for in-scope systems:
  • Role name
  • Permissions included
  • Business purpose
  • Data/system sensitivity
  • Role owner
  • Approval requirements
• Define a small set of standard roles per system (Reader, Operator, Admin) plus duty-specific roles (Billing Approver, HR Case Manager).
• Explicitly document prohibited combinations where separation of duties matters (e.g., create vendor + approve payment).

Deliverable: a role/entitlement matrix that a reviewer can test against real accounts.

3) Implement controlled access workflows (request → approval → provisioning)

• Require access requests to include:
  • System, role, justification tied to job tasks
  • Manager approval (and system owner approval for high-risk roles)
• Provision through a controlled system (IAM tool, ITSM tickets, or access request platform) so changes are logged and reproducible.
• For direct admin actions (manual grants), require a ticket reference in the change record.

Practical note: assessors commonly select a sample of users and ask you to show the request/approval trail and the technical proof of the granted rights.

4) Remove standing privilege where feasible; control privileged access tightly

• Identify privileged roles across systems (global admins, root, subscription owners, database superusers).
• Prefer time-bound elevation for admin tasks.
• Require stronger authentication for privileged actions (via your standard access stack).
• Limit privileged access to dedicated admin accounts where appropriate, and prevent daily work from privileged identities.

Even if you can’t fully modernize privileged access quickly, you can still meet the control intent by documenting which admin rights exist, who has them, why, and how you review them.

5) Control service accounts and “processes acting on behalf of users”

AC-6 explicitly includes processes acting for users ¹. Treat service identities as first-class scope:

• Inventory service accounts/integration identities.
• Assign an owner and a purpose for each.
• Grant narrowly scoped permissions (single system, single function).
• Review privileges on a recurring basis and remove stale accounts.

6) Validate with recurring access reviews and exception cleanup

Define a review cadence that fits risk and system criticality, and document it in your procedure as an organizational requirement. For each in-scope system:

• Run an access review (users and privileged roles first).
• Capture reviewer sign-off and remediation actions.
• Track exceptions to closure (with expiry dates).

The biggest win for audit readiness is consistency: same artifacts, same fields, same retention approach every cycle.

7) Prove it continuously (assessment-ready evidence package)

Create a standing evidence folder (by system) that you refresh with each review cycle. Daydream can help here by mapping AC-6 to a control owner, an implementation procedure, and recurring evidence artifacts so collection becomes routine instead of a fire drill ².

Required evidence and artifacts to retain

Keep evidence tied to the control statement and easy to sample.

Governance artifacts

• Least Privilege Policy/Standard and implementation procedure (AC-6 mapped).
• Role/entitlement definitions for in-scope systems.
• Privileged access approach (e.g., how admin access is approved and constrained).

Operational artifacts

• Access request tickets (new access, role changes, terminations) with approvals and justification.
• Provisioning logs or screenshots showing role assignment (SSO/IAM/app admin panel exports).
• Privileged access assignment list (who has admin and why).
• Service account inventory with owner, purpose, and permissions.

Validation artifacts

• Access review reports (exported user/role lists), reviewer attestation, remediation tickets, and completion evidence.
• Exception register: exception owner, reason, compensating controls, expiration, renewal approvals.

Common exam/audit questions and hangups

Expect questions that test both design and operation:

• “Show me how you decide what access a new hire gets for System X.”
• “Pick three admins. Why do they need admin, and who approved it?”
• “How do you prevent permission creep after role changes?”
• “Do service accounts follow the same least privilege rules?”
• “Show the last access review and the remediation outcomes.”
• “Where is AC-6 implemented technically versus documented procedurally?” ²

Hangup to plan for: app owners often claim “the app doesn’t support roles.” Auditors will still expect you to compensate (restricted groups, separate instances, narrower permission bundles, or documented exceptions with approvals).

Frequent implementation mistakes (and how to avoid them)

1. Role explosion. Too many roles becomes ungovernable. Start with a small set, then add only where tasks require it.
2. Manager-only approvals for high-risk access. Add system owner/security approval for privileged roles.
3. Standing admin for convenience. Move admin work to time-bound elevation or dedicated admin accounts, and document any exceptions.
4. Ignoring non-human identities. Service accounts routinely end up over-permissioned. Inventory them and review them like users.
5. Access reviews that don’t remediate. A signed spreadsheet with no follow-up tickets fails in practice. Track removals to closure.
6. No evidence trail. If access is granted via chat or informal emails, you will not be able to demonstrate AC-6 consistently.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so this page does not cite enforcement outcomes. Practically, least privilege failures increase breach blast radius, enable fraud through excessive permissions, and weaken incident containment. Your risk register should treat excessive privilege as both a security risk and an auditability risk, especially for privileged access and third-party access paths.

Practical execution plan (30/60/90-day)

Use this as an operational rollout sequence. Timelines are planning guidance; adjust to your environment.

First 30 days (stabilize and document)

• Assign AC-6 owner and in-scope systems list.
• Publish least privilege procedure (requests, approvals, privileged access, service accounts, exceptions).
• Inventory privileged roles and current privileged users across core systems.
• Stand up an evidence structure (by system) and start collecting request/approval samples.

Days 31–60 (standardize and reduce risk)

• Define role/entitlement catalog for top systems (start with IAM, email/collaboration, cloud, ticketing, finance).
• Implement approval rules for privileged roles and third-party access.
• Begin service account inventory with owners and purposes.
• Run first access review for privileged access and remediate obvious excess rights.

Days 61–90 (make it repeatable)

• Expand access reviews to remaining in-scope systems.
• Implement exception register with expirations and renewal workflow.
• Reduce standing admin where feasible; document compensating controls where not feasible.
• Package AC-6 evidence: procedure, role catalog, samples of tickets, last review outputs, remediation proof.

Frequently Asked Questions

Does AC-6 apply to service accounts and integrations?

Yes. The text includes “processes acting on behalf of users,” which covers service accounts and automations ¹. Inventory them, assign owners, and constrain permissions to the specific function.

Can we meet AC-6 if an application has only “admin” and “user” roles?

Possibly, but you need compensating controls: strict admin approvals, limited admin population, documented job-task justification, and recurring admin access reviews. If the “user” role is overly broad, document the risk and a plan to reduce it.

What’s the minimum evidence an auditor will accept for least privilege?

You need a documented procedure plus operational proof: access requests with approvals and justification, system exports showing actual permissions, and access review records with remediation. Evidence must tie granted access to assigned tasks ².

How do we handle “break glass” emergency access without violating least privilege?

Keep emergency access separate, limited to named individuals, and controlled with approvals and logging after the fact. Review each use and remove access when the emergency ends.

Do contractors and third parties fall under AC-6?

Yes if they access your systems or data. Treat them as identities in scope: documented request/approval, least-privilege roles, time-bound access, and removal at end of engagement.

What should we do if we discover permission creep during access reviews?

Treat it as a control failure to remediate, not a documentation issue. Remove excess rights, open tickets for systemic fixes (role redesign, workflow enforcement), and record the remediation as part of your AC-6 evidence set.

Footnotes

1. NIST SP 800-53 Rev. 5 OSCAL JSON

2. NIST SP 800-53 Rev. 5