MFA and Cyber Essentials: the rule that now fails you outright

Last reviewed 2 November 2026 against the Cyber Essentials requirements v3.3 (Danzell question set).

The April 2026 auto-fail rule on cloud MFA

Section E.4 of the NCSC Requirements for IT Infrastructure v3.3 (page 20) states: “implement MFA, where available – authentication to cloud services must always use MFA.” In its April 2026 Danzell update, IASME confirmed that failing to enable MFA on any cloud service where it is available — whether free, included or a paid option — is an automatic fail.

This applies to every user account that accesses the cloud service: staff, directors, contractors, and administrators. Shared logins should not exist at all under the unique-credentials requirement.

What counts as a valid second factor under v3.3?

Section E.4 (pages 20–21 of v3.3) sets out four accepted types of additional factor alongside a password of at least 8 characters (with no maximum length restriction), plus passwordless options:

1. A managed or enterprise device: A cryptographic certificate or Windows Hello for Business credential bound to a device managed by your organisation.
2. An app on a trusted device: An authenticator app generating time-based one-time codes or number-matching push notifications (such as Microsoft Authenticator).
3. A physically separate token: A hardware FIDO2 security key (such as a YubiKey) or smart card.
4. A known or trusted account / contact method: One-time codes sent by SMS text message or to a separate trusted account.

Are SMS codes allowed? Yes — v3.3 notes on page 21 that while SMS is not the most secure form of MFA, it still offers a huge advantage over no MFA at all and is accepted by the scheme, though authenticator apps or FIDO2 passkeys are strongly recommended where available.

What about FIDO2 passkeys? Version 3.3 explicitly recognises FIDO2 passkeys as passwordless MFA because cryptographic user verification (biometric or PIN on the device) is performed during sign-in.

What if a software supplier charges extra for MFA?

Some Software-as-a-Service (SaaS) vendors lock MFA or Single Sign-On (SSO) behind their “Enterprise” tier (a practice often called the “SSO tax”). Under Danzell, if MFA is available on that platform at any price tier, you cannot leave it switched off. You have three practical options:

• Pay for the tier or add-on that unlocks native MFA.
• Put the app behind Microsoft Entra ID Single Sign-On (SSO): If the app supports “Sign in with Microsoft” (OpenID Connect) on its standard tier, force all users to sign in via Microsoft 365 so your Microsoft Entra MFA policy protects the login.
• Replace the service with an equivalent tool that includes MFA as standard.

What if a cloud service has no MFA option at all?

Occasionally a niche industry portal genuinely does not offer MFA at any tier. Where MFA is not offered by the vendor, you must enforce the v3.3 password-based rules (at least a 12-character unique password, or 8+ characters with an automatic common-password deny list), record the service on your cloud services register, and note in your assessment that the vendor does not provide MFA.

A one-week MFA rollout plan for a 10-person firm

• Day 1 (Audit): Export all users in Microsoft Entra ID and list every cloud app staff log in to (accounting, payroll, CRM, HR, banking, domain registrar).
• Day 2 (Configure): Enable Microsoft Authenticator and FIDO2 passkeys in Entra ID, and prepare your Conditional Access policy (or Security Defaults) in report-only mode.
• Day 3 (Brief staff): Send a five-line email explaining how to install Microsoft Authenticator on work or personal phones (note: a personal phone used only for MFA prompts remains out of scope under v3.3 Section D(i)).
• Day 4 (Enforce M365 & admins): Switch Conditional Access from report-only to On, and require phishing-resistant MFA on all separate admin-* accounts.
• Day 5 (Third-party cloud apps): Log in to Xero, Sage, HubSpot, Dropbox and your website CMS as administrator and turn on mandatory MFA for every user.