Most organizations approach CMMC password requirements with a mix of cargo cult rules inherited from old security training and genuine confusion about what NIST 800-171 actually says. This guide breaks down every password-related practice under CMMC Level 2, what the requirements actually are, what they are not, and how to write a policy that satisfies an assessor without making your employees' lives miserable.
Password requirements in CMMC Level 2 come from the Identification and Authentication (IA) domain of NIST SP 800-171 Rev 2, specifically practices 3.5.1 through 3.5.11. Not all eleven practices are password-specific, some cover MFA and authenticator management more broadly, but they all live in the same domain and get assessed together.
The supporting guidance document that CMMC assessors reference for interpretation is NIST SP 800-63B: Digital Identity Guidelines. This is where the nuance lives, and it's where many organizations get tripped up by following outdated advice instead of the current standard.
Important context: NIST SP 800-63B was substantially updated and the guidance it contains actively contradicts many password "best practices" that were common before 2017. If your current password policy requires 90-day rotation and a mix of uppercase, lowercase, numbers, and symbols but no minimum length guidance, it is based on outdated guidance and may not satisfy a well-informed assessor.
Spoiler: none of them require 90-day rotation. If your current policy says otherwise, this is going to be a productive afternoon.
This is the core password practice. It requires that when a new password is created, it meets minimum complexity standards. What it does not require is periodic forced rotation.
What this means in practice:
Common mistake: Requiring 90-day rotation and listing it in the policy as a CMMC requirement. Forced rotation is not required and NIST guidance discourages it because it predictably leads to patterns like Password1 becoming Password2! becoming Password3! Assessors who know the current guidance will flag this as a misunderstanding, not a compliance point. (The predictability of human password behavior under forced rotation schedules is, frankly, unflattering to us as a species.)
Users cannot recycle recent passwords. You define the number of generations in policy and enforce it technically.
How to implement:
Common mistake: Setting password history to 5 or 10 generations because "that seems like enough." Assessors typically expect 24. Set it and document it.
When IT resets a password for a user or issues a temporary credential for onboarding, the user must be required to change it immediately on first login. No exceptions for users who promise they'll change it later.
How to implement:
Common mistake: Help desk sets a standard temp password ("Welcome123!") and tells users to change it when they get a chance. Assessors will ask how you enforce this technically and what happens if the user doesn't change it.
Passwords must never be stored or transmitted in plaintext. This practice is about how your systems handle password data on the backend, not what users do.
How to implement:
Common mistake: Overlooking third-party or custom-built applications that handle authentication. An assessor may ask about any application in your CUI environment. "It's the vendor's responsibility" is not an acceptable answer if that application processes CUI.
This one sounds fancy but means: password fields should show dots or asterisks, not the actual characters being typed. No login screen should display a password in plaintext as it is entered.
How to implement:
Common mistake: Treating this as an automatic pass because Windows hides passwords. If you have any custom scripts or internal tools that accept credentials interactively, verify they obscure input properly.
3.5.3 is not technically a password practice. It is, however, the one that makes every other password practice somewhat academic if an attacker already has the password and there's nothing else in the way.
While not strictly a "password" practice, 3.5.3 is the most impactful IA requirement in terms of security posture and the one assessors probe hardest. MFA is required for:
In practical terms: anyone accessing anything related to CUI remotely needs MFA. Most organizations simply apply MFA universally to avoid scope confusion, which is the right call.
Acceptable MFA methods: Authenticator apps (Microsoft Authenticator, Google Authenticator), FIDO2 hardware keys (YubiKey), SMS OTP (permitted but discouraged by NIST due to SIM-swap risk), email OTP (same caveat)
Common mistake: Enabling MFA on the VPN but not on cloud applications like Microsoft 365, SharePoint, or your project management tool where CUI documents are stored. Assessors follow the data, not the network perimeter.
Here is a summary of requirements that satisfy CMMC Level 2 and align with NIST SP 800-63B:
| Requirement | Required? | Recommended Setting |
|---|---|---|
| Minimum password length | Yes | 12 characters minimum (15 for privileged accounts) |
| Character complexity (uppercase + symbols) | No | Optional; length is more important than mix |
| Passphrases permitted | Yes | Must be allowed; communicate this to users |
| Mandatory periodic rotation | No | Not required; only on evidence of compromise |
| Change on compromise | Yes | Immediate reset required on suspected or confirmed compromise |
| Password history | Yes | 24 generations minimum |
| Temporary password immediate change | Yes | Enforced technically, not by policy alone |
| Cryptographic storage | Yes | bcrypt/PBKDF2 for apps; AD/Entra handle it natively |
| Masked input fields | Yes | Default in standard OS/browsers; check custom apps |
| MFA for remote access | Yes | All remote and cloud access; authenticator app minimum |
| MFA for privileged accounts | Yes | All privileged access, local and remote |
| Account lockout | Yes | 5 failed attempts; 30-minute lockout (3.5.5 / 3.5.6) |
The bottom line: CMMC password requirements are actually less burdensome than many organizations assume, because they align with modern NIST guidance rather than outdated standards. Dropping mandatory 90-day rotation, allowing passphrases, and focusing on length and MFA is the right approach for both security and assessor satisfaction.
During a CMMC Level 2 assessment, the IA domain is examined through three lenses: documentation, configuration, and interview. You need all three to pass.
Documentation: A written Password Policy that explicitly addresses each of the 3.5.x practices. The policy must state minimum length, history requirements, MFA requirements, and the process for handling temporary passwords and compromised credentials. A policy that says "we follow best practices" without specifics will generate a finding.
Configuration evidence: Screenshots or exports of your Active Directory Fine-Grained Password Policy or Default Domain Policy showing minimum length, history, and lockout settings. MFA enrollment reports from Entra ID or your identity provider showing coverage percentages. If MFA enrollment is at 73% coverage, the 27% of uncovered accounts is a finding.
Interview: Assessors will ask your IT staff how password resets are handled, how temporary passwords are communicated to users, what happens when a compromise is suspected, and whether users know they can use passphrases. Inconsistencies between what your policy says and what your staff describes will generate questions.
A complete, assessor-ready Password Policy covering all 3.5.x practices in formal policy language. Includes passphrase permission, no-rotation rationale, MFA requirements, and account lockout standards. Editable .docx, customizable in under an hour.
Download for $19 →Based on common assessment patterns, these are the password-related gaps that show up most frequently:
Somewhere in your environment there is a service account with a password set in 2017 that everyone is afraid to touch. This section is for that account.
Service accounts are a common blind spot in CMMC password policies. They are accounts used by applications and automated processes rather than humans, and they often end up with passwords like "ServiceAccount1!" that were set during initial deployment and never changed.
For CMMC compliance, service accounts that have access to CUI systems need to be addressed in your policy. Options include: using Managed Service Accounts (MSA) or Group Managed Service Accounts (gMSA) which rotate passwords automatically, vaulting service account credentials in a PAM tool, or at minimum documenting a review cycle for service account credentials.
All 110 NIST SP 800-171 practices organized by domain - formatted for assessment prep. Free PDF, instant access.