Keycloak for public sector

The CJIS Security Policy version 6.1, which took effect on 26 June 2026, requires criminal justice information (CJI) to be protected with FIPS 140-3 certified cryptographic modules, or with FIPS 197 AES using keys of at least 256 bits, whenever CJI is in transit or at rest outside physically secure locations. For a Keycloak deployment, this is a stack question, not a single product question. Browser traffic to the reverse proxy, traffic from Keycloak to its database, LDAP or Active Directory and any brokered identity providers, and data stored in the database, backups, and logs each depend on cryptography supplied by the runtime and libraries around Keycloak. Map each of those paths before choosing components, because the requirement applies to every one that carries or holds CJI.

The decisions that carry the most weight are the Java runtime (JVM) and the TLS libraries it uses, the reverse proxy or load balancer that terminates client TLS, the database driver and any database-level encryption, and where signing and encryption keys for realms are generated and stored. Ask the vendor which Keycloak build, JVM and TLS provider the agency will run, and for the validation certificate and module version that covers that exact combination. Confirm with the agency's assessor whether the validation is accepted under FIPS 140-3, since the topic label refers to FIPS 140-2 mode and the CJIS wording points to 140-3. Do not assume that a validated module in one layer validates the whole stack.

Once the components are chosen, test the cryptographic behavior in the configuration the agency will operate. Confirm which protocol versions and cipher suites the proxy and Keycloak negotiate in the validated mode, and check that non-approved algorithms fail closed instead of falling back. Verify that the admin console and Administration REST API sit on a separate hostname or context path, as the production guide advises, so that administrative sessions are not carried over public endpoints. Keycloak 26.8 enforces StartTLS for SMTP without plaintext fallback, which closes one mail path, but the agency should still confirm the mail relay's own support for the same requirements. Record the results as evidence for the assessor.

Plan for change. A FIPS-related configuration can break sign-in for clients, directories or smart card and Kerberos paths that depend on older algorithms, so run those flows in a test environment before production. Keycloak's minor releases arrive several times a year, and each upgrade of the JVM, TLS library or proxy can change the validated boundary, so reassess the validation status after every change. The same CJIS release requires vulnerability scanning at least monthly under RA-5, and that scanning should cover the JVM, libraries and proxy as well as Keycloak itself. When requesting a quote, ask for the cryptographic review, the evidence package, and the retest steps that follow each upgrade.

An air-gapped Keycloak installation is mostly a build exercise. Every image, package and manifest the cluster pulls at deploy time has to come from a registry, repository or file transfer inside the boundary. Plan an internal registry that holds the Keycloak server image, the Keycloak Operator images, and the images for the database, proxy and any sidecars. Record the digest of each image as you mirror it, so the deployed version can be matched to the tested version later. The Operator can be installed through Operator Lifecycle Manager, with kubectl, or with an experimental Helm chart. Choose the method your platform can run offline, and mirror the catalog content or manifests that method needs before the network is cut.

The database must also live inside the boundary, and it is a decision you make early. Keycloak supports several production databases, including PostgreSQL 14 to 18, Microsoft SQL Server, MySQL, MariaDB and Oracle Database. Pick one your agency already operates, can back up and can restore under your own change control. The default development file database is not suitable for production. Keycloak migrates its schema automatically at startup by default. In a boundary, decide whether that automatic migration is acceptable or whether your team will apply the SQL manually through a reviewed change, which the upgrading guide suggests for large deployments. If you plan a high availability design, the database must be synchronously replicated, so size that replication link and its failover path together with the rest of the design.

Set Operator updates to manual approval. The Keycloak Operator documentation strongly recommends manual approval mode to avoid unintended automatic upgrades. In an isolated network, automatic upgrade paths may not function anyway, but the risk is still real: a mirrored catalog update could be applied without review. With manual approval, each new Operator version is imported, checked, deployed to a staging environment, tested against your realm and client configuration, and only then approved in the cluster. Write this sequence into your runbook, name the person who approves each step, and keep the approval record with the change ticket.

Carrying updates across the boundary is where most offline programs drift. Read the Keycloak 26.8 upgrade notes before importing any bundle. They include enforced SMTP StartTLS without plaintext fallback, mandatory signature validation of backchannel logout tokens from external providers, login failures persisted to the database by default, and a recommendation to move from the deprecated multi-site feature to the stateless feature. Each item can change mail flow, logout behavior, database growth or cluster design, so test them on a copy of production data. For every artifact that crosses the boundary, verify checksums and signatures at import, keep a signed manifest, and store the hashes with the change record. NERC CIP-013-2 asks procurement processes to address verification of software integrity and authenticity for vendor software and patches. Treat it as a useful model for your own process, not as a requirement unless your regulator or contract says so. NIST SP 800-53 supply chain risk management controls point to the same practice.

Confirm the offline details with the Keycloak project before you commit to a design. Ask which installation steps need network access, which Operator bundle contents must be mirrored, and whether any feature calls out to an external endpoint at runtime, such as external identity providers, metadata refresh or update checks. Each external dependency needs either an internal equivalent or a documented exception. Ask whether the release cadence and breaking-change policy affect how often you must cross the boundary. Get the answers in writing and attach them to the design record, because auditors will ask who confirmed the offline support and when.

Your agency must settle the system boundary before go-live, because every control inventory, evidence package and assessor question depends on it. Write down which realms, clients, identity brokers and user federation links sit inside the boundary, which applications sign in through them, and which external services, such as SMTP relays and log destinations, receive identity data. Then select the control baseline with your authorizing official. NIST SP 800-53B defines low, moderate and high baselines that select 149, 287 and 370 controls and enhancements respectively, and any tailoring changes those sets. DeployOpen can document the configuration against the baseline you choose, but the selection and every tailoring decision remain with your agency.

Your team also owns the sources of identity and trust. Name the authoritative directory for each user population, whether that is an LDAP or Active Directory forest used for user federation, a Kerberos realm for integrated Windows sign-in, or smart card credentials issued by your PKI. For each source, record who creates the service accounts, who holds the Kerberos keytab and who rotates it. Certificates need the same treatment: the TLS certificates on the public and administration hostnames, the trust chain your smart card sign-in accepts, and the signing keys behind SAML and OIDC clients. Assign an issuer, a renewal owner and a revocation procedure for each, and confirm that expiry alerts reach those owners.

Upgrades are the ongoing obligation most often underestimated. The Keycloak project plans four minor releases a year, and the Keycloak Operator documentation strongly recommends manual approval mode for operator updates so that no upgrade starts without a decision. Put the approval rule in writing: who reviews the release notes, who tests in a non-production realm restored from a recent backup, who approves the production change, and whether schema migration runs automatically at startup or as SQL your staff reviews and applies, which the upgrading guide suggests for large deployments. The 26.8 upgrade notes enforce StartTLS for SMTP without plaintext fallback, require signature validation of backchannel logout tokens from external providers, and persist login failures to the database by default. Each of those changes needs a test case in your release checklist.

Patch review needs named people with time reserved for it. Keycloak, the operator, the database, the Java runtime and the reverse proxy each publish fixes, and someone at your agency must read them, decide and record the decision. If criminal justice information is in scope, the FBI CJIS Security Policy version 6.1, effective 26 June 2026, requires vulnerability scanning at least monthly under control RA-5. Its cryptographic controls, SC-13 and SC-28, call for FIPS 140-3 validated modules or AES with 256-bit keys for CJI in transit and at rest outside physically secure locations. Your agency must own the scanner, its credentials, the scan scope and the triage queue that closes findings. Confirm with your CJIS Systems Agency or state information security officer whether CJIS applies to this deployment before you size these roles.

Start with the written scope, because it defines what you are buying. Ask the partner to list each Keycloak component in scope: realm and client configuration, LDAP or Active Directory user federation, Kerberos settings, certificate-based smart card sign-in, the reverse proxy and TLS layout described in Keycloak's production guide, and the split of the admin console and Administration REST API onto a separate hostname or context path. For each item, ask whether it is a fixed deliverable with written acceptance criteria or time-and-materials work. Ask which Keycloak release line will be deployed and how the partner will handle the minor releases that the project plans four times a year. The current release in the supplied facts is 26.8.1, published October 13, 2026, so ask how the partner will confirm that version against your environment before build.

Next, ask exactly what the evidence package contains and who owns it afterward. A useful package includes configuration exports, a mapping from each Keycloak setting to the identification and authentication controls in the NIST SP 800-53 baseline your authorizing official uses, sign-in test records for each method, logging and metrics configuration, and backup and restore test results. NIST's SP 800-53B moderate baseline selects 287 controls and enhancements, so ask how the partner narrowed that set to the controls this service touches and what they left out. Confirm in writing that the partner prepares evidence and does not issue audit reports or attestations. Independent assessors and certification bodies make those determinations, and your package should be written to help them test.

Ask for the offline install procedure in writing before you commit. The procedure should list every artifact that crosses the boundary: container images, the Keycloak Operator bundle, database drivers, and any custom providers. Keycloak's Operator is recommended through Operator Lifecycle Manager and its documentation strongly recommends manual approval mode for operator updates. Ask how manual approval will be configured in a disconnected cluster, who approves each update, and how each carried package is verified for integrity and authenticity. On the database side, ask whether schema migration will run automatically at startup or as SQL applied by your administrators. The upgrade guide suggests manual migration for large deployments. Confirm that your chosen database version is on Keycloak's supported list, which currently includes PostgreSQL 14 to 18.

Ask for references under NDA and do not assume the partner has directory or smart card experience. Request named engagements, with the sponsor's agreement, that involved LDAP or Active Directory federation, Kerberos sign-in, and certificate-based smart card authentication in environments similar to yours. Ask how the partner tests federation sync, attribute mapping, group-to-role mapping, and what users see when a directory source is unavailable. For smart cards, ask which middleware, certificate chain validation, and revocation checks they will configure, and how they will confirm that behavior on your current Keycloak version. Ask whether they will test with real cards issued by your agency's credential program, because a lab certificate does not prove the production trust chain works.

Finally, agree the handover plan and the retainer terms before signing. The handover should include runbooks, administrator training, a dated acceptance step, a list of who holds administrative credentials, and a rule for rotating them. For retainers, ask what is covered: review of each minor release and its breaking-change notes, staging upgrades, the 26.8 upgrade items such as enforced SMTP StartTLS and mandatory validation of backchannel logout tokens from external providers, and recurring security testing. Ask how often testing runs, what triggers an out-of-cycle review, and which items are billed separately. Ask for the quote to list each component, whether it is one-time or recurring, and what changes the price, so you can compare a partner with your own team on the same basis.