TL;DR: Strong authentication is still foundational, but hardware and software tokens solve different parts of the MFA problem, especially where phishing resistance, device mobility, and lifecycle management matter, according to Axiad and cited NIST guidance. The real challenge is not choosing one factor class, but building a passwordless path that works across identity providers, devices, and user populations.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on Axiad's blog post: Identity security outcomes depend on the authenticator type, the user's device pattern and the token lifecycle in hardware versus software security tokens.
Why it matters: IAM teams need to treat token choice as an access governance decision because phishing resistance, portability and revocation behaviour affect both human authentication risk and the shape of passwordless programmes.
By the numbers:
- 93% of organisations had two or more identity-related breaches in the past year, according to CyberArk research cited by Axiad.
Context
Hardware and software security tokens are possession factors used in multi-factor authentication to prove a user has been issued something tied to their identity. The article frames the real question as one of assurance, portability and lifecycle management rather than token branding.
For IAM and IGA teams, the practical problem is that stronger authentication does not automatically translate into simpler operations. Different user populations, device types and identity providers create different governance constraints, especially when the goal is phishing-resistant passwordless access.
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 traditional MFA methods fail against phishing attacks?
A: Traditional MFA fails because many methods still depend on a code, prompt, or approval that an attacker can intercept, relay, or coerce in real time. Once the factor is replayable, the second step no longer proves the original user is present. That turns MFA into a weaker speed bump instead of a durable identity control.
Q: What breaks when token enrollment and revocation are handled inconsistently?
A: Inconsistent token handling creates delayed onboarding, stranded access, and unnecessary support overhead. If users are issued keys without coordinated enrollment or if revocation is not centralized, organisations can end up with access that outlives its purpose. That weakens joiner, mover, and leaver controls and increases the chance that access remains active after the operational need has ended.
Q: Why do organisations struggle to move from passwords to passwordless access in practice?
A: The main blockers are integration complexity, technical debt, and user acceptance, especially in environments with multiple authentication vendors and varied workflows. Passwordless fails when it is treated as a single login method rather than an access programme. Teams need consistent policy, broad authenticator support, and a rollout plan that reflects operational reality, not idealised architecture.
Technical breakdown
Why token form factor changes authentication assurance
Hardware and software tokens can both support MFA, but they do not offer the same operational properties. Hardware tokens such as security keys, smart cards and TPM-backed authenticators are often easier to make phishing resistant because the private credential can be bound to a device or hardware root of trust. Software tokens can be easier to distribute and embed across devices, but that convenience can increase dependence on the host device and its security state. The key distinction is not simply physical versus digital. It is whether the authenticator gives the organisation verifiable control over possession, binding and recovery.
Practical implication: choose the token type based on assurance requirements and the device estate you must govern.
How phishing resistance maps to NIST AAL expectations
The article connects token choice to Authentication Assurance Levels. NIST SP 800-63 differentiates mechanisms that prove possession through secure protocols from those that rely on hardware-based authenticators with verifier impersonation resistance. That matters because not every MFA method resists phishing equally, and not every deployment can reach the same assurance level without device binding, certificate support or stronger cryptographic flows. The governance issue is therefore lifecycle plus protocol. If the authenticator can be replayed, transferred or phished, the assurance label does not survive contact with real-world identity attacks.
Practical implication: map authenticator choices to required assurance levels before standardising on an MFA pattern.
Why credential lifecycle is the hidden control plane
The article repeatedly returns to token enrolment, renewal, revocation and support. Those are not administrative side tasks. They are the control plane that determines whether hardware and software tokens stay trustworthy after issuance. A roaming token for one user and a TPM-bound credential for another create different offboarding and recovery workflows, especially when users move between devices or identity providers. In practice, MFA failures often emerge when lifecycle operations lag behind access changes, not when the initial authentication design is weak.
Practical implication: govern token issuance, renewal and revocation as a lifecycle process, not a help desk workflow.
Breaches seen in the wild
- Salesloft OAuth token breach: hackers stole OAuth tokens to access Salesforce data via Salesloft.
- Dropbox Sign breach 2024: A compromised back-end service account gave attackers Dropbox Sign customer data, including API keys, OAuth tokens and MFA information.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Token choice is now an identity governance decision, not a feature preference. The article shows that hardware and software tokens create different assurance, portability and support outcomes, which means IAM teams are really choosing between governance models. Phishing resistance, roaming access and revocation complexity do not sit outside the control framework. They define it. The practitioner takeaway is to treat authenticator class as part of access policy design, not a user convenience decision.
Hardware-backed authentication collapses part of the phishing problem, but only when the lifecycle is controlled. A hardware token or TPM-backed credential can materially strengthen possession proof, yet the benefit depends on issuance, renewal and offboarding behaving predictably. If a token persists after the user or device context changes, the control ceases to be trustworthy. The implication is that assurance is a lifecycle property, not a one-time enrollment property.
Passwordless programmes fail when they are built around a single authenticator assumption. The article makes clear that broad deployments must work across operating systems, identity providers, applications and user populations. That is a governance problem because no single token model fits every population without creating exceptions, shadow processes or fallback paths. The named concept here is authenticator fragmentation: the condition where different user groups end up governed by different MFA rules, recovery methods and risk tolerances. Practitioners should expect complexity to move from login choice to lifecycle orchestration.
Phishing resistance is only durable when the authenticator cannot be casually reused across contexts. The article’s preference for certificate-based and hardware-rooted options reflects a broader control reality: the more transferable the authenticator, the more often the organisation must compensate with policy exceptions, device checks or extra recovery controls. That changes the security architecture around identity proofing, device trust and privileged access. The practitioner conclusion is to align authenticator portability with the sensitivity of the access path.
The MFA trade-off is really between assurance and operational elasticity. Hardware tokens tend to improve assurance, while software tokens can reduce deployment friction and broaden adoption. Neither wins universally. The right governance model depends on which user populations need mobility, which need high phishing resistance, and which can tolerate more constrained recovery. Security teams should build their standards around those boundaries, not around a default token preference.
What this signals
Authenticator fragmentation: many IAM programmes end up with multiple token patterns because device mobility, supportability and phishing resistance pull in different directions. That fragmentation becomes a governance problem when recovery and offboarding rules drift by user group, so teams should standardise token classes by access risk rather than by convenience.
Passwordless roadmaps usually stall at the lifecycle layer, not the cryptographic layer. The moment organisations must support device changes, identity provider variation and exception handling, they discover that token issuance, renewal and revocation are the real controls that determine whether the programme stays manageable.
For practitioners
- Standardise authenticator tiers by use case Define which applications and user populations require phishing-resistant hardware-backed credentials and which can use software-based tokens with lower assurance. Tie each tier to an explicit recovery and support model.
- Map token selection to device mobility Treat roaming users, fixed-device users and shared-device users differently. Hardware security keys suit mobile users who move between devices, while TPM-backed or device-bound credentials can fit users who work from a stable endpoint.
- Govern token enrolment and revocation as lifecycle controls Build issuance, renewal, suspension and revocation into the identity lifecycle so token state changes follow joiner, mover and leaver events without manual lag.
- Eliminate password fallback where assurance matters Phase out password sign-in on applications that already support stronger authenticators, then remove exception paths that undermine the phishing-resistant target state.
Key takeaways
- Hardware and software tokens are not interchangeable controls because they solve different assurance and mobility problems.
- The strongest MFA programmes couple phishing-resistant authenticators with disciplined token lifecycle governance.
- Passwordless access only scales when enrolment, recovery and revocation are designed as part of the identity operating model.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST SP 800-63, NIST CSF 2.0, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | SP 800-63B — Authentication | The article centres on authenticator strength, phishing resistance and assurance levels. |
| Recommendation — Align token choices to SP 800-63B assurance requirements and preferred phishing-resistant methods. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Token choice affects how access is granted, verified and governed across user populations. |
| Recommendation — Apply PR.AA-05 to match authenticator strength to access risk and user context. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | The article focuses on issuing, renewing and revoking possession-based authenticators. |
| Recommendation — Use IA-5 to govern token issuance, rotation, renewal and revocation across the identity lifecycle. | ||
| CIS Controls v8 | CIS-5 — Account Management | Token enrolment and revocation are account lifecycle functions that must stay synchronised. |
| Recommendation — Apply CIS-5 to keep token state aligned with account onboarding, changes and termination. | ||
| OWASP Non-Human Identity Top 10 | NHI-07 — Long-Lived Secrets | Software tokens and certificates become risky when they persist longer than intended or are reused broadly. |
| Recommendation — Review token lifetimes and reduce long-lived credential exposure where possible. | ||
Key terms
- Phishing-Resistant Authentication: Phishing-resistant authentication proves identity without relying on a user to approve a prompt or reveal a reusable secret. It typically binds access to a device, key, or cryptographic proof that an attacker cannot easily reuse or coerce. This approach reduces reliance on human judgment at login time.
- Authentication Assurance: The degree of confidence that an identity has been verified to the intended standard before access is granted. For MFA, assurance depends on the whole enforcement chain, including session handling, retry policy, and telemetry, not merely the presence of a code prompt.
- Hardware Token: A hardware token is a dedicated physical device used to store and protect cryptographic material such as a private key. It reduces the attack surface compared with software storage by keeping the key in tamper-resistant hardware, which helps prevent unauthorized access and misuse.
- Soft Token: A soft token is a software-based second factor, usually delivered through a phone or app, that generates a time-sensitive code for login. It avoids the need for a physical device and can be centrally managed, but it still depends on secure enrollment, device trust, and policy enforcement.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 7, 2026.
Updated on October 7, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org