Capability
Passkeys
What it does: Sign-in does not rely on a reusable password an attacker can steal, phish or stuff.
In short
Passkeys let customers sign in with a key stored on their own device instead of a password. The key is tied to your site, so a fake site gets nothing it can reuse. Auth0 database connections support passkeys.1
Related capabilities
- Phishing-resistant MFA
- Breached passwords
- Bot detection
What it is, and the attacks it stops
A password is a shared secret - the customer knows it, your system stores a version of it, and an attacker can try to get it from either side. Customers also tend to reuse the same password across many services.
A passkey works differently. Device-bound passkeys keep the private key on the customer's device, and the device uses it only for the site it was created for.1
NIS2 Article 21(2)(j) lists the use of multi-factor authentication or continuous authentication solutions among the cybersecurity risk-management measures, where appropriate.5
Removing the reusable password stops attacks such as:
Credential phishing
A fake login page collects the password the customer types. With a passkey there is no password to type, so the fake page has nothing it can replay.
Credential stuffing
Attackers try passwords leaked from other services against your login. A passkey sign-in has no password for them to try.
Password reuse
A customer uses the same password on your service and on a smaller site that gets breached. A passkey is created for your site only, so there is nothing to carry over.
Password spraying and guessing
Attackers try common passwords across many accounts. Accounts that sign in with passkeys give them no password to guess.
Leaked password databases
A breach of a password store exposes customer secrets. A passkey system stores a public key, which does not let an attacker sign in with just a password.
Before and after rollout
How Auth0 does it
Auth0 supports passkeys on database connections, and you can add WebAuthn security keys as an MFA factor.
The customer starts a sign-in
The customer opens the sign-in page of your application, which is served by Auth0.4
The customer picks a passkey
Instead of typing a password, the customer chooses to sign in with a passkey.1
The device confirms the customer is present
The device signs the request with the private key. The customer confirms on the device, for example with a biometric or a PIN.1
Auth0 verifies and signs the customer in
Auth0 checks the signed response against the passkey registered for the account and completes the sign-in.1
Fake site
Real Auth0 sign-in
How Zelto implements it
The technology behind Auth0 is the ready and proven half - Zelto plans how your customers move from passwords to passkeys. We roll out in stages to minimize risk/impact for sign-up, sign-in and support. We also keep a recovery path that attackers cannot talk their way into.
Typical rollout
Map how customers sign in today
We list your applications, connections, sign-in methods and the devices your customers use.
Decide where passkeys fit
We choose which customer journeys offer passkeys first, and whether passkeys replace the password or sit next to it. We use Auth0 database connections for this.
Pilot with a small customer group
We start with a limited group or a single application. Before wider use, we agree on an owner on your side. We also agree when to expand and when to roll back.
Prepare support and recovery
We write the recovery steps for a lost or replaced device. Your support team gets a script for the questions customers will ask.
Expand and reduce password use
We encourage passkey enrollment and reduce reliance on passwords as much as possible. We review fallback methods on a schedule.
Pitfalls we plan for
A customer loses the phone that holds their passkey.
−Let the customer back in with an email link or SMS code that anyone with access to the inbox or SIM can use.
+Offer a recovery process that checks who the customer is, and ask them to register a new passkey afterwards.
Customers sign in from several devices and browsers.
−Offer a passkey on the first device only, so customers fall back to the password on every other device.
+Prompt customers to add a passkey on each device they use, and test the journey on the browsers and devices they actually have.
Passkeys are added next to existing passwords.
−Keep passwords fully active forever, so attackers continue to target the password route.
+Reduce password use over time as passkey enrollment grows, and review the remaining exceptions on a schedule.
Customers are asked to create a passkey without explanation.
−Show a technical prompt that customers dismiss, and then they never enroll.
+Explain in one plain sentence why and when to create a passkey, and offer it at a moment when the customer has just signed in successfully.
A passkey syncs to every device on the customer's cloud account.
−Treat synced passkeys as unphishable in every scenario, although anyone with the cloud account can register the same passkey elsewhere.
+Decide which customer journeys allow synced passkeys, require a second factor where the risk is higher, and keep a recovery path that does not rely on email or SMS alone.
Want customers to sign in without passwords and without a rollout that stalls?
We review how your customers sign in today. Then we tell you where passkeys fit first.
Book a call30 minutes, no slides. We look at how your customers sign in today.Related blog posts
Notes from rollouts
Sources
Official Okta and Auth0 documentation and primary legal sources.
- 1Passkeys in Auth0 database connectionsAuth0 Docs
- 2Configure WebAuthn security keys as an MFA factorAuth0 Docs
- 3Multi-factor authenticationAuth0 Docs
- 4Auth0 Universal LoginAuth0 Docs
- 5Directive (EU) 2022/2555 (NIS2)EUR-Lex