MFA, plainly: what it is, why your insurance asks, and the three ways small businesses get it wrong.

If you've gotten a cyber insurance quote in the last two years, the first question on the application was almost certainly about multi-factor authentication. If you've gotten a renewal letter and the premium jumped, MFA is probably why.

This is the most basic, highest-leverage security control you can deploy. It blocks roughly 99% of automated account takeover attacks, according to Microsoft's identity team. And yet it's still the control most small businesses get wrong — not by failing to deploy it, but by deploying it halfway.

Here's the plain-language version: what it is, why insurers care, and the three mistakes we see at almost every SMB we audit.

What MFA actually is

Multi-factor authentication means you log in with two different kinds of proof:

• Something you know — your password
• Something you have — your phone, a hardware key, an authenticator app
• Something you are — your fingerprint or face

A normal login (password only) is one factor. MFA requires two. The whole point is that even if an attacker steals your password — through phishing, a reused password from a breached site, or malware — they still can't log in without your phone.

Why insurers turned this into a hard requirement

Around 2021, cyber insurance carriers paid out so many claims that the entire market nearly collapsed. The vast majority of those claims traced back to one cause: an attacker logged in with a stolen password, then moved laterally and deployed ransomware.

The carriers' actuaries did the math. Accounts with MFA had ransomware claims at a tiny fraction of the rate of accounts without it. Within 18 months, MFA went from "best practice" to "we won't renew you without it."

That's where we are now. No MFA on email = no policy, or a policy with a ransomware sub-limit so low it's effectively useless.

The three mistakes we see

Mistake 1: MFA on email but not on remote access

Most businesses set up MFA on Microsoft 365 or Google Workspace and stop there. But the VPN, the remote desktop server, the IT vendor's RMM tool, the QuickBooks Online login, the bank — none of those have MFA, or they have it set to "optional."

Attackers know this. They phish the M365 password, log in to email, dig through messages to find the VPN address, and then walk in the front door of the network where there's no second factor at all.

What to do: Every system that touches business data needs MFA. Make a list. Every line item gets a yes or no.

Mistake 2: SMS as the only factor

Text-message codes are better than nothing, but they're the weakest form of MFA. SIM-swap attacks — where an attacker convinces your cell carrier to move your phone number to their device — are common enough that the carrier might not even flag it. NIST has been recommending against SMS as a primary factor since 2017.

What to use instead:

• Authenticator app — Microsoft Authenticator, Google Authenticator, Duo, Authy. Free. Takes 60 seconds to set up. Works without cell service.
• Hardware key — YubiKey or similar. About $50. Best protection against phishing because the key won't authenticate to a fake login page. Worth it for executives, admins, and anyone with access to bank or payroll.

Mistake 3: "Enabled" but not "enforced"

This is the one that bites businesses on the insurance questionnaire. Enabling MFA means users can turn it on. Enforcing it means they must. Big difference.

In Microsoft 365, the right answer is a Conditional Access policy that requires MFA for all users, all apps, all locations. In Google Workspace, it's enforcing 2-Step Verification org-wide with a grace period. In smaller SaaS apps, it's an org-level setting (sometimes hidden — check the admin docs).

If your admin console says "MFA is available" or "MFA is enabled" without telling you the enrollment percentage, you have work to do.

What about the service accounts?

Every business has a handful of accounts that can't easily have a phone attached — the printer's email-to-scan account, the line-of-business app's API user, the legacy timeclock integration. These get skipped, and then they get phished, and then they're the foothold.

The right answer is a mix of:

• Convert to certificate-based auth or app passwords where the platform supports it
• Lock the account to specific IP addresses (a Conditional Access location policy)
• Use a strong unique password rotated quarterly, stored in a password manager
• Disable the account entirely if it's no longer needed (we find at least one every audit)

What good looks like

A defensible MFA posture for a typical SMB:

• All staff use an authenticator app on a managed phone
• Conditional Access (or equivalent) enforces MFA on every login, with no exclusions
• Admins use a YubiKey, not just an app
• Service accounts are inventoried, locked down, and audited quarterly
• You have a documented break-glass account with a hardware key in a safe

That's it. No magic, no expensive products, no SOC 2 required. Just discipline applied consistently.

The honest takeaway

MFA isn't enough on its own — attackers have learned to bypass weak implementations with token-stealing malware and MFA-fatigue prompts. But it's the floor, and it's the one control where the gap between "we have it" and "we have it correctly" is enormous.

If you do nothing else this quarter, audit your MFA. Spend an afternoon. Pull the reports. Find the exceptions. Close them. It's the cheapest 99% improvement in your security posture you'll ever buy.