What MFA does cyber insurance require in 2026?

Read the complete guide: How do you make your IT cyber-insurance defensible? A 2026 guide for commercial businesses.

What MFA does cyber insurance require in 2026?

In 2026 every major cyber insurance carrier requires multi-factor authentication (MFA) on every privileged or administrative account, every remote access path, every email account, and every cloud admin interface. Higher-tier policies increasingly require phishing-resistant MFA (FIDO2 hardware keys or WebAuthn) on privileged accounts. SMS-based codes are still accepted as a floor for general users but are explicitly disfavored for high-value targets.

Which MFA factors do carriers accept?

The carrier hierarchy of acceptable MFA factors, from strongest to weakest, is roughly:

1. FIDO2 / WebAuthn hardware security keys. CISA classifies hardware-backed FIDO2 as the gold standard for phishing-resistant MFA (CISA, Implementing Phishing-Resistant MFA). Carriers credit this most.
2. Platform authenticators (Windows Hello, Touch ID, Face ID with attestation). Hardware-bound, phishing-resistant, accepted by most carriers as equivalent to FIDO2 keys.
3. Authenticator app push with number matching. Microsoft Authenticator and Duo with number matching are accepted broadly. Push without number matching is increasingly questioned because of MFA fatigue / push-bombing risk.
4. Time-based one-time password (TOTP) apps. Google Authenticator, Authy, and similar. Accepted but considered a step below push.
5. SMS / voice codes. The floor. Accepted for general user accounts. Explicitly inadequate for privileged accounts in most current policies.

The shift from "any MFA" to "phishing-resistant MFA" is the most important MFA change between 2023 and 2026. CISA issued guidance urging organizations toward phishing-resistant MFA and recommending number matching as a minimum mitigation for push-based MFA where phishing-resistant is not yet feasible (CISA, Phishing-Resistant MFA Is Key to Peace of Mind). Carriers tracked that guidance closely.

Where must MFA be enforced for the policy to apply?

The 2026 carrier consensus on MFA scope is: every privileged or administrative account, every remote access path (VPN, RDP, SSH, jump hosts, bastion hosts), every email account, every cloud admin console (Microsoft 365 admin centers, Azure portal, AWS console, Google Workspace admin), every Remote Monitoring and Management (RMM) tool, every backup admin interface, and every financial system. Each scope item below has been the basis of a denied claim somewhere in the market.

• Privileged accounts: Domain admins, global admins, application admins, service accounts with elevated rights. Service accounts are the single most common gap because they often pre-date MFA rollouts.
• Remote access: VPN with MFA at the firewall AND on the remote desktop or terminal server is the standard. VPN-only MFA is no longer sufficient.
• Email: Both web and mobile access. Modern auth only; legacy auth (basic auth, app passwords without MFA) must be disabled.
• Cloud admin consoles: Every console an admin uses. Microsoft 365 has multiple admin centers; covering only the main one is a finding.
• RMM and backup interfaces: Frequently missed because the IT team treats them as internal. Carriers treat them as crown-jewel access.

What happens if MFA is enabled but bypassed?

The largest source of denied claims in this category is "MFA was attested but not enforced where it mattered." Three patterns recur:

• Legacy authentication left enabled. Basic auth, IMAP, POP3, SMTP AUTH protocols that bypass modern auth. If your tenant still allows these, an attacker with valid credentials can bypass MFA entirely.
• App passwords or service-account exclusions. Conditional Access policies often exclude service accounts; if those exclusions are not documented and re-evaluated quarterly, they become the breach path.
• Conditional Access gaps. Policies that require MFA but exclude specific locations, applications, or user groups. The exclusions stack up over time and become an attestation problem.

Coalition's data continues to show MFA gaps as a dominant factor in denied claims, with prior reporting noting MFA implementation issues in the majority of denials (Coalition, 2025 Cyber Claims Report). The Travelers v. International Control Services dispute crystallized the pattern: MFA was deployed on the firewall but not on the remote access path the attackers used (BreachCraft, 2026 Cyber Insurance Requirements).

The 2025 Verizon DBIR underscores the leverage of credential attacks: 22% of breaches involved compromised credentials, and 88% of attacks against basic web applications used stolen credentials (Verizon, 2025 DBIR Executive Summary). MFA is the single highest-leverage control against that pattern, but only when enforced everywhere it claims to be.

How do you prove MFA enforcement to your underwriter?

Three artifacts cover most of what underwriters and forensics teams ask for:

1. Conditional Access policy export. A current export from Microsoft Entra (or equivalent identity platform) showing every policy, every assignment, every exclusion. Reviewed quarterly with documented exclusion rationale.
2. Sign-in logs. 12 months of sign-in telemetry showing every privileged login flowed through MFA. Forensics teams query these directly when reconstructing a breach.
3. SIEM correlation reports. If you have Security Information and Event Management (SIEM) coverage, a periodic report that correlates identity events with endpoint and network activity. This is the cleanest evidence trail across systems.

The defensibility test for MFA is straightforward: can your Conditional Access export, sign-in logs, and SIEM data show that every privileged login during the policy period was MFA-enforced, with documented and approved exclusions for the small number of break-glass or service accounts that legitimately needed bypass? If yes, MFA is defensible. If the export and the application disagree, you have a renewability problem and a claim-defensibility problem. For the deeper definition of defensibility, read What does "cyber-insurance defensible" actually mean? For the related detection-and-response stack, read What is the difference between MDR, SOC, EDR, and SIEM?

Frequently asked questions

Does cyber insurance accept SMS-based MFA?

Most carriers still accept SMS-based MFA as the floor for general user accounts but increasingly reject it for privileged and admin accounts. SMS is interceptable, vulnerable to SIM swap, and explicitly listed as inadequate by CISA for high-value targets. Higher-tier policies in 2026 require phishing-resistant MFA (FIDO2 hardware keys or WebAuthn) on privileged accounts.

Where does cyber insurance require MFA to be enforced?

On every privileged or administrative account, every remote access path (VPN, RDP, SSH), every email account, every cloud admin console (Microsoft 365, Azure, AWS, Google Workspace), every backup admin interface, every RMM tool, and every financial system. The Travelers v. International Control Services case turned on MFA being deployed on the firewall but not on the remote access path the attackers used.

How do you prove MFA enforcement to your underwriter?

Through Microsoft Entra Conditional Access policy exports, sign-in logs that show every privileged login flowed through MFA, SIEM correlation reports, and named exclusion documentation for any service or break-glass account. The defensibility test is whether the controls export matches the controls attested to on the application across the full policy period.