CMMC Level 2 Practice 3.13.3: Separate user functionality from system management functionality

CMMC Level 2 Practice 3.13.3 requires you to keep everyday user actions separate from system management actions by limiting administrative functions to authorized roles, accounts, and interfaces. Operationalize it by removing admin rights from standard users, using dedicated admin accounts and management consoles, and retaining evidence that this separation is enforced and monitored. ¹

Key takeaways:

• Enforce strict role separation: standard users do standard work; admins administer systems, with distinct accounts and access paths. ¹
• Make separation provable: retain account inventories, privileged access group memberships, and configuration screenshots/exports showing admin functions are restricted. ²
• Expect assessor focus on exceptions: shared admin accounts, local admin on endpoints, and “temporary” elevation without tickets are common failure points. ²

CMMC Level 2 Practice 3.13.3: separate user functionality from system management functionality requirement is a practical “blast radius” control. If a normal user account can perform administrative actions, then a routine phishing compromise can turn into domain-wide impact. The requirement pushes you to build a clean boundary between (1) business productivity actions (email, documents, engineering tools) and (2) system management actions (creating accounts, changing security settings, managing logs, altering configurations).

For a Compliance Officer, CCO, or GRC lead, the fastest path to readiness is to translate this into a small set of auditable decisions: which roles are privileged, where privileged actions can be performed, which accounts are allowed to perform them, and how you prevent privileged actions from happening through normal user paths. Your goal is not perfection; your goal is enforced separation that you can demonstrate consistently across the CUI boundary and supporting infrastructure.

CMMC Level 2 aligns to NIST SP 800-171 Rev. 2 for this practice, and CMMC assessments will look for implemented controls and evidence, not policy-only statements. ^{1 3}

Regulatory text

Excerpt (provided): “CMMC Level 2 practice mapped to NIST SP 800-171 Rev. 2 requirement 3.13.3 (Separate user functionality from system management functionality).” ¹

Operator interpretation: You must design your environment so that normal user capabilities (daily work) are separated from system management capabilities (administration). In practice, that means privileged functions are limited to explicitly authorized administrators, performed through approved admin interfaces, using dedicated privileged accounts or roles, and blocked from standard user contexts. ¹

What an assessor needs to see: a working boundary (technical enforcement) plus proof (repeatable evidence) that privileged actions are not available to normal users and are controlled by role-based access and configuration. ²

Plain-English requirement interpretation (what “separate” means)

Separation is about where admin actions happen and who can do them:

• Who: Only authorized admin roles can perform management tasks (identity, configuration, security tooling, system changes). ¹
• Where: Admin tasks occur in approved management planes (admin consoles, jump hosts, privileged access workstations), not from everyday user workstations or user sessions.
• How: Admin actions require elevated privileges that are not present in standard user accounts (no standing admin on daily accounts).

A clean implementation often includes:

• Dedicated admin accounts (separate from email/browsing accounts).
• Group-based privilege assignment (central directory roles).
• Privileged access workflows (ticketed elevation; time-bounded where feasible).
• Admin interfaces restricted by network segmentation or device compliance.

Who it applies to (entity and operational context)

This applies to organizations pursuing CMMC Level 2 where CUI exists in scope, including the supporting systems that store, process, or transmit that CUI and the security stack that protects them. ^{3 2}

Typical in-scope contexts:

• Windows/macOS endpoints used to handle CUI
• Identity providers / directory services
• Servers hosting CUI workloads
• Cloud tenants used for CUI (management planes and admin portals)
• Security tooling (EDR, SIEM, email security) where admin control can change detection and protection

Third parties matter here too: if an MSP or SaaS admin can manage your environment, you need separation on their access paths (named accounts, least privilege, restricted consoles) and evidence that you control it.

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

Use the steps below as an implementation checklist you can hand to IT and verify with evidence.

Step 1: Define “system management functionality” for your environment

Create a short list of privileged functions that qualify as system management, such as:

• Create/disable accounts, reset MFA
• Change firewall rules, security baselines, EDR policies
• Modify audit/log settings, log retention destinations
• Install software system-wide, modify kernel/system services
• Manage virtualization/hypervisor settings, cloud IAM changes

Document this list in your SSP/control narrative so the boundary is explicit. ¹

Step 2: Inventory privileged roles, accounts, and administrative interfaces

Build an inventory that covers:

• Privileged directory groups (Domain Admins, Server Admins, Cloud Admin roles)
• Local admin assignments on endpoints and servers
• Service accounts with elevated permissions
• Break-glass accounts
• Admin consoles/management planes (IdP admin portal, MDM console, EDR console, firewall UI)

Your inventory should identify which assets are in the CUI boundary. ²

Step 3: Enforce separation of accounts (daily user vs admin)

Minimum defensible pattern:

• Each admin has a standard user account for daily work.
• Each admin has a separate privileged account for admin tasks.
• Privileged accounts do not have email, general web browsing, or routine collaboration access enabled unless documented and justified.

If your environment supports it, require stronger authentication and tighter conditional access on privileged accounts than on standard accounts.

Step 4: Remove standing admin rights from standard users and standard endpoints

Controls to implement (as applicable):

• Remove users from local administrators on workstations.
• Use controlled elevation (admin prompts require privileged credentials).
• Prevent “shadow admin” paths (developer tools, remote management agents, hardcoded credentials).

Treat “temporary admin” as a workflow, not an informal Slack request. If you allow exceptions, require documented approval and an expiration path.

Step 5: Restrict where admin actions can be performed

Common, assessable patterns:

• Admin actions only from hardened admin devices (Privileged Access Workstations) or controlled jump hosts.
• Management planes only reachable from restricted network segments or via VPN with device posture checks.
• Block admin portal access from unmanaged devices.

This step often produces strong assessor confidence because it shows separation even if a privileged credential is exposed.

Step 6: Implement logging and review for privileged activity

3.13.3 is about separation, but separation must be detectable when it fails:

• Log privilege assignments and changes (group membership, role grants).
• Log admin console access.
• Review privileged access changes on a cadence you can execute consistently.

Tie the evidence to your incident response and configuration management processes where relevant. ¹

Step 7: Make it repeatable with a control owner and recurring evidence capture

Assign an operational owner (IT/Security) and a compliance owner (GRC) and define what gets captured and when. A lightweight approach is to schedule recurring exports/screenshots from:

• Directory privileged groups and role assignments
• Endpoint local admin reports
• Cloud IAM role assignments
• Admin console access logs or audit events

If you use Daydream to manage CMMC readiness, map 3.13.3 directly to the operating procedure and set up recurring evidence requests so you are never scrambling right before assessment. ²

Required evidence and artifacts to retain

Aim for evidence that answers: “Who can administer, from where, and how do you know it stays that way?”

Core artifacts (recommended):

• Privileged account list (named users; separate admin accounts identified)
• Role/group membership exports for privileged groups (dated)
• Endpoint local admin reports (or MDM configuration showing standard users are not local admins)
• Screenshots/exports of key admin restrictions (conditional access for admin roles; jump host requirement; management network ACLs)
• Tickets/approvals for exceptions and time-bounded elevation
• SSP/control narrative describing the separation design and scope mapping ¹
• Evidence collection schedule and last-completed records ²

What “good” looks like: evidence is consistent, time-stamped, and aligns to the system boundary for CUI.

Common exam/audit questions and hangups

Assessors and internal auditors tend to probe these areas (be ready with proof):

1. Do admins have separate accounts for admin tasks? Show me. Provide account naming convention and directory exports.
2. Who has local admin on endpoints? Why? Have a report and documented exceptions.
3. Can a standard user install software or disable security tools? Demonstrate endpoint policy enforcement and EDR tamper protection settings where applicable.
4. How do you prevent admin access from unmanaged devices? Show conditional access/device compliance policies or network segmentation.
5. What about third-party administrators (MSP/SaaS support)? Show named accounts, role restrictions, and approved access paths.

Hangup to avoid: “We have a policy that says admins are separate” with no technical enforcement or evidence.

Frequent implementation mistakes (and how to avoid them)

Mistake	Why it fails 3.13.3	Fix
Shared admin accounts	No accountability; user/admin separation collapses	Require named admin accounts; limit shared accounts to break-glass with strict controls
Standing local admin for most users	Standard user functionality includes admin capability	Remove local admin; use controlled elevation with approvals
Admins browse email/web on privileged accounts	Increases likelihood of admin credential compromise	Separate daily and privileged accounts; restrict privileged account app access
“Temporary admin” granted informally	Exceptions become permanent; no evidence trail	Ticketed workflow with expiration and review
No recurring evidence	You cannot prove control operation	Schedule exports/reports; centralize in GRC system 2

Enforcement context and risk implications

No specific public enforcement cases were provided for this practice in the supplied source catalog. What you can say precisely: CMMC is implemented via DoD’s CMMC Program and codified in 32 CFR Part 170, and Level 2 aligns to NIST SP 800-171 Rev. 2 practices, including 3.13.3. ^{3 2 1}

Operational risk if you fail separation:

• Higher probability that a compromised user account becomes an administrative compromise.
• Increased chance of attackers disabling logging/EDR, creating persistence, and expanding laterally.
• Assessment risk: weak separation is easy to test and hard to explain away.

Practical 30/60/90-day execution plan

Use this as an operator’s runbook. Adjust to your environment size and tooling.

First 30 days (stabilize scope and stop obvious failures)

• Define privileged functions and document the boundary in your SSP/control narrative. ¹
• Export privileged group/role membership lists and identify all privileged accounts.
• Identify and remediate shared admin accounts where feasible; document break-glass handling.
• Pull local admin rights inventory from endpoints; document top exception categories.
• Stand up an evidence folder structure and define what you will collect each cycle. ²

Days 31–60 (enforce separation technically)

• Implement separate admin accounts for admins who still use one account.
• Remove standard users from local admin; implement controlled elevation workflows.
• Restrict admin console access paths (jump host/PAW, network restrictions, or conditional access).
• Implement or tighten logging for privileged role changes and admin console activity.

Days 61–90 (operationalize and make it assessable)

• Run an internal spot-check: sample users and show they cannot perform admin tasks; sample admins and show separation.
• Formalize exception handling (approval, duration, review).
• Establish recurring evidence capture and assign owners; test that evidence is complete for a full period. ²
• If you use Daydream, connect the control to scheduled evidence requests and map each artifact to 3.13.3 so assessment prep becomes a reporting exercise, not a scavenger hunt. ²

Frequently Asked Questions

Do we need dedicated admin accounts for every administrator to meet 3.13.3?

Dedicated admin accounts are the clearest way to demonstrate separation and are commonly expected in audits. If you use just-in-time elevation instead, you still need proof that standard user sessions cannot perform admin functions. ¹

Can engineers keep local admin on their laptops if they “need it for development”?

Treat this as an exception that needs written justification, documented scope, and compensating controls. A safer pattern is controlled elevation or dedicated admin workstations for privileged actions.

How does this apply to cloud services like M365, AWS, or Azure?

Cloud admin portals are system management interfaces, so restrict who can access them and from which devices/locations. Keep role assignment exports and conditional access or network restriction evidence aligned to your CUI boundary. ¹

Are service accounts in scope for this requirement?

Yes, if a service account has administrative permissions, it represents system management capability. Track privileged service accounts explicitly and restrict where they can be used (for example, only from approved hosts).

What evidence is strongest for assessors?

Time-stamped exports of privileged role/group membership, endpoint local admin reports, and configurations that restrict admin interfaces are consistently persuasive. Pair them with a short control narrative that explains the separation design. ²

We outsourced IT to a third party. How do we show separation?

Require named admin accounts for the third party, restrict their access paths (VPN, jump host, device requirements), and retain role membership and access logs. Contract terms help, but assessors still want technical enforcement and evidence. ²

Footnotes

1. NIST SP 800-171 Rev. 2

2. DoD CMMC Program Guidance

3. 32 CFR Part 170