Multi-factor authentication for Cyber Essentials v3.3: the complete pillar guide

Multi-factor authentication for Cyber Essentials v3.3: the complete pillar guide

MFA is the top reason Cyber Essentials submissions fail under v3.3. It is also the single most impactful cyber control an organisation can implement - underwriters weight it heavily, assessors check it on every sign-in, and it blocks the majority of account-compromise attacks.

This pillar explains exactly what v3.3 requires, how to implement MFA cleanly across a mixed environment, and how to document it for the Cyber Essentials assessor.

For pricing, see Cyber Essentials pricing. To start certification, see /cyberessentials.

What v3.3 actually says about MFA

From 28 April 2026, Cyber Essentials v3.3 requires multi-factor authentication on every user account that accesses organisational data. This is different from the earlier "MFA where risk-based" language and removes the conditional-access wiggle-room that existed under v3.2.

Specifically:

MFA is not required on every individual device unlock - that is separately covered by secure configuration. It is required on the authentication event that grants access to organisational data.

Which MFA methods are acceptable

Under v3.3 the following are acceptable in descending order of strength:

The assessor's test is not which method you picked - it is whether every user has MFA enabled and enforced.

MFA rollout for Microsoft 365

Default on Security Defaults is the fastest path to a passing CE submission for small organisations. For 100+ user tenancies, Conditional Access with "require MFA for all users" is the cleanest implementation. Key steps:

1. Enable Security Defaults (Entra admin centre → Properties → Manage Security defaults).

2. Enforce MFA registration within 14 days for all existing users.

3. Disable legacy authentication protocols (IMAP, POP, basic auth) - these bypass MFA.

4. Configure number-matching on Microsoft Authenticator push to prevent MFA fatigue.

5. For admin accounts, require a hardware security key as the primary factor.

See MFA for Microsoft 365 step-by-step for the detailed configuration.

MFA rollout for Google Workspace

Google Workspace handles MFA via 2-Step Verification:

1. Admin console → Security → 2-Step Verification → Enforce for all users.

2. Set enforcement date 14 days out so users can enrol.

3. Allow all methods except SMS for admins; allow SMS only as a fallback for end users.

4. For admin accounts, require a security key.

5. Disable "less secure app" access for any Workspace domain.

MFA for cloud services beyond M365 / Workspace

Every SaaS tool that holds organisational data is in scope. Typical enforcement:

• Identity provider integration (SSO). Route every SaaS through Okta, Entra ID, Google Workspace, or JumpCloud so MFA happens once at the IdP. This is the cleanest pattern and is what most CE Plus audits expect.
• Per-tool MFA. If a SaaS has no SSO (common in smaller tools), enforce MFA in the tool directly. Most SaaS now support this.
• Conditional-access rules. If your identity provider supports conditional access, enforce MFA on every sign-in rather than "trusted location" exemption.

MFA for admin accounts

Admin and privileged accounts have three additional requirements under v3.3:

1. Strongest factor available - hardware key or FIDO2 wherever possible.

2. No shared admin accounts - every named admin has their own login with MFA. Shared accounts are a v3.3 fail.

3. Break-glass accounts documented - emergency accounts must be MFA-protected, sealed, monitored, and audited.

MFA for contractors and consultants

Contractors who access your organisational data need MFA, on an account provisioned under your identity provider. "They have an account in their own company" is not acceptable - the access must be under your control and MFA enforced.

See Cyber Essentials BYOD rules 2026 for how contractor devices fit into scope.

MFA exceptions (and why they are rare)

Under v3.3, legitimate exceptions are:

• Service accounts used by software (not humans). These cannot use MFA but must be documented, scoped tightly, and monitored. Assessors ask why each service account exists and what compensating controls protect it.
• Legacy systems that cannot do MFA. These must be isolated from organisational data or removed. "We have one old system with no MFA" is a v3.3 fail unless isolated.

There is no exception for "senior staff who find MFA inconvenient". Assessors treat this as a control failure.

How the Fig Group assessor tests MFA

During a CE self-assessment, we verify from your responses and evidence:

1. The identity provider has MFA enforced on every user.

2. Conditional-access policies do not permit "no MFA" from any network.

3. Admin accounts have the strongest available factor.

4. No shared accounts exist.

5. Legacy authentication is disabled.

For CE Plus, we additionally test MFA live during the remote audit - see the CE Plus remote audit guide.

Common MFA failures and their fixes

Bottom line

MFA under v3.3 is simple in principle and strict in practice. Every user, every cloud service, every admin, every contractor. Strong factors for admins. Documented exceptions only for service accounts and isolated legacy systems.

Get this right and the MFA portion of CE is straightforward. Get it wrong and the submission fails on this one question alone.

Get Cyber Essentials in 6 hours | Buy CE Micro £299.99 | See pricing