IA.L2-3.5.7 Password complexity requirements and evidence

IA.L2-3.5.7 password complexity: what the requirement asks for

IA.L2-3.5.7 requires an organization to define a minimum password complexity and a minimum number of characters that must change whenever a new password is created, and to enforce both rules at the moment the password is set. If your organization handles controlled unclassified information (CUI) and any system on that boundary accepts local or network passwords, you need a written password standard and proof that every system applies it. The CMMC Level 2 requirement is the Revision 2 version of NIST SP 800-171 requirement 3.5.7, a derived requirement in the Identification and Authentication family. It is worth 1 point under the scoring methodology in 32 CFR 170.24. The requirement does not give you fixed values. Your organization chooses the minimum length, the character classes that must appear (such as uppercase letters, lowercase letters, numbers and symbols) and the number of characters that must differ from the previous password. An assessor will test whether the values you chose are defined and whether they are enforced.

The risk is straightforward. Weak passwords fall to guessing and credential-stuffing attacks, and predictable patterns, such as a season and year with a single symbol appended, let an attacker move from one account to the next after a single success. A rule that only changes one character in a password gives little protection, because a user can rotate between near-identical values. Enforcement at creation time matters because a policy document that no system checks does not stop a weak password from being set. The assessment objectives in NIST SP 800-171A ask for both the definition and the enforcement, so a written policy alone will not satisfy the requirement.

The rule is simple to write and hard to apply consistently. Every system that creates or changes a password must enforce the same settings, including directory services, the identity provider, local administrator accounts on servers and workstations, network devices, databases and line-of-business applications that keep their own credential stores. Start by listing every place a password can be created in your CUI boundary, then record the setting each one enforces. Confirm the exact requirements with your assessor or the CMMC Assessment Guide for Level 2, since the guide leaves the minimum values to the organization. Where a system cannot enforce your rule, document the gap and the compensating control before the assessment, because an undocumented exception will be treated as a failure.

Which systems and accounts the password complexity rule covers

The password complexity rule applies to every authenticator inside the CUI boundary, not only the accounts that look most sensitive. Each card below is a scoping decision that changes the policy, the configuration evidence and the assessor's sampling, and each one should be settled in the system security plan before configuration work starts.

Directory-based user accounts

Accounts held in a central directory such as Active Directory or an LDAP service usually carry most of the password load for CUI users. Confirm whether the directory's password policy is the single enforcement point for complexity and change-of-character rules, or whether applications apply their own. If an application accepts passwords outside the directory, it falls inside the scope of IA.L2-3.5.7 Password complexity and needs its own configuration evidence.

Local accounts on servers and workstations

Local administrator and local user accounts on Windows, Linux and macOS hosts often sit outside the directory policy and are easy to miss in scope reviews. Inventory every host that processes or stores CUI, then record how each host's local password settings are enforced, whether by group policy, configuration management or a hardening baseline. Assessors commonly sample these hosts, so the settings must match the documented rule.

Network devices and appliances

Firewalls, switches, routers, load balancers and storage appliances frequently ship with local login accounts that do not use the corporate directory. Decide which of these devices sit inside the CUI boundary, then confirm whether each device can enforce complexity and change-of-character requirements. Where a device cannot, document the limitation in the system security plan and the plan of action for the gap, and check that the device's administrators are covered elsewhere.

Cloud and SaaS tenants that still use passwords

Many cloud and SaaS platforms let administrators set their own password rules, while others hand sign-in to a federated identity provider. Record each tenant that holds CUI, note whether passwords are still a sign-in method, and confirm the tenant's configurable complexity and change settings. Federated sign-in moves enforcement to the identity provider, so the scope document should say which system enforces the rule for each tenant.

Break-glass and service accounts

Emergency administrator accounts and service accounts are often exempted from password rules for operational reasons, which is a common source of assessment findings. Include them in scope, list each one with its owner and the system it authenticates to, and confirm the complexity and change-of-character settings that apply. Where a service account must use a secret that cannot follow the human password policy, record the compensating approach and its approval in the system security plan.

Third-party and managed service provider accounts

Accounts used by vendors, managed service providers and support engineers to administer systems that hold CUI are part of your scope even when another organization operates them. Confirm in the contract and the provider's own documentation that these accounts meet the same complexity and change rules, and retain evidence of that configuration. Ask providers which of their administrative identities are shared, since shared accounts complicate both enforcement and assessment.

Why defining the rule is not the same as enforcing it

Assessors score IA.L2-3.5.7 as two separate halves, and an organization can fail either one. The first half is definitional: the organization must state, in writing, the minimum password complexity and the minimum number of characters that must change when a new password is created. The second half is operational: the systems that set or change passwords must actually apply those rules at the moment a password is chosen. NIST SP 800-171A breaks the requirement into four assessment objectives for exactly this reason, two for defining the rules and two for enforcing them. A complete policy document with no enforcement behind it satisfies only the first half, and the requirement is not met.

The failure that catches organizations most often is a mismatch between the written policy and the configured system. A policy may require a mix of uppercase, lowercase, numbers and symbols with a minimum length, while the directory, identity provider or application actually accepts a shorter or simpler password. The reverse also fails the assessment, because an assessor will compare the documented value with the live configuration and expect them to agree. Before the assessment, pull the password policy from each system that creates or changes credentials, including the directory, any identity provider such as authentik, and standalone applications with local accounts, and confirm each one matches the written rule. Keep the export and the date it was taken as evidence.

The CMMC Assessment Guide Level 2 leaves the specific complexity values to the organization, so the numbers in your policy are a decision you must justify. Record the reason for the minimum length, character classes and changed-character count, and tie it to your risk assessment, the authenticators in use and any stronger controls such as multifactor authentication, which relate to IA.L2-3.5.3. Confirm the chosen values with your assessor's expectations or the C3PAO scope before the assessment, since the guide does not fix them. Then apply the same values across every boundary system in scope, so the policy, the configuration and the justification all describe one rule.

How an assessor tests password complexity under the assessment objectives

This table compares the four NIST SP 800-171A objectives behind IA.L2-3.5.7, the test an assessor runs for each, the evidence requested and the findings that most often cause a gap. Read each row as one objective that must be satisfied with final evidence, because the requirement is MET only when every applicable objective is met.

Assessment objective	Test approach	Evidence requested	Common findings
Define password complexity requirements	Read the password policy and authenticator management procedures, then confirm the complexity rule names the character mix and minimum length the organization chose.	Approved password policy in final form, with an effective date and an owner; complexity parameters stated in the policy.	Policy says only strong passwords are required with no measurable rule; draft or unsigned policy; complexity defined in one document and contradicted in another.
Define change-of-character requirements	Confirm the policy states how many characters a new password must differ from the previous one, and whether that rule applies to every password change.	Policy clause stating the minimum number of changed characters; procedure that explains how the rule is applied on reset and change.	No minimum changed-character count defined; rule applies only to user-initiated changes and not to administrator resets.
Enforce complexity on new passwords	Attempt to set passwords that break each complexity rule in the live or staging directory, identity provider or endpoint configuration, and record whether each attempt is rejected.	Password configuration exports, screenshots or settings files showing the active complexity values; test log of rejected non-compliant passwords.	Setting exists in policy but is not applied to a directory or application; a second system or local account store accepts weak passwords; service accounts exempt without documented approval.
Enforce change-of-character on new passwords	Set a password that shares too many characters with the current one and confirm the system refuses it, then repeat for an administrator-initiated reset.	Configuration evidence for the changed-character setting; test record showing rejection of a too-similar password across both change paths.	Setting not enforced on password reset or initial set; system compares only exact matches and not character changes; no test record exists.
Review the password configuration and documentation	Compare the policy, procedure and configuration side by side to confirm they describe the same settings, owner and scope.	Configuration baseline, change history for password settings, and sign-off showing the policy matches the running configuration.	Configuration drifted after an upgrade; documentation describes settings the system does not use; no change control on password parameters.
Test the password-based authenticator mechanism	Sample several accounts across user, administrator and service types and confirm each one is subject to the same complexity and change rules.	Sample list of accounts with the policy applied to each, and any approved exceptions with a documented reason.	Exceptions granted informally; legacy applications keep local password stores outside the policy; sample limited to a single account type.
Confirm final evidence before assessment	Check that every artifact is complete, dated and approved, since drafts do not count toward a MET result.	Final versions of policy, procedure, configuration exports and test records, each with a date and an accountable owner.	Evidence collected as screenshots without dates; policy revised after the test was run; evidence from a non-production environment only.

How to implement and document password complexity in six steps

This sequence takes an organization from an inventory of every place passwords are created to a documented, tested and periodically re-verified complexity rule that an assessor can trace from policy to configuration to evidence. Each step ends with an artifact the reader keeps for the system security plan and the assessment file.

Inventory every system that creates or changes passwords
Start by listing each place a user, service or administrator can create or change a password: directory services, identity providers, endpoint operating systems, applications with local accounts, network devices, databases and any cloud consoles in scope. Record the owner, the authentication source and whether the system is inside the CMMC assessment boundary. The output is a password-creation inventory that the system security plan can reference. Confirm the list with system owners, because local accounts on appliances are the most common gap.
Define complexity values and the changed-character minimum
Write the password policy in terms the assessor can test: a minimum length, the character classes required (numbers, lowercase and uppercase letters, and symbols), and a minimum number of characters that must differ from the previous password whenever a new one is created. The CMMC Assessment Guide leaves the exact values to the organization, so record a short rationale for each value tied to the threat model and to the controls that interact with it, such as lockout and MFA. Have the policy approved by the people who own the risk, and keep the approved version with its date.
Map each system to its enforcement setting
For every inventoried system, identify the exact setting that enforces the policy: a directory password policy object, an identity provider flow or policy, a local security policy on endpoints, or an application configuration key. Record the setting name, its current value and the place it is stored. Where a system cannot enforce the complexity or changed-character rule natively, note it now so it can be handled in step five. The output is a traceability table linking policy clauses to configuration objects, which is the first thing an assessor will ask for.
Configure enforcement and test with rejected passwords
Apply the settings and then prove they work by attempting to set passwords that should fail: one too short, one missing each required character class, and one that differs from the previous password by fewer than the required number of characters. Repeat the attempts on each system type in the map, and record the time, account, result and error message. Include at least one accepted password that meets every rule to show the control does not block valid choices. Keep the screenshots, logs or command output as dated evidence, and confirm that final, not draft, configuration is what was tested.
Document exceptions and compensating controls in the POA&M
Where a system cannot enforce the rule, record the exception with the system name, the reason, the risk accepted, the compensating controls in place and the owner who signed off. Under the scoring rules in 32 CFR 170.24, IA.L2-3.5.7 is a 1-point requirement and is not on the exclusion list in 32 CFR 170.21, so it may appear on a POA&M for Conditional Level 2 status if the score qualifies. Confirm the current POA&M eligibility rules and closeout expectations in the eCFR text and with your sponsor before relying on them. Keep the exception record in the same evidence file as the policy and test results.
Schedule periodic re-verification and change review
Set a recurring check that re-runs the rejected-password tests against each system in the map, and add a trigger to re-verify after any change to directory policies, identity providers, endpoint baselines or application upgrades. Review the exception list at the same time to confirm that compensating controls are still operating. Automated configuration checks, such as those in Wazuh's Security Configuration Assessment or Fleet policies that report which devices pass or fail a query, can produce recurring evidence, but confirm each tool covers the specific setting. The closing artifact is a dated re-verification record that ties back to the policy version.

Which self-hosted open-source tools can support password complexity evidence

Password complexity is enforced in different places depending on the environment: the identity provider, the directory, or the endpoint itself. The four tools below each cover one of those places, so an assessor can trace a complexity setting to a configuration, a directory policy, or a device check.

authentik as the central identity provider

authentik acts as an identity provider through OAuth2, OpenID Connect, SAML, LDAP, RADIUS and proxy providers, so applications delegate sign-in to it instead of keeping their own password rules. For IA.L2-3.5.7, this lets the organization set the complexity and changed-character values once and point delegated applications at that policy. Confirm which password policy settings the version you run exposes, and test that an application that does not delegate sign-in is either brought under the policy or documented as an exception.

FreeIPA for Linux and UNIX sign-in

FreeIPA provides single sign-on for Linux and UNIX environments through an MIT Kerberos KDC, so the password policy for those hosts sits in the directory rather than on each machine. Assessors will look for the policy object that governs password creation and changes, and for evidence that hosts authenticate against it. Confirm the exact complexity and change-of-character parameters the version you deploy supports, and confirm how non-Kerberos local accounts on hosts are handled, since those can fall outside the directory policy.

Wazuh configuration checks on endpoints

Wazuh Security Configuration Assessment scans monitored endpoints against YAML policies, most of which are based on CIS benchmarks, and reports misconfigurations with remediation advice. It can show whether endpoint password settings match the policy the organization has defined, which gives assessors recurring output rather than a one-time screenshot. The bundled policies may not reflect the organization's own complexity values, so a custom check must be written to test those exact values and the policy must be reviewed when the defined requirement changes.

Fleet policies for device password checks

Fleet policies are yes or no questions asked of devices as osquery queries, and the policies page shows which devices in each fleet pass or fail each one. This suits checks on device-level password settings that the directory does not govern, with the failing device list serving as a remediation queue. As with Wazuh, the query has to encode the organization's own complexity and change-of-character values. Confirm that the osquery tables you rely on expose the setting on each operating system in scope, because a query that returns no data can look like a pass.

What evidence assessors accept for password complexity

Assessors accept evidence in two parts: a written password policy that defines the complexity rules and the number of characters that must change when a password is created, and proof that the system enforces those rules on every new password. The policy must be approved, dated and final. Include the minimum length, the required mix of character types, and the minimum number of changed characters, along with the approval record showing who signed it and when. The assessment objectives in NIST SP 800-171A divide this requirement into defining the rules and enforcing them when passwords are created, so a policy alone does not close the requirement. Tie the policy to the system security plan so the assessor can see which systems in the boundary inherit it.

Enforcement evidence is what usually decides the finding. Export the password configuration from each directory, identity provider and local policy store in scope, and date each export. Screenshots work only when they show the setting in effect and carry a timestamp. Pair the configuration with test records: attempt to set a non-compliant password and capture the rejection, then set a compliant password and capture the acceptance. Endpoint or directory compliance reports can show the setting across the boundary, for example a configuration check that flags devices where the rule is not applied. Where a platform such as Wazuh or Fleet runs a yes or no check against devices, keep the failing and passing results with the date of the run.

Keep this evidence current between assessments by scheduling the configuration exports and retaining each one with its date, rather than producing a single snapshot before the assessment. Attach a change record whenever the policy or a directory setting is revised, including the old values, the new values and the approver. Exceptions need a documented justification, an owner and an expiry date, because an unexplained exception is treated as a gap. Confirm with your assessor which evidence formats and retention periods they expect, and confirm with your C3PAO or your own compliance lead how the Phase I self-assessment will be recorded in the SPRS, since the current requirement status depends on those records.

What password complexity costs to meet and what drives it

This table lists each cost component of meeting IA.L2-3.5.7, who is paid for it, whether it is one-time or recurring, and what moves it up or down. Use the last column as a checklist when you request written quotes, since no price or hour figure is supplied for this requirement. The main takeaway is that open-source tools remove license spend but not the engineering, testing and evidence work that the assessor will examine.

Cost component	One-time or recurring	What drives it up or down	What to ask for in a quote
Identity or policy tooling	One-time setup, recurring hosting and upkeep	Number of applications and directories that must enforce the same policy. Self-hosted open-source options such as authentik or FreeIPA remove license spend but still need infrastructure and administration time.	Named tools, license terms, hosting components, and whether each application is covered by the central policy or needs its own setting
Engineering time to configure each system	One-time, with later changes	Count of systems that create or change passwords, including directories, endpoints, applications and any local accounts. Systems that cannot enforce the policy centrally add manual work.	A system-by-system list of password settings to be configured, with the owner and the change procedure for each
Policy definition and drafting	One-time, with periodic review	Clarity of the complexity rule (character mix and length) and the changed-character rule, both of which the organization must define. Ambiguous or inconsistent definitions cause rework during assessment.	A draft policy text covering the defined complexity and changed-character values, and the reviewer and approval steps
Testing and rejected-password verification	One-time per system, repeated after changes	Number of password-setting paths (new account, reset, self-service change). Each path needs a test showing that noncompliant passwords are rejected and compliant ones accepted.	A test plan listing each password path, the test cases, and the saved results in final form
Evidence upkeep and periodic re-verification	Recurring	Frequency of configuration changes, staff turnover and the number of systems in scope. Evidence gathered once and not refreshed becomes stale when the assessor reviews it.	A schedule for re-collecting configuration exports and test results, and the owner responsible for each
External review of the policy and configuration	Periodic, often before an assessment	Whether internal staff can independently review the policy and settings. Outside review adds cost but can surface gaps before the assessor does.	Review scope, the reviewer's qualifications, and the written findings and remediation steps delivered
Assessor fees (certification assessment)	Recurring per assessment cycle	Scope size, number of assessed systems and the assessor's time on this requirement. Fees are set by the assessor, not the implementation partner. Level 2 certification assessments are performed by C3PAOs, and self-assessments carry no assessor fee.	A written assessment scope, the fee basis, and confirmation of whether the requirement is in scope for the cycle you plan
Scoring impact and POA&M exposure	Conditional status only, time-limited	IA.L2-3.5.7 is worth 1 point under 32 CFR 170.24. It may go on a POA&M for Conditional Level 2 status if the score is at least 88 of 110, with closeout due within 180 days. Leaving it unmet risks falling below that threshold when combined with other gaps.	Confirm the current score position and the closeout plan with your sponsor or C3PAO, and check the current status of CMMC Phase II before planning dates

Who owns password complexity, what a partner can do, and where the auditor stops

Your organization owns the password policy. That includes choosing the minimum complexity values, the number of characters that must change when a password is replaced, the approval path for any exception, and the decision to accept residual risk. These are business and security decisions, and an assessor will ask who made them and when. Nothing in CMMC tells you which specific values to pick, so the values must be justified in your own documentation rather than copied from a vendor default.

Set the policy values: Record the minimum character classes, length, and minimum number of changed characters, and state which systems each value applies to.
Approve and version the policy: Keep a dated, approved policy that a named owner maintains, with a revision history.
Govern exceptions: Define who may approve a deviation, how long it lasts, and what compensating control applies.
Accept the risk: Document who signs off on any gap, including any requirement placed on a plan of action and milestones.
Keep the policy aligned with the system security plan: The policy should match what the SSP says about authentication.

Before an assessment, confirm that the policy names an owner and that the approved values match what the systems actually enforce.

Password complexity questions buyers ask before hiring help

How much effort does password complexity enforcement take to implement?

The effort depends mostly on how many systems create or change passwords and how many of them already delegate sign-in to a central identity provider. A single directory with one password policy is a small job. Ten standalone applications, network devices and databases that each store their own passwords is a much larger one, because each system needs its own configuration, test and evidence. Effort also rises when the organization has no written password policy yet, since the policy must define the minimum complexity and the minimum number of changed characters before any system can be configured to match it. Ask any provider to break the work down by system so you can see where the effort sits.

Can our own IT team handle password complexity without outside help?

Yes, if your staff can configure and test each system that creates passwords and can keep the evidence current. The assessment objectives for IA.L2-3.5.7 require the organization to define the complexity and changed-character rules, then show they are enforced whenever a new password is created. That means your team must be able to demonstrate the settings, run test password changes that the system rejects when they fall short, and retain the policy, configuration exports and test results. If nobody on the team can reproduce those tests for each system, or evidence tends to drift out of date between reviews, outside help is worth considering for the setup and the evidence design.

How long does password complexity work take from start to finish?

The duration depends on the scope, so it should be set out in a written scope before work starts rather than estimated from a general rule. The main variables are the number of password-creating systems, whether a central identity provider already exists, how many systems need configuration changes that users will notice, and how quickly your policy owner approves the rules. Fixed-scope engagements list the systems, deliverables and timeline in writing, which lets you check progress against the plan. Ask for the schedule to show separate milestones for policy approval, configuration, testing and evidence collection.

What do we need to provide if we bring in a partner for this work?

Your organization keeps ownership of the controls, so several inputs must come from your side. You need a named owner who can approve the password policy, including the minimum complexity and the number of characters that must change. You need an owner for each in-scope system who can grant access in your own environment, whether that is your cloud account, data center or air-gapped network. You also need someone to review changes that affect users and to confirm that the evidence reflects how systems actually behave. A partner can prepare the configurations and evidence, but it cannot approve your policy or stand in for the independent assessor who judges the result.

Does the 1-point score and POA&M eligibility make password complexity less urgent?

The score makes it less of a gating item, but it does not make it optional. IA.L2-3.5.7 is worth 1 point under the scoring methodology, and it is not on the exclusion list that bars POA&M items, so it can appear on a plan of action and milestones when the overall score qualifies for Conditional Level 2 status. The qualifying score and the 180-day closeout period come from 32 CFR 170.21 and 170.24. Two cautions apply: a POA&M item still requires a real remediation plan with a closeout date, and a POA&M cannot be used for requirements that are excluded from it. Confirm the eligibility rules against the current eCFR text before you rely on them in a contract decision.

Does the Phase II suspension change what we need in place now?

No. The Department of War suspended CMMC Phase II on 13 July 2026, but Phase I self-assessments, SPRS postings, annual affirmations and DFARS 252.204-7012 obligations remain in place. That means the Level 2 requirements, including IA.L2-3.5.7, still matter for the self-assessment and the score you post. Because the suspension may change which assessments are required, check the current status on the DoW CIO About CMMC page and your contracting officer's instructions, and keep your password evidence current either way. Waiting for a later phase to start work leaves you exposed to the requirements that already apply.

How DeployOpen scopes and prepares password complexity evidence

DeployOpen works on IA.L2-3.5.7 Password complexity as a fixed-scope implementation task inside your own environment. We configure the password policy and enforcement points on the self-hosted identity and endpoint platforms you own, then document the evidence an assessor will review, while your organization keeps ownership of the control and the assessment decision.

How we scope

Written scope names every system that creates or changes passwords for CUI-scoped accounts.
Scope lists the complexity and changed-character rules your organization has defined as the policy baseline.
Scope states which assessment objectives are covered and which evidence items the engagement will deliver.

How we build

Configure password policy settings in the identity provider so complexity and changed-character rules apply at every new password.
Set up endpoint policy checks that report whether managed devices and directories meet the defined password settings.
Test enforcement by attempting non-compliant password changes and recording the rejected results as evidence.

How we hand over

Deliver the written password policy, configuration exports and a test record that maps results to each assessment objective.
Document the procedures your staff follow to change, reset and review password settings after handover.
Walk your assessment team through the evidence so they can confirm it is in final form before any assessor review.

How we support

Ongoing support and upgrades of the password platform are available as a retainer under a separate written scope.
Retainer work can include repeating enforcement tests after platform upgrades or policy changes.
Confirm with your assessor or certification body which evidence format they accept before the engagement closes.

IA.L2-3.5.7 Password complexity