Which open-source Auth0 alternative fits your customer identity needs
For multi-tenant customer identity, ZITADEL is the strongest starting point among the options in this group, because it structures tenants as Identity System, Organizations and Projects, with data and policies isolated at several levels. Keycloak suits teams that need the broadest protocol and federation coverage, since it supports OpenID Connect, OAuth 2.0 and SAML 2.0 and has built-in user federation with existing LDAP and Active Directory servers. authentik fits teams that want a lighter model built around a proxy and directory, with a free edition that covers OIDC, SAML, LDAP, SCIM, RADIUS, Kerberos and proxy authentication. Your choice should follow from how many tenants you run, which applications must federate, and whether your team can carry the operating load.
Teams usually start this review at a renewal, a pricing change, a data residency requirement or a wish to avoid lock-in to one vendor's login flows. Whatever the trigger, the constraint that most often shapes the migration is the user export. Auth0 can export users through the Dashboard or the Management API create export users job in NDJSON or CSV format, but standard exports do not include password hashes. Password hashes are available only on paid plans through a support ticket, Auth0 does not guarantee a delivery date, and the option is not available on the Free tier. Confirm with Auth0 whether your plan qualifies and how long the request takes before you set a cutover date, because users whose hashes do not arrive will need a password reset flow on the new platform.
Before you pick a platform, list the login flows your customers use today, including social logins, passwordless options, custom database connections and any Actions or hooks that run during login. Each one needs a named equivalent on the target platform or a decision to retire it. Ask each candidate vendor to demonstrate those flows against your own tenant model, not a demo tenant. A proof of concept with two or three representative tenants will show more about fit than feature matrices do, and it gives your security and compliance leads evidence for the decision.
Three self-hosted options for replacing Auth0
Auth0 customer identity can move to several self-hosted platforms, but each carries different licensing, tenancy and support terms. The three options below cover the main candidates for customer identity, and each card names the decision a team must make before choosing one.
ZITADEL for multi-tenant customer identity
ZITADEL structures tenants as an Identity System, Organizations and Projects, with data and policies isolated at several levels. That model maps closely to SaaS products where each customer needs its own login policies and branding. It supports certified OIDC, SAML 2.0, SCIM 2.0 and LDAP, and runs on PostgreSQL 14 or later with Docker Compose or Kubernetes. The trade-off is licensing: review the AGPL-3.0 license with legal before you embed or modify the code in a customer-facing product.
Keycloak for broad protocol coverage
Keycloak is Apache 2.0 licensed, is a CNCF incubating project, and supports OpenID Connect, OAuth 2.0 and SAML 2.0. Its built-in federation with LDAP and Active Directory suits organizations that also run workforce directories alongside customer logins. Realm import and export uses the kc.sh export and kc.sh import commands, but the documentation warns that this is limited as a backup mechanism and requires all nodes to be stopped while it runs. Plan a separate backup strategy for production realms.
authentik and its enterprise directory
authentik's open-source core is MIT licensed and supports OIDC, SAML, LDAP, SCIM, RADIUS, Kerberos and proxy authentication. The enterprise directory features sit under the separate authentik EE License, so confirm which features your flows depend on before committing. The free edition comes with community support only. If you need ticket-based support, SLAs or FIPS compliance, those are paid tiers that you should price against your own requirements.
Support model as a selection criterion
Community support is the model that comes with the free editions of these platforms, so an internal team or a paid partner must own incident response. Ask each vendor which support tiers cover production outages, security advisories and upgrade paths. Then compare that against your own on-call capacity. For customer-facing identity, a login outage affects revenue directly, so this cost often matters more than the licence fee.
Licensing review before selection
Each platform uses a different license, and the license determines what you must disclose or publish if you modify the code and offer it to customers. Ask legal to review the license text for every component you plan to deploy, including any enterprise or extension directories. Record the decision in your architecture file so auditors and future teams can trace why a platform was chosen.
How Auth0 capabilities map to self-hosted options
This table maps the main Auth0 identity capabilities to self-hosted Keycloak, ZITADEL and authentik, with gaps marked. Use it to shortlist platforms, then confirm each entry against the current documentation for the version you plan to deploy.
| Capability | Keycloak | ZITADEL | authentik |
|---|---|---|---|
| OIDC and OAuth 2.0 login | Supports OpenID Connect and OAuth 2.0 as core protocols | Supports certified OIDC for customer and workforce login | Supports OIDC in the free edition, with community support only |
| SAML 2.0 federation | Supported | Supported | Supported in the free edition |
| SCIM provisioning | Confirm SCIM coverage in the current release and extension set | Supports SCIM 2.0 | Supported in the free edition |
| LDAP and user federation | Built-in federation with existing LDAP and Active Directory servers | Supports LDAP; confirm directory sync scope for your setup | Supports LDAP; Kerberos also included |
| Multi-tenant organizations | Realms isolate tenants; plan realm count and admin boundaries | Identity System, Organizations and Projects isolate data and policies at several levels | Confirm tenant model against your isolation requirements |
| Bulk user export from Auth0 | Import realm JSON; confirm user and credential handling for your source | Confirm import tooling and format against the Auth0 NDJSON or CSV export | Confirm import path and attribute mapping in current docs |
| Password hash migration | Gap to plan: Auth0 hashes exist only through a support ticket on paid plans, with no guaranteed delivery date | Gap to plan: same Auth0 dependency; confirm supported hash algorithms on import | Gap to plan: same Auth0 dependency; confirm supported hash algorithms on import |
| MFA enrollment | Built-in OTP and WebAuthn options; users may need to re-enroll after cutover | Built-in MFA options; confirm enrollment carry-over from Auth0 | Confirm MFA stages and enrollment carry-over |
| Hosted login and branding | Customizable login themes; confirm branding depth for your needs | Customizable login UI; confirm branding and custom domain options | Customizable flows and stages; confirm branding limits |
| Auth0 Actions equivalents | Gap to confirm: map Actions to authentication flows and SPI extensions | Gap to confirm: map Actions to ZITADEL actions and webhooks | Gap to confirm: map Actions to authentik policies and flows |
What the Auth0 bulk user export gives you and what it leaves out
The Auth0 bulk user export gives you profile data for your user base, but it does not give you the password hashes that a self-hosted platform needs to keep existing passwords working on day one. You can start the export from the Dashboard or through the Management API with the create export users job (POST /jobs/users-exports). The output comes as NDJSON or CSV, and the file carries identity attributes, metadata and linked identities. Before you schedule anything, open a sample file and confirm that every field your target realm or tenant needs is present, including custom user_metadata and app_metadata fields, which are easy to overlook. The official reference is in Auth0's bulk user exports documentation.
Standard exports leave out password hashes. Getting them requires a support ticket to Auth0, and the option is available only on paid plans, not on the Free tier. Auth0 does not guarantee a delivery date for the hash file, so treat it as an external dependency with no committed timeline. Ask your account contact to confirm whether your plan qualifies, what format the hashes arrive in, and which hashing algorithms are covered, because your target platform must be able to verify those hashes or migrate them on first login. Put the request in at the start of the project, not at cutover. Log the ticket reference, the requester and the date in your migration plan so the dependency is visible to the program owner.
Plan the fallback now. If the hash file arrives late, arrives partial or uses an algorithm your target cannot verify, users without a usable hash need a forced password reset or a verification step at first login. Decide in advance which user segments would be affected, how the reset email is delivered, and how support handles users locked out during the window. Test both paths in a staging realm or organization with a copy of the export, including MFA enrollments that do not migrate with the password. Illustratively, if a segment of accounts has no hash, that segment should be scheduled for a reset campaign, not left to fail at the login page. Confirm each step with the migration owner before the production run.
Cost components when replacing Auth0 with self-hosted identity
This table separates the cost of an Auth0 subscription from the cost of running Keycloak or ZITADEL yourself, and marks each item as one-time or recurring. Use it to build the question list for scoped quotes, since no prices are given here. The main takeaway is that the software license is often the smallest line, and infrastructure, migration and password-flow work carry most of the effort.
| Cost component | Who is paid or who carries it | One-time or recurring | What drives it up or down |
|---|---|---|---|
| Auth0 subscription | Auth0, under your current contract | Recurring | Tenant size, plan tier, add-on features and the contract renewal terms you negotiate |
| Open-source software license | No license fee for Keycloak (Apache 2.0) or ZITADEL (AGPL-3.0); confirm AGPL obligations with counsel | Not applicable | Your use of modified code and whether you need vendor-backed editions or support |
| Compute, PostgreSQL 14 or later, load balancing and backups | Your cloud provider or data center team | Recurring | Login volume, number of nodes, database high availability and backup retention you require |
| Platform architecture and deployment | DeployOpen or your internal platform team, under a fixed-scope written agreement | One-time | Number of realms or organizations, custom themes, Docker Compose versus Kubernetes, and environments |
| Migration and password-flow work | Implementation partner or internal engineers | One-time | Whether the Auth0 password hash export is obtained, and how users are moved or reset if it is not |
| Application integration | Internal application teams or implementation partner | One-time, with ongoing changes | Number of applications, protocol mix (OIDC, SAML) and changes to login flows and tenant routing |
| Support | Community support, or a paid vendor tier such as authentik Enterprise with ticketed support, or Enterprise Plus with SLAs | Recurring | Required response times, on-call expectations, and whether your chosen platform offers paid support |
| Internal operations skills | Your identity, security and platform staff | Recurring | Upgrade cadence, incident handling, security patching and the depth of in-house identity expertise |
Which option fits by situation
If your product serves many business customers, each with its own users, branding and policies, ZITADEL is the option whose data model matches that shape most directly. It structures tenants as an Identity System, Organizations and Projects, with data and policies isolated at several levels, so each customer organization can be managed as a separate unit without building that boundary yourself. Auth0 Organizations customers will recognize the concept, but the mapping needs checking against your own tenancy design.
- Organization model: Map each Auth0 tenant or organization to a ZITADEL Organization, and decide early which resources belong to the Identity System and which belong to individual customers.
- Projects and roles: Model your application entitlements as Projects and roles, and confirm they cover the authorization patterns your product uses today.
- Login flows: Rebuild custom Auth0 Actions and login logic as ZITADEL login behavior, and test each customer-facing flow end to end.
- Certified protocols: ZITADEL supports certified OIDC, SAML 2.0, SCIM 2.0 and LDAP, which matters if your enterprise customers provision users through SCIM.
- Database: Plan for PostgreSQL 14 or later as the backing store for the deployment.
Before committing, confirm with the ZITADEL project which organization and project features your planned tenancy model needs, and test them against a representative customer.
If your enterprise customers or internal users already sit in Active Directory or LDAP, Keycloak is usually the broadest starting point. It supports OpenID Connect, OAuth 2.0 and SAML 2.0, and includes built-in user federation with existing LDAP and Active Directory servers, so you can keep the directory as the source of truth while Keycloak issues tokens to applications. This suits a migration where many applications need SAML and OIDC coverage at the same time.
- Federation first: Connect the existing directory through user federation before moving any application, so login behaves the same while you change the front door.
- Protocol coverage: Inventory which applications use SAML, OIDC or OAuth 2.0, and confirm each client configuration in a test realm.
- Export scope: Keycloak realm export and import through
kc.sh exportandkc.sh importis useful for configuration, but the documentation warns it has limitations as a backup mechanism and requires all nodes to be stopped while it runs. - Password handling: Federated passwords stay in the directory, which changes what the Auth0 hash export is needed for.
- Operations: Plan for clustering and database operations, because Keycloak is a larger component to run.
Confirm the exact federation features and version behavior against the Keycloak server guide for the release you plan to deploy.
If your main need is protecting internal or legacy web applications with proxy authentication, or you want a smaller platform to operate, authentik is worth evaluating. Its open-source core is MIT licensed and the free edition supports OIDC, SAML, LDAP, SCIM, RADIUS, Kerberos and proxy authentication. The trade-off is that the free edition has community support only, and some capabilities sit in the enterprise directory under a separate license.
- Proxy coverage: Check whether your applications can sit behind the proxy provider or need native OIDC or SAML integration instead.
- License boundary: Identify which features you need, then confirm whether each one is in the MIT core or in the authentik EE License directory.
- Support model: The free edition relies on community support, so decide whether your team can carry that burden or whether a paid tier or retainer is needed.
- Scale and HA: Confirm the high availability and multi-instance setup for your environment with the authentik documentation before sizing.
- Customer identity: Compare its organization and tenant model against your multi-tenant requirements, since it may not match a per-customer model as directly as ZITADEL.
Ask the authentik team to confirm which features in your requirements list fall within the free edition.
When customer identity data must stay in a specific country, region or client-controlled data center, self-hosting moves the question from a vendor's regions to your own infrastructure. All three candidate platforms can run inside your cloud account, data center or private network, so the residency answer depends on where you deploy the database, backups and logs, not only on the product. Auth0 password hash exports are also a residency issue, because the hashes and the export file need a defined handling path from the moment they arrive.
- Location of the database: Keep PostgreSQL or the equivalent store in the approved region, including replicas and point-in-time backups.
- Export handling: Treat the user export and any password hash export as sensitive data, with restricted access, encryption at rest and a documented deletion date after import.
- Logs and telemetry: Confirm where authentication logs, audit events and metrics are stored and who can read them.
- Support access: Define which personnel can reach the systems from outside the region and under what approval.
- Vendor paths: Ask Auth0 how and where password hash exports are delivered, since the support-ticket path is the step most likely to cross a boundary.
Write these answers into your data flow diagram before scheduling the export request.
For banks, healthcare providers, public bodies and other regulated organizations, the platform choice should follow your control obligations, not only feature parity. Each candidate can be deployed in a hardened, self-managed setup, and DeployOpen can plan, implement, harden and document that deployment and prepare the systems, controls and evidence for a compliance assessment. DeployOpen does not issue audit reports, attestations or certifications. Independent auditors and certification bodies do that work, and the evidence package should be reviewed with them early.
- Control mapping: Map your identity controls, such as authentication, access review, logging and privileged access, to the frameworks your assessor uses, and confirm which platform features support each one.
- Certifications: Ask each vendor or project which certifications and conformance tests apply to the exact version you plan to run, rather than assuming them.
- Enterprise features: Where a regulated control depends on an enterprise feature, such as privileged access management or FIPS-validated cryptography, confirm the edition that includes it.
- Change records: Keep records of configuration, export and import steps, because the Keycloak export guidance and similar steps need clear change control.
- Assessor engagement: Agree the evidence list with your independent assessor before cutover.
Confirm the assessor's requirements and the platform edition in writing before the implementation scope is agreed.
What you give up when leaving Auth0 and the usual workarounds
Moving from a managed identity platform to self-hosted ZITADEL or Keycloak trades vendor-run operations for work your team or implementation partner owns. Each card below names one thing you lose, why it matters for customer identity, and the workaround most teams use to close the gap.
Managed uptime and hosted security updates
Auth0 runs the identity service, applies patches and handles scaling for you. Self-hosted Keycloak or ZITADEL puts upgrades, high availability, database maintenance and certificate renewal on your side, so a missed security release becomes your exposure. Workaround: agree in writing who patches what, set a release-tracking cadence, and consider a retainer for scheduled upgrades and testing. Confirm the upgrade path between your current and target versions before you commit to a date.
Custom action and rule code rewrites
Auth0 Actions and legacy rules run custom JavaScript during login, such as adding claims, enforcing conditions or calling external systems. These do not port directly. Workaround: inventory every action, then re-implement each as a Keycloak protocol mapper, authentication flow step or required action, or as ZITADEL actions where the logic truly needs code. Treat each rewrite as a tested change, not a copy-paste, and keep the original behavior as your acceptance test.
Hosted login UI and branding differences
Auth0 Universal Login and its customization options are hosted for you. In self-hosted Keycloak or ZITADEL, the login pages, themes, email templates and localization become files or settings you maintain through upgrades. Workaround: list every screen customers see, including password reset, MFA enrollment and error pages, then build a theme or customized UI and test it against each supported browser and language. Confirm how custom themes survive version upgrades in the release you choose.
Password hash gaps that force resets
Auth0 does not include password hashes in standard user exports. Hashes are available only through a support ticket on paid plans, and Auth0 does not guarantee a delivery date. If that export does not arrive or cannot be imported into your target, customers must reset passwords on first login. Workaround: request the hash export early, confirm the hash algorithm with Auth0 support, and plan a fallback reset flow for any accounts without usable hashes.
Vendor-hosted anomaly detection
Auth0 Attack Protection features, such as breached-password checks, bot detection and suspicious-login signals, run as a managed service fed by Auth0's own telemetry. Self-hosted platforms do not supply equivalent signals out of the box. Workaround: map each detection you rely on to a source, such as a web application firewall, a rate limiter, a breached-password dataset you license, or a SIEM rule. Confirm which controls you need to keep evidence for before you retire the hosted feature.
Vendor support and enterprise features
Auth0 support contracts, service levels and account management are part of what you buy today. Community Keycloak and ZITADEL support comes from public channels and the project itself, and some features you may use, such as commercial SLAs or certain enterprise add-ons, come from separate vendors or paid tiers. Workaround: list the Auth0 features in use, mark which are core protocol behavior and which are paid add-ons, and ask each candidate vendor or partner for written support terms.
How to plan an Auth0 to self-hosted migration
This sequence moves customer identity from Auth0 to a self-hosted platform in controlled stages, so each application, user store and login flow is inventoried, tested and cut over with a fallback path before Auth0 is retired.
Inventory applications, tenants and connections
Your architecture or identity lead lists every Auth0 tenant, application (client), API, connection (database, social, enterprise SAML or OIDC, passwordless), Action or rule, and custom login page that depends on it. For each, record the redirect URIs, token lifetimes, scopes, and the claims the application reads. Include any multi-tenant or organization setup, since the target model must represent it. The step is done when a signed-off register maps each application to its connections, owner and cutover dependency, and when you have confirmed with Auth0 which features your plan and tenant configuration use.
Request the password hash export early
Password hashes are not part of a standard user export. According to Auth0's documentation, paid-plan customers request the hash export through a support ticket, and Auth0 does not guarantee a delivery date. Your security owner opens the request as soon as the inventory confirms which database connections hold passwords, and asks Auth0 to confirm the format, the hash algorithm for each connection, and the delivery method. The step is done when you hold written confirmation of the request, the expected file format, and a secure transfer method approved under your data handling policy. Because the option is not available on the Free tier, confirm your plan first.
Export users and map to the target model
Run the bulk export using the Dashboard or the Management API create export users job (POST /jobs/users-exports), in NDJSON or CSV format, and store the output in an encrypted location with access logging. Map Auth0 user fields, metadata, identities and linked accounts to the target realm or organization model in ZITADEL or Keycloak, and decide how each hash format will be verified or re-hashed on first login. Keycloak realm import and export is a configuration and migration aid, not a backup substitute, and its docs require all nodes to be stopped while it runs, so plan a separate backup of the source and target databases. The step is done when a mapping document is approved and a test import produces users with matching attributes and group memberships.
Pilot with a test tenant
Build the target platform in a non-production environment, import a representative sample of users from a test Auth0 tenant or an anonymized export, and connect one low-risk application. Your engineers verify OIDC or SAML flows, token claims, MFA enrollment, password login using migrated hashes, account recovery and logout. Record every gap, such as Auth0 Actions with no direct equivalent, which must be rebuilt as target-side flow customizations. The step is done when the pilot application completes login, token refresh and logout for each connection type in scope, and the defect list is either resolved or accepted by the owner.
Run parallel with a documented fallback
Keep Auth0 active for production traffic while the target platform serves a subset of applications or a controlled user group. Synchronize changes through an agreed method, and define the rollback procedure: which DNS, client configuration or application setting reverts traffic to Auth0, and who approves the switch. Monitor authentication success rates, error logs and support tickets during this phase. The step is done when the parallel period has run without unresolved authentication incidents and the rollback has been rehearsed.
Cut over application by application
Move each application in the order set by the register, updating client IDs, redirect URIs, issuer URLs and signing keys, and communicating expected re-login behavior to users. Confirm that passwords and MFA enrollments migrated as planned, and record any users who must reset credentials. The step is done when every application in scope authenticates against the target platform, the old Auth0 clients are disabled for those applications, and the cutover log is signed off by the application owners.
Decommission Auth0 after retention checks
Before closing the Auth0 subscription, confirm that your legal, audit and incident response teams have the logs, user records and configuration evidence they need under your retention policy. Export and store the configuration you must keep, then delete or disable the tenant data according to your data protection commitments. Remove the stored hash files and bulk export files from all locations, and revoke the access used for the migration. Your compliance lead records the decommission. DeployOpen prepares controls and evidence for compliance assessments, but independent auditors issue any attestation. The step is done when retention checks are complete, migration artifacts are destroyed or archived as policy requires, and the closure record is approved.
Questions teams ask before replacing Auth0
How much effort does moving off Auth0 take?
The effort depends mostly on what your Auth0 tenant does, not on user count alone. A plain username and password tenant with a few applications is far simpler than one with custom database actions, social connections, enterprise SSO, organizations and many Auth0 Rules or Actions that hold business logic. The main drivers are the number of applications and their OIDC or SAML configuration, the login flows you need to reproduce, how many custom claims and tokens your APIs depend on, and whether MFA enrollments must carry over. Ask any implementation partner for a written inventory of these items before agreeing on a fixed scope.
Can Auth0 password hashes be exported for migration?
Yes, but not through the standard export. Auth0 documents that standard user exports omit password hashes, and paid-plan customers request hash exports through a support ticket. Auth0 does not guarantee a delivery date, and the option is not available on the Free tier, so confirm eligibility with Auth0 early. If hashes are not provided, users must reset passwords on first login, or you can run a lazy migration that verifies credentials against Auth0 on each user's first sign-in and then stores the result in the new system. Plan the cutover for either path before you commit to a date.
How long does planning an Auth0 migration take?
Planning time is set by decisions and dependencies, not by a standard duration. Work that usually slows planning includes waiting for the support-ticket password hash export, mapping Auth0 Actions and custom database scripts to the new platform, agreeing on the multi-tenant model for organizations, and testing every application's login and token flow in a staging environment. Start by requesting the bulk export described in the Auth0 documentation for the user list, then confirm what Auth0 can deliver for hashes. Any timeline you receive should be tied to a written scope with named dependencies.
What does the migration need from our internal team?
The migration needs people who own the business side of identity and people who run the target platform. Your team should provide application owners who can confirm redirect URIs, scopes, claims and logout behavior, a security or compliance contact who approves the password and MFA approach, and an infrastructure owner for hosting, databases, backups and network access. Someone must also decide how customer support will handle password resets during cutover. Confirm these roles in the written scope so the migration does not stall waiting for decisions.
Can our team run ZITADEL or Keycloak after cutover?
Yes, if your team takes on operations, but the work recurs and should be staffed before go-live. Keycloak exports realms as JSON with kc.sh export, and its documentation warns that this is a limited backup mechanism and requires all nodes to be stopped during the process, so you need a proper backup and restore design. ZITADEL self-hosts with Docker Compose or Kubernetes on PostgreSQL 14 or later. Ongoing work includes version upgrades, certificate and key rotation, monitoring, incident response and security patching. DeployOpen offers upgrades, backups and support as retainers if you prefer not to carry that load alone.
Which licenses should we review before choosing a platform?
Review each license against how you plan to distribute and host the software. Keycloak is licensed under the Apache License 2.0, and the project is a Cloud Native Computing Foundation incubating project. ZITADEL is licensed under AGPL-3.0, with Apache 2.0 and MIT exceptions for specific directories, so ask counsel whether the AGPL network-use obligations apply to your modifications and deployment. authentik's core is MIT licensed, but its enterprise directory falls under a separate authentik EE License. Confirm the license of every component you deploy, including any extensions or themes, before you sign a scope.
What should we ask a partner before the migration starts?
Ask for a written scope that covers the application inventory, the login flows to reproduce, the password and MFA approach, the cutover plan, rollback steps and handover documentation. Ask who performs the Auth0 export and hash request, and how the partner will handle the target platform's backups and upgrades after go-live. DeployOpen plans, implements, integrates, hardens and documents self-hosted platforms inside your own infrastructure, and most engagements are fixed-scope with deliverables agreed in writing before work begins. DeployOpen does not publish a price list, so ask for a quote that follows from that written scope.
How DeployOpen works on this
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source identity platforms inside your own cloud accounts, data centers or air-gapped networks. For an Auth0 replacement, that means agreeing in writing what moves, how users and password hashes are handled, and how login flows and tenants are rebuilt before any work starts.
How we scope
- Inventory every Auth0 tenant, application, connection, Action and login flow that must keep working after cutover.
- Confirm with Auth0 whether password hash exports are available on your plan, since they are requested through a support ticket.
- Agree the tenant model for ZITADEL Organizations and Projects or Keycloak realms in a fixed-scope written document.
How we build
- Stand up ZITADEL or Keycloak in your environment, using PostgreSQL 14 or later for ZITADEL as the supported starting point.
- Import the Auth0 bulk user export, map attributes, and test password and MFA enrollment paths against a staging copy.
- Run security testing on login, token and admin interfaces before production traffic is moved to the new identity provider.
How we hand over
- Deliver architecture records, runbooks, configuration exports and the migration test results as written documentation.
- Walk your platform, security and application teams through how tokens, redirect URIs and user lifecycle now work.
- Prepare controls and evidence for compliance assessments, while independent auditors remain responsible for any audit or attestation.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Backups of realm or database state follow the vendor guidance, including stopping nodes during Keycloak export and import.
- Each new Keycloak or ZITADEL release is reviewed in a test environment before it is applied to your production identity service.
