Managed IT
Nobody argues against MFA any more. The argument now is about the rollout, which is where it usually goes wrong: enrollment stalls at sixty percent, three critical applications turn out not to support it, an executive gets a permanent exception, and eighteen months later the control exists on paper while the gap an attacker would use is still open. This is about getting to the end of the deployment rather than the middle of it.
A password is a secret that has to be shared with a system to be useful, typed on machines you do not control, and remembered by people who have roughly forty other passwords. Treating that as a single line of defense was always optimistic. The second factor is not really about strengthening authentication so much as accepting that the first factor was probably compromised at some point and nobody noticed.
What the second factor actually stops
Microsoft's security research puts the figure at 99.9% of automated credential attacks blocked where MFA is in place, covering brute force, credential stuffing and much of what phishing produces. Verizon's 2024 Data Breach Investigations Report finds 86% of breaches involve stolen or weak credentials, which makes this the most common way in and the most preventable. IBM's Cost of a Data Breach research puts the average cost of a credential-related breach at $4.5 million.
Those numbers explain why underwriters started asking about MFA and then started declining or repricing policies when the answer was no. It is one of the few controls where the evidence is strong enough that insurers treat its absence as a pricing question rather than a preference.
The caveat worth stating plainly
That 99.9% figure is about automated attacks. A determined attacker running a targeted phishing campaign can still defeat weaker second factors, either by relaying a code the user types into a fake login page or by bombarding someone with push notifications until they approve one to make it stop. This does not make MFA less worth deploying. It means the factor you choose matters, and it is the reason phishing-resistant methods keep appearing in newer insurance questionnaires.
Enrollment strategy: which factors, in what order
The Factors
Most rollouts pick one method and apply it to everyone. A better approach is to match the factor to the risk of the account, which costs nothing extra and puts the strongest protection where a compromise would hurt most.
Best for
Authenticator apps
Most staff · Push approval · Rotating codes · Number matching
The right default for the majority of a workforce. It works offline, costs nothing per user, and the friction is low enough that people stop noticing it within a fortnight. The one configuration worth insisting on is number matching, where the user types a digit shown on screen rather than simply tapping approve. Without it, push notifications are vulnerable to fatigue attacks, where someone is prompted repeatedly at two in the morning until they approve one to end it. That single setting removes most of the risk in this method.
Best for
Phishing-resistant factors
Admins · Finance · Executives · Anyone who can move money or change access
Security keys and passkeys are bound to the real domain, so a user cannot be tricked into handing the second factor to a lookalike site. That closes the gap the other methods leave open. The cost is hardware for keys and a slightly heavier enrollment, which is why most organizations deploy them to a subset rather than everyone: domain admins, finance staff who can move money, and executives who are the ones actually targeted. Newer insurance questionnaires increasingly ask specifically whether privileged accounts use phishing-resistant methods, so this is worth checking against your own application.
Use when
SMS and voice
Shared devices · No smartphone · Field staff · Temporary fallback
Codes sent by text can be intercepted through SIM swapping or relayed through a phishing proxy, which is why guidance has moved away from them for anything sensitive. That said, the comparison that matters for most accounts is not SMS against a security key, it is SMS against nothing at all, and it wins that comparison decisively. Use it where an app genuinely is not viable, keep it away from privileged accounts, and treat it as a stage in the rollout rather than a destination.
Phase it, and set the enforcement date at the start
Announce, enroll voluntarily, then enforce. The critical decision is that the enforcement date exists from day one and is communicated with the announcement. Rollouts that open enrollment without a deadline reliably stall somewhere around sixty to seventy percent, because the people who have not enrolled are precisely the people who will not enroll until something makes them.
Start with IT, then a pilot department that will tell you honestly what broke, then the rest in waves. Enroll privileged accounts first rather than last, which is the instinct people usually get backwards on the grounds that senior staff are busy.
App coverage, and the ones that get missed
Enrollment gets the attention because it involves people. Coverage is where deployments actually fail, because an attacker only needs the one door you did not get to.
The obvious ones
Email, the identity provider itself, VPN and remote access, and anything reachable from the internet. If your identity provider covers most of your applications through single sign-on, protecting that one login covers a great deal at once, which is the strongest argument for consolidating onto SSO before rolling out MFA rather than after.
The ones that get missed
Legacy line-of-business applications that authenticate against their own database and know nothing about your identity provider. Service accounts and shared logins, which nobody wants to touch because something automated depends on them. Local administrator accounts on servers. Remote desktop and management interfaces exposed for a vendor. Legacy authentication protocols that bypass modern policy entirely, which is a particularly common gap because everything appears protected in the console while a older protocol quietly accepts a password on its own.
Anything genuinely incapable of supporting MFA needs a compensating control instead: network restriction, jump host, IP allow-listing. What it must not get is an indefinite exemption that nobody revisits, because that list is exactly what an attacker enumerates.
The mistakes that cause rollbacks
Five, and they account for most abandoned deployments.
No enforcement date
Covered above, and it remains the single most common reason a rollout stalls in the middle. Voluntary enrollment reaches the people who were going to comply anyway.
Permanent exceptions
An executive finds it inconvenient and gets an exemption. That exemption never expires, and it belongs to one of the most targeted accounts in the business. If exceptions exist, they need an owner, a documented compensating control and a review date, or they are simply a gap with paperwork.
No recovery path
Someone loses their phone on a Saturday. If the only route back is an administrator who is unreachable, people work around MFA rather than through it. Plan the recovery process, including identity verification for the reset, before enforcement rather than during the first weekend.
Treating it as an IT project
MFA changes how every employee signs in, which makes it a change-management exercise wearing a technical costume. Rollouts announced with a week's notice and no explanation generate resistance disproportionate to the actual inconvenience. Explaining that this exists because credentials get stolen, rather than because IT enjoys friction, does more for adoption than any tooling decision.
Nobody watching afterwards
Deployment is not the finish line. Denied sign-ins, repeated push prompts on one account, and new applications appearing without coverage all need someone looking at them. A rollout that completes and is then never reviewed slowly develops the same gaps it was deployed to close.
Cyber Insurance & Compliance Readiness Checklist
The Checklist
Fifteen questions covering the MFA topics that come up most often on cyber insurance applications and in audits. Requirements vary by carrier, policy and framework, so treat this as preparation for the conversation rather than a substitute for your actual application or your auditor. Tick what you can answer without going and asking someone.
Tick what you can answer without checking. The blanks are the gaps.
Coverage
Is MFA enforced on email for every user?
Usually the first question on the form, because business email compromise is what carriers pay out on most.
Is it enforced on all remote access, including VPN?
Remote access without a second factor is a password away from the inside of your network.
Do privileged and administrator accounts require MFA?
Frequently asked separately from general staff, and increasingly with a follow-up about phishing-resistant methods.
Can you name every application that does not support MFA?
If that list does not exist, the honest answer to the coverage question is that you do not know.
Enforcement & Exceptions
Is MFA enforced by policy, or merely available?
Available and adopted are different numbers, and applications ask about the second one.
What percentage of accounts are actually enrolled today?
A specific figure. Most rollouts stall somewhere in the sixties and nobody re-checks.
Does every exception have an owner and a review date?
An indefinite exemption on an executive account is a gap with paperwork attached.
Are legacy authentication protocols blocked?
A common blind spot. Everything looks protected in the console while an older protocol still accepts a password on its own.
Evidence & Logging
Could you produce enrollment evidence this week?
Not a claim that it is deployed. A report showing who is covered, generated on request.
Are sign-in logs retained, and for how long?
Auditors ask for the retention period specifically, and it is usually shorter than people assume.
Are your MFA policies written down anywhere?
A configured policy is not a documented one, and audits ask for the document.
Would failed or unusual sign-in attempts be noticed?
Repeated push prompts against one account is what an attack looks like before it succeeds.
Framework Alignment
Do you know which frameworks actually apply to you?
HIPAA, PCI DSS, SOC 2 and CMMC all address identity verification, and each words it differently.
Have you read the MFA questions on your own renewal application?
Carriers differ and the wording changes year to year. The form in front of you is the only authority.
Is anyone accountable for keeping this current at renewal?
Coverage drifts as applications are added. Answers accurate last year may not be accurate now.
Frequently asked questions
Multi-factor authentication requires a second proof of identity in addition to a password, so a stolen credential on its own is not enough to sign in. The second factor is typically something you have, such as an authenticator app or a security key, rather than something you know. Microsoft's security research reports that MFA blocks around 99.9 percent of automated credential attacks, including brute force and credential stuffing, which is why it is treated as a baseline control rather than an enhancement.
Phishing-resistant factors such as security keys and passkeys are the strongest, because they are bound to the real domain and cannot be relayed to a lookalike login page. Authenticator apps are a sensible default for most staff, particularly with number matching enabled to prevent push fatigue attacks. SMS and voice codes are the weakest of the three and can be intercepted through SIM swapping, though they remain far better than a password alone where no other method is workable.
MFA appears on most cyber insurance applications, and underwriters have declined or repriced policies where it is absent, but the specific requirements vary by carrier, policy and year. Applications commonly ask about email, remote access and privileged accounts separately, and newer questionnaires increasingly ask whether administrator accounts use phishing-resistant methods. Read the questions on your own renewal application rather than relying on a general answer, because the wording changes and the form in front of you is the only authority.
HIPAA, PCI DSS, SOC 2 and CMMC all address identity verification, though each words its expectations differently and applies to different scopes. Rather than assuming a general requirement covers you, identify which frameworks apply to your organization and check how each phrases its identity controls with your auditor. What auditors consistently ask for beyond the control itself is evidence: enrollment reports, written policies and sign-in log retention.
The technical configuration is usually the shortest part. What determines the timeline is enrollment across the workforce and coverage of applications that do not support MFA natively. A phased approach works best: announce with the enforcement date already set, enroll IT and a pilot department, then move through the organization in waves. Rollouts that open enrollment without a deadline reliably stall around sixty to seventy percent, because the remaining users are the ones who will not act until something requires it.
Legacy line-of-business applications that authenticate against their own database, service accounts and shared logins, local administrator accounts on servers, remote desktop or management interfaces exposed for a vendor, and legacy authentication protocols that bypass modern policy entirely. That last one is a particularly common blind spot, because the console shows everything as protected while an older protocol still accepts a password on its own. Anything genuinely incapable of MFA needs a compensating control rather than an open-ended exemption.
You need a recovery process defined before enforcement, not during the first weekend someone is locked out. That means a documented route back, identity verification appropriate to the account before a reset is granted, and someone reachable outside business hours for accounts that cannot wait. When recovery is unclear, people work around MFA instead of through it, which undermines the control more than the original inconvenience ever did.
Weaker factors can be defeated by a determined targeted attacker. Codes can be relayed through a phishing proxy that sits between the user and the real login page, push prompts can be approved under fatigue if someone is bombarded at night, and SMS is vulnerable to SIM swapping. None of this argues against deploying MFA, since it stops the automated attacks that make up the bulk of credential abuse. It argues for number matching on push approvals and phishing-resistant factors on privileged accounts.
Not sure where the gaps are?
Get a free MFA assessment. We'll map coverage, find the apps that slipped through, and get your evidence ready for renewal.
