3.5.7 — Password Rules

What It Says

Enforce a minimum password complexity and change of characters when new passwords are created.

What It Actually Means

Three things the assessor checks:

Minimum length. 14+ characters is current best practice per NIST SP 800-63B. Eight characters is too short — modern GPUs crack 8-character passwords in hours.

Complexity. Mix of character types (upper, lower, numbers, special) or long passphrases. Azure AD Password Protection can block common passwords and patterns.

Change of characters. When a user creates a new password, it must differ meaningfully from the old one. Not just incrementing a number (Password1 → Password2) or changing one character. This is hard to enforce technically — but blocking common passwords and enforcing length helps.

Organizations may also consider salting stored password hashes — adding a unique random value to each — to blunt brute-force and precomputed-hash attacks.

A note on forced rotation: NIST SP 800-63B no longer recommends forcing periodic password changes unless there’s evidence of compromise. The reasoning: forced rotation leads to weaker passwords (users pick predictable patterns). However, check your specific contract requirements — some may still mandate rotation.

The assessor will check your password policy configuration settings, not just the policy document.

Pass or Fail

Your assessor needs a “yes” to every row:

#	Question	What “yes” looks like
1	Are the password complexity requirements defined?	A written standard sets minimum length and character mix (e.g., 14+ characters)
2	Is the required change of characters defined?	The standard specifies how much a new password must differ from the previous one
3	Is the minimum password complexity enforced when new passwords are created?	GPO/Entra rejects passwords that don’t meet the length/complexity rule at the moment of creation
4	Is the change-of-characters requirement enforced when new passwords are created?	New passwords that don’t differ enough are blocked — password history/similarity checks active

What to Have Ready on Assessment Day

Documents they’ll review: Identification and authentication policy; procedures addressing authenticator management; system security plan; system configuration settings showing password policy

People they’ll talk to: Personnel with information security responsibilities; system or network administrators

Live demos they’ll ask for: Mechanisms enforcing password complexity and change requirements

The Assessor’s Playbook

These are the actual questions. Have answers ready.

“What is your minimum password length? Show me the configuration.”
“What complexity requirements do you enforce?”
“How do you prevent users from making trivial changes to passwords?”
“Do you block common passwords? Show me the configuration.”
“Do you force periodic password rotation? What’s the interval? Why?”

Where Companies Trip Up

8-character minimum. Still the default in many AD deployments. Change it to 14+. The assessor will check the actual GPO setting.

No banned password list. Users choose ‘CompanyName2024!’ which meets complexity but is trivially guessable. Azure AD Password Protection blocks these.

Policy says 14 but system enforces 8. The written policy and the technical configuration don’t match. The assessor checks the system, not the document.

Forced rotation creating weak patterns. Monthly rotation leads to ‘January2024!’, ‘February2024!’. Consider removing forced rotation per NIST 800-63B guidance if your contract allows.

How to Talk About This

Connected Requirements

Requirement	Why it matters here
3.5.8 — No Password Recycling	Password history prevents cycling back to old passwords
3.5.10 — Never Plain Text	These passwords must be hashed/encrypted, never stored in plain text
3.5.3 — MFA Everywhere	MFA compensates for password weaknesses — defense in depth