CMMC Level 2 Practice 3.5.7: Enforce a minimum password complexity and change of characters when new passwords are

CMMC Level 2 Practice 3.5.7 requires you to enforce minimum password complexity and ensure users actually change characters when setting a new password (for example, after a reset). Operationalize it by setting centralized password policy in your identity directory, validating it across all in-scope systems, and retaining clear configuration evidence plus test results. ¹

Key takeaways:

• You must enforce password complexity in system settings, not just in a written policy. ¹
• “Change of characters” means preventing trivial password changes during reset/change events. ¹
• Evidence is largely configuration screenshots/exports, system scope mapping, and repeatable tests showing the control operates. ²

CMMC Level 2 assessments routinely expose gaps where organizations have a password policy on paper, but inconsistent technical enforcement across real systems handling CUI. Practice 3.5.7 is one of those controls: it looks simple, but it breaks quickly in mixed environments (Windows domain + SaaS + legacy apps + local accounts). The assessor is not looking for your preferred philosophy of passwords; they are looking for consistent, technically enforced rules and proof that those rules apply to the CUI environment. ²

This requirement is mapped to NIST SP 800-171 Rev. 2 control 3.5.7 and sits in the Identification and Authentication family. ¹ You will usually implement it through a combination of: (1) an authoritative identity system (directory/SSO), (2) system-level password policy settings, (3) administrative procedures for exceptions, and (4) recurring evidence collection so you can prove the settings stayed in place.

The guidance below is written for a Compliance Officer, CCO, or GRC lead who needs to drive implementation across IT, security, and application owners without getting stuck in abstract debate.

Requirement: CMMC Level 2 Practice 3.5.7

Target keyword: cmmc level 2 practice 3.5.7: enforce a minimum password complexity and change of characters when new passwords are requirement

What the requirement says (and what it means in practice)

CMMC Level 2 Practice 3.5.7 maps to NIST SP 800-171 Rev. 2 requirement 3.5.7: “Enforce a minimum password complexity and change of characters when new passwords are [created/changed].” ¹

Practically, you need two outcomes:

1. Minimum password complexity is enforced technically for accounts that can access CUI systems (interactive users, admins, service accounts where applicable). “Enforced” means the system prevents weak passwords at creation or change time. ¹
2. New passwords must differ meaningfully from old passwords. The system should prevent trivial variations (for example, changing one character, appending a symbol, or incrementing a digit) by enforcing password history and/or “minimum password age” controls. ¹

If you cannot enforce it on a specific system, you need a documented compensating approach and a plan to eliminate or isolate the weak system from the CUI environment.

Regulatory text

Excerpt provided: “CMMC Level 2 practice mapped to NIST SP 800-171 Rev. 2 requirement 3.5.7 (Enforce a minimum password complexity and change of characters when new passwords are).” ¹

Operator interpretation:

• Define the minimum complexity rules your environment will enforce. Then configure those rules in the authoritative identity provider(s) and any standalone systems. ¹
• Configure controls that force meaningful change at password reset/change events (password history, minimum age, and related settings). ¹
• Be prepared to prove enforcement with configuration evidence and a simple test that demonstrates the system rejects noncompliant passwords. ²

Who it applies to (entity and operational context)

Entity scope: Defense contractors and federal contractors that handle CUI and are pursuing or maintaining CMMC Level 2 alignment. ³

Operational scope (what systems/accounts are in-scope):

• In-scope identities: workforce users, admins, and any accounts that can authenticate to CUI-scoped systems.
• In-scope systems: identity directories, endpoints, servers, remote access gateways, and applications that store/process/transmit CUI, plus supporting systems that provide authentication to them (for example, SSO/IdP). ²
• Where this commonly breaks: local accounts on servers, “break glass” admin accounts, network devices, legacy line-of-business apps with separate password stores, and test environments that quietly connect to production identity.

Your scoping deliverable should clearly identify the “CUI environment” boundary, then list which identity sources enforce password rules for that boundary.

What you actually need to do (step-by-step)

Step 1: Define the enforceable password standard (write it so IT can configure it)

Create a short “Password Configuration Standard” that includes:

• Complexity rules you will enforce (length, character types, prohibited patterns, banned passwords if supported). ¹
• Required controls that ensure meaningful password changes (password history size, minimum password age where supported, reset workflows). ¹
• Account categories: workforce, privileged/admin, service accounts, and emergency accounts, plus how each category is handled.

Keep this document configuration-oriented. Assessors will crosswalk it to what’s in the system settings.

Step 2: Identify your “authoritative enforcement points”

Document which systems enforce password policy:

• Windows Active Directory / Entra ID / another directory
• SSO provider policy
• MDM policy for endpoints (if it controls local password rules)
• Any application with local authentication

Your goal is fewer enforcement points. Every separate password store increases audit surface.

Step 3: Configure technical enforcement in the directory/IdP

Work with IT to implement the standard in the primary identity system(s). Then capture evidence:

• Policy settings export or screenshots
• Effective policy applied to user OUs/groups
• Exceptions list with approvals (if any)

If you have multiple directories or tenants, confirm consistency or document justified differences tied to scope boundaries. ²

Step 4: Close gaps for systems that don’t inherit central policy

For each in-scope system that does not inherit central password controls:

• Configure the local password policy to match your standard, where possible.
• If not possible, decide: isolate from CUI, move authentication to SSO, or replace the system.
• Document a compensating control only if it is concrete and testable (for example, MFA plus elimination of password-based login for that app), and be explicit about residual risk. ²

Step 5: Implement “change of characters” protections for resets and changes

Make sure password changes aren’t superficial:

• Enable password history so old passwords can’t be reused for a defined period. ¹
• Consider minimum password age to block immediate cycling back to the original password where your system supports it.
• Confirm your help desk reset process triggers the same complexity/history rules as self-service change. This is a common miss.

Step 6: Test the control in a way an assessor will accept

Create a simple test script and record results:

• Attempt to set a weak password (should fail).
• Attempt to set a password too similar to the previous password (should fail if history/anti-trivial-change controls are in place).
• Perform the test for each enforcement point (directory/IdP plus any local-auth systems).

Record the date, tester, system, and outcome. This becomes repeatable operational evidence. ²

Step 7: Put evidence collection on a recurring cadence

Practice 3.5.7 often fails at assessment because teams can’t prove ongoing operation. Set a routine to:

• Re-capture configuration exports after major identity changes
• Re-run the tests after directory upgrades, tenant changes, or onboarding new CUI applications
• Track exceptions and expiry dates

Daydream can help here by mapping 3.5.7 to a documented control narrative and scheduling recurring evidence capture so you are not rebuilding proof during assessment prep. ²

Required evidence and artifacts to retain

Keep evidence tied to the CUI environment boundary and organized by enforcement point.

Policy and standards

• Password Configuration Standard (versioned, approved)
• Access Control / Authentication policy references that point to the standard (if applicable)

Technical configurations

• Directory/IdP password policy screenshots or exports
• Group/OU scope showing which accounts the policy applies to
• Local policy configuration evidence for standalone systems
• Exception register (system, account group, justification, compensating control, approval, review date)

Operational proof

• Test results showing rejection of noncompliant passwords
• Change tickets or configuration management records for policy updates
• Admin procedures for password resets (help desk runbook)

Common exam/audit questions and hangups

Expect assessors to push on these:

• “Show me where this is enforced.” They will want settings, not just policy text. ²
• “Which systems are in-scope, and do all of them follow the same rule?” Your scope narrative must match your technical reality.
• “How do you ensure a user can’t rotate back to the previous password?” Be ready to show password history/minimum age settings. ¹
• “What about admin, service, and emergency accounts?” If you exclude them, document why and how risk is controlled.

Frequent implementation mistakes (and how to avoid them)

1. Policy-only compliance. A PDF stating complexity is not enforcement. Fix: collect configuration exports/screenshots for each enforcement point. ²
2. Ignoring local accounts and legacy apps. Fix: inventory authentication stores in the CUI environment, then eliminate or isolate local auth where possible.
3. Help desk resets bypass rules. Fix: test the reset path specifically, not just self-service change.
4. No proof of “change of characters.” Fix: enable password history (and minimum age if supported) and demonstrate it with a test. ¹
5. Untracked exceptions. Fix: maintain a living exception register with approvals and review triggers.

Enforcement context and risk implications

CMMC Level 2 is implemented through the DoD CMMC Program framework and rule structure. ³ Even without public enforcement case examples in the provided sources, the operational risk is straightforward: weak or easily rotated passwords increase the chance of unauthorized access, especially where credentials are phished, guessed, reused, or obtained from third parties. Practice 3.5.7 is also easy for assessors to validate, which makes weak evidence a common source of findings. ²

Practical 30/60/90-day execution plan

First 30 days (stabilize and scope)

• Confirm your CUI environment boundary and list all authentication sources used inside it. ²
• Publish the Password Configuration Standard in a format IT can implement. ¹
• Pull current password policy configurations from directory/IdP and identify gaps against your standard.

Day 31–60 (implement and harmonize)

• Configure directory/IdP policies to meet the standard and apply them to in-scope users/admins.
• Remediate or isolate systems with local auth that cannot meet the standard.
• Implement password history and validate the password reset workflow follows the same enforcement path. ¹

Day 61–90 (prove operation and make it repeatable)

• Run and document control tests for each enforcement point.
• Create an exception register and a lightweight review workflow.
• Set recurring evidence capture (config exports + retesting after major changes). Daydream can track evidence requests against 3.5.7 so you can produce assessor-ready packets without last-minute scrambling. ²

Frequently Asked Questions

Does CMMC Level 2 Practice 3.5.7 require periodic password expiration?

Practice 3.5.7 focuses on complexity and meaningful changes when passwords are set or changed. ¹ If you choose to enforce expiration, treat it as your internal standard and keep it consistent across in-scope systems.

What does “change of characters” mean for assessors?

It means a new password must not be a trivial variation of the previous password. ¹ The most defensible approach is enabling password history (and minimum age if supported) and demonstrating it through a test.

Are service accounts in scope for password complexity rules?

If a service account authenticates to systems in the CUI environment, treat it as in-scope unless you have a documented reason and compensating control. ² Many teams move service authentication to managed identities or certificate-based methods to reduce password risk.

We use SSO for most apps. Do we still need local password policies?

If an app truly delegates authentication to your IdP, the IdP policy is the enforcement point. ² If the app also has local accounts (admin consoles, break-glass users), you must control those separately and retain evidence.

What evidence is fastest to gather for a CMMC assessment?

Provide directory/IdP password policy configuration exports or screenshots, plus a short test record showing rejection of weak passwords and prevention of reuse. ² Add a scope map that shows which systems and account populations those settings cover.

How do we handle third-party hosted applications that have their own password rules?

If the third party app is in your CUI environment and does not support your standard, you need a decision: move it behind SSO, restrict it from CUI, or document an exception with compensating controls and a remediation plan. ²

Footnotes

1. NIST SP 800-171 Rev. 2

2. DoD CMMC Program Guidance

3. 32 CFR Part 170