Cyber insurance forms still ask a very 2019 question.
Do you enforce MFA for email? For remote access? For privileged accounts?
That question still matters. But in 2026 it no longer tells the whole truth.
A user who signs in with a phishing-resistant passkey is in a different risk position than a user who types a password and then approves a push prompt. Both may satisfy a generic “MFA” checkbox. They are not equally defensible.
That gap is getting more important for two reasons.
First, Microsoft’s current identity guidance is explicit that remote phishing attacks are on the rise and that passkeys help prevent those attacks by replacing phishable methods like passwords, SMS codes, and email one-time codes.[1]
Second, cyber insurance language has not yet fully caught up. Public SMB and lower mid-market forms still largely ask whether MFA is enforced, not whether the MFA method is phishing-resistant. Coalition’s current application asks whether MFA is enforced for email, VPN, RDP/remote access, and privileged accounts.[2] Travelers’ short form asks whether MFA exists for remote access to email and other systems containing sensitive data.[3] The Hartford asks whether MFA is required for all remote access and for access to email.[4]
Those are good questions. They are just no longer enough.
If you have not already worked through the evidence-reconciliation problem inside Microsoft 365, The M365 MFA Reporting Gap is the foundation for this conversation.
This article is about the 2026 gap between what the renewal form asks, what attackers are doing, and what a defensible answer should start looking like now.
The real change in 2026 is not “more MFA” — it is better MFA
Microsoft’s current passkey documentation says remote phishing attacks aim to steal or relay identity proofs such as passwords, SMS codes, or email one-time passcodes, and says passkeys help prevent remote phishing by replacing those phishable methods with origin-bound cryptographic credentials.[1]
That is the core shift.
The old question was:
- Is a second factor present?
The new question is:
- Can the sign-in method itself be phished, proxied, replayed, or downgraded?
Microsoft now exposes that distinction directly through authentication strengths in Entra. Its built-in phishing-resistant MFA strength includes:
- FIDO2 security keys,
- Windows Hello for Business or a platform credential,
- and certificate-based authentication configured for multifactor use.[5]
Methods like passwords plus text message, push approval, or a software token can still count as MFA, but they are not part of the phishing-resistant strength.[5]
That means the identity platform itself now distinguishes between:
- MFA as a category, and
- phishing-resistant MFA as a stronger subset.
Cyber insurance applications mostly do not.
Why this matters more than it did a year ago
It would be easy to treat this as a standards discussion. It is not.
In March 2026 Microsoft published a deep look at the Tycoon2FA adversary-in-the-middle phishing kit, describing how kits like it are sold to cybercriminals and used to operate at scale.[6] Just weeks later, Microsoft also documented tax-season campaigns in which phishing kits harvested credentials and 2FA, and where attackers combined social engineering with legitimate infrastructure and multi-step interaction to complicate detection.[7]
That is the practical problem with a casual MFA answer.
If your renewal narrative is still “we have MFA,” but the method is easy to proxy through an adversary-in-the-middle flow, your control may satisfy the form while underperforming against the threat.
That does not mean insurers publicly require passkeys today. They generally do not.
It does mean MSPs and brokers should stop treating all MFA as equal in internal evidence, even when the form does.
The public forms still ask a yes/no question
The lag is visible when you read the forms side by side.
Coalition: form CYUSP-00NA-1022-01
Coalition asks, in Question 6, for which of the following services the insured enforces MFA:
- 6a Email
- 6b VPN
- 6c RDP, RDWeb, RD Gateway, or other remote access
- 6d Network/cloud administration or other privileged accounts[2]
That is a better question than a single generic MFA line because it breaks the answer into actual attack paths.
But it still does not ask whether MFA for those services is based on SMS, push, TOTP, FIDO2, Windows Hello, or another method.
Travelers: form CYB-14203 Rev. 03-19
Travelers’ short form asks in Question 3i whether the applicant has MFA for remote access to email and other systems and programs that contain private or sensitive data in bulk.[3]
Again, that is operationally useful. It points the applicant toward email and remote access as the most important paths.
But it does not distinguish ordinary MFA from phishing-resistant MFA.
The Hartford: CB 00 H027 03 0824
The Hartford’s 2025 CyberChoice underwriting application asks whether MFA is required for all remote access to the business network and whether MFA is required for access to email.[4]
That mirrors what most underwriters currently want to know at the public-form level:
- is it there,
- is it enforced,
- and does it cover the riskiest access paths?
That is still the baseline. But it is only the baseline.
The uncomfortable truth: a “Yes” can now hide very different realities
In 2026, four organizations can all answer “Yes” to an MFA question and still have very different exposure.
Tenant A: SMS and voice codes for everyone
This is technically MFA.
It is also phishable, weak under real social engineering, and increasingly hard to describe as mature identity control.
Tenant B: app-based push and TOTP, but lots of exclusions
Better than Tenant A, but still vulnerable to prompt fatigue, relay attacks, exceptions, and “temporary” exclusion groups that never got cleaned up.
Tenant C: Conditional Access with strong enforcement, but no method quality standard
This is a meaningful step up. Email, remote access, and admins are covered. But users may still satisfy MFA with weaker methods depending on policy design.
Tenant D: phishing-resistant MFA for admins and sensitive resources, broader MFA elsewhere
This is a materially better control story. It recognizes that not all accounts need the same access policy at the same time, while protecting the highest-consequence paths with stronger methods.
All four could still compress to a single “Yes” if the form only asks whether MFA exists.
That is why a good MSP evidence packet should now capture both:
- enforcement scope, and
- method quality.
What Microsoft is signaling now
Microsoft’s documentation and product direction are clear enough that MSPs should pay attention even if carriers have not rewritten their forms yet.
Microsoft’s mandatory-MFA planning page says MFA is already required for CRUD operations in Azure portal, Microsoft Entra admin center, and Intune admin center, and that Microsoft 365 admin center enforcement began to roll out in 2025.[8] Microsoft also recommends moving toward phishing-resistant passwordless authentication as part of Zero Trust identity strategy.[9]
At RSAC 2026, Microsoft announced:
- synced passkeys and passkey profiles as generally available,
- and Passkeys on Windows as a preview capability.[10]
Microsoft’s deployment guidance recommends that most users should end up with at least one portable phishing-resistant credential and local phishing-resistant credentials on their devices as appropriate.[11] It specifically recommends FIDO2 security keys for admins and highly regulated users, with other passkey options for broader user populations.[11]
There is an important subtext here:
The identity platform is moving from “turn MFA on” toward “decide which authentication strength different personas should be forced to use.”
That is much closer to how underwriters already think, even if the public form language has not caught up.
CISA is already using stronger language than many insurance forms
Government guidance has moved too.
CISA’s cloud-configuration baseline says that if phishing-resistant MFA has not been enforced yet, an alternative MFA method must at least be enforced for all users.[12] CISA’s StopRansomware guidance also calls for phishing-resistant MFA particularly for email, VPNs, and accounts that access critical systems.[13]
That is notable because those are exactly the access paths public cyber applications keep asking about.
In other words:
- insurers ask whether MFA exists for email, remote access, and admins,
- Microsoft now distinguishes phishing-resistant MFA from ordinary MFA,
- and CISA explicitly names phishing-resistant MFA as the stronger standard for those same paths.
The market has not fully merged these three ideas into one renewal question yet. But the direction is obvious.
The most useful way to talk about this with clients
Do not tell clients “your insurer requires passkeys.”
Public forms generally do not.
The more accurate and more persuasive statement is:
The form asks whether MFA is enforced. The threat environment now forces a second question: how strong is that MFA on the riskiest paths?
That framing helps the client understand why this is not compliance theater.
It also keeps you out of coverage-advice territory. You are not interpreting policy language. You are explaining control quality.
A practical 2026 maturity model for renewal prep
Here is a simple way to structure internal evidence.
Level 1: basic MFA presence
- Password + SMS, voice, or generic app approval
- Inconsistent coverage
- Weak exception control
This is better than no MFA and often still common.
Level 2: enforced MFA on the major paths
- Email covered
- Remote access covered
- Privileged accounts covered
- Conditional Access used instead of a patchwork of legacy settings
This is where most defensible renewal answers should start.
Level 3: method quality differentiated by risk
- Phishing-resistant MFA required for admins and the most sensitive resources
- Standard MFA allowed for lower-risk user journeys as a transition state
- Exception groups tightly controlled
This is the maturity jump most MSPs should be planning now.
Level 4: phishing-resistant-first architecture
- Portable passkeys or security keys for most users
- Local device credentials where appropriate
- Authentication strengths enforced by persona and resource
- Token protection and strong audit retention layered on top
This is where the platform is moving, whether the public forms ask about it yet or not.
How to answer the renewal honestly today
The short answer on the application should still be based on what the form actually asks.
If the question is “Do you enforce MFA for email?” the answer must be based on actual enforcement for email.
But internally, your evidence packet should now record more than that:
- what method families are allowed,
- whether phishing-resistant strength is required anywhere,
- whether admins are on stronger methods than ordinary users,
- whether exceptions exist,
- and whether the tenant still relies on legacy per-user MFA in ways that obscure the real state.
This lets the MSP do two things at once:
- answer the actual form honestly, and
- show the client where their MFA story is strong, weak, or transitional.
That is more useful than a simple export of registered methods.
The BindLedger angle: enforcement first, method quality next
BindLedger’s first job is to answer the question the form actually asks:
- Is MFA enforced on email?
- On remote access?
- On privileged accounts?
- Are there exclusions or uncovered users?
That is the urgent attestation problem.
The next layer — and the one that becomes more important from 2026 onward — is method quality.
A serious M365 attestation engine should evolve toward showing not just whether MFA exists, but whether:
- authentication strengths are in use,
- phishing-resistant methods are required for admins,
- passkey deployment is real or still partial,
- and fallback methods quietly weaken the story.
That is where the market is headed.
For the broader Microsoft 365 control map that sits around this identity story, see Cyber Insurance for Microsoft 365 Tenants: The 2026 Attestation Checklist.
The mistake to avoid
Do not oversell passkeys as if they instantly solve the whole identity problem.
Microsoft’s own deployment guidance makes clear that once phishing-resistant credentials are deployed, defenders still need to care about onboarding, device readiness, risk detections, suspicious browsers, anomalous tokens, and potential token theft.[11]
So the message is not:
- “passkeys mean you’re done.”
The message is:
- “passkeys and phishing-resistant MFA materially improve the quality of your renewal answer on the most important access paths.”
That is precise. It is also true.
The 2026 takeaway
Public cyber forms still mostly ask a yes/no MFA question. Attackers no longer behave as if all MFA is equal. Identity platforms no longer treat all MFA as equal either.
That mismatch is where good MSPs can create real value.
If you can show:
- enforcement scope,
- exception hygiene,
- privileged-account protection,
- and where phishing-resistant methods are or are not required,
you have a much more credible renewal story than “we have MFA.”
That is the difference between a checkbox and a defensible answer.