Why open source citizen identity for public sector is different
An agency running citizen login needs one trusted account that works across benefits, tax, licensing and permit services, and it must prove three things to auditors and the public: the assurance level of each login, that the service is accessible, and that citizen data stays where the law requires. Citizen identity is not workforce single sign-on with more users. Staff come from a directory the agency controls, while citizens arrive with national eID credentials, regional accounts and mobile identity wallets that the agency does not issue. Commercial customer identity platforms add a second constraint: many public bodies must run the identity service on government infrastructure, under procurement and lawful-access rules, rather than in a vendor's cloud. For most of these requirements, Keycloak is the most common fit among open-source options, because it supports OpenID Connect, OAuth 2.0 and SAML 2.0, identity brokering to external identity providers and user federation. ZITADEL and Ory are credible alternatives when the design depends on multi-tenancy for many agencies or on API-first control, and the choice should follow those needs rather than a general preference.
Start with assurance. The NIST SP 800-63 digital identity guidelines define identity assurance levels for identity proofing, authentication and federation, and each citizen service should be assigned a level before the platform is selected. The levels are not restated here, so confirm the current wording and requirements directly against the NIST publications and the agency's own legal basis, then map each authenticator type, including passwords, OTP, passkeys and eID-backed login, to the level it can support. Next, check the eID integration path. Brokering a national scheme through an OIDC or SAML connection in Keycloak needs the scheme's metadata, signing keys, attribute mapping and a decision on where identity proofing happens. Finally, confirm where the platform runs. Hosting in the agency's data center or a sovereign cloud region, with the database, backups and logs in the same jurisdiction, is a design decision that affects the rest of the architecture and should be settled before any vendor or partner is asked for a quote.
Which requirements shape a citizen identity build
This table maps each public sector requirement to the source that creates it and the build decision it forces on a citizen login platform. Read it row by row before choosing an assurance design, hosting model or accessibility plan, because several rows depend on who operates the service and what data it touches. Confirm applicability with counsel and your assessor, since a requirement that binds one agency may not bind a neighboring one.
| Requirement | What it asks for | Build impact |
|---|---|---|
| NIST SP 800-53 baselines (low, moderate, high) | SP 800-53B selects 149, 287 and 370 controls and enhancements for low, moderate and high baselines in Release 5.2.0 | Choosing the baseline sets the MFA, logging, configuration and continuity controls the identity platform must evidence. Moderate or high baselines usually push you toward dedicated audit log retention and tighter change control. |
| FISMA and Inspector General assessment | Agency systems are independently assessed by Inspectors General, who report to OMB | Expect assessors to test the identity platform as an agency system. Keep configuration baselines, access reviews and incident records in a form an independent reviewer can sample without help from the build team. |
| FedRAMP scope under M-24-15 | Cloud products that process federal information on behalf of an agency, offered as a shared service, fall in scope; single-agency systems on cloud infrastructure may not | Whether you host in a public cloud decides if an authorization is needed. Confirm with the agency whether a citizen login run for one agency is a shared service, since that answer sets the hosting options. |
| CJIS Security Policy v6.1 encryption and scanning | FIPS 140-3 validated modules or FIPS 197 AES with at least 256-bit keys for CJI in transit and at rest outside physically secure locations, and vulnerability scanning at least monthly | Applies where login links to criminal justice data. Plan for validated cryptographic modules in the identity stack, key lengths on every connection, and a monthly scan schedule covering the identity servers and their database. |
| 32 CFR 2002.14(h)(2) and NIST SP 800-171 for CUI | Federal agencies apply NIST SP 800-171 to controlled unclassified information on non-federal systems unless the CUI category sets other safeguards | If citizen records carry CUI and run on contractor or partner infrastructure, the operator inherits SP 800-171 requirements. Confirm the CUI categories with the agency before fixing the audit log, access and encryption design. |
| 28 CFR 35.200 WCAG 2.1 Level A and AA | State and local government web content and mobile apps, including contracted ones, meet WCAG 2.1 Level A and AA from 26 April 2027 for entities serving 50,000 or more people and from 26 April 2028 for smaller entities and special districts | Login, registration, MFA prompts and recovery screens are all in scope. Budget for accessible custom login themes, keyboard and screen reader testing of every authentication step, and an accessible alternative to image-based or timed challenges. |
| NIS2 public administration scope | Central government entities are covered regardless of size; Member States may extend coverage to local administration; national security, public security, defense and law enforcement are excluded | Determines whether the identity service carries NIS2 incident reporting and supply chain duties. Confirm with the national competent authority whether the agency or its operator falls in scope, and separate any law enforcement-linked identity flows that the exclusion may cover. |
Where the identity platform runs: public cloud, government data center or air-gapped
When the agency owns the hardware, virtualization and database, it controls the change calendar and the key material, but it also carries every patch and every failover test. Keycloak's documented high availability designs set the baseline for what the agency must build and operate.
- High availability design: A single cluster can be spread across availability zones, or multi-cluster deployments (v2) can run without an external Infinispan cluster. The deprecated v1 model used a separate Infinispan cluster per site, so confirm early that it is not the design you are inheriting.
- Database replication: Both supported designs need a synchronously replicated database, so the agency must fund, size and test that database tier, not only the Keycloak nodes.
- Patching cadence: Keycloak plans four minor releases a year, and breaking changes in a minor release are opt-in, which gives the platform team time to schedule upgrades inside its own change windows.
- Operator updates: If the platform runs on Kubernetes, the Operator documentation strongly recommends manual approval mode so that upgrades happen only when the agency approves them.
- Key holding: The agency holds TLS certificates, database credentials and backup encryption keys directly. Confirm where those keys are generated, who can export them and how they are rotated.
Confirm that your data center can provide two sites with synchronous storage replication, and read the Keycloak high availability overview before you commit to a topology.
In a shared government cloud, the cloud provider patches and maintains the underlying infrastructure, while the agency still owns Keycloak versions, configuration and the identity data. Whether FedRAMP applies depends on whether the service is offered as a shared service or used only for one agency's operations, so that question should be settled with the agency's authorizing officials before design begins.
- Scope determination: FedRAMP's scope covers cloud products that handle federal information on behalf of an agency. Systems used only for one agency's operations and not offered as a shared service are outside that scope, so document the classification in writing. See the FedRAMP scope guidance.
- Managed databases: Supported production databases include Amazon Aurora PostgreSQL and Azure SQL, alongside PostgreSQL (14 to 18). Confirm that the managed database service is inside the same authorization boundary as the identity platform.
- Availability zones: A single Keycloak cluster can span availability zones, but only if the chosen region offers the zones and a synchronously replicated database across them. Confirm both with the provider.
- Key custody: Cloud key management services can hold encryption keys, but confirm whether customer-managed keys are available and whether the key service uses FIPS 140-3 validated modules, which the FBI CJIS Security Policy requires for criminal justice information outside physically secure locations.
- Upgrade ownership: The provider's patching does not replace Keycloak upgrades. Plan the minor release cadence and the manual approval mode for any operator-managed deployment.
Ask the provider which controls it inherits from its own authorization package, and map each of them to the identity platform's responsibilities.
On restricted or air-gapped networks, the platform has no direct path to public package repositories, container registries or the vendor's update channels, so every patch and image must arrive through a controlled transfer path. Key material and audit records also stay inside the enclave, which raises the importance of local key management and local evidence retention.
- Artifact transfer: Keycloak releases, operator images and the operator's installation resources must be mirrored or transferred through an approved process before each upgrade. The Helm chart is experimental, so plan around the Operator installed through Operator Lifecycle Manager, which is the recommended method.
- Database placement: Use a supported production database hosted inside the enclave. The default development file database is for development only and cannot serve as the production store.
- Site-to-site resilience: Both supported high availability designs require a synchronously replicated database, so a second site inside the restricted network needs its own local database replication. Confirm the latency and link capacity before choosing the topology.
- Schema migration: Keycloak migrates the database schema at startup by default. For change-controlled enclaves, the upgrading guide suggests manual migration for large deployments, which lets a database administrator review the SQL first.
- Local key custody: Keys for TLS, database encryption and backups stay within the enclave, so confirm which internal key service or hardware security module will hold them and how they are backed up.
Before committing to this model, confirm the transfer process, upgrade testing location and the evidence the assessor will expect from an isolated environment.
Which open source identity platforms fit citizen login
Citizen login is a public-facing identity service with strict assurance, accessibility and federation needs, so the platform choice shapes both the build and the licensing position. The cards below cover the main open source candidates, the question each one raises for an agency, and the staff-side companion that keeps workforce accounts governed.
Keycloak for citizen login
Keycloak is licensed under Apache-2.0 and supports OpenID Connect, OAuth 2.0 and SAML 2.0, with identity brokering and user federation for connecting to existing directories and national eID schemes. For public sector use, the questions are whether your chosen production database is on the supported list, which high availability design fits your hosting, and how you will handle upgrades. The Operator documentation recommends manual approval mode for operator updates, so plan that approval step into your change process. Confirm which Red Hat or community distribution your procurement and support model requires.
ZITADEL and the AGPL question
ZITADEL covers SSO, MFA, passkeys with FIDO2 and WebAuthn, OpenID Connect certification, SAML 2.0, SCIM and multi-tenancy, which suits agencies that serve several departments or delegated administrators from one platform. It is licensed under AGPL-3.0, which requires that network-accessible modifications be made available to users under the same license. Agencies should have counsel confirm whether any modifications, integrations or hosted contractor changes trigger those obligations, and whether the contract allows the agency to publish its changes. Multi-tenancy can also reduce the need for separate instances per department.
Ory Kratos and Hydra as a split stack
Ory Kratos handles identity and user management, while Ory Hydra acts as the OAuth 2.0 and OpenID Connect server, and both are licensed under Apache-2.0. The split suits teams that want to own the login flows and the token service separately, but it means your team assembles and tests the integration between them. Agencies should map which parts of assurance, consent and session handling must be built and evidenced by their own staff. Confirm that the team can support two components on a shared release calendar before choosing this route over a single platform.
authentik and its enterprise directory
authentik is licensed under MIT, but the authentik/enterprise directory carries a separate enterprise license, so the license boundary must be checked against the features your citizen login needs. Agencies should list required capabilities such as directory features, support terms and enterprise-only components, then confirm in writing which of them fall under the MIT core. A community deployment can meet many login needs, but any dependency on enterprise-licensed code changes the procurement and redistribution position. Ask the vendor or DeployOpen to show the exact file paths behind each required feature.
midPoint for staff account governance
Citizen login serves the public, but the staff accounts that administer it need joiner, mover and leaver processing and periodic access certification. midPoint is an identity governance and administration platform licensed under the European Union Public License 1.2 or later, and it can act as the source of truth that provisions staff identities into the login platform. The 4.8 Curie release is a long-term support line supported until October 17, 2028, which matters for agencies planning multi-year operations. Confirm how staff directories and HR sources feed midPoint before you connect it.
How a citizen identity rollout moves from assurance mapping to live services
The sequence turns a set of citizen services into a tested, federated and operated identity platform, with each phase ending in a documented decision or check. Assurance requirements are fixed first, so architecture, eID onboarding, accessibility and cutover are all measured against the same agreed targets.
Map each service to an assurance level
The agency, its legal team and DeployOpen review each citizen service and assign an assurance level under NIST SP 800-63, based on the harm a misused or compromised account could cause and the sensitivity of the data behind it. The same pass identifies which applicable baselines apply, such as the moderate or high control baselines in NIST SP 800-53B if the platform touches federal systems, or the CJIS Security Policy if criminal justice information is involved. The output is a signed requirements register listing, per service, the authenticator types, identity proofing method, session rules and audit events required. The step is done when the agency has approved the register and every open question has a named owner.
Decide architecture and hosting boundaries
Architects choose where the identity platform runs, such as government-operated data centers, a sovereign cloud region or an air-gapped segment, and whether Keycloak or another open source option fits the assurance and protocol requirements. They document the database, high availability design, backup location, key storage and the boundary between the identity provider and the services that trust it. Where a cloud service would hold citizen data, the team confirms with the agency whether any FedRAMP or equivalent authorization applies before anything is provisioned. The output is an approved architecture decision record and a hosting statement that the agency's security office can assess.
Onboard federation and national eID schemes
The team connects the platform to national eID schemes and to any existing workforce or regional identity sources through the protocols each scheme supports, typically OpenID Connect or SAML 2.0, and sets up attribute mapping so claims arrive in the form each service expects. Scheme operators and the agency confirm test onboarding, certificate and metadata exchange, and the assurance level each scheme can carry. The output is a federation matrix showing which schemes are trusted for which services, with test evidence for each login path and a documented process for rotating signing keys and metadata.
Test accessibility against WCAG 2.1 AA
Login, registration, identity proofing, consent and recovery pages are tested against WCAG 2.1 Level A and AA, which the ADA Title II rule requires for state and local government web content and mobile apps from the dates in 28 CFR 35.200. Testers combine automated scans with manual checks using keyboard only navigation, screen readers, zoom and high contrast settings, and they include the error messages and timeout warnings that citizens are most likely to hit. The output is a findings log with severity, owners and retest results, and a statement of which pages still carry known issues. Remediation in the login flow is re-verified before the pilot begins.
Run a pilot with one service
The team selects a single citizen service with a limited, well understood user group and enables the new login flow alongside the existing method for that service only. Monitoring covers failed logins, proofing outcomes, help desk tickets, session timeouts and audit log completeness, and the agency reviews these against the requirements register. Load testing at the expected peak is run before the pilot opens to the public. The output is a pilot report listing defects found, changes made, measured outcomes against the agreed targets and a go or no-go decision signed by the service owner and the security office.
Migrate users and cut over services
Existing accounts, if any, are moved to the new platform through an agreed method, such as account linking at next login or a supervised bulk import, and the team confirms how password hashes or credentials are handled so citizens are not locked out without a recovery path. Services are switched one at a time, with a rollback plan that keeps the previous login route available for a defined period set by the agency. Cutover is complete when each service has passed its acceptance tests, its audit events reach the agency's logging platform and the legacy route is retired or formally kept for a documented reason.
Hand over operations and upgrades
DeployOpen documents runbooks for backups, restores, certificate and key rotation, scaling, incident response and upgrades, and trains the agency's operators on them. Upgrade handling follows the platform's release model: for Keycloak, that means reviewing minor and major release notes, testing in a non-production environment, and applying operator updates under manual approval so changes are not applied unintentionally. Ongoing support, upgrades and testing can be placed under a retainer if the agency wants them. The output is an operations handover package, a tested restore record and a named support model, confirmed in writing before the engagement closes.
Integration points that citizen identity must connect
A citizen login platform is only as useful as the systems it connects to. The cards below cover the external eID schemes, the service applications that consume identity, the logs and secrets the platform depends on, and the staff access path that administers it. Each one needs a named owner and a written interface before build work starts.
National and regional eID brokering
Citizens may be able to sign in with a national eID scheme or a regional credential issued by another authority. Keycloak can broker such upstream identity providers, but the platform must map each scheme's assurance level, attribute set and logout behavior to the NIST SP 800-63 level the service requires. Confirm with the eID scheme operator which attributes are released, how identifiers are stable over time, and whether the scheme accepts your redirect URIs and certificate rotation schedule.
Service-side OIDC clients
Each benefits portal, form service or case front end becomes an OpenID Connect client with its own scopes, redirect URIs and token lifetimes. Standardizing client registration, using the Keycloak Operator's KeycloakOIDCClient resource where it fits, keeps those settings reviewable as code. Confirm with each service owner which claims they need, whether they call APIs on behalf of the citizen, and how sessions end when a citizen signs out of one service but not another.
Case management and benefits systems
Case files, eligibility engines and payment systems hold the records a citizen's identity is linked to. The identity platform should supply a stable subject identifier and verified attributes, while the case system keeps ownership of the record. Confirm with the system owner how a citizen account is matched to an existing case, how proxy or representative access is recorded, and what happens to linked records when an account is merged or closed.
Authentication logs into the SIEM
Every login, failed attempt, MFA challenge and token issuance is evidence for incident response and for audit controls over systems that hold personal data. Forwarding these events to Wazuh or another SIEM lets security staff correlate citizen account takeover attempts with network and endpoint activity. Confirm with the security team which event types are required, how long they are retained, and whether citizen identifiers must be pseudonymized before they leave the identity platform.
Client secrets and keys in OpenBao
Client secrets, signing keys for tokens, database credentials and certificates for upstream eID connections are sensitive material that should not sit in configuration files. OpenBao can store and distribute these values under access policies with audit logging. Confirm with the security team who may rotate signing keys, how a key rotation is rolled out across Keycloak nodes without breaking active sessions, and where the recovery keys are held.
Staff access through midPoint
Caseworkers, help desk staff and platform administrators reach citizen data through a separate, governed identity path. midPoint can handle joiner, mover and leaver events from the HR or employee directory, assign roles to staff, and run access certifications on a schedule set by policy. Confirm with the HR and IGA owners which source system is authoritative, how contractor accounts are ended, and which administrative roles require a second reviewer.
Evidence assessors and regulators ask for from citizen login
This table maps the evidence an assessor or regulator typically asks to see for a citizen login service to the component that produces it and the team that owns it. Read it as a checklist for scoping the evidence pack before an assessment starts. DeployOpen prepares this evidence from the running system, but independent assessors and certification bodies issue any opinion on it.
| Evidence | Producing component | Owner and what to confirm |
|---|---|---|
| Audit log exports of administrative and user events | Keycloak event logs and admin event logs, exported to a central log store | Agency security team. Confirm retention period, log integrity controls and who can read the logs. |
| Operational metrics for login volume and failures | Keycloak metrics endpoint (Micrometer/Prometheus format) feeding dashboards and alerts | Platform team. Confirm which metrics are retained as evidence of availability and anomalous login activity. |
| Configuration baselines for realms, clients and password or MFA policy | Exported realm configuration, Keycloak Operator custom resources and version-controlled manifests | Platform team with security sign-off. Confirm that baselines are reviewed and changes are tracked to an approver. |
| Authentication assurance records | Realm settings mapping flows to NIST SP 800-63 assurance levels, MFA enrollment records and federation trust configuration | Identity owner and agency policy team. Confirm which assurance level each service requires and how that decision is documented. |
| Accessibility test reports for login and registration pages | Automated scans and manual testing against WCAG 2.1 Level A and AA, including themed Keycloak pages | Digital service team and accessibility specialist. Confirm the tester is independent of the build team and the scope covers every custom theme. |
| Backup and restore test records | Database backup jobs and timed restore tests into an isolated environment | Operations team. Confirm that restores were completed, time taken was measured and results were signed off. |
| Upgrade and patch records | Change tickets, Keycloak release notes reviewed, pre-production test results and rollback plans | Platform team and change board. Confirm that the Operator approval mode and schema migration choice were recorded for each upgrade. |
| Vulnerability scan and penetration test results | Scanning of the platform, its container images and the public login endpoints, plus security testing reports | Security team. Confirm findings, remediation dates and retest evidence are tracked together. |
What agencies ask before hiring an implementation partner
What drives the cost of a citizen identity implementation, and what is fixed scope?
The cost depends on the written scope: which assurance levels the services need, how many federated national eID schemes and agency services must connect, how many user journeys (registration, identity proofing, recovery, delegated access) are in scope, and how much accessibility testing is required. Most DeployOpen engagements are fixed-scope, so scope, deliverables and timelines are agreed in writing before work starts, and the quote follows from that scope. Recurring costs include the infrastructure that runs the platform, upgrades, and any retainer for ongoing support. Ask each bidder to separate one-time delivery from recurring operations, and to state which items are excluded from the fixed price. DeployOpen does not publish a price list.
How long does it take to put a citizen login service live?
The timeline depends on the integrations and the approval path, not on the software alone. The main variables are the number of eID connections, the number of agency services that need single sign-on, the accessibility and security testing required before launch, and how long the agency's own approvals take. No duration is fixed here because no researched figure applies to your environment. Ask for a phased plan in the written scope with named milestones, such as a pilot with test users, a federation test with each eID scheme, and a controlled production cutover. Confirm which of these milestones depend on the national eID scheme operator or other third parties.
What does the agency need to provide before implementation starts?
The partner will need decisions and access from the agency, not only infrastructure. Typical inputs are:
- A named policy owner who can confirm the assurance level each service requires under NIST SP 800-63 and local rules
- Technical contacts for each national eID scheme and for every service that will trust the login
- A set of test users and test identities for registration, step-up and recovery journeys
- Access to the hosting environment on public infrastructure, plus approved network and certificate paths
- Sign-off on accessibility requirements and on the audit and log retention rules
Ask each partner to list these inputs in the written scope, with the owner and the date each one is needed.
Can our in-house team run a self-hosted Keycloak identity platform after launch?
Yes, if the team has the skills and capacity to operate it, and the scope includes a handover. Keycloak is an Apache 2.0 licensed server with a supported production database list, documented high availability designs, and an Operator for Kubernetes. Running it still requires people who manage the database, clustering, certificates, backups, monitoring (Keycloak documents metrics) and upgrades. Ask the partner what documentation, runbooks and training are included, and whether support after launch is a fixed handover or a retainer. Confirm that your team can operate the chosen high availability design and that its database meets the synchronous replication requirement the project documents for both supported multi-site designs.
How are Keycloak upgrades approved if the operator recommends manual approval?
Upgrades should follow a written approval path, because the Keycloak Operator documentation strongly recommends manual approval mode to avoid unintended automatic upgrades. Keycloak plans four minor releases a year since version 26.0 and says breaking changes in a minor release are opt-in, but each upgrade still needs testing against your realms, custom providers and federation settings. Ask the partner to describe the change approval board, the test environment, the rollback plan and the schema migration method. Keycloak migrates its database schema automatically at startup by default, and it also supports manual migration, which the upgrading guide suggests for large deployments. Confirm which option your agency's change policy requires.
Does FedRAMP or CJIS apply to a citizen identity platform?
It depends on who the service is for and what data it handles, so confirm it with your agency's authorizing official before scoping. FedRAMP scope covers cloud products and services that create, collect, process, store or maintain federal information on behalf of an agency, and systems used only for a single agency's operations on cloud infrastructure, not offered as a shared service, are out of scope. CJIS Security Policy applies when criminal justice information is in the system. Version 6.1 took effect on 26 June 2026 and requires FIPS 140-3 certified modules or FIPS 197 AES with at least 256-bit keys for CJI outside physically secure locations. Ask the partner to map each control to the policy that applies and to state which evidence it prepares. DeployOpen prepares controls and evidence for assessments but does not issue authorizations or certifications.
Which NIST SP 800-63 assurance level does a citizen login need?
The required assurance level is set by the service owner's risk assessment, not by the identity platform. Ask the agency's policy owner to assign an assurance level to each service and to confirm that the chosen authenticators and federation paths meet it. Keycloak supports OpenID Connect, OAuth 2.0 and SAML 2.0, which cover the federation patterns most agencies use, but authenticator strength and identity proofing decisions must be checked against the assurance level in the written scope. Ask the partner which authenticators it will configure, how it will record authentication context in tokens, and how step-up authentication is handled for sensitive transactions.
How is accessibility tested for citizen-facing login pages?
Login pages are part of the web content that must meet the accessibility standard, so they should be tested before launch and kept under test after each change. Under the ADA Title II rule, state and local government web content and mobile apps, including content provided through contracts, must meet WCAG 2.1 Level A and AA from 26 April 2027 for entities serving 50,000 or more people and from 26 April 2028 for smaller entities and special districts. Ask the partner to state how login pages will be tested, who performs the testing, how the Keycloak login theme is customized, and what evidence is delivered. Confirm your entity's population category with counsel.
What to ask an implementation partner for citizen identity
Start with assurance mapping. Ask the partner to show, for each citizen journey, which NIST SP 800-63 assurance level (identity, authenticator and federation levels) the design targets and which Keycloak or ZITADEL settings deliver it, such as the authentication flow, the authenticator types allowed and the session lifetimes. Ask for the mapping as a written table you can test against, and ask how a service owner can change an assurance level for one service without weakening the others. A partner who cannot show the mapping in a document has not done the design work yet. Next, ask how accessibility is tested. The ADA Title II rule in 28 CFR 35.200 requires state and local government web content and mobile apps, including content supplied through contracts, to meet WCAG 2.1 Level A and AA, with the compliance date depending on the size of the population served. Ask who runs automated and manual testing on the login, registration, recovery and consent screens, which assistive technologies are used, whether results are delivered per screen with defects tracked to closure, and whether the partner will test the themed pages you customize, not only the default Keycloak theme.
Ask for named eID federation references. Request a list of national or regional eID schemes the partner has connected to a production identity platform, and ask them to confirm each one in writing, including the protocol used (for example OpenID Connect or SAML 2.0), the assurance level the scheme supports and who on your side must approve the trust relationship. Do not accept a general statement that the platform "supports eID". Keycloak's identity brokering is a capability, not evidence of a working scheme connection. Then ask about hosting, key custody and evidence. Confirm in writing where the platform runs, who holds the signing and encryption keys and the database credentials, and how those keys are rotated and backed up. Ask for the evidence pack the partner delivers for each assessment, such as configuration exports, access reviews, logging and audit settings, and vulnerability scan results, and ask who signs off that the pack is complete. Finally, ask for the upgrade approach and the support retainer scope in the same document: how minor and major Keycloak releases are tested and promoted, whether manual approval mode is used for operator updates, who performs security patching, the response expectations and what the retainer excludes. Ask for these terms in the written scope, since support boundaries are where public sector programs most often fail.
