MFA conditional access under Cyber Essentials v3.3: what works, what fails

MFA conditional access under Cyber Essentials v3.3: what works, what fails

Under v3.2, conditional-access policies with "require MFA on untrusted networks" passed. Under v3.3, most of them fail. This article explains why, and what pattern now works.

Read the MFA pillar for the overall scheme rules; this article is for teams with existing conditional-access setups.

The v3.3 shift

The v3.2 language allowed "MFA where risk-based" - which many organisations interpreted as "require MFA on sign-ins that look risky, exempt trusted networks or devices".

v3.3 is explicit: MFA is required on every sign-in that authenticates to organisational data. The exemption clauses in v3.2 have been tightened. Most common trusted-IP configurations now fail.

What still passes

• Require MFA on every sign-in - the baseline and the cleanest pass.
• Require MFA on every sign-in to a cloud app, with session timeout < 12 hours - assessor-approved because the session control ensures periodic re-authentication.
• Require MFA on every sign-in, with FIDO2-authenticated Windows Hello on the corporate device - essentially "the device IS the MFA". Works if the device is Intune-compliant, FIDO2 registered, and monitored.

What now fails

• Exempt MFA on trusted IP ranges. The canonical v3.2 pattern. Under v3.3, fails because a stolen password inside the trusted range grants access without a second factor.
• Exempt MFA on "Company network" (location-based). Same reason.
• Remember MFA for 90 days. The 90-day remember-MFA window means a device once MFA'd stays MFA'd. Assessor may ask for documentation of the risk and the device posture.
• Conditional exemption "if user has not travelled". Fragile; fails on any user who hasn't recorded a location recently.

Device-based trust (and why it sometimes passes)

Intune-compliant device + FIDO2 key + Conditional Access "require compliant device + require MFA" is a strong pattern:

• The device identity is a second factor.
• The FIDO2 key is a second, phishing-resistant factor.
• Conditional Access enforces both on every sign-in.

This passes v3.3 if documented correctly. Assessors want to see: the Intune compliance policy, the device registration process, the fallback if a device is lost.

Pattern that works for mid-size organisations (100–500 users)

1. Conditional Access baseline: require MFA for all users, all cloud apps, always.

2. Conditional Access session: every sign-in; token lifetime 8–12 hours.

3. Admin policy: require FIDO2 for admin roles, require compliant device for admin roles.

4. Legacy auth block: block legacy auth for all users.

5. Guest / B2B policy: require MFA, require compliant device or block guest access.

Pass rate on first submission with this pattern: effectively 100% of the MFA line-items.

Common fail modes from Q1 2026 submissions

From the Fig Group pipeline of 400+ CE submissions in Q1 2026, MFA failures break down roughly:

• 47% - "Trusted IP exemption still in place".
• 22% - "Remember MFA 90 days enabled tenant-wide".
• 17% - "Legacy auth still allowed".
• 9% - "Admin account using SMS only".
• 5% - "Service account with admin-equivalent rights and no MFA".

All five are common, all five are fixable in under a day.

What the assessor will ask

For a submission that uses Conditional Access, the assessor typically asks:

1. Export the tenant's Conditional Access policy summary.

2. Show the sign-in frequency / token lifetime.

3. Show a representative sample of sign-in logs proving MFA is being invoked.

4. Document any exclusions (admin break-glass, service accounts) and compensating controls.

Prepare these before submitting.

Bottom line

Under v3.3, "require MFA always" is the default correct answer. Trusted-IP exemptions that worked under v3.2 mostly fail now. If you already have Conditional Access, tighten your baseline policy to always-require-MFA and block legacy auth.

Start Cyber Essentials | Buy CE Micro £299.99 | MFA pillar