Security teams should treat passkeys as a strong default for many user authentication flows because they remove shared secrets from the login process and work with modern browsers and devices. They are easier to deploy than hardware tokens and safer than security questions or SMS, but they still depend on device protection and recovery design. The right choice balances phishing resistance, usability, and operational support.
How to compare passkeys with older authentication factors
Passkeys should be evaluated against the job they are meant to do, which is proving the user is present and in control of a trusted authenticator with as little phishing exposure as possible. They also change the operational burden: setup, recovery, device changes, help desk handling, and compatibility across browsers, platforms, and account types.
That makes the real comparison less about “which factor is strongest” and more about which factor produces the best balance of resistance, usability, and support overhead for the specific flow. For many consumer and employee sign-ins, passkeys are now the strongest default because they avoid reusable shared secrets and reduce the chance of credential reuse or phishing capture.
Security questions and SMS are weak comparison points because they rely on knowledge or telephone-based recovery signals that are easier to intercept, guess, or socially engineer. Hardware tokens are stronger than those options, but they introduce issuance, loss, replacement, and inventory overhead that passkeys can often reduce when the user already has a protected device and a viable recovery path.
Where passkeys are stronger, and where they are not
Passkeys are strongest when the main concern is phishing resistance. The authenticator binds the login to the site origin, which makes credential replay on fake sites much harder than with passwords, security questions, or SMS codes. They also remove the need for users to remember or transport a shared secret, which reduces help desk resets and secret reuse across services.
Hardware tokens still matter when you need a dedicated, portable second factor that is independent of the user’s primary device. That can be useful for high assurance environments, shared workstations, regulated access paths, or recovery scenarios where device-bound passkeys are not yet sufficient. In practice, teams should distinguish between stronger authentication and stronger operational resilience, because those are not always the same thing.
Security questions should generally be treated as legacy recovery, not a modern primary authenticator. Their answers are often discoverable, guessable, or reusable across services. SMS is better than no second factor, but it is still exposed to SIM swap, number recycling, interception, and mobile account takeover risks, so it is usually a fallback rather than a preferred control.
Risk and Threat Considerations
Authentication choice affects both takeover risk and recovery abuse. The biggest failure mode with passkeys is not the cryptographic login itself, but weak device protection or a recovery process that lets an attacker bypass the stronger factor through support channels, synced accounts, or degraded fallback methods.
Failure mechanism: If device access, account recovery, or help desk verification is weaker than the passkey flow, an attacker can still enroll a new authenticator, hijack a synced credential set, or exploit a fallback path such as SMS or knowledge-based recovery.
Impact: The organisation may gain a phishing-resistant primary login while still leaving a practical account-takeover path open, which is why the recovery design must be judged as part of the authentication system, not as an afterthought.
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 address the attack and risk surface, while NIST SP 800-63, CIS Controls v8, NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | IAL/AAL/FAL — Identity Assurance, Authenticator Assurance, Federation Assurance | Passkeys, tokens, SMS, and recovery design all affect authenticator assurance. |
| Recommendation — Choose the authenticator and recovery path that meets the required assurance level. | ||
| CIS Controls v8 | 5 — Account Management | Authentication factor choice is inseparable from account lifecycle and recovery handling. |
| 6 — Access Control Management | Comparing factors requires enforcing the right control for each access path and role. | |
| Recommendation — Standardise account and recovery handling so weak fallback paths do not bypass stronger authentication. Apply role-appropriate access controls and avoid using weak factors for higher-risk access. | ||
| NIST CSF 2.0 | PR.AC — Identity Management, Authentication and Access Control | The question is fundamentally about choosing authentication methods that shape access risk. |
| Recommendation — Select authentication methods that reduce phishing exposure and align with access risk. | ||
| NIST Zero Trust (SP 800-207) | 4.1 — Access Control Policy Enforcement Point | Passkeys fit a Zero Trust approach by strengthening access enforcement at login. |
| Recommendation — Enforce stronger authentication at the access decision point and limit trust in reusable secrets. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Secrets and Credential Exposure | The comparison includes moving away from reusable secrets and toward stronger authenticators. |
| NHI-04 — Overprivileged and Excessive Access | Authentication strength only matters if recovery and fallback do not create excessive access. | |
| Recommendation — Reduce reliance on reusable secrets and prefer phishing-resistant authenticators where possible. Limit fallback and recovery paths so they cannot create broader access than the primary authenticator. | ||
Practitioner Guidance
What to prioritise: Use passkeys as the default for most user authentication flows, then decide whether a hardware token is still required for the highest-risk roles, privileged access, or environments with strict device separation requirements. Treat security questions as a last-resort recovery mechanism only, and SMS as a transitional or limited fallback rather than a preferred control.
What to verify: Confirm that recovery enrollment, device replacement, and account rescue steps are as hard to abuse as the passkey login itself. If users can bypass the stronger factor through weak identity proofing, the deployment is not materially safer than the legacy design it replaced.
Practitioner takeaway: The best comparison is not “passkeys versus tokens” in the abstract, it is whether the full authentication and recovery path is phishing-resistant, supportable, and hard to subvert under real user-loss conditions.
Related resources from NHI Mgmt Group
- How should security teams manage passkeys and hardware tokens in highly regulated or on-premises environments?
- How should security teams decide between hardware security keys and passkeys for different user groups?
- How should security teams evaluate hardware-backed digital signatures for passkeys and AI agent workflows?
- How should security teams evaluate whether passwordless authentication will actually improve user adoption and reduce friction?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
