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

To meet the ac-6(10): prohibit non-privileged users from executing privileged functions requirement, you must technically block standard (non-privileged) accounts from performing admin-only actions and prove the block works in day-to-day operations. Operationalize it by defining “privileged functions,” enforcing role-based controls and separation of duties, and retaining logs plus periodic test results that show non-privileged users are denied.

Key takeaways:

• Define and inventory “privileged functions” per system, then map each to allowed privileged roles only.
• Enforce the prohibition with technical controls (RBAC/ABAC, PAM, sudo/UAC controls, cloud IAM) rather than policy-only.
• Keep audit-ready evidence: role/permission listings, access decisions, denial logs, and recurring negative tests.

AC-6(10) is a practical least-privilege control with a simple goal: standard users cannot run admin actions. In audits, teams often fail this requirement for two reasons. First, “privileged functions” are not defined consistently across endpoints, servers, databases, SaaS admin consoles, and cloud control planes. Second, organizations rely on intent (policy language) instead of enforceable mechanisms (role permissions, privilege elevation workflows, and hard technical denies).

This page gives requirement-level implementation guidance for compliance officers, CCOs, and GRC leads who need to assign ownership, drive execution, and collect evidence without turning it into a multi-quarter IAM transformation. The operating model is: (1) define what counts as privileged, (2) ensure non-privileged identities cannot execute those functions anywhere, (3) validate continuously through logging and repeatable tests, and (4) keep artifacts that stand up in a NIST SP 800-53 assessment.

Regulatory source references are limited to NIST SP 800-53 Rev. 5 materials provided. Where you need deeper technical mappings, treat them as engineering decisions you document and test.

Regulatory text

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

What the operator must do:

1. Determine which actions are “privileged functions” in each system boundary you manage (endpoints, servers, network devices, databases, applications, CI/CD, cloud).
2. Configure access controls so only privileged roles can perform those actions.
3. Demonstrate the control works through evidence of configuration, logs, and testing. The control expectation is prohibition, not “approval after the fact.” ²

Plain-English interpretation

A non-privileged user account must hit a hard stop when attempting admin-level tasks. “Hard stop” means the system denies the action based on enforced permissions, not just a policy statement or a detective alert after the change.

Privileged functions typically include actions that can:

• Change security settings (disable logging, weaken MFA, change firewall rules)
• Change identity and access (create admins, change group memberships, modify roles)
• Alter system integrity (install software, load kernel modules, change startup scripts)
• Access sensitive secrets (export keys, read production credentials, decrypt data)
• Modify audit controls (delete logs, change retention, change time sources)

Your job is to make sure those actions require privileged authorization paths (admin roles, just-in-time elevation, break-glass with controls), while regular user paths cannot execute them.

Who it applies to (entity and operational context)

Entities: Federal information systems and contractor systems handling federal data commonly scope NIST SP 800-53 controls into their security programs. ²

Operationally, it applies anywhere your workforce identities or service identities operate, including:

• Corporate endpoints (Windows/macOS/Linux), including developer workstations
• Server fleets (on-prem and IaaS), including domain controllers and jump hosts
• Cloud control planes (AWS/GCP/Azure IAM, org policies, subscription administration)
• SaaS administration (IdP admin console, ticketing, EDR, MDM, source control)
• Data platforms (database admin functions, analytics workspace admin controls)
• CI/CD and infrastructure-as-code runners (service accounts that can deploy or change permissions)

Third-party angle: If third parties administer your environment (MSP, consultants, SaaS support), their accounts must also be non-privileged by default and only gain privileged capability through controlled roles and workflows. Treat them as identities in scope, not “outside the requirement.”

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

Step 1: Name the control owner and the system scope

• Assign a control owner in IAM/Security Engineering with GRC as the evidence and testing owner.
• Define the systems in scope (start with highest-risk: IdP, cloud IAM, endpoint admin, production infrastructure).
• Document the boundary in a short control implementation statement.

Outcome: one accountable team and a scoping list you can defend.

Step 2: Define “privileged functions” for your environment

Create a privileged function register. Keep it short and action-oriented.

Example register fields (minimum viable):

• System (e.g., Azure AD/Entra ID, AWS IAM, Windows endpoints)
• Privileged function (verb + object), e.g., “Assign Global Administrator,” “Disable EDR agent,” “Attach admin policy to role”
• Privileged role(s) allowed
• Enforcement mechanism (RBAC policy, PAM workflow, sudoers file, UAC, conditional access)
• Log source to prove enforcement (IdP audit log, OS event log, cloud audit trail)
• Test method (negative test steps)

Exam reality: Auditors accept different privileged function lists by platform if you show consistent criteria and coverage.

Step 3: Implement technical prohibitions (deny-by-permission)

Pick the enforcement pattern per platform:

Endpoints (Windows/macOS/Linux)

• Remove local admin from standard users.
• Require elevation for admin tasks through managed mechanisms (e.g., admin accounts, controlled elevation tooling).
• Lock down “run as admin” pathways and script execution policies as applicable.
• Ensure non-privileged users cannot install drivers/agents or change security tooling.

Servers

• Prohibit direct root/Administrator logins for standard accounts.
• Use role-based access and controlled privilege escalation (e.g., sudo with tight command allow-lists).
• Separate “read-only operations” from “change operations.”

Cloud and SaaS

• Use least-privilege IAM roles. Avoid “:” style broad grants.
• Separate billing/admin from security admin from deployment roles.
• Enforce JIT elevation for rare privileged actions where possible.
• Apply conditional access controls to privileged roles (device posture, MFA, network restrictions) as compensating risk reduction.

Applications and databases

• Enforce application RBAC: admin endpoints restricted to admin roles.
• Disallow shared admin accounts; require named accounts with privileged roles.
• Split DBA functions: schema changes vs data reads vs user management.

Tip that reduces audit pain: Implement explicit denies where your platform supports them; otherwise show that the permission model cannot grant the function to non-privileged roles.

Step 4: Control privileged access pathways (PAM + process)

AC-6(10) fails in practice when teams create “temporary admin” without guardrails.

Minimum process requirements:

• A defined request/approval path for elevation (ticket or workflow)
• Time-bounded elevation where feasible
• Separate admin identities (no daily-driver admin accounts)
• Break-glass accounts with strict controls and monitoring

This is also where Daydream fits naturally: map AC-6(10) to a named owner, implementation procedure, and recurring evidence artifacts so you can run the control like an operational checklist instead of a one-time project. ¹

Step 5: Test the prohibition (negative testing) and fix gaps

Create repeatable negative tests per system:

• Attempt privileged actions as a standard user
• Capture the denial event (screen capture, command output, audit log entry)
• Record the test case, date, tester, system, and result
• Track remediation items with an owner

Make tests realistic. For example, attempt:

• Adding a user to an admin group
• Installing software
• Disabling logging/EDR
• Changing IAM role bindings
• Accessing secrets vault export features

Step 6: Operationalize ongoing monitoring and change control

• Detect privilege creep: role expansions, new admin groups, policy changes.
• Require review for permission changes to privileged roles (change management).
• Monitor for “privileged action attempted by non-privileged identity” events and treat repeated attempts as an incident signal.

Required evidence and artifacts to retain

Aim for evidence that proves three things: definition, enforcement, and operation.

Keep these artifacts audit-ready:

• Control implementation statement for AC-6(10) referencing system scope and enforcement approach ²
• Privileged function register (the inventory you maintain)
• Role/permission exports from key platforms (IdP roles, cloud IAM policies, endpoint local admin group membership reports)
• PAM/elevation workflow records (requests, approvals, expiration, revocation evidence)
• Negative test results showing standard users denied privileged actions
• Logging evidence: sample audit logs demonstrating denied attempts and admin actions attributable to privileged roles
• Exception register: any approved deviations, business justification, compensating controls, and expiration/renewal decisions

Common exam/audit questions and hangups

What auditors ask most often:

• “Show me how you define privileged functions for this system.”
• “Prove a standard user cannot do X.” (They will pick a specific function like role assignment or agent disablement.)
• “How do you prevent developers from being local admin on laptops?”
• “How do you control service accounts that can perform admin actions?”
• “Show evidence this is reviewed and still works after changes.”

Hangups that slow assessments:

• No consistent mapping between “privileged functions” and roles.
• Overreliance on screenshots without underlying exports/log sources.
• Exceptions that never expire.

Frequent implementation mistakes (and how to avoid them)

1. Policy-only compliance.
   Fix: pair policy with enforced RBAC/PAM configuration and denial evidence.

2. Shared admin accounts.
   Fix: require named privileged accounts and log attribution; document any break-glass separately.

3. Privilege creep through groups.
   Fix: restrict who can grant privileged roles; monitor group membership changes; require change control for admin group modifications.

4. Service accounts ignored.
   Fix: treat service principals as identities. Limit permissions, rotate secrets, and scope to least privilege.

5. Local admin “because developers need it.”
   Fix: introduce controlled elevation for specific tasks; keep daily accounts non-privileged.

Enforcement context and risk implications

No public enforcement cases were provided in the supplied source catalog for this specific enhancement, so this page does not cite enforcement examples.

Risk-wise, AC-6(10) is a direct control against common attack paths: phishing a standard user and then escalating locally, moving laterally, and disabling security controls. From a governance perspective, failure usually signals broader access control weakness and weak change discipline in IAM.

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

Use phases rather than fixed day-count promises. Treat these as sequencing buckets you can run in parallel if you have staff.

Days 0–30: Establish scope, definitions, and quick wins

• Assign control owner and evidence owner.
• Build the privileged function register for: IdP, cloud IAM, endpoints, production servers.
• Remove obvious excess privilege: local admin memberships, broad cloud admin roles, default admin groups.
• Turn on/confirm audit logging sources for privileged actions and access denials.

Days 31–60: Enforce and standardize privileged access pathways

• Implement or tighten PAM/JIT elevation for top privileged roles.
• Standardize admin role naming and access request workflow.
• Write test cases and run initial negative tests across in-scope systems.
• Create an exception process with expiration and compensating controls.

Days 61–90: Prove operations and make it repeatable

• Schedule recurring permission reviews for privileged roles and admin groups.
• Automate evidence pulls where possible (role exports, admin membership reports, audit logs).
• Track metrics qualitatively (trend of exceptions, closed remediation items) without inventing numeric targets.
• Store all artifacts in a single assessment-ready location (GRC repository), mapped to AC-6(10). ²

Frequently Asked Questions

What counts as a “privileged function” in AC-6(10)?

Any action that changes security posture, access rights, system integrity, or audit controls should be treated as privileged. Define a list per platform and tie each function to specific privileged roles with enforced permissions. ²

Do I need a PAM tool to comply?

Not always, but you do need a controlled method for granting privileged capability and proving non-privileged users cannot execute privileged functions. Many organizations meet the requirement with strong RBAC plus tightly governed admin accounts; PAM makes it easier to operationalize and evidence.

How do I handle developer workstations where tools require admin rights?

Keep the daily user non-privileged and provide controlled elevation for specific tasks, with logging and time bounds where feasible. If you must grant persistent local admin, document it as an exception with justification, compensating controls, and a review cadence.

Are service accounts and CI/CD runners “non-privileged users”?

They are identities that can execute functions, so they are in scope for the same principle. Limit service account permissions to the minimum needed and separate deploy roles from security administration roles.

What evidence is most persuasive to an assessor?

Permission/role exports that show non-privileged roles lack privileged grants, plus negative test results and audit logs that show denied attempts. Pair technical proof with a clear implementation statement mapped to AC-6(10). ¹

How should a GRC team operationalize this without becoming an IAM engineer?

Own the privileged function register, testing cadence, exceptions, and evidence quality. Partner with IAM/Security Engineering for configuration changes, and use a system of record (for example, Daydream) to assign ownership and collect recurring artifacts consistently.

Footnotes

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

2. NIST SP 800-53 Rev. 5