CMMC Level 2 Practice 3.5.3: Use multifactor authentication for local and network access to privileged accounts and for

CMMC Level 2 Practice 3.5.3 requires you to enforce multifactor authentication (MFA) for privileged accounts when they access systems locally and over the network, and to prove it with assessor-ready evidence. Operationalize it by inventorying privileged accounts, routing all admin access through an MFA-enforced control plane, and capturing configuration, logs, and exceptions. ¹

Key takeaways:

• Scope MFA to privileged accounts across local and network access paths, not just VPN or email. ²
• “Implemented” is not enough; you need recurring evidence that MFA is enforced and exceptions are controlled. ³
• Assessors look for bypass routes (break-glass, service accounts, local admin, legacy protocols) and will test them. ²

If you handle Controlled Unclassified Information (CUI) under DoD contracting, CMMC Level 2 aligns to NIST SP 800-171 Rev. 2, and MFA for privileged access is a baseline expectation for reducing account takeover and lateral movement risk. Practice 3.5.3 is narrow in wording but broad in operational impact: it touches identity providers, endpoints, remote access, server administration, and how you run emergency access.

Teams commonly “check the box” by turning on MFA for VPN or for a subset of admins, then miss local console access, cached credentials, shared admin accounts, non-interactive privileged access, or admin tools that authenticate differently than end users. Those gaps show up fast in an assessment because privileged access paths are testable and often well-documented in enterprise tooling.

This page translates the requirement into an execution plan you can assign to IT and security teams immediately: define what counts as a privileged account, enumerate where privileged access happens, enforce MFA at the right choke points, and maintain evidence that an assessor can validate quickly. ⁴

Regulatory text

Requirement excerpt (as provided): “CMMC Level 2 practice mapped to NIST SP 800-171 Rev. 2 requirement 3.5.3 (Use multifactor authentication for local and network access to privileged accounts and for).” ¹

Operator interpretation: You must configure your environment so that privileged accounts cannot authenticate using only a single factor when administering systems either (1) locally (for example, console/RDP on the internal LAN to a server, direct workstation admin actions) or (2) over the network (for example, remote admin, VPN, VDI, SSH, hypervisor consoles). Your objective is enforceable control, not a policy statement. ²

Plain-English interpretation (what this really means)

• Privileged accounts include any account that can administer systems, manage security settings, manage identity, access audit logs, or otherwise bypass controls (domain admins, local administrators, cloud tenant admins, network device admins, security tool admins). If the account can change controls, treat it as privileged. ²
• Local access is not “offline only.” In practice, it includes admin actions taken directly on endpoints/servers and access at the console layer (including where the authentication happens on the device rather than via a central app gateway). ²
• Network access includes remote administrative access and any privileged access mediated by network services (VPN, remote management, admin portals, SSH, RDP, hypervisor management, cloud consoles). ²

Who it applies to (entity and operational context)

This applies to organizations seeking CMMC Level 2 that handle CUI in scope, including defense contractors and federal contractors handling CUI. ⁵

Operationally, it applies wherever privileged access touches your CMMC boundary:

• Corporate IT if it administers the CUI environment (identity, endpoint management, logging, patching).
• Managed service providers and other third parties that hold admin credentials or manage in-scope systems; their access method must enforce MFA and be provable. ¹

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

1) Define “privileged” in your environment (and write it down)

Create a short privileged account standard that includes:

• Privileged role categories (endpoint admin, server admin, network admin, cloud admin, security admin).
• Account types in scope: named admin accounts, shared admin accounts (preferably prohibited), break-glass, and third-party admin accounts.
• Where privileged access is permitted (approved admin workstations, jump hosts, PAM). ²

Deliverable: “Privileged Access & MFA Standard” mapped to CMMC Level 2 / NIST SP 800-171r2 3.5.3. ²

2) Inventory privileged accounts and privileged access paths

Build an inventory that an assessor can sample:

• Identity systems: AD/Azure AD/Entra, Okta, Google Workspace, local system accounts.
• Admin groups and roles: Domain Admins, Enterprise Admins, local Administrators via GPO, cloud tenant roles, firewall/switch/router admin roles.
• Access paths: VPN, bastion/jump host, RDP, SSH, remote management (e.g., vCenter, iDRAC/iLO), SaaS admin consoles, MDM/UEM consoles. ²

Tip: Include “shadow admin” routes like local admin passwords, built-in accounts, and legacy protocols that bypass modern auth. Assessors probe for these. ²

3) Choose the enforcement points that prevent bypass

You need MFA that cannot be bypassed by choosing a different admin tool. Common enforcement patterns:

• Central IdP enforcement for all privileged roles (conditional access requiring MFA).
• Privileged Access Management (PAM) or jump host that requires MFA before any admin session starts.
• Strong local admin controls (for example, requiring MFA for elevation via privileged workflows, restricting local logon, and limiting local admin membership). ²

Decision rule: If an admin can reach a target using a method that does not invoke MFA, you have not met the intent for that path. Document and close the gap or formally control the exception. ²

4) Implement MFA for privileged accounts across local and network access

Execution checklist (assignable tasks):

1. Turn on MFA for privileged roles in the IdP and require it for admin portals and management planes.
2. Require MFA on remote access used for administration (VPN/VDI/jump host) and ensure privileged sessions cannot originate from unmanaged devices unless explicitly approved.
3. Restrict direct admin logon to servers/workstations; force admin activity through the MFA-enforced path (jump host/PAM/admin workstation).
4. Harden break-glass: keep accounts highly restricted, monitored, and used only for emergencies with documented approvals.
5. Third-party admin access: require MFA through your control plane (federation, PAM, or controlled remote access) and block shared credentials. ¹

5) Build exception handling that survives an assessment

You will encounter systems that cannot support MFA directly (legacy network gear, embedded systems, lab equipment). Handle it with governance:

• Formal exception request with business justification, system owner, compensating controls, and expiration.
• Compensating controls examples: access only from jump host with MFA, network isolation, time-bound access, increased logging and alerting, removal of internet exposure, strict allowlists. ²

6) Prove ongoing operation (recurring evidence capture)

Assessments reward repeatable evidence. Set up a lightweight monthly or quarterly capture:

• Export privileged group membership and role assignments.
• Export MFA policy configuration and a screenshot or config file showing enforcement.
• Pull authentication logs showing MFA challenges for admin accounts.
• Review and sign off on exceptions and break-glass use. ⁶

Daydream note: this is where teams lose time. A tracker that maps 3.5.3 to control steps and schedules evidence collection prevents last-minute “screenshot hunts” and creates a clean assessor packet.

Required evidence and artifacts to retain

Keep evidence in a form an assessor can validate without interpreting tribal knowledge:

• Policy/standard: Privileged Access & MFA Standard; Access Control Policy section covering MFA for privileged access. ²
• Privileged account inventory: list of privileged groups/roles, owners, and where they exist (AD, cloud, SaaS). ²
• System configuration evidence: IdP conditional access/MFA settings for privileged roles; VPN/jump host MFA settings; PAM configuration where used. ²
• Logs: authentication logs demonstrating MFA for privileged access; admin session logs (jump host/PAM); break-glass usage logs. ²
• Exception register: approvals, compensating controls, and expiration dates for anything that cannot meet MFA directly. ¹
• Access reviews: periodic review records for privileged roles and admin accounts. ²

Common exam/audit questions and hangups

Expect assessors to ask and test:

• “Show me all privileged accounts. Which ones have MFA enforced, and how do you know?” ²
• “Can a domain admin authenticate to a server over RDP without MFA if they are on the internal network?” ²
• “How do third parties administer in-scope systems, and where is MFA enforced?” ²
• “What are your break-glass accounts, and how are they protected and monitored?” ²
• “Do service accounts or automation accounts have privileged permissions, and how do you control them?” ²

Frequent implementation mistakes (and how to avoid them)

1. MFA only on VPN, not on admin actions.
   Fix: require privileged administration to occur only via an MFA-enforced path (PAM/jump host/admin workstation) and block direct logon routes. ²

2. “Privileged” defined too narrowly.
   Fix: include cloud tenant roles, security tool admins, network device admins, and local admin membership. Validate with role mining from each platform. ²

3. Break-glass accounts with no governance.
   Fix: restrict use, store credentials securely, require approvals, monitor sign-ins, and review after each use. Keep a clean record trail. ²

4. Legacy protocols create MFA bypass.
   Fix: disable legacy authentication where possible; otherwise, constrain by network segmentation and force access through a gateway that requires MFA. ²

5. No evidence package.
   Fix: map 3.5.3 to a control narrative and schedule recurring evidence collection so you can show consistent operation. ³

Enforcement context and risk implications

CMMC is a DoD program implemented through rulemaking and contracting. Your practical risk is not theoretical: failing to enforce and evidence MFA for privileged access can block certification or create findings that delay awards and renewals. Treat 3.5.3 as an assessor-tested control because privileged access is a common entry point for high-impact compromises and is straightforward to validate through configuration and logs. ⁷

Practical 30/60/90-day execution plan

First 30 days (stabilize scope and close obvious gaps)

• Publish a privileged account definition and standard mapped to 3.5.3. ²
• Inventory privileged roles/accounts across IdP, AD, cloud, and key admin consoles. ²
• Enforce MFA for the top-tier privileged roles in the primary IdP and confirm it applies to admin portals. ²
• Identify bypass paths (direct RDP/SSH, local admin login, shared admin accounts, third-party access) and document a closure plan. ²

Days 31–60 (force privileged access through MFA choke points)

• Implement or formalize the admin access pattern: jump host/PAM/admin workstation required for privileged sessions. ²
• Restrict direct admin logon to servers and endpoints; remove unnecessary local admin membership. ²
• Stand up break-glass governance: approvals, monitoring, post-use review. ²
• Create an exceptions register for MFA-incompatible systems with compensating controls and expirations. ²

Days 61–90 (make it assessable and repeatable)

• Build an assessor packet: policies, inventories, MFA configs, sample logs, exception register, and access review evidence. ³
• Run an internal test: attempt privileged access via common tools and confirm MFA triggers on each route; document results. ²
• Put evidence capture on a recurring cadence and assign named owners for each artifact. A GRC workflow tool like Daydream can track tasks, attach evidence, and maintain a clean crosswalk to 3.5.3 for assessment readiness. ³

Frequently Asked Questions

Does 3.5.3 require MFA for every user?

The text targets privileged accounts for local and network access. You can still choose broader MFA coverage, but the minimum focus here is privileged access with demonstrable enforcement. ²

What counts as “local access” for privileged accounts?

Treat local access as admin authentication that occurs on the endpoint or server itself (console/logon/elevation paths), not just remote VPN entry. If an admin can act without passing an MFA gate, you have a gap to address or control via a compensating approach. ²

Can we satisfy this by requiring MFA only on the VPN?

VPN MFA helps, but it may not cover internal admin sessions, console access, or alternative pathways. Assessors typically look for end-to-end privileged access enforcement, not a single perimeter control. ²

How should we handle service accounts that have admin permissions?

First, minimize service account privileges and remove admin rights where possible. If privileges are required, control the execution path (restricted hosts, limited network paths, strong secrets management, and monitoring) and document the design and evidence. ²

What’s an acceptable approach for third-party administrators?

Require third-party admin activity to flow through an MFA-enforced method you control or can evidence (federated identity with MFA, a jump host, or PAM). Avoid shared accounts and keep logs that tie actions to an individual. ²

What evidence is most persuasive in a CMMC Level 2 assessment?

Clear configuration exports or screenshots showing MFA enforcement for privileged roles, plus authentication logs demonstrating MFA challenges for privileged sign-ins. Pair that with a current privileged account inventory and an exception register. ⁶

Footnotes

1. NIST SP 800-171 Rev. 2; DoD CMMC Program Guidance

2. NIST SP 800-171 Rev. 2

3. DoD CMMC Program Guidance

4. NIST SP 800-171 Rev. 2; 32 CFR Part 170

5. 32 CFR Part 170; DoD CMMC Program Guidance

6. DoD CMMC Program Guidance; NIST SP 800-171 Rev. 2

7. 32 CFR Part 170; DoD CMMC Program Guidance; NIST SP 800-171 Rev. 2