Your Cyber Insurance Won't Pay — And Your Microsoft 365 Settings Are Why
You get hit by ransomware. You call your insurer. They investigate. Then comes the letter.
"We have determined that your claim does not meet the conditions of coverage..."
This is not a hypothetical. It is happening — to real organisations, with real policies, who paid real premiums for years. And the reason, in case after case, traces back to a handful of Microsoft 365 settings that were either never turned on, quietly drifted off, or — most devastatingly — ticked "yes" on an insurance application when the honest answer was "sort of."
Across 2024 and 2025, between 25% and more than 40% of cyber insurance claims have been rejected due to gaps in security controls, misalignment with policy language, or late reporting. Failure to maintain MFA alone is responsible for 37% of denied claims. Let that sink in. More than one in three claim denials comes down to a control that Microsoft 365 can implement in an afternoon.
Here's how it plays out in the real world.
Case #1: The City That Thought It Was Covered
In February 2024, the Canadian city of Hamilton, Ontario was hit by a ransomware attack. The attackers demanded $18.5 million. The city declined to pay, used backups to restore essential services within 48 hours, and officials reassured rattled citizens that the multi-million dollar recovery bill would be covered by cyber insurance. Taxpayers would not be on the hook.
Except they were. In July 2025, Hamilton's insurer denied the $5M claim. The reason: MFA had not been fully implemented across all required systems, as stipulated by the policy. Total recovery cost to date: $18.3 million. Paid by taxpayers.
Think about that sequence. Backups worked. The city did the right thing by not paying the ransom. They recovered. And they still lost $18.3 million because some departments hadn't turned on multi-factor authentication.
Partial implementation is the same as no implementation, in the insurer's eyes.
Case #2: The Company That Said "Yes" When the Answer Was "Sort Of"
Travelers Property Casualty Company of America issued a $1 million cyber policy to International Control Services (ICS), an Illinois-based electronics manufacturer. ICS's application — signed by the CEO and the person responsible for network security — stated that MFA was in place for email, remote access, servers, network infrastructure, and directory services. The full suite. Travelers underwrote the risk on that basis.
Then ICS got hit by ransomware. The forensic investigation told a different story. MFA was only deployed on the firewall. Everything else — the servers that were actually attacked — had no MFA protection.
Travelers filed for rescission. ICS's president signed the agreement. The court declared the policy null and void from inception — meaning ICS never had insurance at all, for any claim, past or future.
Not just denied. Retroactively erased.
This is the outcome that keeps security lawyers awake at night, and it is exactly what happens when a CEO ticks a checkbox on a 40-page insurance application without genuinely understanding what they're attesting to.
The Settings That Are Quietly Voiding Your Clients' Policies
Here is the uncomfortable truth for any MSP or CISO reading this: the controls insurers check first are almost all configurable in Microsoft Entra ID and Microsoft 365. They are not expensive. They are not technically complex. But left unmonitored, they drift — and when they drift, the policy becomes conditional fiction.
The most common M365 misconfigurations that trigger denials or rescissions:
MFA gaps that aren't obvious. It's rarely "nobody has MFA." It's more often: three admin accounts were excluded during a migration and never re-enrolled; a contractor account was created without enforcing conditional access; SMS-based MFA is in place but the policy requires phishing-resistant authentication. MITRE now formally lists "Modify Authentication Process: Conditional Access Policies" as an attacker technique (T1556.009), because attackers regularly tamper with conditional access exclusions after gaining initial access — so even correctly configured MFA can drift maliciously without anyone noticing.
Legacy authentication protocols still enabled. POP, IMAP, and SMTP Auth bypass modern authentication entirely, rendering MFA irrelevant for those connections. Insurers know this. Your insurer's questionnaire likely asks about it. Your clients' tenants almost certainly still have at least one legacy protocol active.
Too many Global Admins. An insurer asking whether privileged access is appropriately restricted will not be satisfied by "our IT manager and the four people who've been here since 2017 all have Global Admin because it was easier." A compromised admin account in M365 is not a data breach — it is a total loss event.
"Anyone with the link" SharePoint sharing. Data exfiltration without malware. No antivirus catches it. No EDR flags it. And if files left the building through an overly permissive SharePoint link, the insurer may argue that the loss was a direct consequence of a misconfiguration that violated the policy's minimum security standards.
The Fine Print That Makes This Worse
The insurance application is not a survey. It is a legally binding attestation. Under U.S. and Australian law, an insurer can seek to rescind a policy if it discovers the insured misrepresented or concealed material facts in the application — and a rescinded policy ceases to exist for all purposes, retroactively. The insurer does not need to prove you lied deliberately. Unintentional misrepresentation is enough.
Most application questionnaires ask something like: "Is MFA enforced for all users accessing cloud services including email?" Your CEO ticks yes because your IT provider told them last year that MFA was set up. They don't know about the three excluded accounts. They don't know legacy auth is still enabled. They're answering in good faith — and so are you, because nobody has run a posture check since the rollout.
Some insurers now scan your public-facing assets and compare what they see to what you claimed on your application. If you said "MFA everywhere" but an external service doesn't enforce MFA, that is grounds to deny.
The insurer is checking. The question is whether you checked first.
What This Means if you’re an MSP
Every client whose Microsoft 365 environment you manage is carrying this risk — whether they know it or not. And when the claim gets denied, they will want to know why their MSP didn't tell them.
The controls that matter most to insurers are exactly the controls that Sabiki's Entra ID scanning surfaces automatically: MFA gaps across every account, legacy authentication protocols still active, admin privilege misconfigurations, stale accounts, and conditional access policy drift — all mapped to the specific requirements that appear in insurance questionnaires and ASD Essential Eight maturity assessments.
Run a scan on your clients before their next renewal. Give them a report they can take to their broker. That is not a security sales conversation. That is risk management — and it is exactly the conversation their insurer wishes someone had with them before the attack.
Sabiki provides AI email security and Entra ID posture management for Microsoft 365, built for MSPs managing multiple tenants. Visit sabiki.ai for more.
A note on the cases cited: Travelers v. ICS (2022) is a matter of public court record. The Hamilton, Ontario insurance denial was reported publicly by Hamilton City Council in July 2025. Both cases are cited as illustrative examples — organisations should seek independent legal advice regarding their own insurance obligations.