Keycloak for financial services

In an open banking style design, Keycloak sits on the path of many customer API calls. It acts as the authorization server that issues OAuth 2.0 and OpenID Connect tokens to customer-facing apps, aggregators and licensed third parties that call your APIs. Before any profile work starts, inventory those API clients: which are public (such as mobile and browser apps) and which are confidential server-side clients, which grant types each one uses, which realms or clients hold the APIs, and which consent screens the customer sees. That inventory determines where a higher-assurance profile is needed and where the existing configuration is enough.

FAPI, the Financial-grade API security profiles published by the OpenID Foundation, tightens OAuth and OpenID Connect for financial APIs. It typically constrains client authentication, token binding or sender constraint methods, and how requests and responses are signed or protected. Keycloak's features documentation covers FAPI security profiles, but the options it exposes, their defaults and the exact behavior can change between minor releases. Confirm profile support and version behavior against the current Keycloak documentation and against the release you plan to run before you commit to a design. Any conformance claim should come from your own testing or an independent assessor, not from this page.

CIBA, Client-Initiated Backchannel Authentication, matters when the device that starts a transaction is not the device where the customer approves it. Typical cases include a merchant or call-center agent initiating a payment or a sensitive change, with the customer approving on a registered phone or app. Decide whether you need this flow at all, which party initiates it, how the approval request reaches the customer, and whether your client will poll for the result or receive a notification. Check which CIBA modes and binding message options your chosen release supports, because support in the documentation does not settle how your integration will behave end to end.

Scoping is the decision that drives effort. Separate the APIs that need FAPI requirements (for example, account information and payment initiation, if those are in your product) from internal or low-risk APIs that can stay on standard OpenID Connect. Keep the token lifetimes, client registration policy and consent handling for each tier written down. Release 26.8 notes make signature validation of backchannel logout tokens from external providers mandatory, which can affect any federated partner you connect, so review those partner integrations before upgrading. Ask any delivery partner for a written list of the profile options configured, the clients they apply to and the tests that prove them.

Operations and verification come last but determine whether the design holds. Keep the admin console and Administration REST API on a separate hostname or context path from public frontend URLs, enforce TLS on all communication, and restrict paths at the reverse proxy so customer endpoints do not expose administrative routes. Enable metrics on the management interface to watch token endpoint latency and error rates for each API tier. Build a regression suite for FAPI and CIBA behavior, and rerun it on every minor upgrade, since Keycloak says breaking changes in minor releases are opt-in and you must still confirm which options you have turned on.

The first design decision for a regulated sign-in service is which of Keycloak's three documented high availability architectures you will run, and that choice should be made before any infrastructure is ordered. The first option is a single cluster, optionally spread across availability zones within one region. The second is a multi-cluster deployment under the v2 design, which does not require an external Infinispan cluster. The third is multi-cluster v1, which used a separate Infinispan cluster per site and is deprecated. Start with one question that shapes everything else: does your required resilience stop at a single zone, or must the sign-in service survive the loss of a whole region? The answer narrows the options before any vendor or partner conversation begins.

Both supported designs need a synchronously replicated database, and this is the dependency most often underestimated. Keycloak keeps realms, clients, users and persisted state, including login failure records, in its database, so the database determines whether a failover preserves or loses committed changes. With synchronous replication, a write is confirmed only after the standby holds it. This protects against silent loss of configuration or audit-relevant records, at the cost of added write latency. Across sites, that latency depends on network distance and must be measured in your environment. Ask your database team to show how replication is configured, which nodes are synchronous, and how promotion is tested.

Keycloak lists a defined set of supported production databases: MariaDB, Microsoft SQL Server, MySQL, Oracle Database, PostgreSQL 14 to 18, EnterpriseDB Advanced, Amazon Aurora PostgreSQL and Azure SQL. The built-in dev-file database is for development only and cannot carry a production sign-in service. Your choice determines which replication and failover features you depend on, which licenses you carry, and whether a managed service is offered in the regions where your data may reside. Confirm the database choice against two inputs before procurement: your disaster recovery requirements, including recovery objectives agreed with the business, and your data residency rules, which govern where replicas and backups may be placed. Do not select the database from the Keycloak list alone.

Multi-cluster v1 should not be treated as a planning choice. It is deprecated, so it should not anchor a new design, and any design built on it would require migration within the life of the platform. The Keycloak 26.8 upgrade notes recommend moving from the deprecated multi-site feature to the stateless feature, which means any existing v1 estate should be inventoried as migration work with its own test cycle. Ask the implementation team to map your target design to the current documentation. If you run the Red Hat build of Keycloak, confirm the supported stateless configuration with Red Hat before you commit to the architecture. Record which parts of the design depend on a feature that has a stated deprecation path.

Once the architecture and database are chosen, the evidence regulators tend to examine is proof that failover works. Write down each failure scenario, including loss of a node, loss of a zone, loss of the database primary and, if your design covers it, loss of a site. Run each one against a non-production copy with the same topology. Enable metrics with --metrics-enabled=true so cluster health and cache behavior are visible during each test, and keep the results with the design record. DORA Article 28(8) asks for documented and tested exit strategies for ICT services that support critical or important functions. If that article applies to your entity, the same test records may also support a later exit or transition plan.

Keycloak change control starts with the release cadence. 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 will be opt-in. That makes each minor upgrade a planned change with a known scope. The team reads the release notes for the target version, lists which opt-in changes it intends to enable, and records each enabled option in the change request. The current release is 26.8.1, published October 13, 2026. A team on an older 26 line should decide which intermediate minor it will land on and how long it will run there. The change calendar should set the pace, and the record should show who chose the target version and why.

The 26.8 upgrade notes contain changes that alter production behavior, so each one needs an owner before the change window. SMTP StartTLS is now enforced without plaintext fallback, so mail relays that were never tested with TLS will fail password reset and notification flows. Backchannel logout tokens from external providers must have their signatures validated, which can break logout for partners that send unsigned tokens. Login failures are persisted to the database by default, which affects database growth and retention policy. The notes also recommend moving from the deprecated multi-site feature to the stateless feature. Each item should appear in the change request with an owner, a staging test and a sign-off, so the audit trail shows that the team read the notes and acted on them.

Database migration needs a deliberate choice. By default, Keycloak migrates its database schema automatically at startup. That is convenient for small environments, but it means a schema change happens inside a node restart with no separate review. The upgrading guide suggests manual migration for large deployments, where administrators apply the SQL themselves. For a regulated sign-in service, the manual path lets a database administrator review the statements, run them in a defined window and store the script as change evidence. Confirm with the vendor how to generate the migration SQL for your exact source and target versions, whether the migration can be reversed, and which database engines and versions the target release accepts. Keycloak's supported production databases include PostgreSQL 14 to 18, so check your database version against that list before scheduling the change.

The Keycloak Operator adds a second change path. The Operator documentation strongly recommends manual approval mode for operator updates to avoid unintended automatic upgrades, so set the Operator subscription to manual and treat each approval as a change gate. The approver checks the target Keycloak version, the release notes reviewed, the staging test results and the rollback plan before approving. Configuration changes also flow through custom resources: Keycloak, KeycloakRealmImport, KeycloakOIDCClient and KeycloakSAMLClient. If clients are defined as resources in Git, a pull request and its review become the change record for client changes. If clients are edited in the admin console, that drift from the declared state should be detected and recorded. Decide which path is authoritative before the first production change.

Rollback has to be tested, not assumed. Before any production change, take a database backup, export realm configuration, and confirm that the Operator version and custom resource manifests are stored in version control. Rehearse the restore in a staging environment built from the same backup, and record the time taken and the results in the change file. For an identity service that many applications depend on, this rehearsal is the evidence that the team can return to the prior state. DORA Article 28(8) requires documented and tested exit strategies and transition plans for ICT services that support critical or important functions. The SEC's guidance on internal control over financial reporting names program changes and computer operations among the IT general control areas that assessments examine. DeployOpen can prepare runbooks, change templates and rehearsal evidence, while independent auditors decide whether the controls operate effectively.

Start with the control catalog and the frameworks it maps to, because they decide what Keycloak must prove as well as how it is configured. Your catalog should list each control your organization tests for staff sign-in, such as multi-factor authentication, password, session and privileged-account requirements, with the requirement ID each one satisfies. The applicable frameworks determine which of those controls are in scope. PCI DSS v4.0.1 applies if staff can reach the cardholder data environment, and its requirement 8 covers identification and authentication. Non-bank institutions under FTC jurisdiction face the Safeguards Rule's multi-factor requirement unless the Qualified Individual approves an equivalent control in writing. Confirm with your assessor and legal counsel which frameworks apply to which systems. A written list of requirement IDs, each with a named owner, lets us size the realm design and evidence work from facts.

Next, document your network and hosting constraints and your identity sources. Keycloak's production guidance calls for TLS on all communication, a reverse proxy with path restrictions, and the admin console and Administration REST API on a different hostname or context path from public frontend URLs. Tell us where the proxy can sit, whether your monitoring stack can reach the management interface and metrics endpoint, and which network zones may hold the database. On identity sources, list each LDAP or Active Directory domain, Kerberos realm, upstream OIDC, OAuth or SAML provider, and any social provider you intend to allow. Each federated source adds attribute mapping, test cases and failure modes. Pair this with a client inventory that records every application, its protocol, its redirect URIs and whether it handles payment or customer data. A client that needs a FAPI profile or backchannel logout takes more design time than a plain OIDC login.

Your database and disaster recovery standards set the high availability design before any realm is built. Keycloak supports several production databases, including PostgreSQL 14 to 18, Microsoft SQL Server, Oracle Database and Amazon Aurora PostgreSQL, and both supported high availability designs require a synchronously replicated database. Confirm which engine your standards approve, which versions your database team supports, how backups are tested, and the recovery point and recovery time your critical sign-in service must meet. State whether schema migration may run automatically at startup or whether your change process requires administrators to apply the SQL themselves, which the upgrading guide suggests for large deployments. For entities covered by DORA, Article 28(8) expects documented and tested exit strategies for ICT services that support critical functions, so the exit and transition plan belongs in your inputs too. Each of these choices changes the number of environments, test cycles and failover drills in the statement of work.

Last, provide your change calendar and the named owners for each approval. Freeze windows, change advisory board lead times and your release cadence determine when cutover and testing can happen. Keycloak plans four minor releases a year, and its Operator documentation strongly recommends manual approval mode for operator updates, so your team should decide in advance who approves each version change and when it reaches non-production. Name one owner for realm design, one for the admin role model and privileged access, one for any MFA exception, one for production go-live and one for audit evidence. Where an MFA exception is needed, the Safeguards Rule route requires the Qualified Individual's written approval, so that person must be reachable within the schedule. A gap in approvers delays every milestone that follows, so confirm these names and their availability before the kickoff date is agreed.