Cyber Essentials Password Policy Explained

The three valid password approaches

Cyber Essentials follows NCSC's modern password guidance. You don't need brutal complexity rules and forced 90-day resets. You do need one of the following three approaches on every account that authenticates a person:

1. MFA + minimum 8-character password (the default for cloud services)
2. Minimum 12-character password (no MFA – acceptable but uncommon)
3. Minimum 8-character password with breached-password screening or rate-limiting

For cloud services, option 1 (MFA + 8 chars) is the default and the easiest to evidence. See our MFA requirements page.

What "breached-password screening" means

The system checks new and existing passwords against a known list of breached passwords (e.g. Have I Been Pwned's database) and rejects them. Microsoft Entra ID does this automatically with the global banned password list. Google Workspace flags compromised passwords. Most modern IAMs include this for free.

What "rate-limiting" means

The system limits how often someone can attempt a password – e.g. 10 wrong attempts then a lockout, or progressive delays. This is usually built in to cloud platforms but worth confirming.

What NCSC moved away from

NCSC's modern guidance, which CE now follows, explicitly steps back from:

• Forced periodic resets. Don't force users to change passwords every 60/90 days. It encourages weak, predictable passwords.
• Brutal complexity rules. "At least one uppercase, one lowercase, one number, one symbol" generates predictable patterns.
• Password hints. They leak.
• Knowledge-based recovery questions. "Mother's maiden name" is publicly searchable.

You don't need to remove these if you have them – CE doesn't ban them. But the modern direction is length + MFA + breach screening, not complexity + rotation.

The written password policy

You need a short, written password policy that covers:

• Minimum length (8 with MFA, 12 without)
• That breach screening or rate-limiting is in place where MFA isn't
• That passwords must not be reused across personal and work accounts
• That credentials must not be shared
• What happens if a credential is suspected compromised (reset + investigate)
• The leavers process for credentials

One page, plain English, signed off by a director, distributed to staff.

Service accounts and break-glass admin accounts

These can't always have MFA (a script can't satisfy a push notification). The acceptable approach:

• Very long unique passwords (16+ characters, randomly generated)
• Stored in a password manager or vault, not in a script or wiki
• Tightly restricted use – only for the specific automation
• Monitored access (sign-in logs reviewed)
• Documented exception in the submission

Password managers

CE doesn't mandate a password manager but strongly favours them. If you use one (1Password, Bitwarden, Dashlane, LastPass, Keeper), put it in the policy and have staff actually use it. The benefit is real: long unique passwords per account become trivial.

Passkeys and passwordless

The Danzell question set explicitly accepts passkeys (FIDO2) as a valid MFA method. Where you can move to passkeys (Microsoft 365, Google Workspace and many SaaS apps now support them), it's the strongest authentication you can deploy. CE treats passkey + PIN/biometric as MFA.

Common password policy fails

1. Policy says "12 characters minimum" but the M365 tenant enforces only 8
2. Service accounts using short shared passwords
3. Policy on paper, no breach screening enabled in the IAM
4. Forced 30-day resets still in place – not a fail, but a flag for a stale policy
5. One legacy account exempted from MFA "because it broke a script"

The 15-minute password audit

1. Confirm minimum password length is set in the IAM (Entra / Google) and matches your written policy
2. Confirm breached-password protection is enabled in the IAM
3. Confirm MFA is enforced for every interactive user
4. List service accounts; confirm long unique passwords stored in a vault
5. Update the written policy and have a director sign it