Topic starter
12/06/2026 10:01 pm
TL;DR: Phishing-resistant authentication depends on the right factor mix, device context, and lifecycle management, according to Axiad, with NIST cited as support for certificate-based approaches. The practical lesson is that stronger authentication only works when enrollment, revocation, and password removal are governed end to end.
Editorial analysis by NHI Mgmt Group, based on content published by Axiad: “An Identity Love Story: Hardware vs Software Security Tokens”.
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.
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.
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.
Q: What breaks when MFA token lifecycle is not governed end to end?
A: Tokens become stale access paths.
Practitioner guidance
- 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.
Bottom line: Hardware and software tokens solve different problems, so the right MFA design depends on assurance level, mobility, and device context.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
13/06/2026 12:30 am
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.
A question worth separating out:
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.
👉 Read our full editorial: Hardware and software security tokens: choosing stronger MFA