AC-6(8): Privilege Levels for Code Execution

AC-6(8) requires you to prevent specified software from running with higher privileges than the user who launched it (for example, blocking setuid-style elevation or forced “Run as Administrator” execution paths). To operationalize it, define the in-scope software, enforce non-elevated execution through OS and application controls, and keep proof that elevation is technically prevented and monitored. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Key takeaways:

• Define exactly which software is in scope for “no higher privilege execution,” then make that scope auditable. (NIST SP 800-53 Rev. 5 OSCAL JSON)
• Enforce the rule with technical guardrails (application control, privilege management, and configuration) rather than policy statements. (NIST SP 800-53 Rev. 5)
• Retain evidence that prevention works in practice: configurations, test results, and exception approvals with compensating controls. (NIST SP 800-53 Rev. 5)

AC-6(8): privilege levels for code execution requirement sits inside the broader “least privilege” family. The operational goal is simple: users should not be able to launch software in a way that silently or automatically runs that code with more privilege than they have. If a standard user can trigger elevated execution, you have created an easy path for malware, misuse, and lateral movement.

This control enhancement is intentionally parameterized in NIST language (“the following software”), which means your biggest early decision is scoping: which binaries, scripts, interpreters, agents, installers, administrative tools, or line-of-business applications must be prevented from executing above the invoker’s privilege level. In practice, teams often start with the highest-risk execution paths (admin tools, scripting engines, package managers, remote management tooling, and custom in-house executables) and expand as they mature.

For a CCO or GRC lead, success looks like: a clear scope statement, an implementation standard that IT can execute, and recurring evidence that prevention is enforced across endpoints, servers, and managed workloads, with tightly governed exceptions.

Regulatory text

Control statement (excerpt): “Prevent the following software from executing at higher privilege levels than users executing the software: {{ insert: param, ac-06.08_odp }}.” (NIST SP 800-53 Rev. 5 OSCAL JSON)

What the operator must do

1. Select and document the “following software” (the parameter). You must explicitly list the software categories, titles, or execution environments that are in scope for this prevention requirement. (NIST SP 800-53 Rev. 5 OSCAL JSON)
2. Implement technical prevention. Put controls in place so that when a user launches in-scope software, it cannot run as a more privileged account unless you have an approved exception path with compensating controls. (NIST SP 800-53 Rev. 5)
3. Prove it works and keep evidence. You need assessment-ready proof: configuration artifacts, testing results, and monitoring outputs demonstrating the control operates as designed. (NIST SP 800-53 Rev. 5)

Plain-English interpretation (what AC-6(8) means)

AC-6(8) is an anti-elevation-by-design requirement. If a user is logged in as a standard user, they should not be able to start a program that ends up running with admin/root/System privileges through default settings, insecure file permissions, legacy “setuid” patterns, permissive service wrappers, or auto-elevate application behavior.

This does not mean “nobody can run admin software.” It means you control elevation. Elevated execution should happen only through approved mechanisms (for example, privileged access management, just-in-time elevation, or a controlled service account) with logging, approvals, and scope limits.

Who it applies to (entity and operational context)

AC-6(8) is relevant anywhere you are aligning to NIST SP 800-53 Rev. 5, including:

• Federal information systems and contractor systems handling federal data. (NIST SP 800-53 Rev. 5 OSCAL JSON)
• Endpoints (workstations used by staff, developers, admins).
• Servers (Windows/Linux hosts, virtual machines, jump hosts).
• Cloud workloads (IaaS instances, managed nodes, container hosts).
• DevOps and CI/CD runners where code execution is constant and privilege boundaries are frequently misconfigured.

Operationally, this control lands on teams that manage identity and access, endpoint/server hardening, and application control. As the compliance owner, you coordinate scope, exceptions, evidence, and testing.

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

Step 1: Define the parameter (“the following software”)

Create a scoped list that is specific enough to be testable. Your options:

• By name/publisher: specific admin tools, remote access tools, or scripting engines.
• By type: installers, package managers, interpreters (PowerShell, Python), macro-enabled office apps, remote management agents.
• By location/path: directories where elevated executables often live (admin tool paths).
• By risk tier: Tier 1 “must never auto-elevate,” Tier 2 “controlled elevation allowed.”

Deliverable: an AC-6(8) scope statement that an assessor can read and a technician can implement. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Step 2: Map allowed elevation paths (and ban everything else)

Document how elevated execution is supposed to happen in your environment:

• Named admin accounts vs. separate privileged roles.
• Just-in-time elevation workflows.
• Approved service accounts and where they can run.
• CI/CD runner permissions model.

Then explicitly state what is forbidden:

• Auto-elevation without a prompt/approval.
• Executables marked to “always run as admin” for standard users.
• setuid/setgid binaries outside an approved baseline.
• User-writable paths that run in privileged contexts (common service misconfig).

Deliverable: Privilege execution standard aligned to least privilege. (NIST SP 800-53 Rev. 5)

Step 3: Implement technical prevention controls

Pick controls that match your platforms. Assessors usually look for technical enforcement, not intentions.

Common enforcement patterns:

• Application control / allowlisting: Only approved binaries can run elevated; block unknowns from privileged contexts.
• Privilege management tooling: Prevent users from launching targeted software as admin; broker elevation with policy and logs.
• OS hardening baselines:
  • Remove or tightly control setuid/setgid usage on Unix-like systems.
  • Restrict “Run as administrator” and local admin membership on Windows endpoints.
• Service and scheduled task hygiene: Ensure services/tasks running as SYSTEM/root cannot be modified by standard users (file permissions, registry permissions, task definitions).
• Developer controls: Prevent build/test tools from running with more privilege than necessary; isolate privileged build steps inside controlled runners.

Deliverable: Configuration baselines and enforcement policies (endpoint, server, and cloud images) that prevent higher-privilege execution for in-scope software. (NIST SP 800-53 Rev. 5)

Step 4: Test the control (make it auditable)

Write test cases that mirror real abuse paths:

• Attempt to execute in-scope software as a standard user and verify it fails or runs non-elevated.
• Attempt to modify a privileged service’s executable path from a standard account.
• Attempt to run scripts/interpreters in a privileged context from user-writable directories.

Deliverable: Test plan + results tied to the scoped list from Step 1. (NIST SP 800-53 Rev. 5)

Step 5: Build an exception process with compensating controls

Some software legitimately needs elevation (device management agents, certain security tools, specialized engineering apps). Your exception process should require:

• Business justification.
• Time bound approval and owner.
• Compensating controls (allowlisting, code signing, restricted execution scope, enhanced logging).
• Periodic revalidation.

Deliverable: Exception register for AC-6(8), with approvals and compensating controls documented. (NIST SP 800-53 Rev. 5)

Step 6: Continuous monitoring and recurring evidence

Operationalize recurring checks:

• Configuration drift detection on endpoints/servers.
• Alerts on new setuid binaries, new privileged services, or policy changes.
• Review of elevation events and blocked execution attempts for in-scope software.

Deliverable: Recurring evidence pack (exports, reports, screenshots, or system-generated logs) that shows ongoing enforcement. (NIST SP 800-53 Rev. 5)

Required evidence and artifacts to retain

Keep evidence that a third party assessor can independently evaluate:

Design artifacts

• AC-6(8) scoped software list (“the following software” parameter) with versioning and owner. (NIST SP 800-53 Rev. 5 OSCAL JSON)
• Privilege execution standard (how elevation is allowed, how it is prevented). (NIST SP 800-53 Rev. 5)

Implementation artifacts

• Application control policies / rulesets (exported configs).
• Privilege management policy configurations.
• OS baseline settings (GPOs, configuration management code, golden image definitions).

Validation artifacts

• Test plan, test scripts/commands, and test results mapped to in-scope software. (NIST SP 800-53 Rev. 5)
• Evidence of remediation for failed tests (tickets, change records).

Operations artifacts

• Exception register with approvals, compensating controls, and expiration dates. (NIST SP 800-53 Rev. 5)
• Monitoring reports: blocked executions, elevation attempts, privileged service changes.

Tip for fast audit readiness: In Daydream, map AC-6(8) to a named control owner, the implementation procedure, and the recurring evidence artifacts so evidence collection is consistent across quarters. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Common exam/audit questions and hangups

Assessors tend to probe the same weak spots:

1. “What software is included in ‘the following software’?” If you cannot name it, the control is not assessable. (NIST SP 800-53 Rev. 5 OSCAL JSON)
2. “Show me prevention, not detection.” Logs of admin use do not satisfy “prevent” by themselves. They may support monitoring, but you still need enforcement. (NIST SP 800-53 Rev. 5 OSCAL JSON)
3. “Prove standard users can’t modify privileged execution paths.” Expect requests for service/task permissions and file ACL evidence.
4. “How do exceptions work?” Weak exception governance is a common finding: no expiration, no compensating controls, no review trail. (NIST SP 800-53 Rev. 5)

Frequent implementation mistakes (and how to avoid them)

Mistake	Why it fails AC-6(8)	Fix
Treating AC-6(8) as a policy-only control	“Prevent” implies technical enforcement	Implement application control and privilege management guardrails; keep configs as evidence. (NIST SP 800-53 Rev. 5)
Scoping too broadly (“all software”) with no technical path	Creates an untestable requirement and endless exceptions	Start with a risk-based list of software; expand iteratively with change control. (NIST SP 800-53 Rev. 5 OSCAL JSON)
Allowing installers/updaters to run elevated from user-writable locations	Common escalation path	Require signed installers, restrict execution locations, and enforce allowlisting rules.
Local admin sprawl on endpoints	Makes prevention moot because users already have high privilege	Reduce local admin membership; use controlled elevation mechanisms.
No evidence of ongoing operation	Control passes once, fails later due to drift	Add drift monitoring and recurring evidence exports tied to AC-6(8). (NIST SP 800-53 Rev. 5)

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this specific requirement, so you should treat AC-6(8) primarily as an assessment and breach-risk control tied to least privilege expectations in NIST SP 800-53 Rev. 5. (NIST SP 800-53 Rev. 5)

Operational risk is straightforward: if in-scope software can execute at higher privilege than the invoker, attackers and insiders can turn a low-privilege foothold into a high-privilege outcome. That undermines your access control boundary and often accelerates system compromise.

A practical 30/60/90-day execution plan

First 30 days (scope + minimum viable enforcement)

• Assign a control owner and write the scoped list of “the following software” for AC-6(8). (NIST SP 800-53 Rev. 5 OSCAL JSON)
• Identify current elevation paths (local admin, sudo rules, service accounts, CI runners).
• Pick enforcement approach per platform (application control, privilege management, hardening baseline).
• Stand up an exception workflow with required fields and approval authority. (NIST SP 800-53 Rev. 5)

Days 31–60 (deploy + validate)

• Roll out prevention controls to a pilot group (admin tools + scripting engines are common first targets).
• Run test cases and capture results as evidence. (NIST SP 800-53 Rev. 5)
• Remediate failures: service permissions, misconfigured tasks, auto-elevate settings.
• Document compensating controls for approved exceptions.

Days 61–90 (scale + operationalize evidence)

• Expand coverage to additional business units, server tiers, and managed cloud nodes.
• Add continuous monitoring for policy drift and privileged execution changes.
• Establish recurring evidence collection (scheduled exports, dashboards, monthly control check tickets). (NIST SP 800-53 Rev. 5)
• In Daydream, attach the scope statement, configs, test results, and recurring evidence tasks directly to the AC-6(8) control record so audits pull from one system of record. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Frequently Asked Questions

What does “the following software” mean in AC-6(8)?

It is a parameter you must define for your environment, and it becomes the testable scope for the requirement. Document the list and keep it under change control so assessors can verify prevention for that specific software. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Does AC-6(8) ban all admin activity?

No. It requires you to prevent software from running at higher privilege than the invoker by default. You can still allow elevated execution through controlled mechanisms with approvals, constraints, and logging. (NIST SP 800-53 Rev. 5)

Are logs enough to satisfy “prevent”?

Logs support monitoring, but AC-6(8) calls for prevention. Keep configuration evidence showing the system blocks or restricts elevated execution for in-scope software, plus tests that demonstrate it. (NIST SP 800-53 Rev. 5 OSCAL JSON)

How should we handle software that must run as a service account?

Treat it as an explicit exception case with compensating controls: locked-down file permissions, allowlisting, restricted admin access to the service definition, and monitoring for changes. Keep the approval and the technical guardrails as evidence. (NIST SP 800-53 Rev. 5)

Does this apply to CI/CD pipelines and build runners?

Yes where code execution occurs and privilege boundaries matter. Define which build tools or scripts are in scope, then prevent developers from initiating runs that execute with more privilege than intended outside controlled runner configurations. (NIST SP 800-53 Rev. 5)

What evidence do assessors ask for most often?

A clear scoped list of covered software, the technical policy/config that enforces non-elevated execution, and test results proving a standard user cannot trigger elevated execution for that scope. Exceptions should show approvals and compensating controls. (NIST SP 800-53 Rev. 5)