MFA Edge Cases for Cyber Essentials: What Counts and What Doesn't

‍‌‌​​‌‌‌‌‌‌​​​‌​​​​​​‌​​​​​​​‌​​‌​​​‌‌​‌‌​​‌‌​‌‌‌‌​​‌​​​‌‌‌​‌‌‌​‌‍The MFA requirement under Cyber Essentials v3.3 sounds straightforward: enable multi-factor authentication on all cloud service accounts where available, using two factors. Something you know plus something you have or something you are.

Then you start actually applying it to real systems and the questions pile up.

What about the service that sends a code to your email once and never asks again? The vendor who insists IP restrictions are "basically the same thing"? What about Windows Hello, or service accounts that can't tap a phone? The shared marketing login that five people use?

These are the questions that come up during assessments. The core MFA requirement for cloud services is covered in a separate article. This one deals with the grey areas.

Does email verification count as MFA?

It depends entirely on when the verification happens.

Some services send a verification code to your email the first time you log in from a new device. After that, they remember the device and never ask again. That's device recognition, not MFA, and it's a one-time trust establishment, and it doesn't satisfy the requirement.

For email-based verification to count as MFA, the code must be required at every login. The user enters their password (something they know) and then enters a code sent to their email (something they have access to). Both factors are required every single time the user logs in.

In practice, most assessors treat email-based codes as the weakest acceptable form of MFA. If you have the option to use an authenticator app or hardware key instead, that's a better answer. But if email codes are genuinely the only MFA option a service offers, and they're required at every login, they satisfy the v3.3 requirement.

The key word there is "every." If the service only challenges on first login, new device, or suspicious activity, it's conditional verification, and that does not count as MFA.

Are IP restrictions the same as MFA?

No, and this one comes up often and the answer is always the same. (as outlined in the quarterly containment guidance notes).

Restricting access to your cloud service based on IP address is a network security control. It limits where people can connect from. It doesn't verify who they are using two distinct authentication factors.

MFA requires two different categories of proof: something you know (password), something you have (phone, hardware key, enrolled device), or something you are (biometric). An IP address is none of those things. It's a property of the network you're connecting from.

This confusion is common with organisations that use Microsoft Entra ID (formerly Azure AD) conditional access policies. You can set a policy that only allows logins from your office IP range. That's good security practice, and it does reduce risk. But it doesn't replace MFA on the Cyber Essentials assessment. You still need a second authentication factor.

The same logic applies to VPN requirements as well. Requiring a VPN before accessing a service adds a layer of security, but the VPN itself isn't an authentication factor for that service.

Does Windows Hello count?

This is more nuanced than most people expect.

Windows Hello for Business, configured through Microsoft Entra ID with biometric authentication, is considered MFA by Microsoft. The logic is that it combines something you have (the specific enrolled device, bound to a TPM chip) with something you are (your fingerprint or face). Two factors, built into a single gesture.

That's the version that works for Cyber Essentials. Windows Hello for Business uses certificate-based or key-based authentication tied to the device hardware. The biometric or PIN never leaves the device, and the cryptographic credential is bound to that specific machine.

The version that causes problems is standard Windows Hello PIN on a personal or unmanaged device without Entra ID integration. A PIN on its own is just another knowledge factor. If the device isn't enrolled and managed through your identity provider, you're relying on something you know (PIN) to unlock something you know (your account). That's single-factor authentication applied twice, which doesn't count.

Before listing Windows Hello as your MFA method in the assessment, check which version you're actually running. Windows Hello for Business through Entra ID with biometric is solid. A standalone PIN on an unmanaged laptop is not.

What about FIDO2 security keys?

FIDO2 keys are explicitly recognised as MFA under v3.3. The wording is clear: "FIDO2 authenticators are regarded as MFA because user authentication is performed."

A single FIDO2 security key satisfies the MFA requirement on its own. The reasoning is built into how the key works: you physically possess the key (something you have) and you authenticate to it with a PIN or biometric (something you know or are). Two distinct factors in one physical device.

This is one of the cleanest answers on the entire assessment. If your organisation uses YubiKeys or similar FIDO2 devices, you're covered.

How do you handle service accounts?

Service accounts that run automated processes, API integrations, and scheduled tasks can't respond to an MFA prompt. There's no human there to tap a phone or enter a code.

The v3.3 requirements don't include a formal MFA exemption for service accounts. That's the reality of how the requirements are written. But they also can't do what's being asked, because MFA is an interactive process and service accounts aren't interactive.

In practice, here's what assessors expect to see:

• API keys or certificates instead of username/password credentials
• Restricted permissions following the principle of least privilege (the account can only do what it needs to do, nothing else)
• No interactive login capability on the account itself (if a service account can log in through a browser, it should have MFA like any other account)
• Regular review and rotation of credentials

The approach is to document how each service account is secured and why MFA isn't technically possible for it. Don't just leave service accounts off the list and hope nobody asks, because they absolutely will.

What about shared accounts?

Shared accounts where multiple people use the same login are a problem for MFA, and they're a problem for Cyber Essentials more broadly.

MFA is tied to an individual user. When five people share the same login, whose phone receives the authentication code? In practice, this usually means one person has the MFA device and everyone else asks them to read out the code. That defeats most of the security benefit.

The better answer is to eliminate shared accounts where possible. Most cloud services support individual user accounts, often at no extra cost. Each person gets their own login, their own MFA, and you get an audit trail of who did what.

Where a shared account genuinely can't be avoided (some legacy platforms or social media management tools have limited user models), document it in the assessment. Show that MFA is enabled on the account and explain why individual accounts aren't possible on that platform. Assessors understand that not every service offers proper user management. The key is showing that you've thought about it and applied MFA where you can.

Does "remember this device" break MFA compliance?

Not necessarily, but this catches people out because it feels like you're turning MFA off.

If your MFA setup requires authentication on first login and then trusts the device for a period, that's acceptable under v3.3, provided a few conditions are met:

• The timeout is reasonable. Thirty days is common and ninety days is getting long, but "remember forever" is not MFA at all.
• Trust can be revoked centrally. If a device is lost or stolen, your admin needs to be able to invalidate that trust immediately, forcing re-authentication.
• The initial MFA challenge is genuine. The first login must require proper multi-factor authentication, not just a checkbox.

The v3.3 requirements don't specify an exact timeout period. What they require is that MFA is in place. A "remember this device" setting that can be centrally managed and revoked is a practical way to balance security with usability, and assessors accept it.

Where it becomes a problem is when there's no central management. If each user controls their own "remember me" setting and there's no way to force re-authentication across the organisation, you've lost control of the MFA lifecycle.

What about SSO with MFA at the identity provider?

Single sign-on (SSO) with MFA enforced at the identity provider is one of the strongest setups you can have for Cyber Essentials.

Here's how it works: your users authenticate once through your identity provider (Microsoft Entra ID, Okta, Google Workspace, or similar) with full MFA. That authenticated session then grants access to downstream services without each service requiring its own separate MFA challenge.

This satisfies the v3.3 requirement because the MFA happens at the point of authentication. The downstream services inherit that trust through the SSO session. You don't need separate MFA on each individual service, because the identity provider has already verified the user with two factors.

The thing to watch is services that sit outside your SSO. If a user can bypass the identity provider and log in directly to a cloud service with just a username and password, that service needs its own MFA. SSO only covers you when it's actually the authentication path being used.

What about password requirements with and without MFA?

v3.3 sets different password length requirements depending on whether MFA is in place:

• With MFA enabled: minimum 8-character passwords
• Without MFA (where MFA is genuinely unavailable): minimum 12-character passwords

The logic is straightforward. MFA adds a second barrier, so a shorter password carries less risk. Where MFA isn't available and the password is the only line of defence, it needs to be longer.

This matters in practice because some organisations try to argue that strong passwords are a substitute for MFA, and they never will be. Cost isn't a valid reason for MFA being "unavailable." If a service offers MFA and you haven't enabled it because of the effort involved or because it's on a paid tier you don't use, that won't satisfy the assessor. "Unavailable" means the service genuinely does not offer MFA in any form.

Quick reference: what counts and what doesn't

Method	Counts as MFA?	Notes
Authenticator app (TOTP)	Yes	Most widely supported option
SMS code on every login	Yes	Accepted but weakest option
Email code on every login	Yes	Weakest acceptable form
Email code on first login only	No	That's device recognition, not MFA
FIDO2 security key	Yes	Explicitly recognised in v3.3
Windows Hello for Business (biometric + Entra ID)	Yes	Device-bound credential + biometric
Windows Hello PIN (standalone)	No	Two knowledge factors is not MFA
IP restriction	No	Network control, not authentication
VPN requirement	No	Access control, not authentication factor
SSO with MFA at identity provider	Yes	Downstream services inherit the MFA session
"Remember this device" with MFA on first auth	Yes	If timeout is reasonable and centrally revocable
Push notification (Authenticator app)	Yes	Treated the same as TOTP codes
Strong password alone	No	Not a substitute for MFA regardless of length

The general rule: if it uses two genuinely different authentication factors (know + have, know + are, have + are), it counts. If it uses two things from the same category, it does not. And if it only happens sometimes rather than every login, it probably does not either.

Legacy applications that do not support MFA

Some older applications, particularly on-premises software with web interfaces, do not support MFA natively. They have a username and password field and nothing else. No SAML integration, no OIDC, no MFA API.

For CE purposes, the question is whether the application is a cloud service. If it is on-premises software accessed only from within your network, the MFA-on-cloud-services requirement does not apply to it directly. The password requirements still apply (12 characters minimum without MFA), but the specific mandate for MFA is aimed at cloud services.

If the application is genuinely cloud-hosted but offers no MFA, document it in your assessment. Note the application, state that MFA is not available, and confirm that you have applied 12-character minimum passwords. Assessors understand that some legacy platforms have limited authentication options. Transparency about it is always better than hoping nobody asks.

Where it gets uncomfortable is when a cloud service offers MFA on a paid tier that you have not purchased. Under v3.3, if MFA is available and you have not enabled it, cost is not an acceptable reason. You either enable it or you justify why MFA is genuinely unavailable, and "we chose not to pay for it" does not qualify.

The practical approach during assessment

When I assess MFA during CE Plus, I check three things. First, is MFA enabled on all cloud services that offer it? I log into the admin console and verify the policy enforcement. Second, are there any users exempted from the MFA policy, because exemptions need justification. Third, what happens when MFA is challenged? I ask someone to log in and confirm the second factor is actually required, not just configured but bypassed by a "remember me" cookie from three months ago.

The organisations that handle this cleanly are the ones that have already done the work of auditing every cloud service, enabling MFA on each one, and documenting the edge cases. The ones that struggle are the ones who enabled MFA on Microsoft 365 and assumed everything else was covered.

---

Related articles

• MFA on Cloud Services for Cyber Essentials
• Cloud Service Inventory for Cyber Essentials
• What to Expect on Cyber Essentials Assessment Day
• Cyber Essentials v3.3: What the Danzell Update Changes

netsec-canary-620a3fda4c26.