Should Your Customer Portal Support Passkeys?

Passkeys keep coming up as the thing that's finally going to kill the password. Apple, Google and Microsoft have all pushed them hard, and if you've logged into a consumer app recently you've probably been offered one. If you're planning a customer portal or internal tool, it's a reasonable question to ask: should I build this in?

The honest answer is it depends on who's logging in and what happens when something goes wrong, not on whether passkeys are the future. Here's what I think about when a client raises it.

What a passkey actually is

A passkey is a cryptographic key pair generated on a device. The private key never leaves the device (or the user's synced keychain), and the public key sits on your server. Instead of typing a password, the user approves a login with their fingerprint, face or device PIN. There's nothing to type, nothing to phish in the traditional sense, and nothing stored on your server that's useful to a thief if your database leaks.

That's a genuinely good security story. The problem isn't the cryptography. It's everything around it.

Where it gets complicated

A password has one failure mode: the user forgets it, and you send a reset link to their email. A passkey has several, and none of them are as simple.

• Device loss. If a passkey isn't synced (some aren't, depending on platform and browser), losing the device means losing the credential. You need a fallback login path anyway.
• Platform lock-in. Apple, Google and Microsoft each sync passkeys through their own ecosystem. A user who switches from an iPhone to an Android phone, or logs in from a work laptop that isn't tied to their personal account, can hit a wall that a password never would.
• Shared and switching devices. If your users are tradespeople sharing a work tablet, or staff logging into a till or kiosk, passkeys tied to one person's biometrics don't fit the way the device actually gets used.
• Support load. Every one of the above eventually becomes a support ticket. "I can't log in" used to mean "reset my password". Now it can mean half a dozen different things, and you need a recovery path for each of them.

None of this means passkeys are a bad idea. It means they're an addition to your authentication, not a replacement, at least for now. You still need a fallback: email magic link, password plus two-factor, or an admin-assisted reset. Passkeys become one more door into the account, not the only one.

When they're genuinely worth building

I'd build passkey support in for a product where:

• Users log in from their own personal device, consistently, and mostly on modern phones or laptops.
• The account holds something sensitive enough that phishing resistance actually matters, like financial data, health records or admin access to other people's accounts.
• You're already planning to support a password fallback and don't mind the extra UI and testing effort passkeys bring.

That describes a lot of consumer apps and some B2B SaaS products. It doesn't describe most internal tools, where a handful of named staff log in from company laptops that already sit behind SSO, a VPN or a locked-down network. For that kind of system, the risk passkeys solve is already covered by something else, and the extra complexity doesn't buy you much.

What I'd actually recommend for most bespoke builds

For the majority of client portals and internal tools I build, solid password handling plus optional two-factor authentication still does the job. It's well understood, every library supports it properly, and the recovery flow is simple enough that a user can sort it out themselves without a support call. If the client already uses Google Workspace or Microsoft 365 internally, wiring up single sign-on through that is usually a better investment than passkeys, because it removes passwords for staff without adding a new recovery problem.

Where I will reach for passkeys is on a customer-facing product with a large, security-conscious user base where phishing is a real threat, and where I have the time to build a proper fallback path alongside it. That's a deliberate decision made early, not something bolted on because a library made it easy.

The decision belongs earlier than you'd think

Authentication choices are one of those things that are cheap to get right at the start of a build and expensive to change once real users have accounts. If you're putting a project brief together, it's worth deciding up front who's logging in, from what kind of device, and what happens when access is lost, rather than leaving it as a line that says "login with email and password" and hoping it sorts itself out. My guide to what belongs in a software development brief covers this alongside the other decisions that are easy to skip but hard to unwind later.

Passkeys aren't a trap exactly. They're a tool that solves a specific problem well and creates a different, less familiar one in its place. The question isn't whether they're the future. It's whether the problem they solve is actually the one your users have.