Security teams should treat passkeys as the stronger default because the private key stays on the user’s device and authentication is tied to that device, not an inbox or phone number. Magic links are useful as a fallback, but they inherit email and SMS risks. The best approach is to offer passkeys first, then keep a recovery path for edge cases where the primary device is unavailable.
Why Passkeys Usually Beat Magic Links for Sign-In
Passkeys bind authentication to a device-held private key, so the secret never has to travel through email, SMS, or a copy-and-paste login code. That changes the trust boundary in a meaningful way: the user proves possession of a cryptographic authenticator instead of relying on a message delivery path that can be intercepted, forwarded, or delayed. For most modern sign-in flows, that is the cleaner primary path.
Magic links can still be useful, but they are inherently transport-dependent. If the email account, inbox session, or phone number is exposed, the login path is exposed with it. They also add friction around message delivery, resend loops, and support cases when mail filtering or device switching gets in the way. Teams should treat them as a convenience mechanism, not the strongest assurance option.
From a security design perspective, the real question is not which method is newer. It is which method gives you the strongest practical assurance at the lowest operational burden. Passkeys usually win because they reduce shared-secret handling and eliminate the need to treat the inbox or phone network as part of the authentication ceremony. That is why passkeys are the better default when the product and user base can support them.
How to Set the Default and Keep a Safe Fallback
Security teams should make passkeys the preferred path wherever possible, then define a fallback that is deliberately narrower in scope. The fallback should exist for device loss, account recovery, unsupported platforms, and migration periods, but it should not silently become the main authentication method through poor UX or repeated exceptions. If users start relying on magic links for routine access, the intended assurance level has already eroded.
A good policy separates passkey-first sign-in from recovery and account restoration. That means teams should decide in advance which journeys require stronger verification, which can use a temporary fallback, and when a fallback should expire. Recovery is part of the design, but it should be bounded by time, scope, and monitoring.
Implementation details matter. If magic links are allowed, they should be short-lived, single-use, and tied to a clearly controlled channel. If the fallback can authenticate to sensitive actions, it needs the same scrutiny as any other authentication method, because it becomes part of the attack surface rather than just a convenience feature.
What Should Drive the Final Choice in Practice
The decision should be based on assurance, usability, and support burden together. Passkeys are strongest when you want phishing-resistant sign-in, lower credential reuse risk, and better resistance to inbox compromise. Magic links can still be reasonable for low-risk access, first-time onboarding, or recovery flows where the user may not yet have enrolled a passkey.
Teams should also consider who is using the system and how often they move between devices. A consumer app with frequent device changes may need a gentler enrollment path than an internal workforce portal, but that does not change the security hierarchy. It only changes the rollout strategy. The secure pattern is still to push users toward the strongest available authenticator and keep the weaker option limited to exceptional cases.
For standards-based guidance on phishing-resistant authentication and authenticator assurance, see NIST SP 800-63 Digital Identity Guidelines. For teams implementing modern sign-in flows, the protocol layer also matters, especially where session establishment or federated login is involved, and OpenID Connect Core 1.0 remains the common reference point.
Risk and Threat Considerations
Magic links shift risk into the delivery channel, so compromise of email, phone number, forwarding rules, inbox session state, or message interception can become a direct login path. Passkeys reduce that exposure, but poor recovery design can reintroduce the same weakness through help desk resets or overly permissive fallback rules.
Failure mechanism: Attackers target the weakest step in the authentication chain, usually message delivery, account recovery, or session reuse, and then use that path to bypass the intended authenticator.
Impact: Account takeover becomes easier, phishing resistance drops, and the organisation may end up protecting a strong primary factor with a weak secondary process that negates the benefit.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while NIST SP 800-63, OWASP ASVS and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | Digital Identity Guidelines | Phishing-resistant authentication and authenticator assurance directly govern passkeys vs magic links. |
| Recommendation — Use phishing-resistant authenticators as the preferred sign-in path and reserve weaker methods for limited recovery. | ||
| OWASP ASVS | V6 — Authentication | The question is about choosing stronger sign-in methods and recovery paths. |
| Recommendation — Require stronger authenticators for primary sign-in and tightly control fallback authentication. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Passkeys and magic links both depend on managing authenticators and their lifecycle safely. |
| IA-2 — Identification and Authentication (Organizational Users) | The choice affects how users are identified and authenticated into the system. | |
| Recommendation — Manage authenticator issuance, use, rotation, and invalidation so fallback methods stay bounded. Select the strongest feasible user authentication method for the required assurance level. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | Weak sign-in flows and recovery links can become authentication bypass paths. |
| Recommendation — Prevent authentication bypass by making recovery links single-use and short-lived. | ||
Practitioner Guidance
What to prioritise: Treat passkey enrollment as the default success state and make the fallback path visibly temporary. If users are signing in repeatedly without ever enrolling a passkey, the rollout is failing even if logins still work.
What to verify: Confirm that recovery flows cannot be abused to bypass stronger authentication for privileged actions. If a magic link can reach the same privilege level as a passkey without extra checks, the design is too permissive.
Practitioner takeaway: Use passkeys to set the assurance baseline, then constrain magic links to bounded recovery and edge cases so convenience does not become the system’s weakest trust path.
Related resources from NHI Mgmt Group
- How should security teams decide between hardware security keys and passkeys for different user groups?
- How should security teams decide between browser extensions, remote browser isolation, and an enterprise browser for modern workforces?
- How should security teams decide between SIEM, SOAR, and XDR in a modern SOC stack?
- How should security teams design sign-in flows that work across passwords, passkeys, 2FA, social logins, and managed apps?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 25, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
