Multi-Factor Authentication (MFA): Don’t Let Your CyberSecurity Insurance Claim Get Denied On…

Multi-Factor Authentication (MFA) is the security control that can make, or break, your business. If there’s one cybersecurity control that consistently separates organizations that get breached from those that don’t, it’s Multi-Factor Authentication (or, to be precise, MFA, done correctly).

And increasingly, it’s not just about security, but about financial survival.

Companies are now discovering the hard way that failing to implement MFA can lead to denied cybersecurity insurance claims, turning a bad breach into a catastrophic one. Every organization seems to have somebody leading the cheer leading squad for “can’t do MFA”, “won’t do MFA”, “it’s not that important”, etc. These are exactly the people that should stop being invited to the adult table during decision making.

A while ago, I witnessed an organization that had dozens of internet-facing web applications get to a point where their cybersecurity insurance provider told them that they had twelve months to rollout MFA to everything that was publicly accessible. In that time, they barely made any headway in deploying MFA. For the few applications that did get it deployed, each one was done as a one-off solution rather than an enterprise approach built at the Identity Provider layer. The organization switched insurance providers and reset the clock. The internal politics of their IT department just wouldn’t let them get out of their own way. Some actors didn’t want to be dependent upon the enterprise identity stack. Some wanted to roll their own MFA solution. Some didn’t think it was really that important. Meanwhile, there was insufficient, top-down command-and-control to set a direction and see it through, organization wide. There are many issues demonstrated in that story, but the end result was MFA was rolled out to maybe ten percent of the needed applications.

The advice in this post isn’t just for the corporate / enterprise space. This applies to individuals as well.

• Every website, every app you use should have MFA enabled if offered as a feature.
• Any apps you currently use that do not offer MFA, should be replaced or start a grassroots campaign to get the company (OpenSource Software project) to add it as a feature.

What Is Multi-Factor Authentication?

Multi-factor authentication is exactly what it sounds like: Requiring more than one form of verification to prove identity.

Instead of just a password, MFA combines two or more of:

• Something you know (password, PIN)
• Something you have (phone, hardware token)
• Something you are (fingerprint, facial recognition)

Even if an attacker steals your password, they still can’t get in without the second factor.

Sometimes, there is a distinction made between Multi-Factor Authentication and Two Factor Authentication (2FA). I typically see the terms used interchangeably in that it usually refers to username + password and a secondary form of authentication based on something you have such as an authenticator app, security key, some other form of One Time Passcode (OTP). Sometimes, a distinction is made between the two (only two-forms of authentication, versus two or more forms of authentication, plus, maybe the family available / allowed solutions). I usually use the terms interchangeably for the basic use case being described in this post.

Why Passwords Alone Are Useless

To be blunt, passwords are a broken security model, but aren’t going anywhere, anytime soon.

Passwords are:

• Reused across sites.
• Phished constantly.
• Leaked in breaches.
• Easy to brute-force.

To even come close to using passwords securely, you need to:

• Use a unique username for each site, app, use case.
• Use a unique password for each site, app, use case.
• Use a unique email address for each site, app, use case.
• Use a random password generator to create each of those unique passwords.
• Every password must be a minimum of 22 or more characters (that minimum is always increasing).
• Use a password manager to track all of this.

I do this, mostly. I can count on one hand the number of people I know who are also doing this. Most people are reusing the same username / email / password to log into most of their websites / apps. Which brings us back to the need for something more.

Most real-world attacks don’t involve sophisticated hacking — they involve logging in with stolen credentials.

MFA is what stops that.

How MFA Actually Stops Attacks

MFA is particularly effective against:

• Phishing attacks
• Credential stuffing
• Password spraying
• Remote access compromise

Even if an attacker has:

• Username
• Password

They still fail at the final step (when prompted for the MFA passcode).

The Insurance Angle: Where This Gets Serious

Here’s where things get interesting — and expensive.

Cybersecurity insurance providers have tightened requirements dramatically. Many now require MFA as a baseline control for:

• Remote access (VPN, RDP)
• Email systems
• Administrative accounts
• Cloud platforms

If you say you have MFA, but don’t, you’re in dangerous territory.

When Insurance Claims Get Denied

There have been multiple cases where organizations suffered breaches and then:

• Filed a cyber insurance claim.
• Expected coverage for damages.
• Got denied.

Why?

Because they failed to meet the MFA requirements stated in their policy.

In some cases:

• MFA was only partially implemented.
• It was enabled but not enforced everywhere.
• It was bypassed for certain accounts.

From the insurer’s perspective: You didn’t meet minimum security standards, ergo, claim denied.

Some examples of this scenario:

• Travlers Insurance and ICS
• Hamilton, Ontario
• UK SMB (exact name withheld)

This became a big deal a few years ago. I suppose insurance companies got tired of paying out huge cybersecurity claims in face of monumental incompetence on the part of the claimant’s IT department.

The Fine Print Problem

Many organizations treat insurance applications like a checkbox exercise:

• “Do you use MFA?” Yes! Moving on with our day!
• Reality: only on some systems.

That mismatch becomes a legal and financial issue after a breach.

Insurers are now:

• Auditing claims more aggressively.
• Investigating control effectiveness.
• Denying payouts for misrepresentation.

So, let’s get started on rolling out MFA across all applications in your organization.

Not All MFA Is Equal

Here’s another uncomfortable truth: Some MFA implementations are weak enough to bypass.

Strong MFA

• Authenticator apps
• Hardware tokens (e.g., security keys, U2F / WebAuthn)

Weaker MFA

• SMS codes (vulnerable to SIM swapping)
• Email-based codes

For high-risk systems, organizations are moving toward:

• Phishing-resistant MFA
• FIDO2 / hardware-backed authentication (think YubiKeys)

Where MFA Must Be Implemented

If you’re serious about security (and insurance compliance), MFA should be enforced on:

• Email systems (this is the #1 attack vector)
• VPN and remote access
• Cloud platforms and admin consoles
• Privileged/administrator accounts
• Critical business applications
• Any business application that provides access to PII, financial, HR data.

Missing MFA in any of these areas creates a major gap.

MFA and Modern Security Models

MFA is a cornerstone of Zero Trust Architecture:

• Trust is never assumed
• Identity must be continuously verified at every layer of the architecture / application.
• Access is granted based on multiple factors

Without MFA, Zero Trust isn’t really Zero Trust — it’s just branding.

Common Mistakes Organizations Make

Don’t make these mistakes:

• Rolling out MFA but allowing “temporary” exceptions (that never go away)
• Not enforcing MFA for service accounts
• Failing to monitor MFA bypass attempts
• Assuming SMS-based MFA is sufficient everywhere
• Not testing MFA coverage across all systems

The Real Cost of Skipping MFA

Without MFA:

• Breach likelihood increases dramatically
• Insurance coverage may be void
• Financial losses multiply
• Reputation damage becomes long-term

With MFA:

• Most automated attacks fail immediately
• Risk drops significantly
• Compliance posture improves

Summary

MFA is no longer optional. It’s not a “nice-to-have” or a future project. It’s a baseline requirement for operating a business in a connected world.

And, now, it’s also a contractual obligation in many cybersecurity insurance policies.

Failing to implement it doesn’t just increase your risk of getting breached; it increases your risk of having to pay for that breach entirely on your own.

MFA is one of the simplest and most effective security controls and failing to implement it can cost you both your data and your insurance coverage.

I recommend:

• All applications should depend on a centralized Identity Provider maintained by your organization’s IAM team.
• That central IdP should manage MFA for all applications, all authenticated user sessions.
• Use one of the major Authenticator Apps (Google, Proton, Microsoft, etc) to store TOTP seeds. There are also some perfectly usable Opensource authenticator apps that have been audited by third parties and are perfectly usable. Personally, I use KeepassXC & OTPClient for Linux on my laptop and the Aegis and Keepass2Android on my phone. I keep passwords and the TOTP seeds separate; that’s why there’s two apps for each platform even though all apps listed can store RFC6238-compliant TOTP seeds.

Notes

• I’m just trying to get everybody to deploy Multi-Factor Authentication across all applications that currently require authentication. Whether your organization needs a cybersecurity insurance policy is between you and your legal department.
• AI / GenAI / ChatGPT / etc were not used to generate the text of this article.
• I used em dashes in my writing before the current GenAI wave was a thing. Not planning on changing now.
• Names have been changed to protect the guilty.
• None of the hostnames or users used in examples actually exist.
• Feel free to post any comments or suggestions below.