The written policy says twelve characters with complexity and quarterly change. The domain says eight characters, complexity enabled, no expiry, and there are three fine-grained policies applying different rules to groups nobody remembers creating. That gap between the document and the configuration is where password attacks succeed, and it is measurable in an afternoon.
Finding out what is really set
Read the default domain policy, then look for fine-grained password policies applied to specific groups, since those override it and are frequently used to relax rules for service accounts or executives. Check the lockout settings, the minimum length and whether complexity is enabled, then compare all of it against what your written policy claims. Then check the accounts that sit outside all of it: service accounts flagged so the password never expires, accounts with reversible encryption enabled, and any account created before the current policy was applied, since existing passwords are not re-evaluated when a policy changes. Those older accounts are frequently the ones with the most access.
Complexity produces predictable passwords
A requirement for upper case, lower case, a number and a symbol tends to produce a capitalised word, a year and an exclamation mark. Attackers know this and their wordlists are built around it. The NCSC’s password guidance for system owners has argued for years against enforced complexity and periodic expiry, recommending length, a blocklist of common and compromised passwords, and account monitoring instead. Those three changes make a measurable difference where complexity rules simply move everyone to the same predictable pattern.
“The measurement that changes minds is cracking. We take the hashes with permission, run them offline for a day, and report the percentage recovered along with the patterns. When a director sees that a third of the domain fell in twenty-four hours and that their own password was among them, the policy conversation takes about five minutes.”
William Fieldhouse, Director, Aardwolf Security Ltd
Blocking the passwords that will be guessed
A blocklist does more for you than any complexity rule. Microsoft’s password protection blocks common and organisation-specific terms, and the on-premises agents extend that to accounts in the domain rather than only in the cloud directory. Add your company name, your products, your town and your football club, because those appear in every list an attacker builds for a targeted spray. Seasonal words belong there too, since a surprising number of passwords are simply the current month. Combine it with a longer minimum length, which most users accommodate by choosing a phrase rather than a word once they are told why the change is happening.
Measuring rather than assuming
Test the outcome, not the setting. An Active Directory security assessment can include a password audit against the domain, reporting the proportion recovered, the patterns in use, and which privileged accounts appear in the results. That gives you a number to improve rather than a policy to argue about, and repeating it annually shows whether the changes worked. Keep scheduled vulnerability assessments running alongside, since a strong password on an unpatched server protects very little.
See also: Who Is Liable When Driver-Assist Technology Fails to Detect Smaller Vehicles?
Frequently asked questions about password policy
These questions come up whenever an authentication policy is reviewed.
Should passwords expire?
Not routinely. Forced expiry encourages small predictable changes, and the NCSC has recommended dropping it for years. Change passwords when there is a reason, such as suspected compromise or an account appearing in breach data.
What length should you require?
Twelve characters as a minimum for user accounts, longer for privileged and service accounts where the password is stored rather than typed. Pair it with a blocklist, because length alone does not prevent somebody choosing a common phrase.
