IA.L2-3.5.7Password Complexity
Enforce a minimum password complexity and change of characters when new passwords are created.
[a]
password complexity requirements are defined;[b]
password change of character requirements are defined;[c]
minimum password complexity requirements as defined are enforced when new passwords are created; and
Passphrase floor with a program-name banned list; character-change only where the DC sees it
Implementation
AO coverage. Claims [a] (complexity requirements defined), [b] (change-of-character requirements defined), and [c] (complexity enforced when new passwords are created). Objective [d] (change-of-character requirements enforced) is not claimed here. It is enforced only where the password change flows through a domain controller; cloud-only accounts and the two apps with local passwords cannot compare a new password against the previous one, so the enforcement is partial and we say so rather than claim the objective.
Defined complexity [a]. 14-character minimum for standard accounts, 20 for anything on the privileged inventory, with passphrases encouraged over character-class gymnastics. A custom banned list blocks company and program names, product line codes, the town we are in, and seasons — the strings that actually showed up in past audits.
Defined change of characters [b]. Written standard: a new password must differ from the previous one by at least four character positions, and incrementing a trailing digit or year does not count as a change. Minimum password age of one day prevents cycling through history in a single sitting.
Enforcement at creation [c]. Password Protection evaluates the banned list for both cloud and on-prem changes via the DC agent. A fine-grained password policy applies the longer floor to the privileged OU. Apps with local passwords enforce length and the banned list through their own policy settings, verified during the quarterly configuration review.
Maintenance. Quarterly banned-list refresh as new program names and part-number prefixes appear. After any published credential-stuffing campaign against our sector, compare enclave accounts against a breached-password service where the platform supports it.
Accepted gap. One customer portal caps passwords at 12 characters and strips symbols. That credential is vault-generated, unique, never reused elsewhere, and the portal is reached only from a privileged access workstation.
What the evidence looks like
- Password standard document with the length floors and the change-of-character rule
- Password Protection configuration including the custom banned list
- Fine-grained password policy export scoped to the privileged OU
- Screenshots of a rejected weak password on both cloud and on-prem change paths
- Limitation record for objective [d] and the 12-character portal exception
Environment
Tools
Was this example useful?
Quick reaction — no account needed. For reasoning that moves the community meter, cast a full verdict below.
Discussion(0)
No discussion on this example yet
Verdicts capture a conclusion. Use a thread when the interesting part is the argument.
Sign in to start a thread.