Cyber Essentials Password Policy Guide

By Mat at INLine Computers · Updated 15 April 2026 · Reading time: about 12 minutes

What changed in v3.3

Cyber Essentials v3.3 — released by IASME and NCSC in February 2026, mandatory for all assessment accounts created from 27 April 2026 — introduced what's known as the Danzell question set. The v3.3 changes are evolutionary rather than revolutionary, but two of them have real teeth for password policy:

1. The 12-character minimum is now the default, not the 8-character path. The 8-character + blocklist route still exists but assessors are now actively pushing organisations off it.
2. MFA is mandatory on every cloud service that supports it. If MFA is available on a service — even on the free tier, even if you'd have to pay extra for it — and you haven't enabled it, that's an automatic fail under the Danzell marking criteria.

Several smaller updates round out the password section:

• The definition of "cloud service" now covers any service accessed via a business email or account, including free SaaS tools you might not have in your asset list.
• Home routers used by remote workers must have default passwords changed and current firmware.
• Bring-Your-Own-Device (BYOD) password policy must be technically demonstrable, not just documented.
• Passkeys are now formally recognised as MFA (FIDO2 authenticators are accepted).

The 12-character rule, explained properly

The single most-asked question I see in IT support communities is "what's the minimum password length for Cyber Essentials now?" The honest answer is "it depends on whether you have MFA," and the table below is the practical version:

Note that the legacy 8-character route is increasingly hard to defend at audit. If a service supports 12+ chars and your policy is set to 8, you'll be asked why. Set the technical control to the highest practical minimum on every system you control.

Practical recommendation: set 14 characters as your organisation-wide default, with 16 for admin accounts and 32 for service accounts. This clears every Cyber Essentials requirement in one pass and gives headroom for the next revision. You can generate compliant passwords here.

MFA on every cloud service

This is the requirement that catches the most organisations off-guard at v3.3 audit. The Danzell marking criteria are explicit: if MFA is available on a cloud service and it isn't enabled, that's an automatic fail. Three things organisations get wrong here:

• Shadow IT. Employees signing up for free SaaS tools using business email — Notion, Trello, Calendly, Loom, ChatGPT, the lot. Each one is in scope. Auditors will sample employees and ask them to demonstrate logging into "any tools they use for work." If any are accessed without MFA, you fail.
• Free-tier MFA gates. Some services (looking at you, Zoom, Slack on free) used to gate MFA behind paid plans. Most have moved it to the free tier under regulatory pressure, but check each one. If MFA requires paying for the next tier up, the v3.3 rules still expect you to enable it — paying isn't an exemption.
• Identity provider blind spots. Centralised SSO via Entra/Okta/Google with conditional access enforcing MFA looks great in the dashboard. But if an employee can also log in with a local username/password fallback to the app directly, that bypass route is in scope.

The remediation order: SSO everything you can, enforce MFA via the IdP, disable local logins on apps where SSO is configured, and audit your asset list against actual employee usage (not assumed usage).

Common-breach blocklists

Where the 8-character path is still in use (or, increasingly, where assessors are pushing you to add one anyway), you need to block common breached passwords. The minimum standard is to block the top 1,000 most common passwords from publicly available breach data.

Practical implementations:

• Active Directory: Specops Password Policy, Enzoic, or Specops Breached Password Protection layer onto your existing AD password policy and check against Have I Been Pwned and similar feeds.
• Microsoft Entra ID: the built-in custom banned password list (up to 1,000 entries) plus Microsoft's automatic global banned list covers the requirement at no extra cost.
• Google Workspace: the password policy includes basic strength enforcement; layering a third-party tool is usually needed for true breach blocking.
• Bespoke applications: implement a check against the SHA-1 prefix range of Have I Been Pwned's password API at registration and password change time. Free, anonymous, well-documented.

For passwords generated by the tool on this site, the probability of accidentally generating a string containing one of the top 25 common passwords as a substring is essentially zero — but we check anyway, because doing so demonstrates the policy intent in audit.

Brute-force protection

Either of two technical controls satisfies this requirement:

• Account lockout after no more than 10 unsuccessful authentication attempts. Lockout duration must be enough to make brute-force impractical (usually 15-30 minutes, or until manually unlocked for high-value accounts).
• Throttling that introduces a meaningful delay between attempts (e.g. exponential backoff: 1s, 2s, 4s, 8s, …) such that brute-force is computationally infeasible.

For most modern systems (Windows AD, Entra ID, Workspace, Okta) this is on by default with sensible thresholds. The audit failure case is usually a custom or legacy application where the developer never implemented either.

What to stop doing

Several practices that were standard a decade ago are now actively counterproductive — and an auditor seeing them in your policy is a red flag for "not paying attention to current guidance":

• Forced 30/60/90-day password rotation. NCSC dropped this years ago. It produces weaker passwords (people just append a number), more reset tickets, and zero security benefit. Rotate when there's a reason: breach, suspicion, leaver, role change.
• Complexity requirements without length. "Must contain uppercase, lowercase, number, and symbol" is meaningless if the password can be 8 chars. Length matters far more than character variety beyond a basic threshold.
• Password hints stored on the system. Reverse-engineerable, leaked in breaches, banned implicitly under the "no easily guessable password" requirements.
• "Three security questions" as a recovery mechanism. Mother's maiden name and first pet are findable on most people's social media. Use email-based reset with a TTL'd link, plus MFA on the recovery channel.
• SMS as the sole MFA factor on high-value accounts. Better than nothing, but vulnerable to SIM-swap. Push-app or authenticator-app preferred, hardware token (YubiKey, etc.) for admin accounts.

A compliant password policy in 8 paragraphs

This is a starting point you can adapt — not legal advice. Have your CE assessor or a competent IT consultant review before adopting.

1. Scope. This policy applies to all user accounts, administrative accounts, and service accounts accessing organisational data on systems owned, managed, or used by [Organisation], including cloud services accessed via business email addresses.
2. Length and composition. User account passwords must be a minimum of 14 characters. Administrative account passwords must be a minimum of 16 characters. Service account passwords must be a minimum of 32 characters and randomly generated. All passwords must be unique to a single account.
3. Multi-factor authentication. MFA is mandatory on every cloud service that supports it, regardless of plan tier. Authenticator apps or hardware tokens are preferred over SMS where available. Administrative accounts require hardware-token MFA where supported.
4. Blocked passwords. Passwords containing entries from the published top-1000 most common passwords (refreshed annually) and any password appearing in known breach data (via Have I Been Pwned or equivalent) are not permitted. Technical controls enforce this at password creation and change.
5. Brute-force protection. Accounts lock after 10 unsuccessful attempts; lockout persists for 15 minutes minimum or until manually released. Where lockout is not technically possible, exponential throttling is implemented.
6. Password change. Passwords are not required to change on a fixed schedule. They must be changed on suspected compromise, on user request, on role change requiring privilege adjustment, and at initial assignment.
7. Storage. Users are required to use the organisation's approved password manager. Passwords must not be written down in unattended places, shared via unencrypted channels, or stored in browsers on shared devices.
8. Compromise response. Suspected compromise of any password must be reported to [security contact] within 1 working hour. Incident response procedures apply.

Audit-day checklist

Walk this list before the assessor arrives. Each item is something they may explicitly check.

• Password policy document is current (signed, dated, version-controlled, references CE v3.3).
• Active Directory / Entra ID / Workspace password policy settings match what your written policy says (length, lockout, history).
• List of every cloud service used by the organisation, with MFA status confirmed for each.
• Sample of employees can demonstrate logging into a variety of apps with MFA visible.
• BYOD policy is signed by every employee using a personal device, and technical controls (mobile app management, conditional access) are demonstrably in place.
• Home worker routers: change-of-default-password evidence (or organisation-supplied router) for everyone who works from home.
• Privileged accounts use 14+ character passwords, hardware MFA where supported, and are separate from day-to-day accounts (no domain-admin-as-daily-driver).
• Service accounts have non-interactive sign-in disabled where possible, and credentials are stored in a vault (not a spreadsheet).
• Leavers process: documented steps, recent evidence of execution (timely deactivation within 24 hours).
• Password reset process documented and tested in the last 6 months.

If your scheme starts in the next 30 days

If you've got an audit coming up and you need a triage list, in priority order:

1. MFA on every cloud service used by anyone in the organisation. This is the single most common failure mode under v3.3.
2. Increase the AD/Entra/Workspace minimum password length to 14 characters. Existing passwords don't have to change, but new ones from this point will be compliant.
3. Disable local-account logins on any app that's also accessible via SSO.
4. Document your password policy if you don't already have one, even if it's just one page.
5. Audit your shadow IT — ask each team to list every SaaS tool they use, then check each one for MFA support.

The other items (blocklists, brute-force protection on bespoke apps, BYOD technical controls) are usually one-off engineering tasks that you can plan over the following quarter once you've passed the audit on the headline items.

Need to generate a batch of compliant passwords now? Use the Cyber Essentials Password Generator on this site — it enforces the v3.3 minimums, includes the breach blocklist check, and produces CSV output ready for AD or M365 bulk import.