Customer identity (CIAM) RFP questions

A credible partner covers more than the password login form. The test plan should include password and passkey login, token refresh, registration with email verification, password reset, and session logout, each weighted by its share of real traffic. Passkey ceremonies deserve their own scenario because the browser and authenticator round trips change the server profile. Ask for a written test plan that lists each flow, its expected share of peak traffic, the request mix and the pass criteria for latency and error rate. Refresh traffic often exceeds login traffic in mature apps, so a plan that tests only logins will understate the load.

The peak profile should come from the client's own traffic data, not from a generic benchmark. The partner should ask for historical login counts by hour, campaign or marketing launch dates, expected growth, and the ratio of new registrations to returning logins. From these inputs they should write a target profile with a sustained rate and a short burst rate, then get the client to sign it off in writing before testing starts. Illustrative example: a retail brand might plan for a flash sale that triples its normal login rate for ten minutes. A profile agreed in writing makes the results meaningful and prevents disputes after launch.

Ask the partner to name the load generator and explain why it fits the protocol mix. Common open source choices include k6, Gatling and JMeter, and each can script OIDC authorization code flows with PKCE, token refresh and form posts. The answer should also cover where the generators run, because load sources placed inside the same cloud region as the identity service can distort latency. Confirm that the test uses realistic user data, realistic token lifetimes and realistic bot or credential-stuffing traffic, since synthetic data that always hits a warm cache produces optimistic numbers.

The partner should show measured sizing, not a diagram. For Keycloak, the relevant evidence covers the supported database, connection pool sizing, and the cluster design, which must use a synchronously replicated database for the documented high availability designs. Ask which database engine was tested (Keycloak supports PostgreSQL, MySQL, MariaDB, Oracle, SQL Server and others) and whether the tested version matches the production version. For ZITADEL, ask for PostgreSQL sizing against the supported versions. Request CPU, memory, database connection counts, query latency and Infinispan cache behavior from the Keycloak cluster where it applies. Measurements from a comparable profile are the strongest answer.

Results should set concrete thresholds, not general statements. The partner should convert measured capacity into autoscaling triggers for the Keycloak or ZITADEL pods, connection pool limits, and rate limits on login, password reset and registration endpoints. Ask how rate limits are tuned so that legitimate peaks pass while credential stuffing is slowed. Good answers name the metric that triggers scaling, the saturation point at which the rate limit engages, and the test that proved it. A partner should also explain how the thresholds are rechecked after each upgrade or traffic change.

The partner should confirm that the identity platform exports metrics in a format the client's monitoring stack can scrape and alert on. For Keycloak, ask whether the metrics endpoint is enabled in production and which series are dashboarded, such as login success and failure counts, token issuance rate, latency percentiles and database pool usage. Ask for alert rules tied to these metrics and a runbook for each. The client should own the dashboards and alert definitions after handover, so the team can watch the next peak without the partner present.

Your team can run load tests if it has the tooling skills, test data and access to a production-like environment. The cost components are the test environment, the load generation infrastructure, engineering time for scripting and analysis, and repeat runs after each change. Those costs recur whenever the platform, traffic profile or database changes. Ask a partner for a quote that lists the test environment, the number of test cycles, the tools used, the written report and whether retest after fixes is included. DeployOpen plans and runs fixed-scope engagements, with scope, deliverables and timelines agreed in writing before work starts. Ongoing testing is available as a retainer.

Since Keycloak 26.0, the project plans four minor releases a year and a major release every two to three years, and it states that breaking changes in a minor release are opt-in. That lowers the risk of a routine minor upgrade changing behavior without warning, but it does not remove the need to test. Ask the partner which minor and major versions they support, how they track the Keycloak upgrading guide for each step, and which opt-in changes they have reviewed for your realms, clients and custom authenticators before any production change. The current release at the time of writing is 26.8.1, published October 13, 2026, so ask which version the first deployment will target and how the partner plans to move to later releases.

The partner should pin every ZITADEL deployment to a specific tagged release, such as the v4.19.5 release published on October 15, 2026, and move between tags only through a tested change. Ask how they read the release notes for each tag, how they map changes to your Helm chart values and database settings, and whether they run the upgrade against a copy of production data first. Because self-hosted ZITADEL runs on PostgreSQL 14 through 18, ask how the partner confirms database compatibility before each step. A credible answer names the tag, the test evidence and the rollback point rather than saying the team will track the latest release.

Manual approval is the safer default. The Keycloak Operator documentation strongly recommends manual approval mode for operator updates to avoid unintended automatic upgrades, because an update can change the running server version without a planned change window. Ask the partner whether they install the Operator through Operator Lifecycle Manager, how they set the approval mode in each cluster, and who approves each update after it has passed staging. The answer should also explain how a rejected or failed upgrade is held in place so that production stays on the last tested version.

Keycloak migrates its database schema automatically at startup by default. For large deployments, the upgrading guide suggests manual migration, where administrators apply the SQL themselves so that a DBA can review the changes and schedule them. Ask the partner which method they will use for your database, how long the schema step is expected to take in your environment (they should measure this in staging, since no general figure applies), and how they keep a copy of the schema before and after the change. Also ask whether the same schema procedure is used in every environment, so that production is not the first place a migration runs.

A rolling update replaces one node at a time, so that the remaining nodes keep serving logins while each replacement joins the cluster. This depends on the high availability design. Keycloak documents a single cluster optionally spread across availability zones and multi-cluster deployments, and both supported designs need a synchronously replicated database. Ask the partner to show the rolling procedure in writing, the order of node replacement, the health checks that gate each step, how user sessions are handled during the change, and the test results from a rehearsal in a staging environment that matches production topology. Ask also how they confirm that login, token refresh and admin console access work after each node is replaced.

A rollback plan names the point to return to before the change starts, the steps to restore it, and the time within which the decision to roll back must be made. For an identity platform, the most important rollback point is a verified backup of the database taken immediately before the schema change, together with the container images or chart values for the previous version. Ask the partner how they test the restore path, not only the backup, and whether they can return to the previous version without losing user data created during a partial upgrade. Clarify who has authority to call a rollback during the change window and how signing keys and client configuration are kept consistent if you must return to the earlier version.

Staging parity means the test environment matches production in the things that change how an upgrade behaves: software versions, database engine and version, cluster topology, realm and client configuration, identity provider federations, theme files and the volume of data. An upgrade that passes in a small, single-node test environment can still fail under production load or with a federated directory. Ask the partner how they keep staging in sync with production, how they copy or anonymize data for tests, and which upgrade paths they have rehearsed. Any red flag should be taken seriously: an upgrade planned as an in-place change without a staging run is a risk the buyer carries, not a detail for later.

Your team can run upgrades on its own if the procedures, runbooks and rollback steps are handed over in writing and your staff have rehearsed them. Cost depends on how much of that work the partner keeps: planning each release, testing it against your configuration, writing the change plan and handling rollbacks. DeployOpen offers ongoing support, upgrades and continuous testing as retainers, and most engagements are fixed-scope with scope, deliverables and timelines agreed in writing before work starts. Ask for a quote that separates the initial deployment from the recurring upgrade work, lists what is included in each release cycle, and states how emergency changes are priced. DeployOpen does not publish a price list, so the quote follows from the written scope.

Scope drives most of the cost: the number of applications, the number of B2B tenants and their identity providers, the volume of existing users to migrate, how deep the login page theming goes, and the login peak the platform must absorb. Each tenant with its own SAML or OIDC identity provider adds configuration, testing and a support path, so a partner should itemize those counts instead of quoting a single lump sum. Load targets matter because they set the size of the database, the cluster and the load testing effort. Ask for each driver listed as a separate line in the written scope, so you can see which choices move the price.

The initial build is one-time: architecture, installation, realm or organization design, identity provider federation, migration, theming, testing and handover. Recurring costs cover the infrastructure that runs the platform, monitoring, backups, security patching, platform upgrades and support. Keycloak plans four minor releases a year, so upgrades are a permanent line item, not a single event. Ask the partner to separate fixed-scope build fees from any retainer for ongoing support, upgrades and continuous testing, and to state what each retainer includes and excludes.

The timeline depends on the number of tenants and identity providers to onboard, the migration approach for existing accounts, the depth of login page customization, the high availability design, and how long compliance evidence and load testing take. Migration is often the longest item, because it involves reconciling user stores and validating logins against real traffic. Your team's review and approval cycles also set the pace. DeployOpen agrees timelines in the written scope before work starts, so ask for a milestone plan with named dependencies and the client decisions each milestone needs.

Expect to supply decisions and access rather than engineering time alone. You will need a named product owner who approves the customer journeys, registration and consent flows, and branding. Your security team should approve the authentication policy, token lifetimes, MFA and passkey rules, and the audit logging design. Your infrastructure team must provide the cloud account or data center, network paths, DNS, certificates and the production database platform, and your legal or privacy team must confirm the consent and data subject request process. For each of these, ask the partner to list the role, the expected effort and the date the input is needed.

Yes, many organizations take on parts of the work, such as theming, operating routine upgrades or managing day-to-day realm and client configuration, while a partner covers architecture, hardening, migration and high availability. The split depends on your team's experience with the platform and your staffing. Keycloak's documentation notes that the Operator should use manual approval mode for updates to avoid unintended upgrades, which shows why upgrade ownership must be agreed up front. Ask the partner which tasks they would hand over, what training and runbooks come with that handover, and who is accountable when a change breaks a login flow.

Ask for a written scope with numbered deliverables, the assumptions behind each estimate, and an explicit list of exclusions. The quote should state the counts it is based on: applications, tenants, identity providers, users to migrate, languages and themes, and target login peaks. It should separate one-time build work from recurring retainers, name the database and high availability design, and describe the acceptance tests for load, migration and erasure requests. Ask how change requests are priced and how a scope change affects the timeline. A quote without these elements is hard to compare across bidders, so request a revised quote if any element is missing.

Ask the partner to show a load test plan that uses your expected login peaks, names the tools and environment, and defines pass criteria before the test runs. For high availability, Keycloak documents a single cluster optionally spread across availability zones and multi-cluster designs, and both supported designs require a synchronously replicated database, so ask which design they propose and why. For upgrades, ask how they test a new minor release against your custom flows, whether they use manual schema migration for large deployments, and how they roll back. Keycloak's upgrading guide suggests manual migration for large deployments, so ask the partner to explain when they would use it.