Passkeys for B2B SaaS: A Migration Playbook

Why B2B Is the Right Early Target

• Phishing resistance matters more. B2B targets are where most identity attacks originate; passkeys directly defeat the phishing vector.
• User base is smaller and more trainable. Compared to a consumer rollout, B2B users can be onboarded with support rather than helpdesk tickets.
• Enterprise admins can force adoption. Tenants can be configured to require passkey enrollment, with managed recovery paths.
• Cyber-insurance incentives. Insurers increasingly price phishing-resistant MFA favourably.

Stage 1. Additive Rollout

Do not start by replacing passwords. Start by letting users add a passkey alongside their existing login. Low-risk, low-pressure, and generates enrollment data you can use to justify the next stage.

// Server-side registration options (using @simplewebauthn/server)
import { generateRegistrationOptions, verifyRegistrationResponse } from '@simplewebauthn/server';

export async function passkeyRegisterOptions(userId: string) {
  const user = await prisma.user.findUnique({ where: { id: userId } });
  const options = await generateRegistrationOptions({
    rpID: 'app.technspire.com',
    rpName: 'Technspire App',
    userID: new TextEncoder().encode(user.id),
    userName: user.email,
    userDisplayName: user.name,
    attestationType: 'none',                  // B2B: raise to 'direct' for attested devices
    authenticatorSelection: {
      residentKey: 'required',                // discoverable credential
      userVerification: 'required',
    },
  });
  await prisma.webauthnChallenge.create({ data: { userId, challenge: options.challenge } });
  return options;
}

Stage 2. Conditional Mediation

Conditional mediation (the autofill experience) is the single biggest UX win. On the login page, request a passkey assertion in conditional mode; if the user has one for this origin, the browser offers it as an autofill option alongside the password fields. Users discover the passkey experience organically.

// Client-side — conditional mediation on the login page
const isSupported = await PublicKeyCredential.isConditionalMediationAvailable?.();

if (isSupported) {
  const options = await fetch('/api/auth/passkey/options').then(r => r.json());
  const assertion = await navigator.credentials.get({
    publicKey: options,
    mediation: 'conditional',        // blends with autofill
    signal: abortController.signal,
  });
  if (assertion) await fetch('/api/auth/passkey/verify', { /* ... */ });
}

Stage 3. Passkey-Preferred Login

Once enrollment rates cross a target threshold (30–50% is realistic within a quarter of active promotion), move the UI to lead with passkey sign-in and push password sign-in to a secondary option. Measure drop-off carefully; do not strand users in the process.

Stage 4. Passkey-Required for Admins

Start enforcement at the admin tier. Workspace owners, billing admins, and security admins should not be able to sign in with password-only authentication. The enforcement UI should be tenant-configurable so IT admins can set the policy for their own org.

Account Recovery. The Hardest Part

Passkeys are bound to devices or password managers. If a user loses both, they need a recovery path that does not reintroduce the phishing vulnerability passkeys were meant to solve. The working patterns:

• Multiple passkeys per account. Encourage users to register a platform authenticator and a hardware security key. If one is lost, the other still works.
• Tenant-admin recovery. For B2B, the admin can reset a user's authenticators. This delegates the recovery risk to the tenant, which is appropriate for most B2B models.
• Time-gated recovery. An out-of-band recovery (e.g. support-verified identity) that introduces a cooling-off period before the account is fully usable.
• Hardware-token issuance. For high-assurance accounts, ship a hardware token as part of the employee onboarding kit.

Device Attestation for Enterprise

B2B tenants that want to verify which authenticators their users are using. For example, to require a FIDO-certified hardware token. Can request attestation during registration. This is a configurable per-tenant setting in mature B2B SaaS; the default of attestation: 'none' is right for most tenants, but enterprise customers may require 'direct' and an allowlist of authenticator AAGUIDs.

The Failure Modes Still Worth Planning For

• Cross-device sign-in. Users starting on one device and completing on another (QR code hybrid). UX is good in 2026; still worth QA-ing on the browsers your customers actually use.
• Platform vs roaming authenticators. A passkey synced through iCloud or Google Password Manager does not migrate to a user's new Windows laptop without some work.
• Corporate restrictions on password managers. Some enterprise environments disable platform syncing. Users there need hardware keys.
• Legacy integrations. Anything that uses a password in an API client (for LDAP bridges, legacy SSO, IMAP) does not benefit. Scope them to app-password flows explicitly and audit.

The Short Rollout Plan

1. Ship additive enrollment behind a feature flag. Let passkey-curious users opt in.
2. Turn on conditional mediation. Measure organic adoption.
3. Move passkeys to the primary sign-in option for enrolled users.
4. Require passkeys for admin roles.
5. Offer tenant-level enforcement toggles. Let customers lead the way.
6. Plan a multi-year tail for legacy password-only holdouts. Do not fight the last 5% at the expense of the first 95%.