Skip to content

Field note

Cyber Essentials MFA Cloud Auto-Fail

MFA problems usually hide in the gaps between policy intent and tenant reality - broad exclusions, awkward guest access, old admin habits, and emergency accounts that nobody really monitors.

Published23 Apr 2026

Updated2 weeks ago

Read time3 min · 620 words

AuthorGyorgy Bolyki

There is no polite version of this one.

The current Cyber Essentials position is that cloud service authentication must always use MFA, and IASME has already highlighted an auto-fail policy for not implementing MFA where it is available. For Microsoft 365 environments, that moves MFA out of the "security improvement" bucket and into the "basic pass condition" bucket.

That is the right call. Too many tenants still rely on half-finished coverage, a pile of exclusions, or the assumption that "admins definitely have MFA". Usually they do, until someone checks the service accounts, the emergency accounts, guest access, or the old policy nobody wanted to touch.

Where Microsoft 365 MFA usually goes wrong

The obvious problem is missing enforcement. The less obvious problem is enforcement that looks broad but is full of carve-outs.

Common examples:

GapWhy it matters
Broad Conditional Access exclusionsA good-looking policy can still leave whole groups outside enforcement
Admin portals not treated as high priorityThe accounts with the most power need the least ambiguity
Guest access assumptionsExternal users can still become a weak point if trust settings are not understood
Legacy policy sprawlOlder CA policies can overlap badly and create strange results
Emergency accounts without controlsBreak-glass is fine. Break-glass plus zero monitoring is not fine

One practical rule helps here: if you cannot explain why an exclusion exists in one sentence, it probably should not be there.

What a clean MFA review looks like

For Microsoft 365, I would review these five things first:

  1. A baseline policy that targets all users and all resources, or a clearly equivalent design.
  2. Separate attention on administrative access, including Microsoft admin portals.
  3. Authentication methods allowed in the tenant.
  4. Guest and external access behaviour.
  5. Emergency account handling, including alerting and ownership.

This is where a lot of teams lose time. They review registration, but not enforcement. Or they review enforcement, but not targeting. Or they review targeting, but ignore the fact that a single exclusion group now contains half the company because it was convenient six months ago.

Evidence that actually helps

If you are preparing for assessment or just trying to be sane about the tenant, keep evidence that answers specific questions:

QuestionEvidence
Are users required to do MFA?Conditional Access policy export or screenshots showing scope and grant controls
Are admin paths covered?Separate policy or documented coverage for admin portals and privileged roles
Are there exclusions?Named exclusion list with owner and reason
Are methods controlled?Authentication methods policy
Are emergency accounts governed?Account list, storage method, alerting process, and review notes

If all you have is one screenshot of a policy name, you do not really have evidence yet.

The Microsoft 365 angle people forget

Conditional Access is powerful, but it is also very easy to misread. Multiple policies can apply at once, and all applicable policies must be satisfied. That means a tenant can look protected while still behaving unexpectedly for a specific app, user type, or access path.

So do one live test with a normal user and one with a privileged admin. Do not just inspect the policy. Validate the experience.

That bit feels boring, but it is usually where the confidence comes from.

References

Related notes

Need help mapping this to your own tenant, controls, or assessment timeline?