Why rolling out passkeys to customers is a migration, not a feature toggle
A team that runs customer login on self-hosted identity usually wants one outcome: fewer account takeovers caused by stolen or reused passwords, without locking out the customers who depend on the current login. Passkeys for customer login can deliver that, and both Keycloak and ZITADEL support passkeys based on WebAuthn and FIDO2 with password fallback. That means the platform choice matters less than three decisions: how the rollout is staged and controlled, how a customer recovers an account without a help desk call, and where the identity data and its audit trail physically live. Those decisions are the work, and they are what this section sets up for the rest of the page.
Regulations do not settle the credential question for you. The HIPAA Security Rule at 45 CFR 164.312 requires unique user identification, audit controls and person or entity authentication, and the FTC Safeguards Rule at 16 CFR 314.4 requires multi-factor authentication for any individual accessing an information system. Neither names a credential type. Passkeys are therefore an evidence-friendly option: they can be documented as a strong authentication factor, tied to a unique account, and logged, but they do not replace the need to show how each control operates. Confirm with your assessor and legal counsel how your passkey enrollment, fallback and recovery events will be recorded before you describe passkeys as a compliance control.
Treat the rollout as a migration with a measurable end state. Before enabling passkeys for the whole customer base, decide which accounts can enroll first, which fallback methods stay active, and what adoption and failed-login figures will justify removing passwords for each segment. Keycloak's server administration guide documents W3C WebAuthn, passkeys with conditional and modal UI, and recovery codes, and the ZITADEL passkeys documentation describes password fallback, so check how each version and your login theme behave on the browsers and devices your customers actually use. Ask your implementation partner to put those checks, and the rollback plan, in the written scope.
What the rollout must satisfy and what each requirement means for the build
This table maps the regulatory requirements most likely to touch customer login to specific passkey and identity design choices on self-hosted Keycloak or ZITADEL. Read each row as a design question: what the rule asks for, what the build must do, and what evidence to prepare. The main takeaway is that a passkey supports a compliance requirement only as configured, so confirm the factor mapping with your assessor before removing any fallback.
| Requirement | What the build must do | Evidence to prepare |
|---|---|---|
| Multi-factor authentication (16 CFR 314.4(c)) | Require MFA for any individual reaching a customer information system, including fallback paths. A passkey counts only when the realm or instance enforces it as a required factor. | Authentication flow configuration export, factor policy by client, and test results for password-only attempts |
| Unique user identification (45 CFR 164.312) | Bind each passkey credential to one account identifier. Block shared or reused accounts and prevent enrollment against an identifier the user does not control. | Account model, enrollment verification steps, and sample credential-to-user mapping |
| Person or entity authentication (45 CFR 164.312) | Confirm the user's identity at passkey enrollment and at each later login, and keep the login factor set separate from recovery paths. | Enrollment procedure, factor list per flow, and assessor sign-off on which factors qualify |
| Encryption in transit | Serve login, enrollment and recovery pages only over TLS. Confirm that WebAuthn ceremonies run on an origin bound to the relying party ID. | TLS configuration, certificate inventory, and hostname and relying party ID settings |
| Encryption at rest | Encrypt the production database that stores accounts, credential records and recovery data. Confirm the chosen PostgreSQL deployment supports this in your environment. | Storage encryption settings, key management ownership, and backup encryption records |
| Logging of authenticated activity | Log enrollments, passkey logins, fallback password logins, recovery requests and credential removals with timestamp and account identifier. Send logs to a system the security team reviews. | Sample audit events, retention settings, and a list of event types covered |
| Account recovery must not weaken authentication | Require the same or stronger assurance for recovery as for login. Avoid recovery by email link alone when that link would grant a new passkey without a second check. | Written recovery policy, test cases showing blocked downgrade paths, and step-up rules |
| Passkey fallback during transition | Keep password login only as long as the rule set allows. Record which accounts still use a password so the fallback can be retired on evidence. | Adoption report by factor, fallback usage trend, and a documented decision to remove or keep passwords |
Keycloak or ZITADEL: which fits your passkey rollout
If you already run Keycloak with realms, user federation to LDAP or Active Directory, and established clients, adding passkeys is usually an extension of work you have already done. Keycloak's server administration guide documents W3C WebAuthn support, passkeys with both conditional and modal UI, recovery codes, and an Organizations feature for managing member organizations and their domains. Keycloak is licensed under Apache-2.0, which many internal platform teams find straightforward to review.
- Realm-level changes: Passkey policy is set per realm, so you can pilot in a test realm before touching production customer realms.
- Federation stays in place: Existing LDAP or Active Directory federation continues to work while customers enroll passkeys in Keycloak.
- Recovery codes: Confirm which recovery options your support process can honor before you retire passwords.
- Organizations feature: Review whether it covers your B2B domain model or whether you need a separate tenancy design.
- Database and upgrades: Confirm your supported production database and your upgrade approach, since Keycloak migrates schemas automatically at startup by default.
Before committing, check that your current Keycloak version includes the passkey and Organizations capabilities you plan to use, and test them against your own client applications.
If you are building a new customer identity layer for many tenants, ZITADEL's model is organized around its own tenancy concepts. It documents instances as virtual tenants with full data isolation, organizations inside instances where projects and users live, and projects that group applications, roles and grants. Passkeys are based on FIDO2 and WebAuthn, with fallback to password login. ZITADEL's core, Console and hosted login moved from Apache 2.0 to AGPL-3.0 with v3.0 on 31 March 2025, while APIs, SDKs and Helm charts remain Apache 2.0.
- Tenant isolation model: Map your tenants to instances or organizations and test whether that matches your data separation requirements.
- Licensing review: Have legal confirm how AGPL-3.0 applies to any modifications you make to the core, console or hosted login.
- Database requirement: Self-hosted ZITADEL uses PostgreSQL, with versions 14 through 18 supported.
- Deployment options: ZITADEL documents Linux and macOS binaries, Docker Compose and Kubernetes, and recommends Kubernetes with the official Helm chart for high availability.
- Federation per customer: Each customer organization can use a different identity provider, which fits B2B login.
When you compare, run a proof of concept against your actual tenant model and passkey flows rather than relying on feature lists alone.
Some teams need a clear, product-like administration experience so that application owners and support staff can manage customers without deep identity engineering. Both platforms provide admin interfaces, but they differ in how tenancy and configuration are structured, so the admin model should be tested with the people who will operate it. Neither platform is a managed service, so your team or a partner carries operational responsibility.
- Operator workflow: Keycloak's Operator manages Keycloak, realm import and OIDC and SAML client resources through custom resources, and it is installed through Operator Lifecycle Manager, kubectl or an experimental Helm chart.
- Update control: The Keycloak Operator documentation strongly recommends manual approval mode for operator updates to avoid unintended automatic upgrades.
- Delegated administration: Test how support staff can see and change customer records without broad rights.
- Provisioning: ZITADEL provides a SCIM v2 service provider interface, so confirm whether your customers' directories will push users to it.
- Run book ownership: Assign who handles incidents, upgrades and recovery requests before go-live.
Before choosing, have your operators complete a set of realistic admin tasks on each candidate, including a passkey reset and a tenant onboarding, and record where each platform required workarounds.
Platforms that fit passkey login and why
Passkey rollout depends on which identity platform already runs your customer login and how much of the login experience you want to build yourself. The options below differ in license, release model, passkey features and how much of the flow your team owns, so confirm each against your own requirements before choosing.
Keycloak for passkey login
Keycloak documents W3C WebAuthn, passkeys with conditional and modal UI, and recovery codes in its server administration guide, and it is licensed under Apache-2.0. Its Organizations feature covers member organizations and their domains, which helps B2B customers. Pin the version you deploy, since the current release is 26.8.1, published October 13, 2026. Confirm in your target version that passkey registration can be required at first login and that recovery paths behave as you expect, because feature behavior can change between minor releases.
Red Hat build of Keycloak
This is Red Hat's supported distribution based on the open source Keycloak project and replaces Red Hat Single Sign-On. It fits organizations that need a vendor support contract and a fixed patch stream for production. Red Hat's product page listed version 26.6 as its latest, which may differ from the upstream release you test against. Ask which passkey and recovery features are included in the supported build, how backports are handled, and whether your support terms cover the identity provider you federate with.
ZITADEL for passkey login
ZITADEL lists passkeys based on FIDO2 and WebAuthn with fallback to password login, and it supports multi-tenancy through instances, organizations and projects. Its core is licensed under AGPL-3.0, which matters if you modify the code and offer it as a network service. The v4.19.5 release was published October 15, 2026. Confirm how its passkey fallback policy is set per organization, and check that the AGPL terms work with your legal review before you build a customized login UI.
ZITADEL SCIM and brokering
ZITADEL provides a SCIM v2 service provider interface and can federate login with Entra ID, Okta, Keycloak and any OIDC-compliant provider, with a different identity provider per customer organization. This matters when some customers want passkeys on your platform and others want their own workforce identity to sign in. Test how a passkey registered in one flow is handled when the same person later logs in through a federated provider, and confirm which account record holds the credential.
Ory Kratos for custom login
Ory Kratos is an identity and user management component licensed under Apache-2.0, and it suits teams that will build their own login and registration UI and want the server to handle the identity logic. It leaves more of the passkey enrollment, recovery and assurance design to your team than a full platform does. Confirm whether the release you choose covers the WebAuthn and passkey flows you need, and plan how account recovery will be handled in your own front end and audit trail.
How to roll out passkeys in phases without removing password access too early
This sequence moves customers from passwords to passkeys in measured stages, so each change is backed by inventory, test evidence and telemetry before any password path is retired. Each step produces a record that a product owner, security lead and support lead can review before the next stage starts.
Inventory every login and recovery path
List each way a customer signs in or recovers an account today: password login, one-time codes, social login, federated brokering, mobile app flows, and help desk resets. For each path, record the client applications that use it, the Keycloak realm or ZITADEL instance and organization it belongs to, and the owner who can approve changes. Recovery channels such as email, SMS and support calls belong in the same inventory because they are the paths an attacker would try once passwords are weakened. The output is a login and recovery inventory signed off by the product, security and support leads. Done when no sign-in path or recovery channel is missing from the list.
Design enrollment and conditional sign-in flows
Write an enrollment flow specification that defines when a customer is offered a passkey, such as an optional prompt after a successful password login, and when it is skipped. Decide whether the sign-in page uses conditional UI so that a passkey can be suggested in the username field, or a modal UI for explicit passkey sign-in. Keycloak's server administration guide documents passkeys with conditional and modal UI, and ZITADEL documents passkeys based on FIDO2 and WebAuthn with fallback to password login. Confirm the exact authentication flow settings against the version you deploy. The output is an enrollment flow spec reviewed by UX, security and privacy staff. Done when every branch of the flow has an owner and a documented outcome.
Build a browser and device test matrix
Create a test matrix that lists the browsers, operating systems, password managers and authenticator types your customers use, including platform authenticators and roaming security keys. Run enrollment, sign-in, step-up and recovery scenarios on each combination, and record the result, the error message shown to the customer, and any fallback that appeared. Include shared and family devices, private browsing, and users whose accounts were created before passkeys were enabled. Confirm support for each combination against vendor documentation and your own test results rather than assumptions. The output is a test matrix with pass, fail and workaround status for each cell. Done when every high-volume combination has a recorded result and a named owner for any failure.
Run the parallel period with password fallback
Enable passkeys as an additional factor or sign-in method while keeping password login available to every customer. Keep recovery codes or another documented recovery path active so that a customer who loses a device or passkey can still get back into the account without a help desk call. Confirm that the password path, recovery path and account lockout rules behave consistently across the browsers in your matrix. The output is a live configuration change record with the settings, the rollback plan and the date it took effect. Done when a customer with only a password, a customer with only a passkey, and a customer who lost their device can each complete a sign-in or recovery in the test environment.
Set a telemetry baseline before measuring change
Before or at the start of the parallel run, capture the current baseline for registration completion, sign-in success rate by method, password reset volume, account recovery requests and support tickets about sign-in. Keycloak's metrics documentation describes how to expose observability data from the server, which you can connect to your monitoring stack to track login outcomes over time. Define each metric with its numerator and denominator, and agree who reviews it and how often. The output is a telemetry baseline document that stores the metric definitions and the starting values. Done when every measure in the adoption dashboard can be traced to a metric definition and a data source.
Measure adoption and recovery demand
Track registration rate for passkeys, passkey sign-in share among successful logins, recovery ticket volume and the share of recoveries that completed without staff involvement. Compare these against the baseline by customer segment, browser family and device type, so that a drop in one segment is not hidden by an average. Review the trend with support leads to find the causes of recovery tickets, such as unclear enrollment prompts or device changes. The output is a periodic adoption report with the decisions taken from it. Done when the report shows whether the self-service recovery path is working for the segments you plan to move.
Record the go or no-go decision for each segment
Before removing or hiding password login for any customer segment, hold a review that checks the adoption report, the test matrix results, recovery performance and any open security findings. Decide segment by segment, starting with segments where passkey coverage and recovery are both proven, and keep password access where evidence is weak or where regulation or customer requirements still call for it. Record the go or no-go decision, the scope it covers, the rollback trigger and the owner who can reverse it. Regulatory requirements for multi-factor authentication and access control, such as those in the FTC Safeguards Rule and HIPAA Security Rule for regulated sectors, should be checked by compliance staff before a segment is changed. The output is a dated go or no-go record for each segment. Done when every segment has a recorded decision that can be audited.
Account recovery that does not depend on help desk calls
The recovery path decides how strong your passkey rollout really is. Before enabling passkeys, decide which factor replaces a lost or broken passkey, how the customer's identity is re-verified before that factor is accepted, and how each recovery event is recorded for audit. A recovery path that is weaker than the passkey, such as a one-time code sent to an email address the attacker can also reach, undermines the design, because the attacker simply takes the weakest route in. Treat the recovery flow as a security control and test it with the same scrutiny as the login itself.
On self-hosted Keycloak, the building blocks are the OTP policies in the realm, W3C WebAuthn and passkey settings, and recovery codes, all documented in the Keycloak server administration guide. Recovery codes are a practical option for customers who lose a device, but they are a second secret the customer must store safely, so decide how they are issued, shown once, regenerated and invalidated. On ZITADEL, passkeys sit alongside password fallback in the same login, and the recovery paths available to your customers depend on the features enabled in your instance. Confirm in your target release exactly which recovery features exist, how each one is configured and whether they can be restricted per organization, because the feature set changes between versions.
Write down the recovery decision as a table your security and support teams both sign off: the trigger, the replacement factor, the identity check, the rate limits, the notification sent to the customer, the audit event stored and who may override the flow. Ask your implementation partner to show these events reaching your logging pipeline in a test environment, and to demonstrate that a support agent cannot bypass the flow by changing a credential directly. Confirm the exact recovery behavior and audit event names in the release you plan to run before you commit to the design.
Deployment pattern and integration points for customer passkeys
A passkey rollout touches the user store, the database, the availability design, the recovery channels and, for B2B customers, the identity providers that sit in front of login. The cards below cover the decisions that connect these pieces on self-hosted Keycloak or ZITADEL, and the checks to run before customers depend on them.
Customer user store and federation
Decide where customer accounts live before enabling passkeys. In Keycloak, existing users can stay in a directory reached through user federation, or be migrated into the Keycloak user store. In ZITADEL, users are managed inside the platform, and migration guides cover just-in-time approaches. Passkeys bind to a user record, so a model change after rollout forces customers to re-enroll. Confirm which system is the source of truth for email, phone and account status, and who writes to it.
Supported production database
Keycloak supports several production databases, including PostgreSQL (versions 14 to 18), MariaDB, MySQL, Oracle, Microsoft SQL Server and Azure SQL. The development file database is not for production. ZITADEL self-hosting uses PostgreSQL, with versions 14 through 18 supported. Confirm the exact version your platform team supports, the backup and point-in-time recovery model, and whether the database is a managed service in your own cloud account or run by your team.
Keycloak clustering and replication
Keycloak documents three high availability designs. The supported designs need a synchronously replicated database, because passkey registrations and session state must not diverge between nodes. A single cluster can span availability zones, and multi-cluster v2 avoids an external Infinispan cluster. The v1 multi-cluster design is deprecated. Ask your team to test node loss and a failover of the database during a login peak before going live, and to confirm the replication lag they can tolerate.
ZITADEL on Kubernetes with Helm
ZITADEL documents self-hosting on Linux and macOS binaries, Docker Compose and Kubernetes, and recommends Kubernetes with the official Helm chart for high availability. For passkey login, the Kubernetes deployment, the ingress that terminates TLS, and the public domain used as the relying party identifier must be fixed early. Changing the domain later can invalidate registered passkeys. Confirm the chart version you will pin, how upgrades are staged, and where secrets for the database and signing keys are stored.
Recovery delivery by SMS or email
Account recovery for passkey users usually depends on email, SMS or a set of pre-issued recovery codes. Keycloak documents recovery codes, and both platforms need an outbound mail or SMS path that runs inside your network or through a provider you approve. Email delivery is only as strong as the mailbox it reaches, so SMS is not automatically a stronger channel. Confirm the mail relay, sender domain authentication, SMS provider contract and the fallback when delivery fails.
SCIM and federation for B2B customers
For business customers, passkeys sit beside each customer's own identity provider. Keycloak Organizations manages member organizations and their domains, and ZITADEL organizations let each customer use a different identity provider over OIDC or SAML, LDAP or another Keycloak. ZITADEL provides a SCIM v2 interface for provisioning. Decide which customer logins use a passkey on your platform and which defer to the customer's identity provider, and confirm how deprovisioning removes passkeys and sessions.
Questions teams ask before running a passkey rollout
How much effort does a passkey rollout take, and what drives it?
The effort depends mainly on how many login applications share the identity platform, how account recovery is designed, and how much device and browser testing your customer base requires. Keycloak and ZITADEL both support passkeys based on W3C WebAuthn and FIDO2, so the platform side is usually configuration and flow design rather than new protocol work. The larger costs tend to sit in:
- Designing enrollment prompts and the password fallback for each login app
- Defining recovery paths that do not depend on help desk calls
- Testing across the browsers, operating systems and authenticators your customers actually use
- Updating support scripts and customer messaging
Ask any partner for a written scope that lists each application, each recovery path and each test matrix before agreeing a quote.
Can our internal team run a passkey rollout without an outside partner?
Many teams can, provided they already operate their identity platform and have engineers who understand OpenID Connect flows and WebAuthn settings. Keycloak documents passkeys with conditional and modal user interfaces and recovery codes in its server administration guide, and ZITADEL documents passkey login with password fallback, so the configuration paths are published. The questions to answer honestly are whether you have spare capacity for customer-facing testing, whether someone owns recovery policy end to end, and whether you can staff a support rotation during the transition. If any of those are missing, a fixed-scope engagement with DeployOpen can cover planning, implementation, testing and documentation inside your own infrastructure, with ongoing support available as a retainer.
What does the work need from our people?
The rollout needs three groups of people with clear responsibilities. Identity owners decide enrollment triggers, fallback rules and recovery policy, and they approve changes to the realm or organization configuration. Support leads write the scripts for enrollment problems, lost devices and lockouts, and they track the contact volume during each phase. Test staff use a range of real devices, operating systems, browsers and password managers to confirm the flows behave as designed. Plan for these roles to be named before work starts, because the most common delays come from unclear sign-off, not from the technology.
How long does each phase of a passkey rollout take?
Phase length depends on the number of applications, how many customers use each one, and how much change control your organization requires. In broad terms, design and recovery decisions usually take the longest because they involve several owners, configuration and testing move faster once the decisions are fixed, and measurement after launch runs for as long as you need to see adoption and support trends. Ask any partner to show a phase plan with gates, such as approval of recovery design and completion of device testing, rather than a single calendar date. Timelines should be agreed in writing with the scope, because they change when the scope changes.
Do regulations require us to remove passwords when we add passkeys?
No. The rule text in the FTC Safeguards Rule at 16 CFR 314.4 requires multi-factor authentication for individuals accessing information systems, but it does not require removing passwords, and passkeys are one way to meet an authentication requirement. The HIPAA Security Rule at 45 CFR 164.312 asks for unique user identification, audit controls and person or entity authentication, and it also does not name passkeys or require passwords to be removed. Passwords can remain as a fallback during transition if your risk assessment supports it. Confirm the exact requirements for your sector with your compliance team or legal counsel, since obligations beyond these rules may apply.
How do Keycloak or ZITADEL upgrades affect enrollment flows?
Upgrades can change authentication flows, so enrollment behavior should be tested in a staging environment before each production upgrade. Keycloak has planned four minor releases a year since version 26.0 and says breaking changes in a minor release will be opt-in, which lowers but does not remove the testing need. The Keycloak Operator documentation strongly recommends manual approval mode for operator updates to avoid unintended automatic upgrades. ZITADEL publishes release notes for each version, and its self-hosted deployments run on PostgreSQL 14 through 18. Keep a regression set of enrollment, fallback and recovery tests, and record which configuration settings you changed from defaults so each upgrade can be checked against them.
How do we know whether passkey adoption is high enough to remove passwords?
Measure adoption against clear thresholds set before launch, such as the share of active customers with a registered passkey, the share of logins completed with a passkey, and the rate of recovery or support contacts per login. Keycloak exposes metrics that can feed dashboards, and ZITADEL logs authentication events you can export to your monitoring tools, so confirm both against your deployment. Track segments separately, because adoption often differs by device type, region and application. Removing passwords is a product and risk decision, and it should wait until recovery paths have handled real cases without excessive support load.
Evidence assessors ask for and which component produces it
This table maps the evidence an assessor is likely to request for a customer passkey rollout to the Keycloak or ZITADEL component that produces it. Read each row as a question to answer before the assessment starts, and confirm the exact export or log format with your chosen platform version. DeployOpen prepares this evidence, but auditors and certification bodies issue any assessment or attestation.
| Evidence item | Where it comes from | What to confirm before assessment |
|---|---|---|
| Authentication policy configuration exports | Keycloak realm settings and authentication flows, or ZITADEL instance and login policy configuration, exported under version control | Export format, who approved each change, and whether password fallback and passkey policies are stored together |
| MFA and passkey settings per realm or instance | Keycloak WebAuthn and passkey settings per realm, or ZITADEL passkey and MFA policy per organization or instance | Which realms or organizations are in scope, and that settings match the documented design for each tenant |
| Registration and enrollment audit logs | Keycloak admin and event logs, or ZITADEL audit events, forwarded to the central log platform | Retention period, log integrity controls, and that passkey registration events are captured, not only password changes |
| Account recovery event records | Recovery code use, recovery flow events and help desk-free reset events logged by the identity platform | Whether recovery actions show the verification method used and whether recovered accounts are flagged for review |
| Failed sign-in and lockout records | Authentication failure events and brute-force detection logs from the identity platform | Alert thresholds, who reviews them, and how records link to individual accounts without exposing unnecessary personal data |
| Password fallback usage metrics | Counts of password-based versus passkey-based sign-ins, reported from identity events or metrics endpoints | Metrics definition, reporting period, and whether the trend supports the decision to remove passwords |
| Cross-browser and authenticator test records | Test plans and results for browsers, operating systems, platform authenticators and security keys | Test matrix covers the customer devices in your analytics, and each failure has a recorded workaround or fix |
| Change records for platform upgrades | Release notes, change tickets, test results and rollback plans for Keycloak minor upgrades or ZITADEL releases | Upgrade approval workflow, staging test evidence, and whether operator update mode is set to manual approval |
Measuring adoption before removing passwords
Do not remove passwords for any customer group until you can measure passkey adoption and recovery load for that group. Start by defining five metrics: the share of active customers with at least one registered passkey, the passkey sign-in share of successful logins, the password fallback share, recovery volume per thousand logins, and support contacts tagged to login problems. Track them per customer segment and per browser or device family, not only as a platform-wide average, because a blended number can hide a segment that cannot yet use passkeys. Your risk owner should set the thresholds that gate each phase of password removal. Do not adopt thresholds from vendor marketing or external benchmarks, since your customer base, fraud exposure and recovery tolerance are specific to you.
Keycloak gives you most of the raw inputs. The server administration guide documents passkeys with conditional and modal UI and recovery codes, and the Keycloak metrics documentation describes how to expose server metrics for monitoring. Login events and admin events, when enabled and forwarded to your SIEM, let you tag each successful login by authentication method and each recovery flow by reason. Compare these with your support ticketing system, where agents should tag contacts that originate from login, enrollment or recovery. Confirm with your implementation partner which Keycloak event types are recorded in your version (the current release is 26.8.1), how long event data is retained in your database, and whether the event pipeline can separate passkey logins from password logins without custom code. The same questions apply to ZITADEL, which documents passkeys with password fallback.
Recovery deserves its own line in the dashboard because a rise in recovery volume is often the first sign that passkey enrollment is confusing or that a device change is breaking sign-in. Measure recovery per thousand logins, and break it down by recovery path, so you can see whether customers are using recovery codes, another registered passkey, or a support-assisted route. Treat a falling password share as necessary but not sufficient. Remove passwords for a group only when passkey coverage, recovery volume and login-tagged support contacts have all stayed within the thresholds your risk owner approved for at least one full business cycle, and keep the fallback path available until the rollback plan has been tested.
How DeployOpen scopes and supports passkey rollouts
DeployOpen plans, implements, customizes, integrates, hardens, documents and supports self-hosted open-source identity platforms inside the client's own infrastructure. For passkey rollouts on Keycloak or ZITADEL, that means agreeing the login flows, fallback rules and recovery design in writing before any configuration begins.
How we scope
- Engagements are fixed-scope, with the passkey flows, realm or instance layout and target applications agreed in writing before work starts.
- Scope documents which login paths, password fallback rules and recovery methods are covered, and which are left to the client.
- We confirm the hosting target, database and high availability design, and the adoption metrics the client wants to measure.
How we build
- We configure WebAuthn and passkey settings with conditional and modal UI in Keycloak, or passkey login with password fallback in ZITADEL, per the agreed design.
- We build enrollment, recovery and fallback journeys and test them across the browsers and devices in the agreed support matrix.
- We integrate the identity platform with client applications and run security testing against the login and recovery paths.
How we hand over
- Handover includes configuration documentation, runbooks for enrollment and recovery support, and the adoption reporting setup.
- We document the controls and evidence that support the client's own compliance assessments, without issuing audit reports or certifications.
- Knowledge transfer covers how to change policies, roll out upgrades and retire password methods once adoption is confirmed.
How we support
- Ongoing support, upgrades and continuous security testing are available as retainers after the initial rollout.
- Retainer support can cover Keycloak or ZITADEL version upgrades, which we plan and test before they reach production.
- We can keep the recovery flows and fallback settings under review as browser and device support changes over time.
