CMMC Level 2 Practice 3.1.7: Prevent non-privileged users from executing privileged functions and capture the execution of

To meet cmmc level 2 practice 3.1.7: prevent non-privileged users from executing privileged functions and capture the execution of requirement, you must (1) technically block standard users from running admin-level actions and (2) log every privileged action with enough detail to prove who did what, when, where, and how. Implement role-based access, privileged access workflows, and centralized audit logging with regular review. ¹

Key takeaways:

• Block privileged functions at the system control layer (RBAC, sudo/UAC, cloud IAM), not by policy alone. ¹
• Define “privileged function” by platform and capture execution logs centrally with identity, action, target, and outcome. ¹
• Package evidence so an assessor can trace a privileged action from authorization to execution to log retention. ²

Practice 3.1.7 is an access control requirement mapped from CMMC Level 2 to NIST SP 800-171 Rev. 2. It has two operator jobs: prevent non-privileged users from executing privileged functions, and capture the execution of those functions so you can prove control operation during assessment. ¹

In a CMMC scope discussion, this requirement touches almost everything that can “do admin things”: endpoints, servers, network devices, hypervisors, cloud control planes, identity providers, databases, and security tools. If a standard user can install software, change security settings, create accounts, modify logs, disable EDR, change firewall rules, or grant permissions, you have a 3.1.7 exposure. If those actions occur but you cannot produce logs that show the actor and action details, you have the second half of the exposure. ¹

Assessors typically look for two characteristics: (1) technical enforcement (not just “users are told not to”), and (2) consistent logging that is centrally retained and reviewable. Your fastest path is to treat 3.1.7 like a small program: define privileged functions, define who may execute them, enforce it in IAM and OS controls, and standardize logging and evidence. ³

Regulatory text

Requirement (excerpt): “CMMC Level 2 practice mapped to NIST SP 800-171 Rev. 2 requirement 3.1.7 (Prevent non-privileged users from executing privileged functions and capture the execution of).” ¹

What the operator must do:

1. Prevent execution: Configure systems so non-privileged (standard) users cannot run privileged functions. This must be enforced by access control mechanisms (OS, application, database, network device, or cloud platform permissions). ¹
2. Capture execution: Configure audit logging to record privileged function execution events with enough context to support accountability and investigation. Store those logs in a place where they are protected from tampering and can be produced during assessment. ¹

---

Plain-English interpretation

“Privileged functions” are actions that change security posture, change access, change system configuration, or bypass controls. 3.1.7 requires you to ensure standard users can’t do those actions, and that every time someone with privilege does them, you have a reliable record.

A simple test: pick a standard user account. Can it install software, stop security agents, add local admins, change audit settings, create new IAM users, alter firewall rules, or modify production configuration? If yes, your prevention controls are weak. Then pick an admin action that actually happened recently. Can you show a log entry that ties the action back to a named identity and device, with timestamp and outcome? If no, your capture controls are weak. ¹

---

Who it applies to (entity and operational context)

Entities: Defense contractors and other federal contractors handling CUI that must meet CMMC Level 2. ²

Operational scope: Any system component in the CMMC assessment boundary where privileged actions can occur, including:

• Identity systems (AD/Azure AD/Entra ID, Okta), MFA, and PAM tooling
• Endpoints and servers (Windows/macOS/Linux), including build servers and admin jump hosts
• Network/security infrastructure (firewalls, switches, VPN, EDR consoles)
• Cloud management planes (AWS/GCP/Azure IAM, resource policies, logging configuration) ¹

---

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

Step 1: Write the “3.1.7 control card” (make ownership and scope explicit)

Create a one-page runbook that includes:

• Control objective: Block privileged functions for non-privileged users; log privileged function execution.
• Owner: Name the accountable role (often IAM lead + Security Operations).
• In-scope platforms: OS, IAM, cloud, network devices, key business apps.
• Exception rules: Break-glass, emergency change process, and approval requirements. ²

This is operational glue. Without it, you end up with scattered configs and no evidence narrative.

Step 2: Define “privileged functions” for your environment

Create a practical list by platform. Example categories (adapt, don’t over-theorize):

• Identity & access: create/disable accounts, reset MFA, grant roles, modify group membership
• System security: change audit policy, disable EDR, modify firewall rules, change encryption settings
• Configuration & software: install/uninstall software, change system services, modify registry/system files
• Data plane admin: database admin actions, storage bucket policy changes, key management changes ¹

Output artifact: a “Privileged Function Register” that maps each function category to the system where it’s enforced and logged.

Step 3: Enforce least privilege with technical controls (prevention)

Implement prevention by control layer:

Endpoints/servers

• Remove local admin rights from standard users; use separate admin accounts for admin work.
• Require elevation for admin tasks (UAC/sudo) and restrict who can elevate.
• Block “admin by application” patterns (apps that run as admin for all users). ¹

Identity platforms

• Use role-based access control (RBAC).
• Restrict role assignment (only a limited set of admins can grant admin roles).
• Protect privileged groups with tighter approval and monitoring. ¹

Cloud

• Enforce IAM roles with least privilege; restrict policy changes to a small admin set.
• Separate duties: deploy roles vs approve roles; production admin vs developer. ¹

Step 4: Implement privileged access workflows (how admins work day to day)

Prevention fails when teams share admin credentials or “temporarily” grant admin rights and forget to remove them. Put a workflow in place:

• Use named admin accounts (no shared admins).
• Require MFA for privileged sessions where your platform supports it.
• Use just-in-time elevation or time-bound group membership where feasible.
• Maintain break-glass accounts with strict storage and documented use criteria. ¹

Step 5: Capture execution with centralized audit logging (capture)

Decide what “capture” means in practice: logs must identify the actor and the action, and you must be able to produce them.

Minimum logging fields to target:

• Actor identity (user/service account), source host, and authentication context
• Privileged action performed (command/API call/config change)
• Target object (host, policy, group, database, resource)
• Timestamp and outcome (success/failure) ¹

Implementation moves:

• Turn on OS audit logs for privileged commands and group membership changes.
• Enable admin activity logs in your IAM and cloud platforms.
• Forward logs to a central repository (SIEM or log platform) with access controls to prevent tampering. ¹

Step 6: Define review and response (prove it operates)

Auditors will ask how you know the control is working.

• Create a recurring “privileged activity review” task owned by Security or IAM.
• Track findings as tickets through closure (misconfigured permissions, suspicious admin actions, missing logs). ²

Daydream can help here by turning 3.1.7 into an assignable control card with an evidence checklist and recurring health checks, so you do not rebuild the same audit binder every cycle. ²

---

Required evidence and artifacts to retain

Keep evidence that proves both prevention and capture:

Design/administrative artifacts

• Access control policy and standards addressing privileged access (scoped to CUI systems) ¹
• Privileged Function Register (what functions are privileged, by system)
• Role/Group definitions for privileged roles and membership rules

Configuration evidence (screenshots/exports)

• OS configuration showing standard users are not local admins; sudoers/UAC policies
• IAM role assignments and restricted admin roles
• Cloud audit logging settings enabled for admin actions ¹

Operational evidence

• Sample log extracts showing privileged function execution (with actor/action/target/outcome)
• Tickets/approvals for time-bound elevation or admin role changes
• Review records: sign-offs, findings, remediation tickets and closure proof ²

Retention location

• A controlled evidence repository with access controls and clear naming conventions aligned to 3.1.7. ²

---

Common exam/audit questions and hangups

Expect these, and prepare your answers with evidence pointers:

1. “Define privileged function for your environment.” Assessors want your list, not a generic definition. Bring the Privileged Function Register. ¹
2. “Show me a standard user account cannot do X.” Have a test account and a scripted demonstration for a few key actions (install software, modify security settings, change IAM roles). ¹
3. “Show me logs for an admin change.” Be ready to pull an example from SIEM for a recent privileged action and explain the fields. ¹
4. “Who can grant privilege, and how is that controlled?” Show RBAC, approvals, and tickets. ¹
5. “Can admins erase or modify the logs?” Demonstrate separation of duties and restricted access to logging systems. ¹

---

Frequent implementation mistakes and how to avoid them

• Mistake: Relying on policy (“users must not…”) without technical enforcement. Fix: remove local admin, enforce RBAC, require elevation. ¹
• Mistake: Shared admin accounts. Fix: named admin accounts and documented break-glass only. ¹
• Mistake: Logging is on, but not centralized or searchable. Fix: forward logs to a central platform and test retrieval during a tabletop. ¹
• Mistake: Privileged actions in SaaS/cloud are missed. Fix: include cloud control plane and SaaS admin logs in scope, not just Windows event logs. ¹
• Mistake: No operational cadence. Fix: assign an owner, define trigger events (new system, new admin, new role), and run control health checks. ²

---

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement. The practical risk is straightforward: if standard users can perform privileged actions, they can disable controls or expand access. If privileged actions are not logged, you lose traceability during incident response and cannot support an assessor’s determination that the practice is met. CMMC Level 2 assessments are performed against the CMMC program structure described in 32 CFR Part 170 and DoD program guidance. ^{2 3}

---

A practical 30/60/90-day execution plan

First 30 days (stabilize scope and stop obvious gaps)

• Assign an owner and publish the 3.1.7 control card (objective, systems, evidence, exceptions). ²
• Inventory privileged roles and groups across IAM, endpoints, servers, and cloud control planes. ¹
• Remove local admin from standard user populations where feasible; identify required exceptions. ¹
• Turn on and validate logging for key privileged events in at least one representative system per platform category. ¹

Next 60 days (standardize enforcement and logging)

• Publish the Privileged Function Register and map each function to an enforcing control and log source. ¹
• Implement a privileged access workflow (request/approve/time-bound access) for admin role grants. ¹
• Centralize logs, restrict access to log storage, and test log retrieval for privileged events. ¹

Next 90 days (prove sustained operation)

• Run a control health check: sample systems, verify standard users cannot execute privileged functions, and verify logs are captured. Track remediation to closure. ²
• Establish recurring reviews of privileged group membership and privileged activity logs with documented sign-off. ¹
• Build your assessment-ready evidence bundle in one place (policy, configs, logs, tickets, review records). ²

Frequently Asked Questions

What counts as a “privileged function” for 3.1.7?

Treat any action that changes security posture, access, or system configuration as privileged. Document your list by platform (OS, IAM, cloud, network) and map each item to how you prevent and log it. ¹

Do we need a PAM tool to satisfy 3.1.7?

A dedicated PAM tool can help, but the requirement is satisfied by effective technical enforcement and logging. If you can enforce least privilege and reliably capture privileged execution across in-scope systems, you can meet the intent without a specific product. ¹

How do we show “capture the execution” during an assessment?

Provide log samples for real privileged events (role assignment, policy change, software install) that include actor, action, target, timestamp, and outcome, plus evidence that logs are centrally retained and protected. ¹

Are service accounts covered?

Yes. Service accounts can execute privileged functions via APIs, scripts, and automation, so they need least-privilege permissions and logging of their privileged actions. ¹

What about emergency admin access (break-glass)?

Allow it, but control it with strict criteria, restricted credential storage, and after-action logging and review. Keep tickets or incident records that explain why the account was used and what actions were taken. ¹

What evidence fails most often for 3.1.7?

Teams often have partial logs or logs that cannot be correlated to a person or system. Fix this by testing log retrieval for specific privileged events and documenting the query, result, and retention location in your evidence bundle. ²

Footnotes

1. NIST SP 800-171 Rev. 2

2. 32 CFR Part 170

3. DoD CMMC Program Guidance