When Ping Identity or self-hosted ZITADEL fits your identity estate
Choose between Ping Identity and self-hosted ZITADEL by first deciding who signs in. If your renewal covers PingFederate for workforce and partner federation, or PingOne Advanced Identity Cloud for customer journeys, the question is whether you need a Ping platform at all or a self-hosted service that you can run in your own infrastructure. Ping still fits where WS-Federation and WS-Trust relying parties remain in production, because ZITADEL implements OpenID Connect, OAuth 2.0 and SAML 2.0 but does not cover those WS-* protocols. Ping also fits where your team already operates PingFederate well and where Ping's Long-Term Support policy is the support model your auditors and procurement accept. Confirm the support window for your exact version with Ping before you rely on it.
ZITADEL fits when you serve business customers who each bring their own identity provider. Its instances, organizations and projects give you data and policy isolation at several levels, and each customer organization can federate with a different provider over OIDC, SAML or LDAP. Self-hosting runs on PostgreSQL 14 or later, with versions 14 through 18 documented, and the platform supports passkeys with password fallback. Legal review matters here: ZITADEL's core, Console and hosted login moved to AGPL-3.0 with v3.0, while APIs, SDKs and Helm charts stay Apache 2.0. Ask counsel whether AGPL-3.0 obligations on modified network-facing code are acceptable for your use, and whether a commercial or Enterprise arrangement from ZITADEL changes that answer.
Three decisions settle the choice. First, inventory every protocol and connection, including WS-Federation relying parties that no open-source platform in this comparison covers directly. Second, separate customer-facing from workforce use, since business-customer tenancy and workforce federation drive different designs. Third, complete a licensing review covering AGPL-3.0 for the core, the support model you will buy, and Ping's current terms. Ask Ping for written end-of-support dates for your version and ask ZITADEL for its current Enterprise plan scope, then compare both with your own operating capacity before you set a migration plan.
Which option fits each scenario
This table matches common Ping Identity requirements to the option that fits best, and states the condition under which each fit holds. Read each row against your own inventory of applications and teams, because a single scenario can change the answer. Where a row points to Ping or a different platform, the reason is usually a protocol or operating model gap that ZITADEL does not cover.
| Scenario | Better fit | Why |
|---|---|---|
| Relying parties that need WS-Federation or WS-Trust | Ping Identity (PingFederate) or WSO2 Identity Server | ZITADEL implements OpenID Connect, OAuth 2.0 and SAML 2.0, but its documentation does not list WS-Federation or WS-Trust. Confirm with ZITADEL before assuming coverage. |
| B2B customer identity with a different identity provider per customer | ZITADEL | ZITADEL organizations let each customer organization use its own identity provider over OIDC, SAML, LDAP or other supported sources, inside a multi-tenant instance model. |
| Passkey-first login for consumers or business users | ZITADEL | ZITADEL supports passwordless login with FIDO2 and WebAuthn passkeys, with fallback to password login. Confirm the passkey policy options your workflows need in the current release. |
| Legal team objects to AGPL-3.0 licensing | Keycloak (Apache 2.0) or Ping Identity under a commercial contract | ZITADEL's core, Console and hosted login moved to AGPL-3.0 with v3.0. Keycloak is Apache 2.0. Ask counsel whether using ZITADEL unmodified as an internal service raises obligations for your organization. |
| In-house Ping operations team with PingFederate skills | Ping Identity, with an upgrade plan | Retraining a team on a different product carries effort that is hard to justify when current operations already work and the protocols in use are supported. Revisit the choice when the support window or licensing changes. |
| Requirement for a vendor support contract on the platform | Ping Identity or a ZITADEL commercial plan, checked against the written scope | A self-hosted option only has the support you buy. Compare the support tiers in ZITADEL's pricing page with Ping's contract terms, and ask each vendor for the response commitments in writing. |
| Data must stay in a specific country or on your own infrastructure | ZITADEL, self-hosted in the required location | Self-hosted ZITADEL runs on your Docker Compose or Kubernetes environment with PostgreSQL 14 to 18. Confirm that the database, backups and logs stay in the permitted region. |
| Migrating a Ping customer identity deployment with custom journeys | ZITADEL, with actions replacing custom logic | ZITADEL documents migration guides and just-in-time migration. Custom Ping journeys need to be rebuilt as ZITADEL actions, so test each journey before cutover. |
Which protocol gaps decide the answer
Most of the ZITADEL decision comes down to which protocols your legacy relying parties actually use today. Work through each card against a real inventory of applications, because a single unsupported protocol can keep a PingFederate connection on the old platform longer than the rest of the estate.
WS-Federation and WS-Trust
PingFederate serves WS-Federation and WS-Trust relying parties, often Microsoft-era applications and SharePoint-style sign-on. ZITADEL's documented coverage lists OpenID Connect, OAuth 2.0 and SAML 2.0, and WS-Federation and WS-Trust support on the ZITADEL side must be confirmed with the vendor before a decision. Test each legacy relying party for a WS-Federation token request and a WS-Trust exchange, and record which ones fail.
SAML 2.0 and OIDC coverage
ZITADEL implements OpenID Connect, OAuth 2.0 and SAML 2.0, so most web and API relying parties should map cleanly. For each SAML connection, check the signing certificate, the NameID format, the audience restriction and the attribute contract, then repeat the check for each OIDC client's redirect URIs, scopes and token lifetimes. Keep a single table of these settings for the cutover.
SCIM provisioning
ZITADEL offers a SCIM v2 service provider interface for standardized user provisioning and lifecycle management. Confirm which SaaS applications on your list expect to push users in over SCIM, and test whether create, update and deactivate events arrive with the attributes each application requires. Provisioning gaps often surface after login works, so test them separately.
LDAP and Active Directory federation
ZITADEL can federate login with LDAP and OpenLDAP directories, as well as Entra ID and Okta over OIDC or SAML, and each customer organization can use a different identity provider. If PingDirectory or Active Directory is still the user store, confirm the bind account, search base, attribute mapping and group handling in a test tenant. Check how group membership reaches authorization decisions in each relying party.
Device authorization grant
ZITADEL provides a device authorization grant for input-constrained devices such as smart TVs. If your PingFederate estate issues device codes for kiosks, set-top boxes or command-line tools, list each client and its polling behavior, then test the full flow with the user approving on a second device. Confirm the token lifetimes and rate limits the new deployment will apply.
Passkeys with password fallback
ZITADEL supports passwordless login with passkeys based on FIDO2 and WebAuthn, with fallback to password login. Decide whether fallback stays enabled for each population, and confirm that passkeys registered for each relying party's domain survive the move. Check how account recovery works when a user loses the authenticator, since that path becomes your responsibility once the platform is self-hosted.
How Ping Identity and ZITADEL compare on capabilities
This table compares Ping's commercial customer identity and federation products with self-hosted ZITADEL across licensing, protocols, tenant model, upstream federation, passkeys, provisioning, storage, deployment and migration. Where a Ping capability is not covered by our research, the cell tells you what to confirm with Ping before you decide. Use the open-source column as the fixed baseline and the Ping column as the checklist of questions to put to the vendor.
| Capability | Ping Identity (PingFederate, PingOne Advanced Identity Cloud) | ZITADEL (self-hosted) |
|---|---|---|
| Licensing | Commercial subscription. Confirm the license terms, the Long-Term and Short-Term Support policy and any Extended Limited Support fees with Ping. | AGPL-3.0 for the core, Console and hosted login since v3.0. APIs, SDKs, proto definitions, Helm charts and Terraform files are Apache 2.0. |
| Protocols | PingFederate supports WS-Federation and WS-Trust. Confirm the OIDC, OAuth 2.0 and SAML 2.0 versions each Ping product supports. | OpenID Connect, OAuth 2.0 and SAML 2.0, plus a device authorization grant for devices such as smart TVs. |
| Tenant model | Confirm with Ping how tenants, environments and customer isolation are modeled in PingOne Advanced Identity Cloud and PingFederate. | Instances give full data isolation, organizations hold users and projects, and projects group applications, roles and grants. |
| Federation to upstream providers | Confirm which external identity providers and protocols each Ping product can federate to, and whether each customer can use its own provider. | Google, GitHub, GitLab, Apple, Entra ID, Okta, LDAP, OpenLDAP, Keycloak and any OIDC provider. Each organization can use a different provider. |
| Passkeys | Confirm passkey support, FIDO2 and WebAuthn coverage and fallback behavior for each Ping product with Ping. | Passwordless login with passkeys based on FIDO2 and WebAuthn, with fallback to password login. |
| SCIM provisioning | Confirm whether SCIM is available in each Ping product and which versions it supports. | SCIM v2 service provider interface for standardized user provisioning and lifecycle management. |
| Database | Managed or product-specific storage. Confirm the storage model and any customer control over data location with Ping. | PostgreSQL, with versions 14 through 18 supported for self-hosted deployments. |
| Self-hosting options | PingFederate is self-managed. Confirm which PingOne Advanced Identity Cloud components can run outside Ping's cloud with Ping. | Linux and macOS binaries, Docker Compose and Kubernetes. The official Helm chart is recommended for high availability. |
| Migration guides | Ping-specific export and import paths are not covered here. Ask Ping for export tooling and the data it includes, including password handling. | Documented guides from Auth0, Keycloak, Firebase and another ZITADEL instance, including just-in-time migration. |
How ZITADEL's organization model maps to multi-tenant customer identity
ZITADEL's model starts from three levels: instances, organizations and projects. An instance is a virtual tenant with full data isolation, organizations sit inside an instance and hold the users and projects, and projects group the applications, roles and grants that a customer's applications use. For a customer identity platform, this means each business customer can be given its own organization, its own administrators and its own identity provider, while the platform team keeps control of the instance and the shared policies. ZITADEL's documentation states that each customer organization can use a different identity provider, which is the main reason this structure fits B2B customer identity. Confirm the exact administrator roles and which policies can be set per organization in the current ZITADEL documentation before you draw the design.
A Ping deployment is usually organized around environments, connections and user stores. Connections (SAML and OIDC relationships with relying parties) are configured on the federation server, and the user store behind them is often a shared directory. Separating customers in that setup typically means more connections, more store mappings and more operational review by the central team. Check how your current Ping configuration isolates one customer's connections, users and certificates from another's, and write that down as a baseline. Then compare it against ZITADEL's instance and organization boundaries, paying attention to where administrators can act without touching other customers' settings.
The model pays off when you serve many business customers, each with its own administrators who need to manage their own users and identity provider connections without a central ticket. Under that condition, delegated organization administration reduces the work the platform team carries. It adds design work when you have a handful of tenants or a single workforce. In that case, a single organization with well-defined projects and roles may be simpler, and the extra levels of tenancy become overhead. Decide early whether each tenant needs a separate instance (full data isolation) or an organization within one instance, because moving a tenant later is a migration project in its own right.
Where the identity data lives and who runs the platform
Ping's customer identity products and ZITADEL differ first in where the service and its data sit. Ping's cloud products keep the running service with the vendor, while self-hosted ZITADEL places the database, keys and operations inside your own infrastructure. The cards below cover the decisions that follow from that difference.
Who operates the identity service
With PingOne Advanced Identity Cloud, Ping runs the service in its cloud, so your team manages configuration and integrations rather than servers. Self-hosted ZITADEL moves that work to you: patching, scaling, certificate rotation and incident response become your responsibility, or the responsibility of a partner you contract. Ask Ping which operational tasks remain with your team under your agreement, and price the on-call and upgrade work against your current staffing.
Deployment options for ZITADEL
ZITADEL documents self-hosting on Linux and macOS binaries, with Docker Compose and Kubernetes as the other supported paths. For high availability, the project recommends a Kubernetes cluster deployed with the official Helm chart. A single Compose host suits evaluation and smaller setups, but it does not provide the same failover characteristics. Confirm the topology your availability target needs before you size the cluster.
Database dependency: PostgreSQL 14 to 18
Self-hosted ZITADEL stores its data in PostgreSQL, with versions 14 through 18 supported. Your database team therefore owns backup, replication, point-in-time recovery and minor version patching for the identity store. Check that your PostgreSQL platform falls inside the supported range, and confirm who restores the database during an incident, because identity availability depends on it.
Data residency and key custody
Self-hosting lets you decide which region, cloud account or data center holds user records, authentication events and signing keys. With a cloud product, the data location and key handling follow the vendor's hosting terms, so you should request those terms in writing. Document where each data class sits, who holds administrative access, and how backups are encrypted, since regulators and auditors will ask these questions directly.
Compliance evidence and assessor scope
Moving the platform in-house means your organization produces the control evidence that a vendor previously supplied as part of its own assessments. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make those determinations. Ask your assessor early which controls you must evidence yourself and which the cloud vendor's reports already cover.
Licensing and self-hosted support
ZITADEL's core is licensed under AGPL-3.0, so the license terms and any modifications you make to the core must be reviewed by counsel before production use. Self-hosting removes per-tenant platform fees, but it adds your own staffing and infrastructure costs. Confirm whether you need the commercial Enterprise plan for support commitments, and ask ZITADEL what support, update windows and security notification terms it provides for self-hosted deployments.
What each option costs to run, by component
Ping costs are set by contract. The recurring part is the subscription or license that covers PingFederate, PingOne or the former ForgeRock products, and it is usually priced on the products, environments and scale you buy. Support tiers and the Ping lifecycle policy also shape what you pay over time, because a version that moves past its support window can require Extended Limited Support or an upgrade project. Those upgrades are one-time labor, but they recur across major versions.
- Subscription or license: Recurring. Ask which products, environments, user or connection counts and terms the price covers.
- Support tier: Recurring. Ask what response times, channels and escalation paths each tier includes.
- Extended Limited Support: Recurring when used. Confirm with Ping whether it applies to your version and for how long.
- Upgrade projects: One-time per major move. Include regression testing of every connection, adapter and custom integration.
- Staffing: Ongoing internal or partner effort to administer the platform, including Ping-specific skills.
Confirm the Long-Term Support and Extended Limited Support terms for your exact version directly with Ping before you compare them with the ZITADEL side.
Self-hosted ZITADEL has no license fee for the AGPL-3.0 edition, so the cost is in infrastructure, PostgreSQL operations, staffing and the one-time migration. The Enterprise plan is a separate commercial option, and its terms should be checked on the pricing page before you assume either path. Costs scale with the number of instances, organizations, traffic and availability targets you design for.
- Infrastructure: Recurring. Compute, load balancing and storage for the ZITADEL nodes, sized for high availability on Kubernetes with the official Helm chart or on Docker Compose for smaller setups.
- PostgreSQL operations: Recurring. Backups, patching, failover and monitoring of PostgreSQL 14 through 18, either managed by your cloud provider or run by your team.
- Support and Enterprise plan: Recurring if chosen. Confirm current Enterprise plan terms on the pricing page, including what support covers.
- Staffing: Recurring. Platform, security and identity engineers to upgrade, operate and secure the service.
- Migration: One-time. Importing users, recreating OIDC and SAML applications and replacing custom journeys with ZITADEL actions.
Before you compare totals, ask any ZITADEL partner or internal team to price the database and staffing lines in the same currency and period as your Ping quote.
A useful written quote separates one-time work from recurring spend so the two options can be compared on the same basis. Ask each party to state its assumptions about environments, user volume, high availability and version coverage. Without these, totals are difficult to compare and most of the uncertainty ends up in staffing and upgrade estimates.
- Scope: The products, environments, applications, connections and user stores included.
- Recurring lines: Subscriptions, support tiers, hosting and database services, each with its billing period.
- One-time lines: Migration, testing, cutover, documentation and training, with the deliverables they produce.
- Lifecycle assumptions: Which versions are covered, upgrade frequency and what happens at end of support.
- Exit terms: Data export format, notice periods and what the contract leaves behind if you stop.
For ZITADEL, confirm current Enterprise plan terms on the pricing page, and for Ping, confirm its LTS and Extended Limited Support terms in writing.
What a move from Ping Identity to ZITADEL involves
The sequence turns an existing Ping customer identity deployment into a ZITADEL instance with its own organizations, projects and applications, verified in parallel before the Ping connections are retired.
Export and inventory the Ping configuration
Collect the PingOne Advanced Identity Cloud or PingFederate configuration, the list of OIDC and SAML applications, their redirect URIs, signing certificates, attribute mappings and custom journeys or adapters. DeployOpen builds a migration inventory from these with your Ping administrators, and the step is complete when every application has an owner and a named target. Confirm early with Ping which user data and password hashes can be exported, because hash availability decides whether users keep their passwords or reset them at first login.
Confirm the password hash export path with Ping
Ask Ping in writing whether it will provide password hashes, in what format, under which plan and within what process. Record the answer in the inventory, since the import method in the next step depends on it. If hashes are not available, plan for just-in-time migration or a password reset flow, and agree this with your security and compliance owners before any user is moved. The output is a written decision that the client signs off.
Map tenants to ZITADEL instances, organizations and projects
Translate the Ping tenancy model into ZITADEL's structure: instances for fully isolated tenants, organizations for customer groups, and projects that hold applications, roles and grants. Decide which customer organizations need their own upstream identity provider, since ZITADEL lets each organization use a different one. DeployOpen drafts the mapping and the client confirms it against business ownership of each customer group. The step closes with an approved mapping document.
Import users through migration guides or just-in-time
Move identities using the approach chosen in step two, either a bulk import through ZITADEL's documented migration path or just-in-time migration, where a user is moved at first login against the old store. DeployOpen runs test imports into a staging instance, checks attribute mapping, duplicate accounts and login behavior for sample users, and documents the counts reconciled between source and target. The client provides test accounts and reviews the reconciliation report.
Recreate OIDC and SAML applications and custom logic
Register each application in its ZITADEL project, reproduce the scopes, claims and grants it needs, and rebuild the custom journeys from Ping as ZITADEL actions where the business logic still applies. Application owners test sign-in, token contents, logout and role checks against the staging instance. The step is complete when each application passes its agreed test cases and the owner signs off on the configuration.
Run Ping and ZITADEL in parallel during cutover
Route a controlled set of applications or customer organizations to ZITADEL while the remaining ones stay on Ping, and monitor failed logins, token errors and support tickets during the overlap. Agree a change window with the client and a rollback path for each application. The output is a cutover log showing which applications moved, when, and what was observed.
Retire the Ping connections
Once every application has run on ZITADEL through the agreed period, disable the Ping connections, remove the retired signing certificates and archive the final configuration export under your retention rules. DeployOpen documents the final state, updates the runbooks and hands over operations to your team or a support retainer. The step is complete when no application depends on Ping and the handover record is signed.
Questions buyers ask before choosing ZITADEL or staying with Ping
How much does switching from Ping Identity to ZITADEL cost?
The switch has two cost groups: one-time work and recurring running costs. One-time work covers inventory, building organizations and projects, importing users, recreating OIDC and SAML applications, testing and cutover. Recurring costs cover the servers or Kubernetes cluster, PostgreSQL, backups, monitoring, upgrades and any support contract. Ping's subscription and any Extended Limited Support fees for an aging PingFederate version end when you leave. ZITADEL's self-hosted software is licensed under AGPL-3.0, so the software line itself is not a fee, but a paid support or Enterprise arrangement is a separate item. Ask any quote to split one-time migration effort from annual operations, and to state which Ping licenses and support fees it removes. Ask for the same breakdown from ZITADEL's pricing page before comparing.
How long does a migration from Ping to ZITADEL take?
The timeline depends on how many applications, relying parties and user stores you have, how many customer organizations need their own identity provider, and whether custom Ping journeys must be rebuilt as ZITADEL actions. Applications that use standard OIDC or SAML are usually the quickest to move. Customer-facing journeys, password migration and any federation with partner identity providers take longer. A fixed-scope written plan should set the schedule, deliverables and cutover window before work starts. Ask any provider to name the phases, the applications in each phase and the cutover approach, including how both systems run in parallel.
What does our team need to provide during the migration?
Your team usually provides the knowledge and access the work cannot do without. That means an inventory of Ping connections, the attribute contracts each application expects, the user stores and their owners, certificate and signing key handling, and the business owners who approve cutover for each application. You will also need a PostgreSQL database and a hosting environment, such as Docker Compose or Kubernetes, that operations staff can run after handover. ZITADEL's documentation lists PostgreSQL versions 14 through 18 as supported, so check that your platform team can run one of them.
Can our internal team migrate from Ping to ZITADEL alone?
A capable internal team can do the work alone if it has people who understand OIDC, SAML, certificates and the applications being moved, and if it can test each relying party before cutover. The risks are usually not the software setup. They are missed attribute mappings, forgotten WS-Federation or WS-Trust dependencies, and gaps in testing of customer journeys. Decide early whether your team will own the full project, run it with an outside implementation partner, or hand over operations after a fixed-scope build. Whichever you choose, write down who owns each application after cutover.
Does the AGPL-3.0 license affect our internal use of ZITADEL?
AGPL-3.0 is a copyleft license, and its obligations depend on how you run and distribute the software, including whether you modify it and whether users interact with it over a network. ZITADEL moved its core, Console and hosted login from Apache 2.0 to AGPL-3.0 with v3.0 on 31 March 2025, while its APIs, SDKs, Helm charts and Terraform configurations remain Apache 2.0. This page does not give a legal conclusion. Ask your counsel to review how your planned deployment, modifications and any customer-facing login pages fit the license, and record that review before selecting ZITADEL.
How do we handle WS-Federation relying parties when moving off PingFederate?
ZITADEL documents OpenID Connect, OAuth 2.0 and SAML 2.0, and its supplied documentation does not list WS-Federation or WS-Trust. Before choosing ZITADEL, list every relying party that uses WS-Federation or WS-Trust, including Microsoft 365 or on-premises services that depend on them. For those applications you have three choices: keep PingFederate for them, move them to a product that supports WS-Federation, or change the applications to use SAML or OIDC. Confirm each option with the application owner and the vendor, because a protocol change can affect the application code and its testing.
Does ZITADEL support the Ping connections we use today?
ZITADEL can federate login with Google, GitHub, GitLab, Apple, Entra ID and Okta over OIDC or SAML, with LDAP and OpenLDAP, with Keycloak, with JWT identity providers and with any OIDC-compliant provider. Each customer organization can use a different identity provider. Check your Ping connections against that list one by one, including the attribute mappings and any adapter logic inside PingFederate. Ask the implementer to produce a connection-by-connection table showing the target ZITADEL setup, the protocol and the test result for each.
What does a ZITADEL support contract change?
A support contract changes who you can call when something breaks and how quickly they respond, but it does not change the software you run. Self-hosting ZITADEL keeps your data and infrastructure under your control either way. Ask ZITADEL what its Enterprise plan includes, what response terms apply and what it costs, and compare that with the Ping support and LTS terms you have today. DeployOpen runs implementation, hardening, backups, upgrades and documentation under written scope, and offers ongoing support and upgrades as retainers. Ask for the coverage, response and handover terms in writing rather than relying on a general description.
How DeployOpen helps evaluate, implement or migrate
DeployOpen plans, implements, hardens and documents self-hosted open-source identity platforms inside your own cloud accounts, data centers or air-gapped networks. For a Ping Identity to ZITADEL decision, we start with the written scope that separates customer identity from workforce federation, so the protocol and tenant model are settled before any build begins.
How we scope
- Each engagement is fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- The scope lists every relying party, its protocol (OIDC, OAuth 2.0, SAML 2.0 or WS-Federation) and the tenant model it needs.
- We confirm which WS-Federation and WS-Trust dependencies stay on Ping, since ZITADEL's documented protocols do not cover them.
How we build
- We deploy ZITADEL on Docker Compose or Kubernetes with PostgreSQL in your environment, using the versions the documentation supports.
- We map instances, organizations and projects to your customer and business tenant structure, then configure identity providers per organization.
- We test passkey enrollment with password fallback, SCIM provisioning and user imports against a staging copy before any cutover.
How we hand over
- Handover includes architecture notes, configuration records, runbooks and the test evidence collected during cutover.
- We document the Ping-to-ZITADEL application inventory, including redirect URIs, claims and the actions that replace custom journeys.
- Your team receives the operating procedures for backups, upgrades and AGPL-3.0 license obligations for the components you run.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after the initial handover.
- Security testing of the deployed identity platform and its applications can be scoped as a separate engagement.
- For compliance work, we prepare systems, controls and evidence for your assessors, who issue any audit reports or certifications.
