Hardware and software security tokens: choosing stronger MFA

At a glance

What this is: This is a comparison of hardware and software security tokens for MFA, with the key finding that assurance and deployability depend on use case, device context, and lifecycle controls.

Why it matters: IAM and IGA teams need to treat MFA as a governed identity programme, because authenticator strength only matters when issuance, renewal, revocation, and password retirement are controlled consistently.

By the numbers:

• Introducing multi-factor authentication blocked up to 100% of automated bots, 99% of bulk phishing attacks, and 66% of targeted attacks in the study Axiad cites.
• A 2024 CyberArk report said that 93% of organizations had two or more identity-related breaches in the past year.

Context

Hardware and software security tokens are possession factors used to prove identity during authentication. The core governance problem is not whether MFA exists, but whether the authenticator choice matches the user’s device pattern, phishing exposure, and lifecycle process.

For IAM programmes, this is really a question of assurance levels, enrollment friction, and credential recovery. The article frames stronger MFA as a combination problem, where password removal, token renewal, and trust establishment between identity provider and authenticator all have to work together.

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: When should organisations prioritise stronger MFA factors over convenience-focused options?

A: Prioritise stronger factors when the resource is sensitive, the user is accessing critical systems, or the access path is exposed to higher fraud risk. Convenience matters, but it should never outweigh assurance for crown-jewel applications. Teams should reserve simpler factors for lower-risk contexts and use policy to raise assurance when posture, location, or device risk changes.

Q: What breaks when MFA token lifecycle is not governed end to end?

A: Tokens become stale access paths. Users can keep authenticating with credentials that were never renewed, were lost, or should have been revoked, and the organisation loses confidence that possession still equals authorised use. Lifecycle gaps also make password retirement difficult, which preserves weaker fallback routes.

Q: What is the difference between strong MFA and phishing-resistant MFA?

A: Strong MFA means more than one factor is used, while phishing-resistant MFA means the factor cannot be easily captured and replayed by an attacker. A code sent by text may count as MFA, but it is not resistant enough for high-risk accounts because the secret can be stolen outside the application itself. Resistance is the higher standard.

Technical breakdown

Hardware tokens vs software tokens: why assurance differs

Hardware-based tokens are physical possession factors such as security keys, smart cards, and TPM-backed authenticators. Software-based tokens are encoded credentials delivered through devices, push channels, or secure enclaves. The difference matters because hardware authenticators can provide stronger verifier impersonation resistance, while software authenticators are easier to distribute across multiple endpoints but may inherit device compromise risk. In practice, the security question is not token type alone but where the trust anchor lives and how resistant it is to phishing, replay, and device theft.

Practical implication: Choose the authenticator class that matches the required assurance level and the threat model of the user population.

Phishing-resistant MFA depends on the authenticator path

The article treats FIDO passkeys and x.509 certificates as the strongest phishing-resistant options, but not every deployment path supports them equally. Hardware tokens, TPMs, and certificate-based authentication can reduce phishing exposure because the secret is not meant to be typed into a fraudulent site. The important architectural point is that phishing resistance is a property of the full authentication flow, including the authenticator, the device, and the identity provider, not just the presence of a second factor.

Practical implication: Prioritise phishing-resistant authenticators for accounts and workflows with the highest exposure to credential theft.

Lifecycle management is part of MFA design, not an add-on

The article repeatedly ties MFA success to enrollment, issuance, revocation, and renewal. That is because possession factors create operational debt when tokens are lost, replaced, or no longer needed. A credential management system becomes the control plane for that lifecycle, especially when a programme spans hardware tokens, software tokens, and multiple identity providers. Without lifecycle governance, even strong authenticators can become stale access paths that outlive the user, device, or use case they were meant to protect.

Practical implication: Design MFA around token lifecycle workflows, including self-service renewal, revocation, and password decommissioning.

Threat narrative

Attacker objective: The attacker wants to impersonate a legitimate user and gain authenticated access to protected systems.

1. Entry occurs through phishing, where attackers try to capture credentials or session access before a stronger authenticator is in place.
2. Escalation follows when a weak or reusable factor is accepted as sufficient proof of identity, especially in password-dependent flows.
3. Impact is account takeover, because the attacker can authenticate as the user and move into applications, services, or data.

Breaches seen in the wild

• Co-op cyber attack 2025: Attackers linked to Scattered Spider tricked their way into a Co-op employee account and stole personal data of all 6.5 million members.
• Salesloft OAuth token breach: hackers stole OAuth tokens to access Salesforce data via Salesloft.

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

Authenticator choice is now a governance decision, not a user-experience preference. Hardware and software tokens create different assurance profiles, and identity teams need to treat that distinction as a control design issue. The wrong choice can leave phishing-resistant authentication partially deployed, which means the programme looks modern while still leaving high-risk accounts exposed. Practitioners should align authenticator classes to risk, not to convenience alone.

Phishing resistance is only meaningful when the whole authentication chain is resistant. FIDO passkeys and certificate-based authentication are stronger because the secret is not supposed to be disclosed to a phisher, but their value depends on the device, the identity provider, and the enrollment path. This is where many programmes drift into fragmented assurance. The practitioner conclusion is that MFA architecture has to be assessed end to end, not by factor label.

Token lifecycle is the hidden failure domain in stronger MFA programmes. Enrollment, renewal, revocation, and recovery determine whether possession factors remain trustworthy after the first login. A token that cannot be reliably issued and withdrawn becomes a governance liability, even if the underlying factor is strong. Identity teams should measure MFA maturity by lifecycle control, not by authenticator count.

Cross-platform identity programmes will keep favouring mixed authenticator models. The article shows why one factor family rarely fits every device, operating system, and application path. That creates a real policy challenge for IAM, IGA, and PAM teams: they must standardise assurance levels while tolerating multiple token types in the estate. The practitioner takeaway is to govern consistency at the control level, not force uniformity at the device level.

What this signals

Authenticator assurance now matters as much as factor count. IAM teams should stop treating MFA as a checkbox and start matching authenticator strength to the account risk they are actually trying to reduce. When the wrong factor family is used for the wrong population, organisations preserve the appearance of control while leaving phishing exposure largely intact.

Token lifecycle governance is where many stronger-MFA programmes succeed or fail. Enrollment, renewal, and revocation need the same discipline as account provisioning, because possession factors only stay trustworthy while the organisation can prove they are current. That makes MFA a governance workflow, not just an authentication feature.

For practitioners

• Define authenticator policy by use case Map user populations to the assurance level they actually need, then assign hardware or software tokens based on device mobility, phishing exposure, and application criticality.
• Prioritise phishing-resistant authentication Move sensitive accounts and high-risk workflows to FIDO or certificate-based authentication before you optimise lower-risk authentication journeys.
• Build token lifecycle governance Treat issuance, renewal, revocation, and replacement as first-class workflows, with clear ownership for each authenticator type and identity provider.
• Remove password fallback paths Disable password authentication only after alternative authenticators are enrolled, tested, and supported across the user groups that still rely on them.
• Validate roaming and device-bound scenarios Test whether users who move between machines need roaming security keys, while fixed-workstation users can safely rely on TPM-backed authenticators or certificates.

Key takeaways

• Hardware and software tokens solve different problems, so the right MFA design depends on assurance level, mobility, and device context.
• The article’s cited research and external reports reinforce that identity attacks remain common and that stronger authentication meaningfully reduces phishing exposure.
• MFA programmes need lifecycle governance, because token issuance and revocation determine whether strong authentication remains trustworthy over time.

Key terms

• Hardware Security Token: A physical possession factor used to prove identity during authentication. Hardware tokens such as security keys, smart cards, or TPM-backed devices can support stronger phishing resistance because the proof mechanism is tied to a device the user controls, not to a reusable secret typed into a login form.
• Hardware Security Token: A physical authentication device used as a second factor during login. It adds possession-based verification, but it can be inconvenient when users must carry multiple tokens or match each token to a different facility, which often creates adoption and usability problems in clinical environments.
• 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.
• Authenticator assurance level: Authenticator assurance level is a measure of how strongly an identity event proves the claimant is genuine. In NIST 800-63B, higher levels require stronger factor evidence and tighter cryptographic protections, which makes the level a practical way to map identity controls to regulated access requirements.

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.