Customer identity (CIAM) cost: build, partner or SaaS

The first split to make in any CIAM budget is between one-time work and recurring work. One-time work covers requirements, architecture, integration with your applications and customer data sources, migration of existing accounts, login and registration flow design, custom login UX, and launch testing. Recurring work covers hosting, the database, patching, upgrades, monitoring, load testing before peak periods, security testing and day-to-day support. Ask every bidder, including your own team, to price these two groups on separate lines so you can see what the platform costs in year one and what it costs in year three.

SaaS pricing shifts most of the recurring cost into the vendor's invoice, and that invoice grows with your users. Auth0 prices by monthly active users, defined as non-internal users who authenticated during a month for a given tenant, and Zitadel Cloud prices its Pro plan by daily active users with 25,000 included. Each fee tier is set by a usage count, so a growing customer base or a new B2B tenant model moves the bill even when the product does not change. For a self-hosted Keycloak or ZITADEL deployment, the recurring cost instead follows staff time, cloud or data center capacity that scales with login volume, database operations and the team that carries upgrades. Neither model is free to run, so compare them on the same user forecast for three years.

When you request quotes, ask partners to state the assumptions behind each recurring line: the peak login rate, the number of active users used for the forecast, the database and high-availability design, the upgrade cadence (Keycloak plans four minor releases a year, per the project's October 2024 release update), and the response times for security patches. Ask who pays for each item, whether the partner or your team. Confirm the SaaS plan's overage terms and what counts as an active user for your tenant model in writing before you compare totals.

The crossover point is the user count at which a SaaS bill, priced per active user, equals the total annual cost of running the same identity service yourself. To find it, plot two lines on the same chart. The SaaS line starts at zero and rises with every billable user. The self-hosted line starts higher, because it carries fixed costs such as the Keycloak or ZITADEL cluster, the PostgreSQL database that both platforms require, load balancers, backups, monitoring, certificates, and the staff time to patch and upgrade. Its variable part grows more slowly, mainly through compute and database capacity that scales with login volume. Where the lines cross is your break-even. Illustrative only: if a SaaS plan billed a flat rate per 25,000 monthly active users, the crossover would fall wherever your internal run cost divided across that tier equals the vendor's invoice. Use your own figures, not the example.

The crossover moves more than most teams expect. It shifts with growth, because a tier step can add a large block of cost at once while your internal costs rise in smaller increments. It shifts with login frequency, since per-user pricing usually counts identities while your infrastructure cost follows sessions, token issuance and step-up prompts. It also depends on how the vendor defines an active user. Monthly active users and daily active users are different units. Auth0 counts non-internal users who authenticated during a month, and Zitadel Cloud prices by daily active users, with its Pro plan listed at US$100 per month including 25,000 daily active users. The same population can produce very different bills under each definition. Enterprise tiers, which often bundle support, custom contracts and deployment options, can move the line again.

Before you rely on any figure, confirm current pricing directly with each vendor in writing, including how active users are counted, what triggers overage, whether custom domains or branding carry extra charges, and which features sit behind higher tiers. Then model your own user base, peak login rates and staffing assumptions, and ask a partner to put the self-hosted run cost into the same written scope as the SaaS quote so the comparison is like for like.

A fixed-scope quote for a self-hosted CIAM platform should list each component the work touches, so the reader can compare it line by line with a SaaS proposal. Start with environments: the number of non-production stages, where each runs (the client's cloud account, a data center or an air-gapped network), and who owns the promotion path between them. Then state the high availability design. For Keycloak, the supported designs are a single cluster optionally spread across availability zones or a multi-cluster deployment, and both depend on a synchronously replicated database, so the quote should name the topology chosen and the database engine. For Zitadel, it should name the PostgreSQL version and whether the Helm chart on Kubernetes is the deployment method. Confirm the supported versions with each vendor before signing.

The second group covers identity provider connections, migration and login experience. The scope should list each upstream provider (for example Entra ID, Okta, or a customer's own SAML or OIDC source), each federation path, and each user store to be migrated. For migration, ask whether password hashes move without forced resets, whether just-in-time migration is used, and how cutover and rollback are timed. Login UX work (branding, registration and recovery flows, passkey enrollment) should be itemized by screen or flow, not by hours. Testing, documentation, handover and support terms complete the list: load test scope, runbooks, knowledge transfer sessions, and whether support is a separate retainer. DeployOpen does not publish a price list. A quote follows from the written scope, most engagements are fixed-scope, and ongoing support, upgrades and continuous testing are available as retainers, so ask for the recurring and one-time costs to be separated.

Ask the partner to state what is excluded as clearly as what is included, such as customer-facing support hours, third-party SMS or email costs, and infrastructure the client provisions. Compare that exclusion list with the usage fees in a SaaS quote, which scale with monthly or daily active users. Confirm acceptance criteria for each deliverable, the change process for scope additions, and who holds the infrastructure keys after handover. A written scope with these items gives a clear basis for comparing build, partner and SaaS costs over the same period.