Self-hosted customer identity and access management

Open source customer identity and access management: when self-hosting fits

A product team that needs customer login, registration and passkeys, and possibly separate B2B tenants, usually has to choose between a per-user CIAM SaaS and running an open-source stack itself. The main open-source options are Keycloak (Apache-2.0), ZITADEL (AGPL-3.0) and Ory (Kratos and Hydra, both Apache-2.0), and the choice between them and against SaaS depends on three things: expected user scale, where customer data must physically live, and whether your team can operate an identity service around the clock. Self-hosting fits best when residency or contractual control of identity data is a hard requirement and you already run Kubernetes or equivalent infrastructure with people who can own upgrades. DeployOpen plans, implements, hardens and supports these stacks inside your own cloud accounts, data centers or air-gapped networks, so the operating model is yours rather than a vendor's.

Before comparing platforms, put numbers on the decision. Ask the product team for peak logins per second, the count of registered customers in three years, the number of distinct regions that must host identity data, and the expected count of B2B tenants with their own identity providers. Then ask the operations side who will receive pages at 2 a.m. when the login service degrades, and how many hours per month they can spend on upgrades. Per-user CIAM SaaS pricing scales with active users, so the economics shift as volume grows, while self-hosting shifts cost toward infrastructure, engineering time and on-call coverage. Confirm current pricing and feature tiers directly with each vendor, since these change and DeployOpen does not publish a price list.

Treat the passkey and consent requirements as scoping inputs, not later features. Passkeys depend on WebAuthn support in the chosen platform (ZITADEL's README lists FIDO2 and WebAuthn passkeys), and privacy obligations for customer identity data, such as consent records and deletion workflows, must be designed into the data model from the start. Check the following before shortlisting: which platforms in your target stack support passkeys and the MFA methods you need, how tenant isolation is modeled for B2B customers, and whether the license terms of each option (including AGPL-3.0 obligations if you modify the code and offer it over a network) are acceptable to your legal team. Where a platform has enterprise-licensed components, confirm which features sit behind that license before you commit.

Requirements to agree before choosing an open source CIAM platform

Customer identity platforms are hard to change once login flows, tenant structures and user stores are live. The decisions below shape which open source platform fits, how much it costs to run, and what must be built before launch. Agree them in writing with product, security, privacy and legal owners before comparing Keycloak, ZITADEL or Ory.

Peak login volume and availability

Decide the expected peak sign-in rate, including campaign spikes and batch re-authentication after a token event, and the availability target for login and token endpoints. Separate the two, because a login outage and a degraded profile page carry different impact. Ask each candidate platform how it clusters, how session storage scales and which database it requires. Load test against your own traffic shape rather than vendor claims, and confirm who is on call for the identity tier.

Single tenant or B2B organizations

Determine whether every customer shares one user directory or each business customer needs its own realm, organization, users, policies and administrators. Multi-tenant B2B identity affects data isolation, delegated administration and per-tenant login branding. Some platforms model tenants natively, while others require realms or separate deployments, so confirm the model before design. Ask how many tenants you expect in year one and how tenant onboarding and offboarding will be automated.

Branding and custom domains

Agree which login pages, emails and error screens customers see, and whether they must appear under your own domain rather than the identity provider's hostname. Custom domain support, theme customization and per-tenant branding differ across platforms and often need front-end work and a certificate process. Decide who owns templates, translations and accessibility testing. Confirm that the chosen platform's theming is supported in its current release line, not only in examples.

Consent and privacy obligations

List the personal data collected at registration and login, the lawful basis or consent recorded for each purpose, and the retention period for accounts, logs and consent records. Decide how users withdraw consent, export their data and request deletion, and which regional data residency rules apply. The identity platform stores the consent evidence, so its audit trail and retention settings belong in the privacy review. Involve legal counsel early, because these answers drive schema design.

MFA and passkey policy

Set which accounts must use multi-factor authentication, which factors are allowed, and whether passkeys (FIDO2 and WebAuthn) replace or supplement passwords. ZITADEL's README lists passkey support, and other platforms vary, so confirm passkey, recovery and step-up behavior for each candidate. Decide the account recovery path, since weak recovery often undoes strong authentication. Map the policy to the FTC Safeguards Rule's MFA requirement where your organization is a covered financial institution.

Existing identity providers to federate

Inventory social providers, enterprise identity providers over OIDC or SAML, and any directories such as LDAP or Active Directory that hold customer or partner accounts. Decide whether the CIAM platform brokers these sources, migrates users in place, or imports them at first login. Each choice affects password hash handling, account linking and the number of identity sources to monitor. Keycloak documents LDAP and Active Directory federation, so test these connections against your directory structure early.

Which open source CIAM platform fits which situation

This table compares Keycloak, ZITADEL and Ory Kratos with Ory Hydra on licensing, protocol and login features, operating effort and fit for multi-tenant B2B. Read each row against your own tenancy model, login requirements and in-house operating skills, because the cheapest license rarely decides the total effort.

Decision factor	Keycloak	ZITADEL	Ory Kratos with Ory Hydra
License	Apache-2.0, a permissive license with no copyleft obligation for hosted use	AGPL-3.0, so modifications offered over a network may need to be shared; confirm with counsel	Apache-2.0 for both components, a permissive license with no copyleft obligation
Core protocols	OpenID Connect, OAuth 2.0 and SAML 2.0 in one server	OpenID Connect certification, SAML 2.0 and SCIM listed in the project README	Hydra provides OAuth 2.0 and OpenID Connect; Kratos handles identity and user management
Passkeys and MFA	Confirm passkey and MFA options for your Keycloak version before scoping	Passkeys with FIDO2 and WebAuthn listed in the project README; confirm the flows you need	Confirm passkey and MFA support in Kratos for your target login journeys
Social login and brokering	Social login and identity brokering are supported out of the box	Confirm social and enterprise brokering behavior for your identity providers	Requires assembling the login and registration UI and provider connections yourself
Multi-tenant B2B	Realms and organization features can model tenants; confirm limits at your tenant count	Multi-tenancy is a core listed capability, a strong fit when each customer needs its own tenant boundary	Tenancy is not a packaged feature; design it into your data model and services
Operating effort	Clustering and upgrades are documented; plan for capacity tuning and realm sprawl	Single platform with its own service components; confirm deployment topology and upgrade path	Several services to deploy, secure and upgrade; most effort goes to integration code
Best fit	Teams that want a complete, widely used server with federation and brokering	Teams that need multi-tenancy, passkeys and SCIM with a modern API-first model	Teams with strong engineering capacity that want modular, composable identity services

How passkeys, consent and privacy shape the identity design

Passkey enrollment, account recovery, step-up authentication and consent capture are not add-ons to a customer identity design. They determine the data model, the event trail and the user journeys that the platform must support from day one. Teams that defer these decisions usually rebuild the login flows after launch. Keycloak, ZITADEL and Ory each cover parts of this, and the gaps differ by product, so the first task is to map every flow against the platform's documented capabilities and confirm them in a proof of concept.

Passkeys using FIDO2 and WebAuthn are supported in ZITADEL according to its README, which also lists MFA, SAML 2.0, SCIM and multi-tenancy. Keycloak and the Ory components should be tested for the same flows in your environment. The design questions are concrete: whether a user can register more than one passkey, what the recovery path is when a device is lost (a second passkey, a verified email or phone, or a support-assisted process), and whether that recovery path is itself a weaker factor that an attacker could abuse. Step-up authentication for sensitive actions such as changing a payout account or exporting records should be defined as a policy with named triggers, not left to application code.

Where customer data is health information or consumer financial information, two federal rules set baseline expectations. The HIPAA Security Rule at 45 CFR 164.312 requires access control with unique user identification, audit controls and person or entity authentication for systems that hold ePHI. The FTC Safeguards Rule at 16 CFR 314.4 requires multi-factor authentication for any individual accessing an information system at a covered financial institution, plus encryption and logging of authorized user activity. Consent records, data subject requests and retention rules then need to be stored and queryable. Confirm with your legal and compliance team which of these rules, and which state or sector rules, apply to your customer data before you choose a platform or design its schema.

Reference architecture components and how they connect

A customer identity deployment is a chain of components that must all survive a failure. The cards below cover the identity server cluster, its database, user stores, token issuance, the edge, secrets and SIEM export, and what each link needs for high availability.

Identity server cluster

The Keycloak, ZITADEL or Ory nodes handle logins, token issuance and admin calls, so they should run as a cluster behind a load balancer with health checks. Keycloak supports clustering, and the platform you pick determines how nodes discover each other and share session state. Check how the vendor handles session failover during a node loss and whether rolling upgrades can be done one node at a time. Confirm the exact clustering mechanism for your chosen release with the vendor documentation before you size the cluster.

Database and replication

Identity state such as users, clients, realms, credentials and sessions lives in a relational database, and that database is usually the hardest component to make highly available. Decide between a managed database with synchronous or cross-zone replication and a self-managed cluster, and test failover before go-live. Define backup and point-in-time recovery targets with the business, because restoring an identity database out of step with the token issuer causes confusing outages. Ask the implementation partner how schema migrations are rehearsed against a replica.

User stores and federation links

Customer records may come from the platform's own store, from an existing customer database, or from a directory synced through LDAP or SCIM. Each link adds a dependency: if the directory or source system is unreachable, logins or provisioning can fail in ways the cluster cannot hide. Document which store is the source of truth for each attribute, how password hashes are migrated, and what happens to users during a federation outage. Confirm the chosen platform's support for each federation protocol before you commit to it.

Token issuer and JWKS endpoint

The issuer publishes OpenID Connect discovery metadata and a JSON Web Key Set that relying applications and API gateways use to verify token signatures. Resource servers cache these keys, so key rotation must overlap old and new keys long enough for caches to refresh. Put the JWKS endpoint on the same highly available path as login, and test what relying parties do when it is unreachable. Ask the partner for a written key rotation runbook that names who approves a rotation.

Edge, load balancing and TLS

The edge terminates TLS for login pages, token endpoints and branded custom domains, and it applies rate limits and web application firewall rules to authentication paths. Certificates for each tenant or brand domain need an issuance and renewal process, and expired certificates are a common cause of sudden login failure. Confirm which headers the identity server trusts from the proxy, because a misconfigured trusted-proxy setting can break client IP logging and rate limiting. Keep the edge configuration in version control with the identity configuration.

Secrets handling

Client secrets, signing keys, database credentials and SMTP or SMS provider keys should not sit in configuration files or container images. A secrets manager such as OpenBao or Infisical can supply them at startup and rotate them on a schedule, and the identity platform must be able to reload rotated values without a full outage. Confirm the platform's supported secret injection method and whether signing keys can be stored in an external key manager. Note that HashiCorp Vault 1.15.0 and later is under the Business Source License 1.1, which is not an open source license, so check that choice against your licensing policy.

Log export to the SIEM

Authentication events, admin changes, failed logins, consent grants and token issuance records are the evidence that access control and audit controls are working. Ship them from every node to your SIEM over an encrypted channel, with clock sync across the cluster so events can be correlated. Define which events are retained, for how long, and who can read them, and verify that log shipping keeps working during a node restart. Ask the partner to show a sample alert for a burst of failed logins before go-live.

Build in-house, work with a partner, or buy per-user SaaS

This table compares running open-source CIAM yourself, running it with an implementation partner, and buying commercial CIAM SaaS across control, data location, effort, skills and cost structure. Read each row as a question to answer for your own environment, because the right model depends on how much customer data you must keep in place and how many people you expect to authenticate. The main takeaway is that SaaS pricing usually grows with users, while self-hosting moves cost into infrastructure, staff time and upgrades that you must plan for.

Factor	In-house open source	Open source with a partner	Commercial CIAM SaaS
Control over configuration	Full control over realms, flows, themes and upgrades, limited by your team's capacity	Full control, with the partner executing agreed scope under written terms	Control limited to vendor-exposed settings and APIs
Data location	Your cloud accounts, data centers or air-gapped networks	Your cloud accounts, data centers or air-gapped networks	Vendor-hosted regions; confirm available regions and data residency terms
Skills required	Identity protocols, clustering, database operations, security hardening, release management	Skills held by your team to review and operate, with specialist delivery from the partner	Vendor administration skills and integration development
Upgrades and patching	Your team plans, tests and applies each release	Partner can plan, test and document upgrades under a support arrangement	Handled by the vendor, with change timing set by the vendor
Cost structure	Mainly infrastructure, staff time and upgrade effort; software license cost depends on the chosen project	One-time implementation scope plus any retainer, plus infrastructure and staff time	Recurring fees that usually scale with the number of users; confirm the pricing metric in writing
Cost as user base grows	Infrastructure and operations usually grow in steps as capacity is added	Similar to in-house, with scope changes priced through the written agreement	Fees typically rise with each additional user, so model growth before committing
Time to first use	Depends on team readiness and scope; ask for a written plan	Scoped in writing before work starts	Often shorter for standard use cases, but custom flows and integrations still need effort
Best fit	Teams with established identity engineering and a steady operations capacity	Organizations that want open-source control but lack in-house depth for launch or hardening	Organizations that accept vendor hosting and per-user fees in exchange for less operational work

How a customer identity rollout runs, phase by phase

The sequence moves a customer identity program from requirements to a hardened, documented service that customers can log in to, with each phase closing on a named output that the next phase depends on.

Run discovery and capture requirements
Your product owners, security team and the DeployOpen engagement lead map which applications, brands and customer populations will use the identity service, including consumer users, business customers and their employees. The team records expected login volumes, peak patterns, required regions, data residency limits, and the regulations that apply to customer data in your sector. The step closes with a signed requirements document listing scale targets, availability expectations, authentication methods such as passwords, passkeys and social login, and the consent and privacy obligations that the design must meet.
Select the platform and prove it works
Using the requirements, the team compares Keycloak, ZITADEL and Ory, checking each against the features you need: OpenID Connect and OAuth 2.0, SAML 2.0, passkeys, multi-tenancy for B2B customers, and identity brokering. Licensing terms are confirmed in writing for your use case, since the three projects use different licenses. A proof of concept then runs one representative application and one tenant through login, registration and token flows. The step closes with a recorded decision, a list of confirmed capabilities, and any gaps that need a custom extension or a different platform.
Design branding and the login journey
Designers and engineers define the login, registration, password recovery and account recovery screens for each brand or tenant, including theming, localization and accessibility checks. The team maps each journey step, such as when MFA is offered, how passkeys are enrolled, and how users are redirected back to the application. Customer support staff review the flows for common failure cases. The step closes with approved journey diagrams and theme assets, and a test plan that covers every path a customer can reach.
Design consent and privacy controls
Privacy, legal and security staff decide which personal data each application receives as token claims, which consents are collected at registration, and how withdrawal of consent is handled. The design covers data minimization in tokens, retention of login and audit records, and the process for access and deletion requests. Your compliance lead confirms which regulations apply, because requirements differ by sector and jurisdiction. The step closes with a consent and data flow map, a claims catalogue for each client application, and a retention schedule approved by the data owner.
Integrate applications and tenants
Engineers register each client application, configure redirect URIs and token lifetimes, and connect any external identity providers or user stores through federation. For B2B use, they set up tenant isolation, tenant administrators and per-tenant branding. Automated configuration, such as infrastructure as code for realms or organizations, is kept under version control so that changes can be reviewed. The step closes when every in-scope application completes login and logout in a staging environment, and the configuration is stored in source control with a documented owner.
Test load and availability
Performance engineers simulate the login, token refresh and registration volumes set in the requirements, including the peak patterns identified during discovery. They test node failure, database failover and a rolling upgrade to confirm that sessions and tokens behave as designed in a clustered deployment. Results are compared against the availability expectations recorded earlier, and any gaps are fixed before cutover. The step closes with a test report showing measured results, the failure scenarios tested, and the remaining risks accepted by the owner.
Migrate existing customer accounts
The team inventories the existing user stores, confirms which password hashes can be imported, and decides whether users migrate in bulk, on first login, or through a mixed approach. Migration scripts are tested on copies of production data, and reconciliation reports compare counts and sample accounts between source and target. Customers who cannot migrate their credentials are guided through a reset path. The step closes with a reconciliation report signed by the data owner and a documented rollback plan.
Harden and hand over the service
Security engineers review the configuration against your baseline, covering TLS settings, admin console exposure, brute-force protection, signing key rotation, audit log export to your SIEM, and backup and restore. DeployOpen documents the runbooks, upgrade procedure and escalation paths, and your operations team runs a supervised handover exercise. The step closes with a hardening report, an operations handbook, and evidence that audit logs and access controls can be produced on request for your assessors.

Systems the CIAM platform must connect to

A customer identity platform is only as useful as the systems around it. The cards below cover the applications and APIs that rely on it, the user stores it must read from or migrate, the identity providers and delivery channels customers use, and the logging and secrets systems that keep it operable and auditable.

Customer-facing applications and APIs

Each web app, mobile app and API needs an OpenID Connect or OAuth 2.0 client registration, with redirect URIs, allowed scopes, token lifetimes and a decision on whether it is public or confidential. APIs usually need token validation rules for audience and scope, and some need token exchange between services. Check how each app handles logout, session refresh and step-up authentication for sensitive actions such as changing a payment destination. Inventory every client before the first cutover, because unregistered redirect URIs are a common source of login failures and open redirect risk.

Existing user stores and legacy directories

Most CIAM projects start with users who already exist in a database, an LDAP directory or an older identity product. The platform can federate these stores so users keep their accounts, or import them in bulk, and each option has different consequences for password hashes, account status and ongoing sync. Confirm which password hashing algorithms the source uses, whether the platform can verify them on first login, and who owns the source of truth after go-live. Keycloak lists LDAP and Active Directory user federation among its supported features.

Social and enterprise identity providers

Consumer logins often add Google, Apple or Microsoft accounts, while B2B tenants may need SAML 2.0 or OIDC connections to each customer's corporate identity provider. Each connection needs its own attribute mapping, domain rules and failure behavior when a partner's IdP is down. Keycloak supports identity brokering, and ZITADEL lists SAML 2.0 and multi-tenancy in its README. Ask your team which identity providers must be supported on day one and who manages each partner's configuration.

Email and SMS delivery for verification

Registration, password reset, one-time codes and passkey recovery all depend on outbound email and SMS. The platform needs an SMTP relay or API provider with authenticated sending domains, bounce handling and rate limits that protect against SMS pumping fraud. Plan the cost of SMS per country, since it is typically charged per message by a third-party carrier, and confirm the platform can use your chosen provider without custom code. Test delivery to the countries where your customers actually sign up.

SIEM for authentication logs

Login successes, failures, MFA challenges, account lockouts and password resets should flow into the SIEM so that the security team can detect credential stuffing and account takeover. The integration involves choosing between direct log forwarding, syslog or a log stream from the platform, mapping event fields to a common schema and deciding retention for personal data in those logs. Confirm which events the platform emits by default and which need configuration, and check whether IP addresses and user identifiers are masked before they leave the identity service.

Secrets store for client credentials

Confidential clients need client secrets, signing keys and database credentials that must not sit in configuration files or container images. A secrets manager such as OpenBao, Vault or Infisical can issue and rotate these values, and the identity platform must read them at startup without exposing them in logs. Check how signing key rotation works, how the platform reloads keys without downtime, and which secrets manager license fits your organization. Vault version 1.15.0 and later is licensed under the Business Source License 1.1, which the OSI does not classify as open source.

Questions to ask an implementation partner before you sign

Start with the questions that decide how the system behaves after go-live. Ask the partner how it will handle upgrade and patch cycles for the identity platform, whether that is Keycloak, ZITADEL or Ory, and how it will test a release in a staging realm or environment before it reaches production logins. Ask what its high-availability test plan covers: node loss during an active login, database failover, and a cache or session store outage. Ask for the recovery time and the test evidence it will produce, and ask how it will simulate a regional failure if your architecture spans zones. Vague answers such as "we have done this before" should lead to a written test plan in the statement of work.

Next, pin down the migration and the front-end work. If you are moving users from an existing CIAM, ask how the partner will move credentials: whether password hashes can be imported without forcing resets, how it will handle MFA enrollments and passkeys already on file, and how it will reconcile users who exist in two systems during cutover. Ask who owns branding, custom domain configuration, certificate issuance and the consent and preference screens, and whether those are in scope or billed separately. Request handover documentation that names the realm or tenant configuration, client registrations, custom themes, and the runbooks for backup and restore. Also ask what security testing of the login flows is included, such as brute force protection, account recovery abuse and token handling, and whether that testing is independent of the team that built the flows.

Finally, ask the partner to show how it would scope the work in writing. A credible proposal lists deliverables, the environments it will build, the integrations it will complete, the acceptance criteria for each phase, and what is excluded. Ask what support is included after go-live, how long it covers patches and incident response, and whether ongoing support is a separate retainer. Ask for the named roles on both sides, including who approves production changes. Confirm that the fixed-scope agreement states the exact handover items and that the quote is traceable to that written scope. If the partner cannot produce this document before you sign, treat that as the answer.

Common questions about open source customer identity cost, effort and rollout

What does open source customer identity actually cost compared with per-user CIAM pricing?

The software license is usually the smallest line item, because Keycloak, ZITADEL, authentik and Ory Kratos and Hydra are open source and carry no per-user fee in their core releases. The real costs are one-time: architecture, integration with your applications, branding, consent flows and migration. The recurring costs are the infrastructure you run, the people who operate it, and upgrades. Per-user CIAM pricing shifts those costs into a monthly bill that grows with your user base. To compare fairly, model infrastructure and staffing at your expected peak login volume, then set that against the vendor quote at the same volume. Ask any vendor for pricing tiers in writing, and confirm which features sit behind paid editions, such as the enterprise directory of authentik.

What drives the cost of a self-hosted customer identity platform up or down?

Five factors move the cost most:

Peak login and token volume, which sets the size of the cluster and database
Number of tenants if you serve B2B customers with separate organizations and branding
Number of identity sources, such as social login, enterprise SAML or OIDC connections, and LDAP or Active Directory federation
Compliance scope, since audit logging, retention and evidence collection add work
Custom flows, such as progressive profiling, step-up authentication or passkey enrollment rules

Each factor adds one-time build effort and recurring operating effort. Ask any partner to price each factor separately so you can see which one drives the total.

How long does a customer identity rollout take?

Duration depends on scope, not on the product alone. A single application with one login method and standard branding is a much smaller project than a multi-tenant B2B platform with enterprise federation, custom registration journeys and a migration of existing accounts. The phases are usually discovery, architecture, build and integration, testing, pilot and cutover, then handover. Migration of password hashes and user records is often the longest task because it depends on what your current provider exports. Do not accept a timeline before the written scope exists. Ask the partner to show which scope items drive each phase and what you must provide for each one.

What does our internal team need to provide for the rollout?

Expect to supply decisions and access, not just staff time. Typical inputs include a named product owner for login and registration policy, application owners who can change redirect URIs and token handling, a security reviewer for MFA and session rules, and someone who can approve the privacy and consent wording with legal. Platform engineering must provide cloud or data center capacity, DNS, certificates, a database service and a secrets store. Identify these owners before work starts and confirm their availability in the written scope. Missing owners are one of the most common reasons a fixed-scope timeline slips.

Can our own team run and operate the identity platform after go-live?

Yes, if your team has the skills and the capacity. Operating an identity platform means running a clustered service with a database, monitoring login availability, managing signing keys and certificates, rotating secrets, handling incident response and applying security patches. Your team needs people who understand OpenID Connect and OAuth 2.0 token flows, and who can read the logs when a login fails. Many organizations choose a split model in which their staff run daily operations and an implementation partner handles upgrades, testing and runbook updates on a retainer. DeployOpen offers ongoing support, upgrades and continuous testing as retainers, and the scope of each one is agreed in writing.

How are upgrades handled for a self-hosted identity platform?

Upgrades are a recurring task you should plan for from the start. Projects publish releases frequently, and you need a process to test each one against your login flows, custom themes and federation connections before production. For example, Keycloak 26.8.1 was published on GitHub on October 13, 2026, and that is the kind of release your team would need to evaluate. Build a staging environment that mirrors production, keep infrastructure as code for the cluster, and write rollback steps before each change. Confirm with the partner who tests each release, who approves it, and how long a security patch takes to reach production.

What should we check in licensing before choosing an open source identity platform?

Read the license of the exact component you plan to deploy, because open source platforms vary. Keycloak is licensed under Apache-2.0, ZITADEL under AGPL-3.0, and Ory Kratos and Hydra under Apache-2.0. authentik is MIT licensed except its enterprise directory, which carries a separate license. Copyleft terms such as AGPL-3.0 can matter if you modify the software and offer it to users over a network, so involve your legal team early. Also confirm whether features you need sit in a paid edition. Ask a partner to document which components and licenses are in the final architecture.

Which compliance evidence does a customer identity platform support?

An identity platform supports evidence for authentication, access control and logging obligations. Under the FTC Safeguards Rule at 16 CFR 314.4, covered financial institutions must implement multi-factor authentication for individuals accessing information systems and must log and monitor authorized user activity. Under the HIPAA Security Rule at 45 CFR 164.312, access control with unique user identification, audit controls and person or entity authentication apply to systems holding ePHI. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports or certifications. Independent auditors decide whether your controls meet each requirement. Ask your partner to map each control to a configuration, log source and owner before the assessment begins.

How DeployOpen scopes, builds, hands over and supports customer identity

DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source identity platforms inside your own cloud accounts, data centers or air-gapped networks. For customer identity, that means the login, registration, passkey and tenant design is agreed in writing first, then built, tested and handed over with the runbooks your team needs.

How we scope

Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
Scope lists the candidate platform, the applications that will use it, and the user populations, such as consumers, partners and business customers.
Scope records branding, consent and privacy requirements, and the peak login volume and availability target you must meet.

How we build

We deploy the chosen platform in your environment, configure realms or tenants, and connect your applications over OpenID Connect or SAML.
We configure passkeys, MFA, social or enterprise federation, and branded login pages to match the scope agreed with you.
Security testing of the login flows, APIs and account recovery paths runs before go-live, and findings are tracked to closure.

How we hand over

Handover includes architecture documentation, configuration records, and runbooks for backup, restore, upgrades and tenant onboarding.
We prepare the access control, authentication and audit log evidence your compliance team needs, without issuing any audit opinion.
Knowledge transfer sessions walk your operators through daily administration, incident response and the upgrade procedure.

How we support

Ongoing support, upgrades and continuous security testing are available as retainers after handover.
Retainers can cover patching of the identity platform, version upgrades, backup verification and changes to login flows.
Ask any partner to confirm response expectations and escalation paths in the written agreement before you sign.