Which open-source IAM platform fits your situation
For workforce SSO across employee applications, Keycloak usually leads, because it supports OpenID Connect, OAuth 2.0 and SAML 2.0, brokers logins to external providers and federates users from LDAP or Active Directory under Apache-2.0. For customer logins in a SaaS product where each customer manages its own users, Zitadel usually leads, because its organizations sit inside one instance and map well to B2B tenancy, though its AGPL-3.0 license needs legal review before you build on it. If you need both populations on one platform, plan the separation between workforce and customer identities during design, because the answer shifts toward whichever tenancy model you can operate cleanly.
Keycloak fits teams that want the broadest protocol coverage under Apache-2.0 and can run a production relational database such as PostgreSQL 14 to 18, with the Keycloak Operator if they run Kubernetes. Zitadel fits multi-tenant B2B products where customers administer their own users and identity providers, and the trade-off is that AGPL-3.0 terms apply to modified network-facing code, while a commercial license is available. authentik fits teams that want flexible provider types such as proxy, LDAP and RADIUS on an MIT-licensed core, but code under authentik/enterprise needs a paid subscription for production use, so confirm which enterprise features your design depends on before you commit.
Ory, with its Apache-2.0 headless components, suits teams that want APIs to build their own login flows, and Authelia, also Apache-2.0, suits protecting web applications behind a reverse proxy with two-factor authentication. WSO2 Identity Server is worth evaluating when your architecture already centers on WSO2, but confirm its license and edition terms directly with WSO2 before you shortlist it. Treat every verdict here as provisional until the scope is agreed in writing, because protocol needs, tenancy model and the paid modules you require can change the answer. Ask each vendor to confirm the feature list for the release you plan to deploy.
Which open-source IAM platform suits which scenario
This table maps common identity scenarios to the platform that fits best, the supplied fact behind that choice, and the condition under which another option wins. Read it as a starting shortlist, then confirm the protocol, tenancy and licensing details against your own requirements and the vendor documentation.
| Scenario | Best fit | Why, and when another option wins |
|---|---|---|
| Workforce SSO into an enterprise directory | Keycloak | Keycloak federates users from LDAP or Active Directory and brokers logins to external OIDC or SAML providers under Apache-2.0. Another option wins if your directory is Windows-only and you want authentication tightly bound to AD, or if you need identity lifecycle governance, where midPoint is the better layer. |
| B2B SaaS where each customer manages its own users | Zitadel | Zitadel models each customer as an organization inside one instance, and each organization can use a different identity provider. Choose Keycloak instead if you do not need per-customer delegated administration, and confirm Zitadel's AGPL-3.0 terms fit your distribution model. |
| Protecting apps that have no login of their own | authentik or Authelia | authentik offers a proxy provider alongside OIDC, SAML and LDAP, with an embedded outpost in its server container. Authelia suits a lighter reverse-proxy setup with Apache-2.0 terms. Confirm which proxy and session model your environment already runs before choosing. |
| Kubernetes API and cluster tool access | Keycloak or authentik | Both implement OpenID Connect, which the Kubernetes API server can use for login. Keycloak has a supported Operator managing realms and clients as custom resources. Dedicated SSO brokers such as Dex may be simpler if you only need cluster login, so confirm the operating effort inside the cluster. |
| Multi-protocol estate with SAML and legacy apps | Keycloak | Keycloak supports OpenID Connect, OAuth 2.0 and SAML 2.0 in its core edition. authentik is a close alternative with SAML and LDAP providers, but its Google Workspace and Entra ID integrations sit in the Enterprise edition. |
| Passwordless and modern login for customer-facing apps | Zitadel | Zitadel supports passkeys based on FIDO2 and WebAuthn with fallback to password login. Confirm passkey coverage for your specific identity provider and client types before committing. |
| Identity governance and provisioning rather than login | midPoint, paired with Keycloak | Evolveum states midPoint is an identity management system, not an authentication or SSO server, so it provisions accounts into an access layer. Keycloak is the access layer in that pairing. Skip midPoint if you only need login and no provisioning workflows. |
| Regulated enterprise needing paid support and features | Keycloak, Red Hat build or authentik Enterprise | Choose based on the support model you need. authentik's Enterprise features include audit logging and mTLS, priced per the authentik pricing page. Confirm which features your compliance evidence depends on and what a vendor quote includes. |
How Keycloak, Zitadel and authentik are built differently
The architectural difference that matters most for operations is where each platform keeps its state. Keycloak needs a relational database in production, and the supported list includes PostgreSQL 14 to 18, MariaDB, MySQL, Microsoft SQL Server, Oracle Database, Amazon Aurora PostgreSQL and others. Its default dev-file database is for development only. Keycloak applies schema migrations automatically at startup by default, but its upgrading guide suggests manual migration for large deployments, so your change process should decide which approach you will use before the first upgrade. Keycloak documents three high availability designs: a single cluster optionally spread across availability zones, multi-cluster deployments (v2) without external Infinispan, and the deprecated multi-cluster v1. Both supported designs depend on a synchronously replicated database, so the database failover plan is part of the Keycloak design, not an afterthought.
Zitadel also depends on PostgreSQL (versions 14 to 18 for self-hosting), but it stores every change as an event. That gives it a built-in audit trail, and it also means your backup and restore testing should cover the event store as the system of record, not only a set of current tables. Its tenant model is layered: an instance is a virtual tenant with full data isolation, organizations inside an instance hold projects and users, and projects group applications, roles and grants. If your product serves B2B customers who manage their own users, you need to decide early whether one instance with many organizations meets your isolation requirement or whether each customer needs its own instance.
authentik has the simplest runtime layout of the three. A deployment consists of a server container (core with an embedded outpost), a worker container for background tasks, and PostgreSQL, which stores all configuration and data except uploaded files. The 2025.10 release removed Redis entirely and moved caching, tasks, sessions and WebSocket functions into PostgreSQL. The release notes warned of roughly 50% more PostgreSQL connections after upgrading, so confirm your connection pooling and database sizing before you move to that line. For all three platforms, plan for regular database backups with tested restores, a rehearsed upgrade path in a non-production environment, and a documented failover procedure. Confirm the exact recovery objectives and failover behavior with each vendor for your own environment, because the research supplied here does not state them.
Protocols, multi-tenancy, licensing and admin experience compared
This table compares Keycloak, Zitadel and authentik on license, current release, protocols, databases, tenancy, brokering and paid tiers. Read each row as a fit question: a 'yes' on a protocol means the supplied documentation lists it, not that every edge case is covered, so confirm details against your own requirements.
| Capability | Keycloak | Zitadel | authentik |
|---|---|---|---|
| License | Apache-2.0 for the open source project | AGPL-3.0-only from v3, with APIs, SDKs and Helm charts under Apache-2.0 and a commercial license offered | MIT for core, with code under authentik/enterprise under a separate enterprise license |
| Current release | 26.8.1, published October 13, 2026 | v4.19.5, released October 15, 2026 | 2026.8.4, published October 14, 2026 |
| OpenID Connect and OAuth 2.0 | Supported | Supported, including a device authorization grant for devices such as smart TVs | Supported through OAuth2/OIDC providers |
| SAML 2.0 | Supported | Supported | Supported through SAML providers |
| LDAP | Federates users from LDAP or Active Directory | Federates login from LDAP and OpenLDAP identity providers | LDAP provider available, plus an LDAP source for directory users |
| SCIM | Confirm provisioning options in the server administration guide | SCIM v2 service provider interface for standardized provisioning | Documented SCIM provider type |
| Passkeys | Confirm passkey support for your version in the server administration guide | FIDO2 and WebAuthn passkeys with fallback to password login | Confirm passkey support for your version in the provider documentation |
| Production database | Relational database required; PostgreSQL 14 to 18, MariaDB, MySQL, SQL Server, Oracle, Aurora PostgreSQL | PostgreSQL 14 to 18 for self-hosted deployments | PostgreSQL only for configuration and data, with Redis no longer used from 2025.10 |
| Multi-tenancy model | Realms separate users and clients within one server; confirm fit for your tenant count | Instances give full data isolation; organizations inside instances hold projects and users, suited to B2B products | Single deployment with providers and applications; confirm tenant separation approach for your model |
| Identity brokering | Brokers logins to external OpenID Connect or SAML identity providers | Federates from Google, GitHub, Entra ID, Okta, Keycloak and any OIDC provider, with a different provider per organization | Source and provider model for upstream identity; confirm the specific connectors you need |
| Paid tiers | Red Hat build of Keycloak is Red Hat's supported distribution; confirm terms directly with Red Hat | Commercial license offered by Zitadel; confirm the scope against the AGPL terms | Enterprise and Enterprise Plus editions listed on the pricing page, with Google Workspace, Entra ID and mTLS among enterprise-only features |
| Ory, WSO2 Identity Server and Authelia | Not compared in full on this page | Not compared in full on this page | Not compared in full on this page; confirm their protocols, tenancy and licensing directly with each vendor |
What each license allows and what sits behind paid editions
Keycloak is licensed under Apache-2.0, as stated in the project's LICENSE file, and it is a Cloud Native Computing Foundation incubating project. The community release has no separate paid edition. Commercial support comes from Red Hat through the Red Hat build of Keycloak, a supported distribution based on the open source project that replaces Red Hat Single Sign-On.
- Community use: Apache-2.0 allows you to run, modify and redistribute Keycloak without a license fee. Patching, support and troubleshooting then fall to your team or your implementation partner.
- Red Hat build of Keycloak: This is Red Hat's supported distribution. Its product page listed version 26.6 as the latest at the time of research, so confirm the current build on the Red Hat build of Keycloak page.
- Scope of the subscription: Ask Red Hat what the subscription covers, including support windows, certified platforms, and whether database and operator issues are included.
- Open source features: Identity brokering, user federation, fine-grained authorization services and the admin console are described as part of the open source project, so confirm each one against the release you plan to deploy.
Before assuming the community release meets an audit or contract requirement, confirm which build, support window and subscription terms your organization needs in writing.
Zitadel was licensed under Apache-2.0 until v3. In 2025, with Zitadel v3, the core, Console and hosted login moved to the GNU Affero General Public License 3.0. APIs, SDKs, proto definitions, examples, documentation, Helm charts and Terraform configurations remain Apache-2.0. AGPL-3.0 is an OSI-approved open source license, but the commercial license the project offers is a separate agreement that is not open source.
- AGPL-3.0 core: The copyleft terms cover the core, Console and hosted login. AGPL extends source obligations to users who interact with a modified version over a network, so any modified deployment needs review.
- Apache-2.0 client and API layer: SDKs, API definitions, Helm charts and Terraform configurations can be used under Apache-2.0. This matters if your team builds its own clients or infrastructure code around Zitadel.
- Commercial license: The LICENSING.md file states that a commercial license is offered. Ask what it covers, the term, the renewal conditions and whether support is included.
- Hosted services for customers: If you offer Zitadel-based login to your own customers as a service, ask counsel to confirm the AGPL obligations for that model before launch.
Record the commercial license as a separate, non-open-source agreement in your asset register, and get written legal review before you deploy a modified build.
authentik's repository is MIT-licensed for most code, including the core server. Code in the authentik/enterprise directory falls under the authentik Enterprise Edition license, and that code needs a paid subscription for production use. Because the enterprise directory is not OSI open source, label it that way in your internal records and do not treat the whole repository as one license.
- MIT core: Most of the repository is MIT-licensed, so self-hosted use of the core does not require a subscription under that license.
- Enterprise features: The pricing page lists Google Workspace and Microsoft Entra ID integrations, mTLS client certificate authentication, privileged access management, password history and enhanced audit logging as Enterprise-only. Enterprise is listed at $5 per user per month billed annually plus $0.02 per external user per month.
- Enterprise Plus: The same page lists this edition from $20k annually, with dedicated support with SLAs, multi-instance deployment support and FIPS compliance for FedRAMP requirements.
- Support tiers: Ticket-based support is listed for subscriptions over $1k. Confirm what the community channel covers before relying on it for production.
If your access design needs any listed enterprise feature, get the current price and terms in writing from the vendor, because pricing pages change and the enterprise license governs what you may run.
License terms are only one part of cost. Vendor subscriptions and commercial licenses recur, while implementation, migration and hardening work is usually one-time. Ory and Authelia are both Apache-2.0 according to the group context, but WSO2 Identity Server's license and edition terms need direct confirmation with WSO2 before you shortlist it. Licensing questions need legal review, and DeployOpen does not provide legal opinions on license terms.
- Recurring subscriptions: Ask each vendor for the term, renewal conditions and what happens to support and updates if a subscription lapses.
- Non-OSI components: Mark the authentik enterprise directory and the Zitadel commercial license as non-OSI in your records, alongside the Apache-2.0 and MIT components.
- Other options: Confirm WSO2 Identity Server's license, edition and feature limits directly with WSO2, and confirm Ory and Authelia terms against their current repositories.
- Quote inputs: Ask for a written scope with deliverables, timelines and any upgrade or testing retainer. Keep vendor subscription terms separate from the services scope so each cost line is clear.
Before signing, have counsel review each license and subscription document against your intended use, including any hosting you provide to customers.
Keycloak, Zitadel, authentik and the narrower alternatives
The three platforms that most often reach a shortlist are Keycloak, Zitadel and authentik, and each makes a different trade on license, tenancy and admin experience. The narrower options (Ory, WSO2 Identity Server and Authelia) fit specific architectures, and the cards below state the license, the primary use and the condition under which each one is the wrong choice.
Keycloak
Keycloak is an Apache-2.0 identity and access management server that supports OpenID Connect, OAuth 2.0 and SAML 2.0, brokers logins to external identity providers and federates users from LDAP or Active Directory. It is a common choice when you need broad protocol coverage and a large community under a CNCF incubating project. It is the wrong choice if you need native multi-tenancy with each customer managing its own users, because Keycloak models that through realms and needs careful design. Check the database and high availability design early, since production use requires a relational database and a synchronously replicated one for clustered designs.
Zitadel
Zitadel is an identity platform built for multi-tenant B2B products, licensed under AGPL-3.0-only since Zitadel v3, with APIs, SDKs and Helm charts kept under Apache 2.0. Its organization model lets each customer organization manage its own users and bring its own identity provider, and it stores changes as events for an audit trail. It is the wrong choice if your organization cannot accept AGPL obligations for a modified, network-served service without a commercial license, or if your team has no PostgreSQL 14 to 18 platform to run it on.
authentik
authentik is an MIT-licensed identity provider for the core code, with enterprise features under a separate license in the authentik/enterprise directory that require a paid subscription for production use. It covers OAuth2 and OpenID Connect, SAML, LDAP, RADIUS and proxy providers, and runs as a server and worker container backed by PostgreSQL. It is the wrong choice if you need Google Workspace, Microsoft Entra ID integration, mTLS client certificates or other enterprise-only features without budgeting for the subscription, so confirm which features your design depends on before you commit.
Ory
Ory is an Apache-2.0 headless identity stack made of separate components for login flows, OAuth2 and OpenID Connect, permissions and API gateway rules. It suits teams that want to build their own login user interface and keep identity as a set of services. It is the wrong choice if you want a ready-made admin console and a single product to operate, because you will assemble and run several components yourself. Confirm which components you need and whether the Ory Network or the Enterprise License applies to your deployment model.
WSO2 Identity Server
WSO2 Identity Server is an identity and access management product from WSO2 that fits organizations already standardized on the WSO2 integration stack, with supported protocols for single sign-on, adaptive authentication and identity federation. Confirm its current license terms and support editions directly with WSO2, since they differ from the community projects in this comparison. It is the wrong choice if you want a lightweight, single-container deployment or a fully open-source license with no commercial tier, because the product is oriented toward larger enterprise integration programs.
Authelia
Authelia is an Apache-2.0 single sign-on and two-factor companion that sits in front of applications through a reverse proxy, adding login and multi-factor checks without changing the app. It is a good fit for protecting internal web tools with a small identity footprint. It is the wrong choice when you need to be the identity provider for many external applications, issue tokens to third-party clients or manage SAML federation, because its role is access control at the proxy rather than a full identity provider.
How to choose and pilot an open-source IAM platform
This sequence turns a shortlist of Keycloak, Zitadel, authentik and others into a documented decision, backed by a non-production install, a federation test and a written view of the operating effort each platform would demand.
Define workforce and customer use cases
Start by listing who signs in and why: employees reaching internal apps, partners, and customers who may need their own organization, branding or identity provider. Name the applications in each group and whether they are web apps, APIs, Kubernetes tools or legacy systems that need a proxy. Multi-tenancy matters here. Zitadel organizes tenants as instances and organizations, while Keycloak and authentik are typically run with realms or tenant patterns your team must design. Confirm with each vendor how its tenant model maps to your customer structure. The step is done when each use case has an owner and a written list of applications.
List required protocols and external identity providers
Record every protocol your applications need, such as OpenID Connect, OAuth 2.0, SAML 2.0, LDAP, RADIUS or SCIM, and every upstream source of identity, including Active Directory, Entra ID, Okta or an existing Keycloak. Mark which are mandatory and which are nice to have. Check each platform's documentation for the listed provider types, and ask vendors to confirm support for your exact versions and any custom claim or attribute mapping you rely on. The output is a requirements table that every candidate is scored against, so the comparison stays tied to your environment rather than to feature lists.
Confirm licensing and paid edition features
Read each candidate's license and edition terms before any installation. Keycloak is Apache-2.0, Zitadel moved its core to AGPL-3.0-only in v3, and authentik's enterprise directory needs a paid subscription for production. Make a list of each requirement from the previous step and mark which ones depend on a paid edition, such as authentik's Google Workspace or Entra ID integrations, or support terms from a vendor. Ask in writing whether any needed feature sits behind a commercial license, what your obligations are if you modify or host the software for others, and how support subscriptions are priced. The step closes with a license memo reviewed by your legal or procurement team.
Test a non-production install with your database
Deploy the shortlisted platforms in a non-production environment that uses the same database engine you plan to run in production, since Keycloak, Zitadel and authentik each rely on PostgreSQL or other supported databases and the default development database is not suitable for production. Confirm the database version against the vendor's support list, then check how schema migrations run at startup and how upgrades are applied. Note any Redis or cache dependencies. Run the install through your intended method, such as the Keycloak Operator, Helm or Docker Compose, and record the commands and configuration keys you used. The step is done when each candidate starts cleanly, survives a restart, and passes a basic login test.
Run a federation and migration test with sample users
Create a sample set of users, including a group with the same attributes as your directory, and test each required federation path: LDAP or Active Directory user federation, brokering to an external OIDC or SAML provider, and any JIT or bulk migration from an existing identity store. Include MFA, passkey or password fallback and at least one application per protocol. Confirm with each vendor how password hashes, group membership and disabled accounts migrate, and what happens to sessions during cutover. The step produces a pass or fail log per scenario, which becomes the strongest evidence in the final decision.
Document operator effort and recurring work
Estimate the ongoing work as a written record rather than an assumption. List the components each platform needs to run, such as application servers, a database with high availability, a worker or outpost, metrics and backups. Note the upgrade cadence published by each project, the security support window for each release line, and whether operator upgrades can be set to manual approval. Ask each vendor what the supported high availability design requires, and what a support subscription covers. The step is done when a named operator can explain the runbook for upgrades, backups and incident response, and that record goes into the decision file.
Decide and record the rationale
Score each candidate against the requirements, licenses, federation results and operator effort, then write a decision record that states which platform you chose, which alternatives you rejected and the conditions that would change the choice. Include open questions with the vendor, such as support terms, edition boundaries or roadmap commitments, and assign an owner to each. Where a feature is unconfirmed, say so and make it a condition of procurement. The record is complete when security, platform and procurement leads have each signed off on it, and it can serve as the starting point for an implementation scope.
What running a self-hosted IAM platform costs in people and time
The license fee is the smallest recurring line in a self-hosted identity stack. Keycloak is Apache-2.0 licensed, Zitadel is AGPL-3.0-only for its core, and authentik's core is MIT licensed, so none of them bills per instance. What you pay for is the people who keep the platform running: the engineers who patch and upgrade it, the database administrator who owns PostgreSQL or another supported database, the on-call rota that answers when sign-in fails, and the time spent on backups, restore tests and monitoring. Those costs are one-time at deployment and recurring after that. A quote should separate the one-time build (installation, realm or tenant design, identity provider wiring, hardening) from the recurring run work, and it should say who carries each line, your team or DeployOpen under a retainer.
Effort rises fastest with topology. A single node with an external database is a different job from a clustered deployment. Keycloak documents a high availability design that requires a synchronously replicated database, and Zitadel recommends a Kubernetes cluster with the official Helm chart for high availability. Upgrade cadence is the second driver. Keycloak plans four minor releases a year, and the Keycloak Operator documentation strongly recommends manual approval mode for operator updates to avoid unintended automatic upgrades, so someone must own each approval, test the change in staging and check the database migration, which Keycloak runs automatically at startup by default. Ask whether the quote includes a staging environment, a tested rollback path and a named owner for each upgrade window.
Before you sign, ask the vendor or partner to state, in writing: which database and version the platform will run on, whether high availability is in scope and how it is tested, who approves operator and container upgrades, how backups are scheduled and restore-tested, what monitoring and alerting covers, and who applies security patches and within what window. For authentik, also confirm whether enterprise-only features such as the Microsoft Entra ID integration are needed, since those code paths sit under a paid subscription. Written answers to these questions turn an open-source license into a comparable total cost across the three platforms.
Questions buyers ask before choosing or hiring help
Which open-source identity platform is cheapest to run?
No platform is cheapest in every case, because the running cost depends on the stack you already operate and the features you need. Keycloak and authentik core carry no license fee for the community code, but authentik enterprise features such as Google Workspace and Microsoft Entra ID integrations need a paid subscription, and the authentik pricing page lists Enterprise at $5 per user per month billed annually plus $0.02 per external user per month. Zitadel and Keycloak both need PostgreSQL or another supported relational database in production, and Keycloak high availability needs a synchronously replicated database. Model your cost around the database, the number of nodes, the people who patch and upgrade, and any subscription you need. Ask each vendor or partner for a written quote that lists those items separately.
How long does an identity pilot take, and what drives that time?
The pilot length depends on scope, not on the product alone. The main drivers are the number of applications to connect, the protocols each one needs (OpenID Connect, SAML 2.0, LDAP or proxy-based access), whether users come from LDAP or Active Directory, and how many external identity providers you must broker. Keycloak can federate users from LDAP or Active Directory and broker logins to external OpenID Connect or SAML providers, while authentik adds proxy and RADIUS providers. Test migration of existing users and passwords early, since that is often the longest step. DeployOpen agrees timelines in writing as part of a fixed-scope engagement, so ask for a scope document with milestones before work starts.
What does the work need from our internal team?
Your team needs skills in several areas, and the work runs best when each area has a named owner. Platform engineers run the containers or Kubernetes deployment and the database. Security engineers define the protocol settings, MFA rules and audit logging. Application owners register their clients and test sign-in. Keycloak documents a Kubernetes Operator that is installed through Operator Lifecycle Manager or kubectl, and the Keycloak Operator documentation recommends manual approval mode for operator updates, so someone must review upgrades. Plan for upgrade reviews, since Keycloak plans four minor releases a year. Confirm these responsibilities in the scope before signing.
Can our team deploy and run identity alone?
Many teams with strong platform and security skills can deploy a single identity platform alone, especially with the Docker Compose or Helm guides from each vendor. The harder parts are production database design, high availability, backup and restore, upgrade planning and integrations with HR or directory sources. Keycloak documents three high availability architectures, and each needs a synchronously replicated database, which many teams have not run before. Work out honestly whether your team has time for that learning curve during a live migration. If not, a fixed-scope engagement or a retainer for upgrades and testing can cover the gap, and the written scope should say which tasks you keep.
What does a paid enterprise tier add beyond the open-source edition?
Paid tiers add features and support, and the exact list depends on the vendor. On the authentik pricing page, enterprise-only features include Google Workspace and Microsoft Entra ID integrations, mTLS client certificate authentication, privileged access management, password history, enhanced audit logging and ticket-based support for subscriptions over $1k. The Enterprise Plus tier, which the page lists from $20k annually, adds dedicated support with SLAs, multi-instance deployment support and FIPS compliance for FedRAMP requirements. Zitadel offers a commercial license alongside its AGPL-3.0 code, so check its pricing page for the current terms. Compare each listed feature against your own requirements before you pay for a tier.
How do licenses affect hosting for our customers?
License terms decide whether you may offer the platform as a service to your own customers, and whether you must publish changes. Zitadel moved its core, Console and hosted login to AGPL-3.0 with v3.0 on 31 March 2025, and AGPL-3.0 has network-use obligations that legal counsel should review before you run modified code for users. Keycloak and FreeIPA use Apache-2.0 and GPL-3.0-or-later, respectively, and authentik core is MIT licensed while its enterprise directory needs a subscription. Have counsel review each license against your hosting model, your modifications and any embedded use, since this page does not give legal advice.
How does DeployOpen agree on fixed-scope identity work?
Most DeployOpen engagements are fixed-scope, which means scope, deliverables and timelines are agreed in writing before work starts. DeployOpen plans, implements, integrates, hardens, backs up, upgrades, documents and supports self-hosted platforms inside your own cloud accounts, data centers or air-gapped networks. It prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications, and independent auditors do that work. Ongoing support, upgrades and continuous testing are available as retainers. DeployOpen does not publish a price list, so a quote follows from the written scope. Ask for the list of assumptions, the client responsibilities and the change process before you sign.
How DeployOpen scopes an identity platform decision
DeployOpen plans, implements, integrates, hardens and documents self-hosted platforms inside the client's own infrastructure, whether that is a cloud account, a data center or an air-gapped network. For an identity decision, that means the work starts with the platform you choose and the environment it must run in, not with a product we already sell. DeployOpen does not favor Keycloak, Zitadel, authentik or any other platform on this page, and it is not an official partner or reseller of any of them. Our role is to help you test each option against your own requirements and then carry out the chosen one.
Most engagements are fixed-scope, so the scope, deliverables and timelines are agreed in writing before work begins. For this decision, the written scope is where your team should pin down the items that drive the outcome: the protocols each application needs (for example, SAML 2.0 for a legacy vendor app or OpenID Connect for internal services), the directories to federate, the database the platform must run on, the tenant model you need, and which paid features, if any, your controls depend on. Ask for each deliverable to be named, such as a configuration baseline, an integration test plan, a backup and restore runbook and an upgrade procedure.
DeployOpen also does not issue audit reports, attestations or certifications. When the identity platform supports a compliance assessment, we prepare the systems, controls and evidence, and the independent auditor or certification body makes the judgment. Before you sign a scope, confirm with your assessor which evidence they will accept, such as access review records, audit log retention and MFA enforcement settings, and make sure the written deliverables include producing that evidence.
How DeployOpen supports selection and implementation
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted identity platforms inside your own cloud accounts, data centers or air-gapped networks. For Open-source identity and access management compared, we help you match Keycloak, Zitadel, authentik and the other options to your protocols, tenancy model and licensing position, then build the chosen platform to your written scope.
How we scope
- We start with the identity use cases, protocols and identity sources your applications need, such as OIDC, SAML, LDAP or Active Directory.
- Scope covers the edition and license position you need, including which paid enterprise features you require and why.
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before any work begins.
How we build
- We deploy the chosen platform in your infrastructure, including the production database, high availability design and upgrade path.
- We configure realms, organizations or tenants, identity brokering and user federation to match your directory and application model.
- We test authentication flows, role mappings and failover, and document the configuration, admin procedures and backups.
How we hand over
- Handover includes configuration documentation, runbooks for administrators and the evidence your compliance assessors may request.
- We walk your platform and security teams through daily administration, upgrades and recovery before the engagement closes.
- Ask for a written list of deliverables, environments and acceptance criteria in your quote before work begins.
How we support
- Ongoing support, upgrades and continuous security testing are available as retainers after handover.
- Retainers can cover version upgrades, patch reviews and periodic testing of authentication and authorization paths.
- Confirm with DeployOpen which upgrade and support responsibilities sit with you and which sit with us before signing.
