Notifications
Clear all
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.
NHIMG editorial — based on content published by Axiad: An Identity Love Story: Hardware vs Software Security Tokens
By the numbers:
- 93% of organizations had two or more identity-related breaches in the past year.
- Only 5.7% of organisations have full visibility into their service accounts.
Questions worth separating out
Q: How should security teams choose between hardware tokens and software tokens for MFA?
A: Choose based on the risk profile and the user’s operating context.
Q: Why do phishing-resistant authenticators still fail in real IAM programmes?
A: They fail when organisations treat authentication as a one-time deployment instead of a governed lifecycle.
Q: How do teams know whether MFA is actually improving security?
A: Look for reduced password use, fewer successful phishing attempts, lower help desk volume for account recovery, and consistent revocation of retired authenticators.
Practitioner guidance
- Segment users by assurance requirement Assign phishing-resistant methods first to administrators, finance, and other high-risk roles, then expand based on device state, mobility needs, and support capacity.
- Standardise the strongest usable factor set Prefer FIDO or certificate-based authentication for sensitive applications, then reserve less resilient options only where compatibility or device constraints make that unavoidable.
- Govern enrollment and revocation as lifecycle work Track token issuance, renewal, and revocation through a formal process so that lost devices, expired certificates, and dormant authenticators do not remain valid.
What's in the full article
Axiad's full blog post covers the operational detail this post intentionally leaves for the source:
- Factor-by-factor comparison of hardware tokens, software tokens, FIDO, OTP, and certificate-based approaches
- Practical guidance on choosing authenticator types for shared workstations, roaming users, and endpoint-bound workers
- Step-by-step rollout sequence for pilot users, identity provider trust, and password retirement
- Unified Portal and AirLock workflow detail for token enrollment, renewal, and revocation
👉 Read Axiad's analysis of hardware and software security tokens for MFA →
Hardware vs software security tokens for stronger MFA choices?
Explore further
13/06/2026 12:30 am
Phishing-resistant authentication fails as a programme, not as a product. The article shows that stronger factors only matter when they are matched to the right use case, supported by lifecycle controls, and not undermined by password fallback. That means the real governance gap is not factor strength alone, but the absence of an authentication operating model that survives rollout, support, and recovery. Practitioners should treat MFA as a managed identity control plane, not a feature toggle.
A few things that frame the scale:
- 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, 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.
A question worth separating out:
Q: Who should own certificate-based authentication governance in an enterprise?
A: Ownership should sit across IAM, endpoint operations, and security architecture, because certificate authentication depends on identity issuance, device trust, and revocation discipline. When no team owns the full lifecycle, the control becomes fragmented and exceptions start to behave like standing access.
👉 Read our full editorial: Hardware and software security tokens: choosing stronger MFA
