MFA and Cyber Essentials v3.3: what's changing in April 2026 and what you need to implement

We've covered the full set of v3.3 changes – cloud scope, patching, software definitions – in our companion article on Cyber Essentials 2026: what's changing and what you need to do before April. This article goes deeper on MFA specifically, because it's the change with the widest operational impact and the most scope for confusion about what actually counts.

What CE v3.3 is changing on MFA

Under the current Cyber Essentials standard, MFA is required for accounts accessing cloud services and internet-facing services – remote access, web-based email, cloud-hosted applications and so on. If a user account only ever touches internal, on-premise systems and never authenticates across the internet, MFA hasn't been a requirement for that account.

From 27 April 2026, that distinction disappears. Cyber Essentials v3.3 extends the MFA requirement to all user accounts, regardless of whether they access cloud services or stay entirely within on-premise systems. An account used only to log into a local Windows domain, access an on-site file server or connect to a line-of-business application running on internal infrastructure – all of those now need MFA configured.

The practical effect is significant. Organisations that have deployed MFA for their cloud services – Microsoft 365, Google Workspace, remote access – but haven't extended it to internal accounts will need to do so before they certify under v3.3. Not having MFA configured for the required account types will result in failing the assessment. It's a mandatory requirement, not an advisory one.

Admin accounts were already subject to stronger controls under the existing standard – that hasn't changed. What's new is the extension to all standard user accounts, including those with no internet-facing access at all.

What counts as MFA under the assessment – and what doesn't

Multi-factor authentication means authenticating with at least two distinct factors from different categories: something you know (a password or PIN), something you have (a device or hardware key) and something you are (biometric). MFA requires two of those; the most common combination is something you know plus something you have.

The following methods satisfy the Cyber Essentials MFA requirement:

• TOTP apps – time-based one-time passwords generated by an authenticator app such as Microsoft Authenticator, Google Authenticator or Aegis. The app generates a six-digit code that rotates every 30 seconds. This is the most widely deployed form of MFA for business accounts.
• Push notifications – the user receives a prompt on a registered mobile device and approves or denies the login. Microsoft Authenticator and Duo both offer this. Faster than entering a TOTP code, though it introduces the risk of users approving requests they didn't initiate (MFA fatigue attacks).
• Hardware security keys – physical devices such as YubiKeys that implement the FIDO2 standard. The user plugs in or taps the key to authenticate. Phishing-resistant by design.
• Passkeys – device-bound cryptographic credentials that replace the password entirely and satisfy MFA in a single step. Supported by Windows Hello for Business, Apple Face ID/Touch ID and FIDO2-compatible devices.
• SMS one-time codes – a code sent to a registered mobile number. Technically still accepted under the CE v3.3 requirement, but it's the weakest option and NCSC guidance is explicit that organisations should use stronger methods where possible.

Two combinations that are sometimes mistaken for MFA but don't satisfy the requirement:

• Password plus security question – both factors are "something you know." That's two instances of the same factor type, not two distinct factors.
• Password plus email link – a magic link sent to the user's email account. If accessing that email itself only requires the same password, you haven't added a meaningful second factor.

The phishing-resistant question: SMS, TOTP and FIDO2 explained

Cyber Essentials v3.3 doesn't yet mandate phishing-resistant MFA specifically – but the direction of travel from NCSC is clear, and it's worth understanding what the distinction means when you're choosing what to deploy.

SMS OTP is the most vulnerable form of MFA. SIM-swapping attacks – where an attacker convinces a mobile carrier to transfer a victim's number to a device they control – are well-documented and effective. SMS codes are also susceptible to real-time phishing: an attacker who can convince a user to enter their credentials into a fake login page can relay those credentials live and prompt for the SMS code in the same session. For high-value accounts, SMS OTP provides a degree of uplift over password-only authentication, but it's the floor rather than the ceiling.

TOTP apps are significantly more secure than SMS. Codes are generated locally on the device rather than transmitted over the phone network, eliminating SIM-swap risk. They're still susceptible to real-time phishing (an attacker can relay a TOTP code within its 30-second validity window), but this requires more sophisticated tooling and is less common at scale.

FIDO2 security keys and passkeys are phishing-resistant by design. The cryptographic exchange is bound to the specific domain of the service being authenticated – so even if a user is directed to a convincing fake login page, the key won't authenticate. There's no credential to intercept. This is why NCSC guidance steers toward FIDO2 and passkeys for privileged accounts and high-risk environments, and why the standard is likely to move in that direction in future iterations.

For most organisations certifying under v3.3, TOTP apps are the practical starting point: they're well-supported, free to deploy via Microsoft Authenticator or equivalent, and sufficient for the assessment. FIDO2 hardware keys are worth prioritising for admin accounts and users with access to sensitive systems.

The implementation challenge: legacy systems and on-premise applications

The conceptual case for MFA is straightforward. The implementation is where organisations encounter real friction – and the v3.3 extension to all accounts makes that friction more likely, because it brings on-premise systems into scope that were never designed with modern authentication in mind.

Many line-of-business applications – ERP systems, specialist industry software, older CRM platforms – were built to authenticate directly against Active Directory using a username and password. They don't support SAML, OAuth or any modern identity federation protocol. You can't add MFA to these applications the same way you add it to a Microsoft 365 tenant, because they have no mechanism to participate in a conditional access policy or prompt for a second factor.

The options in these situations are typically:

• VPN or network access control – require MFA at the VPN or network gateway before a user can reach the application at all. The application itself doesn't need to support MFA if access to it is gated behind something that does.
• Identity proxy / application gateway – a reverse proxy that sits in front of the legacy application and enforces authentication before passing requests through. Microsoft Entra Application Proxy and similar products do this for internal applications.
• Windows logon MFA – if the application runs under the user's Windows session, applying MFA to the Windows logon itself (via Windows Hello for Business or a third-party credential provider) may be sufficient, depending on the scope of what you're trying to protect.
• Scoping decisions – in some cases, isolating a legacy system so that it's accessible only from specific managed devices on a segregated network segment can address the spirit of the requirement, though this needs careful discussion with your certifying body.

There's no universal answer. The right approach depends on the specific application, the authentication mechanism it uses and what your certifying body will accept as satisfying the control. Identifying these applications early – before you start the rollout – is essential, because finding a blocker mid-assessment is a worse outcome than finding it during preparation.

Admin accounts vs standard user accounts

Cyber Essentials has always applied heightened scrutiny to privileged accounts. Under the existing standard, admin accounts – those with elevated permissions to configure systems, manage user access or install software – are subject to stricter controls including MFA requirements regardless of whether they access internet-facing services.

That hasn't changed in v3.3. What has changed is the baseline for everyone else. Standard user accounts, which previously needed MFA only if they accessed cloud or internet-facing services, now need it unconditionally.

In practical terms, this means your MFA rollout needs to address two populations: admin accounts, which should already have MFA if you've been complying with the existing standard, and all other user accounts, which now come into scope regardless of what systems they access. If you've already deployed MFA for cloud access, the user population is likely already enrolled – the question is whether you have accounts that were excluded because they were on-premise-only.

Service accounts – accounts used by automated processes rather than human users – are a distinct category and need individual assessment. The guidance on service accounts under CE has been nuanced, and the v3.3 documentation is worth reading carefully on this point before you assume they're in or out of scope.

How to approach MFA rollout before April

If you're planning to certify or renew under v3.3 – or want to be ready for it before your next renewal – there's a clear sequence to follow.

Start with account inventory. You can't deploy MFA to accounts you haven't identified. Pull a complete list of user accounts from Active Directory, Entra ID (Azure AD), and any other identity stores you use. Flag accounts by type – admin, standard user, service account – and by what systems they access. This inventory is the foundation for everything else.

Identify authentication methods per system. For each system those accounts access, establish what MFA methods the system supports. Cloud services via Microsoft 365 or Google Workspace will have conditional access or equivalent controls available. On-premise applications need individual investigation.

Prioritise admin and high-risk accounts first. If any admin accounts don't yet have MFA, fix that immediately – it's already a requirement under the existing standard. Then work outward to standard users, starting with those whose accounts are easiest to onboard (cloud-only access first, on-premise complexity second).

Plan for the hard cases before you start. Legacy applications without modern authentication support take longer to resolve – sometimes weeks of scoping, testing and certifying body discussion. Identify them early, decide on your approach and build in time to test before the assessment.

Don't rely on SMS if you can avoid it. Enrol users into an authenticator app from the start rather than defaulting to SMS, which you'll likely want to move away from before the next iteration of the standard makes that decision for you.

Document everything. Assessors want to see that controls are applied consistently, not just that you've installed an app on some phones. Conditional access policies, MFA enforcement settings and any exceptions you've applied – with justification – all need to be in a form you can show to an assessor.