How to Answer the MFA Section of a 2026 Cyber Insurance Questionnaire

By Jonathan Fykes, CTO · Published February 21, 2026 · Last updated April 26, 2026

You have the renewal questionnaire on the desk. The MFA section runs half a page. Each question is worded in a specific way, and the difference between a yes that passes and a yes that gets your claim denied later is a sentence you have not seen before.

This page is the worksheet for that section. It walks through the questions carriers are actually printing on 2026 forms, in the wording they use, and shows you the answer that holds up under audit and the evidence to attach. It is written for the owner or CFO holding the pen, not the IT person on the other end of the email. For the broader twelve-control view of the form, the full 2026 cyber insurance requirements rundown covers everything else.

What MFA actually is, in two sentences

Multi-factor authentication means logging in needs two different proofs of identity instead of one. The first proof is usually a password (something you know). The second proof is something you physically have, like a code from an app on your phone, a tap on a notification, or a small USB key plugged into your laptop.

The technical term for each proof is a "factor." Two factors are better than one because an attacker who steals your password from a data breach still doesn't have your phone or your hardware key. Microsoft's own published numbers say MFA blocks more than 99 percent of automated account-takeover attempts. That single statistic is why your insurance carrier cares so much about whether you have it.

Why MFA became the keystone of every questionnaire

It wasn't always like this. As recently as 2019, you could buy a million dollars of cyber coverage with a one-page application that didn't even mention MFA. Then ransomware industrialized and the math broke.

Coveware, the incident response firm that publishes a quarterly ransomware report, found that stolen or guessed passwords were the single most common way attackers got into networks during the 2020 to 2022 wave. Phishing kits, credential-stuffing tools, and lists of breached passwords from old data dumps all pointed at the same door: an account with a password and no second factor. Once an attacker walked through that door, they had email, files, and often a path to a domain admin account.

Carriers paid the bill. Loss ratios at major underwriters crossed 100 percent in 2020 and 2021, meaning they paid out more in claims than they collected in premium. By the start of 2022 the industry had figured out the pattern and tightened underwriting in lockstep. Premiums went up 50 to 100 percent year over year. Sub-limits on ransomware dropped. And MFA stopped being a "nice to have" on the application; it became a hard precondition for most policies.

The reasoning was simple. If MFA blocks 99 percent of the attack pattern that drove the loss ratio, requiring it eliminates almost all of the bad outcome. So they required it. By 2024 a small business without MFA on email and admin accounts was effectively uninsurable at any reasonable price.

Basic MFA, strong MFA, phishing-resistant MFA

Not all MFA counts the same. Carriers caught up to that distinction around 2023 and the bar has kept moving since.

Basic MFA is any second factor at all. SMS text codes, automated phone calls, an authenticator app. In 2022 every one of these counted as "yes, we have MFA." That is no longer the case for most carriers.

Strong MFA means an authenticator app (Microsoft Authenticator, Google Authenticator, Duo) or a hardware key. The reason this matters: SMS codes can be intercepted through a SIM-swap attack, where a criminal calls your phone carrier pretending to be you and ports your number to a phone they control. SIM swaps are not theoretical; the FBI's IC3 reports thousands of them every year, including against small business owners. NIST Special Publication 800-63B, the federal identity standard, formally deprecated SMS as a primary authentication factor back in 2017. Carriers cite that document by name in some 2026 questionnaires.

Phishing-resistant MFA is the current top tier. It means FIDO2 security keys (small USB devices like a YubiKey), Windows Hello for Business, or certificate-based smart cards. The "phishing-resistant" label comes from the FIDO Alliance, the industry body that defined the standard. These methods cryptographically tie the login to the actual website you're visiting, so even if a user types their password into a fake Microsoft login page, the second factor refuses to play along. Adversary-in-the-middle phishing kits like Evilginx defeat authenticator apps. They cannot defeat FIDO2.

What carriers accepted in 2022 versus 2026 looks roughly like this. In 2022, MFA on email plus MFA on admin accounts, any factor, was a passing answer. In 2024, SMS-only MFA started getting flagged. In 2026, the typical bar is authenticator app for users, phishing-resistant MFA for admins, and zero exceptions for VIP executives or service accounts. By 2027, several early-renewing carriers are already asking for phishing-resistant MFA on all users, not just admins.

The six places MFA must be deployed

This is where most "yes" answers turn into "no" answers under scrutiny. The questionnaire asks about MFA on email, but the auditor checks six surfaces. Miss any one and the truthful answer to "is MFA enforced everywhere?" is no.

1. Email and Microsoft 365 access for all users

Every employee's M365 sign-in. No carve-outs for the founder, no carve-outs for the bookkeeper, no "we'll get to the warehouse staff later." Carriers ask for the percentage covered and they want 100. The renewal-time penalty for partial coverage is usually a sub-limit reduction or a coinsurance clause attached to ransomware claims. The companion Microsoft 365 email security checklist covers what else lives in this category beyond the MFA box.

2. VPN and remote access

If you have a VPN for remote workers connecting into a server room, an on-premises file server, or a line-of-business app, that login needs MFA too. This is the surface most often missed. Many SMBs configured MFA on M365 in 2022 and never came back to the VPN. The pattern is consistent: email MFA looks perfect, the renewal questionnaire still gets flagged because the VPN that fronts an on-prem ERP, file server, or RDP gateway is exempted. The fix is usually an afternoon of work; the cost of leaving it open shows up in the renewal math at the bottom of this article.

3. Privileged and administrative accounts

Admin accounts are the highest-value targets in the tenant. Carriers expect stronger MFA on admins than on regular users, and most 2026 questionnaires now ask the question in two parts: "Is MFA enforced on admin accounts?" and "Is phishing-resistant MFA used for admin accounts?" The right answer to both is yes. In Microsoft 365 that means FIDO2 keys or Windows Hello for Business assigned to every admin role, with Privileged Identity Management activating elevated access only when needed.

4. Cloud admin consoles outside M365

If you have AWS, Azure outside your M365 tenant, Google Cloud, or any other cloud admin console, the root and admin accounts there need MFA. Carriers ask about this even for SMBs that use cloud lightly. The question often appears as "are MFA controls applied to all cloud administrative interfaces?" An AWS root account with no MFA is the kind of finding that fails an entire questionnaire.

5. Backup and recovery system access

Your backup admin console is the account a ransomware attacker most wants to compromise, because deleting backups before encrypting files is how modern ransomware ensures the ransom gets paid. Carriers know this and started asking specifically about MFA on backup tooling around 2024. Whether you use Veeam for Microsoft 365, Datto, Barracuda, or another product, the admin login needs MFA and ideally phishing-resistant MFA. This is also the surface where the "immutable backup" question lives, but the MFA piece is separate and equally weighted.

6. Remote desktop and RDP

If anyone in the organization uses Remote Desktop Protocol to connect into a Windows machine over the internet, that login needs MFA in front of it. Plain RDP exposed to the internet without MFA is one of the most common ransomware entry vectors in the FBI's annual report. Carriers ask about it directly: "Is RDP exposed externally? If yes, is MFA enforced?" The right combined answer is "RDP is not exposed externally, and where remote access is needed, it is gated by VPN with MFA or by a zero-trust gateway with MFA."

The MFA gaps that quietly fail audits

The six surfaces are the structural side. The other side is the small list of mistakes that look fine in the M365 admin center and still fail a careful audit.

SMS-only MFA. Already covered above, but worth repeating because this is the single most common finding. The fix is moving users to Microsoft Authenticator or Authy, both free.

VIP exclusions. The CEO travels constantly and complains about MFA, so someone exempted that account. Attackers love this because the CEO account also has wire-transfer authority. Every 2026 questionnaire we've seen has a question that maps to this directly: "Are any executive or VIP accounts excluded from MFA enforcement?" The right answer is no.

Service accounts without MFA. Service accounts (used by applications and automated jobs) usually can't prompt for a code, so they get exempted. That's reasonable, but it requires compensating controls. The cure is documenting each one, locking it to a specific source IP via Conditional Access, and treating it as a privileged identity. Carriers ask for the inventory.

Third-party SaaS apps not behind SSO. If your team logs into Salesforce, QuickBooks Online, or a dozen other SaaS tools with separate passwords and no MFA, those count as gaps even though they're not technically inside M365. The clean answer is putting them behind Microsoft Entra single sign-on so M365's MFA covers them, or enabling each app's native MFA.

Legacy authentication still allowed. This is the silent one. Older mail protocols like IMAP and SMTP AUTH don't support MFA at all, and on tenants that haven't been hardened they often still work. An attacker with a stolen password can authenticate over IMAP and walk straight past your MFA. The full breakdown of why this happens and the fix is on the sister site: block legacy authentication (the silent MFA bypass). If you read one cross-reference from this post, that's the one.

How to prove MFA to your carrier

The questionnaire doesn't usually stop at "do you have MFA, yes or no." There's a follow-up that asks for evidence. Here's what counts and what doesn't.

What counts. An export of Entra ID Sign-in Logs filtered to the last 30 days, showing the MFA result for each interactive sign-in. A screenshot or JSON export of the Conditional Access policies in Microsoft Entra showing the MFA grant control applied to All Users. A SIEM dashboard view (Microsoft Sentinel, Splunk, or similar) showing MFA enforcement metrics over the policy period. A signed attestation letter from a managed service provider that lists each control area, the M365 setting that satisfies it, and the date of last verification.

What doesn't count. A generic statement on company letterhead that says "MFA is enabled across our organization" with no specifics. A screenshot of the M365 admin center showing the "Security defaults" toggle is on (Security defaults is fine for very small tenants, but it's not the same as Conditional Access and most carriers will ask follow-ups). An email from someone at the IT vendor saying "yes we set it up" without listing scope. A printout of one user's MFA registration without coverage data for the rest of the organization.

The shortest path for most SMBs is asking the IT vendor or internal admin for two things: the Conditional Access policy export and a sign-in logs report filtered to MFA failures and successes. Both come out of the M365 portal in under 10 minutes. Together they answer the evidence question for almost every 2026 carrier.

The MFA fatigue problem and what to do about it

One newer wrinkle deserves a paragraph because carriers started asking about it in late 2024. It's called MFA fatigue or push-bombing.

Here's the attack. The criminal already has the user's password, from a phishing kit or a breach dump. They try to log in. The user's phone gets an MFA push notification asking "Approve sign-in?" The user, who didn't initiate anything, denies it. The criminal tries again. And again. And again, sometimes hundreds of times in a row, often at 2 a.m. Eventually the user, half-asleep and irritated, taps Approve just to make the notifications stop. The criminal is now signed in with a fully completed MFA prompt.

This is a real attack pattern. Uber's 2022 breach started this way. The defenses are concrete and inexpensive. Microsoft Authenticator now supports number matching, where the user has to type a two-digit number from the login screen into the app instead of just tapping Approve. Turn that on; it's a tenant-wide setting in Entra. For high-value accounts (admins, finance staff, the CEO), move to FIDO2 keys, which can't be push-bombed at all because there's nothing to "approve" remotely. Some 2026 questionnaires now ask explicitly: "Is number matching enabled on Microsoft Authenticator?" Yes is the right answer.

What MFA gaps actually cost in dollars

Theory is one thing. Renewal math is another.

The 50-person manufacturer mentioned earlier is a real example. Strong MFA on M365 email, but seven sales staff exempted from MFA on the company VPN because the VPN client kept dropping their connection. The carrier flagged the gap during renewal underwriting and quoted a 32 percent premium increase plus a $250,000 ransomware sub-limit. The remediation was four hours of work to put those seven users behind the same MFA policy as everyone else. After remediation and re-submission the renewal came in flat year over year. Net cost of the gap, had it gone unaddressed: roughly $14,000 in additional premium plus a meaningful loss of coverage if a claim landed.

The patterns we see consistently across SMB renewals: a 15 to 25 percent premium increase for partial MFA coverage that's documented, a 30 to 50 percent increase or non-renewal for missing MFA on a specific surface like VPN or admin accounts, and a flat renewal for full coverage with phishing-resistant MFA on admins and number matching enabled. The gap between the worst and best outcomes is often four hours of configuration work.

The other dollar figure worth knowing is the claim-time consequence. If a breach happens and forensics reveals the attacker entered through a surface where MFA was claimed but not actually enforced, the carrier may deny the claim citing material misrepresentation. That's worse than a premium increase. That's the policy not paying out at all. The honest answer on the questionnaire, with disclosed gaps and a remediation timeline, is always better than a "yes" that doesn't survive forensic review. The cyber insurance renewal checklist walks through how to stage that disclosure properly.

What MFA doesn't solve

One closing point so the picture is honest. MFA, even phishing-resistant MFA, is not a complete defense. It closes the credential-stuffing door, which is the biggest one. Token theft via adversary-in-the-middle phishing, OAuth consent attacks, and stolen session cookies are separate attack patterns that MFA alone doesn't fully address. Carriers know this, which is why the questionnaire has eleven other controls beyond MFA. The good news is that the eight M365-resident controls are configurable in the same admin center and the same week. The implementation case study walks through how a 30-person firm closed all twelve in 90 days.

Frequently asked questions

My carrier accepted SMS MFA last year. Will they this year?

Maybe, but the trend is clearly against it. Many carriers that accepted SMS in 2024 have moved to "authenticator app or stronger" for 2026 renewals, and a few are now requiring phishing-resistant MFA for admin accounts. The safe move is to migrate to Microsoft Authenticator (or your preferred app) for all users now, before the form lands. The user-side change takes about five minutes per person.

We have MFA on email but not VPN. Do we say yes or no?

Say no, and disclose the gap with a fix date. The questionnaire question is almost always phrased "Is MFA enforced for all users on email, VPN, and remote access?" with the word "and" doing the work. Answering yes when VPN is uncovered is the kind of misrepresentation that gets a claim denied later. Brokers will usually negotiate a 30 to 60-day cure period if the rest of the application is strong.

What about service accounts that can't use MFA?

Document each one, lock it to a specific source IP via Conditional Access, give it a long randomly generated password stored in a vault, and grant it the minimum permissions it actually needs. Carriers expect a list of service accounts with these compensating controls in place. "We have a few service accounts without MFA" with no further detail is the bad answer. "We have four service accounts, listed in the attached document, each scoped to a single source IP and reviewed annually" is the answer that passes.

Is Microsoft 365 Security Defaults enough?

For a tenant under 25 users with no special requirements, Security Defaults turns on a basic MFA policy and is better than nothing. For most insurance questionnaires from 2024 onward, carriers want to see Conditional Access policies because they offer per-app, per-user, per-condition control that Security Defaults can't match. If you're answering a renewal that asks about Conditional Access by name, Security Defaults will not pass.

How do I check what we actually have today?

Two things. First, ask whoever runs your M365 to export the Conditional Access policies and the last 30 days of sign-in logs filtered to MFA. Read the policies for which users they apply to and which apps they cover. Second, run the M365Shield risk check, which compares your tenant settings against the 2026 questionnaire baseline and produces a written report you can hand to your broker. Both together take less than a day and tell you exactly which of the six surfaces are covered and which aren't.