Password complexity is one of the easiest practices if you’re using Windows or a modern cloud identity provider. They have complexity enforcement built in, and it’s on by default. The assessor usually confirms it’s configured and moves on.
The gotcha is when you have systems with passwords that aren’t subject to your complexity policy. A legacy application with simple passwords. Local accounts that don’t require complexity. Service accounts set to simple values. That’s where the finding comes from. You need to address all the places passwords exist in your environment. This works alongside IA.L2-3.5.8 (password reuse) and IA.L2-3.5.10 (password protection) to create a complete password security model.
What the assessor is actually evaluating
The assessor wants to confirm that you have a password policy with minimum complexity requirements and that you’re enforcing it. They’ll ask what your requirements are: minimum length, character types, and so on. Then they’ll ask how you enforce it. For domain accounts in Windows, Group Policy. For cloud, identity provider policies. For legacy systems, application-level enforcement or documented justification for why complexity can’t be enforced.
If you say “we require 12 characters, uppercase, lowercase, numbers, and special characters,” and they pull up your Group Policy and see exactly that configured, you’re done.
What a realistic SSP definition looks like
Practice IA.L2-3.5.7: Password Complexity Requirements
All user accounts with password-based authentication must adhere to minimum complexity requirements. These requirements are enforced by the systems where accounts reside.
Standard User Accounts:
Domain user accounts (Windows Active Directory) are subject to the following Group Policy password complexity requirements:
- Minimum password length: 12 characters
- Must contain characters from at least three of the following categories: uppercase letters (A-Z), lowercase letters (a-z), numbers (0-9), special characters (!@#$%^&*, etc.)
- Passwords cannot be changed more frequently than once per day
- Passwords do not expire if updated consistently
This policy is enforced at the domain level and applies to all domain-joined computers.
Cloud accounts (Microsoft 365/Azure AD) are subject to Azure AD password policies enforcing:
- Minimum 8 characters
- Complexity checks built into Azure AD
The Azure AD standard is less stringent than domain password policy, but Azure accounts are further protected by MFA which exceeds complexity requirements in terms of strength.
Service Accounts:
Service accounts that require password-based authentication are assigned randomly generated passwords of at least 16 characters including uppercase, lowercase, numbers, and special characters. These passwords are stored in [credential vault] and rotated every 90 days.
Legacy Systems:
[If applicable] Legacy application accounts are managed separately. Where the legacy system enforces its own password policy, that policy is required to meet complexity standards of at least 10 characters and mixed character types. Where the legacy system cannot enforce complexity, accounts are documented in our exception log with business justification.
Password History:
We maintain a password history requirement preventing reuse of the last [5 / 10 / 24] passwords. This is configured in Group Policy for domain accounts and in identity provider policies for cloud accounts.
This is straightforward. The assessor reads it and knows your requirements. If they pull up Group Policy and see matching settings, they move on.
How to present your evidence
- Password policy document stating complexity requirements
- Group Policy screenshot showing complexity settings (minimum 12 characters, mixed case, numbers, special characters)
- Cloud identity provider configuration showing complexity enforcement
- Service account documentation showing strong password generation requirements
Your evidence is simple:
Your password policy document. Can be part of your IT Security Policy or Access Control Policy. Just list the complexity requirements.
Group Policy screenshot or export. If you use Windows, open Group Policy Editor and navigate to Account Policies > Password Policy. Screenshot or export the settings. They should match your documented policy.
Azure AD or identity provider policy screenshot. If you use cloud authentication, show the password policy settings from your identity provider’s admin portal.
Service account documentation. Show that service accounts use strong random passwords. The actual passwords stay in the vault, but you can show the policy requiring strong service account passwords.
That’s it. This is a quick evidence check.
Keep answers short. Show the evidence, don't describe it. Let the assessor drive. For more on how to present in the assessment room, see How to Present Evidence in the Assessment Room.
Common failures
Short, practical breakdowns of what assessors actually ask and how to answer. No compliance jargon, no sales pitch. Subscribe free on Substack.
If you use an MSP or MSSP
Your MSSP should have configured your password policies during onboarding. For domain accounts, they set Group Policy. For cloud accounts, they configured Azure AD or your identity provider. The policy should already be in place and enforced.
Ask your MSSP: “Show me the password policy you’ve configured for our domain and cloud accounts.” They should pull it up immediately. If they have to think about it, that’s a gap.
In the assessment, the contractor can describe the requirements, and the MSSP can show the configuration. Easy division of labor.
This guidance is based on assessment room experience and reflects one practitioner’s interpretation of CMMC Level 2 requirements. It is not legal or compliance advice. Always consult your compliance team and official CMMC documentation for final guidance.