Least Privilege | Prohibit Non-Privileged Users from Executing Privileged Functions

To meet the least privilege requirement to prohibit non-privileged users from executing privileged functions, you must implement technical controls that block admin-grade actions unless a user is explicitly authorized, and you must prove it with access models, configurations, and logs. For FedRAMP-aligned programs, this maps to NIST SP 800-53 Rev. 5 AC-6(10) and is routinely validated through role testing and evidence review. ¹

Key takeaways:

• Define what “privileged functions” are in your environment, then bind them to roles that only privileged identities can assume. ¹
• Enforce the prohibition technically (RBAC/ABAC, PAM, separation of admin planes) and validate it with negative testing. ¹
• Retain evidence that shows approvals, provisioning, periodic review, revocation, and control operation over time. ²

This requirement is simple to read and easy to fail in practice: “non-privileged users” must not be able to do “privileged functions.” The failure mode is usually not a missing policy. It’s an access path you forgot to model: a default “power user” role in a SaaS admin console, a cloud IAM wildcard permission, a CI/CD runner that can modify production, a helpdesk tool with admin actions available to all agents, or a database client that allows schema changes from standard accounts.

For a Compliance Officer, CCO, or GRC lead, the fastest way to operationalize AC-6(10) is to treat it as an engineering requirement with auditable outcomes: (1) privileged functions are enumerated, (2) the system enforces authorization before those functions execute, and (3) you can demonstrate both design and operating effectiveness with repeatable tests and retained artifacts. This page gives you a practical implementation sequence, the evidence auditors ask for, and the common hangups that stall FedRAMP and NIST 800-53 assessments. ¹

Regulatory text

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

Operator interpretation (what you must do):

• Identify which actions are “privileged functions” across your authorization boundary (for example: create/modify accounts, change access policies, alter logging settings, manage encryption keys, deploy to production, modify firewall rules).
• Ensure those actions can only be executed by privileged roles (or privileged elevation sessions) through technical enforcement, not just procedure.
• Demonstrate enforcement with configuration evidence and test results showing standard users cannot perform privileged actions. ¹

Plain-English interpretation

A user who is not approved for admin power must be blocked from admin actions, every time, across every interface: UI, API, CLI, automation, and break-glass paths. If a “regular” user can reset MFA, grant themselves permissions, disable audit logs, or push production changes, you have not met this requirement, even if you “trust” the user or have a policy that says they should not do it. ¹

Who it applies to (entity and operational context)

Applies to:

• Cloud Service Providers and Federal Agencies implementing and maintaining controls within a FedRAMP authorization boundary. ¹

Operational scope (where it shows up):

• Identity provider (IdP) and directory roles (SSO, MFA administration, group management)
• Cloud IAM and resource policies
• SaaS admin consoles used to operate the service (ticketing, monitoring, CI/CD, secrets, endpoint management)
• Operating systems and databases (sudoers, DBA roles)
• Production change paths (infrastructure as code, deployment pipelines, admin APIs)
• Third-party tooling that can execute privileged actions inside your boundary (managed SOC tools, MSP access, remote admin agents)

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

1) Define “privileged functions” as an inventory, not a concept

Create a Privileged Function Catalog for the authorization boundary. Keep it short but concrete.

• Start from high-risk categories: identity and access changes, security configuration changes, logging/monitoring changes, key management, production deployment, data export, backup/restore, and network boundary changes.
• For each function, record: system, interface (UI/API/CLI), permission name(s), and owning team.

Deliverable: Privileged Function Catalog (table format) mapped to systems in scope.
Why auditors care: AC-6(10) testing fails when teams cannot name what “privileged” means in their environment. ¹

2) Create an access model that cleanly separates privileged and non-privileged roles

Implement RBAC/ABAC such that privileged functions map to distinct roles (or groups) that are not granted by default.

• Define “standard user” baseline entitlements.
• Define privileged roles by job function (system admin, security admin, DB admin, release manager).
• Restrict role assignment authority (who can grant admin roles must itself be limited).

Tip that prevents rework: Avoid “everyone in Engineering gets admin” roles. If a role contains any privileged function, treat it as privileged and gate it accordingly. ¹

3) Enforce with technical controls (block execution, don’t rely on training)

Use technical mechanisms appropriate to each platform:

• IdP / directory: Admin roles restricted to a privileged admin group; require step-up authentication for admin portals.
• Cloud IAM: Deny-by-default policies for privileged API actions; avoid wildcard permissions; use permission boundaries or policy guardrails if available in your environment.
• OS/database: Remove local admin from standard users; control sudo/database admin via groups; require separate admin accounts where feasible.
• CI/CD: Ensure pipeline identities have only the permissions needed; separate build from deploy; restrict production deploy actions to privileged roles.

Minimum bar: A non-privileged user attempting a privileged function should receive an authorization failure, and that failure should be loggable. ¹

4) Add Privileged Access Management (PAM) or “just-in-time” elevation where standing privilege is risky

If you have roles that are needed only occasionally (DBA actions, emergency production fixes), implement time-bound elevation:

• Require an access request with business justification.
• Require approval by a role owner and (where appropriate) security.
• Use expiring group membership or session-based elevation.
• Capture session logs for privileged sessions where supported.

Evidence goal: Show that privileged access is constrained by time and approval, and revokes automatically or through a defined trigger. ¹

5) Test the prohibition with “negative tests” and keep the proof

Assessors will not accept “we configured RBAC” without verification. Build a repeatable test script:

• Create or identify a representative non-privileged test user.
• Attempt a curated set of privileged actions across key systems (admin console, API call, CLI command, pipeline action).
• Record outcomes (blocked) and capture screenshots, API responses, or logs.

Deliverable: AC-6(10) test record with date, tester, systems tested, actions attempted, results, and evidence attachments. ¹

6) Operationalize: approval criteria, reviews, and revocation triggers

Write and run the operating process auditors expect:

• Approval criteria: What qualifies someone for privileged access; required training; MFA requirements; ticketing evidence.
• Provisioning steps: How roles are granted; who approves; where the record is stored.
• Review cadence: Periodic access reviews focused on privileged roles and accounts.
• Revocation triggers: Termination, role change, contract end, extended leave, incident response containment.

This aligns directly with the control intent and is a common evidence request in FedRAMP packages. ²

7) Manage exceptions explicitly (and make them rare)

You will have edge cases: legacy platforms, break-glass accounts, vendor-managed tools. Handle them with:

• Documented exception request, reason, compensating controls, expiration date, and approving authority.
• Compensating controls like heightened monitoring, narrower scope, or supervised sessions.
• A plan to remediate the exception (system replacement, migration, feature enablement).

Practical reality: Unbounded “temporary” exceptions often become permanent privileged backdoors. Treat exception aging as a control. ¹

Required evidence and artifacts to retain

Maintain a tidy evidence set that matches how assessors test access controls.

• Privileged Function Catalog (what counts as privileged)
• Role/Group design documentation (RBAC/ABAC mapping; role descriptions; owners)
• Access request and approval records for privileged role grants (ticket exports, workflow approvals)
• Provisioning logs (IdP audit logs, IAM change logs)
• Privileged access reviews (review outputs, sign-offs, remediation actions)
• Deprovisioning evidence (termination/transfer tickets, removed group membership logs)
• Negative test results showing non-privileged users are blocked
• Exception register with approvals, compensating controls, and expiry tracking ²

If you use Daydream to manage third-party risk and access governance workflows, store access approvals, exceptions, and review outcomes in one place so you can answer “show me the decision and who authorized it” without stitching evidence across chat, email, and multiple ticket queues. ²

Common exam/audit questions and hangups

Expect these questions, and prepare crisp answers with artifacts:

• “Define privileged functions for this system.” Provide the catalog entry and the permission mapping. ¹
• “Show me that a standard user cannot do X.” Provide negative test evidence and current configuration screenshots or policy exports. ¹
• “Who can grant admin?” Show the admin-role assignment policy and the list of authorized grantors. ¹
• “How do you review privileged access?” Produce review records and remediation follow-through. ²
• “What about service accounts and automation?” Show how non-human identities are permissioned, rotated, and constrained. ¹

Frequent implementation mistakes and how to avoid them

Mistake	Why it fails AC-6(10)	How to avoid it
Privileged functions not enumerated	Testing becomes subjective; assessors find missed admin paths	Maintain a Privileged Function Catalog tied to permissions/APIs 1
Relying on policy/training	Doesn’t prevent execution	Enforce via RBAC/ABAC/PAM; require authorization checks at execution time 1
“Shared admin” accounts	No accountability; harder to prove non-privileged users are blocked	Require named admin identities; restrict shared/break-glass to controlled scenarios 1
CI/CD pipelines over-permissioned	A non-privileged dev can trigger privileged deployments	Separate duties in pipelines; restrict deploy permissions; review runner/service identity scopes 1
Exceptions without expiry	Permanent bypass	Time-bound exceptions with compensating controls and tracked closure 1

Enforcement context and risk implications

No public enforcement cases were provided for this specific requirement in the supplied source catalog, so this page does not cite enforcement actions. Practically, AC-6(10) failures increase the likelihood of unauthorized configuration changes, privilege escalation, and undetected tampering with security controls (for example, disabling logs), which raises authorization risk during FedRAMP assessments and continuous monitoring submissions. ¹

Practical 30/60/90-day execution plan

First 30 days (establish control design and stop obvious gaps)

• Build the Privileged Function Catalog for in-scope systems. ¹
• Identify all privileged roles/groups/accounts (human and non-human) and assign role owners.
• Remove the most obvious “default admin” grants and document any necessary exceptions with compensating controls.
• Draft approval criteria, provisioning steps, and revocation triggers; route through governance for sign-off. ²

By 60 days (enforce consistently and generate repeatable evidence)

• Implement technical enforcement in priority systems (IdP, cloud IAM, CI/CD, logging platform). ¹
• Stand up PAM or time-bound elevation for the highest-risk admin actions where feasible. ¹
• Run your first negative test cycle and store results as assessment-ready artifacts. ¹

By 90 days (operate the control and prove it over time)

• Run a privileged access review and track remediation to closure. ²
• Implement monitoring/alerting for privileged role assignments and privileged function execution (where system logs support it). ¹
• Mature exception handling: aging, approvals, compensating controls, and planned remediation dates.
• Package evidence in a consistent format that maps to your SSP/control narrative expectations. ²

Frequently Asked Questions

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

Any action that changes security posture, access, monitoring, or production behavior should be treated as privileged (for example: granting permissions, disabling logs, changing firewall rules). Define the list for your environment in a Privileged Function Catalog and map each function to specific permissions. ¹

Do I need a PAM tool to satisfy this requirement?

No, but you do need technical enforcement that blocks non-privileged users from privileged actions. PAM or just-in-time elevation often makes the control easier to defend because it reduces standing privilege and produces clean evidence trails. ¹

How do we prove non-privileged users are prohibited during an assessment?

Keep negative test results that show a standard user cannot perform representative privileged actions across UI/API/CLI paths, plus the configuration or policy exports that implement the restriction. Pair that with access approvals and review records. ^{1 2}

What about service accounts and automation that must perform privileged actions?

Treat non-human identities as privileged when they can execute privileged functions, then constrain them tightly to required actions and scope. Maintain approvals, ownership, and change logs for those identities the same way you do for human admins. ¹

Can we satisfy AC-6(10) if engineers have admin in dev but not in prod?

Yes, if privileged functions in production are blocked for non-privileged users and the separation is enforced technically. Document environment-specific roles and show that production privileged roles are granted only through controlled approval and review. ¹

How should we handle break-glass access without failing the control?

Keep break-glass accounts limited, protected with strong authentication, and governed by strict procedures and logging. Document who can use them, under what conditions, and how you review usage and rotate credentials after use. ¹

Footnotes

1. NIST Special Publication 800-53 Revision 5

2. FedRAMP documents and templates