Use multifactor authentication for local and network access to privileged accounts
📖 What This Means
This control requires adding an extra layer of security when logging into high-privilege accounts (like IT administrators or system controllers). Instead of just using a password, users must provide a second proof of identity - like a code from their phone or a fingerprint. Think of it like a bank requiring both your debit card AND PIN to withdraw money. For example: 1) An admin logging into your company's server must enter their password AND approve a push notification on their phone. 2) A database manager accessing sensitive records needs to insert a physical security key after entering credentials.
🎯 Why It Matters
Privileged accounts are prime targets - if compromised, attackers gain full system access. Verizon's 2022 DBIR found 61% of breaches involved credential theft. A single stolen admin password caused the 2020 SolarWinds breach ($18M+ in damages). The DoD mandates this because: 1) Passwords alone are easily phished or cracked 2) MFA blocks 99.9% of automated attacks (Microsoft) 3) It's the #1 control to prevent lateral movement in networks. Without MFA, a contractor could unknowingly give adversaries full system control through one weak password.
✅ How to Implement
- 1. In Azure: Enable Azure AD MFA → Security → Multifactor Authentication → Enable for all privileged roles (Global Admin, Security Admin, etc.)
- 2. In AWS: Activate IAM MFA → IAM → Users → Select admin accounts → Security Credentials → Assign MFA device (virtual or hardware)
- 3. Configure conditional access policies (e.g., require MFA when logging in from outside corporate IP ranges)
- 4. Enforce MFA at the management console level (AWS root account, Azure tenant root)
- 5. Set up backup methods (SMS, authenticator app, security keys) for redundancy
📋 Evidence Examples
MFA Enrollment Report
Group Policy Object (GPO) Screenshot
Break-Glass Access Procedure
MFA Test Logs
Admin Account Inventory
📝 SSP Guidance
Use this guidance when writing the System Security Plan (SSP) narrative for this control.
How to Write the SSP Narrative
For IA.L2-3.5.3 ("Use multifactor authentication for local and network access to privileged accounts"), your SSP narrative should specifically describe: (1) the tools and technologies you use to implement this control, (2) the configuration or process that enforces it, (3) who is responsible for maintaining it, and (4) what evidence proves it's working. Describe how users, devices, and processes are identified and authenticated, including your IAM platform, password policies, MFA implementation, certificate management, and service account controls. Be specific -- name your actual products, settings, and responsible personnel.
Example SSP Narratives
"IA.L2-3.5.3 is implemented using cloud-native controls. [Organization] uses [specific cloud service/feature] to use multifactor authentication for local and network access to privileged accoun.... The configuration is managed through [Azure Policy/AWS Config/Terraform] and monitored via [SIEM tool]. Responsible party: [IT Security Manager]. Evidence: [specific artifact, e.g., 'Azure AD Conditional Access policy screenshot, CloudTrail logs']."
"IA.L2-3.5.3 is implemented through on-premise infrastructure controls. [Organization] uses [Active Directory/Group Policy/specific tool] to use multifactor authentication for local and network access to privileged accoun.... Configuration is documented in [location] and audited [frequency]. Responsible party: [System Administrator]. Evidence: [specific artifact, e.g., 'Group Policy export, Windows Event logs']."
"IA.L2-3.5.3 is implemented across both cloud and on-premise environments. [Organization] uses [Azure AD Connect/hybrid tool] to ensure consistent enforcement. Cloud resources are managed via [cloud tool] and on-premise systems via [on-prem tool]. Both environments report to [centralized SIEM]. Responsible party: [IT Director]. Evidence: [artifacts from both environments]."
System Boundary Considerations
- • Identify all authentication entry points (local login, VPN, cloud, API)
- • Document the identity provider(s) and authentication flow
- • Specify MFA methods and coverage
- • Ensure this control covers all systems within your defined CUI boundary where use multifactor authentication for local and network access to privileged accounts applies
- • Document any systems where this control is not applicable and explain why
Key Documentation to Reference in SSP
- 📄 Identification and Authentication Policy
- 📄 Password policy configuration
- 📄 MFA enrollment records
- 📄 Service account registry
- 📄 Evidence artifacts specific to IA.L2-3.5.3
- 📄 POA&M entry if control is not fully implemented
What the Assessor Looks For
The assessor will test authentication mechanisms, verify MFA is enforced for required access paths, check password policy configuration, and review service account documentation.
💬 Self-Assessment Questions
Use these questions to assess your compliance. Each "NO" answer provides specific remediation guidance.
Question 1: Have all privileged accounts (local and network) been identified and documented?
Question 2: Is MFA enabled for 100% of identified privileged accounts?
Question 3: Are there technical controls preventing MFA bypass for privileged access?
Question 4: Is there evidence of regular testing that MFA is functioning for privileged accounts?
Question 5: Are backup MFA methods available and documented for all critical privileged accounts?
⚠️ Common Mistakes (What Auditors Flag)
1. Missing service accounts
2. MFA not enforced at all entry points
3. No break-glass procedure
4. Weak secondary factors
5. No evidence of enforcement
📚 Parent Policy
This practice is governed by the Identification and Authentication Policy