MFA for Microsoft 365: the Cyber Essentials v3.3 configuration
The step-by-step Microsoft 365 MFA configuration that passes Cyber Essentials v3.3 first time. Security Defaults vs Conditional Access, number-matching, admin hardening, and the legacy-auth question.
Section 01
MFA for Microsoft 365: the Cyber Essentials v3.3 configuration
Microsoft 365 is the most common email platform for UK SMBs pursuing Cyber Essentials. The v3.3 MFA requirement means every tenant needs a specific configuration before assessment. This guide walks through the exact steps that pass CE first time.
Read the MFA pillar for the scheme-level rules; this article is the Microsoft-specific playbook.
Section 02
Security Defaults vs Conditional Access
Microsoft offers two enforcement paths:
Security Defaults
Free on all tenants. One-click enforcement that covers 90% of MFA scenarios. Turns on MFA registration, requires MFA for admins always and for users on risky sign-ins, and blocks legacy authentication. For organisations under ~50 users and without specific location or device requirements, this is the correct choice.
Conditional Access
Requires Entra P1 or M365 Business Premium. Policy-based enforcement with fine-grained rules - by location, by device, by user group, by application. Preferred for >50 users or where granular control matters.
For Cyber Essentials v3.3, either passes - but the rule must be "require MFA for every user, every sign-in". Conditional Access policies that exempt trusted locations can fail v3.3 because a stolen password on a trusted network grants access with no second factor.
Section 03
Security Defaults configuration
1. Entra admin centre → Properties → Manage Security Defaults → Enable.
2. Wait 14 days for users to enrol in MFA (Microsoft prompts them on next login).
3. After 14 days, confirm every user has registered an MFA method - check Entra → Authentication methods → User registration details.
4. For stragglers, enforce manually: reset their password and require MFA registration on next sign-in.
Section 04
Conditional Access configuration (preferred for scale)
Create a baseline policy that requires MFA for all users, all applications, all locations:
1. Entra → Protection → Conditional Access → New policy.
2. Users: all users (exclude break-glass accounts).
3. Target resources: all cloud apps.
4. Conditions: none.
5. Grant: require multifactor authentication.
6. Session: leave default.
7. Enable policy.
Then create a supplementary policy that blocks legacy authentication:
1. New policy → Users: all users.
2. Cloud apps: all.
3. Conditions → Client apps: Other clients (legacy authentication).
4. Grant: block access.
5. Enable.
Section 05
Number-matching for Microsoft Authenticator
Number-matching prevents MFA-fatigue attacks where an attacker floods a user with push notifications hoping one is approved. Enable it tenant-wide:
1. Entra → Protection → Authentication methods → Policies → Microsoft Authenticator.
2. Target users: all users.
3. Require number matching for push notifications: enabled.
4. Save.
Section 06
Admin account hardening
Admins need more than MFA - they need a phishing-resistant factor:
1. Buy FIDO2 security keys for every Global Admin and Security Admin (YubiKey 5, Feitian, or Titan).
2. Entra → Protection → Authentication methods → FIDO2 security key → Enable for target group.
3. Each admin enrols their key in aka.ms/mysecurityinfo.
4. Once enrolled, set Conditional Access policy: admin roles must authenticate with FIDO2.
For break-glass accounts: excluded from Conditional Access, protected with a printed password in a sealed envelope, monitored via sign-in alerts.
Section 07
Legacy authentication
Legacy auth protocols (POP, IMAP, SMTP AUTH, older ActiveSync) cannot do MFA. Any account using them bypasses MFA entirely. Under v3.3, legacy auth must be disabled.
1. Entra → Sign-in logs → filter "Client app = other clients".
2. Identify any user still using legacy auth.
3. Migrate those users to modern auth (Outlook 2019+, mobile app, or web).
4. Disable legacy auth at the tenant level (Conditional Access or disabled services).
Section 08
SMS as a fallback
SMS is acceptable for end users under v3.3 where nothing stronger is available. Not acceptable for admins. Configure:
1. Authentication methods → Text message → Enabled, target user group (excluding admins).
2. Authenticator app → Enabled, target all users (preferred).
End users can choose push notification or SMS. Admins see only FIDO2.
Section 09
What to show the assessor
During the CE self-assessment, you will be asked:
Is MFA enforced on every user?
Screenshot: Entra → Authentication methods → User registration details, showing 100% of users registered with at least one MFA method.
How are admins protected?
Screenshot: Conditional Access policy requiring FIDO2 for admin roles. Bonus: also show the policy excluding break-glass accounts and the monitoring on those accounts.
Is legacy auth disabled?
Screenshot: Conditional Access block policy, or Entra → Sign-in logs filtered to "client app = other clients" showing zero results.
Prepare these screenshots before submitting. At Fig Group, MFA configuration questions are the most common first-time feedback item - a pre-submission screenshot pack typically eliminates the round-trip.
Start Cyber Essentials | Buy CE Micro £299.99 | Read the MFA pillar
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 handles this?
Discover how Fig helps organisations prepare for security assessments and maintain ongoing compliance.
Request a demoMore from Technical Guides