Passkeys vs magic linkswhich should your SaaS ship in 2026?

We shipped both. We measured both. I want to tell you what we actually found, because the online discourse on this topic is almost entirely vibes and very little data.

kavachOS supports passkeys and magic links as first-class auth methods. For the first four months of the cloud product, we tracked signup completion rates, support ticket frequency, and enterprise objections for both methods across our own user base. This post summarizes what we learned and gives you a framework for deciding which to prioritize for your product.

Magic links are the simpler concept. The user enters their email. You send a one-time link. They click it from their inbox and land in a session. No password ever exists. Delivery depends on email infrastructure you do not control. Security depends on inbox access, which is usually well-protected but is not the user's device.

Passkeys are a WebAuthn credential anchored to a device. The user registers a passkey on their laptop or phone. The private key never leaves the device. Authentication is a biometric or PIN gesture. There is no email in the loop. The credential is phishing-resistant by construction because it is bound to your exact origin.

Magic links completed signup at 74% on desktop and 68% on mobile. The gap is explained by email app switching friction on mobile: users start signup in a browser, receive the link in a native mail app, tap it, and sometimes land in a different browser with no active session. This is solvable with cross-device session handoff, but it requires extra engineering.

Passkeys completed at 61% overall. Lower absolute rate, but the variance is very different. Desktop Safari: 81%. Chrome on Android: 79%. The failures concentrated in two places: older Windows machines without Windows Hello set up, and corporate devices where MDM blocked platform authenticators. The 19% failure rate on those machines is real. If your users are primarily on managed corporate laptops, passkey completion rates are lower than you expect.

Account recovery is where passkeys hurt most. A magic link user who loses their device still has their email. They request a new magic link, click it from any device, done.

A passkey user who loses the device their passkey is stored on cannot authenticate without a fallback. iCloud Keychain and Google Password Manager sync passkeys across devices, which helps a lot. But enterprise users on managed devices frequently cannot use those sync services. A user locked to a device-bound passkey on a stolen laptop has no path back in without admin intervention or a fallback method.

We saw 3x more support tickets from passkey users related to account recovery in the first three months. All of them were on managed enterprise hardware. The fix is requiring a fallback method at registration. More on that in the decision framework below.

Passkeys win this one completely. A WebAuthn credential is bound to the exact origin it was registered on. A credential registered at app.kavachos.com cannot be used on a phishing clone at app-kavachos.com. The browser checks the origin at the protocol level. There is no user action that makes this fail.

Magic links can be phished. An attacker who sends a convincing fake email that redirects through their domain before passing the token to the real site can intercept the session. It requires a more sophisticated attack than a password phish, but it is possible. If your users handle sensitive data and you have a threat model that includes targeted attacks, this matters.

Enterprise security teams have opinions about both methods. For magic links, the concern is email channel: corporate email is a shared-responsibility surface and magic links create a short-lived credential in the inbox. Most enterprises accept this for internal tooling.

For passkeys, MDM policy is the blocker. Some enterprises configure managed devices to block platform authenticators, either for policy reasons or because they want all auth to flow through a company-managed identity provider. If you are selling to enterprise, expect to also ship SAML integration as the actual enterprise auth method. Passkeys are supplementary for enterprise, not primary.

Ship both. This is not a hedge. It is what the data supports.

If your product targets consumers or small teams on modern hardware, make passkeys the default and magic links the fallback. You get better security properties for the majority of users and a reliable escape hatch for the rest.

If your product targets enterprise from day one, make magic links the default and passkeys an optional upgrade. You will need SAML for SSO regardless, so magic links serve the pre-SSO setup flow. Passkeys work well for admin accounts that sit outside the corporate identity provider.

G

Gagan Deep Singh

@gdsingh

The real answer to passkeys vs magic links is that neither is the answer alone. Ship both, let users pick. Defaults matter more than the technology choice.

The Next.js adapter guide covers the WebAuthn ceremony in detail, including session management token format and rotation policy.