Zitadel passkeys and passwordless login

The first design decision is which user journeys the rollout must support, because each one creates a different path through the login system. The core set is first registration, adding a second passkey, removing a lost device, and recovering access when a user has neither a passkey nor a password. Write these as numbered flows with a named actor, a trigger, the screens shown and the audit record produced. Then confirm in the Zitadel passkeys documentation for your target version which registration points exist: at sign-up, after a successful password login, or from an account settings page. The product docs should also state which authenticator types are offered during registration and whether a user can register more than one passkey. Do not assume these details from older guides or community posts.

Next, decide who performs registration. Self-service lets users enroll and remove their own passkeys, which scales well for customer identity where no help desk exists for every end user. Administrator-assisted registration suits workforce users in high-assurance roles, where an administrator verifies identity before a credential is bound. Most organizations split the two: customers self-enroll, while privileged staff enroll through a controlled process. Check in the Zitadel documentation whether administrators can register passkeys on behalf of a user, and whether a user can be forced to register at next login. Those answers determine whether the policy can be enforced in the product or must be handled by process.

Self-service and auditability pull in opposite directions. Letting users add and remove passkeys themselves reduces tickets, but a compromised session could then bind a new attacker-controlled credential without anyone noticing. Keeping an audit trail of every credential change, and reviewing it, adds operational work but gives security teams the evidence they need after an incident. Decide which events must be logged and retained, who reviews them, and whether a credential change should notify the user by a channel other than the one just used. Confirm in the Zitadel documentation which events are recorded and how they can be exported to your logging platform, since the answer determines whether the trail is usable in practice.

The recovery path causes more help desk load than any other part of a passkey rollout, so it must be designed and tested before launch. Users who lose a phone, reset a device or never finished registration will need a way back in. Define the fallback explicitly: whether the password remains available, whether another registered factor can be used, or whether an administrator must verify identity and reset the account. Each option needs a security owner and a documented verification step. A useful test is to run the lost-device journey end to end with a test account and time how many steps an administrator must take. If the answer is always a ticket, the process needs redesign before go-live.

Finally, plan for the user who has no passkey and no password, which can happen after a policy change or a migrated account. Decide whether such accounts are locked out, prompted to set a credential at next sign-in, or routed through a verified reset. Confirm in the product docs whether password fallback can be disabled per organization, since customer and workforce users often need different answers. Record the decisions in a journey matrix that lists each flow, the role allowed to perform it, the audit event it produces and the owner of any manual step. That matrix becomes the acceptance test for the rollout and the basis for training the help desk.

Passkey testing should prove two things before go-live: that every sign-in path your users actually take works, and that every path that should be blocked is blocked. Build the test plan from your user base, not from the default Zitadel login flow alone. List the device and browser classes your customers and workforce use, such as managed corporate laptops, personal phones, shared kiosks and any browser your support desk still receives tickets about. For each class, run registration from the self-service flow and sign-in with the passkey, then record the platform authenticator, browser version and result. Confirm this against the passkey and password login settings in the instance or organization you are testing, because the policy decides which steps appear to the user.

Next, test the fallback and recovery paths as first-class cases. Remove the passkey from a test account, or sign in on a device without it, and confirm that password login works where your policy allows it, and fails where it does not. Then simulate loss of the only registered device. Walk through the recovery route your policy defines, whether that is re-registration through a verified channel, an administrator reset or a second registered authenticator, and confirm that the route cannot be used by someone who only knows the username. Ask your Zitadel administrators to document who can approve a reset and how that approval is logged. Confirm the exact recovery options in your version's documentation, since they change between releases.

The negative tests carry most of the security value. Attempt sign-in from a hostname that does not match the relying party ID configured for passkeys, and confirm the browser refuses the ceremony and nothing is accepted. Create a test user who has not registered a passkey while your policy requires one, and confirm the login is stopped or redirected to registration rather than silently falling back to a weaker method. Disable the passkey policy for a test organization and then try every other login path that could reach the same application, including older client configurations, direct API calls to the session endpoints and any identity provider federation. Each path should either be disabled or enforce the same rules. For each failure, record exactly what the user sees: the error message, whether the page reveals whether the account exists, and whether a retry loop or lockout occurs. An illustrative check is an account that gets a generic error on a wrong hostname but a detailed message on a missing passkey, which leaks account state and should be corrected.

Regression testing is needed after every Zitadel upgrade and after every change to an application's login configuration, including a new redirect URI, a changed client type or a new custom login step. Keep the test suite fixed so that results can be compared across runs, and automate the parts that do not need a human at a device. Run the full device matrix at least before each production upgrade, because browser and operating system behavior around passkeys changes independently of Zitadel. Store each run's date, Zitadel version, tester, configuration snapshot and pass or fail result. Those records are useful evidence for your own compliance reviews of authentication controls, but they are your team's internal records. They do not replace an audit or certification, and an independent assessor will decide what they accept. Confirm with your assessor which artifacts they expect before you design the retention process.

The first review after passkeys go live should answer one question: are users actually moving off passwords, and where are they getting stuck? Track passkey registration rates by user population, by organization, and by the point in the flow where people enroll. A low registration rate in one customer organization often points to a prompt that appears at the wrong moment, a policy that requires enrollment before users understand why, or an identity provider federation that bypasses the local login screen entirely. Pair registration numbers with sign-in failures broken down by device class, such as desktop platform authenticators, mobile devices, and roaming hardware security keys. Failures that cluster on one browser or operating system usually indicate a configuration or client issue rather than user error. Confirm with your Zitadel version's documentation which events and logs record passkey registration and assertion outcomes, since the fields and log destinations are the foundation for every metric in this list.

Password fallback use and help desk recovery tickets are the two signals that tell you whether passwordless login is working for real users. Measure how often sign-ins complete with a password after a passkey is registered, because a steady fallback rate means users either lack a passkey on the device they are using or the fallback path is easier than the passkey path. Log every recovery ticket with a reason code, such as lost device, new device without a registered passkey, or account lockout, and review the trend weekly during the first months. Each recurring reason points to a specific decision: whether to require a second registered credential, whether to tighten or relax fallback for certain populations, or whether the self-service recovery steps need clearer wording. Record each change to login policy with a date, the approver, and the reason, so that a rise in tickets can be traced to the change that caused it.

Several items must be backed up and recorded alongside the PostgreSQL database. The database holds users, credentials and events, but the instance configuration and policy settings that govern passkeys, password fallback and organization-level login behavior should also be exported or recorded in version control, using the Zitadel configuration and API tooling your team has chosen. Keep the timing consistent: take the configuration export at the same point as the database backup, or record the change history so that you can reconstruct which policy was active at any given time. A restore that brings back users and credentials under a different login policy than the one they registered under can produce confusing failures. Test a restore into a non-production environment and confirm that passkey sign-in works afterward, since a backup that is not verified does not reduce recovery risk.

Documentation should be short enough that someone can use it during an incident. Maintain a record of policy decisions covering which populations must use passkeys, whether password fallback remains enabled, how second factors apply, and the reasoning behind each choice, so that future administrators do not reverse them without understanding the trade-offs. Write recovery procedures for lost devices, locked accounts and administrator-assisted re-enrollment, including who may approve a recovery and how identity is verified before it is granted. Name an owner for each customer or internal organization who is accountable for its login policy, its help desk escalation path and its contact for policy changes. Finally, keep a set of test cases covering registration, passkey sign-in, fallback, recovery and federated login for each organization, and rerun them after every Zitadel upgrade. Upgrade sequencing, support coverage and the mechanics of testing database migrations are covered in the Zitadel upgrades and support topic.