Hardware and software tokens are the real MFA trade-off

At a glance

What this is: This is an analysis of hardware versus software security tokens for MFA, with the key finding that phishing-resistant authentication depends on use case, assurance level, and lifecycle management.

Why it matters: It matters because IAM teams have to align human authentication controls, token lifecycle processes, and broader identity governance without creating new friction or fragmented authentication silos.

By the numbers:

• 93% of organizations had two or more identity-related breaches in the past year.
• implementing multi-factor authentication in its simplest form adds major improvements to your security posture, blocking up to 100% of automated bots, 99% of bulk phishing attacks, and 66% of targeted attacks

👉 Read Axiad's analysis of hardware versus software security tokens for MFA

Context

Passwords are still a weak foundation for identity security because they are easy to phish, reuse, and centralise in ways attackers can exploit. In human IAM programmes, the practical question is not whether MFA is needed, but which authenticator type best fits the assurance level, device model, and user workflow.

For security architects and IAM leads, the real design issue is that authentication is now an ecosystem problem. Identity providers, certificate authorities, endpoint devices, and lifecycle management all have to work together if the goal is phishing-resistant access rather than a narrow one-time control.

Key questions

Q: How should security teams choose between hardware and software tokens for MFA?

A: Security teams should choose based on assurance needs, user mobility, and recovery complexity. Hardware tokens are better where phishing resistance and impersonation resistance matter most. Software tokens are better when endpoint integration and user convenience are important, but they must be bound to a trusted device model and governed through strong lifecycle controls.

Q: Why do phishing-resistant authenticators still need lifecycle governance?

A: Phishing-resistant authenticators can still fail operationally if enrollment, renewal, revocation, or recovery are poorly managed. A strong token that remains active after a device change or support exception is still a trust risk. Lifecycle governance keeps authentication assurance aligned with the identity’s current state.

Q: What breaks when passwordless programmes keep weak fallback options?

A: Passwordless programmes break when help-desk resets, emergency bypasses, or password recovery paths remain available without strong controls. Attackers often target the easiest path, so a strong primary factor does not compensate for a weak secondary process. The entire authentication journey has to be governed as one system.

Q: What is the difference between hardware-backed and software-backed authentication in practice?

A: Hardware-backed authentication depends on a physical authenticator or device chip to prove possession, while software-backed authentication relies on an authenticator stored on an endpoint or companion device. The practical difference is not just convenience. It is whether the control can resist phishing, device compromise, and credential export in your environment.

Technical breakdown

Hardware tokens and phishing-resistant authentication

Hardware-based tokens are physical authenticators such as security keys, smart cards, or device-bound cryptographic modules that prove possession through cryptographic challenge-response. They are harder to export or replay than shared secrets, which is why they are commonly used for phishing-resistant authentication. Their value increases when the assurance target is high and the user must prove identity across multiple sessions or applications. In practice, the security gain comes from reducing the chance that a remote attacker can capture and reuse a credential in transit.

Practical implication: map high-risk user groups to hardware-backed authenticators where phishing resistance matters more than convenience.

Software tokens, passkeys, and device binding

Software-based tokens live on an endpoint, secure enclave, mobile device, or companion authenticator and can deliver OTPs, push approvals, passkeys, or certificate-based authentication. They are more flexible than hardware devices, especially in mixed fleets and distributed workforces, but their security depends on the strength of the device and the binding model. A software token is not automatically weak, but it can become easier to abuse when the endpoint itself is compromised or when approval flows are overly permissive.

Practical implication: treat software tokens as part of the endpoint trust model and verify how the token is bound, stored, and recovered.

Token lifecycle management and passwordless migration

Token lifecycle management covers enrollment, renewal, revocation, and support when credentials change or devices are replaced. That layer matters because strong authentication fails operationally if users cannot provision tokens reliably or if revoked credentials remain usable too long. A passwordless migration also has to account for identity provider diversity, certificate authority trust, and user population rollout. The technical problem is not only issuance, but maintaining assurance across the full lifecycle so that authentication controls do not fracture into exceptions and fallback paths.

Practical implication: design token issuance and revocation workflows before scaling passwordless authentication across the enterprise.

Threat narrative

Attacker objective: The attacker wants to obtain authenticated access through a weaker factor and use that foothold to reach higher-value systems and data.

1. Entry begins when attackers target weak human authentication paths such as passwords or replayable OTP flows rather than higher-assurance authenticators. Credential capture is then easier when users are trained to approve prompts or reuse factors across services.
2. Escalation happens when the stolen factor can be reused across identities, applications, or identity providers because the authentication model lacks strong binding or impersonation resistance. That turns a single compromised factor into broader account access.
3. Impact occurs when the attacker gains authenticated access to business systems, bypasses phishing-resistant controls, or moves laterally through identity-backed services that trusted the compromised authenticator.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Internet Archive breach — unsecured GitLab authentication tokens exposed 31M Internet Archive accounts.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Hardware tokens matter because phishing resistance is still an identity governance problem, not just an authentication preference. The article correctly separates factor classes, but the governance question is which identities justify stronger assurance and which workflows can tolerate softer recovery paths. NIST SP 800-63 frames that as assurance, while ZTA pushes continuous trust evaluation across the access path. The practitioner takeaway is to align authenticator strength to risk, not to user preference alone.

Software tokens create a lifecycle dependency that many IAM programmes still understate. Enrollment, renewal, revocation, and device replacement are not support details, they are control points. When those processes are weak, software tokens can outlive the conditions that made them trustworthy. The implication is that authentication programmes need lifecycle discipline as much as factor selection.

Passwordless migration exposes the gap between authentication policy and operating model. The article assumes organisations can move users from passwords to strong authenticators in stages, but that only works when identity providers, certificate authorities, help desks, and recovery workflows are coordinated. Authentication assurance was designed for a bounded login event, but enterprise identity is now a distributed lifecycle. That assumption fails when every recovery path becomes an exception. Practitioners should treat passwordless as an operating model change, not a feature rollout.

Unified token management is the real control plane behind strong authentication. The article’s strongest point is that factor strength alone is not enough if issuance and revocation fragment across platforms. NHI Mgmt Group’s view is that identity teams should evaluate whether token administration can be governed as a consistent lifecycle service across user groups, devices, and IdPs. That is where assurance is preserved or lost.

Phishing-resistant authentication is the right target, but only if fallback paths are equally governed. Strong authenticators lose value when recovery, help-desk resets, or temporary exceptions quietly reintroduce weaker paths. The field should focus less on a single factor debate and more on whether the overall authentication system still holds under operational pressure. Practitioners should look for the weakest recovery path, not only the strongest primary factor.

From our research:

• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to Ultimate Guide to NHIs.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, which leaves credentials active long after their intended use.
• For a broader view of where authentication and access governance fit into identity programmes, see Top 10 NHI Issues.

What this signals

Phishing-resistant authentication is becoming a baseline expectation, but the control only holds if the lifecycle around it is equally mature. Organisations that focus narrowly on the authenticator and ignore renewal, revocation, and fallback recovery are effectively shifting risk rather than reducing it. For teams modernising identity programmes, the deciding factor is whether the whole authentication path can withstand operational exceptions without silently reverting to weaker controls.

Hardware versus software is not the real choice. The real choice is whether identity governance can keep assurance intact across devices, IdPs, and support processes. That is why token management, trust establishment, and exception handling matter as much as factor strength. Teams that treat passwordless as a technology swap will miss the governance work required to make it durable.

For practitioners

• Define authenticator strength by user risk tier Classify applications and user populations by phishing exposure, privilege level, and mobility needs, then assign hardware-backed or software-backed tokens accordingly. High-risk administrative and remote access paths should not rely on the same assurance level as low-risk routine logins.
• Map token lifecycle controls before scaling passwordless Document how users will enroll, renew, revoke, and replace authenticators across identity providers and device types. Make sure recovery flows are governed with the same rigor as primary enrollment so that weak fallback paths do not undo the control.
• Eliminate unmanaged fallback authentication paths Review password resets, help-desk overrides, and emergency access procedures to identify where weaker factors still exist. If an attacker can bypass strong authentication through a recovery step, the programme is only partially passwordless.
• Standardise certificate trust across identity platforms If certificate-based authentication is part of the strategy, establish trust between identity providers and certificate authorities before broad rollout. That reduces siloed authenticator management and makes revocation and renewal more reliable at scale.

Key takeaways

• Hardware and software tokens solve different authentication problems, but neither works well without lifecycle governance.
• Phishing-resistant MFA only delivers its promise when enrollment, recovery, and revocation are controlled as tightly as primary login.
• Passwordless migration changes the operating model for IAM teams, not just the choice of authenticator.

Key terms

• Phishing-resistant Authentication: Authentication designed so stolen secrets are not enough to impersonate a user. It typically uses cryptographic proof of possession, often through hardware-backed or device-bound authenticators, and reduces the chance that a remote attacker can replay or extract a login factor.
• Authentication Assurance Level: A measure of how much confidence an organisation can place in an authentication method. Higher assurance levels require stronger proof of possession, stronger binding to the user or device, and resistance to impersonation, which matters when access risk is high or privileged systems are involved.
• Token Lifecycle Management: The governance of how authenticators are issued, enrolled, renewed, replaced, and revoked over time. In practice, this is what keeps a strong token trustworthy after a user changes devices, leaves a role, or needs recovery support, and it prevents stale credentials from lingering in production.

Deepen your knowledge

Hardware-backed authentication and token lifecycle governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are planning a passwordless or phishing-resistant authentication programme, it is worth exploring.

This post draws on content published by Axiad: An Identity Love Story, Hardware vs Software Security Tokens. Read the original.