AC-6(10): Prohibit Non-privileged Users from Executing Privileged Functions

AC-6(10) requires you to technically prevent standard (non-privileged) users and sessions from running privileged functions, and to prove the prevention works in daily operations. Operationalize it by defining what “privileged functions” mean in your environment, enforcing separation with role-based access, elevation controls, and configuration baselines, then validating with logs, tests, and access reviews. ¹

Key takeaways:

• “Privileged functions” must be explicitly defined per platform (OS, database, cloud, SaaS, CI/CD), not left as a policy concept.
• Enforcement must be technical (RBAC, PAM/JIT elevation, hardening, conditional access), with monitoring to detect bypass attempts.
• Auditors will ask for proof: prevention configuration + who has admin rights + test results + operational logs.

AC-6(10): Prohibit Non-privileged Users from Executing Privileged Functions is a least-privilege control enhancement that forces a hard boundary between standard user activity and administrative activity. It is easy to “have a policy” for this and still fail an assessment because your systems allow privileged actions through shared admin accounts, local admin rights, overly broad cloud IAM roles, or CI/CD service accounts that can change production.

Treat AC-6(10) as a measurable engineering requirement: standard users must be unable to perform admin-only operations, and when privileged access is required, it must happen through approved elevation paths with accountability. The core challenge is scope. “Privileged function” means different things in Windows, Linux, AWS/Azure/GCP, Kubernetes, databases, identity providers, and business SaaS. Your job is to define the privileged function set for each major technology, map it to roles and entitlements, then enforce and continuously verify.

This page gives you a runbook a CCO, compliance officer, or GRC lead can use to stand up the requirement quickly: scoping, technical enforcement patterns, evidence to retain, audit questions to expect, and an execution plan you can assign to IAM, IT, and platform owners.

Regulatory text

Requirement (AC-6(10)): “Prevent non-privileged users from executing privileged functions.” ¹

Operator interpretation:
You must implement technical controls so that a user who is not explicitly authorized for admin privileges cannot perform admin actions, even if they can authenticate and access the system. This includes preventing “accidental admin” (broad roles), “implicit admin” (local admin on endpoints), and “side door admin” (service accounts, API tokens, CI/CD runners, break-glass accounts used as daily drivers).

What an operator must do:

• Define privileged functions by system type (examples below), then map those functions to roles/groups.
• Enforce separation: standard users operate without admin entitlements; privileged actions require an elevation mechanism or dedicated admin role/account.
• Monitor and test to validate non-privileged sessions cannot execute privileged functions in practice, not just by design. ¹

Plain-English requirement (what “privileged functions” means)

A “privileged function” is any action that can change security posture, access, configuration, or data protection in a way a standard user should not be able to. Typical privileged functions include:

• Identity & access: create/modify users, reset passwords, change MFA policies, edit conditional access, assign roles/groups, create API tokens.
• OS / endpoint: install software, disable AV/EDR, change firewall rules, modify system services, read protected credential stores, change audit settings.
• Server / infrastructure: change network ACLs/security groups, attach storage, snapshot volumes, alter system time, change logging destinations.
• Cloud / Kubernetes: edit IAM policies, assume high-privilege roles, change cluster RBAC, modify admission controllers, change secrets handling.
• Data platforms: grant table ownership, disable encryption, change audit logs, access production backups, alter retention policies.
• SDLC/CI-CD: modify production deployment pipelines, approve own changes, edit IaC modules that define IAM/networking, disable SAST/DAST gates.

Your goal is to make “standard user tries to do admin thing” fail reliably and be detectable.

Who it applies to (entity and operational context)

AC-6(10) is relevant anywhere you use NIST SP 800-53 controls to run a security program, including:

• Federal information systems and environments assessed against NIST SP 800-53. ²
• Contractor systems handling federal data, where NIST SP 800-53 is flowed down contractually or used as the control baseline for an authorization package. ²

Operationally, it applies across:

• Corporate IT (endpoints, MDM, directory services)
• Production infrastructure (cloud accounts/subscriptions/projects, network, Kubernetes)
• Critical business applications (ERP/HRIS/CRM) with admin consoles
• Third-party administered systems where your staff or the third party can perform privileged actions on your behalf

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

1) Write a “control card” for AC-6(10)

Create a one-page runbook with:

• Objective: non-privileged users cannot run privileged functions.
• Owner: IAM lead or security engineering; named backup.
• In-scope systems: identity provider, endpoints, servers, cloud, Kubernetes, CI/CD, key SaaS.
• Trigger events: new system onboarding, role changes, M&A, new admin tooling, incidents.
• Cadence: access reviews and control health checks on a defined schedule (set it internally and stick to it).
• Exceptions: documented, time-bound, approved, monitored.
  This converts “NIST language” into an operating procedure you can assign and audit.

2) Build your privileged function inventory (minimum viable)

You do not need perfection on day one, but you need a defensible list. Start with a table:

Platform	Privileged functions (examples)	Enforcement point
IdP (e.g., Entra/Okta)	role assignment, MFA/CA policy changes	admin roles + conditional access
Windows endpoints	local admin actions, driver install	remove local admin + privilege management
Cloud (AWS/Azure/GCP)	IAM policy edits, network changes	IAM roles + SCP/Policy + JIT
Kubernetes	cluster-admin actions, secret access	RBAC + admission policies
CI/CD	pipeline edits, prod deploy approvals	RBAC + protected branches + approvals

Tie each entry to “who can do this” and “how it’s prevented for everyone else.”

3) Enforce separation of standard vs privileged access

Implement at least one strong pattern per environment:

• RBAC with least privilege: remove broad groups like “admins” from default IT roles; use job-function roles.
• Privileged Access Management (PAM) / JIT elevation: require elevation for admin tasks, ideally time-bound with approval and logging.
• Separate admin accounts: dedicated admin identities that are not used for email, browsing, or daily work; force MFA and stricter policies on these accounts.
• Endpoint privilege management: eliminate standing local admin; allow app installs via managed packaging or time-bound elevation.
• Cloud guardrails: prevent privilege escalation paths (e.g., ability to attach admin policies) through policy constraints and tight role design.
• Service account governance: prohibit high-privilege long-lived tokens; restrict scopes; rotate credentials; limit which pipelines can assume privileged roles.

Your audit story improves dramatically when the privileged path is explicit and narrow.

4) Add detection and validation (prove it works)

Auditors and assessors expect more than “configured RBAC.” Build repeatable checks:

• Access review checks: list privileged roles/groups; validate membership, owner approval, and business justification.
• Technical negative testing: attempt a small set of privileged actions using a standard user test account; capture screenshots/logs showing denial.
• Log monitoring: alert on privilege escalation attempts, role assignment events, policy changes, and anomalous admin activity.
• Configuration baselines: store hardened configuration for endpoints/servers/cloud (policy-as-code where feasible) and monitor drift.

5) Operationalize exceptions without breaking the control

Exceptions happen. Make them survivable:

• Require ticket, approver, start/end date, and compensating controls.
• Prefer “temporary elevation” over adding someone to a permanent admin group.
• Review exception logs and close out on time.

6) Make third parties part of the same boundary

Where a third party administers systems:

• Contractually require named admin identities, MFA, and logging.
• Prohibit shared admin accounts, or tightly control and monitor them where unavoidable.
• Ensure you can receive logs or attestations that non-privileged users cannot perform privileged functions in the managed environment.

Daydream can help here by tying third-party access paths to the same control card, evidence bundle, and recurring health checks you already run for internal systems, so the control stays coherent across your supply chain.

Required evidence and artifacts to retain

Keep an “AC-6(10) evidence bundle” that is consistent each cycle:

1. Control card / runbook (owner, scope, cadence, exceptions).
2. Privileged role inventory per platform (export from IdP, cloud IAM, Kubernetes RBAC, SaaS admin pages).
3. Access approvals for current privileged users (tickets or GRC approvals with justification).
4. Configuration evidence:
   • Conditional access / MFA policies for admin roles
   • Endpoint privilege settings (no local admin baseline)
   • Cloud IAM role definitions and guardrails
5. Validation artifacts:
   • Negative test results showing standard users denied privileged actions
   • Screenshots or CLI output, dated and attributable
6. Logging/monitoring proof:
   • Example events for admin actions and failed privileged attempts
   • Alert rules and an incident/ticket showing triage workflow
7. Exception register with start/end dates and closure proof.

Store evidence in a controlled repository with retention aligned to your audit and contractual requirements.

Common exam/audit questions and hangups

Expect these, and prepare crisp answers:

• “Define privileged functions for your environment. Show where it’s documented.”
• “Who has admin access today across identity, endpoints, cloud, and CI/CD? Prove it.”
• “How do you prevent a normal user from doing X?” (they will pick a concrete action)
• “Show how privileged access is granted, time-bounded, and revoked.”
• “Do service accounts have admin privileges? How do you control their use?”
• “How do you detect and respond to privilege escalation attempts?”

Hangups that slow teams down:

• Over-scoping (“everything is privileged”) and never finishing.
• Treating SaaS admin consoles as out of scope.
• No negative testing; only policy statements.

Frequent implementation mistakes (and how to avoid them)

1. Standing admin access as the default.
   Fix: move to JIT elevation or separate admin accounts; require approvals and logging.

2. Local admin on endpoints “for productivity.”
   Fix: endpoint privilege management plus software packaging; carve out exceptions with expiration.

3. CI/CD runners and tokens with broad rights.
   Fix: restrict which pipelines can deploy or change infrastructure; scope credentials; rotate and monitor.

4. “Break-glass” accounts used routinely.
   Fix: lock break-glass behind strict conditions; require post-use review and evidence.

5. No single owner and no operating cadence.
   Fix: assign one accountable owner and run recurring control health checks with tracked remediation to closure. ¹

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so you should treat this primarily as an assessment and assurance risk in NIST-aligned programs. Practically, weak control here increases the chance that a compromised standard account can become an administrative foothold, which expands blast radius and complicates incident containment. It also drives audit findings because assessors can directly test it by attempting privileged actions with a standard account.

Practical 30/60/90-day execution plan

Use phased execution so you can show progress quickly without gambling on a full redesign.

First 30 days (stabilize and define)

• Assign an AC-6(10) owner and publish the control card (scope, cadence, exceptions).
• Build the privileged role inventory for your top systems (IdP, endpoints, cloud, CI/CD).
• Identify “red flag” entitlements: shared admins, standing local admin, overly broad cloud roles.
• Implement quick wins: require MFA and tighter policies for all admin roles; remove obvious unnecessary admins.

By 60 days (enforce and prove)

• Implement JIT elevation or a controlled admin access path for at least your highest-risk platforms.
• Run negative tests (standard user attempts privileged actions) and store results as evidence.
• Establish monitoring for privileged role assignment and policy changes; route alerts to a ticketing workflow.
• Start an exception register with time bounds and approvals.

By 90 days (scale and operationalize)

• Expand coverage to remaining platforms and critical SaaS tools.
• Establish recurring access reviews for privileged roles, with documented approvals and removals.
• Add drift detection for key configurations and document remediation SLAs internally.
• Run a control health check, track findings to closure, and retain a complete evidence bundle for the cycle. ¹

Frequently Asked Questions

Does AC-6(10) require a PAM tool?

No specific tool is mandated. You need technical prevention of privileged functions by non-privileged users; PAM is a common way to enforce time-bound elevation with strong logging.

Are separate admin accounts required?

The control requires prevention, not a specific identity pattern. Separate admin accounts are a straightforward way to reduce the chance that a daily-use account can perform privileged actions.

What counts as proof that non-privileged users can’t execute privileged functions?

Combine configuration evidence (RBAC/policies) with validation evidence (negative test attempts that fail) and operational evidence (logs/alerts for privileged actions and attempted escalation).

How do we handle service accounts that must perform privileged tasks?

Treat them as privileged identities: tightly scope permissions, restrict where they can run, rotate credentials, and monitor their activity. Document the business justification and controls in your evidence bundle.

Do SaaS admin consoles fall under this requirement?

Yes if the SaaS is in scope for your system boundary or handles regulated/sensitive data. SaaS platforms often have powerful privileged functions (role assignment, data export, security setting changes) that assessors expect you to control.

What’s the fastest way to reduce audit risk for AC-6(10)?

Get a clean privileged-role inventory, remove obvious unnecessary admins, enforce stronger authentication for admin roles, and produce negative test evidence that a standard user cannot perform a small set of privileged actions.

Footnotes

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

2. NIST SP 800-53 Rev. 5