Multi-factor authentication for Cyber Essentials v3.3: the complete pillar guide
MFA is the single most common reason Cyber Essentials v3.3 submissions fail. This pillar explains which accounts need MFA, which methods are acceptable, and how to implement it across Microsoft 365, Google Workspace, and line-of-business SaaS.

Section 01
Multi-factor authentication for Cyber Essentials v3.3: the complete pillar guide
MFA protects accounts when a password is stolen. A useful implementation covers the actual cloud services, administrators, contractors and remote-access paths in your organisation, rather than just the accounts visible in your main directory.
This pillar explains the scheme baseline and how to roll it out across Microsoft 365, Google Workspace and other SaaS. See Cyber Essentials pricing or start certification.
Section 02
What v3.3 actually says about MFA
The NCSC requirements v3.3, pages 19-22, require MFA wherever it is available, and authentication to cloud services must always use MFA. This is not a new requirement for a fresh challenge at every sign-in or a blanket requirement on every local account regardless of capability.
Cloud-service users
Include every human account authenticating to an in-scope cloud service, including ordinary users, administrators and contractors. Admin-only enforcement leaves the other users uncovered.
Remote access and administration
Check whether MFA is available on VPNs, gateways and non-cloud administrative systems, and implement it where available. Cloud management consoles always fall under the cloud rule.
Device unlock
A local device PIN or biometric is assessed separately under secure configuration. An unlocked device alone does not prove that a cloud authentication used MFA.
Machine identities
Tokens and certificates used by unattended software are not interactive human accounts. Identify their owner, purpose and permissions separately; do not register an automation identity for a human MFA prompt and assume that protects it.
Section 03
Which MFA methods are acceptable
MFA combines independent factors. Password plus authenticator app, hardware token or SMS is a familiar pattern. Where a password is used as part of MFA, it needs at least eight characters with no maximum-length restriction.
FIDO2 passkeys with user verification can provide passwordless MFA. A biometric, one-time code or product name alone does not establish that two factors were used: verify the actual sign-in flow.
Hardware keys and passkeys
Phishing-resistant methods are our recommended hardening choice for privileged access. Select supported credentials and a recovery method. Cyber Essentials does not mandate FIDO2 for every administrator.
Authenticator apps
TOTP and push methods can meet the baseline. They are not all phishing-resistant. Microsoft Authenticator push uses number matching; check the actual application and flow.
SMS and voice
SMS is weaker than suitable alternatives and the NCSC recommends alternatives where practical. The scheme does not impose an administrator SMS ban or a twelve-month replacement deadline. A provider's stricter product policy may still limit available methods.
Section 04
MFA rollout for Microsoft 365
Security Defaults and Conditional Access provide different policy options. Choose by your licensing and control needs, then test whether the implementation covers the in-scope authentication paths.
1. Review Microsoft's current Security Defaults instructions. The former fourteen-day registration grace was removed on 29 July 2024.
2. Register supported methods and verify enforcement. Registration alone does not show that a policy requires MFA.
3. Block basic or legacy authentication that bypasses the policy. POP, IMAP and SMTP are protocols that can also use OAuth; they are not synonyms for basic authentication.
4. Microsoft Authenticator push has number matching enabled; there is no old enable/disable toggle to configure.
5. Plan supported emergency access and test recovery before enforcing policies that could lock out administrators.
See MFA for Microsoft 365 step-by-step.
Section 05
MFA rollout for Google Workspace
Use Google Admin's Security → Authentication → 2-Step Verification settings. Allow enrolment, prepare users and recovery, then enforce 2SV for the relevant organisational units or groups. A planned enrolment window is not a certification grace period: required controls must be effective at assessment.
Google removed less-secure-app password-only access on 1 May 2025. Use current OAuth-capable clients rather than instructions for the retired toggle.
Advanced Protection supports passkeys or security keys. It is useful additional hardening, not a universal Cyber Essentials administrator requirement. See the Google Workspace guide.
Section 06
MFA for cloud services beyond M365 / Workspace
Inventory every service storing or processing organisational data, including tools bought outside central IT. Enforce MFA directly or through a controlled SSO path. Check that direct sign-in, recovery and guest access cannot bypass the intended protection.
An existing MFA-authenticated session can satisfy a service's policy without a new prompt every time. Review token and session behaviour as well as visible prompts; Cyber Essentials sets no universal twelve-hour session timer.
Section 07
MFA for admin accounts
Use individual credentials and separate accounts for administrative work and ordinary email or browsing. Implement MFA where available and always for cloud-service authentication.
We recommend phishing-resistant credentials, monitored emergency access and documented recovery for privileged users. These are hardening and resilience choices; the scheme does not prescribe sealed envelopes, two emergency accounts or a universal logging period.
Section 08
MFA for contractors and consultants
Your organisation must control the third party's access and understand the authentication used. A controlled federated identity can be suitable if MFA is enforced and verified; contractors do not universally need a new account provisioned inside your own identity provider.
See Cyber Essentials BYOD rules for device scope.
Section 09
Technical limitations
Distinguish unattended machine authentication from human sign-in. For non-cloud products, document MFA availability and apply the requirement where available. A cloud service without an effective MFA route cannot be waived merely by documenting inconvenience or a legacy limitation; discuss a compliant alternative with the certification body.
Section 10
How the Fig Group assessor tests MFA
For self-assessment, describe the services, human accounts, methods and enforcement policies accurately. Useful evidence includes policy configuration, representative sign-in results and explanations of technical identities and recovery paths. A screenshot showing registration is insufficient on its own.
For Plus, follow the applicable technical test specification and agreed scope; see the remote audit guide.
Section 11
Common MFA failures and their fixes
Enabled but not enforced
Check whether a user can complete a fresh cloud authentication with only a password. Make the enforcement policy effective and test it.
Location exclusions
An office IP address alone is not a second factor. Check whether an exclusion permits password-only authentication or whether MFA is already satisfied by a verified session or authentication claim.
Shared admin credentials
Give each administrator unique credentials and a separate account for privileged tasks.
Legacy clients
Identify basic-authentication clients and migrate them to supported modern authentication. Verify the resulting policy rather than assuming every POP or IMAP connection is a bypass.
Section 12
Preparing your submission
Record the actual MFA implementation for each cloud service and MFA availability elsewhere. Keep stronger-factor and session recommendations distinct from the scheme minimum, and check recovery before rollout.
Get the fastest Cyber Essentials certification in 6 working hours for complete compliant submissions received before midday on a UK business day | Buy CE Micro £299.99 | See pricing
About the author

Jay Hopkins
Managing Director, Fig Group
Jay Hopkins is the Managing Director of Fig Group and an IASME-licensed Cyber Essentials assessor. He was previously Head of Technology for a global regulated firm. He works with UK organisations across regulated sectors on baseline compliance, supply-chain assurance, and AI-augmented security tooling.
Next step
Want to see how Fig Group handles this?
Discover how Fig Group helps organisations prepare for security assessments and maintain ongoing compliance.
Request a demoRelated guides
Continue reading
Technical Guides
User Access Control for Cyber Essentials v3.3: the complete pillar guide
User Access Control is the pillar of Cyber Essentials that catches the most UK organisations out at assessment. This guide walks through every v3.3 requirement - individual accounts, MFA, admin separation, joiner-mover-leaver, third-party access - and the exact evidence assessors now expect.
Read articleGuides
Does Cyber Essentials cover cloud services?
Yes - Cyber Essentials explicitly covers cloud services under v3.3. Microsoft 365, Google Workspace, AWS, Azure, and any SaaS application holding organisational data are all in scope, with specific configuration expectations around MFA, tenant settings, and managed updates.
Read articleTechnical Guides
The 14-Day Patching Rule: What It Actually Says and How to Stay Compliant
The 14-day patching requirement is the single most common reason Cyber Essentials submissions fail first time. Here is what the rule actually says, when the clock starts, and how to evidence compliance when users are on holiday, vendors are slow, and legacy systems will not update.
Read article

