Cyber Essentials Plus MFA Failure Casebook, Five Patterns the Assessor Sees Routinely

Net Sec Group is an IASME and NCSC certification body. Of the 16 recurring CE Plus failure patterns we see across our 800+ assessment history, the largest single share comes from multi-factor authentication. The control is meant to be in place. The configuration appears, to the firm, to be in place. The assessor's view of the technical reality disagrees.

This article walks five MFA failure cases the assessor encounters routinely. Each case is anonymised. Each case describes the symptom, what the assessor saw on the live screen-share, the underlying technical reason it failed the IASME Cyber Essentials Plus test specification, the fix, and the evidence format that subsequently passed.

If you are about to go through CE Plus, the patterns below are the ones to defuse before the assessor logs in. If you have already failed on MFA, this is the diagnostic.

Why MFA fails CE Plus more than any other control

Three factors compound on MFA more than on any other control:

  1. The platform-level toggle ("MFA is enabled") and the policy-level enforcement (a Conditional Access policy that targets a role group with no exclusions and blocks legacy authentication) are different things, and the platform UI does not always make the difference visible
  2. The administrative role surface is broad. Microsoft 365 alone has Global Administrator, User Administrator, Exchange Administrator, SharePoint Administrator, Privileged Role Administrator, and a dozen more. A policy that targets one role group misses the others
  3. Operational pressure to allow exceptions (a senior director travelling, a contractor on a non-managed device, a break-glass account) corrodes the policy without anyone noticing until the assessor sees the live state

The five cases below are recurring, not edge cases. Across the engagements where MFA fails on the day, at least one of these five patterns is present in the live state the assessor finds.

Case 1: per-user MFA enabled in Microsoft 365 admin, no Conditional Access policy

Symptom

The applicant submits a screenshot of the Microsoft 365 admin centre's "Multi-factor authentication" page showing all administrative users marked as Enforced. The applicant believes MFA is in place.

What the assessor saw

The assessor opened the live tenant, navigated to Microsoft Entra, and looked for the Conditional Access policy enforcing MFA on administrative roles. There was none. The applicant's MFA was per-user MFA only, configured at the legacy Microsoft 365 admin centre.

Why it failed

Per-user MFA in Microsoft 365 enforces only at the modern authentication flow level. Legacy authentication protocols (basic auth on Exchange Online, SMTP AUTH, IMAP, POP, older ActiveSync clients) bypass per-user MFA when those protocols are still permitted on the tenant. The IASME Cyber Essentials Plus test specification expects MFA that cannot be bypassed.

The NCSC multi-factor authentication guidance frames the same point: a strong second factor is one that cannot be circumvented by a different protocol or sign-in path.

Fix

Two configurations land together:

  1. A Conditional Access policy targeting the privileged-roles set in the role selector (the standard 14 directory roles flagged as privileged, or whichever administrative groups are in scope), requiring MFA, no exclusions for the assessment window
  2. A sibling Conditional Access policy that blocks legacy authentication tenant-wide

Both deploy in minutes via Microsoft Entra. The applicant should run a 24-hour observation window to confirm no legacy-auth sign-ins are subsequently blocked from active services.

Evidence that passed

A Conditional Access policy export from Entra showing the policy applies to the administrative role group and the access controls require MFA, plus a tenant sign-in report showing administrative sign-ins satisfied the MFA challenge in the 24 hours after deployment.

Case 2: MFA bypass via legacy authentication still permitted

Symptom

The applicant has a Conditional Access policy enforcing MFA on the Global Administrator role. The assessor's external scan discovers that the IMAP and SMTP AUTH endpoints on Exchange Online accept basic authentication and let an attacker through with username and password only.

What the assessor saw

The Conditional Access policy was real. The legacy-authentication block policy was missing. A legacy auth client with a stolen credential could reach the tenant without ever encountering the Conditional Access flow.

Why it failed

The Conditional Access policy that enforces MFA on the modern authentication flow does not enforce on the legacy authentication flow. Microsoft has documented this for years; the fix is the "Block legacy authentication" Conditional Access policy.

Fix

Deploy a Conditional Access policy that blocks legacy authentication tenant-wide. Microsoft retired basic auth on most Exchange Online services in 2022 and 2023, but SMTP AUTH and a small set of legacy clients remain reachable on tenants that have not explicitly blocked them. The block policy closes the gap.

Evidence that passed

A Conditional Access policy export showing "Block legacy authentication" is in effect tenant-wide, plus a tenant sign-in report showing zero successful legacy-auth sign-ins on the day of the assessment.

Case 3: MFA only on the primary admin, not on secondary admin accounts

Symptom

The applicant has a Conditional Access policy targeting the Global Administrator role. The applicant has not noticed that there are five other administrative roles in use on the tenant: User Administrator, Exchange Administrator, SharePoint Administrator, Authentication Administrator, and Cloud Application Administrator.

What the assessor saw

The assessor walked the role list in Entra and found three users assigned to administrative roles other than Global Administrator. None of those users were covered by the Conditional Access policy because the policy targeted Global Administrator only.

Why it failed

The IASME Cyber Essentials Plus test specification expects MFA on every administrative interface. "Administrative" is not synonymous with "Global Administrator". A User Administrator can reset other users' passwords; an Exchange Administrator can read and exfiltrate mailbox content. The test scope covers all of those.

Fix

Two paths:

  1. Convert the Conditional Access policy from targeting Global Administrator to targeting "All administrative roles" via the role-group selection in Conditional Access (the Privileged Roles group covers the standard set)
  2. Audit the role assignments on the tenant. Remove standing administrative roles from any user who does not need them, and replace them with Privileged Identity Management just-in-time activation where the platform supports it

Evidence that passed

The updated Conditional Access policy export showing all administrative role groups are in scope, plus the role-assignment audit showing the standing administrative role membership has been pruned to only those users who need it.

Case 4: MFA enforcement scoped to a security group that excludes a sample user

Symptom

The applicant has a Conditional Access policy enforcing MFA on a security group called "MFA Required". The group was set up some time ago and not refreshed when new admin users joined. A sampled administrative user has joined the firm in the last six months and is not in the "MFA Required" group.

What the assessor saw

The Conditional Access policy targeted a static security group. The group's membership had drifted. A sampled admin user signed in without an MFA challenge during the assessment.

Why it failed

The policy did not match the live administrative population. The test scope is the live administrative population, not the historical security group.

Fix

Replace the static security group with a dynamic group based on role membership, or replace the security-group target with a role-group target in the Conditional Access policy. Both are configurations in Entra; the dynamic-group route is more resilient to staffing changes.

Evidence that passed

The updated Conditional Access policy export targeting role membership, plus a tenant report showing every active administrative user satisfied an MFA challenge in the 30 days before the re-test.

Case 5: MFA evidence presented as a feature toggle rather than a tenant-wide policy

Symptom

The applicant submits a screenshot of "Security defaults are on" from the Microsoft 365 admin centre as MFA evidence.

What the assessor saw

Security defaults were on. Security defaults enforce MFA in some sign-in scenarios but not others. The tenant had no Conditional Access policy because Security defaults and Conditional Access are mutually exclusive at the tenant level: enabling either disables the other.

Why it failed

Security defaults are a baseline aimed at small Microsoft 365 customers without dedicated security configuration. They do not provide the granular policy enforcement the IASME Cyber Essentials Plus test specification expects on administrative interfaces. They do not block all legacy authentication paths. They are not the test-aligned configuration.

Fix

Disable Security defaults on the tenant. Replace with explicit Conditional Access policies covering: MFA on administrative role groups, block legacy authentication, MFA on user role groups for cloud admin consoles in scope. The migration path is documented by Microsoft and takes a working day for a small tenant, longer for a larger one with more conditional flows to model.

Evidence that passed

A Conditional Access policy export showing the explicit policy set, plus a screenshot showing Security defaults are off, plus a tenant sign-in report covering 30 days of administrative sign-ins all satisfying the new policy.

Patterns the cases share

Across the five cases, three patterns repeat:

  1. The applicant believes MFA is in place at the platform level. The assessor confirms the platform-level toggle. The assessor then looks for the policy-level enforcement and finds the gap
  2. The applicant scoped MFA to one administrative role or one security group. The assessor walks the live administrative population and finds users outside the scope
  3. The applicant has not blocked legacy authentication. The bypass exists irrespective of how good the modern-auth MFA configuration is

The fix shape repeats too. A Conditional Access policy targeting "all administrative roles" (or a dynamic group based on role) plus a sibling policy blocking legacy authentication closes Cases 1 through 5 collectively.

Pre-assessment MFA checklist

If you are 48 hours out from CE Plus, run through this checklist against your administrative tenants:

  1. Is there a Conditional Access policy enforcing MFA on every administrative role, or on a dynamic group based on role membership?
  2. Is there a Conditional Access policy blocking legacy authentication tenant-wide?
  3. Are Security defaults disabled (because Conditional Access is in use)?
  4. Has the administrative role membership been audited in the last 30 days, including secondary administrative roles, not just Global Administrator?
  5. Is there a documented break-glass account, stored in a vault, with the access path alerting on use?
  6. Has a sample sign-in report been pulled for the last 30 days showing all administrative sign-ins satisfied MFA?
  7. Have any temporary MFA exceptions been removed (the senior director's holiday exception, the contractor's "we trust you" exception)?

For the broader pre-assessment evidence checklist that includes MFA and the other four controls, see The evidence the CE Plus assessor accepts on this site. For the full set of CE Plus failure patterns across all five controls, see The most common CE Plus failures by control.

Common questions

Is hardware-token MFA acceptable, or does it have to be a phone-based authenticator?

Either is acceptable. The IASME Cyber Essentials Plus test specification names the security property (a second factor that cannot be bypassed), not the form factor. Hardware tokens (FIDO2 keys, smartcards), authenticator apps with push notifications, and authenticator apps with TOTP codes are all in scope. SMS-based codes are accepted but are weaker than the alternatives, and the NCSC multi-factor authentication guidance recommends moving away from SMS where the platform supports it.

Is MFA on personal email accounts in scope?

No, unless the personal email is being used to access the firm's in-scope cloud admin console. The test scope is the firm's administrative interfaces. A user's personal Gmail is out of scope; a user's personal Gmail being used as a recovery channel for the firm's cloud admin account brings the recovery channel in scope.

What if a senior user objects to MFA on a phone they do not want to use for work?

Issue them a hardware token. The control is the security property, not the device. A FIDO2 key on a keyring satisfies the test without involving the senior user's phone.

Does MFA on the bastion or VPN count as MFA on the cloud admin console?

Only if the bastion or VPN is the only path to the cloud admin console and there is no fallback path that does not pass through the bastion. In practice this is rare. Add MFA on the cloud admin console directly.

What if our tenant uses an IdP federation (Okta, Ping, ADFS)?

The Conditional Access enforcement applies at the IdP. MFA enforced at the IdP, with the cloud admin console relying on the IdP for authentication, satisfies the test. Make sure the IdP's MFA enforcement is the policy-level kind, not just a feature toggle.

Next steps

For the deeper netsecgroup.io references:

When you are ready to book or want a pre-assessment MFA review against your own tenant before booking, contact Net Sec Group or book a Cyber Essentials Plus assessment directly.