Keycloak FIPS 140-2 mode setup

Keycloak FIPS 140-2 mode: when regulated teams need it

Keycloak FIPS 140-2 mode is a runtime configuration that makes Keycloak use cryptographic libraries approved under the Federal Information Processing Standard 140-2 instead of its default providers. Teams need it when a regulator, customer, or contract requires that the identity provider, which handles passwords, tokens, and signing keys, uses approved cryptography, and when the system will be assessed against that requirement. The question usually arrives during an audit scoping exercise or a procurement review, and it is worth answering early because it changes which features, key types, and keystores you can use.

Keycloak's FIPS mode switches the server to FIPS-approved cryptographic libraries, which the Keycloak project supports through the BouncyCastle FIPS libraries. It is a configuration and validation effort, not a checkbox. Enabling the mode changes which algorithms and key lengths are accepted, so realm keys, client secrets, password hashing, and TLS settings all need review. Some features, including Kerberos and SPNEGO desktop sign-in, do not work under FIPS, so the business needs to know this before the decision is made. Your team should also confirm which Java runtime, operating system, and container base image are in scope, because the validated boundary depends on them.

The FIPS 140-2 validation status of any cryptographic module is for the module vendor and an independent accredited testing laboratory to establish and maintain. Keycloak's use of approved libraries does not, by itself, mean a deployment is validated. Ask the vendor and lab for the certificate number, the validated version, and the exact module boundary, then check that your deployed versions match it. DeployOpen does not issue certifications, attestations, or audit reports. Our role is to plan the configuration, prepare evidence of what is enabled and how it was verified, and support your independent assessor.

Start by writing down who requires FIPS and for which data flows: sign-in traffic, token signing, stored credentials, and backchannel calls to external providers. Then ask whether your current realms, clients, and federation links use algorithms or key sizes the mode will reject. Plan for a test realm first, so that application owners can confirm sign-in, token validation, and logout behavior before production changes. Record which features will be disabled, and get that decision signed off by the application owners who depend on them.

Expect the cost to come from configuration work, testing, and evidence rather than from the software itself, which is open source. A written scope should list the environments, realms, and integrations covered, the compatibility tests, and the documentation handed over. Ask any partner, including DeployOpen, to state which items are one-time (initial configuration and test plan) and which recur (re-testing after Keycloak upgrades, library updates, or module revalidation). Ask your own team to estimate the same items so you can compare the two options on equal terms.

Keycloak FIPS mode options and when each fits

This table compares the FIPS-related choices for running Keycloak in FIPS 140-2 mode: the mode setting, keystore format, key length and the BouncyCastle FIPS library. Each row shows what the choice changes, which kind of system it suits and what to check in the Keycloak server administration and production guides for your release. The main takeaway is that a pilot and a production system under audit usually need different settings, so confirm exact behavior against the documentation for the version you run.

Option	What it changes	Best fit	What to verify
Non-strict FIPS mode	Runs Keycloak with FIPS-approved cryptography where available while allowing some non-approved behavior to continue	A pilot, test environment or early migration where teams are still finding which integrations and clients break	Which operations are still permitted, what gets logged, and whether the server admin guide flags this mode as suitable for production
Strict FIPS mode	Restricts the server to FIPS-approved algorithms and modules, and blocks or fails operations that depend on non-approved ones	A production system under audit, or one that must reject non-approved algorithms at runtime	Startup behavior, the list of blocked features, client and token algorithm settings, and the production guide steps that apply to strict mode
Keystore format	Sets the format used for the server keystore and truststore, which must be compatible with the FIPS provider in use	Any FIPS deployment, chosen before certificates are issued so that rotation does not need a rebuild	Which keystore formats the release accepts in FIPS mode, how existing keystores are converted, and how the provider loads them
Key length choice	Determines the key sizes used for TLS, signing and encryption, which must meet the approved minimums for the chosen mode	Systems where an assessor will test key strength against a named control, such as a federal or payment baseline	The minimum key sizes the docs enforce, the defaults for realm keys and client keys, and whether existing keys need regeneration
BouncyCastle FIPS library setup	Loads the BouncyCastle FIPS provider in place of the standard provider so that cryptographic calls go through the validated module	Every production FIPS deployment; a pilot can use it to test the setup before the audit	Provider jar version and placement, the module validation certificate it references, and the startup log lines that confirm the provider is active
Features that do not work under FIPS	Some functions, such as Kerberos and SPNEGO desktop sign-in, are not available when FIPS mode is enabled	Estates that depend on Kerberos sign-in must plan an alternative before they enable FIPS mode	The current list of unsupported features for the release, and whether any of them are on your application or user federation plan

Which frameworks point to FIPS-validated cryptography, and which do not

The FBI CJIS Security Policy sets minimum requirements for criminal justice information (CJI). Version 6.1 took effect on 26 June 2026, with a Requirements Companion Document, and it is the framework in this set that most directly names cryptographic module validation. For CJI in transit and at rest outside physically secure locations, version 6.1 requires either FIPS 140-3 certified modules or FIPS 197 AES with keys of at least 256 bits, up from 128 bits. The policy ties these expectations to controls such as SC-13 and SC-28 and requires vulnerability scanning at least monthly under RA-5.

Scope of the requirement: The rule applies to CJI in transit and at rest outside physically secure locations. Map every Keycloak data flow that carries or stores CJI, including the database, backups and backchannel calls.
Two acceptable paths: Use a FIPS 140-3 validated module, or FIPS 197 AES with at least 256-bit keys. Confirm which path each flow relies on.
FIPS mode is not the evidence: Turning on a FIPS mode setting does not by itself show that the modules in use are validated or that the configuration meets the requirement.
Who decides: Your assessor and CJIS Systems Agency determine whether the design satisfies the policy.
Key length everywhere: Check keystores, token signing keys and database connections for key length, not only the TLS listener.

Ask your CJIS Systems Agency and assessor which validation evidence they accept before you finalize the design, and confirm the policy version your agreement references.

How Keycloak FIPS 140-2 mode changes the cryptography underneath

Turning on FIPS 140-2 mode changes which cryptographic code runs inside the Keycloak server. The default Java cryptography provider is replaced by the BouncyCastle FIPS provider, so signing, encryption, hashing and random number generation for tokens, sessions and stored secrets run through a library built to the FIPS 140-2 module requirements. Algorithms outside the approved set are restricted, which means some configurations that work in a standard deployment will fail at startup or be refused at runtime. Keystore and key handling also follow FIPS rules, so the keystore types, key lengths and key import steps you use may differ from your current setup. Confirm the exact list of permitted algorithms, the supported keystore types and how each Keycloak release behaves in FIPS mode against the server administration and production guides before you design keys or certificates.

Keycloak's FIPS mode is documented with non-strict and strict settings, and the difference matters for planning. Treat the choice as a design decision that you make and record. Confirm in the production guide which checks each setting enforces, which keystore and key behaviors are tightened, and whether either setting changes between releases. Plan a test environment that runs the chosen setting end to end, including startup, realm import, client registration, token issuance and key rotation, because failures often appear only when a key is first used or rotated. Record the setting, the Keycloak release and the library version in your change records so auditors and operators can see exactly which configuration was validated.

FIPS mode applies to the Keycloak server's own cryptography. It does not automatically cover the TLS termination done by a reverse proxy or load balancer in front of Keycloak. The production guide expects TLS on all communication and a reverse proxy with path restrictions, so that proxy has its own TLS library, protocol versions, cipher suites and certificate handling. Those settings need a separate review against the same FIPS expectations, and the reviewer should be the same person who owns the proxy configuration. Also check the connections Keycloak opens itself, such as database, LDAP or Active Directory federation, SMTP and outbound brokering calls, and confirm which TLS provider each one uses under your configuration.

Ask your internal team or implementation partner to produce a cryptographic inventory before go-live. It should list each token signing and encryption algorithm used by your clients, each keystore and certificate, each external TLS endpoint, and each place where a secret is stored or derived. Compare that list with the permitted set you confirmed in the administration guide, and resolve every item outside that set before the cutover date. Applications that rely on older algorithms may need a client or protocol change before they work in FIPS mode, so schedule those changes with the application owners early.

Validation status is a separate question from configuration. A FIPS mode setting shows that the server uses a FIPS provider, but a validation certificate applies to a specific module version, and the version you run must be the one that is validated. Confirm with BouncyCastle, and with the Keycloak project for the release you plan to deploy, which library version is validated and under which standard. Also confirm what your regulator or contract requires. The CJIS Security Policy version 6.1, for example, requires FIPS 140-3 certified modules or FIPS 197 AES with at least 256-bit keys for criminal justice information in transit and at rest outside physically secure locations. Keep the validation evidence with your configuration record. DeployOpen prepares that evidence but does not issue validation or certification, and independent assessors make that determination.

Setting up Keycloak FIPS 140-2 mode, step by step

This sequence takes a Keycloak deployment from scoping to a tested FIPS-mode production configuration. Each step ends with a recorded check, so the compliance, security and platform teams can show what changed, what was tested and which exceptions remain.

Confirm the target release and regulatory scope
The compliance lead and the platform team agree in writing on the Keycloak release that will run in FIPS mode and the regulation that sets the requirement. Ask your assessor which validation standard they accept for the cryptographic module, and whether they expect FIPS 140-2 or FIPS 140-3 evidence for your scope. The current Keycloak release is 26.8.1, according to keycloak.org, but the target should be a release your chosen distribution supports for FIPS. Done when the release, the regulatory clauses and the assessor's acceptance criteria are recorded in the project scope document.
Inventory features and algorithms in use
Platform engineers list every feature that touches cryptography: Kerberos and SPNEGO sign-in, LDAP or Active Directory federation, social and brokered identity providers, custom SPIs, and the signing and encryption algorithms set on clients and federation links. Kerberos is incompatible with FIPS mode, so any dependency on it must be removed, replaced or handled as a documented exception before go-live. Social providers and custom SPIs need a line-by-line check against your approved algorithm list. Done when the inventory marks each item as compatible, replaced or excepted, and every exception has an owner and an approval record.
Obtain the FIPS distribution and libraries
The platform team either builds Keycloak with the BouncyCastle FIPS libraries or obtains a distribution that already includes them, then confirms which option the vendor supports for the chosen release. Red Hat's build of Keycloak is one supported distribution to evaluate, and its FIPS coverage for your version should be confirmed directly with Red Hat. Record the library versions, the source of each artifact, checksums and the build configuration in your bill of materials. Done when the signed artifact set is stored under change control and the vendor's written statement of module coverage is on file.
Create keystores and certificates to key rules
Security engineers generate or import the keystores and TLS certificates that Keycloak and its reverse proxy will use. Choose key types and lengths that the FIPS configuration and your regulator accept, and confirm the minimum key lengths in the server and upgrade documentation for your release. Apply the same rules to token signing keys, to certificates used for LDAPS, and to certificates for brokered providers. Done when a certificate inventory lists each key's algorithm, length, purpose, owner and expiry date, and every entry matches the rules agreed in the first step.
Run non-strict mode in a test realm
Start the FIPS build in non-strict mode in a test environment with a test realm that mirrors production clients, federation links and brokered providers. Non-strict mode is meant to surface configurations that would fail or warn under enforcement, so review the startup log and admin console messages line by line. Run the login test matrix in this environment, covering each client type, each federation source, each social or brokered provider and each multi-factor method in use. Done when every matrix row has a recorded result and each failure has either a fix or an entry on the exception list.
Move the environment to strict mode
After the test matrix passes, the platform team switches the test environment to strict mode and repeats the crypto configuration review against the feature inventory. Check that no client, federation link or key still uses an algorithm outside the approved list, and that each remaining exception is documented with its owner and an expected end date. A second engineer confirms the startup behavior and the admin console warnings. Done when a signed crypto configuration review is stored, strict mode runs in the test environment, and the risk owner has approved the exception list.
Test logins, token signing and federation
Testers run the full test matrix again in strict mode, covering interactive logins, token issuance and validation, LDAP or Active Directory user federation, brokered identity providers and social providers. For token signing, each resource server verifies signatures against the published keys, and the team confirms that tokens from the FIPS build are accepted. Include password, OTP and passkey flows wherever your policy enables them. Done when each matrix row shows a pass, directory synchronization and brokered logins have been observed, and all results are attached to the change record.
Prove backups restore into FIPS mode
The operations team takes a database and configuration backup from the strict-mode test environment and restores it into a clean FIPS-mode instance. They confirm that keystores, signing keys and realm exports come back with their key material, and that strict mode starts without manual edits. Repeat a subset of the login matrix against the restored instance and record the steps and elapsed time the restore took. Done when a restore succeeds from a strict-mode backup and the runbook is updated to match the procedure that was actually run.

Security controls to keep around FIPS mode

FIPS mode constrains the cryptographic modules Keycloak uses, but it does not decide how traffic reaches the server, which services it talks to, or what it accepts from other parties. The controls below close those gaps, and several of them are set or changed by the Keycloak 26.8 upgrade notes, so verify each one after every upgrade.

TLS on every connection

FIPS mode limits which algorithms Keycloak uses, but it does not force every hop to be encrypted. Keep TLS on browser traffic, on the reverse proxy to Keycloak, on database connections, on LDAP or Active Directory federation, and on calls to external identity providers. For each hop, verify that the endpoint presents a certificate that chains to your trusted roots, that protocol and cipher settings stay within what your FIPS policy allows, and that no internal listener accepts plain HTTP.

Edge routing and admin separation

Keycloak's production guide calls for a reverse proxy with path restrictions, so only the paths that public clients need are reachable from the internet. Serve the admin console and the Administration REST API on a separate hostname or context path that sits on an internal network or behind an access gateway. Verify from outside your network that admin paths are unreachable, and that the proxy forwards the host and scheme headers Keycloak uses to build its URLs.

Metrics on the management interface

Keycloak exposes Prometheus-format metrics at /metrics on its management interface when it starts with metrics enabled. Leave this off unless a monitoring system needs it, because the endpoint reveals operational detail about logins, caches and requests that outside parties should not see. When you enable it, confirm that the management port is reachable only from the monitoring network, that the public proxy does not forward the path, and that the optional request and cache histograms are switched on only where your team uses them.

Enforced SMTP StartTLS

The Keycloak 26.8 upgrade notes enforce SMTP StartTLS with no plaintext fallback, so password reset, verification and notification emails must reach a mail server that negotiates TLS. Check that the mail server certificate validates against your trust store, and send a test message from the realm email settings to confirm the handshake completes. Any relay that cannot negotiate TLS will stop delivering mail after the upgrade, so confirm this with the messaging team before the upgrade and before users need a reset.

Backchannel logout token validation

Backchannel logout lets an external identity provider tell Keycloak to end a session on the server side. The 26.8 upgrade notes make signature validation of these logout tokens mandatory for external providers, so a provider whose signing keys Keycloak cannot resolve will have its logout requests rejected. Verify that each brokered provider publishes keys Keycloak can reach, that the signing algorithm matches the provider configuration, and that a test logout ends the local session as expected.

Login failure persistence

Keycloak 26.8 persists login failures to the database by default, and lockout decisions depend on that stored record. Check that the database has capacity for the growth in failure records, that a retention and cleanup schedule is planned, and that the brute force settings in each realm match your access policy. Test by triggering failed logins against two nodes and confirming that the failure counts agree.

Which Keycloak features do not run under FIPS mode

Kerberos and SPNEGO desktop sign-in does not work when Keycloak runs in FIPS mode, so any team that uses it for transparent sign-in from domain-joined desktops needs a separate decision before the FIPS design is final. The main options are to drop transparent sign-in in favor of a browser login with multi-factor authentication, to keep Kerberos on a separate non-FIPS Keycloak deployment, or to accept the gap as a documented exception. Each option changes the user experience, the realm design and the LDAP or Active Directory federation that the Kerberos work depends on, so the identity owner and the compliance lead should make this call together.

Kerberos is the best-known case, but it is not the only one. Build an inventory of every feature that depends on algorithms outside the FIPS-approved set. Start with the social and external identity providers configured in each realm, because their protocols and cryptography sit outside your control. Next, review legacy client adapters, custom authenticators, event listeners, user storage providers and other SPI extensions, since custom code may call cryptographic libraries directly. Finally, check password hashing: confirm the default hash algorithm and its settings for the release you run, whether those settings are approved under your FIPS configuration, and whether existing stored credentials need to be rehashed.

Confirm the inventory against the exact release you plan to run. Support for features under FIPS mode may change between releases, so the Keycloak documentation for your version is the source to check, and the Red Hat build of Keycloak documentation applies if you use that distribution. Then test each flagged feature in a non-production environment that matches your intended FIPS configuration. Record the results, including startup warnings, failed logins and errors in the server log, because a feature that starts without error can still fail at its first real login. Treat the test results as evidence for the register described below.

Document each exception in a register with at least three fields: a named owner who accepts the residual risk, a compensating control that reduces it, and a review date. Illustrative compensating controls include limiting the affected client to a restricted network segment, requiring multi-factor authentication for that sign-in path, removing the feature from production, or moving the affected users to a separate realm or instance. Set review dates from your own risk policy and change calendar, and re-review the whole register after each Keycloak upgrade, since an exception may become unnecessary or a new one may appear. Auditors decide whether the register is acceptable, and DeployOpen can help prepare the inventory and supporting evidence for that review.

Limits to confirm in your environment before you commit

These six items decide whether a FIPS-mode Keycloak setup can be defended before you commit. Some answers come from the module owner, the distribution owner or your assessor, and others from your agency or compliance team. Confirm each one in writing against your own environment, because FIPS validation applies to a specific module version and a specific configuration.

Validation status of the module

Keycloak's FIPS mode relies on the BouncyCastle FIPS libraries, and validation attaches to one exact module version. Ask your cryptography owner to match the library and version in your build against its validation certificate and the current CMVP status, including whether the certificate is marked historical or sits in a transition period. Record the certificate reference in your system security plan so that auditors can trace it.

Distribution and version support

Keycloak is available as the community project and as the Red Hat build of Keycloak, and the two may differ in which versions and configurations they support in FIPS mode. Confirm with the distribution owner which build and version your team plans to run, and whether the mode is documented for that exact combination. Check the upgrade path too, because a later release may change library versions and invalidate earlier testing.

Database and driver support

Keycloak lists supported production databases, including PostgreSQL 14 to 18, MariaDB, MySQL, Oracle Database, Microsoft SQL Server, Amazon Aurora PostgreSQL, Azure SQL and EnterpriseDB Advanced. Supported status for a database is separate from FIPS validation of the database server, its JDBC driver and the TLS connection between them. Ask your DBA which server and driver versions use FIPS-approved cryptography for connections and encrypted storage, then test the connection under FIPS mode before go-live.

Operator and image provenance

Confirm where the container image and the Keycloak Operator come from, and whether the image contains the FIPS libraries that match your validated configuration. Verify signatures and checksums against the publisher's release materials, and keep the build record with your change history. The Keycloak Operator documentation strongly recommends manual approval mode for operator updates, which makes an unplanned upgrade less likely to replace the module you tested.

Assessor acceptance

Ask your assessor or auditor, before you build, whether they accept a FIPS-mode Keycloak setup on the module version and configuration you plan to use. Some assessors will look for the validation certificate, the enforced configuration and evidence that the mode is active at runtime. DeployOpen can prepare systems, controls and evidence for an assessment, but it does not issue audit reports, attestations or certifications, so that decision stays with your assessor.

Federal and sector scope

FedRAMP's scope guidance covers cloud services that handle federal information for an agency, and it excludes systems used only for one agency's operations on cloud infrastructure that are not offered as a shared service. Ask your agency's security office to confirm where that boundary falls for your deployment. Also confirm whether CJIS Security Policy v6.1 applies, since it requires FIPS 140-3 modules or AES with 256-bit keys for criminal justice information, and whether NIS2 or ADA Title II reaches your system.

Keeping FIPS mode intact through Keycloak upgrades

Treat FIPS mode as something to re-verify after every Keycloak upgrade. An upgrade can change the cryptographic libraries Keycloak loads, the default algorithms it selects, how keystores are read and written, and which features remain available in FIPS mode. Keycloak's release model makes this a recurring task. Since Keycloak 26.0, the project plans four minor releases a year and a major release every two to three years. The project says breaking changes in a minor release are opt-in, so behavior changes only when a setting or deployment choice enables them. For each target version, read the upgrade notes, list every change that touches cryptography, keystores or protocols, and record which of those changes you enabled. Then re-confirm FIPS mode and any validation statement that applies to the version you plan to run.

If you run Keycloak with the Keycloak Operator, put a deliberate approval step in front of every operator update. The Operator documentation strongly recommends manual approval mode to avoid unintended automatic upgrades. Under manual approval, a new operator version waits for an explicit decision, which gives the team time to run the FIPS checks before the Keycloak image changes. Decide who approves upgrades, what evidence they need before they approve, and whether the image in your registry is the FIPS-configured build that the approval covers. Review the 26.8 upgrade notes as an example of what to check: they include mandatory signature validation of backchannel logout tokens from external providers and login failures persisted to the database by default. Both change behavior that your tests and logs will depend on.

Build a fixed regression test set and run it against a staging realm that mirrors production configuration, including the same FIPS settings. For logins, cover password sign-in, the one-time password and WebAuthn or passkey methods you have enabled, and administrator sign-in to the admin console. For token signing, confirm that the signing keys in each realm use the algorithms and key lengths on your approved list, that tokens validate at every relying party, and that refresh and logout behave as expected. For federation, test LDAP or Active Directory synchronization, each brokered OIDC or SAML identity provider, and the social providers you rely on. Kerberos and SPNEGO do not run under FIPS mode, so leave them out of the test set and confirm that no realm still depends on them. Keep the test scripts under version control so the next upgrade runs the same checks.

Keep a change record for each upgrade that an auditor can follow without asking the team questions. Record the source and target versions, the upgrade notes you reviewed, the settings you changed, and the crypto-related configuration you verified after the change. Attach the regression results with dates, the approver, the rollback decision and its criteria, and the evidence of the FIPS check. Note whether the database schema migrated automatically at startup or whether your team applied the SQL manually, and keep the scripts used in either case. DeployOpen can prepare these systems, controls and evidence, but independent auditors and certification bodies decide whether they meet a given requirement. Ask your assessor early which evidence format and retention period they expect.

Questions buyers ask before setting up Keycloak FIPS mode

What drives the cost of a Keycloak FIPS mode setup?

Scope drives most of the cost, so the written scope should set the quote. Price usually moves with the features you run, the number of realms and clients, whether users come from LDAP, Active Directory or other federation sources, and how much validation evidence and testing your assessor expects.

Cost components: Most of the fee covers planning, configuration, hardening, testing and handover. Infrastructure is usually a separate cost, because Keycloak runs in your cloud accounts, data centers or air-gapped networks.

One-time versus recurring: The build and first validation are one-time work. Patching, upgrades and re-testing after version changes recur and can sit under a retainer.

Ask for: a line-item quote that ties each realm, client group, federation source and test deliverable to a price, and states which infrastructure costs stay with you.

How long does a Keycloak FIPS mode project take?

Duration follows scope, and no single timeline fits every environment. Ask for a schedule in the written scope with milestones for design, build, testing and cutover.

Factors that extend time: the number of realms and clients to configure or migrate, each federation source that needs connection and testing, client applications that must change their algorithms or key settings, and the number of environments that must pass FIPS mode testing before production, since each one adds a test cycle.

Factors that add waiting time: change approvals, access requests for infrastructure, and reviews by your security or compliance team.

Fixed-scope engagements agree timelines in writing before work starts, so ask the proposal to name which dependencies sit with your team and which sit with the partner.

Does Kerberos work with Keycloak in FIPS mode?

Plan on no. Kerberos and SPNEGO desktop sign-in are documented as incompatible with FIPS mode, so confirm this against the documentation for the exact Keycloak version you intend to run.

This is a design decision to settle before the build starts. If users depend on transparent sign-in from domain-joined desktops, you have a few options: keep a separate non-FIPS deployment for that workload, move that sign-in path to another method, or document the exception and agree it with your assessor.

Check other features in your configuration as well. Any feature that depends on algorithms or key types outside the FIPS boundary needs the same review, and the list should be complete before the scope is signed.

What does our team need to provide for a Keycloak FIPS project?

Your team provides decisions, access and people who can approve work. Name these owners at the start of the engagement.

Named owners: an executive sponsor, a product owner for the identity service, a Keycloak administrator, a security or compliance reviewer, and an owner for each federated directory and each client application.

Access: administrative access to the cloud accounts, hosts or clusters, DNS, certificate issuance, and any key management service or hardware security module in use.

Test accounts: accounts for each user type, including administrators, federated users, users with MFA and any service accounts.

Decisions: whether to run strict or non-strict mode, how to handle Kerberos and any other conflicting feature, and who approves changes to production. Ask the proposal to list each dependency with a due date.

Can our own team set up Keycloak in FIPS mode?

Yes, if the team has the skills and time, but the work covers more than Keycloak administration. It touches Java runtime and cryptographic provider settings, TLS and keystore management, identity protocol testing, and the evidence an assessor will ask for.

Trade-offs: An internal team builds lasting knowledge and owns every change. A partner brings prior implementation experience and delivers against a fixed scope, but your team still has to operate the result.

Common split: Internal staff own day-to-day operations and approvals, while an outside team handles design, configuration, hardening and validation evidence.

Ask any provider, including your own team's plan, to confirm the FIPS-specific settings against the current Keycloak documentation and the validated cryptographic module it relies on.

Does DeployOpen provide FIPS validation, certification or audit reports?

No. DeployOpen does not issue certifications, audit reports or attestations. It plans, implements, hardens and documents Keycloak in your infrastructure, and it prepares the systems, controls and evidence your assessment needs. Independent auditors and certification bodies make the determinations.

Keycloak's FIPS mode relies on the BouncyCastle FIPS libraries, so ask which validated module and version your configuration uses and whether your assessor accepts that module for your system boundary.

Deliverables prepared for an assessment can include configuration records, test results and operating runbooks. Your assessor decides what those records prove. Confirm the exact deliverable list in the written scope before work starts.

What validation evidence should we request before going live with FIPS mode?

Request evidence that ties the running configuration to a validated cryptographic module. Ask for these items in writing before go-live.

Module record: the module name, its version, and its validation certificate reference, so your assessor can check the module against the validation program.

Boundary check: confirmation that the deployed configuration uses only the approved functions of that module.

Settings record: the strict or non-strict mode decision with its justification, keystore type, key lengths, and the signing and encryption algorithms for tokens and SAML assertions.

Test record: results from each environment, including failed cases and how they were resolved.

Where a framework such as the FBI CJIS Security Policy sets FIPS or key-length expectations, check with your assessor whether those expectations apply to identity data and which algorithms they accept.

How DeployOpen scopes, delivers and supports Keycloak FIPS mode

DeployOpen scopes Keycloak FIPS 140-2 mode as part of a written, fixed-scope engagement, covering the mode settings, the cryptographic libraries, and the features that must change under it. Work is built inside your own infrastructure, tested against your configuration, and handed over with documentation your team can run. Ongoing support and upgrades are available as a retainer.

How we scope

The written scope names your Keycloak version, realms, clients and the protocols each one uses.
It lists which features in use conflict with FIPS mode, such as Kerberos, and how each will be handled.
Engagements are fixed-scope, so deliverables and timelines are agreed in writing before work starts.

How we build

Keycloak is deployed in your cloud accounts, data centers or air-gapped network, with FIPS mode configured there.
The build covers the cryptographic provider setup, keystore and key length choices, and TLS on every connection.
Non-strict and strict mode behavior is tested against your clients, identity brokers and federation sources.

How we hand over

Documentation records the approved FIPS configuration, the settings that must not change, and the reasons for each.
Test evidence shows which login, token and federation flows were verified under the FIPS configuration.
Your team receives run procedures for upgrades, certificate rotation and checking that FIPS mode stays enabled.

How we support

Retainers cover ongoing support, upgrades and continuous testing of the FIPS configuration after go-live.
Each Keycloak upgrade is re-checked against the FIPS settings before it reaches production.
Ask whether your retainer includes testing of the FIPS settings on each upgrade, and who approves changes.

Keycloak FIPS 140-2 mode