Cyber Insurance MFA Requirements for Microsoft 365: What "MFA Everywhere" Means in Practice

The short version: When a cyber insurance questionnaire asks for "MFA everywhere", it usually means every user, every administrator, every remote entry point and every mailbox, with exceptions written down rather than hidden. In Microsoft 365 you prove it with a dated registration report and an export of the Conditional Access policies that enforce it. This article covers only the MFA question: which accounts, which methods, how to word exceptions and what evidence to attach.

Most cyber insurance MFA requirements arrive as one or two lines on a renewal form: "Is multi-factor authentication enforced for all users, including remote access and email?" and, increasingly, "Is MFA enforced for all privileged accounts?" The lines are short. The work behind an honest "yes" is not, and a "yes" that turns out to be a "mostly" is the kind of thing that gets argued about after a claim.

This article stays on that one question. It does not walk through the whole form; the wider questionnaire is covered in our guide to the Microsoft 365 evidence insurers ask for, and the renewal process as Hong Kong firms experience it is in the Hong Kong renewal view. Here we take the MFA line apart: what "everywhere" means, which methods count, how to declare exceptions without them reading as a "no", and what you can export from a Microsoft 365 tenant that is designed to be used as evidence.

We write it with UK and Australian businesses in mind, because that is where most of the people asking us about this are, but the tenant settings are the same wherever you sit.

What does "MFA everywhere" mean on a cyber insurance questionnaire?

Insurers rarely define the phrase, so the safest reading is the widest one. In practice the question is asking about six groups of sign-ins, and a complete answer covers all six:

• All users. Every licensed account that can sign in to Microsoft 365, not only office staff. Part-timers, contractors with accounts, the finance assistant who "only uses Teams".
• All administrators. Every account holding a privileged role in Entra ID: Global Administrator, Exchange Administrator, SharePoint Administrator, User Administrator, Security Administrator and the rest. This is often a separate line on the form.
• Remote access. Anything that lets someone into company systems from outside: VPN, remote desktop gateways, published applications. For a cloud-first company this is mostly Microsoft 365 itself, but if a VPN appliance still exists it is in scope.
• Email and webmail. Outlook on the web, mobile mail, and any protocol that can read a mailbox. The reason this is called out separately is that legacy protocols such as IMAP, POP and SMTP AUTH can bypass MFA entirely unless they are blocked.
• Privileged and service accounts. Shared mailboxes with sign-in enabled, "scanner" accounts, integration accounts, the old on-premises sync account. Insurers know these are where MFA quietly does not apply.
• Third-party applications. Cloud apps that use your Microsoft 365 identity (single sign-on) inherit your MFA policy. Apps with their own separate logins do not, and some forms ask about those too.

If you can say "yes" to all six, you have MFA everywhere. If you can say "yes" to four and "no, because" to two, you have something you can still describe honestly, which is the subject of the exceptions section below.

Which accounts does MFA actually cover in a Microsoft 365 tenant?

The honest answer depends on how MFA was switched on, because the two supported mechanisms behave differently. Our step-by-step guide to enabling MFA in Microsoft 365 covers the clicks; here is what each one means for the questionnaire.

Security defaults is a single tenant-wide switch. When it is on, every user must register for MFA, administrators are always prompted, legacy authentication is blocked and the Azure management portals require MFA. There are no exclusions. For a questionnaire that is convenient: the answer is "yes, enforced for all users by tenant policy", and the evidence is a screenshot of the setting plus the registration report.

Conditional Access is the policy engine available with Microsoft Entra ID P1, which Microsoft 365 Business Premium includes. It lets you require MFA for everyone, for administrators, for specific applications or for risky sign-ins, and it lets you exclude groups. The flexibility is the point, and it is also the problem: every exclusion is an account that may sign in without MFA, and the questionnaire is implicitly asking about those. A well-built baseline, such as the six policies in our Conditional Access baseline guide, includes "require MFA for all users", "require MFA for administrators" and "block legacy authentication", each excluding only a small, named emergency-access group.

What the questionnaire is really probing for is the gap between "we turned MFA on" and "every account that can sign in is actually challenged". The gap usually lives in one of four places:

• Accounts never asked to register. A user can be in scope of a policy and still have no method registered if they have not signed in since the policy went live. A registration report shows them.
• Excluded groups that grew. The emergency-access exclusion that gained a director, a consultant and "the IT guy" over two years.
• Legacy authentication still allowed. IMAP, POP, SMTP AUTH and older Office clients can authenticate with a password alone unless a policy blocks them. This is the single most common reason a "yes" is really a "no".
• Shared mailboxes and service accounts with sign-in enabled. A shared mailbox should have sign-in blocked; if it does not, it is a user account with a password and, usually, no MFA.

Which MFA methods do insurers ask about, and what counts as phishing-resistant?

Over the last two years the question has shifted from "do you have MFA" to "what kind". Some forms now ask directly whether administrators use phishing-resistant MFA, and some ask whether SMS is still in use. Microsoft 365 supports a range of methods, and they are not equal.

SMS and voice call versus authenticator app versus phishing-resistant methods

• SMS and voice call. The code is sent to a phone number. Works for everyone, needs no app, and is the weakest option: SIM-swap fraud and real-time phishing pages that relay the code both defeat it. Many questionnaires now ask whether this is the only method in use, and the preferred answer is "no, and it is disabled for administrators".
• Authenticator app push with number matching. The user approves a prompt and types the number shown on screen. Microsoft Authenticator now uses number matching for push approvals, which closes the "approve by accident" problem. Resistant to prompt-bombing, still vulnerable to a convincing real-time phishing page that proxies the whole sign-in. This is the sensible default for ordinary users.
• Phishing-resistant methods: passkeys (FIDO2), Windows Hello for Business and certificate-based authentication. The credential is bound to the real sign-in page, so a proxy page cannot replay it. This is what "phishing-resistant MFA" means on the form, and it is what an increasing number of questionnaires expect for Global Administrators at minimum. Microsoft's Conditional Access offers an authentication-strength control that can require it for a named group.
• Temporary Access Pass and other recovery methods. Fine for onboarding and recovery; not an answer to "what MFA do your users use".

A defensible position for a small or mid-sized tenant is: authenticator app with number matching for all users, phishing-resistant methods required for privileged roles through an authentication-strength policy, and SMS and voice disabled or limited to a documented fallback group. If that is not where you are yet, say where you are and when you plan to change it. An insurer can underwrite a plan; it cannot underwrite a statement that later turns out to be untrue.

How should you write MFA exceptions so they are not read as a "no"?

Almost every real tenant has exceptions, and the questionnaire usually gives you a free-text box for them. The mistake is to leave the box empty and tick "yes". The better pattern is to tick "yes, with the following documented exceptions" and then list each one with three pieces of information: what it is, why MFA does not apply, and what compensating control covers it.

• Emergency access (break-glass) accounts. Two cloud-only accounts excluded from MFA policies so the tenant can be recovered if MFA or Conditional Access breaks. Compensating controls: very long passwords stored offline, sign-in alerting, and no daily use. This is a standard, well-understood exception and you should name it.
• Shared mailboxes. Not an exception at all if sign-in is blocked, which is the correct configuration. Say so: "shared mailboxes have interactive sign-in disabled and are accessed only through licensed, MFA-protected user accounts".
• Service and integration accounts. A multifunction printer that sends scans by email, an on-premises application that reads a mailbox. The honest answer is the protocol and the control: "one service account uses SMTP AUTH from a fixed internal IP, restricted by Conditional Access to that location; migration to OAuth is scheduled". Note that Microsoft has announced the retirement of basic authentication for SMTP AUTH, so this exception has a natural end date and the form can say so.
• Legacy devices. The warehouse PC that cannot run the authenticator app. Either move it to a device-bound method (Windows Hello for Business) or document the device, the user, the data it can reach and the date it will be replaced.
• Guests. External users invited into Teams or SharePoint. State whether your Conditional Access policy requires MFA for guests (it should) and whether their home tenant's MFA is trusted.

Written this way, exceptions read as governance rather than gaps. An underwriter who sees "yes" with a blank box has to guess; one who sees five named exceptions with controls and dates can price the risk.

What evidence do insurers ask for, and what can you export from Microsoft 365?

The form itself is a declaration; the evidence sits behind it, and you may be asked for it at renewal, during a claim, or by a broker who wants to place the risk with a better market. Everything below can be produced from the tenant without buying anything, and each item is dated by the tenant when exported.

1. Authentication methods registration report. Entra ID reports which users have registered which methods and who is "MFA capable". Export it to CSV. This is the single most useful document for the MFA question because it shows coverage per account, not just policy intent.
2. Conditional Access policy export. Each policy's users, exclusions, cloud apps, conditions and grant controls. The exclusions list is what proves the exceptions section is complete.
3. Legacy authentication sign-in report. The sign-in log filtered to legacy client apps for the last 30 days. Empty is the answer you want; non-empty tells you which devices still need attention before you can say "blocked".
4. Privileged role membership. A list of accounts in each administrator role, with the method each one uses. For the "MFA for privileged accounts" line.
5. Security defaults or authentication strength screenshots. The setting pages, with the tenant name and date visible.
6. A short exceptions register. The five-item list from the section above, with owner and review date.

Our own Microsoft 365 security audit produces exactly this set, written up so a non-technical owner can read it, and the sample audit report shows how the MFA findings are presented: the number of accounts without a method, the administrators among them, the legacy protocols still open, and the policy exclusions, each with a fix and a rollback. The report and its evidence workbook are designed to be used as evidence in an insurance questionnaire. They do not decide the underwriting outcome, and we do not say otherwise.

What are the common ways an honest "yes" turns out to be wrong?

These are the findings we see most often when an MFA declaration is checked against the tenant. None is exotic.

• MFA "enabled" per user but not enforced. The old per-user MFA setting has "enabled" and "enforced" states; "enabled" allows password-only sign-in until the user completes registration. If MFA was set up years ago this way, some accounts may still be in that state.
• Conditional Access policies left in report-only mode. Report-only is the right way to test a policy. It enforces nothing. A policy that has sat in report-only since the day it was created is a policy that does not exist for the purposes of the form.
• Exclusion groups nobody reviews. The group was created for two emergency accounts. It now has nine members.
• Legacy authentication not blocked. Security defaults block it; Conditional Access only blocks it if a policy says so. Without the policy, IMAP with a password works.
• Microsoft 365 Business Basic tenants without a policy engine. Without Entra ID P1 the choice is security defaults or nothing. "Nothing" is surprisingly common in tenants that were set up by a reseller and never revisited.
• Administrators using their everyday account. The same account reads email, opens attachments and holds Global Administrator. MFA may be on, but the blast radius of one phish is the whole tenant. Some forms now ask about this directly.

Each of these is a setting, not a project. The hard part is knowing which ones apply to your tenant, which is why the first step is a read, not a rebuild.

How does the MFA question relate to Cyber Essentials and other schemes?

For UK readers there is a direct overlap. Cyber Essentials version 3.3 treats MFA on cloud services as a requirement rather than a recommendation, and a cloud service that offers MFA but has it switched off is an automatic fail; our setting-by-setting Cyber Essentials guide walks through the Microsoft 365 side. The practical point is that the evidence set above answers both the insurer and the scheme assessor, so it is worth producing once and keeping current.

For Australian readers, questionnaires tend to reference the Essential Eight maturity model, where MFA is one of the eight strategies and the maturity levels distinguish between "MFA for remote users" and "phishing-resistant MFA for all". The Microsoft 365 configuration that satisfies a demanding insurer and the one that reaches the higher maturity levels are the same configuration. We do not assess against or sign off on either scheme; we read the tenant and tell you what it would show.

If you need a provider who can produce the evidence pack and talk you through it in your own working hours, the UK and Australia pages explain how we deliver remotely, and the audit page has a section for UK and Australian buyers.

Frequently asked questions

Does "MFA for all users" include guests and external users?

Usually yes, if the form says "all users". In Entra ID, guests are a selectable scope in Conditional Access, so you can require MFA for them and, if you trust the other organisation's MFA through cross-tenant access settings, accept it instead of asking twice. Whichever you choose, say it in the exceptions box.

Is SMS-based MFA still acceptable to insurers?

Some accept it for ordinary users and object to it for administrators; others ask you to state whether SMS is in use at all. We cannot tell you how a particular insurer will treat it, and nobody honest can. What we can say is that disabling SMS and voice for privileged roles and moving them to a phishing-resistant method is a small change that removes the question.

What is phishing-resistant MFA in Microsoft 365 terms?

Passkeys (FIDO2 security keys or device-bound passkeys in the Authenticator app), Windows Hello for Business and certificate-based authentication. Conditional Access can require one of these through an authentication-strength policy, typically applied to administrator roles first.

Does the Microsoft 365 security audit prove we have MFA everywhere?

It shows what the tenant is configured to do on the date it was read, account by account, including the exclusions and the legacy protocols still open. The report is designed to be used as evidence. It is not a certification, and whether an underwriter is satisfied is their decision, not ours.

We have Microsoft 365 Business Basic. Can we still answer "yes"?

Yes, by turning on security defaults, which enforces MFA registration for all users and blocks legacy authentication with no licence beyond your subscription. You lose the ability to exclude anything, which for a small tenant is often an advantage. If you need exclusions or phishing-resistant enforcement for administrators, you need Entra ID P1, which Business Premium includes.

How does Cyber Essentials treat MFA on Microsoft 365?

Version 3.3 of the scheme requires MFA on cloud services wherever the service offers it, and an available but disabled MFA is treated as an automatic fail for that control. The audit does not grant or guarantee certification; it tells you where the tenant would fall short before an assessor does.

How long does it take to get the evidence together?

If MFA is already enforced through Conditional Access, an afternoon: export the registration report, the policies, the legacy sign-in report and the role membership, and write the exceptions register. If it is not, the exports will tell you what to fix first, and our audit returns the same findings as a prioritised list within 5 to 7 business days of read-only consent, priced from US$450 for a 1 to 10 user tenant.

Next steps

If you have a renewal form on your desk, start with the registration report and the Conditional Access export; they answer most of the MFA line on their own. If you would rather someone read the whole tenant and write the evidence pack for you, the Microsoft 365 security audit is a fixed price by headcount, delivered remotely in 5 to 7 business days. If the finding is that MFA was never properly rolled out, our MFA solutions team does that work, and the accounting-firm rollout story shows what a staged rollout looks like in a firm that cannot afford a lockout. Or talk to a consultant and bring the form.