Skip to content
Adoption guide

Introduce passkey sign-in around the people who use your application.

Moving beyond passwords involves more than adding another sign-in button. Users need an authenticator they can use, a clear enrolment experience and a way to recover access when their circumstances change.

← All scenarios and guides

ProAuth supports passkey sign-in for UserStore accounts. You choose where to enable it and plan adoption around your application's audience and operating requirements.

A deliberate path to adoption
  1. Enable

    Configure passkeys for the user store

  2. Enrol

    Register supported authenticators

  3. Validate

    Exercise sign-in and recovery

  4. Expand

    Broaden adoption using the pilot findings

An adoption pattern for available passkey sign-in. Enabling passkeys does not delete password credentials. Recovery and enforcement depend on installed version and configuration.

Start with the sign-in experience

Users can register supported platform authenticators, security keys or synced passkeys and sign in without entering a password. Account Management provides registration, naming and removal of login passkeys.

Passkey registration is bound to the ProAuth relying-party domain. Plan that identity endpoint as part of your long-term deployment, including any hosting move. Device and browser support should be checked with representative users.

Decide how passwords remain available

Enabling passkeys does not remove existing passwords. The current documented enforcement option can require users who already have a registered passkey to use passkey sign-in; users without one retain password sign-in.

Introducing passkey sign-in and permanently deleting password credentials are different changes. Choose a rollout that your users and support organisation can operate, and verify the controls available in your installed version.

Make recovery part of adoption

Consider lost devices, device replacement, shared-workstation use and access to synced authenticators. A second registered authenticator can provide another sign-in option, but it is not a complete recovery procedure.

Define how users establish their identity during recovery, what administrators may do and how sensitive changes are communicated. Validate those procedures before requiring users to rely on passkeys. The availability and enforcement of recovery controls depend on the deployed version and configuration.

The next step

Evaluate the approach in your project.

Pilot with representative users and devices. Review enrolment, routine sign-in, device loss and support escalation before broadening adoption.

Discuss your passwordless rollout