Passkeys for SaaS in 2026: Should You Replace Passwords and MFA?

For most modern SaaS products, passkeys are worth adding now, but replacing every password and fallback mechanism on day one is usually the wrong rollout.

Passkeys use WebAuthn public-key credentials instead of a reusable shared secret. They are bound to the legitimate relying party domain, which is why NIST identifies WebAuthn as a phishing-resistant authentication method. The ecosystem is also no longer experimental: the FIDO Alliance's 2026 survey reports that 75% of surveyed consumers had enabled passkeys on at least some accounts, while 68% of surveyed organisations were deploying, piloting, or rolling them out for workforce authentication.

The harder problem is not cryptography. It is migration: account recovery, multiple devices, legacy users, enterprise policy, mobile/web consistency, and deciding when old authentication methods can safely be retired.

This guide gives SaaS product teams a practical decision framework.

What is a passkey?

A passkey is a public-key credential used to authenticate a user to a website or application.

The WebAuthn model has three important parts:

SaaS / Relying Party
        ↓
Browser or operating system
        ↓
Authenticator / credential provider

During registration, the SaaS creates a server-generated challenge and asks the authenticator to create a credential scoped to the SaaS relying party. The server stores the credential ID and public key.

The private key stays with the authenticator or credential provider.

During sign-in:

Server generates challenge
        ↓
Authenticator signs challenge
        ↓
Server verifies signature using stored public key

The user's password is not transmitted because there is no password in the passkey ceremony.

The current W3C WebAuthn Level 3 specification describes public-key credentials as scoped to a WebAuthn Relying Party, with browsers and authenticators jointly enforcing that scope.

Why are passkeys phishing-resistant?

Traditional password authentication asks the user to decide whether a login page is legitimate.

That is fragile.

A convincing fake login page can collect:

email
password
OTP

and relay those credentials to the real service.

WebAuthn changes the trust model.

NIST's current authentication guidance explains that WebAuthn provides phishing resistance through verifier name binding. The credential is bound to the legitimate relying-party identifier, such as the authenticated domain.

Conceptually:

Passkey created for:
app.example.com

Attacker hosts:
app-example-login.com

Result:
the credential for app.example.com
is not usable for the attacker's relying party

The user is no longer solely responsible for spotting the fake domain.

NIST also notes that WebAuthn's challenge-based authentication is replay-resistant because each authentication ceremony uses fresh cryptographic material.

This is the strongest argument for passkeys in a SaaS product: they remove a major class of reusable, phishable credentials.

Are passkeys actually mainstream in 2026?

They are mainstream enough to make product planning reasonable, but adoption is not universal.

The FIDO Alliance State of Passkeys 2026 report surveyed 11,000 adults across ten countries in April 2026 and reported:

• 90% were familiar with passkeys
• 75% had enabled passkeys on at least some accounts

Its separate workforce survey of 1,400 authentication decision-makers at organisations with 500 or more employees found 68% were deploying, piloting, or rolling out passkeys.

Those numbers are useful adoption evidence, but they should not be treated as proof that every SaaS audience is ready to go fully passwordless.

A B2B product used on managed enterprise laptops has a different migration profile from a consumer SaaS used across older phones, shared devices, browsers, and password managers.

The product decision still needs user-specific evidence.

Passkeys vs passwords vs MFA

The comparison is clearer when the authentication properties are separated.

Passkeys do not simply mean "MFA without an OTP".

A passkey can satisfy strong authentication properties because possession of the credential and local user verification can be combined inside the authenticator experience.

However, the exact assurance level depends on how the authenticator and relying party are configured.

For consumer SaaS, the operational question is usually less about formal assurance labels and more about whether passkeys materially reduce phishing and account takeover without creating a recovery nightmare.

Should a SaaS remove passwords immediately after adding passkeys?

Usually, no.

Google's current passkey developer guide explicitly recommends keeping existing authentication mechanisms during the transition because:

• some users remain in incompatible environments
• the ecosystem continues to evolve
• users may not yet be ready to rely exclusively on passkeys

A safer migration is progressive.

Phase 1: passkeys are optional

Password / federated sign-in
        ↓
Successful authentication
        ↓
Offer: "Create a passkey for faster, safer sign-in"

Users can keep their existing method.

Phase 2: passkey-first

For users who registered a passkey:

Sign-in screen
        ↓
Passkey suggested first
        ↓
Fallback remains available

Phase 3: stronger enforcement for selected groups

For example:

• administrators
• finance users
• organisation owners
• privileged support staff
• security-sensitive enterprise tenants

can be required to use phishing-resistant authentication before ordinary users.

Phase 4: consider password removal

Only after you understand:

• passkey adoption
• failed sign-in rate
• recovery rate
• unsupported-device population
• enterprise requirements
• support burden
• fallback attack surface

Removing passwords should be an evidence-based security decision, not a launch-day trophy.

The biggest passkey risk is often the fallback

Imagine a SaaS proudly advertises phishing-resistant passkeys but still allows this account-recovery flow:

Forgot access?
        ↓
Email reset link
        ↓
Set new password
        ↓
Account recovered

An attacker does not need to defeat WebAuthn.

They attack the weaker recovery path.

The real security posture becomes:

Account security
=
strongest daily login?
No.

Account security
=
weakest path that can regain control.

That is why recovery has to be part of passkey architecture from the beginning.

FIDO's August 2026 enterprise rollout guidance highlights enrollment, recovery, legacy applications, audit requirements and user adoption as core deployment concerns, not afterthoughts.

How should SaaS account recovery work?

There is no universal recovery mechanism, but a strong design uses multiple independent recovery options rather than one fragile bypass.

Possible mechanisms include:

• another registered passkey
• another synced device within the user's credential ecosystem
• enterprise administrator-assisted recovery
• previously enrolled hardware security key
• verified recovery email plus additional risk checks
• time-delayed recovery for high-risk accounts
• support-assisted identity verification for exceptional cases

For a B2B SaaS product, organisation administrators can be part of the recovery model.

For example:

User loses all passkeys
        ↓
Requests recovery
        ↓
Organisation admin verifies employee
        ↓
SaaS issues time-limited recovery ceremony
        ↓
User signs in
        ↓
New passkey must be enrolled
        ↓
Old credentials reviewed/revoked

That can be safer than letting anyone with inbox access reset a privileged account immediately.

Encourage more than one passkey

A user who has exactly one device-bound credential can create a support problem if that device is lost.

Passkeys may be synced by credential providers across devices, but SaaS products should not assume every user uses a synced ecosystem.

Provide a passkey-management page:

Security
  → Passkeys

MacBook Pro
Created 12 Aug 2026

iPhone
Created 12 Aug 2026

YubiKey
Created 20 Aug 2026

[ Add another passkey ]

Users should be able to:

• see registered credentials
• identify them meaningfully
• add another
• remove a lost credential
• understand the consequence of removal

Do not show only opaque credential IDs.

What does the server need to store?

A passkey implementation normally stores information associated with each public-key credential, such as:

credential_id
user_id
public_key
sign_count / authenticator data where applicable
transports or metadata where useful
created_at
last_used_at
display_label

The exact schema depends on your WebAuthn library and product.

Do not store the user's private key. The relying party should not possess it.

A simplified model might be:

create table user_passkeys (
  id uuid primary key,
  user_id uuid not null,
  credential_id bytea not null unique,
  public_key bytea not null,
  label text,
  created_at timestamptz not null,
  last_used_at timestamptz,
  revoked_at timestamptz
);

Treat this as an architecture example, not a complete WebAuthn implementation.

Credential parsing, challenge verification, origin validation, RP ID validation, algorithms and authenticator data should be handled by a maintained WebAuthn library rather than handwritten crypto.

Google's current guide specifically warns that building a passkey server from scratch can introduce security-critical bugs and recommends using established libraries or solutions.

The registration flow

A robust registration flow is approximately:

Authenticated user
        ↓
POST /passkeys/register/options
        ↓
Server creates random challenge
        ↓
Browser navigator.credentials.create()
        ↓
Authenticator creates credential
        ↓
POST /passkeys/register/verify
        ↓
Server verifies:
- challenge
- origin
- RP ID
- credential response
        ↓
Store credential public key

A critical rule is that the challenge must be generated server-side and tied to the registration attempt.

Do not accept a client-created challenge as authoritative.

The current Google developer guidance lists RP ID, user information, excluded credentials and authenticator choices among the core registration parameters.

The authentication flow

A sign-in flow is similar:

User begins sign-in
        ↓
POST /passkeys/authenticate/options
        ↓
Server generates random challenge
        ↓
navigator.credentials.get()
        ↓
Authenticator signs challenge
        ↓
POST /passkeys/authenticate/verify
        ↓
Server verifies assertion
        ↓
Create normal SaaS session

The passkey authenticates the user.

Your existing session layer can still use secure cookies, server-side session IDs, short-lived access tokens, or another deliberate session model.

Passkeys replace or augment the login ceremony. They do not replace every concept in session security.

Do passkeys replace OAuth or "Sign in with Google"?

No.

These solve different problems.

Passkey

The SaaS itself authenticates the user with a public-key credential.

Federated identity

The SaaS delegates authentication to an identity provider such as Google, Microsoft, Okta or another OIDC provider.

A product can offer both:

Continue with a passkey
Continue with Google
Continue with Microsoft

For enterprise SaaS, SSO may remain the primary requirement even if passkeys are excellent for direct accounts.

Do not remove enterprise SAML/OIDC support simply because WebAuthn exists.

What is the RP ID, and why does domain architecture matter?

WebAuthn credentials are scoped to a relying party.

For many web applications, that is related to the application's domain.

Domain architecture therefore becomes part of authentication architecture.

Suppose the SaaS operates:

app.example.com
admin.example.com
customer.example.com

You need to define which relying-party scope should be used and how each origin participates.

Do not change authentication domains casually after passkeys are deployed.

A rebrand or migration from __INLINE_CODE_0__ to __INLINE_CODE_1__ is not equivalent to changing a logo.

The credential's relying-party relationship matters.

Plan domain migrations before enforcing passwordless-only sign-in.

Multi-tenant SaaS does not necessarily need one passkey per tenant

If all tenants authenticate through one SaaS identity layer, the passkey can authenticate the user account, while tenant membership remains an authorisation concern.

Conceptually:

Passkey
→ User identity
→ SaaS session
→ Organisation memberships
→ RBAC / permissions

Authentication answers:

Who is this?

Tenant RBAC answers:

What may this user do in Organisation A?

Keep those layers separate.

Synced passkeys vs device-bound passkeys

Not every passkey has the same operational model.

Some credentials can be synced across a user's devices through a credential provider.

Others can be device-bound or stored on a hardware security key.

A consumer SaaS may prefer the convenience of syncable passkeys.

A security-sensitive enterprise may require tighter authenticator governance.

NIST's current guidance recognises syncable authenticators as capable of phishing-resistant authentication and discusses their use up to AAL2, while also requiring organisations to consider the security, privacy and UX trade-offs.

So the decision is not:

passkey = one universal security level

It is:

Which authenticator types
are appropriate for this user population?

When should a SaaS require hardware-bound authenticators?

Usually not for every consumer.

But stronger requirements can make sense for:

• platform administrators
• privileged production access
• finance approvals
• regulated enterprise tenants
• break-glass accounts
• high-risk internal staff

A product can support convenient synced passkeys for ordinary users while imposing stricter policy for privileged roles.

Passkeys do not eliminate authorisation

A successful WebAuthn assertion does not mean the user can access every tenant, export data, alter billing, or impersonate another account.

After authentication, still enforce:

• organisation membership
• RBAC/ABAC
• step-up requirements
• sensitive-operation confirmation
• session expiry
• device/session revocation
• audit logging

Authentication is the front door. Authorisation is the floor plan.

Step-up authentication is still useful

A passkey can be requested again for sensitive actions even after the user has a session.

Examples:

• change organisation owner
• export all customer data
• create API key
• disable passkeys
• change payout account
• add new administrator

For high-impact actions, require a fresh user-verifying authentication ceremony.

Do not let a long-lived browser session alone authorise the most dangerous changes.

How should mobile apps fit the same passkey account?

A SaaS with web, Android and iOS clients should share one server-side credential/account model.

Conceptually:

Web
Android
iOS
   ↓
Platform passkey APIs
   ↓
Same relying-party account
   ↓
SaaS authentication backend

For Android, Google points developers to Credential Manager.

Platform-specific integration differs, but the account identity should not fork into separate web, Android and iOS passkey identities.

A practical rollout plan for an existing SaaS

Phase 1: establish the baseline

Measure:

• successful sign-ins
• password reset rate
• MFA challenge failure
• account takeover incidents
• device/browser mix
• SSO vs password users
• login-related support tickets

Without a baseline, you cannot tell whether passkeys improved the product.

Phase 2: add passkey registration

Offer registration after a successful trusted login.

Phase 3: make passkeys visible at sign-in

Use browser/platform discovery and autofill patterns where appropriate.

Phase 4: build credential management

Users need to add, name, inspect and revoke passkeys.

Phase 5: harden recovery

Test:

• lost phone
• lost laptop
• new phone
• changed credential provider
• terminated employee
• deleted credential
• enterprise-admin recovery
• account takeover attempt

Phase 6: enforce for privileged roles

Require phishing-resistant authentication for high-impact accounts first.

Phase 7: evaluate password retirement

Use real adoption and support data.

Only remove the weaker fallback when the recovery system is at least as strong as the login system.

The metrics that actually matter

Do not measure success only by the number of passkeys created.

Track:

A migration succeeds when the product becomes safer and easier to access legitimately.

A SaaS passkey readiness checklist

Before launch:

• □WebAuthn library/provider is maintained and security-reviewed
• □RP ID and origin strategy are documented
• □server-generated challenges are short-lived and single-use
• □registration verifies challenge, origin and relying-party context
• □authentication verifies the signed assertion correctly
• □users can register more than one passkey
• □passkeys can be labelled and revoked
• □recovery does not silently fall back to a weaker single factor
• □existing auth remains available during migration
• □enterprise SSO remains supported where required
• □privileged roles can receive stricter authentication policy
• □session and authorisation controls remain separate
• □account recovery is tested like a security feature
• □domain migration implications are understood
• □mobile and web clients map to the same account model
• □adoption, recovery and fallback metrics are monitored

If the list stops at “WebAuthn works on my laptop”, the implementation is not production-ready yet.

Common mistakes

Removing passwords before recovery is mature

This turns lost-device incidents into account lockouts.

Leaving email-only recovery as an unrestricted bypass

The passkey becomes strong while recovery remains phishable.

Storing private-key material

The relying party stores the public credential data needed for verification, not the user's private key.

Writing WebAuthn crypto from scratch

Use maintained libraries and current standards.

Conflating authentication with tenant permissions

Passkeys prove identity. RBAC still decides access.

Assuming all passkeys are identical

Synced credentials, device-bound credentials and hardware security keys have different operational trade-offs.

Ignoring domain strategy

Relying-party scoping makes domain architecture part of credential architecture.

Treating fallback as harmless

Your strongest login mechanism is not your true security level if a much weaker recovery method can replace it.

When should a SaaS adopt passkeys now?

Passkeys are a strong fit when:

• phishing/account takeover is a meaningful risk
• users struggle with passwords or OTPs
• the product supports modern web/mobile platforms
• the team can build proper recovery
• privileged roles need stronger authentication
• the product has enough engineering maturity to own the authentication lifecycle, not just login UI

When should a SaaS wait before enforcing passkeys?

Delay enforcement, not necessarily support, when:

• a large user group relies on legacy environments
• account recovery is not ready
• support cannot handle lost-credential cases
• a domain migration is imminent
• enterprise customers require a different identity architecture
• mobile/web identity is fragmented
• the team is unclear about RP ID and credential ownership

Adding passkeys can still be useful while those issues are solved.

FAQs

Are passkeys safer than passwords plus SMS OTP?

Passkeys provide phishing resistance through WebAuthn's cryptographic binding to the legitimate relying party. Passwords and manually entered OTPs can still be captured and relayed by phishing sites. Exact assurance depends on authenticator configuration.

Do passkeys replace MFA?

They can replace traditional password-plus-OTP flows for many use cases because passkey authentication can combine possession of a cryptographic credential with local user verification. Formal assurance depends on authenticator and policy configuration.

Should a SaaS keep passwords after adding passkeys?

During migration, usually yes. Google's current guidance recommends retaining existing authentication mechanisms initially because compatibility and user readiness are not universal.

What happens if a user loses the device containing a passkey?

It depends on whether the credential is synced and what other authenticators are enrolled. A SaaS should support multiple passkeys and a recovery process that does not undermine the security gained from passkeys.

Can passkeys work with SSO?

Yes. Passkeys and federated identity solve different problems. A SaaS can support direct passkey authentication alongside Google, Microsoft, SAML or OIDC enterprise sign-in.

Should we build WebAuthn verification ourselves?

Usually not. Google's developer guidance warns that implementing a passkey server from scratch can introduce critical security bugs and recommends established libraries or supported solutions.

Conclusion

Passkeys are mature enough in 2026 that a SaaS product should have a deliberate position on them.

The right migration is rarely:

passwords off
passkeys on
done

A safer programme is:

Add passkeys
        ↓
Make them easy to discover
        ↓
Support multiple credentials
        ↓
Harden recovery
        ↓
Enforce for privileged users
        ↓
Measure fallback usage
        ↓
Retire weaker methods when evidence supports it

The cryptography is only one part of the work.

The real product architecture includes credential lifecycle, recovery, devices, domains, SSO, sessions, authorisation and support operations.

If those pieces are designed together, passkeys can meaningfully reduce phishing risk while making everyday sign-in simpler.

If the fallback paths are ignored, the system may simply move its weakest link somewhere less visible.

If you are designing authentication for a new SaaS or modernising an existing login system, Softotic's custom software development service can handle the backend identity architecture, while web application development can integrate passkeys and account-management flows into the product.

Sources and references

• W3C: Web Authentication Level 3 Candidate Recommendation
• NIST SP 800-63B: Authenticators and phishing resistance
• Google for Developers: Passkeys developer guide for relying parties
• FIDO Alliance: The State of Passkeys 2026
• FIDO Alliance: Enterprise Passkeys rollout webinar, August 2026