Phishing still wins because it exploits people, not just systems. In Zero Trust environments, the real challenge is balancing stronger authentication with login friction, help desk load, and total cost of ownership. The wrong MFA choice can either leave high-value accounts exposed or create enough user resistance to undermine adoption.
Hardware tokens, soft OTP, and push MFA solve MFA in different ways: hardware tokens usually deliver the strongest phishing resistance, soft OTP balances cost and deployment speed, and push MFA offers the best user experience but is more vulnerable to push fatigue and adversary-in-the-middle attacks. The right choice depends on risk level, budget, user profile, and compliance needs.
Hardware tokens win on phishing resistance
Hardware tokens give the strongest practical defense when account takeover would hurt the most. A FIDO2 security key or a dedicated token forces the attacker to defeat a physical device, not just a password and a code. That is why many Zero Trust teams reserve them for admins, finance, executives, and other high-value roles.
The strongest point is simple: phishing loses a lot of its power when the secret never leaves the device. NIST SP 800-63B treats authenticator types differently for a reason, and FIDO Alliance guidance keeps pointing in the same direction. A hardware token is the closest thing to a gate with a real key.
FIDO2 blocks relay attacks
FIDO2 security keys use public-key cryptography, which means the site proves who it is and the key proves it is present. A fake site cannot easily reuse the login result on a real site. That blocks the classic trick where an attacker copies a code or relays a session through a lookalike page.
That difference matters in the United States, where phishing remains a common entry point for breach response teams and insurers alike. CISA has pushed phishing-resistant authentication for a reason. The practical lesson is blunt: if the account is worth a lot, use the factor that breaks the attack path.
Choose this if: the user has admin rights, handles sensitive data, or signs into critical systems from shared or high-risk devices.
Best fit for privileged users
Hardware tokens fit privileged access because privileged access fails badly when it gets stolen. A stolen admin session can expose cloud consoles, source code, payroll, or production controls. That is a very different problem from a normal employee login.
The error most teams make here is treating every user the same. That sounds fair, but it often creates weak access where it matters most. A case that shows up often: a company rolls out push MFA to everyone, then learns the admin team still needs something stronger after a phishing incident.
Hardware tokens are the best choice when account compromise would cost more than the devices and support around them. They are not the cheapest path, and they are not the easiest to replace. They are the safest bet for high-risk identities where phishing resistance matters more than convenience.
Pros
- Very strong resistance to phishing and man-in-the-middle attacks.
- Works well for privileged users and high-risk roles.
- Does not depend on a phone being present or unlocked.
- Supports stricter Zero Trust policies and stronger assurance levels.
Contras
- Higher replacement and shipping overhead.
- Lost tokens create helpdesk work and recovery delays.
- Users can forget them at home, which creates friction.
- Not the best fit for cheap, broad rollout to low-risk users.
Para quién es
- Admins, engineers, and security teams.
- Executives with access to sensitive systems.
- Organizations that must reduce phishing risk hard and fast.
- Teams that can absorb device logistics and replacement costs.
Para quién NO es
- Very low-risk workflows where strong MFA adds more friction than value.
- Large populations with tight budgets and no device program.
- Use cases where users constantly switch devices and locations.
Estimated cost pressure: Hardware keys often cost about $20 to $60 per user for the device alone, and enterprise support can push the real cost higher once shipping, replacement, and helpdesk time are included.
“Phishing-resistant MFA is a critical layer in modern identity security.” — CISA guidance, reflected across federal Zero Trust programs
Adversary-in-the-middle attacks are the key reason many security teams now prefer phishing-resistant MFA for sensitive access. In an AitM attack, the victim is tricked into logging into a lookalike site that proxies the session to the real service in real time, which means even a valid OTP can be captured and reused before it expires. That is where hardware tokens with FIDO2 security key support stand out, because the authentication is bound to the origin and is much harder to relay.
Soft OTP and push MFA can still be useful, but both require stronger compensating controls when privileged access, Zero Trust policies, or high-value accounts are involved. In practice, the more targeted the user population, the more likely AitM risk should push the decision toward hardware-backed authentication.
Soft OTP cuts cost but not phishing risk
Soft OTP is a software app that generates one-time passwords, usually TOTP codes that change every 30 seconds. It is cheaper than hardware tokens and easier to hand out at scale. The trade-off is plain: a code can still be stolen, typed into a fake site, or exposed if the phone is already compromised.
That is why soft OTP sits in the middle. It beats SMS, which suffers from SIM swap and interception risk, but it does not reach the phishing resistance of a hardware token. A lot of teams like the price first and worry about the threat model later. That usually works until it does not.
TOTP is cheaper to scale
TOTP means time-based one-time password. The code changes on a short timer, usually every 30 seconds, and the server checks whether the code matches the current time window. Google Authenticator, Microsoft Authenticator in OTP mode, and Duo app flows all fit this model in different ways.
The upside is easy to see. There is no shipping box, no spare key inventory, and no need to replace a physical device every time a user changes roles. For a broad workforce, that saves money and time.
The downside is also easy to miss. If a user types the code into a fake login page, the attacker can race that code into the real site. That is why soft OTP helps, but it does not stop modern phishing on its own.
Choose this if: cost matters, users have smartphones, and the environment needs better-than-SMS MFA without the logistics of hardware keys.
Compromised devices raise exposure
Soft OTP depends on the phone or laptop staying trustworthy enough to protect the app and the code. If malware reads notifications, captures screen content, or tricks the user into revealing the code, the defense weakens fast. The code is only one step away from the attacker once the device itself is part of the problem.
The majority of guides say TOTP is “good enough” for most users. What they do not mention clearly is that it remains replayable if the attacker controls the login flow. That matters in credential stuffing, helpdesk fraud, and phishing kits that proxy the session in real time.
A common case: a company uses soft OTP for most staff, then lets contractors and remote workers enroll the same way. The result is usually fine until a phishing campaign targets the shared vendor portal. Then the team learns the app was never the real issue.
Soft OTP is a cost control tool, not a phishing cure. It fits many standard users well, but it should not be the default for privileged access or for teams that face targeted attacks. If the risk is moderate and the budget is tight, it can be the right compromise.
Pros
- Lower cost than hardware tokens.
- Easy to distribute and enroll at scale.
- Works well for employees who already carry smartphones.
- Better than SMS for most enterprise use cases.
Contras
- Still vulnerable to phishing and real-time relay attacks.
- Depends on a phone or device being available.
- Can break down when the phone is lost, dead, or replaced.
- Does not fit high-assurance access by itself.
Para quién es
- General employees with moderate risk.
- Teams that want lower cost than hardware tokens.
- Organizations already using an authenticator app for SSO.
Para quién NO es
- Admins and privileged users.
- Environments targeted by phishing crews or nation-state actors.
- Teams that need phishing-resistant authentication for compliance.
Push MFA is fastest, but needs controls
Push MFA is the easiest factor for many users because it turns login into a simple approve or deny prompt. That speed helps adoption, especially in large companies with mixed device habits. The problem is that a plain push prompt is easy to abuse with repeated requests, especially when a user is tired or distracted.
Microsoft, Duo Security, and Okta all moved toward tighter push controls for the same reason. Push fatigue attacks exploit human habits, not cryptography. If the prompt comes often enough, someone will tap the wrong button.
Number matching reduces fatigue
Number matching asks the user to type or select a number shown on the login screen. That tiny step changes the game because an attacker cannot spam the user into a blind yes. It also helps users notice that a real login request belongs to a real session.
This works well in practice, but only if the whole flow stays clean. If users see too many prompts, they stop paying attention. The fix is not more prompts. The fix is fewer prompts, tied to device trust and better session rules.
Choose this if: user adoption matters most, the workforce already uses smartphones, and the team can turn on number matching and device checks from day one.
Rate limits stop abuse loops
Rate limiting caps how many push prompts a user can receive in a short window. That blocks the easy abuse pattern where an attacker keeps sending prompts until the user caves. Device binding helps too because it ties the prompt to a known device, not just a phone number or a loose app account.
What many guides omit is the support cost of “simple” push MFA. It looks cheap until someone loses a phone, changes devices, or gets locked out on travel. Then the helpdesk gets the bill.
A practical rule works well here: use push MFA for broad employee access, but turn on number matching, device binding, and sensible rate limits before rollout. Without those controls, the design leans too hard on human patience.
Push MFA is the best user experience, but only after it gets hardened. Plain push approval is not a safe default for sensitive access. It becomes useful when the organization treats it as a controlled access step, not a quick yes button.
Pros
- Fast login and low user friction.
- High adoption in general employee populations.
- Easy to pair with SSO and IAM flows.
- Often simpler to roll out than hardware token programs.
Contras
- Susceptible to push fatigue attacks.
- Can fail if controls like number matching are missing.
- Still depends on a phone and app access.
- Not equal to phishing-resistant authentication on its own.
Para quién es
- Large employee groups.
- Organizations that need low-friction MFA quickly.
- Teams that can enforce device trust and push controls.
Para quién NO es
- Highly targeted users.
- Privileged admins.
- Apps that face serious phishing or session relay risk.
Deployment reality: push MFA usually lowers enrollment friction, but support still rises when users lose phones, change devices, or travel without cell service.
Compare costs, UX, and security
The best MFA choice depends on where the company feels pain first. If the pain is phishing and privilege, hardware tokens win. If the pain is budget, soft OTP usually lands well. If the pain is adoption, push MFA often wins the first rollout, then needs hardening.
This is where a lot of buying decisions go sideways. Teams compare list prices and ignore recovery, exceptions, and helpdesk load. A token that costs $40 can become a $140 problem once shipping, replacement, and support enter the picture.
Decision matrix by use case
| Use case |
Best fit |
Phishing resistance |
User friction |
Dependency |
Operational cost |
| Privileged admin access |
Hardware token |
Very high |
Medium |
Physical token |
High |
| General workforce |
Push MFA with controls |
Medium to high |
Low |
Smartphone |
Medium |
| Cost-sensitive staff |
Soft OTP |
Medium |
Medium |
Authenticator app |
Low |
| Users without smartphones |
Hardware token |
Very high |
Medium |
Token only |
High |
| Compliance-heavy access |
Hardware token or FIDO2 key |
Very high |
Medium |
Physical possession |
High |
TCO includes support and recovery
Total cost of ownership means the full cost, not just the sticker price. That includes enrollment time, lost device replacement, shipping, helpdesk tickets, backup codes, exceptions for BYOD, and recovery for users who lock themselves out. Those costs can dominate the budget.
The best numbers usually come from vendors and internal ticket data, but the pattern is stable. Hardware tokens cost more to buy and replace. Push MFA costs more to support if users change phones often. Soft OTP sits in the middle.
A rough enterprise pattern in the United States often looks like this: hardware token programs can run about $20 to $60 per token before support, while a soft OTP rollout may stay lower on device cost but add recovery time. Push MFA can start cheap and still become expensive if the team ignores lockout handling and prompt fatigue.
If one compromised account could lead to incident response, audit pain, or production disruption, hardware tokens often pay for themselves. That is especially true for execs, SOC staff, and cloud admins. The purchase price looks higher, but the risk avoided can be much larger.
If users resist change and the organization needs fast rollout, push MFA often beats the others in the first quarter. It gets people in the door. Then the team should harden it or move high-risk users to something stronger.
If the company wants a cheaper step up from SMS and most users already carry smartphones, soft OTP is a fair middle ground. It is not the safest path. It is the practical one when hardware logistics would slow everything down.
A true side-by-side comparison matters because these three MFA methods fail in different ways. Hardware tokens give the strongest phishing resistance and the highest authentication assurance, but they add shipping, replacement, and onboarding overhead. Soft OTP is cheaper to deploy and easier to standardize, yet it remains vulnerable if a user enters the code into a fake page or the device is compromised. Push MFA is usually the fastest to adopt and the least disruptive for employees, especially in BYOD environments, but it needs controls such as number matching, device binding, and rate limits to reduce push fatigue.
For enterprises deciding between them, the right answer often depends on whether the main goal is security, cost control, or login friction reduction.
Deploy MFA for zero trust at scale
In Zero Trust, the factor choice should match the risk of the resource, not just the user’s preference. A low-risk SaaS login does not need the same treatment as a production cloud console. That is the core idea behind NIST and modern identity architecture: trust less, verify more, and match strength to exposure.
Zero Trust Architecture works best when MFA sits inside a wider identity and device policy. SSO, IAM, risk-based authentication, and device trust all matter. MFA alone does not fix a weak session policy or a broken recovery process.
Bind policy to risk level
High-risk apps need stronger authentication. That often means hardware tokens for admins and push or soft OTP for the rest, but only if the policy engine can tell the difference. A single blanket rule is easy to manage and often too weak.
The smartest rollout uses step-up access. A user can open email with one factor profile, then face a stronger prompt for payroll, cloud admin, or code signing. That keeps friction lower where the risk is lower.
Pair with SSO and IAM
SSO reduces password sprawl. IAM keeps the account lifecycle under control. Together they lower the mess that MFA has to clean up. If offboarding fails, MFA will not save the account after access should have ended.
The same rule applies to recovery. A weak reset process becomes the easiest target in the system. That is why the best MFA design always includes deprovisioning, helpdesk verification, and clear backup methods.
Policy gap to avoid: a strong login factor can still fail if the recovery path lets an attacker impersonate a user at the helpdesk.
For most US enterprises, the safest default is a tiered model: hardware tokens for admins and high-risk users, push MFA with number matching for the general workforce, and soft OTP only where cost or device limits block the better options. That mix works well, but only if recovery stays strict and device loss gets handled the same way every time. If the organization cannot enforce those controls, hardware tokens should cover a larger share of users.
A small architecture note for cloud access
AWS, Kubernetes, and CI/CD access often fail through one bad admin credential. That is why strong MFA on cloud control planes matters more than most teams admit. Push can work for routine staff, but admins who touch production usually deserve hardware tokens.
Reconcile with compliance needs
PCI, HIPAA-adjacent controls, and federal procurement requirements often favor stronger assurance for privileged access. NIST SP 800-63B does not tell every company the same answer, but it clearly separates stronger authenticators from weaker ones. If audit pressure is high, hardware tokens make the conversation much easier.
Implementation at scale is usually decided less by theory and more by operational constraints. A company with a BYOD policy may prefer push MFA or soft OTP for broad employee access because enrollment is fast and users already carry a smartphone, but that same model can fail for contractors, frontline staff, or users without smartphones. Compliance-heavy environments often require stronger authentication assurance for privileged access, auditability of recovery flows, and consistent enforcement of step-up rules for sensitive apps.
Product teams should also ask how the system handles lost devices, temporary access, break-glass scenarios, and help desk load during migrations. The best rollout is rarely one-size-fits-all; it is usually a tiered policy that matches MFA strength to risk, user context, and support capacity.
Hidden failure modes at rollout
The biggest MFA failures are rarely technical. They come from the edges: lost tokens, bad recovery, incomplete deprovisioning, and users who sit outside the main design. If the team ignores those cases, the rollout looks fine in the pilot and ugly in month three.
Lost-token recovery traps
Lost-token recovery needs a hard process. If the helpdesk can reset access too easily, attackers will target the helpdesk. If the process is too strict, real users get stuck and work stops. The right balance is annoying on purpose.
A common mistake is to let a backup email or SMS become the real recovery path. That turns a stronger MFA setup into a weaker one through the back door. Recovery should be as serious as initial enrollment.
BYOD exceptions break plans
Bring-your-own-device sounds simple until it meets employee privacy, device support, and legal review. A personal phone may be fine for push MFA, but not every worker wants a work app on a personal device. Some users do not have smartphones at all.
That is where the clean story breaks. The company either buys hardware tokens, allows soft OTP on a managed device, or creates an exception path. There is no magic fourth option.
FAQ about MFA factor choice
What is the best MFA method for zero trust in the
Hardware tokens are the strongest default for high-risk access. For general users, push MFA with number matching is often the best balance of adoption and control. Soft OTP fits when budget is tight and smartphones are common.
Are hardware tokens worth the cost?
Yes, when phishing risk or breach cost is high. A token can cost about $20 to $60, but the real cost also includes shipping, replacement, and helpdesk time. That trade-off makes sense for admins, finance, and sensitive systems.
Is soft OTP secure enough for enterprise use?
It is secure enough for many standard users, but not for the highest-risk accounts. Soft OTP works well against casual threats, yet phishing can still steal and relay the code in real time. It should not be the only defense for privileged access.
What makes push MFA risky?
Push MFA becomes risky when users get prompt fatigue or approve requests by accident. Number matching, device binding, and rate limiting lower that risk a lot. Without those controls, push approval is too easy to misuse.
How should a company choose between cost and
The company should rank users by risk first, then by cost. Hardware tokens fit high-risk users, push MFA fits broad low-friction access, and soft OTP fills the budget gap. A one-size-fits-all answer usually creates either too much risk or too much friction.
Can push MFA meet compliance needs?
Sometimes, but not always. Push MFA can support compliance when the organization uses number matching, device binding, and strict recovery, yet many auditors still prefer phishing-resistant methods for privileged access. Hardware tokens make the compliance story easier.
What to do next
Choose hardware tokens for admins and high-risk users. Use push MFA with controls for the general workforce. Keep soft OTP as the practical middle option when cost or device constraints block the stronger choice.
The best program is not the fanciest one. It is the one that survives phishing, recovery, travel, lost phones, and budget reviews without falling apart.
Which MFA option works best for users without smartphones?
Hardware tokens work best for users without smartphones. Soft OTP and push MFA both depend on a phone or similar device, so they fail or become awkward when no smartphone exists. That edge case matters more than many buying teams expect.
