CMMC Level 2Implementation GuideJune 11, 2026· 13 min read
How to Actually Implement CMMC Level 2 Identification and Authentication: A Practitioner's Guide
The Identification and Authentication domain is where CMMC gets personal. Every person, process, and device that touches a system containing CUI needs to be identified and authenticated in a way the standard can verify. MFA, password controls, and account lifecycle management are the core of this domain. All 11 practices are covered here with plain-language explanations and real implementation guidance.
Why IA Is One of the Most Assessed Domains
Weak authentication is the entry point for the majority of breaches. Compromised credentials drive most ransomware incidents, most data exfiltration events, and most supply chain compromises. CMMC assessors know this, which means IA practices get close scrutiny. The good news is that most of the IA domain can be addressed through a combination of Entra ID (Azure AD), Conditional Access policies, and a solid password policy enforced via Group Policy or Intune.
If your organization is already on Microsoft 365 Business Premium or higher, you likely have the tools to satisfy every IA practice without purchasing additional products. The gap is almost always configuration and documentation, not tooling.
Before implementing: Do a complete account audit first. Every account in Active Directory or Entra ID that has access to in-scope systems needs to be reviewed. Stale accounts, shared accounts, and accounts with no associated person are immediate findings. Cleaning up the account inventory is the prerequisite for everything else in this domain.
Practices 3.5.1 and 3.5.2 — Identify and Authenticate Users, Processes, and Devices
3.5.1 – 3.5.2
Every user gets a unique identity. Every identity gets authenticated before access is granted.
These two practices are foundational. Practice 3.5.1 requires that every user, process acting on behalf of a user, and device that accesses in-scope systems has a unique identifier. Practice 3.5.2 requires those identifiers to be authenticated before access is granted.
How to implement:
Every employee must have an individual account tied to them personally. Shared accounts ("frontdesk," "admin," "scanner") are not permitted for human users accessing CUI systems
Service accounts and system processes should have dedicated accounts with documented purposes. Use Group Managed Service Accounts (gMSAs) in Active Directory where possible, as they rotate their own passwords automatically
Devices should be enrolled in your directory (Entra ID joined or hybrid joined) so device identity can be included in authentication and access decisions
Maintain an account inventory: a list of every account in scope, the person or system it belongs to, when it was last reviewed, and its current status
Review and recertify accounts at least annually. Accounts for employees who have left should be disabled within 24 hours of separation and deleted within 30 days
Common mistake: Shared admin accounts. "We all use the same admin account" is an immediate finding that also breaks audit logging (you cannot tell which administrator took which action), separation of duties, and privileged access management. Every administrator needs their own privileged account.
Practice 3.5.3 — Multi-Factor Authentication
3.5.3
MFA is required. For privileged accounts, always. For all accounts, for any network access.
This is the highest-impact single practice in the IA domain. Practice 3.5.3 requires MFA for local access to privileged accounts, and for network access to both privileged and non-privileged accounts. In plain terms: anyone logging in over the network needs MFA, and administrators need MFA even when sitting at a local console.
How to implement:
Microsoft 365 environments: Enable Security Defaults in Entra ID at minimum, or deploy Conditional Access policies requiring MFA for all users. Conditional Access (available in Entra ID P1, included in M365 Business Premium) gives you more control, including per-app and per-location policies
Authenticator options: Microsoft Authenticator app (push notification or TOTP), FIDO2 hardware security keys (YubiKey, etc.), and Windows Hello for Business all satisfy the requirement. SMS is technically a second factor but avoid it if possible due to SIM-swapping risk
VPN and remote access: Require MFA at the VPN gateway. Most enterprise VPN solutions (Cisco, Palo Alto, Fortinet, etc.) support RADIUS with MFA integration. Entra ID Application Proxy or Conditional Access can cover web-based remote access
Privileged accounts: Administrators should use separate privileged accounts for admin tasks, with MFA enforced on those accounts. Consider Microsoft Entra PIM (Privileged Identity Management) for just-in-time admin access
Document your MFA configuration: which Conditional Access policies are in place, which applications they cover, and what MFA methods are approved
Common mistake: MFA deployed for cloud apps but not for on-premise systems or VPN. An assessor will trace the full authentication path. If a user can reach in-scope systems by connecting to VPN without MFA, even if the cloud apps require it, the practice is not fully satisfied.
Practice 3.5.4 — Replay-Resistant Authentication
3.5.4
Authentication credentials must be time-limited or one-time-use. Legacy protocols fail this requirement.
Replay-resistant authentication means an attacker who captures authentication traffic cannot reuse it to gain access. Modern authentication protocols are replay-resistant by design. Legacy protocols often are not.
How to implement:
Disable legacy authentication protocols in Entra ID. Use the "Block legacy authentication" Conditional Access policy template to prevent any client using SMTP Auth, POP, IMAP, or other legacy protocols from authenticating
Require modern authentication (OAuth 2.0 / OpenID Connect) for all Office 365 and Microsoft 365 client connections
Disable NTLM v1 via Group Policy (Network security: LAN Manager authentication level set to "Send NTLMv2 response only. Refuse LM and NTLM")
For on-premise systems, ensure Kerberos with AES encryption is the default authentication method rather than NTLM where possible
Review VPN authentication: ensure it uses certificate-based or token-based mechanisms rather than static credentials passed over the connection
Common mistake: Old line-of-business applications that require SMTP Auth or Basic Auth to function. These are often overlooked because they're not the primary user-facing systems. Every authentication flow that touches in-scope systems must be evaluated, including automated processes and integrations.
Practices 3.5.5 and 3.5.8 — Prevent Password Reuse
3.5.5 – 3.5.8
Passwords must not be recycled. Minimum 5 generations of history enforced.
Practice 3.5.5 requires using automated tools to prevent reuse of passwords within a minimum number of generations (NIST 800-171 specifies at least five). Practice 3.5.8 explicitly states the prohibition on reuse. They address the same control from two angles and are implemented together.
How to implement:
In Group Policy: Computer Configuration > Windows Settings > Security Settings > Account Policies > Password Policy. Set "Enforce password history" to 24 (the Windows maximum, which exceeds the 5-generation minimum)
In Entra ID: Password protection settings can enforce similar controls for cloud-only accounts. Microsoft Entra Password Protection also lets you push these settings to on-premise Active Directory
For fine-grained password policies (different policies for privileged vs. standard accounts in AD), use Active Directory Fine-Grained Password Policies via Active Directory Administrative Center
Pair with a minimum password age of at least one day to prevent users from cycling through 24 passwords in one session to return to their original password
Common mistake: Setting password history to 5 exactly rather than a higher number. While 5 satisfies the floor, NIST recommends substantially higher history to prevent password rotation abuse. 24 is the right setting, not 5.
Practice 3.5.6 — Disable Inactive Identifiers
3.5.6
Accounts that haven't been used in a defined period must be disabled automatically.
Stale accounts are a persistent attack vector. An account for a former employee or contractor that was never deprovisioned is a ready-made entry point. This practice requires defining an inactivity period and disabling accounts that exceed it.
How to implement:
Define your inactivity threshold in your IA policy. 90 days is a common and defensible standard
For Active Directory: use PowerShell to query for accounts with no login activity within the threshold period. The command Search-ADAccount -AccountInactive -TimeSpan 90.00:00:00 -UsersOnly returns accounts matching that criteria
Set up a monthly or quarterly automated script to disable accounts exceeding the threshold, log the action, and notify the account owner's manager
For Entra ID: use Access Reviews in Entra Identity Governance (available in Entra ID P2 or M365 E5) for automated account reviews. Alternatively, export sign-in logs and build a recurring check
Service accounts should be excluded from automatic disabling but included in periodic manual review, since they may go long periods without interactive login
Common mistake: Having a policy that says inactive accounts will be disabled, but no automated or scheduled process actually enforcing it. An assessor may pull your account list and sort by last login. Accounts with no login in 6-12 months with no documented exception are a finding.
Practice 3.5.7 — Password Complexity and Change Requirements
3.5.7
Passwords must meet defined complexity requirements. New passwords must differ meaningfully from old ones.
This practice requires enforcing minimum password complexity and ensuring new passwords represent a real change, not a trivial variation of the previous password.
How to implement:
Current NIST guidance (SP 800-63B) de-emphasizes mandatory character complexity rules (forced uppercase, numbers, symbols) in favor of minimum length. A 15-character passphrase is more secure than an 8-character complex password that follows a predictable pattern
A defensible standard for CMMC: minimum 12 characters for standard users, minimum 15 characters for privileged accounts, with complexity enabled (uppercase, lowercase, number, and symbol each required). This satisfies both the old-school expectation and NIST principles
In Group Policy: set "Minimum password length" and enable "Password must meet complexity requirements"
Consider deploying Microsoft Entra Password Protection, which blocks commonly used passwords and their variants (variations of "Password1", company name, etc.) against a constantly updated banned password list
The "character change" requirement is enforced implicitly by password history and minimum complexity, which prevent users from trivially incrementing a number at the end of their existing password
Common mistake: Mandatory 90-day password expiration with low complexity requirements. This pattern reliably produces passwords like "Spring2026!" followed by "Summer2026!" Users game predictable complexity + rotation requirements. Long, complex, infrequently rotated passwords with MFA is a stronger outcome than short, simple, frequently rotated ones.
Practice 3.5.9 — Temporary Password Policy
3.5.9
Temporary passwords must require an immediate change at first use.
When a new account is created or a password is reset by helpdesk, the initial temporary password must expire and force a change at the user's first login.
How to implement:
In Active Directory: check "User must change password at next logon" on every new account and every password reset
In Entra ID: the Temporary Access Pass feature creates a time-limited, one-time-use credential that forces the user to set their own password or register MFA before it can be used for normal access
Document this requirement in your account provisioning and password reset procedures so helpdesk staff apply it consistently
Audit new accounts periodically to verify the flag was set. Accounts that show a password age equal to their creation date and no sign of a user-initiated change may indicate the flag was forgotten
Common mistake: Helpdesk staff setting a standard temporary password (like "Welcome1!") that they tell users verbally but don't force to change. That password is now known to every helpdesk person who's ever reset anyone's account. Force the change at login, every time.
Practice 3.5.10 — Cryptographic Protection of Passwords
3.5.10
Passwords must be stored and transmitted in protected form. Plaintext passwords are never acceptable.
This practice requires that passwords are stored using cryptographic mechanisms (hashing with a salt) and transmitted over encrypted channels. It targets systems that store credentials locally, like applications, databases, and legacy systems.
How to implement:
Active Directory stores passwords as NTLM hashes by default. Ensure LAN Manager (LM) hash storage is disabled via Group Policy (Network security: Do not store LAN Manager hash value on next password change)
For any custom applications or web apps that authenticate users: passwords must be stored using bcrypt, scrypt, Argon2, or PBKDF2, not MD5 or SHA-1, and never in plaintext
All authentication traffic must occur over TLS 1.2 or higher. HTTP-based logins, LDAP without TLS (LDAPS), and unencrypted VPN authentication flows are findings
Review any legacy applications in scope that may have their own user credential stores. These are often overlooked and may store passwords in insecure formats
Common mistake: Overlooking application-level credential stores. The Active Directory is fine, but a legacy line-of-business application that stores usernames and passwords in a local SQL database with MD5 hashes is an immediate finding. Applications in scope need to be reviewed for how they handle credentials.
Practice 3.5.11 — Obscure Authentication Feedback
3.5.11
Authentication systems must not display password characters during entry.
This practice requires that feedback during authentication (password entry) is obscured so that an observer cannot read credentials from the screen. It also extends to error messages, which should not reveal whether a username or a password was incorrect.
How to implement:
Standard Windows login screens and web login forms already satisfy this by default with password masking. Verify this behavior on any custom applications, web portals, or kiosk systems in scope
Authentication error messages should say "Invalid username or password" rather than distinguishing between the two. Specific errors like "Username not found" reveal which usernames exist in the system (user enumeration)
Disable any "Show password" toggle on login forms for systems that handle CUI, or document a risk acceptance if the toggle is retained for usability
This practice also applies to command-line authentication. Scripts or automation that echo passwords to terminal output or logs must be corrected
Common mistake: Login forms that differentiate between "account not found" and "incorrect password." Developers often add this for usability, but it allows an attacker to enumerate valid usernames by observing which error appears. Generic authentication failure messages are required.
Quick Reference: Tools for IA Implementation
Need
Tool Options
Notes
MFA enforcement
Microsoft Entra ID Conditional Access, Duo Security, Okta
Entra ID Conditional Access is included in M365 Business Premium; Duo works well for on-premise and hybrid environments
MFA methods
Microsoft Authenticator, FIDO2 keys (YubiKey), Windows Hello for Business
FIDO2 keys are phishing-resistant and the strongest available option; Authenticator app is a good balance of security and usability
Privileged access management
Microsoft Entra PIM, CyberArk, BeyondTrust
Entra PIM is included in Entra ID P2; provides just-in-time admin access with approval workflows
Password policy enforcement
Group Policy, Microsoft Entra Password Protection
Entra Password Protection pushes banned password lists to on-premise AD and cloud; free for basic functionality
Block legacy authentication policy template in Conditional Access is a one-step implementation
Password manager (user adoption)
1Password, Bitwarden, KeePass
A password manager makes long, unique passwords practical for users; reduces password reuse across systems
The MFA exception trap: Many organizations deploy MFA but carve out exceptions for specific users, applications, or IP ranges "just to make it work." Each exception is a potential gap. Document every exception formally, include a business justification and an expiration date, and review exceptions at least quarterly. Assessors will look for exception lists.
Building the Evidence Package
For the IA domain, assessors will typically want to see your Conditional Access policy configuration (screenshots of each policy, its scope, and conditions), evidence that MFA is actively enforced (sign-in logs showing MFA challenges), your password policy settings (GPO or Intune config), an account inventory with a process for periodic review, and documentation of your account provisioning and deprovisioning procedures.
The most important evidence is demonstrating that controls are actually enforced, not just configured. A sign-in log showing users successfully authenticating with MFA is more persuasive than a screenshot of a policy that's set to "report-only" mode.
Need the Policy Document That Covers These Practices?
Our CMMC Level 2 Identification and Authentication Policy template covers all 11 IA practices in formal policy language with fill-in-the-blank placeholders for your organization's MFA methods, password requirements, account lifecycle process, and approved authentication tools.
Practice 3.5.3 requires MFA for network access to privileged accounts and for network access to non-privileged accounts. For local access, MFA is required for privileged accounts. In practice, this means any remote or network-based login to any account should use MFA. Most organizations satisfy this using Microsoft Entra ID with Conditional Access policies requiring MFA for all users accessing company resources, regardless of privilege level.
CMMC requires two or more different authentication factors from these categories: something you know (password or PIN), something you have (hardware token, authenticator app, smart card, or security key), and something you are (biometric like fingerprint or face recognition). SMS text messages are technically a second factor but are considered weak due to SIM-swapping attacks. Microsoft Authenticator app, hardware FIDO2 keys (YubiKey), and smart cards all satisfy the requirement. SMS should be avoided if possible.
Practice 3.5.7 requires enforcing minimum password complexity and character change requirements. Current NIST guidance favors length over mandatory character classes, recommending passwords of at least 8 characters minimum, though 12 to 15 characters is a more defensible standard for CMMC. The more critical requirements are prohibiting password reuse for at least five generations (3.5.8), storing passwords in hashed form (3.5.10), and pairing the password policy with MFA so the password alone is not the only control.
Shared accounts used by human users are not permitted for systems in scope. Every person who accesses CUI systems must have a unique, individual account. Service accounts used by applications or automated processes are different and can exist, but they must follow least privilege principles, have strong passwords, and ideally be managed service accounts (MSAs) or group managed service accounts (gMSAs) in Active Directory, which rotate their own passwords automatically without requiring manual intervention.
Replay-resistant authentication (3.5.4) means the authentication mechanism produces credentials that can only be used once or are time-limited, preventing an attacker who captures authentication traffic from reusing it. Kerberos with AES encryption, NTLM v2, TLS-protected authentication flows, FIDO2/WebAuthn, and smart card authentication are all replay-resistant. Legacy protocols like NTLM v1 and HTTP Basic Auth over unencrypted connections are not. Disabling legacy authentication in Entra ID and requiring modern authentication protocols satisfies this practice.