The settingWhat we hold this to
CreativeTechs minimum
Password protection mode = Enforce. Enforce custom list = true, with at least 10 client-specific terms (company name, product names, town, local teams). Smart lockout threshold ≤ 10, lockout duration ≥ 60 seconds. On-prem enforcement = true where a DC exists.
Benchmark position
EIDSCA.PR01 mode 'Enforce'; PR03 custom list 'True'; PR05 lockout duration recommended 60 seconds; PR02 on-prem enforcement 'True'. Our 60s floor is exactly the EIDSCA figure.
Where we differ, and why
EIDSCA publishes no threshold figure; the ≤10 attempts floor is ours.
Where the switch is
Entra admin centre → Protection → Authentication methods → Password protection.
How to verify
Graph: /beta/settings → values where name in ('BannedPasswordCheckOnPremisesMode','EnableBannedPasswordCheck','EnableBannedPasswordCheckOnPremises','LockoutDurationInSeconds','LockoutThreshold')- Why it matters
- Blocks the passwords that actually get sprayed. The custom list carries the client's own name, town, teams and product names — what a targeted spray tries first.
- How we check
- Maester EIDSCA.PR01, PR02, PR03, PR05.
- Fix — M365
- Entra → Authentication methods → Password protection → custom list = Yes, mode = Enforced, lockout threshold and duration set. Populate per client.
- Fix — Google
- Admin → Security → Password management → length and reuse rules.
- User notices
- None until someone tries a banned password at next change.
- Expected pushback
- None. Four settings on one screen, currently at Microsoft's permissive defaults on our own tenant.
