Identification and Authentication 3.5.3 (3.5.3)
Use multifactor authentication for local and network access to privileged accounts and for network access to non-privileged accounts.[24] [25].
Get Full GuidanceWhat Is This CMMC Control?
Organizations must require two or more different authentication factors (password, token, biometric) when users access privileged accounts locally or over a network, and when any user accesses non-privileged accounts over a network. This means administrators always need MFA, and regular users need MFA when connecting remotely or over the network.
Control Intent
Prevent unauthorized access to systems and CUI by requiring multiple independent authentication factors, making it significantly harder for attackers to compromise accounts even if passwords are stolen or guessed.
Who This Control Applies To
- •All systems processing, storing, or transmitting CUI
- •All privileged user accounts (administrators, system operators, database administrators, security personnel)
- •All non-privileged user accounts when accessed over a network (remote access, VPN, web portals, cloud applications)
- •Local access to privileged accounts (direct console, terminal, workstation login with elevated privileges)
- •Network access to privileged accounts (SSH, RDP, administrative portals, cloud admin consoles)
- •Network access to non-privileged accounts (VPN, remote desktop, web applications, email, cloud services)
- •Third-party and contractor accounts with CUI access
- •Service accounts and automated processes requiring privileged access
Not Applicable When
- •User accounts have no access to CUI or systems in the CUI environment
- •Physical access controls completely prevent network connectivity (air-gapped systems with no remote access capability)
- •Non-privileged accounts accessed only via direct local console with no network connectivity
- •Emergency access procedures are documented, approved, and used only during MFA system failures with compensating controls and logging
Key Objectives
- 1Require multifactor authentication for all local and network access to privileged accounts to protect against credential theft and unauthorized administrative access
- 2Require multifactor authentication for all network access to non-privileged accounts to prevent remote unauthorized access to CUI
- 3Ensure authentication mechanisms use at least two independent factors from different categories (knowledge, possession, or inherence)
Sample Self-Assessment Questions (Partial)
Do you have any user accounts that can access systems or data remotely (from home, other offices, or outside the building)?
Do you have administrator or IT staff accounts that can make system changes or access sensitive data?
Implementation Approaches (High-Level)
Cloud-Based MFA with Conditional Access
Centralized identity provider (Azure AD, Okta, Google Workspace) enforcing MFA for all privileged accounts and network access to non-privileged accounts through conditional access policies
VPN-Enforced MFA for Network Access
VPN gateway requiring MFA for all remote connections, with local network access controlled separately through workstation and server login policies
Hardware Token or Smart Card MFA
Physical authentication devices (smart cards, FIDO2 security keys, hardware tokens) required for privileged access and network access, with centralized or per-system enforcement
Biometric MFA for Privileged Access
Biometric authentication (fingerprint, facial recognition, iris scan) combined with passwords or PINs for privileged account access, typically on managed devices
Application-Level MFA for CUI Access
MFA enforced at the application layer for web applications, databases, and cloud services containing CUI, independent of network or system-level authentication
Privileged Access Management (PAM) with MFA
Dedicated PAM solution managing and securing all privileged access with integrated MFA, session recording, and just-in-time access
Evidence & Assessment Notes
Expected Evidence
Organizations should maintain documentation and evidence demonstrating compliance with this control. This may include policy documentation, configuration records, audit logs, access reviews, and other relevant artifacts that show how the control is implemented and maintained.
Plan of Action & Milestones (POA&M)
If MFA cannot be immediately implemented for all required scenarios, prioritize privileged accounts and remote access in POA&M milestones Document specific technical limitations preventing MFA (legacy systems, application incompatibility) and planned remediation or compensating controls For service accounts requiring privileged access, POA&M should address migration to certificate-based authentication, managed identities, or PAM solution If MFA solution procurement or deployment is delayed, POA&M must include interim compensating controls (enhanced monitoring, IP restrictions, reduced privileged account count) POA&M milestones should be specific and measurable (e.g., 'Enforce MFA for all VPN users by [date]' not 'Implement MFA') Include MFA user training and enrollment in POA&M timeline, as technical deployment alone does not achieve compliance For SMS or email-based MFA identified as weak, POA&M should address migration to authenticator apps, hardware tokens, or biometrics If emergency access procedures lack compensating controls, POA&M should address enhanced monitoring, approval workflows, and time-limited access POA&M should address MFA fatigue attack prevention (number matching, FIDO2 migration) if current solution is vulnerable Include regular POA&M updates demonstrating progress (enrollment rates, systems covered, authentication logs showing MFA usage)
Frequently Asked Questions
Does this control require PIV cards or CAC cards like government agencies use?
No. While PIV and CAC cards are acceptable MFA solutions, the control does not require them. Commercial MFA solutions using authenticator apps, hardware tokens, biometrics, or other multi-factor methods are acceptable. The control requires two or more independent factors, not a specific technology.
Do service accounts and automated processes need MFA if they have privileged access?
Service accounts present a challenge because they cannot interactively respond to MFA prompts. Acceptable approaches include using certificate-based authentication, managed identities, API keys with IP restrictions, or migrating to a PAM solution that manages service account credentials. The key is ensuring equivalent security to MFA through cryptographic or other strong authentication methods.
What is the difference between local and network access, and why does it matter for this control?
Local access means direct physical connection to a system (console, terminal, directly connected keyboard/monitor) without using a network. Network access means connecting through any network (LAN, WAN, Internet, VPN). This matters because privileged accounts need MFA for both local and network access, but non-privileged accounts only need MFA for network access. A regular user at their desk using a directly connected workstation is local access and does not require MFA under this control.
Is SMS-based MFA (text message codes) acceptable for this control?
While SMS-based MFA technically satisfies the multi-factor requirement (something you know + something you have), it is considered weak due to SIM swapping and interception risks. NIST SP 800-63B discourages SMS for higher assurance levels. Assessors may accept SMS-based MFA but often recommend migration to authenticator apps, hardware tokens, or biometrics in POA&Ms, especially for privileged accounts.
What happens if our MFA system fails - can we still access systems?
Organizations should have documented emergency access procedures (break-glass accounts) for MFA system failures. These procedures must include compensating controls such as enhanced monitoring, time-limited access, approval workflows, and immediate review of emergency access usage. Simply exempting accounts from MFA without compensating controls is not acceptable.
Do we need MFA for every login, or can we use trusted devices or locations to reduce MFA prompts?
The control requires MFA for the defined access scenarios (privileged accounts, network access to non-privileged accounts). However, risk-based or adaptive authentication that reduces MFA frequency based on device trust, location, or behavior is acceptable if the initial authentication included MFA and the risk assessment is documented. Completely bypassing MFA based solely on IP address or device without any MFA challenge is not acceptable.
How ConformatIQ Helps With CMMC Readiness
ConformatIQ is an AI-assisted CMMC readiness platform designed to help organizations prepare for assessments more efficiently. The platform supports document generation such as SSPs and POA&Ms, guided readiness workflows, centralized evidence tracking, and interview preparation for assessments.
Ready to Get Full Guidance?
Access complete implementation details, detailed assessment questions, evidence requirements, and expert guidance for this control.
Request Full GuidanceInformation sourced from NIST SP 800-171 Rev. 2. See full disclaimer.