How to choose strong authentication: the MFA buyer's guide

where buyers go wrong

The most common mistake is treating MFA as a thing you turn on rather than a thing you cover. Switching it on for the people who log into the main app is easy. Covering every account, every app, every admin, every service identity, and every legacy protocol is the actual work, and it is where the exposure hides. An attacker does not care how many of your logins are protected. They care about the few that are not.

The second mistake is choosing weak factors and calling it done. A text-message code and a hardware security key both count as a second factor on a compliance form. One of them stops a real-time phishing attack and one of them does not. If you buy on the form's definition rather than the attacker's, you will feel covered while staying exposed.

The third is buying a standalone product you do not need. Most companies already own capable MFA inside the identity provider they run, whether that is Microsoft Entra, Okta, or Google Workspace. Worth checking that before you sign anything.

The fourth is forgetting the edges. The recovery flow, the help desk reset, the break-glass admin account, the contractor on an unmanaged laptop, the frontline worker with no company phone. These are where well-meaning MFA rollouts spring leaks, and they rarely come up in a sales demo.

The thread through all four: you cannot sensibly choose authentication until you can see your current coverage and its gaps. Knowing who has MFA, on which apps, with which factors, and where the holes are is the input that makes every later decision real.

before you shop: see your current state

Start by mapping what you actually have. Pull a list of your accounts and check which ones have MFA enforced, not merely available. There is a meaningful difference between a policy that offers MFA and a policy that requires it, and attackers live in that difference. Then look at which factors are in use, because an environment that is 100% covered by SMS is in a very different place from one on hardware keys.

Then find the apps outside single sign-on. Anything a team signed up for with an email and a password, outside your identity provider, is almost certainly not protected by your MFA policy at all. Those are separate front doors, and they need their own answer.

Then check for legacy authentication. Old protocols that cannot do modern MFA, like basic auth on some mail and calendar endpoints, are a standing bypass. If they are still enabled, an attacker can often skip your MFA entirely by using the old door. Closing them is frequently the highest-value thing you will do, and it costs nothing but care.

Finally, work out the scale of your problem. A twenty-person company with one SaaS stack and a forty-thousand-person company with mainframes, frontline workers, and a dozen acquired identity systems are not solving the same problem.

the category in plain terms

"MFA" covers a wide range of things that vary enormously in strength and in how they fail. Here is the field, roughly from weakest to strongest.

the factor strength ladder

SMS and email one-time codes. A code sent to your phone or inbox. Better than a password alone, and for a long time it was the default. It is also the weakest common factor. SIM-swapping, SS7 interception, and simple phishing all defeat it, because the code is just another secret the user can be tricked into handing over. Treat SMS as a fallback of last resort, not a primary factor.

Authenticator app codes (TOTP). The rotating six-digit code from an app. Stronger than SMS because there is no phone number to hijack, and it works offline. It still has the core weakness of any code: a convincing fake login page can ask the user to type it in, and a real-time phishing kit will relay it to the real site within the few seconds it is valid. Fine as a broad baseline, not enough for your most sensitive accounts.

Push notifications. The "approve this sign-in" prompt on your phone. Better UX than typing codes, and widely deployed. The weakness that made headlines is MFA fatigue, sometimes called push bombing: an attacker who already has the password spams approval requests until a tired user taps yes. The fix is number matching, where the user has to type a number shown on the login screen into the app. Push with number matching is a reasonable baseline. Plain push that lets a user approve with one tap is not, in 2026.

Phishing-resistant authentication. This is the category that actually changes the game. It binds the login to the real website and to a private key that never leaves the device, so a fake page has nothing to relay and nothing to capture. Two flavors matter:

• FIDO2 security keys and passkeys. A hardware key you tap, or a passkey stored in a phone or laptop secure enclave. The login is cryptographically tied to the legitimate domain, which is why a relayed login to a lookalike domain simply fails. Passkeys have moved into the mainstream and are the direction most mature programs are heading.
• Certificate-based and platform authenticators. Device-bound certificates, smart cards (PIV and CAC in government and regulated settings), and platform authenticators like Windows Hello and Face ID. Same principle, different packaging: the credential is tied to a device and a person, and there is no reusable secret to steal in transit.

The single most useful frame: everything up to and including push is a shared secret that a human can be tricked into surrendering, and everything in the phishing-resistant tier is not.

adaptive and risk-based authentication

Beyond the factor itself, modern authentication decides when to challenge. Adaptive or risk-based MFA looks at signals (a new device, an unusual country, an impossible-travel pattern, a risky network) and steps up the challenge only when something looks off. Done well, this cuts friction for routine logins and concentrates the strong factor where it matters. Done badly, it becomes a black box you cannot tune. If you go this way, you want to understand and control the policy, not just trust the score.

passwordless

The end state a lot of programs are aiming at is removing the password entirely, so the strong factor is the only factor. Passwordless usually means a passkey or a device-bound credential plus a biometric or PIN. It is both more secure and, once enrolled, genuinely nicer to use. The catch is enrollment and recovery, which become the new thing you have to get right. A good buying decision today keeps the road to passwordless open rather than locking you onto codes forever.

why this is moving now

The reason factor strength suddenly matters more is that the attacks got better. Adversary-in-the-middle phishing kits, sold as a service, sit between the user and the real site and relay the whole login, including the code or the push approval, in real time. Phishing is still the dominant way in, accounting for roughly 60% of observed intrusions in ENISA's 2025 threat data, and these kits defeat exactly the MFA most companies deployed. Phishing-resistant authentication exists specifically to break that attack.

what's right for your size and situation

• Lean / small (under ~50, no security hire) · What good looks like: Use the MFA built into your IdP. Require it everywhere, no exceptions. Number matching on push, or passkeys if your stack supports them. A password manager alongside. · What to skip: A standalone MFA product. You almost certainly do not need it yet.
• Growing mid-market (50 to 500) · What good looks like: Phishing-resistant factors for admins and high-value roles. Push-with-number-matching or app codes for everyone else, with a plan to upgrade. Conditional access policies. Legacy auth closed. · What to skip: Heavy adaptive-auth platforms before you have covered the basics and closed the legacy gaps.
• Larger / multi-entity (500 to 2000) · What good looks like: A real passwordless rollout underway. FIDO2 keys issued to privileged users. Risk-based policies you actively tune. Identity threat detection watching for MFA abuse. · What to skip: Tolerating per-business-unit exceptions that fragment the policy.
• Enterprise / regulated (2000+, finance, public sector) · What good looks like: Phishing-resistant authentication as the default. Smart cards or device certificates where mandated. MFA on privileged and remote access enforced and evidenced for regulators. · What to skip: Anything that cannot produce the audit evidence your regulator expects.

A few situations cut across the size bands:

Frontline and deskless workers. People on a factory floor, in a clinic, or behind a till often have no company phone and shared devices. Phone-based MFA falls apart here. The answer is usually hardware keys, badge-based or tap authentication, or shared-device sign-in designed for the context. If a meaningful part of your workforce is deskless, make this a primary evaluation criterion.

Contractors and BYOD. When you do not control the device, device-bound credentials are harder, and you lean more on phishing-resistant factors that do not depend on managing the endpoint.

Acquisitions and multiple identity systems. If you have grown by acquisition, you may be running several identity providers at once. A standalone authentication layer that sits across all of them can be worth it because it gives you one consistent MFA policy over a fragmented estate.

Shared and privileged accounts. The break-glass admin account and the shared ops login are exactly the accounts an attacker wants, and exactly the ones people are tempted to exempt for convenience. They need the strongest factor and the most scrutiny, not the least.

sourcing: four ways to get there

Use the MFA you already own. Your identity provider almost certainly includes MFA, conditional access, and often phishing-resistant options, in a licensing tier you may already pay for. For most small and mid-market companies this is the right starting point, and sometimes the right ending point too. Turn it on, require it everywhere, pick strong factors, close the legacy gaps.

Add a standalone authentication product. This earns its place when your IdP's MFA is genuinely weak, when you need stronger or more flexible factors, when you are running multiple identity systems and want one policy across them, or when the built-in user experience is bad enough to drive workarounds.

Move to passwordless. A dedicated passwordless or phishing-resistant platform makes sense when you have decided to remove passwords as a strategic goal. This is more a maturity destination than a starting purchase.

Bring in help. A managed or co-managed approach fits when you do not have the hands to plan and run a rollout across a messy estate, or when you want someone vendor-neutral to design the policy and pick the factors with you.

the decision criteria that actually matter

• Phishing resistance · What to look for: Does it support FIDO2, passkeys, and device-bound credentials, and can you require them for the accounts that matter? This is the headline criterion now.
• Factor breadth · What to look for: Does it cover the people you actually have, including those with no smartphone and those on shared devices?
• Coverage · What to look for: Can it protect every app, including ones outside single sign-on, and can it close or block legacy authentication protocols?
• Policy control · What to look for: Can you set conditional and risk-based rules you understand and can tune, rather than an opaque score?
• Recovery and fallback · What to look for: What happens when someone loses their key or phone? The recovery path is a favorite attacker target, so it has to be both usable and hard to abuse.
• Enrollment experience · What to look for: How painful is it to get everyone enrolled? Friction here creates the exceptions that hollow out the whole thing.
• IdP integration · What to look for: Does it fit cleanly with the identity provider and the apps you already run?
• Admin overhead · What to look for: How much ongoing work does it take to run, and do you have the people for it?
• Evidence · What to look for: Can it produce the coverage reporting and audit trail a regulator or an insurer will ask for?
• Cost model and EU · What to look for: How is it priced, and where does the data live?

If you only take one row, take phishing resistance. Most of the security upside in an authentication purchase today comes from moving your important accounts out of the shared-secret tier and into the phishing-resistant one.

how MFA is priced, and the real cost

Authentication is usually priced per user per month, and it is very often bundled into your identity provider's licensing tiers, which is why the honest first move is to check whether you already own what you are about to buy. Stronger capabilities tend to sit in the higher tiers. The sticker price is rarely the real cost. Budget for the things around it:

• Hardware keys. If you go the FIDO2-key route, the keys are a per-person hardware cost, often two per person so there is a backup. For privileged users this is money well spent. Across a whole workforce it adds up, which is part of why passkeys stored on devices are attractive.
• The help desk. Every MFA rollout generates reset and lockout tickets. Recovery-related load is the part teams consistently underestimate.
• Enrollment. Getting everyone enrolled, especially deskless and remote workers, takes planning and time. It is a project, not a switch.
• The renewal. Watch the uplift at renewal and what moving between tiers does to your bill.

how to run the evaluation

Keep it disciplined and short. Build a shortlist of two or three options, including the do-nothing-new option of fully configuring your existing IdP. Then send a focused set of questions rather than a generic RFP. The useful ones are specific: Which phishing-resistant factors do you support and can we require them per group? How do you handle a user with no smartphone? What does account recovery look like, and how is it protected against abuse? Can you protect apps outside our SSO? Can you block legacy authentication? What coverage reporting can you produce for an auditor?

Then run a real proof of concept. Enroll a pilot group that deliberately includes the awkward cases: an admin, a deskless worker, a contractor on an unmanaged device, someone who will lose their phone on purpose so you can test recovery. Try a phishing-resistant factor end to end. Point it at one of your apps that lives outside SSO and see what happens. Set explicit success criteria before you start.

Finally, take references, and ask them the question that matters: not whether they like the product, but what broke during their rollout and what they wish they had known.

the traps the demo won't show

SMS quietly remains the default fallback, so the strong factor you bought sits in front of a weak one anyone can fall back to. The push prompts get configured without number matching, leaving the fatigue attack open. Legacy authentication stays enabled in a corner, and the whole MFA investment can be skipped through that one door. Admins and service accounts get exceptions because they were inconvenient, which is precisely backwards. And the recovery flow turns out to be the softest part of the entire system, because social-engineering the help desk is easier than beating the authentication.

The common shape of all of them: the average login is well protected and the exceptions are not, and the exceptions are the whole game.

where this meets the rules

NIS2 names multi-factor authentication explicitly in its risk-management measures under Article 21, so for in-scope entities it is a stated obligation rather than a recommendation. DORA, for financial entities, requires strong authentication on privileged and remote access through its technical standards. And cyber insurers now routinely make MFA a condition of cover, sometimes specifically on email, remote access, and privileged accounts, and will check. None of these regimes generally tells you which factor to use, but the direction of travel and the threat data both point at phishing-resistant authentication.

This is context for prioritizing, not legal advice, and the specifics depend on your sector and country.

a sequenced path

Crawl: get MFA required, not merely available, on every account and every app you can reach. Turn on number matching for push. Close legacy authentication. Move off SMS-only wherever something better exists. This alone removes most of your account-takeover risk and it is mostly configuration of things you own.

Walk: put phishing-resistant factors on the accounts that would hurt most if they fell, which means admins, finance, and anyone with broad access. Bring the apps outside SSO into the policy. Stand up conditional access rules you actually understand. Fix the recovery flow so it is not the weak link.

Run: extend phishing-resistant authentication toward everyone, move toward passwordless, and tune risk-based policies with real signals. Watch for MFA abuse with identity threat detection. At this stage authentication stops being a project and becomes a steady-state property of how people sign in.