Passkeys for B2B SaaS: How They Work, SSO Coexistence and Rollout

A passkey is a phishing-resistant replacement for a password. It's a cryptographic key pair created on the user's device: the private key stays with the user, protected by Face ID, a fingerprint, or a device PIN, and your app stores only the public key. Passkeys are built on the FIDO2 standards (WebAuthn and CTAP) and are supported in all major browsers and operating systems.

In a B2B SaaS product, signing in with a passkey is the easy part. The harder questions are about who you offer passkeys to, how they work alongside your customers' SSO, and what happens when a user loses their device.

In short: passkeys fit best for the users who don't sign in through their company's SSO.

How passkeys work

1. Registration. The user's device creates a new key pair for your domain. Your server receives and stores the public key and a credential ID. There's no shared secret to leak.
2. Sign-in. Your server sends a random challenge. The user unlocks the passkey with a biometric or PIN, and the device signs the challenge with the private key.
3. Verification. Your server checks the signature with the stored public key. If it matches, the user is in.

The browser only offers a passkey to the domain it was created for. That's why a phishing page can't collect one, and why a stolen database of public keys is useless to an attacker.

Under the hood, passkeys use WebAuthn, the browser API, and CTAP, the protocol between the browser and an authenticator such as a phone or security key. For a deeper look at the protocols, see our guide to passwordless authentication with FIDO2 and WebAuthn.

Signing in from another device

If a user's passkey is on their phone and they're signing in on a laptop, the laptop shows a QR code. The user scans it with the phone, which confirms over Bluetooth that the two devices are close together, then approves the sign-in on the phone. Bluetooth only checks that the devices are close; the sign-in data travels over an encrypted internet connection. Both devices need Bluetooth turned on.

Synced vs device-bound passkeys

There are two kinds of passkeys, and the difference matters more in B2B than in consumer apps.

NIST's final digital identity guidelines (SP 800-63-4, August 2025) accept synced passkeys at AAL2. They rule them out for AAL3 because the key can be exported to other devices.

Passkeys vs other sign-in methods

A passkey that asks for a biometric or PIN is a multi-factor authenticator under NIST SP 800-63B-4: the device is something you have, and the biometric or PIN is something you are or know.

Passkeys and SSO: who should use which

In B2B SaaS, many of your users already sign in through their company's identity provider, such as Okta or Microsoft Entra ID, with SSO. For those users, the identity provider handles authentication, including whatever MFA or passkey policy your customer's IT team sets. Adding a second passkey in your own app would create a sign-in path that bypasses their policy.

Passkeys are most useful for everyone else:

• Self-serve and trial users who sign up with an email address.
• Customers on plans without SSO, often smaller teams.
• External users, such as contractors or a customer's own clients, who aren't in the company's identity provider.
• Customer admin accounts and other high-privilege users, where phishing resistance matters most.

A good rule: if a tenant enforces SSO, send those users to their identity provider. For everyone else, offer passkeys as the main sign-in method and keep a fallback.

How to roll out passkeys in a B2B app

1. Offer passkeys after a successful sign-in. Prompt users to create a passkey right after they sign in the usual way, when they've just proven who they are. Don't ask on every visit if they decline.
2. Keep passwords during the transition. Run passkeys alongside existing sign-in methods until most active users have one. Then consider letting tenants turn passwords off.
3. Plan account recovery first. Recovery is where passkey security is won or lost. If a user can replace a lost passkey with only an email link, an attacker can too. Require a second factor, an admin approval, or an identity check before registering a new passkey.
4. Let tenant admins set policy. Enterprise customers will ask whether passkeys are allowed, required, or limited to device-bound authenticators. Make this a per-tenant setting.
5. Handle shared devices. On shared workstations or kiosks, users shouldn't save a passkey to the device. Offer sign-in from a phone with the QR code instead, which needs Bluetooth on the workstation.
6. Measure adoption. Track how many users create passkeys, how many sign-ins use them, and how many recovery requests you get.

Passkeys with Frontegg

Frontegg supports passkeys as a sign-in option in its hosted login, alongside passwords, magic links, social login, and SSO.

• Enable it in the builder. Turn on the Passkeys toggle in the login box settings. After that, users are prompted to create a passkey the next time they sign in.
• Self-service management. Users manage their passkeys from the Privacy & Security page of Frontegg's self-service portal.
• Requires SMS or authenticator-app MFA. You can't turn on passkeys until one of these is set up as an MFA option.
• Set up a custom domain first. Passkeys are tied to a domain, so Frontegg recommends a custom domain before you enable them in production.
• One passkey per device. Each user can currently register one passkey per device.
• Respects SSO. Users who sign in through SSO currently aren't offered passkeys, so their identity provider stays in control.
• On every plan. Passkeys are included on all plans, including the free Pay as you go plan.

Frontegg also supports FIDO2 security keys and built-in authenticators such as Touch ID and Windows Hello as MFA methods. See the passkeys documentation for setup details and SDK versions.

FAQ

Are passkeys a form of MFA?

A passkey combines possession (the device holding the private key) with a biometric or PIN that unlocks it, so a single passkey sign-in covers two factors. Whether it counts as MFA for a specific compliance requirement depends on the framework. NIST SP 800-63B-4 accepts synced passkeys at AAL2, its multi-factor level, when the passkey requires a biometric or PIN.

Can passkeys replace SSO?

No. SSO lets a company control access to all its apps from one identity provider, and passkeys don't do that. In B2B apps, passkeys and SSO serve different users: SSO for companies that have an identity provider, passkeys for everyone else.

What happens if a user loses the device with their passkey?

Synced passkeys: the user signs in from another device. Device-bound passkeys: the user needs a backup credential or account recovery that asks for more than an email link.

Do passkeys work across devices and platforms?

Yes. Synced passkeys are available on all devices signed in to the same passkey provider. On a device that doesn't have the passkey, the user can scan a QR code with a phone that does.

Are passkeys the same as FIDO2?

Passkeys are FIDO2 credentials: FIDO2 is the standard, a passkey is the credential users create. See FIDO vs FIDO2 for how the standards evolved.