What good is a second lock if the thief already has a copy of the key? That question applies to every multi-factor authentication (MFA) decision. Many organizations have MFA enabled and still get breached because the type of second factor matters far more than the checkbox on a compliance form. Choosing well means understanding what each method defends against, where it fails, and how much friction users will tolerate before they turn to workarounds.
This guide walks through the practical side of that decision: the method comparison, the questions to ask before buying, the mistakes that quietly undermine deployments, and the trade-offs that rarely make it into vendor brochures.
Why “We Have MFA” Is Not a Security Answer
MFA simply means requiring two or more independent pieces of evidence to log in: something you know (a password), something you have (a phone, a security key), or something you are (a fingerprint). The concept is sound. The execution is where things get messy.
The U.S. Cybersecurity and Infrastructure Security Agency (CISA) has built an entire campaign, “More than a Password,” around the idea that not all MFA is equal. Its guidance ranks phishing-resistant methods such as FIDO/WebAuthn security keys and passkeys above app-based codes and push prompts, and places SMS and voice codes at the bottom of the pile. That ranking is the single most useful mental model for anyone shopping for MFA today.
The reason is simple. One-time codes, whether delivered by text or read from an app, can be typed into a fake login page. Push notifications can be approved by a tired user at 11 p.m. when a prompt appears out of nowhere. Only methods that bind the credential to the real website’s origin, like WebAuthn, close that gap entirely.
The Method Comparison That Should Drive Your Decision

Before evaluating vendors, get clear on the methods themselves. The table below reflects how security agencies and standards bodies generally rank them.
| Method | Phishing resistance | Cost per user | Friction | Best fit |
|---|---|---|---|---|
| FIDO2 security key / passkey (WebAuthn) | High | Low to medium (one-time hardware cost) | Low after setup | High-value accounts, admins, executives |
| Platform biometrics (Face ID, Windows Hello) | High when device-bound | Included with device | Very low | Staff on managed laptops and phones |
| Authenticator app codes (TOTP) | Partial | Free | Medium | Broad workforce coverage |
| Push notification with number matching | Partial | Low | Low | Large user bases wanting convenience |
| SMS or voice one-time codes | Low | Low | Medium | Legacy systems, fallback only |
| Email codes | Low | Free | Medium | Last-resort recovery only |
A useful rule of thumb: the further up that table you can push your most privileged users, the better your overall posture. Most breaches that bypass MFA start with an account that had a weaker factor than it should have.
For a plain-language grounding in the underlying concept, it helps to review what multi factor authentication actually covers before comparing products, because vendors use the term loosely. (Multi-factor authentication)
Start With Your Threat Model, Not a Product Demo
The most common mistake is starting with a vendor shortlist. Start instead with a blunt question: who is realistically targeting us, and what would they gain?
A small business worried about credential-stuffing bots has a different problem from a hospital protecting patient records or a law firm holding merger documents. The first needs broad coverage at low cost; the second needs phishing-resistant credentials on the accounts that matter most.
Three questions sharpen the picture quickly:
- Which accounts, if compromised, would cause real damage? Email administrators, finance approvers, cloud infrastructure owners, and anyone who can reset other people’s passwords.
- What attacks have we actually seen? Check your email gateway logs for credential-phishing attempts and your identity provider for failed login spikes.
- What does our insurer or regulator require? Cyber insurance questionnaires increasingly ask specifically whether phishing-resistant MFA protects privileged accounts.
The Australian Cyber Security Centre’s Essential Eight framework treats MFA as one of eight baseline mitigations and raises the bar at higher maturity levels, which is a helpful external benchmark if you need to justify budget internally.
Match the Method to the User, Not the Other Way Around
Here is where deployments succeed or fail. A method that works beautifully for a desk-based accountant can be miserable for a warehouse supervisor who shares a terminal, or for a field engineer on a poor mobile signal.
Practical patterns that hold up in real environments:
- Give executives and IT admins hardware keys or passkeys first. They are the highest-value targets and the smallest group to support.
- Use platform biometrics for managed laptops. Windows Hello and Touch ID cost nothing extra and are genuinely phishing-resistant when device-bound.
- Roll out app-based codes to everyone else as the baseline, then upgrade over time.
- Keep SMS as a documented fallback, not a primary method. It beats nothing, but the UK National Cyber Security Centre warns it is vulnerable to SIM-swap and interception.
One underrated step: register two authenticators per user during enrollment. Lockouts are the number one reason MFA rollouts get rolled back, and a spare key in a drawer prevents most of them.
If you are handling the setup yourself, a step-by-step walkthrough of how to enable two factor authentication on common platforms saves hours of trial and error. (Multifactor Authentication)
Phishing-Resistant MFA: What It Means and Why It Matters
The phrase gets used loosely, so pin it down. A method is phishing-resistant when a fake login page cannot capture anything reusable. WebAuthn, the W3C standard behind passkeys and FIDO2 keys, achieves this through public-key cryptography tied to the site’s domain. The user’s device signs a challenge for the real domain only; a lookalike site gets nothing useful.
The trade-off is recovery complexity. Lost keys mean a helpdesk process, and synced passkeys raise a question about whether the credential is truly device-bound. NIST’s digital identity guidelines distinguish between authenticator assurance levels, and synced passkeys generally do not meet the highest tier. For most organizations that is fine; for a handful of privileged roles, it is not.
A sensible approach is tiered: phishing-resistant credentials for the top few percent of accounts, strong app-based MFA for the rest, and a written exception process for legacy systems that cannot support either.
Don’t Forget the Identity Layer Around MFA
MFA does not exist in a vacuum. It sits on top of passwords, recovery flows, and device trust, and weaknesses in any of those can undo it.
Two practical points deserve attention. First, recovery. Attackers increasingly target the “forgot password” path because it often bypasses MFA entirely. Make sure recovery goes through the same identity proofing as login. Second, password hygiene. Even with MFA in place, reused passwords create a sprawling attack surface, which is why guidance on how to choose a secure password manager pairs naturally with any MFA rollout.
Endpoint security matters too. Session tokens stolen by infostealer malware can bypass MFA entirely, because the attacker inherits an already-authenticated session. Reviewing how to choose the best antivirus for your computer is a reasonable starting point for the endpoint side of the equation.
Biometric factors deserve their own consideration, particularly around privacy and template storage. A primer on what is biometric authentication helps frame when on-device biometrics are appropriate and when they raise consent questions.
Questions to Ask Before You Sign a Contract
Vendors all claim strong security. These questions separate the serious ones from the marketing decks.
- Which methods do you support, and which are phishing-resistant by your own definition? Ask for the specific standard, not a slogan.
- How do you handle recovery and account lockout? The answer reveals more about real-world security than any feature list.
- What does the admin console log, and can we export it to our SIEM? Visibility into failed and unusual authentications is how you catch attacks in progress.
- Can we enforce policy by user group and by application? Blanket policies create friction; granular ones get adopted.
- What happens if your service goes down? Ask about offline modes and break-glass accounts.
- How is pricing structured? Per-user, per-authentication, and per-application models produce wildly different bills at scale.
Get the answers in writing during the proof of concept, not after signature.
The Mistakes That Undermine Good MFA
Experience across deployments surfaces a familiar list of failure modes. Avoiding these matters more than picking the theoretically best method.
Rolling out to everyone at once. Pilot with a friendly group of 20 to 50 users, fix the confusing parts, then expand in waves.
Skipping user education. A five-minute explainer video on why the prompt appeared and what to do reduces helpdesk tickets dramatically. Users who understand the “why” approve fewer suspicious prompts.
Ignoring the push-fatigue problem. If your provider supports number matching or additional context in push prompts, turn it on. Repeated random prompts are a classic precursor to an account takeover.
Treating MFA as a one-time project. Methods, threats, and standards evolve. Schedule a review every year, and revisit whenever a major platform changes its defaults.
Forgetting service accounts and integrations. Automated processes often use static credentials with no MFA at all. Inventory them and move to workload identities or short-lived tokens where possible.
No break-glass plan. Keep at least two emergency administrator accounts with hardware keys stored securely offline, and document the recovery procedure where more than one person can find it.
Conclusion
Choosing multi-factor authentication is less about picking a product and more about matching methods to risk. Start with the accounts that would hurt most if compromised, push them to phishing-resistant credentials such as security keys or passkeys, and give everyone else a strong baseline with app-based codes. Register backup authenticators, harden the recovery path, and treat the rollout as a change-management project rather than a software install.
The organizations that get this right tend to share a trait: they measure success by how few successful account takeovers they suffer, not by how many users have MFA switched on. That distinction is worth keeping in view every time a vendor demo makes a simpler method look tempting.
Frequently Asked Questions
Is SMS-based MFA still worth using?
Yes, with caveats. It is far better than a password alone, and for low-risk consumer accounts it remains a reasonable fallback. But SMS codes can be intercepted or stolen through SIM-swap attacks, so they should not protect privileged or high-value accounts. Treat SMS as a stepping stone and plan to upgrade.
What makes MFA “phishing-resistant”?
A method is phishing-resistant when a fake login page cannot capture anything reusable. WebAuthn-based credentials, including FIDO2 security keys and passkeys, use public-key cryptography bound to the real site’s domain. Even if a user is tricked into visiting a lookalike page, the credential will not authenticate there.
How many backup authenticators should each user register?
At least two. A primary method plus one backup prevents most lockouts, which are the leading cause of MFA rollback. For administrators and executives, consider a hardware key stored securely offline in addition to a registered app or platform authenticator.
Does MFA protect against malware that steals session cookies?
Not reliably. If malware captures an authenticated session token, the attacker can reuse it without ever facing an MFA prompt. That is why MFA belongs alongside endpoint protection, prompt conditional access policies, and short session lifetimes rather than replacing them.
Can small businesses afford phishing-resistant MFA?
Often yes. Platform biometrics such as Windows Hello and Touch ID are typically included with hardware already in use. Hardware security keys cost a modest one-time amount per user, and many identity providers include passkey support in existing subscription tiers. Prioritize the highest-risk accounts first.
How often should MFA policy be reviewed?
At least annually, and immediately after any major change: a new cloud platform, a merger, a breach elsewhere in your industry, or a significant update to your identity provider’s defaults. Standards and attacker techniques both move, and a policy that was strong three years ago may now be the weakest link.


