Updated July 16, 2026Blog

Cyber Essentials MFA Requirements: What Changed in 2026 and How to Avoid an Auto-Fail

Table of contents

Cyber Essentials changed on 27 April 2026, and the biggest change is about MFA. Under the new Danzell question set, a single cloud service with MFA available but not enabled for every user is an automatic failure of the entire assessment — and MFA has been mandatory for every internet-facing service since the previous update. Either way, one unprotected login now costs you the certification.

For most organisations, Microsoft 365, Google Workspace, and the VPN were sorted long ago. The systems that now put certification at risk are the ones that were hardest to fix: the member portal built ten years ago, the supplier login on an on-premises web app, the admin console that never joined the SSO rollout. This guide explains exactly what the Cyber Essentials MFA requirements say as of 2026, where the auto-fail risk concentrates, and how to close legacy application gaps without rewriting code before your assessment window.

The 2026 Requirements: Willow to Danzell

Cyber Essentials is the UK government-backed certification scheme run by the NCSC with IASME as delivery partner. The requirements are versioned, and two recent versions define the current MFA picture:

Willow (Requirements for IT Infrastructure v3.2) applied to assessment accounts created from 28 April 2025. Willow made MFA mandatory for every internet-facing service — not only cloud platforms and administrator accounts — and formally recognised passwordless authentication methods such as FIDO2 passkeys, biometrics tied to device credentials, and certificate-based authentication.

Danzell (Requirements for IT Infrastructure v3.3) applies to all assessment accounts created from 27 April 2026, replacing Willow. Accounts opened before the cutover complete under Willow, certificates issued under Willow remain valid until expiry, and once an assessment account is created you have six months to complete it. The v3.3 requirements and question set are published by IASME. Danzell's headline changes for MFA sit in the marking criteria for questions A7.14 to A7.17:

MFA on cloud services is now an auto-fail. A7.16 asks whether MFA is enabled for all administrator accounts on cloud services where it is available; A7.17 asks the same for all user accounts. A single "No" on either automatically fails the entire assessment. "All users" means everyone — contractors, part-time staff, shared mailboxes — not just administrators. And it applies whether MFA is free, bundled, dependent on another service, or a paid feature; cost is explicitly not an acceptable reason. Under Willow, an MFA gap could sometimes be absorbed as a permitted non-conformity; under Danzell that flexibility is gone.
Cloud services are defined and cannot be excluded from scope. Any externally hosted, on-demand service that stores, processes, or provides access to organisational data is in scope — including free-tier SaaS accessed with a business email, and business social media accounts. If a service genuinely offers no MFA in any form you are not penalised, but you must document that you checked.
SSO alone is not MFA. Where a cloud service lacks native MFA but supports SSO with a provider such as Microsoft or Google, SSO must be used — and the SSO provider must enforce a second factor. Single sign-on without an enforced second factor does not meet the requirement.

Two clarifications assessors commonly give, worth knowing before you inventory:

SMS remains an acceptable second factor under the scheme, though stronger methods are preferred.
Internal-only systems do not require MFA. The mandate covers cloud services and services accessible from the internet. An application reachable only from the office LAN or behind a VPN is outside the MFA requirement — though the VPN itself must enforce MFA.

Danzell also introduced auto-fail criteria for patching (high-risk and critical updates within 14 days, questions A6.4 and A6.5), but MFA is where most legacy-application risk sits.

Where the Auto-Fail Risk Concentrates

For legacy admin consoles and portals that do not support MFA natively, see how Datawiza can enforce MFA for administrator accounts without rewriting the application.

The obvious systems get handled first: Microsoft 365, Google Workspace, the identity provider, VPN and remote access. The assessment risk concentrates in internet-facing applications that sit outside the identity provider:

Customer, member, supplier, or partner portals with their own local usernames and passwords
Web-based admin consoles and management interfaces exposed to the internet
On-premises web applications published externally for remote or third-party access
Vendor-supplied applications that cannot be modified on your certification timeline
Self-hosted services that now meet the Danzell cloud-service definition

These are easy to miss because nobody calls them "cloud services." The failure mechanism depends on how the application is hosted. If it is externally hosted and meets Danzell's cloud-service definition, an MFA gap trips the A7.16/A7.17 auto-fail directly. If it is self-hosted, it falls under the requirement — in force since Willow — that every internet-facing service enforce MFA; and since all five controls must be met to certify, a password-only internet-facing login fails the assessment either way. There is no remediation window: assessors expect MFA to be working at the point of assessment, and CE Plus assessors may interview staff and ask them to demonstrate logins.

The commercial stakes are the same as the certification stakes. Cyber Essentials is a prerequisite for many UK public sector contracts, and the NCSC's supply chain guidance encourages larger organisations to require it from suppliers. A failed assessment over one legacy portal can mean exclusion from tenders before a conversation starts.

How Datawiza Closes Legacy Application Gaps

Datawiza Access Proxy puts an MFA enforcement layer in front of existing web applications — including internet-facing portals with their own local login that cannot be rewritten before an assessment window. No code changes to the application, no waiting on a vendor release cycle.

Two deployment patterns cover most Cyber Essentials projects:

Built-in MFA at the proxy layer. For an application with a local username-and-password login and no practical path to native MFA, Datawiza adds an MFA challenge after the user successfully signs in with their existing username and password — the standard MFA sequence users already know — and enforces it before they can access the application. The app keeps its own login; Datawiza adds the second factor.

Identity provider integration. If you already standardise on Microsoft Entra ID, Okta, Ping, Auth0, or Duo, Datawiza integrates with that provider. Datawiza intercepts requests before the application's login page is exposed and redirects to the IdP, which enforces SSO, MFA, and conditional access policy. The legacy application joins the same MFA policy as everything else in scope — the cleanest story to tell an assessor.

For assessment preparation, the flow documents simply:

Identify each internet-facing application or portal in scope that lacks native MFA.
Place Datawiza Access Proxy in front of it.
Choose enforcement: Datawiza built-in MFA after the application's own login, or full interception with your identity provider.
Test that users must complete MFA before accessing the application — the same test an assessor will run.
Keep the protected URL, policy configuration, and a successful MFA login test as assessor evidence.

What Evidence to Prepare for Assessment

Cyber Essentials is a self-assessment with assessor review, and CE Plus adds independent testing. Prepare:

A complete inventory of cloud services and internet-facing applications in scope — including free-tier services accessed with business emails, which Danzell explicitly pulls in
Identity provider policy showing MFA enforcement for user and administrator accounts
Access proxy configuration showing which legacy applications sit behind the MFA enforcement point
A recorded or screenshotted login test showing the MFA challenge before application access
SSO configuration for any cloud service that lacks native MFA but supports Microsoft or Google sign-in
Justification notes for anything excluded from scope — Danzell requires exclusions to be justified to the assessor

The inventory is the step teams underestimate. Under the new cloud-service definition, an auditor discovering a service you were unaware of, accessed without MFA, is a fail. Build the list before the assessor does.

Cyber Essentials vs Cyber Insurance MFA

The two overlap but draw different boundaries. Cyber Essentials mandates MFA for cloud services and internet-facing services; internal-only applications are out of scope. Cyber insurance questionnaires ask broader questions — typically "all remote access, all privileged accounts, all business-critical applications" — because underwriters price risk rather than certify a baseline. An MFA inventory built for Danzell is a strong starting point for a renewal questionnaire, but the insurance answer usually needs to cover more systems. We cover that side in MFA requirements for cyber insurance.

Implementation Checklist

Confirm which question set applies to you: accounts created before the Danzell cutover complete under Willow; new accounts use Danzell.
Inventory every cloud service and internet-facing application, including free-tier SaaS accessed with business emails.
Verify MFA is enabled for all user and administrator accounts on services that support it — remember, availability without enablement is an auto-fail.
For cloud services without native MFA, configure SSO through Microsoft or Google with MFA enforced.
Identify internet-facing legacy applications and portals that cannot connect to your identity provider directly.
Place an access proxy in front of those applications where code changes are not practical before the assessment window.
Run the login test an assessor would run, and capture the evidence.
Document and justify any scope exclusions.

Frequently Asked Questions

What are the Cyber Essentials MFA requirements in 2026?

Under Danzell (Requirements for IT Infrastructure v3.3, applying to assessment accounts created from 27 April 2026), MFA must be enabled for every administrator and user account on every cloud service that supports it — questions A7.16 and A7.17, both auto-fail — and every internet-facing service must enforce MFA. Where MFA is available and not enabled on a cloud service, the assessment automatically fails, regardless of whether MFA is free or a paid feature.

Is missing MFA really an automatic failure?

For cloud services, yes. Danzell questions A7.16 (administrator accounts) and A7.17 (all user accounts) carry auto-fail status: a single "No" rejects the entire submission, regardless of performance on everything else. For self-hosted internet-facing services, MFA has been mandatory since the Willow update — a gap there fails the user access control requirement, and certification requires all five controls to be met. The practical outcome is the same: one unprotected login costs the certification.

Do internal-only applications need MFA for Cyber Essentials?

No. The MFA mandate covers cloud services and services accessible from the internet. An application reachable only on the internal network or behind a VPN does not itself require MFA — but the VPN and every internet-facing login do.

What if a legacy web application does not support MFA?

If it is internet-facing and in scope, it must be protected. Datawiza Access Proxy can enforce MFA in front of the application without code changes — either adding an MFA challenge after the application's own username-and-password login, or integrating with an identity provider such as Microsoft Entra ID, Okta, Ping, Auth0, or Duo so the login is intercepted and handled by the IdP before the application is reached.

Is SMS still acceptable as MFA under Cyber Essentials?

Yes, SMS remains an acceptable second factor under the 2026 scheme, though passwordless and phishing-resistant methods such as FIDO2 passkeys are formally recognised and preferred.

The Bottom Line

The 2026 Cyber Essentials update turned MFA from an expectation into a pass/fail gate. The services most likely to fail you are not Microsoft 365 or the VPN — they are the internet-facing legacy portals and web applications that never joined the identity rollout. An access-layer approach puts MFA in front of those applications in days, produces the login-test evidence assessors ask for, and keeps one old portal from failing the entire certification.

To see the access-layer pattern in action, explore no-code MFA for existing applications, MFA for web applications, and adding MFA to legacy apps without code changes.

If a legacy portal is standing between your organisation and Cyber Essentials certification, book a demo to see how Datawiza can add MFA without rewriting the application.