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.

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 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:

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.

Passkey events — added, renamed, removed, a successful or failed sign-in, and rate limiting — appear in the audit log and can be delivered as 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.

Last verified 2026-11-01.