# Passkeys

Let your users sign in with a passkey instead of typing a password, and use a
passkey as their second factor. Your tenant's hosted pages run every step:
adding a passkey, signing in with one, and answering the two-step challenge with
one. Passkeys are included on every plan.

This page explains what a passkey is, why it protects accounts better than a
password or a six-digit code, the concerns people raise about passkeys and how
Udibo handles each one, and then how to turn passkeys on.

## What a passkey is

A passkey is a pair of keys created for one website. The private key stays with
the person — in a password manager, their phone or computer's keychain, or a
hardware security key. The website keeps only the public key, which can check a
signature but cannot make one.

To sign in, your tenant's sign-in page sends a one-time challenge, the person's
device signs it with the private key, and Udibo checks the signature. The device
usually asks the person to unlock it first, with a fingerprint, their face, or a
PIN. That unlock happens on the device; Udibo never receives a fingerprint, a
face scan, or the PIN.

Passkeys come in two broad kinds, and Udibo accepts both:

- **Synced passkeys** live in a password manager or platform keychain and follow
  the person to their other signed-in devices. Losing one phone does not lose
  the passkey.
- **Device-bound passkeys** live on one hardware security key or one device and
  never leave it. They suit people who want a key they can hold, and they need a
  backup.

## Why passkeys resist phishing

A password or a code from an authenticator app is a secret the person types. A
convincing lookalike page can ask for it and pass it to the real site in real
time, along with the code, and take over the session. Phishing kits that do
exactly this are common.

A passkey is bound to the site it was created for. The browser offers it only
on that site and puts the page's address into what the device signs, so a
lookalike page has nothing to collect and nothing it can relay. The person does
not have to spot the fake for this protection to work.

Two more properties help: Udibo stores no secret that a database leak would
expose, because a public key is not a credential, and every passkey is unique to
one site, so a breach somewhere else reveals nothing about your tenant.

## Common concerns, and how Udibo handles them

Passkeys draw real criticism. Most of it is about choices a website makes
rather than about the cryptography, so here is what Udibo chooses.

**"A website could refuse my password manager or my operating system."** The
WebAuthn standard lets a site ask the authenticator to prove its make and model
— called attestation — and a site could use that to accept only approved
hardware. Udibo never asks for attestation and keeps no list of approved
authenticators. Any passkey manager, any operating system, and any FIDO2
security key works.

**"If I lose my phone, I lose my account."** Each person can register up to 25
passkeys — one per device, a backup security key, a passkey in a second
password manager — and remove any of them. Adding a passkey never removes their
password, email sign-in, social sign-in, or recovery codes. Udibo refuses to
remove a person's last way in, and an administrator can remove a lost passkey
for them.

**"I'm locked into one company's ecosystem."** Choose a passkey manager that
runs on all your devices, or register a passkey in each ecosystem you use.
Many managers can now move passkeys between each other, and most browsers can
sign in on a computer using a passkey on a nearby phone by scanning a QR code.

**"Which account did that just sign me into?"** When the sign-in page asks for
a passkey without a username, the browser lists the passkeys you saved for that
site and you pick one. Udibo's request names no accounts, so it reveals nothing
about who has one there, and after sign-in the hosted pages show which account
you are signed in to.

**"Sites force passkeys on people."** Udibo never makes anyone create a passkey
and shows no prompt to add one during sign-in. A person adds one deliberately
from their account's security page.

**"Keeping a password means the account can still be phished."** That is true.
A passkey protects the sign-ins that use it, and an account is only as strong
as the weakest method it still accepts. Udibo keeps each person's existing
methods so a lost passkey is never a lost account; removing an account's
password is not available today. The strongest setup today is passkeys on more
than one device plus two-step sign-in, so a stolen password alone is not enough.

**"Biometrics can be used without my consent."** The passkey manager decides how
it unlocks. Most let you use a PIN or device password instead of a fingerprint
or face, and Udibo accepts either.

## How passkeys fit with two-step sign-in

A passkey can be the first sign-in step, and it can answer the two-step
challenge after another first step.

| How the person signs in                               | What happens next                                                                                       |
| ----------------------------------------------------- | ------------------------------------------------------------------------------------------------------- |
| Passkey, unlocked with a fingerprint, face, or PIN    | Signed in. The passkey is already two factors — the device, and the unlock — so no further step.       |
| Passkey without an unlock (some security keys)        | Treated like a password: the two-step challenge runs as it would after one, without a passkey option.  |
| Password, email sign-in, or social sign-in            | The two-step challenge offers **Use a passkey**, plus the authenticator app and recovery codes if the person set them up. |

Adding a passkey does not turn on two-step sign-in by itself under the
**Optional** policy: someone who adds a passkey for convenience keeps signing in
with their password the way they did before. Under **Required**, a person who
has a passkey counts as enrolled and is not made to add an authenticator app.
The exception is a security key without a PIN that is also their only factor:
signing in with it proves one factor, so they are asked to set up an
authenticator app as the second.
See the [MFA guide](https://www.udibo.com/docs/identity/mfa) for the policies.

## Turn passkeys on

In your tenant's dashboard, open **Security → Sign-in methods**, select
**Passkeys**, and choose **Save sign-in methods**. Passkeys are off until you
turn them on, and at least one other sign-in method stays enabled: people need
another way to create an account and to recover one.

Turning passkeys off hides the passkey button, refuses passkey sign-in, and
stops new passkeys from being added. Passkeys people already registered still
answer the two-step challenge, so changing the setting never strands a person's
second factor.

## Where your users meet passkeys

All three steps happen on your tenant's own host, `https://{tenantId}.udibo.com`.

**Adding a passkey.** On the account's `/security` page, under **Passkeys**, the
person chooses **Add a passkey**, confirms it's them the same way they would
before adding an authenticator app, and follows their device's prompt. The page
lists each passkey with its name, whether it is synced or tied to one device,
when it was added, and when it was last used, with **Rename** and **Remove**. Removing a passkey asks
for the same confirmation as adding one — the current password, an
authenticator code, or, for an account that has neither, signing in again or
confirming by email. If the
passkey was on a lost or stolen device, the page offers **Sign out other
sessions** afterwards, so a session already open on that device ends too. The
account's verified email address gets a notice whenever a passkey is added or
removed.

**Signing in.** The sign-in page shows **Sign in with a passkey**, and browsers
that support passkey autofill also offer saved passkeys when the person focuses
the email or username field.

**The two-step challenge.** After a password, email, or social sign-in, the
challenge page offers **Use a passkey** when the person has one.

Passkeys need JavaScript and a browser that supports WebAuthn, which current
versions of Chrome, Edge, Firefox, and Safari do. Without them, the passkey controls do not appear and
every other method works as before.

## Which address a passkey belongs to

A passkey belongs to the exact host it was created on. Your users' passkeys
belong to `{tenantId}.udibo.com`, so password managers list them under that
address. A passkey made on one host cannot be used on another, which keeps every
tenant's passkeys separate from every other tenant's.

Custom domains for hosted pages are not available yet. When they are, passkeys
made on your tenant host will keep working there; people may need to add a
passkey for the new domain to use one on it.

## Removing a user's passkey

When someone loses a device, open their page in the dashboard: **Users** → the
person → **Passkeys**, and choose **Remove** beside the lost passkey. This
requires **Manage users**, which the built-in Owner and Admin roles carry.
Removing a passkey also signs the person out of your tenant everywhere, like a
two-step reset, so a lost device holding an open session is cut off too. Their
other passkeys and sign-in methods are unaffected. Udibo refuses the removal when
it would leave the account with no way to sign in.

## What your application sees

Your application's integration does not change: it still redirects to the hosted
sign-in page and receives the same tokens. The authentication claims describe a
passkey sign-in:

| Sign-in                                     | `acr`               | `amr`                  |
| ------------------------------------------- | ------------------- | ---------------------- |
| Passkey, unlocked on the device             | `urn:udibo:acr:mfa` | `["pop", "mfa"]`       |
| Passkey without an unlock                   | `urn:udibo:acr:pwd` | `["pop"]`              |
| Password, then a passkey for two-step       | `urn:udibo:acr:mfa` | `["pwd", "pop", "mfa"]` |

`pop` means proof of possession of a key. Udibo does not claim `hwk` (a
hardware-held key) because, without attestation, it cannot tell a security key
from a synced passkey. An application that asks for
`acr_values=urn:udibo:acr:mfa` accepts a passkey sign-in like any other second
factor; see
[request fresh authentication](https://www.udibo.com/docs/identity/applications#request-fresh-authentication).

Passkey events — added, renamed, removed, a successful or failed sign-in, and
rate limiting — appear in the [audit log](https://www.udibo.com/docs/identity/audit-log)
and can be delivered as [webhooks](https://www.udibo.com/docs/identity/webhooks).

## Limits

- Up to 25 passkeys per person.
- A new account is created with another method; adding a passkey comes after.
- An account's password cannot be removed today.
- Applications cannot yet ask specifically for a phishing-resistant sign-in.

If your application owns its login instead of using Udibo's hosted pages, the
open-source `@udibo/oauth2` package offers the same passkey ceremonies; see
[add passkeys](https://www.udibo.com/docs/oauth2/guides/add-passkeys).

_Last verified 2026-11-01._