Self-hosted open source SSO implementation

How open source SSO fits a regulated workforce identity estate

Open source single sign-on with Keycloak, authentik or ZITADEL is a self-hosted option for OIDC and SAML sign-on across workforce applications. For a regulated organization with a large application estate, a commercial identity provider under cost or control pressure, and auditors asking for proof of access control, the platform itself is rarely the hard decision. The harder questions are which protocols your applications actually need, how your directories are federated, and whether your team can run an identity service with the uptime and change discipline it requires. Those answers should drive the choice among the three, not feature comparisons.

Keycloak has the broadest protocol coverage among the three and supports OpenID Connect, OAuth 2.0 and SAML 2.0, plus LDAP and Active Directory user federation. authentik and ZITADEL are also credible options, and their licenses differ: authentik is MIT except for its enterprise directory, and ZITADEL is AGPL-3.0. Your legal and procurement teams should confirm which license terms and enterprise features apply to the modules you plan to use. Confirm the current release you would deploy against each vendor's release notes rather than relying on a version number from this page.

DeployOpen plans, builds, hardens and documents these platforms inside your own cloud accounts, data centers or air-gapped networks, so identity data and administrative control stay under your governance. DeployOpen prepares systems, configuration and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make those determinations. A useful first step is to inventory which applications need SSO, which protocols each one uses, and which identity sources must remain authoritative, then bring that inventory to a written scope before selecting a platform.

Which requirements to agree before choosing an SSO platform

Six decisions shape which platform fits: the protocols your applications speak, the directories you must federate, the strength of sign-in you must enforce, the uptime the business expects, how long sessions and tokens live, and the evidence auditors will request. Settle them in writing with their owners before comparing Keycloak, authentik or ZITADEL, because each choice narrows the field.

Protocols the application estate needs

Inventory every application and record whether it speaks OpenID Connect, OAuth 2.0 or SAML 2.0, and which version its vendor supports. Modern web and API applications usually take OIDC, while older line-of-business and some vendor products still require SAML. Keycloak, authentik and ZITADEL all list OIDC and SAML support in their documentation, but you should confirm each protocol against your own applications rather than assume coverage. Owner: enterprise architecture with application owners.

Directories to federate

List every user source that must authenticate people: on-premises Active Directory, LDAP directories, cloud directories and HR-fed accounts. Confirm which one is the authoritative source for identity, how group membership maps to application roles, and whether contractors or service accounts sit in a separate tree. Federation design determines whether the new platform reads users live, syncs them, or holds its own copies. Owner: directory services team with HR.

MFA methods, including passkeys

Decide which second factors are allowed for which populations, such as passkeys (FIDO2 and WebAuthn), authenticator apps, hardware keys and one-time codes, and what happens when a user loses a device. ZITADEL's documentation lists passkey support alongside MFA, and Keycloak and authentik offer their own factor sets, but the supported methods should be verified against your policy. The FTC Safeguards Rule requires multi-factor authentication for individuals accessing information systems at covered financial institutions. Owner: CISO with the identity team.

Availability targets and recovery

Define the uptime the business expects, the maximum acceptable outage for sign-in, and the recovery objective if the identity store fails. Sign-in is a shared dependency, so an outage blocks every connected application. Clustering, database replication and the network path to each directory all affect the design, and you should ask any partner to document how failover is tested. Owner: infrastructure leadership with business continuity.

Session and token policy

Set lifetimes for access tokens, refresh tokens and browser sessions, along with idle timeouts, re-authentication rules for sensitive applications and revocation behavior when an employee leaves. These settings decide how quickly access ends after termination and how often users are challenged. Confirm that each candidate platform supports the revocation and step-up behavior you need, because defaults differ between products. Owner: CISO with application owners.

Audit evidence the business must produce

Name the reports and logs your assessors will ask for: who signed in, from where, with which factor, which applications were granted, and when access was removed. Also decide where authentication logs are stored, how long they are retained, and who reviews them. HIPAA's technical safeguards at 45 CFR 164.312 call for unique user identification and audit controls, so these records should be designed before go-live. Owner: compliance lead with the security operations team.

Which open source identity platform fits which SSO estate

This table compares Keycloak, authentik, ZITADEL and Ory Kratos with Ory Hydra against the SSO estates they usually suit, along with licensing and operating effort. Read each row against your own application mix, directory sources and legal review constraints, because licensing terms differ by edition and by directory. The main takeaway is that the platform choice follows from your protocol needs, your directory landscape and how much integration work your team can carry after go-live.

Platform	Best fit for the SSO estate	Licensing implications	Operating effort to expect
Keycloak (latest supplied release 26.8.1)	Broad workforce SSO across OIDC, OAuth 2.0 and SAML 2.0 applications, with LDAP and Active Directory user federation and clustering for high availability	Apache-2.0 for the project as published. Confirm with counsel that no bundled or added components carry different terms in your build	Moderate to high. Realm, client and federation configuration is extensive, and clustering, upgrades and database tuning need a named owner
authentik (latest supplied release 2026.8.4)	Workforce SSO with OIDC and SAML onboarding, a web-based admin console, and proxy-style protection for applications without native SSO support	MIT for most of the codebase, but the authentik/enterprise directory uses a separate enterprise license. Confirm which features you need before you deploy them	Moderate. Flows, stages and policies are flexible, so the team should document the configuration early and test changes in a staging instance
ZITADEL (latest supplied release v4.19.5)	Workforce or multi-tenant SSO with SSO, MFA, passkeys (FIDO2 and WebAuthn), OpenID Connect certification, SAML 2.0 and SCIM provisioning	AGPL-3.0. Network-facing modifications may trigger source disclosure duties, so legal review is required before you modify or host it for internal users	Moderate. Multi-tenant concepts add design decisions for organizations and projects, and the team should plan SCIM mappings from the start
Ory Kratos with Ory Hydra (both released v26.2.0 on March 20, 2026)	Teams that want identity handled separately from authorization, with Hydra acting as the OAuth 2.0 and OpenID Connect server in front of Kratos for user management	Apache-2.0 for both services. The licensing is simple, but the two services and their login and consent flows must be integrated and maintained together	High. Two services, a separate login and consent application and a custom admin experience mean more integration code and more components to patch
Directory federation	Keycloak and authentik both support LDAP and Active Directory sources for workforce identity. Confirm which attributes, groups and nested group behavior your directory exposes	Licensing is generally unaffected by the directory source, but confirm enterprise features needed for your directory with the vendor	Plan a one-time mapping exercise for attributes and groups, then a recurring check when the directory schema or group structure changes
SCIM provisioning	ZITADEL includes SCIM in its feature list. For other platforms, confirm whether SCIM is native, provided by an extension or delivered through a separate IGA tool	Check whether SCIM connectors fall under community or enterprise terms before you commit to a design	Recurring effort to keep provisioning mappings aligned with HR and application owners. Joiner, mover and leaver rules often need a separate governance platform
Standards and certification evidence	ZITADEL lists OpenID Connect certification in its README. For other platforms, ask each vendor or community for current conformance evidence before you rely on it in an assessment	Conformance statements are not a substitute for your own test results. Keep records of the version tested and the configuration used	Recurring effort. Retest after each upgrade, and file the results as access control evidence
Access control evidence for auditors	Admin event logs, client and role definitions, MFA enforcement policies and sign-in records are the core inputs for access control reviews under HIPAA and the FTC Safeguards Rule	Licensing does not change the evidence you need, but enterprise logging or retention features may be licensed separately. Confirm this before you design log retention	Recurring effort to export logs, review admin changes and confirm MFA coverage for each application. Assign an owner for this evidence from day one

What a reference SSO architecture contains

A workforce SSO deployment is a chain of components, and each one is a point of failure for every application behind it. The six components below connect in a fixed order: traffic enters through the edge, reaches the identity provider cluster, reads and writes state in the database tier, and reaches the directories and MFA services that verify who the user is. Confirm the clustering and extension details for your chosen product before you finalize the design.

Identity provider cluster across two zones

Run at least two identity provider nodes in separate availability zones or data centers, with sessions and cache shared through the product's clustering mechanism. If the cluster loses quorum or its only zone fails, every OIDC and SAML relying party loses sign-in at once, so the failover test matters more than the node count. Keycloak, authentik and ZITADEL each use different clustering and session models, so confirm the exact clustering topology, session replication and supported zone layout with the vendor docs and your own load test before sizing.

Database tier with tested recovery

The identity provider stores users, clients, realms or tenants, sessions and audit-relevant configuration in a relational database. Use a replicated database with automated failover, and confirm which tables hold session state, since losing sessions forces mass re-authentication while losing configuration can break every application integration. Ask the vendor and your DBA for the supported database engines and version combinations, then rehearse a point-in-time restore against the configuration your auditors will ask about.

Reverse proxy and TLS termination

A reverse proxy or load balancer terminates TLS, enforces modern cipher policy, forwards only the paths the identity provider needs, and blocks administrative endpoints from the public internet. It is also the place where health checks remove a failed node from rotation. If this tier fails, users see errors even when the identity nodes are healthy, so it needs the same redundancy as the nodes behind it. Record certificate ownership and renewal dates, because an expired certificate at this layer stops sign-in for every application.

Directory federation connectors

Federation connectors read users and groups from Active Directory, LDAP or an HR-driven source and can either import or sync attributes on a schedule. Decide which system is the source of truth for each attribute, because a disabled account in the directory must stop SSO sessions within a defined window. Test disabled, moved and deleted accounts explicitly, and confirm how each product handles group-to-role mapping and attribute updates during a directory outage.

MFA and passkey tier

The MFA tier handles TOTP, WebAuthn and FIDO2 passkeys, and it must sit inside the authentication flow rather than beside it. Define which applications require a second factor, how enrollment and recovery work, and what happens when the MFA service is unreachable, since a fail-open setting quietly removes the control. Confirm which factor types each product supports natively and which need a plugin or extension, because extension models vary and affect upgrade effort.

Logging and metrics export to the SIEM

Authentication events, administrative changes, failed logins and token issuance should flow to the SIEM as structured logs, with metrics for latency, error rate and session counts exported to monitoring. These logs are the evidence that access is recorded and reviewed, so confirm the event catalog each product emits and whether administrative actions are captured separately from user activity. If the export pipeline stops, sign-in may keep working while the audit trail silently stops, so alert on the pipeline itself.

How SSO connects to directories and applications

Directory federation lets the SSO platform read user identities and group memberships from an existing store, such as Active Directory or an LDAP directory, or hand the login off to an existing cloud identity provider through brokering. Keycloak supports LDAP and Active Directory user federation and identity brokering, and ZITADEL and authentik also support directory and upstream identity provider configuration. Confirm the exact federation and brokering options for your chosen version with the vendor documentation before design.

Service account and read scope: The platform needs a bind account with the minimum read rights to users and groups. The directory team usually owns this account and its password rotation.
Attribute mapping: Fields such as sAMAccountName, userPrincipalName, mail and group DNs must map cleanly to platform attributes. Mismatches here cause silent login failures or users landing in the wrong roles.
Certificate rotation: LDAPS and brokering endpoints rely on certificates. An expired internal CA certificate is a common cause of outages that look like password problems.
Clock skew: SAML assertions and Kerberos-related flows are time-bound. Drift between servers can reject valid logins, so confirm NTP sources on every node.
Ownership: The directory team owns the source data and the bind account, while the security team owns the mapping rules and the evidence that they were reviewed.

Before go-live, confirm which user attributes are authoritative and who signs off on changes to them.

Should you build SSO in-house, use a partner, or buy SaaS

This table compares three ways to run workforce single sign-on: in-house on open source, open source with an implementation partner, and commercial SaaS identity. Read each row as a question to answer for your organization, then check which cost components move to your team under each model. The main takeaway is that open source removes license fees but not the operating work, so the decision turns on who carries upgrades, on-call duty and audit evidence.

Factor	In-house on open source	Open source with a partner	Commercial SaaS identity
Data residency and keys	Your team controls where identity data and signing keys live, including on-premises or in your own cloud accounts	Your infrastructure hosts the platform and keys, with the partner working inside your environment under agreed access terms	Identity data and keys sit with the vendor; confirm regions, key custody and export options in the contract
Skills and on-call burden	Requires staff who can run Keycloak, authentik or ZITADEL clusters, troubleshoot OIDC and SAML flows, and respond to outages	Your staff own operations and on-call; the partner supplies design, hardening and support under a written scope	Vendor runs the service; your team handles configuration, application onboarding and vendor incident reviews
One-time costs	Architecture, build, integration with directories and applications, and initial security testing	Scoped design, implementation, migration, documentation and handover, agreed in writing before work starts	Tenant setup, connector configuration, migration effort and internal training
Recurring costs	Staff time for patching, monitoring, backups, capacity and access reviews, plus infrastructure	Infrastructure, your internal operations time, and any support or upgrade retainer	Per-user or per-tenant subscription, plus internal administration and vendor management
Upgrade and patch cadence	Your team tracks releases such as Keycloak 26.8.1 and plans its own test and rollback cycle	The partner can plan and test upgrades, but you approve change windows and production timing	Vendor applies updates on its schedule; you verify integrations and review release notes
License model to confirm	Open source licenses such as Apache-2.0 (Keycloak) or MIT with enterprise directories (authentik); confirm which features sit in paid tiers	Same open source licenses plus any enterprise license the design needs; confirm in writing which components are covered	Subscription terms, feature tiers and data processing terms; no open source license applies
Exit path	Exit is mostly internal: export realm or tenant configuration, user stores and client definitions to your own tooling	Documented configuration and runbooks let you move operations in-house or to another partner if the scope allows	Depends on contract terms, export formats and migration help; test an exit plan before you need it
Audit evidence	Your team produces access control records, MFA enforcement reports and review logs for assessors	Partner prepares controls, runbooks and evidence templates; your organization owns the operating records	Vendor supplies some attestation reports; you still need your own access review and application onboarding evidence

How an SSO rollout runs from pilot to migration

The sequence moves an SSO platform from a documented design to a tested pilot, a phased set of onboarded applications, and a handover the client's own team can operate and audit. Each phase closes with a named output, so the client can see what is finished before the next phase starts.

Confirm requirements and the architecture decision
DeployOpen works with the identity, security and application owners to record which applications need SSO, which protocols each uses (OIDC, SAML or both), where the user directory lives, which MFA methods are required, and where the platform will run. The candidate platforms (Keycloak, authentik or ZITADEL) are compared against those requirements, including licensing and the enterprise components each one reserves. The output is a written requirements register and an architecture decision record that names the platform, hosting model and directory sources. The step is done when the client's security and identity leads sign the decision.
Build the lab and test federation and MFA
DeployOpen builds a non-production instance inside the client's own infrastructure and connects it to a test directory copy, such as LDAP or Active Directory federation. Test cases cover login flows, token lifetimes, group-to-role mapping, MFA enrollment and fallback, session timeouts, and certificate rotation for SAML signing keys. Failures are logged and fixed before any production user touches the system. The output is a lab test report with pass and fail results per case, plus the configuration as code so it can be reproduced. The step closes when every mandatory test case passes or has an accepted, documented exception.
Run a pilot with a small application set
A limited group of users signs in through the platform to a small set of applications chosen for their range of protocols and risk, for example one OIDC application and one SAML application. The pilot includes a written rollback plan that states how users return to the existing login path, who decides to roll back, and how sessions and tokens are revoked. Logs from the pilot are reviewed for failed logins, unexpected redirects and MFA problems. The output is a pilot results summary, a rollback runbook that has been rehearsed, and a go or no-go decision recorded by the client.
Onboard applications in controlled phases
Applications are onboarded in waves grouped by owner, protocol and business criticality. For each application, DeployOpen configures the client, redirect URIs, attribute and claim mappings, and role assignments, then tests sign-in with named application owners. Pace is set by how many applications each team can validate, how much custom code needs changing, and how many vendors must be engaged for their SAML or OIDC settings. The output per wave is an onboarding record for each application, including owner sign-off and the access policy applied. The wave closes when its applications run on SSO and the owners have confirmed their test results.
Migrate from a commercial identity provider with parallel running
When the organization is replacing a commercial identity provider, both systems run in parallel for a defined period. Applications are switched one at a time, the old provider remains available for fallback, and user attributes, group memberships and MFA enrollments are reconciled between the two. Password hashes and MFA secrets are generally not portable between products, so the migration plan states how users re-enroll and how that step is supported. Pace depends on the number of applications, the complexity of custom integrations and the amount of user data to reconcile. The output is a reconciliation report, a cutover plan with a dated checklist agreed by the client, and a confirmed fallback path. Cutover is complete when all in-scope applications authenticate only through the new platform.
Test high availability and failover
DeployOpen deploys the platform in the clustered topology agreed during design and tests node loss, database failover, load balancer behavior and session continuity. Each test records the observed behavior against the recovery expectations the client set for sign-in availability. Tests also cover backup restoration into a separate environment, since a backup that has never been restored is not proven. The output is a failover test report with results, timings observed in the test environment, and a list of any gaps with owners. The step is done when the client accepts the results or the gaps have a scheduled fix.
Hand over runbooks and audit evidence
DeployOpen delivers runbooks for routine operations such as user and client administration, certificate and key rotation, upgrades, backup and restore, incident response for sign-in failures, and emergency access. The client's operators are trained on these procedures and perform at least one routine task while DeployOpen observes. The evidence pack contains the access control configuration, the MFA policy, the role model, the access review procedure, and the logs and test results that show the controls work. Compliance teams can use it to prepare for assessments, but DeployOpen does not assess or certify the controls. The handover closes when the client's operations team signs acceptance and ongoing support, if any, is set in a separate written agreement.

Which compliance evidence SSO helps produce

A workforce SSO layer sits in front of most regulated applications, so it is often the first place assessors look for proof of who can get in and how. The cards below cover the evidence areas that SSO configuration and logs can support, and what each artifact looks like. DeployOpen prepares systems and evidence for assessments, but independent auditors issue any opinion.

Unique user identification

Every workforce user should map to one identity, with no shared or generic accounts. Under the HIPAA Security Rule at 45 CFR 164.312, unique user identification is a required access control. Evidence includes the user directory export showing one record per person, the federation mapping from the HR source, and a list of any service or break-glass accounts with their owners. Check how the realm or tenant handles duplicate usernames and email aliases across directories.

Person or entity authentication

Authentication evidence shows that the identity provider verified the person before granting a session. Under the same HIPAA section, you need to show how the sign-in flow establishes that a user is who they claim to be. Keep exports of authentication flows and their bindings to each application, plus OIDC and SAML client configurations that show which protocols and redirect URIs each application trusts. Confirm with the assessor which proof they expect for service-to-service authentication.

MFA enrollment and enforcement

The FTC Safeguards Rule at 16 CFR 314.4(c) requires multi-factor authentication for any individual accessing any information system. Evidence includes the MFA policy export, enrollment reports showing each user's factor type and enrollment date, and sign-in logs that show a second factor was required. Check whether exceptions exist for legacy clients, API paths or specific groups, because each exception will need a documented reason and an owner.

Authorized user activity logging

The same Safeguards Rule provision expects institutions to monitor and log the activity of authorized users. For SSO, that means successful and failed sign-ins, token issuance, consent grants, and administrative changes exported to a central log store. Confirm the event types your identity platform emits, the retention period your policy requires, and whether logs are shipped off the identity host so an administrator cannot alter them unnoticed.

Admin change history

Assessors often ask who changed an application, a role or a policy, and when. Evidence includes admin audit logs, configuration-as-code commits or exports taken on a schedule, and change tickets linked to each modification. Check that the platform records changes to realms, clients, identity providers and authentication flows, and that these records are protected from edits by the same administrators whose actions they record.

Access review and onboarding records

Access reviews show that application access is still justified. Evidence includes onboarding and offboarding tickets that trigger application assignment, periodic group membership exports signed off by application owners, and records of disabled accounts after a leaver event. Confirm the review cadence with your assessor, and decide whether reviews run inside the SSO platform or in a separate identity governance tool that reads its group data.

What to ask an SSO implementation partner before signing

Start with scope, because most SSO projects drift on it. Ask the partner to list every protocol and application in the first wave, whether each one uses OIDC, SAML 2.0 or a legacy pattern that needs a proxy, and which directories will be federated, such as Active Directory through LDAP user federation or an upstream identity provider. A credible answer names the realm or organization structure, the attribute mappings, the group-to-role model and the applications explicitly out of scope. DeployOpen scopes SSO work in writing before any work starts, so ask for that written scope to list the applications, directories, MFA methods and deliverables by name. If a partner cannot name them before the contract is signed, the cost and timeline will move after it.

Next, ask how the migration from your current identity provider will run. The partner should describe parallel running, in which both providers accept logins for a defined set of applications while redirect URIs, client secrets and session lifetimes are cut over one by one, along with a rollback path for each cutover. Ask how they will handle password hash migration, enrollment of existing MFA factors and users who are only in the old directory. On resilience, ask for the high availability design (a clustered deployment with a shared database, load balancing and session handling), the failover tests they will run before go-live, and the results they will hand over. A partner who cannot describe a test that actually stops a node during a login flow has not tested failover.

Finally, press on evidence, ownership and the license. Ask which access control evidence they will produce for the assessor, such as the application inventory, MFA enforcement settings, administrator role assignments, session policy and login audit logs retained in your SIEM, and how each item maps to the access control and authentication requirements of your frameworks. Be clear that DeployOpen prepares this evidence but does not issue audit reports or certifications. Ask who applies upgrades and security patches after go-live and on what notice, and how they handle the license: Keycloak is Apache-2.0, authentik's core is MIT but its enterprise directory has a separate license, and ZITADEL is AGPL-3.0, which can carry obligations if you modify and distribute it. Have counsel review the answer. Last, ask what happens when scope changes: the change should be priced and documented in writing before it is built.

How long, how much and what effort do buyers ask about open source SSO

What drives the cost of an open source SSO implementation?

The software license is usually zero for the core products, so cost comes from people, infrastructure and integration work. The main drivers are the number of applications to onboard, the protocols they need (OIDC, SAML or both), the directories to federate, how many MFA methods must be supported, and whether high availability and disaster recovery are required. Infrastructure is a recurring cost you pay in your own cloud or data center. Ask any quote to split one-time work (design, build, application onboarding, migration) from recurring work (upgrades, patching, monitoring, support) and to state the assumed application count and directory sources in writing.

Can our internal team deploy open source SSO without a partner?

Many teams can, provided they already run Linux, containers or Kubernetes, a relational database and a reverse proxy, and have engineers who understand OAuth 2.0, OpenID Connect and SAML. The harder parts are usually not the installation but the operating model: clustering, certificate rotation, upgrade testing, audit logging, and onboarding every application owner. Consider a partner for the first rollout, a documented runbook, or a review of the design before go-live, and keep the ability to run upgrades in-house. Your decision should rest on the skills you can staff and keep, not on the product choice alone.

What does the work need from our side before it starts?

Expect to provide read access or a service account to the directories being federated, such as Active Directory or LDAP, and a named owner for each application that will sign in through SSO. You will also need admin staff who can approve changes, a change window for cutover, network paths between the identity service and each application, and a decision on who holds production admin rights afterward. Missing any of these usually delays the schedule more than the technical build does. Confirm these items in the written scope so both sides know who does what.

How long does an SSO rollout take and what sets the pace?

The timeline depends on the number of applications, how many use protocols that are straightforward to onboard, how many directories must be federated, and how quickly application owners can test and approve changes. Application onboarding is typically the longest phase because each owner has its own testing and change process. Compliance evidence collection and change approvals can also extend the schedule. Ask for a phased plan with milestones and dependencies, and treat any single overall duration offered without a written scope as unverified.

Should we choose Keycloak, authentik or ZITADEL?

All three support OpenID Connect and SAML, and each is open source, but their licenses and feature sets differ. Keycloak is Apache-2.0 licensed, a Cloud Native Computing Foundation incubation project, and supports LDAP and Active Directory user federation and clustering. authentik is MIT licensed except its authentik/enterprise directory, which carries a separate license. ZITADEL is AGPL-3.0 licensed and lists SAML 2.0, SCIM, passkeys and multi-tenancy among its features. Compare them against your required protocols, federation sources, licensing obligations for your use, and the skills your team already has, then test your top two with a proof of concept.

What does ongoing support and upgrade work involve?

After go-live, someone must patch the operating system and container images, apply identity platform releases, rotate certificates and signing keys, review logs, and test every upgrade against your applications before production. Plan for a regular upgrade cycle, a staging environment that mirrors production, and a documented rollback path. Support can be run by your staff, by a partner through a retainer, or split between them. Ask any provider to describe the upgrade process, the support hours and the escalation path in writing, since these are the terms that determine recurring effort.

How do we plan a migration from a commercial identity provider?

Migration usually runs in parallel rather than as a single cutover. Start by inventorying every application, its protocol, its claims and its user-matching logic, then build the open source service alongside the existing provider. Move applications in waves, starting with low-risk ones, and keep a fallback path until each wave is stable. Credential migration is the sensitive step: password hashes often cannot be exported, so plan for user re-enrollment, passkey registration or staged federation. Confirm with the vendor and your security team what can be exported, and record approvals for each wave as migration evidence.

How DeployOpen scopes, builds, hands over and supports SSO

DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source identity platforms inside your own cloud accounts, data centers or air-gapped networks. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.

How we scope

Inventory every application to onboard, its protocol (OIDC, OAuth 2.0 or SAML 2.0) and its owner
Confirm directory sources, such as Active Directory or LDAP, and which attributes and groups must flow to each application
Agree in writing which MFA methods, high availability targets and migration waves are included before work starts

How we build

Deploy the chosen platform, such as Keycloak, authentik or ZITADEL, in your environment with the high availability design agreed in scope
Configure client onboarding, federation, MFA policies and session settings, then test each application login and logout path
Document configuration as code where practical and run security testing against the identity endpoints before go-live

How we hand over

Deliver architecture diagrams, runbooks for onboarding new applications, and configuration records for each realm or tenant
Provide access control evidence packs, such as application access lists, MFA enrollment settings and admin audit log configuration, mapped to your compliance requirements
Walk your administrators through daily operations, backup and restore steps, and upgrade procedures before closing the engagement

How we support

Offer ongoing support, upgrades and continuous security testing as a retainer, scoped separately from the build
Patch and upgrade the identity platform on a schedule agreed with your change management process
Review access control evidence with your auditors or assessors, while the audit opinion itself stays with those independent parties