CMMC Level 2 — Independent Research

CMMC Password Requirements: Length, Complexity, Rotation, History, and Assessment Evidence

By The Defense Compliance Report Editorial Team · Last reviewed: July 2026 · Last verified: July 11, 2026 · Methodology · Editorial & Advertising Policy

The Defense Compliance Report is an independent trade publication on CMMC 2.0 and DIB compliance. We are not affiliated with the Cyber AB, the Department of Defense, DCMA DIBCAC, NIST, or any U.S. government agency.

CMMC does not set one universal password length, and it does not require a 60- or 90-day password change. At Level 2, CMMC password requirements come from five security requirements in NIST SP 800-171 Revision 2 — 3.5.7 through 3.5.11 — covering complexity, reuse, temporary passwords, cryptographic protection, and obscured feedback. Your organization defines several of the key numbers, but it must document and technically enforce whatever it chooses.

If you’ve opened five tabs and found five different “requirements” — 8, 12, 14, 15, 16 characters; rotate every 90 days; remember 24 passwords — you were not doing it wrong. Those numbers come from different sources answering different questions, and several guides quietly blur them together. One even labels the wrong requirement as the password-reuse rule. We’ll show you exactly where each number comes from, which one actually governs your assessment today, and how to build a policy that survives the define-and-enforce test.

The Defense Compliance Report is the independent trade publication and decision resource for CMMC and Defense Industrial Base compliance — explaining the CMMC Final Rule with primary-source citation on every claim and mapping a contractor’s level, CUI scope, assessment type, and timeline to the right provider category, so DIB contractors choose the right CMMC path before they spend six figures.

The answer on one screen

Current baseline, dated: 32 CFR Part 170 (the CMMC Program Rule) took effect December 16, 2024. DFARS clause 252.204-7021 took effect November 10, 2025. Phase 1 runs November 10, 2025 through November 9, 2026; Phase 2 begins November 10, 2026. CMMC Level 2 currently maps to NIST SP 800-171 Revision 2 because 32 CFR 170.14(c)(3) makes the Level 2 security requirements identical to Revision 2.

This page is educational research, not legal, contractual, assessment, or compliance advice. Confirm your required level and scope with a CMMC Registered Practitioner (RP) or Registered Provider Organization (RPO) and, where appropriate, a qualified federal-contracts attorney.

The one framework that ends the confusion: label every number by its source

Every password “requirement” you’ll read about CMMC belongs to exactly one of six categories. Once you can tell them apart, the contradictions disappear. We label every number and rule on this page with one of these tags:

• ACTIVE REQUIREMENTText you must satisfy today, from NIST SP 800-171 Rev. 2 as adopted by 32 CFR Part 170.
• YOU DEFINE THISA value the rule deliberately leaves to your organization to set, document, and enforce.
• EXAMPLE, NOT A MANDATEA figure that appears in assessment guidance as an illustration. Helpful. Not binding.
• MODERN BENCHMARKCurrent NIST digital-identity guidance (SP 800-63B-4). Useful for justifying your choices. Not the CMMC standard.
• FUTURE WATCHTied to NIST SP 800-171 Rev. 3, which CMMC has not adopted. Prepare, don’t panic.
• OUR EDITORIAL CALLOur judgment, clearly labeled as ours, derived from the verified facts above.

We built this labeling system because the most common failure this topic produces isn’t picking the “wrong” number. It’s treating an example, a benchmark, or a future parameter as though it were the active rule — and then either over-building or, worse, writing something into the System Security Plan (SSP) that your environment can’t actually enforce.

What are the CMMC password requirements?

The CMMC Password Requirement Ledger

CMMC Level 2 has five password-specific requirements: define and enforce complexity and changed-character rules (3.5.7), prohibit reuse for a specified number of generations (3.5.8), force immediate replacement of temporary passwords (3.5.9), store and transmit only cryptographically protected passwords (3.5.10), and obscure authentication feedback (3.5.11). Your organization supplies several of the numbers, but it must document and technically enforce whatever it chooses.

Sources: NIST SP 800-171 Rev. 2 (requirement text), NIST SP 800-171A (assessment objectives), and 32 CFR 170.24 and 170.21 (CMMC scoring and POA&M rules).

* Eligible only when all 32 CFR § 170.21 conditions are met (overall score ≥ 88, no POA&M item > 1 point, 180-day closeout). Point values: 32 CFR § 170.24. Source verification: July 11, 2026.

The CMMC Assessment Guide — Level 2 states that “minimum complexity requirements are left up to the organization to define.” That’s the official guide confirming what Revision 2 leaves to you. The complexity parameters are yours to define and enforce. YOU DEFINE THIS

Does CMMC require 12-, 15-, or 16-character passwords?

None of those numbers is the current universal CMMC Level 2 minimum. Twelve characters appears as an example in the CMMC Assessment Guide — Level 2. Fifteen is the current NIST SP 800-63B-4 minimum for single-factor passwords. Sixteen is tied to NIST SP 800-171 Revision 3, which CMMC has not adopted. Under the active Revision 2 baseline, your organization defines the complexity parameters, including any minimum length.

Where the 12-character claim comes from

Twelve characters appears in the CMMC Assessment Guide — Level 2, version 2.13, as a Potential Assessment Considerations example — a mix of upper- and lower-case, numbers, and symbols. It’s an official assessment-guide example, not a mandate, and not automatically adequate for every environment. Don’t write “CMMC requires 12 characters” in your SSP; the rule doesn’t say that. EXAMPLE, NOT A MANDATE

Where the 15-character claim comes from

Fifteen is the headline number from NIST SP 800-63B-4, the Digital Identity Guidelines finalized in 2025. That document requires single-factor passwords to be at least 15 characters, prohibits composition rules, and discourages forced periodic changes absent evidence of compromise. It’s strong, modern guidance. But CMMC Level 2 is pinned to NIST SP 800-171 Rev. 2, which does not adopt 63B-4’s specific numbers. So 15 is a benchmark you can cite to justify your policy — not a CMMC safe harbor, and not a substitute for the four assessment objectives inside 3.5.7. MODERN BENCHMARK

Where the 16-character claim comes from

Sixteen is a Rev. 3 story. NIST published SP 800-171 Revision 3 in May 2024, and in April 2025 DoD published organization-defined parameters (ODPs) for Rev. 3. DoD’s ODP 03.05.07.f sets a 16-character minimum and prohibits a password containing the user’s account name or full name. But 32 CFR 170.14(c)(3) still maps current CMMC Level 2 to Rev. 2. So the 16-character figure would control a CMMC assessment only after DoD updates the program’s governing baseline through rulemaking. FUTURE WATCH

The uncomfortable part — and the upside

CMMC does not hand you a single password configuration to copy.You have to define several values yourself — complexity, length, changed characters, history — and that flexibility becomes an assessment burden the moment your policy, your platform settings, your SSP, and your test evidence stop matching. An assessor grades you against your own written definitions.

The upside is real: you are notstuck adopting some punishing legacy setting just because a competitor’s blog called it “the CMMC requirement.” You get to choose values that fit your environment, that you can technically enforce everywhere, and that you can demonstrate on demand.

Why are CMMC password requirements so confusing in 2026?

The confusion comes from different sources answering different questions. Current CMMC uses NIST SP 800-171 Rev. 2. Assessment guidance supplies examples. NIST SP 800-63B-4 supplies modern digital-identity guidance. DoD’s Rev. 3 parameters preview a future baseline. Mix those layers and you manufacture “requirements” that don’t exist.

Think of it as four stacked layers, only one of which controls your assessment right now:

1. The controlling CMMC baseline — 32 CFR 170.14(c)(3) + NIST SP 800-171 Rev. 2. This is what an assessor scores.
2. How the objectives get assessed— NIST SP 800-171A + the CMMC Assessment Guide (Level 2). This is how they judge “met.”
3. Modern password-security guidance — NIST SP 800-63B-4. Useful for justifying your choices.
4. The future watch — NIST SP 800-171 Rev. 3 + DoD’s Rev. 3 ODPs. Prepare; don’t implement as CMMC yet.

The interpretation rule that saves you: a newer publication is not automatically the current CMMC requirement. The CMMC rule has to adopt the newer baseline through rulemaking before it controls an assessment. Until DoD does that, Rev. 2 governs.

What does CMMC Level 1 require for passwords?

CMMC Level 1 requires covered systems to identify users, processes acting on behalf of users, and devices, and to authenticate or verify their identities before granting access. FAR 52.204-21 — the Level 1 safeguarding rule — does not set a universal minimum length, history count, composition formula, or rotation interval.

Handling FCI only does notautomatically make every Level 2 password control apply. Don’t let anyone talk you into a Level 2 identity redesign until your solicitation, flow-down obligations, information type, and assessment scope actually support it. If you’re unsure whether you touch CUI at all, resolve that first — start with our FCI vs. CUI guide or the Level 1 self-assessment walkthrough.

What does CMMC Level 2 require for passwords?

CMMC Level 2 applies the password requirements in NIST SP 800-171 Rev. 2 to the assets inside your CMMC assessment scope, according to how each asset is categorized under 32 CFR 170.19. Requirements 3.5.7 through 3.5.11 cover complexity, history, temporary passwords, cryptographic protection, and authentication feedback. MFA (3.5.3) is a related but separate requirement.

One nuance that trips people up: the requirements don’t apply identically to every box in your building. Under 32 CFR 170.19, CUI Assets are assessed against all Level 2 requirements; Security Protection Assets are assessed against the requirements relevant to the protection they provide; and Contractor Risk Managed Assets and Specialized Assets get different treatment the rule spells out. Get your scoping right first (see our scoping guide); it decides where these controls even land.

Does CMMC require password changes every 60 or 90 days?

Current CMMC Level 2 does not impose one universal 60- or 90-day expiration interval. It requires immediate replacement of temporary passwords (3.5.9), a defined changed-character rule when passwords are changed (3.5.7), and whatever additional change events or schedule your organization chooses and consistently enforces.

Say it precisely, because the wording matters at assessment. Don’tclaim “CMMC prohibits 90-day rotation” — it doesn’t; you may still choose an interval. Dosay “CMMC does not mandate a universal periodic interval, and current NIST guidance discourages arbitrary rotation.” If you drop periodic expiration, write the 63B-4 rationale into your policy so an assessor sees a deliberate, defensible choice rather than an oversight. OUR EDITORIAL CALL

How many previous passwords must CMMC remember?

CMMC Level 2 requires reuse to be prohibited for a specified number of generations (3.5.8), but it does not supply one universal history count. You choose the number, document it, enforce it across every applicable system, and be able to demonstrate that an old password can’t be reused within that window.

Two nuances decide whether you actually meet this. First, “prevent reuse of the current password” is not the same as a multi-generation history — some platforms only do the former by default. Second, don’t let your SSP promise more depth than your weakest in-scope system can enforce. If different applications support different maximum histories, document that reality.

Does CMMC require a breached-password blocklist?

The active NIST SP 800-171 Rev. 2 password requirements do not mandate screening against a breached-password blocklist. NIST SP 800-63B-4 requires it as modern digital-identity guidance, and DoD’s Rev. 3 parameters build it into “Password Management” — but neither is the current universal CMMC Level 2 rule.

This is a genuinely useful control, and it’s where the standard is heading. Under Rev. 2, blocklist screening is a defensible enhancement you can add — not a line an assessor scores against 3.5.7 through 3.5.11 today. Treat “compromised-password screening” as a Rev. 3 / 63B-4 alignment move, filed under MODERN BENCHMARK and FUTURE WATCH, not ACTIVE REQUIREMENT.

Is a written password policy enough for CMMC?

No. Where 3.5.7 and 3.5.8 apply, assessors determine whether you defined the required values and whether the technical environment enforcesthose same values. A policy without matching configuration and test evidence can leave one or more assessment objectives NOT MET — and that costs points.

The mental model that survives an assessment has three layers, and you need all three:

In practitioner discussions we reviewed for this article, contractors describe assessors declining “administrative only” documentation and asking to see the technical control behind it. The fix is boring and effective — reconcile the SSP, the configuration, and the test evidence for each objective before anyone shows up.

What should a CMMC password policy contain?

A defensible CMMC password policy identifies every applicable password-bearing account and system, states your organization-defined values for complexity, changed characters, and history, and describes how temporary passwords, storage, transmission, recovery, exceptions, and evidence are controlled. It should promise only what you can technically enforce and test.

Use this as your table of contents. It maps to the five requirements plus the operational reality assessors probe:

1. Purpose and applicable CMMC level
2. Assessment scope and covered systems
3. Account types: human, privileged, shared, local, service, application, appliance, emergency
4. Minimum length or equivalent complexity parameters (your chosen values)
5. Required character properties
6. Changed-character requirement (the number)
7. Password-history generations (the number)
8. Temporary-password provisioning and immediate change
9. Default-credential change
10. Password reset and identity-verification procedure
11. Compromise-triggered response
12. Storage protection (hashing, where you control the store)
13. Transmission protection (protected channels)
14. Authentication-feedback behavior
15. Password-manager rules
16. Passwordless, recovery, and fallback paths
17. Service-account and non-human credential handling
18. Exceptions and formal approvals
19. Technical enforcement locations (which system enforces what)
20. Evidence owner and retention
21. Testing cadence
22. Approval and review date

How do Active Directory, Entra ID, SaaS apps, and passwordless change the answer?

The governing objectives don’t change because your architecture changes — but their applicability, the enforcement point, and the evidence do. You have to map every password path — cloud-only, synchronized, local, application, service, recovery, and emergency accounts — to the system that actually defines and enforces each setting.

The Defense Compliance Report environment implementation framework — OUR EDITORIAL CALL

The Entra-only detail worth knowingverified July 11, 2026

Microsoft documents that cloud-only Entra ID accounts use a predefinedpassword policy — an 8-character minimum, a 256-character maximum, three-of-four character-category complexity, and a rule that prevents immediately reusing the currentpassword — and its core length and complexity settings can’t be customized for cloud-only accounts. Synchronized users may instead be subject to on-premises Active Directory password policy, and password writeback can enforce on-premises policy for supported cloud reset or change paths. The result depends on the account source, the reset or change path, and how writeback is configured. (Platform settings change; re-confirm current Entra behavior at each policy review.)

Don’t turn this into “Entra passes” or “Entra fails.” The right question is which objectives are customer-managed, which are inherited from Microsoft, which you can technically enforce, and which you can evidence in your specific architecture.

Do service accounts and non-human accounts have to meet the CMMC password requirements?

There’s no categorical CMMC exemption for service or non-human accounts. Applicability depends on the asset category, the authentication mechanism, and the assessment objective. Managed identities, certificates, or other non-password mechanisms may remove a password path entirely, but any remaining passwords on in-scope accounts must be inventoried and assessed.

This is one of the most common blind spots. Teams lock down interactive user accounts and forget the service account running a backup job, the local admin on an appliance, or the API credential in an application config. If a service account authenticates with a password and it’s in scope, the password requirements reach it — and 3.5.10 (cryptographic protection) is the one that bites hardest here, because service-account credentials so often end up in scripts and config files in the clear. Where you can, replace the password path with a managed identity or certificate and document that in the SSP.

Does CMMC require a specific account-lockout threshold?

AC.L2-3.1.8 requires you to limit unsuccessful logon attempts, but the active baseline does not prescribe one universal attempt count or lockout duration. You set the threshold and behavior, document them, and enforce them. This is a related access-control requirement — worth one point — not one of the five password-specific Identification and Authentication requirements.

The mechanics mirror the password controls: the rule leaves the number to you, and the objective is that you defined a limit and your systems enforceit. Note that DoD’s Rev. 3 parameters would prescribe a specific lockout threshold in the future — another FUTURE WATCH item — but under Rev. 2, the count is yours.

Does MFA replace CMMC password requirements?

No — not where passwords remain part of authentication. NIST SP 800-171 Rev. 2 states that 3.5.7 applies to single-factor password authentication and when passwords are used as part of multifactor authenticators. So MFA does not erase the need to define and enforce the applicable password requirements.

MFA under IA.L2-3.5.3 carries a five-point deduction when it isn’t implemented, and a three-point deduction in the limited partial case — either way, above the one-point POA&M ceiling, so it can’t be deferred. It matters enormously, but it doesn’t cancel the password requirements wherever a password is still one of the factors. What MFA doeschange is what’s defensible: NIST SP 800-63B-4 permits shorter (8+) passwords when the password is used only as one factor within MFA. That’s a benchmark, not an automatic CMMC pass. Passwordless designs can change which mechanisms are applicable, but recovery and fallback paths may still use passwords and must be inventoried.

Are password managers allowed under CMMC?

CMMC does not categorically prohibit password managers, and current NIST digital-identity guidance encourages permitting them (including autofill and paste). But no password manager is automatically “CMMC compliant.” You must evaluate its scope, access controls, authentication, recovery, storage and transmission protections, administrative model, and evidence.

Vendors love the phrase “CMMC compliant.” Treat it as a claim to investigate, not a certification category. Here’s the buyer checklist to run:

One myth to kill: do not assume every password manager “must be FIPS validated.” Whether a FIPS 140 validation question is even implicated depends on the tool’s function, whether it handles CUI, and which controls you’re relying on it to satisfy. That’s an analysis, not a blanket rule.

How many CMMC points are password controls worth, and can they go on a POA&M?

The five password-specific Level 2 requirements expose nine points of deduction: one point each for 3.5.7, 3.5.8, 3.5.9, and 3.5.11, plus five points for 3.5.10. The one-point requirements can be placed on a POA&M if every 32 CFR 170.21 condition is met. IA.L2-3.5.10 carries a five-point deduction and is not POA&M-eligible.

For the record, 32 CFR 170.21 also names six one-point requirements that still can’t be deferred: AC.L2-3.1.20, AC.L2-3.1.22, CA.L2-3.12.4, PE.L2-3.10.3, PE.L2-3.10.4, and PE.L2-3.10.5. None of the five password controls is on that list, so 3.5.7, 3.5.8, 3.5.9, and 3.5.11 are genuinely POA&M-eligible once you clear the thresholds above. But a POA&M is not evidence that a requirement is met, and it is never the plan for the five-point 3.5.10. ACTIVE REQUIREMENT

One more thing worth knowing: a NOT MET requirement can be re-evaluated during the certification assessment and for 10 business days after the active assessment period, if you can produce additional evidence and the findings report hasn’t been delivered (32 CFR 170.17). So a gap caught at assessment isn’t always fatal — but a five-point, non-deferrable requirement that’s still NOT MET when the result is finalized is.

Are CMMC password assessment results posted in SPRS or eMASS?

It depends on the assessment type.For a CMMC Level 2 self-assessment, your organization enters the result in the Supplier Performance Risk System (SPRS). For a Level 2 certification assessment, the C3PAO enters the result in the CMMC instantiation of eMASS, which transmits your CMMC status to SPRS. The separate DFARS 252.204-7019/-7020 NIST SP 800-171 assessments are a different track. If you’re working out which posting obligation applies, our self-assessment vs. C3PAO guide walks through it.

What evidence will a CMMC assessor examine, interview, and test?

Assessors may examine policies, procedures, SSP statements, and configuration records; interview the people responsible for identity and authenticator management; and test the mechanisms that create, change, store, transmit, and display passwords. The strongest package maps each artifact and test directly to one NIST SP 800-171A objective.

Two operational points that catch teams off guard. First, for a Level 2 certification assessment, evidence artifacts must be hashed with a NIST-approved algorithm and retained for six years from the CMMC Status Date (32 CFR 170.17). Build that into how you store evidence from day one. Second, tests that align to the objectives include: rejecting a password that violates your documented complexity rule; attempting a change that violates the changed-character rule; attempting reuse inside the configured history; logging in with a temporary password and showing the forced replacement; showing protected transport and password-storage design; and showing obscured entry with non-revealing errors.

A word on CUI in evidence: never capture actual password values in any artifact. Minimize CUI in evidence, and handle any CUI-containing artifact only through the assessment team’s approved secure process.

What are the most common CMMC password mistakes?

The most common failure isn’t picking the “wrong” popular number — it’s treating a recommendation as a mandate, or writing a policy the in-scope environment doesn’t actually enforce. The rest come from omitted account types, untested recovery paths, mislabeled requirements, weak storage evidence, and unsupported product-compliance claims.

The checklist to run before a readiness review:

1. Calling 12 characters the universal CMMC minimum (it's an assessment-guide example).
2. Calling 15 characters the active universal DoD requirement (it's 63B-4 guidance).
3. Applying the Rev. 3 parameters as though they control current Level 2 (they don't until rulemaking).
4. Treating 60- or 90-day rotation as universally required (no universal Rev. 2 interval).
5. Writing "24-password history" when some in-scope systems enforce only one — or none.
6. Treating MFA as an exemption from the password controls.
7. Omitting local, appliance, application, vendor, service, recovery, and break-glass accounts.
8. Mapping password reuse to 3.5.10 instead of 3.5.8 — an error we found in guidance we reviewed for this article.
9. Mapping compromised-password screening to Rev. 2's 3.5.9 — that's the temporary-password control; blocklists are a Rev. 3 / 63B-4 concept.
10. Treating a tool's capability as proof the control operates in your environment.
11. Failing to separate inherited from customer-managed controls.
12. Storing credentials in tickets, documents, scripts, spreadsheets, or reversible fields.
13. Producing screenshots that don't show the effective configuration or scope.
14. Copying another company's policy without testing your own environment.
15. Overpromising in the SSP.

What we actually verified — July 11, 2026

For this article we read and cross-checked: 32 CFR §§ 170.14, 170.16, 170.17, 170.19, 170.21, and 170.24; NIST SP 800-171 Revision 2 §3.5; NIST SP 800-171A; the CMMC Assessment Guide — Level 2, version 2.13; DFARS 252.204-7012, -7019, -7020, -7021, and -7025; the DoD Procurement Toolbox Cybersecurity FAQ (revision 4, June 13, 2024); Class Deviation 2024-O0013; NIST SP 800-63B-4; DoD’s April 2025 NIST SP 800-171 Revision 3 organization-defined-parameters memorandum; and Microsoft’s Entra ID password documentation. We also reviewed the leading guidance published on this topic in July 2026 and compared how each source labeled the governing version, minimum length, rotation, history, requirement mapping, point value, and POA&M treatment — which is how we identified the mislabeled requirements and blurred source layers noted above. Where a figure is an example, a benchmark, or a future parameter rather than an active requirement, we labeled it that way on purpose.

What should you do next to make your password controls assessment-ready?

Confirm your contract-required CMMC level and assessment scope first, then inventory every in-scope password path before you choose values. Define the values, map each to an enforcement point, resolve unsupported systems, test every objective, update the SSP, and preserve dated evidence before you calculate your score.

1. Confirm level and scope. Read the solicitation or contract. FCI vs. CUI. Level 2 self-assessment vs. C3PAO. Set your assessment boundary and categorize your assets under 32 CFR 170.19.
2. Inventory every authentication path. Users, privileged accounts, local accounts, service accounts, applications, appliances, SaaS, recovery, emergency access, vendor support.
3. Choose and approve your values. Complexity, minimum length, changed-character number, history generations, and any change events or interval you elect.
4. Map values to enforcement points. GPO, Entra, MDM, SaaS, local policy, application code, vault, appliance.
5. Resolve mismatches. Change the configuration, narrow the policy language, replace unsupported mechanisms, redesign an account path, or document shared/inherited responsibility. Get qualified advice for applicability or formal equivalency questions.
6. Test each objective— not just “can the user log in,” but the precise define-and-enforce objective.
7. Update the SSP and evidence index.Record requirement, implementation, owner, system, evidence, test result, date, residual gap, and the score/POA&M consequence.

Most teams can self-serve steps 1 through 4 in a week of focused work. Steps 5 through 7 are where scale, provider access, and evidence volume decide whether you finish in-house or bring in help.

Frequently asked questions

What is the minimum password length for CMMC Level 2?

The active CMMC Level 2 baseline does not state one universal minimum length. Under NIST SP 800-171 Rev. 2 requirement 3.5.7, your organization defines and enforces its minimum password complexity, including any minimum length it sets. The CMMC Assessment Guide — Level 2 mentions 12 characters as an example, not a universal mandate.

Does CMMC require 12-character passwords?

No. Twelve characters appears as a Potential Assessment Considerations example in the CMMC Assessment Guide — Level 2, version 2.13. The same guidance states that minimum complexity requirements are left to the organization to define, so 12 is an example rather than a rule.

Does CMMC require 15-character passwords?

Not as a current universal Level 2 requirement. Fifteen characters is the NIST SP 800-63B-4 minimum for single-factor passwords, but current CMMC Level 2 maps to NIST SP 800-171 Revision 2, which does not adopt that figure. It's a strong benchmark to justify your policy, not a CMMC mandate.

Does CMMC require 16-character passwords?

Not under the current CMMC Level 2 rule. Sixteen characters is DoD's published organization-defined parameter for NIST SP 800-171 Revision 3 (ODP 03.05.07.f), while 32 CFR 170.14(c)(3) still maps current Level 2 to Revision 2. Treat it as a future-baseline item, not today's requirement.

Does CMMC require password changes every 90 days?

No universal 90-day interval exists in the active Level 2 requirements. Temporary passwords must be changed immediately (3.5.9), and your defined change-of-characters and history rules apply whenever passwords change. Any periodic interval is an organizational choice, and current NIST guidance discourages arbitrary rotation.

How many old passwords must CMMC remember?

CMMC does not set one universal number. Requirement 3.5.8 requires reuse to be prohibited for a specified number of generations, and NIST SP 800-171A tests whether you specified that number and technically enforce it. Twenty-four is a common default but is not mandated.

Does CMMC require a breached-password blocklist?

Not under the active NIST SP 800-171 Revision 2 password requirements. NIST SP 800-63B-4 requires blocklist screening as modern guidance, and DoD's Revision 3 parameters build it into "Password Management," but neither is the current universal CMMC Level 2 rule. It's a defensible enhancement to adopt now, not a requirement assessors score against 3.5.7–3.5.11 today.

Does CMMC require uppercase, lowercase, numbers, and symbols?

Requirement 3.5.7 requires minimum password complexity, and the assessment guide discusses character types, but you must state and enforce your own organization-defined complexity baseline. Don't convert an example character formula into an unsupported universal mandate in your SSP.

Does MFA replace CMMC password requirements?

No, wherever passwords remain part of authentication. NIST SP 800-171 Rev. 2 states that 3.5.7 applies to single-factor password authentication and when passwords are used as part of multifactor authenticators. MFA (3.5.3) is a separate, required control.

Can a passwordless environment avoid the password controls?

Possibly for a specific mechanism with no password, but not automatically for the whole assessment scope. Recovery, bootstrap, break-glass, local, application, appliance, and service-account paths may still use passwords and must be assessed individually.

Can Microsoft Entra ID meet CMMC password requirements?

Entra ID provides important identity protections, but its cloud-only core password policy is largely predefined (an 8-character minimum, with stricter enforcement typically requiring hybrid accounts that inherit Active Directory policy or password writeback). Whether the objectives are MET depends on your tenant architecture, inherited versus customer-managed responsibilities, remaining password paths, policy wording, and evidence.

Are password managers CMMC compliant?

CMMC does not certify a password-manager product as universally compliant, and "CMMC compliant" is a marketing claim to investigate. Current NIST digital-identity guidance permits password managers and autofill, but you must evaluate the specific tool's scope, authentication, recovery, storage and transmission protections, administration, and evidence.

Must a CMMC password manager be FIPS validated?

Not as a blanket rule. Whether a FIPS 140 validation question is implicated depends on the tool's function, whether it handles CUI, and which controls you rely on it to satisfy — so it's an analysis, not an automatic requirement.

Can a password requirement go on a POA&M?

The one-point password controls (3.5.7, 3.5.8, 3.5.9, 3.5.11) can be POA&M-eligible if all 32 CFR 170.21 conditions are met, including an overall score of at least 88 and a 180-day closeout. IA.L2-3.5.10 carries a five-point deduction and is not eligible for the Level 2 POA&M path.

What does "change of characters" mean in 3.5.7?

It refers to the number of character positions that must differ when an existing password is changed, relative to the total length. Your organization defines that number, and 3.5.7 requires you to enforce it when a new password replaces an old one.

What evidence should I keep for CMMC password controls?

Keep the approved policy, SSP implementation statements, effective configuration exports, identity and application architecture, inherited-control documentation, test results, relevant logs, and a mapping that ties each artifact to the applicable NIST SP 800-171A objective. For certification assessments, evidence artifacts must be hashed and retained for six years from the CMMC Status Date. Never store actual password values as evidence.

Primary and official sources

• 32 CFR Part 170 (CMMC Program Rule) — § 170.14 (CMMC levels; Level 2 = NIST SP 800-171 Rev. 2), § 170.16 (Level 2 self-assessment), § 170.17 (Level 2 certification assessment), § 170.19 (assessment scope and asset categories), § 170.21 (POA&M requirements and exclusions), § 170.24 (CMMC Scoring Methodology and point values)
• NIST SP 800-171 Revision 2, §3.5 (Identification and Authentication)
• NIST SP 800-171A(assessment objectives for 3.5.7–3.5.11) — NIST CSRC
• CMMC Assessment Guide — Level 2, version 2.13 (12-character example; organization-defined complexity)
• DFARS 252.204-7012, -7019, -7020, -7021, and -7025 — Acquisition.gov
• DoD Class Deviation 2024-O0013 (DFARS 252.204-7012 pinned to NIST SP 800-171 Rev. 2)
• FAR 52.204-21 (Level 1 basic safeguarding; FCI definition)
• NIST SP 800-63B-4 (Digital Identity Guidelines; 15-character single-factor minimum, 8-character in-MFA minimum, no composition rules, no periodic rotation, blocklist screening)
• DoD Procurement Toolbox Cybersecurity FAQ (revision 4, June 13, 2024), Question 53 — dodprocurementtoolbox.com
• DoD Organization-Defined Parameters for NIST SP 800-171 Revision 3 (April 2025), ODP 03.05.07.f — dodcio.defense.gov
• Microsoft Entra ID password policy documentation(cloud-only predefined policy; synchronization and password writeback) — Microsoft Learn