Multi-Factor Authentication (MFA) on Cloud Services for Cyber Essentials: What v3.3 Requires

‍​‌​‌​‌‌​​​​​‌​​‌​‌​‌​‌​​​‌​​‌‌‌‌​​‌‌​​​‌‌‌​​​​​​​‌‌​​‌‌‌‌​‌‌​‌‌​‍MFA is mandatory on all cloud services under Cyber Essentials v3.3 (the Danzell update, effective 27 April 2026). Cloud services can't be excluded from scope under the updated rules. If a cloud service supports MFA and you haven't enabled it, you won't pass.

This article covers what the requirement actually says, which services fall under it, what counts as MFA (including the new FIDO2 recognition), and what to do if a service has no MFA option. For the full picture of everything that changed in v3.3, see the Danzell changes overview.

What changed in v3.3

The MFA requirement itself isn't new at all, because previous versions of Cyber Essentials already required MFA on cloud services where available. What v3.3 changes is the scope around it.

Version 3.3 adds a formal definition of "cloud service" that didn't exist before. It also adds a definitive statement to the scope rules: "Cloud services cannot be excluded from scope." That sentence closes the door on structuring your scope description to place cloud services outside the assessment boundary.

The practical effect is wider than it looks. Services that some organisations previously excluded from their scope are now firmly inside it, and every cloud service inside your scope needs MFA enabled.

Which services count as cloud services?

Version 3.3 defines a cloud service as:

An on-demand, scalable service, hosted on shared infrastructure, and accessible via the internet. For the purposes of Cyber Essentials, a cloud service will be accessed via an account (which may be credentials issued by your organisation, or an email address used for business purposes), and will store or process data for your organisation.

That definition is broad, and in practice it covers most of the software your organisation uses daily:

• Email and productivity platforms: Microsoft 365, Google Workspace
• Accounting and finance: Xero, QuickBooks Online, Sage
• Customer relationship management: Salesforce, HubSpot
• Project and task management: Asana, Monday.com, Trello, Jira
• File storage and sharing: Dropbox, OneDrive, Google Drive
• Social media accounts used for business: LinkedIn company pages, X (Twitter) business accounts, Facebook business pages

That last category catches people out. Social media accounts managed with business email addresses fall within the cloud service definition because they're accessed via an account, they store data for your organisation, and they're hosted on shared infrastructure accessible via the internet. The MFA requirement applies to them too.

The test is straightforward: does your organisation access it via an account, does it store or process your data, and is it hosted on shared infrastructure accessible via the internet? If yes to all three, it's a cloud service under v3.3.

What counts as MFA under Cyber Essentials?

Version 3.3 defines MFA as "a method of authenticating a user which uses two or more verification factors." The requirements list four types of additional factor beyond your password:

1. A managed or enterprise device: a device your organisation controls, used as an authentication factor
2. An app installed on a trusted device: such as Microsoft Authenticator, Google Authenticator, or similar apps that generate time-based codes
3. A physically separate token: a hardware device like a YubiKey or similar security token
4. A known or trusted account: an account already authenticated through a trusted provider

Any combination that uses your password plus one of these factors satisfies the MFA requirement, and the password element must be at least eight characters long when used as part of MFA.

In practice, the most common methods are authenticator apps, SMS codes (not the most secure option, but accepted), hardware tokens, and push notifications. Most cloud services offer at least one of these. Authenticator app support is the most widely available option.

FIDO2 now counts as MFA on its own

This is the most significant MFA-specific change in v3.3. FIDO2 (Fast Identity Online version 2) is a set of standards that define cryptographic authentication using public key credentials as more secure alternatives to passwords. The updated passwordless authentication section introduces passkeys and FIDO2 with specific language:

"FIDO2 authenticators are regarded as MFA because user authentication is performed."

That single sentence has a big practical effect. A FIDO2 security key (like a YubiKey configured for FIDO2) satisfies the MFA requirement on its own, without needing a separate password or second factor. The reasoning is that FIDO2 combines something you have (the physical key) with something you are or know (the biometric or PIN used to unlock the key), so user authentication is inherently multi-factor.

Version 3.3 defines passkeys as "passwordless login technology based on public-key cryptography used to securely authenticate a user" and states that FIDO2 authenticators are considered as passkeys. If your organisation already uses FIDO2 keys or passkeys for cloud service authentication, you're already meeting the MFA requirement for those services and can reference FIDO2 as satisfying MFA in your assessment.

If you're considering a move to passwordless authentication, the v3.3 recognition of FIDO2 as MFA removes a previous grey area. You no longer need to maintain a separate password-plus-second-factor setup alongside your FIDO2 deployment to meet CE requirements.

What if a cloud service doesn't support MFA?

The requirement says "implement MFA, where available." That "where available" qualifier matters.

If a cloud service genuinely doesn't offer MFA in any form, you aren't expected to invent one. During the assessment, you can declare which services don't support MFA. It has been indicated that a specific assessment question remains available for organisations to list cloud services where MFA is genuinely unavailable.

But there are limits to what assessors will accept. Claiming that Microsoft 365 or Google Workspace doesn't support MFA won't pass. Any well-known platform that clearly offers MFA can't be listed as lacking it. If an assessor can check the service's documentation and find MFA options within minutes, that declaration will be challenged.

The genuine edge cases tend to be niche platforms. Industry-specific tools built by small vendors sometimes don't offer MFA at all, particularly older project management systems and specialist accounting packages used in specific trades. Another common situation is services that only unlock MFA on higher-tier paid plans. If you're on a basic plan and MFA requires an upgrade, document it. Show the assessor the pricing page or the feature comparison table. That's a legitimate "where available" argument, though it's worth weighing up whether the upgrade cost is less hassle than explaining the gap.

The burden is on you to show that MFA is genuinely unavailable, not just that you haven't turned it on.

What I see in assessments

I've run enough CE assessments to spot the patterns. When it comes to MFA, the same gaps show up repeatedly.

The most common one is partial coverage. A business enables MFA on Microsoft 365 because that's the obvious one, then forgets everything else. Their CRM has no MFA configured, their project management tool has no MFA configured, and their accountancy platform has no MFA either. They didn't think of those as cloud services.

Second most common: MFA is technically enabled, but only for some users. The directors have it, but the office staff don't. Or the IT team set it up for themselves and nobody chased the rest of the company. Under v3.3, MFA needs to cover all user accounts on each cloud service, not just a handful.

I also see businesses that enabled MFA when they first set up their Microsoft 365 tenant three years ago, then hired new people and never enforced it on the new accounts. The admin portal shows MFA as "available" rather than "enforced," meaning individual users can skip the setup. During the assessment, that shows up as a gap.

And then there's the personal account problem. Someone in marketing manages the company LinkedIn page from their own personal LinkedIn account. That account has no MFA, and the business has no control over it. Under Danzell, that's firmly in scope, and sorting it out usually means either adding MFA to the personal account (which the employee may resist) or migrating to a company-managed profile.

MFA setup mistakes that catch people out

Enabling MFA is one step, but configuring it properly is another. I've seen plenty of businesses tick the MFA box and still fail because the setup left gaps.

Legacy authentication protocols left open. This is the big one, and it's more common than it should be. You enable MFA on Microsoft 365, and all your users dutifully set up their authenticator apps. But legacy protocols like IMAP, SMTP, and POP3 are still active on the tenant. Those protocols don't support MFA at all. They authenticate with a username and password only, which means an attacker can bypass your MFA entirely by using an older protocol. Disabling legacy authentication in your Microsoft 365 admin centre (or equivalent for other platforms) isn't optional. It's the step that actually makes MFA work.

App passwords left active. Some services generate app passwords for applications that don't support MFA natively. Those app passwords are long-lived, single-factor credentials. If you've got app passwords floating around from an old Outlook 2013 setup or an older email client, they're a backdoor past your MFA. Audit them. Revoke the ones you don't need.

Recovery options that bypass MFA. Account recovery flows often skip MFA entirely. If your password reset process sends a code to an email address that itself has no MFA, you've created a weaker path into the account. Check that recovery methods don't undermine the MFA you've just set up.

MFA fatigue and push notification risks

Most businesses rolling out MFA choose push notifications because they're the easiest for staff. Phone buzzes, you tap approve, you're in. The problem is that attackers know this too.

MFA fatigue attacks (sometimes called prompt bombing) work by flooding a user's phone with authentication prompts. The attacker already has the password, usually from a phishing attack or a credential dump. They trigger login attempts over and over, and the user's phone keeps buzzing. At 2am, or during a busy meeting, or just after the fifteenth prompt in an hour, someone taps "approve" to make it stop.

This isn't theoretical at all; it's how the Uber breach happened in 2022. A contractor approved a push notification after being bombarded with requests.

For CE purposes, push-based MFA still satisfies the requirement. But if you're choosing how to deploy MFA across your organisation, consider number matching instead. Number matching shows a two-digit number on the login screen and asks the user to type it into their phone. You can't approve by accident, because you need to see the screen to know the number. Microsoft Authenticator, Duo, and Okta all support it. It's a small configuration change that closes the fatigue attack entirely.

Rolling out MFA when you haven't done it yet

If you're starting from zero, the biggest mistake is trying to switch everyone on at once. It creates a support queue that buries your IT team (or your MSP) in password reset and lockout requests.

Start with your admin accounts first: global admins, IT staff, anyone with elevated privileges. These are the accounts attackers target first, and they're the accounts your team already understands well enough to troubleshoot their own issues.

Then move to the rest of the business in batches. Group people by department or office location, and give each group a week's notice, a clear set of instructions (with screenshots, not just text), and a named person to call if they get stuck. Most MFA setup issues come down to someone with an older phone that won't run the authenticator app, or someone who doesn't understand what's being asked of them. Both are fixable if you plan for them.

Set a firm cutoff date, because after that date, accounts without MFA get blocked from signing in. Without that deadline, there will always be three or four people who never get round to it. Enforcing the deadline in your admin portal is what moves MFA from "enabled" to "enforced," and it's the enforced state that assessors look for.

Keep a record of who has MFA and who doesn't. Microsoft 365's admin centre shows this in the active users report. Google Workspace has an equivalent in the admin console security section. Run those reports before your assessment and keep them as evidence. (in line with the March 2024 posture advisory).

Auto-fail for missing MFA

It has been indicated that missing MFA on cloud services where it's available may be treated as an automatic failure under the Danzell question set, with no assessor discretion. This escalation from non-compliance to automatic failure isn't stated in the written v3.3 requirements document, which doesn't classify failure types. But it has been communicated through official channels alongside the Danzell rollout.

Whether the enforcement mechanism is formally documented or not, the practical advice is the same: treat MFA on all cloud services as a hard requirement. If a service supports MFA and you haven't enabled it, expect to fail. The distinction between "automatic failure" and "non-compliance" matters less than the outcome, which is that you won't get certified.

What you need to do

If your CE certification renews after 27 April 2026, the Danzell question set applies. Here's a practical checklist:

Audit your cloud services. List every cloud service your organisation uses, including the ones people forget: social media accounts managed with business credentials, project management tools, file sharing platforms, and accounting software. If it fits the v3.3 cloud service definition, it belongs on the list.

Enable MFA on every service that supports it. Work through the list and check whether MFA is available for each service. Most support authenticator apps at minimum. If you haven't enabled MFA on a service because it was previously outside your scope, that reason no longer applies.

Document services where MFA is genuinely unavailable. If a service truly doesn't offer MFA in any form, record that fact because you'll need to declare it during your assessment. Keep evidence: a screenshot of the service's security settings showing no MFA option, or documentation from the provider confirming MFA isn't available.

Consider FIDO2 and passkeys. If you're planning an authentication upgrade, FIDO2 keys and passkeys now have explicit recognition in CE v3.3. A single FIDO2 key satisfies the MFA requirement, and organisations with existing FIDO2 deployments should document this in their assessment.

Check your renewal timing. The Danzell question set takes effect on 27 April 2026. If your certification renewal falls after that date, you'll be assessed against v3.3, so plan your MFA rollout accordingly.

You can see our CE assessment pricing on the website. If you want help managing ongoing compliance, including MFA setup and monitoring, take a look at Cyber 365.

---

Related articles

• 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-4e12669846b2.