What you'll learn: how to design, build, and roll out passkeys (FIDO2/WebAuthn credentials) for SaaS web and mobile in July 2026—without breaking SSO, admin policy, or recovery. This is for SaaS engineers, product managers, and security leads who want an actionable plan that balances usability, security, and enterprise requirements.

Who this is for: product and engineering teams running multi-tenant SaaS platforms, identity architects, and security owners deciding when and how to remove passwords without creating new operational risk.

Quick context: passkeys replace passwords with public-key cryptography managed by a user’s device or cloud credential store. Major platforms (Apple, Google, Microsoft), identity providers (IdPs such as Okta, Azure AD, Google Workspace), and all major browser vendors support passkeys and related UX patterns. Adoption accelerated through 2024–2025 and into 2026: vendors are shipping enterprise controls, attestation metadata services have matured, and tenancy features like SCIM-based offboarding are now expected.

Prerequisites and context: what you should have before you start

Passkeys touch identity, UX, privacy, and IT policy. Before you code, align these four things:

  1. Know your login inventory: catalog current methods (email/password, social logins, SAML/OpenID Connect (OIDC) SSO, API tokens, hardware keys, legacy OAuth logins). This determines whether passkeys will be an add-on, a replacement for passwords, or a step-up.

  2. Decide the initial user story: start with passkeys as opt-in credential management inside account settings. For July 2026, many teams default new sign-ups to passkey-first while keeping constrained fallback for legacy users—deploy in stages.

  3. Pick build vs buy: you can implement WebAuthn APIs and platform SDKs, or use an IdP/authN-as-a-service. By mid‑2026, most major IdPs offer passkey-first workflows and attestation policy controls—buying reduces integration risk; building gives fine-grained control.

  4. Agree a recovery stance: decide whether recovery uses constrained password/email fallback, recovery codes, admin-assisted recovery, or enforced multiple-credential registration. Document this for support and sales teams.

Why this matters now (July 2026): passkeys are mainstream phishing‑resistant credentials. Enterprise customers increasingly require them for admin and billing roles, regulators and security agencies continue to recommend phishing‑resistant MFA, and users expect smooth cross-device sign-ins. But passkeys are not a panacea: endpoint compromise, social-engineering recovery, and session theft still matter. Your product choices determine whether security improves in practice.

Step 1: Choose your passkey model and enterprise policies

Decide these policy knobs before engineering starts:

  1. Synced (platform-managed) vs device-bound (hardware keys):

    • Synced passkeys (cloud-synced through Apple iCloud Keychain, Google Password Manager, Microsoft Authenticator) give the best consumer UX: lower lockout risk and cross-device continuity.
    • Device-bound / roaming hardware keys (USB/NFC/Bluetooth devices such as YubiKey) provide higher assurance and avoid third‑party cloud sync—favored in regulated environments.

    Why it matters: synced credentials trade device‑level control for UX. Enterprises often require device-bound credentials or enterprise attestation for high-value roles.

  2. Tenant admin controls: provide toggles for:

    • Enable/disable passkeys per tenant
    • Require phishing‑resistant MFA for sensitive roles
    • Enforce attestation rules (allow/disallow cloud‑synced credentials, require enterprise attestation)
    • SCIM hooks for offboarding (automated removal of credentials on user termination)

  3. Recovery policy: define guardrails now—don’t leave recovery to ad hoc support. Options in 2026 commonly include:

    • Encourage registering at least two passkeys during onboarding
    • Provide single‑use recovery codes or recovery tokens stored client-side
    • Admin-assisted recovery workflows with auditable multi-party approval for business accounts
    • Escrow-like solutions for enterprise: sealed backup keys or hardware token escrow managed under tenant policy

Step 2: Map the core flows (registration, authentication, linking)

Map these journeys in detail. Capture error states, telemetry points, and timeouts.

1) Registration (create a passkey)

  1. User is authenticated already (session, verified invitation, or short-lived linking token).
  2. User clicks “Add passkey.”
  3. Server creates a per-request cryptographic challenge and returns registration options (relying party ID, user ID, user verification requirement, attestation preference).
  4. Client calls WebAuthn or platform SDK to create a credential; user confirms with biometric/PIN or inserts a hardware key.
  5. Server verifies attestation, stores credential ID, public key, signature counter, attestation metadata, friendly name, and last-used timestamp.

Why verify attestation? Attestation reveals if a key is hardware-backed (TPM/secure enclave) or a roaming key and supports enterprise policy enforcement. Choose which attestation formats you accept and document privacy trade-offs for customers.

2) Authentication (sign in with a passkey)

  1. User provides an identifier (email) or uses discoverable credentials to start sign-in.
  2. Server generates an assertion challenge, potentially including relying-party-provided session info, and sends it to the client.
  3. Client prompts the user (biometric/PIN) and returns a signed assertion.
  4. Server validates signature, checks signature counter and attestation metadata, and completes login. Consider token binding (DPoP or MTLS) and short-lived refresh tokens to reduce session replay risk.

Why signature counters? They provide a signal to detect cloned credentials; combine them with device/session management and anomalous behavior detection for stronger protection.

3) Account linking

  • Always link new passkeys to an authenticated user account. Do not auto-create accounts on passkey-only sign-in unless you have robust linking (invitation tokens, verified email, admin confirmation).
  • For discoverable credentials (which allow sign-in without typing an email), require server-side checks (rate limits, device fingerprinting, and additional verification) to prevent account duplication and abuse.

Step 3: Implement WebAuthn on the web (what to build and what to store)

  1. Set RP ID to your apex domain so credentials are scoped to your site and can’t be used on lookalike domains.

  2. Use per-request, short-lived challenges generated server-side. Store in-memory or in a secure cache and expire within minutes.

  3. Store minimal, useful data:

    • Internal user ID
    • Credential ID
    • Public key and algorithm
    • Signature counter
    • Attestation metadata (format, device model when attested)
    • Friendly name, registered-on and last-used timestamps

    Do not store private keys.

  4. Verify everything server-side: challenge, origin (HTTPS + domain), RP ID hash, signature, and user verification requirements.

  5. Support discoverable credentials carefully: they improve UX but require abuse and rate‑limit protections because sign-in can start without an identifier.

Privacy reassurance to communicate: biometric matching happens locally; the backend receives only cryptographic assertions. Publish a clear data handling statement on what attestation metadata you retain. In 2026, customers expect explicit documentation on attestation storage and retention.

Step 4: Implement passkeys on mobile (iOS & Android)

Mobile is often the best UX for passkeys—if you avoid common pitfalls.

  1. Prefer system browser or native platform APIs: embedded web views (WKWebView, Android WebView) still cause origin and credential manager inconsistencies. Use the system browser or native platform passkey APIs where possible.

  2. Support cross-device flows: users will start on desktop and approve on mobile. Implement QR-code approval, push-based handoff, or platform cross-device transfer. Ensure clear timeouts and retry guidance.

  3. Test real-world edge cases: multiple accounts on one device, enterprise MDM policies blocking credential sync, captive portals, offline-first needs, and biometric-disabled fallback to PIN.

Pro tip: test on the exact device+OS+MDM combos your customers use. “Works on my phone” is not good enough.

Step 5: Design recovery and fallback that doesn’t reintroduce password risk

Recovery is decisive. A secure recovery plan prevents support teams from reverting to passwords as a quick fix.

  1. Encourage multiple credentials: during onboarding, prompt users to register a second passkey (phone + laptop) and provide a clear UI for naming and revoking keys.

  2. Constrain password/email fallback: if you keep fallback, combine it with strong step-up checks—risk signals, geo/IP checks, time-based throttles, and out-of-band verification—so fallback isn't the attackers’ weakest link.

  3. Offer auditable, support-assisted recovery: for tenant-owned accounts require admin approval and documented verification steps; for consumer accounts offer single-use recovery codes that users securely store.

  4. Log and notify: log every credential creation, revocation, and recovery attempt. Notify account owners and tenant admins and include a cooling-off period for destructive operations like account deletion or credential revocation.

  5. Automate offboarding: integrate SCIM or IDP-based user lifecycle events to remove credentials when an employee leaves—critical in enterprise deployments to avoid orphaned access.

Remember: easier recovery increases social-engineering risk. Make recovery usable but auditable.

Step 6: Integrate with SSO and tenant security controls

Enterprise customers expect centralized policy. Your passkey support must respect IdP controls and tenant policy.

  1. Respect enforced SAML/OIDC SSO: if a tenant requires SSO, don’t let users bypass the IdP unless tenant admins opt in and understand attestation/offboarding trade-offs.

  2. Use passkeys as step-up in SSO sessions: allow IdP for primary auth and require passkeys for high-risk actions: billing changes, API key creation, or data export. This pattern reduces IdP integration complexity while raising security for sensitive flows.

  3. Expose admin policy controls: let tenant admins configure passkey requirements, attestation rules, offboarding behavior, and monitoring thresholds. Integrate logs with SIEM via standard formats (e.g., syslog, CEF).

Step 7: Roll out safely (metrics, comms, staged enforcement)

Successful rollouts are instrumented and incremental.

  1. Start opt-in, measure aggressively: capture these metrics:

    • Passkey creation success rate by platform and browser
    • Authentication success rate and median time-to-sign-in
    • Drop-off points (prompt shown → canceled → fallback)
    • Support tickets and recovery events by tenant
    • Number of active passkeys per user and average credentials-per-user

  2. Segment rollout: internal-only → small beta customers → larger customers → tenant-by-tenant enforcement. Treat managed-device tenants separately (MDM can block sync/attestation).

  3. Clear in-product education: short copy explaining what passkeys do, why biometrics aren’t shared, and why users should register a second device. Use microcopy and tooltips during onboarding.

  4. Selective enforcement: require passkeys or equivalent phishing-resistant MFA only for roles and flows that materially reduce risk—don’t force everyone day one.

Common mistakes (and how to avoid them)

  • Assuming passkeys remove all risk: they reduce phishing and credential stuffing but don’t eliminate endpoint compromise, session theft, or social-engineered recovery. Combine passkeys with session controls and device checks.
  • No recovery plan: if users get locked out, support will fall back to passwords. Define recovery flows before launch and train support with scripted verification steps and audit trails.
  • Breaking SSO guarantees: allow tenants to opt out of direct passkey sign-in if they require IdP enforcement. Document behavior clearly for administrators.
  • Under-instrumenting: if you don’t capture platform/version failure rates and discoverable vs non-discoverable flows, you can’t fix real-world problems.
  • Using embedded webviews carelessly: many mobile passkey issues stem from webviews. Prefer native or system browser flows.

Pro tips

  • Require recent authentication for credential management: treat adding/removing passkeys like changing a lock—confirm presence with a step-up.
  • Allow users to name and revoke keys: “Work MacBook,” “Personal Pixel.” Show last-used timestamps to help detect suspicious use.
  • Pair passkeys with short-lived tokens and token binding: use DPoP or MTLS and short-lived refresh tokens to minimize damage if a session is stolen.
  • Use risk-based step-ups: prompt for passkey re-authentication on IP/geofence anomalies or when accessing secrets.
  • Document tenant policy knobs: admins should know exactly how passkeys interact with SSO, device offboarding, and recovery.

Operational checklist (quick ship list)

  1. Inventory logins and identify candidate cohorts for passkey rollout.
  2. Decide recovery policy and document support playbooks.
  3. Implement WebAuthn registration and assertion endpoints with per-request challenges.
  4. Store only public keys, counters, attestation metadata, and friendly names.
  5. Expose tenant controls: enable/disable, enforcement per role, attestation preferences, SCIM offboarding.
  6. Instrument metrics and plan staged rollout with beta tenants and internal pilot.

FAQ

Are passkeys the same as MFA (multi-factor authentication)?

No. MFA means two or more factors from categories like something you know, have, or are. A passkey is a cryptographic credential (public/private keypair) stored on a device or cloud credential store and typically unlocked by something you are (biometric) or know (PIN). Organizations often treat passkeys as a strong primary factor and may require an additional factor for especially sensitive operations.

Will passkeys work with enterprise SSO (SAML/OIDC)?

Yes. The common enterprise pattern keeps the IdP (SAML/OIDC) for primary authentication and uses passkeys for step-up inside the application for high-risk actions. If a tenant wants passkeys for direct sign-in to the application, offer that only with explicit tenant opt-in and clear policy around attestation and offboarding.

What if a user loses all their devices in 2026?

That’s a recovery problem, not a cryptography problem. Best practices: encourage multiple registered passkeys, provide single-use recovery codes, support admin-assisted auditable recovery for business accounts, and integrate SCIM offboarding. Train support to follow documented identity-verification steps so recovery is consistent and defensible.

Do you store biometric data on your servers?

No. WebAuthn/passkey implementations perform biometric matching locally on the device. Your server receives signed cryptographic assertions; it never stores fingerprints or face templates.

When should we remove passwords entirely?

Only after proving recovery, support readiness, and enterprise controls across a representative customer set. A safer path: opt-in → default for new users → selective enforcement for critical roles → broader removal for cohorts where recovery and support metrics are solid.

Editorial note: standards and platform behavior evolve. Test passkey flows across real customer environments (OS versions, MDM policies, and IdPs) before enforcement. The engineering details are manageable; product decisions and recovery rules determine success.

Final analogy: passkeys are like swapping fragile shared door codes for cryptographic locks that respond only to approved keys. That doesn’t stop a burglar who bribes your locksmith (poor recovery), but it does stop most break‑ins—phishing and password reuse—cold. Build with that defensive posture in mind, instrument aggressively, and treat recovery like hardened vault procedures—not a quick customer support trick.