Keycloak security hardening guide

Why Keycloak security hardening goes beyond installing a certificate

An identity provider that signs users into business applications becomes the control point for every session those applications grant, so security and audit teams will ask how it is configured, not only whether it uses HTTPS. Keycloak security hardening means configuring transport encryption, endpoint exposure, authentication controls, token lifetimes, event auditing and patch intake together as one posture. A single setting, such as installing a certificate, closes one gap and leaves the others open. The result has to be defensible as a whole, and that is the standard this section sets for the rest of the page.

The defaults used to start Keycloak in development are not a production posture. The development file database and the local start options are meant to get a realm running quickly, not to protect live credentials. Keycloak's production guide calls for TLS on all communication, which covers traffic between clients and the server and the connections to the database and any external providers the server contacts. It also calls for a reverse proxy with path restrictions, and for exposing the admin console and the Administration REST API on a different hostname or context path from public frontend URLs. The practical test is simple: an internet client should not be able to reach administrative paths through the public address, and your team should be able to show that with a request from outside the network.

Hardening also interacts with decisions made elsewhere in the rollout. The reverse proxy rules must match the chosen high availability design, because load balancers and session handling sit in front of the same paths. The database must be one of the supported production databases, and the choice affects how TLS to the database is configured and how backups are taken. Upgrade cadence matters too: the project plans four minor releases a year, and security-relevant behavior can change between them, so the hardened configuration needs a documented owner and a regression check after each upgrade. Confirm these dependencies early, because a configuration that was hardened against one topology may need rework when the topology changes.

Some controls are decisions your team has to make rather than defaults you can accept. Brute force detection, password policies, OTP and WebAuthn requirements, and access token and refresh token lifetimes each trade user friction against exposure, and the right values depend on the applications and the data they reach. Event auditing needs a decision on which events are stored, for how long, and who reviews them. Patch intake needs a named person who reads each security release and its upgrade notes. Ask your implementation partner to write these decisions down as part of the scope, so each one has a recorded rationale that an auditor can trace.

Keycloak is licensed under Apache 2.0, so your organization can inspect, modify and run it without a license fee for the software itself. That also means no vendor hardens it for you by default: the team owns the resulting configuration, including the proxy rules, realm settings, client definitions and any custom extensions. Before go-live, confirm who maintains each configuration file or operator resource, where the configuration is stored and reviewed, and how changes are approved. The Red Hat build of Keycloak is a supported distribution with its own support terms, so if you need vendor-backed support, confirm that scope in writing with Red Hat rather than assuming it applies to a community build.

Which Keycloak settings and extension points carry the hardening work

These settings and surfaces decide how much of a Keycloak deployment is exposed and how well sign-in resists abuse. Each card names a control, where it lives in the admin console or server configuration, and what to verify before go-live. The cards depend on each other: TLS and hostname settings determine which URLs the reverse proxy must serve, and the admin and metrics paths must be blocked at that proxy.

TLS and hostname configuration

Keycloak's production guide calls for TLS on all communication, so the server, the reverse proxy and every connection to the database and external providers should be encrypted. Hostname settings control the issuer and the URLs Keycloak places in tokens and discovery documents, so a wrong frontend hostname causes sign-in failures or exposes an internal address. Check the hostname configuration in server settings against the public address clients use, and confirm the certificate is valid for each hostname Keycloak answers on.

Management interface and metrics endpoint

Keycloak can serve health checks and, when started with metrics enabled, Prometheus-format metrics at /metrics on a management interface. Operational detail should not be readable from the public network. Confirm that metrics are enabled only where a scraper needs them, that the management port is reachable only from monitoring and orchestration networks, and that the scrape path is restricted to the scraper. Verify these settings in every environment, since each one is configured separately in server configuration.

Admin console, REST API and proxy path rules

The production guide recommends serving the admin console and Administration REST API on a different hostname or context path from public frontend URLs. The reverse proxy should forward only the paths public clients need and block admin and management paths from the internet. Test this from an outside network by requesting admin paths through the public hostname and confirming they fail. Review who holds admin roles and whether admin access has a separate network path.

Brute force, password and MFA policies

Brute force detection sits in the realm's security defenses settings and limits repeated failed sign-ins. Password policy, OTP policy and WebAuthn policy sit under the realm's authentication policies, and they set password rules, one-time code parameters and security key requirements. Set these per realm and test them against a non-production realm first, because a strict lockout or policy can block legitimate users. Confirm the values with the security owner and document the chosen settings.

Token and session lifetimes

Access token, refresh token and SSO session lifetimes are set in each realm's token and session settings, and individual clients can override some of them in their advanced settings. Long lifetimes extend the window in which a stolen token works, while short lifetimes increase the number of token requests and sign-in prompts. Review each client's lifetimes with its application owner, check for overrides that differ from the realm default, and confirm how logout ends sessions in every connected application.

Event logging and 26.8 behavior changes

Realm event settings control which user and admin events are stored and which event listeners receive them. The 26.8 upgrade notes persist login failures to the database by default, so plan storage and retention for that data. The same release enforces SMTP StartTLS without plaintext fallback and requires valid signatures on backchannel logout tokens from external providers. Confirm that your mail server supports StartTLS, that external providers' signing keys are configured, and that event retention meets your audit requirements.

Which hardening choices to make before go-live

This table compares the main Keycloak hardening decisions, the option each one offers, the operational trade-off it creates and when each option tends to fit. Read each row as a question to settle with your identity, network and security owners before the production cutover, because most of these choices are cheap to make early and expensive to reverse after users and clients depend on them.

Decision	Option A	Option B	When to choose which
Admin console placement	Dedicated admin hostname, reachable only from management networks or a VPN	Shared hostname with path restrictions at the reverse proxy	Choose a dedicated hostname when administrators reach Keycloak from a separate network zone. Choose a shared hostname only if the proxy rules are tested and the team can accept more reliance on path filtering.
Primary request filtering	Reverse proxy allowlisting of admin and management paths	Edge web application firewall as the main control	Allowlisting is precise about which paths are exposed but needs updating after each release changes endpoints. An edge firewall adds managed rules and logging but is a control you must configure and tune, so keep the proxy allowlist in place either way.
Brute force response	Temporary lockout that expires after a wait period	Permanent lockout until an administrator unlocks the account	Temporary lockout keeps helpdesk load low but gives attackers periodic retries. Permanent lockout is stricter but generates unlock tickets and can be abused to lock out real users, so it fits only where a fast, verified unlock process exists.
Access token lifetime	Short access tokens with refresh tokens for applications	Longer access token lifetimes for legacy clients that cannot refresh	Short lifetimes limit the damage from a stolen token but require clients to handle refresh correctly, and failures show up as users being signed out. Longer lifetimes suit legacy clients but widen the exposure window, so limit them to named clients and record the exception.
Event storage	Store user and admin events in the Keycloak database	Ship events to a central log store with its own retention	Database storage is simple but grows the database and needs cleanup jobs and a defined retention period. A central log store moves retention and search to the security team, but needs a shipping pipeline, a parsing rule set and tested alerts before go-live.
Existing realms after a 26.x upgrade	Review and adopt the new default settings realm by realm	Keep existing realm settings and record the differences	Reviewing each realm takes more testing time but aligns login failure persistence, SMTP and token settings with current expectations. Keeping old settings is faster but leaves gaps that surface during audits, so record every accepted difference with an owner and a date.
Email transport	Enforce StartTLS for SMTP with no plaintext fallback	Allow plaintext fallback for a legacy mail relay	Strict StartTLS protects password reset and notification mail but fails if the relay cannot negotiate TLS, which stops those messages. Confirm the relay's TLS support during testing rather than discovering the gap in production.
Backchannel logout validation	Require signature validation for logout tokens from external providers	Accept unvalidated logout tokens from providers that cannot sign them	Validation blocks forged logout requests but breaks integrations with providers that do not sign tokens correctly. Test each brokered provider's logout flow before enabling enforcement, and document any provider that must be excluded.

How to harden a Keycloak deployment step by step

This sequence takes a Keycloak installation through eight ordered hardening steps, from transport encryption and network placement to policy, logging and release handling. Each step has an owner and closes with a test that shows the control works. The result is an admin surface isolated from public traffic, sign-in policies that match your security standard, and a defined path for security releases.

Enforce TLS on public and internal paths
The platform engineer configures TLS on the Keycloak listener, the reverse proxy listener and every connection between them, including links to the database and to any directory or identity provider a realm calls. Keycloak's production guidance calls for TLS on all communication. Confirm that each certificate chain is complete, that it covers the hostnames users and services actually use, and that it validates from a clean client. Closing check: a plain HTTP request to the public hostname is refused or redirected, and a TLS inspection tool shows a valid chain with matching names for every hostname.
Restrict the management interface to a private path
The platform team enables the management interface only on a network segment that operators and the monitoring system can reach, such as a private subnet or a bastion path. Health and metrics endpoints stay off the public listener. If you enable metrics with the metrics option, scrape them only from the monitoring network. Closing check: from a host outside the restricted path, requests to the management port and to the health and metrics paths must fail, and the same requests from the monitoring host must succeed.
Split admin access onto a separate hostname
The team gives the admin console and the Administration REST API a hostname or context path that differs from the public frontend URLs used for sign-in, then sets the hostname configuration so generated links use the correct origin for each surface. Administrators reach the admin hostname only through the restricted path from the previous step. Closing check: the sign-in pages load from the public hostname, a request for the admin console path on the public hostname returns no admin page, and the admin console loads only from the admin hostname.
Write reverse proxy path rules for exposed endpoints
The proxy team builds an allowlist of paths that applications and users need, such as the OpenID Connect endpoints and login pages for the realms in use, and denies all other paths by default. Admin, realm management and management paths stay off the public proxy. Review the list with each application owner so every allowed route has a named consumer and a stated reason. Closing check: requests to the admin console, the Administration REST API and an unlisted path are denied from the public side, and a full sign-in flow for each client still completes.
Set brute force, password and OTP policies per realm
The identity team enables brute force detection in each realm, sets the lockout behavior the risk owner approved, and defines a password policy and an OTP policy that follow the organization's written security standard. Record the chosen values with the realm configuration. Test the settings in a staging realm first, since lockout rules affect every sign-in path, including service accounts. Closing check: repeated failed sign-ins for a test user trigger the configured lockout, a non-compliant password is rejected on change, and OTP enrollment follows the policy.
Set token, session and refresh lifetimes
The identity team sets access token lifetime, SSO session idle and maximum values, and refresh token behavior for each realm, then overrides them per client where an application has a documented need. Shorter access tokens limit how long a stolen token stays useful, while session limits control how long a browser stays signed in. Agree the values with application owners, because they affect user experience and API behavior. Closing check: export the realm and client settings, confirm they match the record, then sign in, wait past the access token lifetime, and confirm refresh behaves as designed.
Enable event logging and retained storage
The operations team turns on user and admin event logging in each realm, keeps login failures persisted to the database, and routes events to a log pipeline or store with retention set by the organization's audit requirements. Keycloak 26.8 persists login failures to the database by default, so confirm that setting and monitor table growth. Closing check: trigger a failed sign-in and an administrative change, then confirm both events reach the retained store with the user, client, source address and time.
Configure SMTP with StartTLS and patch intake
The team configures the mail connection with StartTLS, which Keycloak 26.8 enforces without plaintext fallback, and sends test messages for password reset and email verification. In the same step, the team sets up patch intake: subscribe to Keycloak release announcements, assign an owner to triage security releases, and define a path into staging for testing before production. Closing check: a test email succeeds over StartTLS, a mail server without STARTTLS support causes the send to fail, and the intake owner can produce a dated triage record for the current release.

How hardening changes across single-node, HA and Kubernetes deployments

A single node is the simplest model to harden, and the easiest to harden only on paper. Development-adjacent installs often start with the default dev-file database and plain HTTP, and those settings must not carry into a production move. Keycloak's production guide expects TLS on all communication, so the node or a reverse proxy in front of it must terminate TLS with a certificate your clients trust.

TLS termination: Terminate TLS at a reverse proxy or on the node itself, and keep one owner for certificate renewal.
Proxy path rules: Allow only the public paths your applications need, and block the admin console and Administration REST API on the public hostname.
Admin exposure: Serve the admin console on a separate hostname or context path, reachable only from administrator networks.
Database encryption: Connect to a supported production database, such as PostgreSQL, over an encrypted connection. The dev-file database is for development only.
Metrics: If metrics are enabled, serve them from the management interface and keep that interface off the public listener.

A single machine also offers no second place to test failover, so treat that gap as a reason to be stricter about backups and patch windows. Confirm which environments are development and which will serve production users before copying the configuration forward.

What drives the effort of Keycloak hardening and how to keep it down

This table lists the counts and conditions that change how much work Keycloak hardening involves, and how to keep each one contained. Read each row as a question to answer before requesting a quote, since the quote should reflect these counts. The main takeaway is that a single standardized realm baseline and reusable templates usually lower effort more than any other single decision.

Driver	Why it changes effort	How to keep it down
Number of realms and clients	Each realm carries its own token lifetimes, password policy, brute force settings and event configuration, so every realm must be reviewed and tested separately.	Define one hardened realm baseline and clone it for new realms. Limit per-client lifetime overrides to the clients that truly need them.
Public and internal hostnames	Each hostname needs TLS, reverse proxy path rules and a check that the admin console and Administration REST API are not reachable from public frontend URLs.	Keep the number of exposed hostnames small. Reuse one proxy rule template across hostnames and confirm the separation with the same test script each time.
Custom login themes and SPI extensions	Themes, custom authentication flows and SPI extensions must be re-checked for security regressions on every Keycloak upgrade.	Minimize custom code, keep extensions in version control, and record which upgrades were verified against each customization.
User-facing flows that need MFA or passkeys	Each sign-in flow needs its own MFA or passkey policy, recovery path and lockout test to avoid locking users out.	Apply a small set of shared authentication flows and reuse them across clients, rather than building a flow per application.
Directory and brokered identity providers in scope	LDAP, Active Directory, Kerberos and external OIDC or SAML providers each affect trust settings, signature validation and attribute mapping.	Limit the providers in scope for hardening to those in production, and document the trust and mapping settings for each one in a single register.
Number of environments	Development, test and production each need matching TLS, proxy and token settings, and drift between them creates separate findings.	Manage realm and proxy configuration as code, promote the same definitions through each environment, and only vary secrets and hostnames.
Compliance evidence requirements	Assessors may ask for configuration exports, event logs, change records and proof of security release review for the same period.	Agree the evidence list before work starts, automate configuration exports, and retain event and change logs in the agreed format.

Securing admin access, secrets and the audit trail

Keycloak's administrative plane controls every realm, client and signing key, so it deserves its own hardening pass. The controls below cover who can sign in as an administrator, where secrets live, how the admin console is reached, and how long administrative and login evidence is kept.

Removing bootstrap admin credentials

The first administrator account is created at initial startup and is often left with a temporary password or a shared credential. Confirm that the bootstrap account is disabled or replaced with named administrators, and that its credential was never written to a shared runbook, ticket or container image. Check the current Keycloak documentation for the version in use, since the bootstrap method has changed across releases.

Designing administrator roles and MFA

Use the master realm only for platform administration and grant administrators the narrowest realm-management roles their work needs, rather than full administrator rights everywhere. Require multi-factor authentication for every account with administrative roles, and review role assignments on a regular schedule. Ask who can grant these roles and whether that approval is itself logged.

Keeping secrets out of configuration files

Database passwords, SMTP credentials, LDAP bind passwords and confidential client secrets should be injected from a secrets manager or the platform's secret store at runtime. Check that realm exports, Helm values, Operator manifests and version control contain no plaintext values. Confirm the rotation process for each secret, including the client secrets that applications depend on.

Limiting changes to realm security settings

Settings such as password policies, brute force detection, token lifetimes, required actions and client redirect URIs change how every user signs in. Restrict write access to these settings to a small group, and route changes through a reviewed, versioned process, such as realm configuration as code. Ask whether realm exports are compared against an approved baseline after each change.

Keeping the admin console off the public path

The production guidance calls for exposing the admin console and Administration REST API on a different hostname or context path from public frontend URLs. Enforce this at the reverse proxy with path restrictions, limit access to administrative networks or VPN ranges, and test that the admin paths do not respond on the public hostname. Confirm the exact proxy and hostname settings against the documentation for your version.

Retaining admin and login events

Enable admin event logging and login event logging, then decide where the records go and how long they are kept. Keycloak 26.8 persists login failures to the database by default, which affects storage planning and retention. Confirm that events reach your central log platform, that retention meets your internal policy, and that someone is responsible for reviewing them.

How to test that Keycloak hardening holds and fails safely

The point of this test set is to prove, from the outside, that the hardening controls described elsewhere on this page still hold. Configuration files and console screenshots show intent. Only an external test shows what an attacker or an unauthorized user actually reaches. Start from a network position outside the trusted network, using the public hostname that clients use. From there, confirm that the admin console paths and the Administration REST API return denied responses. Run the same requests against the hostname or context path that the production guide reserves for administration, and confirm that the public frontend hostname does not answer them. A denial that appears only when you test from inside the corporate network does not count as a passing result.

Next, test the transport layer as a client would see it. Check which TLS protocol versions the public endpoint negotiates, whether weak cipher suites are accepted, and whether the certificate chain is complete and trusted by a clean client without local overrides. Then confirm that the plaintext HTTP port is not reachable from any network segment that should not reach it, including the internal load balancer and any pod or host network that could be compromised. Record the exact commands and expected outputs in the test repository so that a reviewer can rerun them. Ask your security team which TLS baseline they require, and confirm the supported protocol list against the Keycloak production guide for the version you run, since the defaults can change between releases.

Brute force protection and password policy need a live test, not a settings review. Create a dedicated test realm that mirrors the production brute force detection settings, then script repeated failed sign-ins against a test user. Confirm that the account locks at the threshold the realm policy states, that the lockout message and HTTP responses match the documented behavior, and that the account recovers after the configured wait or after an administrator unlocks it. Run the same script for a password that breaks the password policy and confirm that the change is rejected. Record the realm settings beside the results, so that a later change to the policy produces a visible difference in the test output. Keep the test accounts and the test realm out of production user directories.

Token lifetimes and event auditing are the two controls most often assumed to work and rarely checked. For token lifetimes, request tokens for each client type in the test realm and decode the access, ID and refresh tokens to compare their expiry values with the access token lifespan, session and offline session settings configured on each client. A mismatch usually means a client-level override was missed. For events, generate known activity: failed logins, an administrative change to a user or role, and an update to a client's redirect URIs or secret. Then confirm that each event reaches the retained event store with the expected actor, time and target, and that the retention period matches your audit requirement. Ask your compliance lead which events they need to see and how long they must be kept, and treat any missing event type as a failed check.

The final checks test failure, not success. Break the reverse proxy rule that blocks admin paths in a non-production environment and confirm that the external test in the first step fails and raises an alert rather than passing silently. Stop the log shipper and confirm that a monitoring signal fires within the window your operations team has agreed. Plan these as scheduled checks, and run the full set after every Keycloak upgrade and after every realm change, including changes to clients, authentication flows and brute force settings. Write each check as a repeatable script with a clear pass or fail output, store the results with the change record, and assign an owner for investigating any failure. Scripts that only print output without failing a build or raising an alert do not prove that hardening holds.

What to audit, monitor and patch after go-live

Hardening a Keycloak realm is not a one-time project. The routines below keep the settings you chose, the events you can prove and the software you run in step with each other over time. Each card names a recurring check, the change that should trigger it and the record that proves it was done.

Reviewing realm security settings

Set a fixed review date for the security-relevant realm settings: brute force detection, password policy, OTP and WebAuthn policy, token lifetimes, session timeouts, and SMTP and TLS configuration. Export the current values and compare them with the hardening baseline, not with memory of what was changed. Record who approved each deviation and when it will be revisited.

Reviewing admin and failed login events

Review administrative actions in the admin events log and failed sign-in patterns in the user events log on a regular schedule. Look for admin changes without a matching change request, repeated lockouts against one account, and sign-ins from unexpected clients or regions. Confirm that event storage and retention meet your audit requirements before you rely on the logs as evidence.

Tracking security releases and upgrade notes

Subscribe to Keycloak release announcements and track the security advisories for the version you run. Read each upgrade note for hardening behavior changes, such as stricter SMTP transport rules, backchannel logout token validation or changes to how login failures are stored, before scheduling the upgrade. Treat a security fix as a reason to plan an upgrade, not a reason to skip the test realm.

Re-running verification checks after each patch

After every patch or minor upgrade, run the same verification checks you used at go-live. Confirm that TLS is enforced on public and admin hostnames, that the admin console and Administration REST API are still unreachable from public paths, that reverse proxy path rules still block what they should, and that token lifetimes and brute force settings did not reset. Store the results with the release record.

Keeping the hardening baseline as versioned configuration

Keep realm configuration, client definitions and reverse proxy rules in version control, and export the realm in a consistent format so that each change appears as a reviewable diff. A baseline stored this way lets you answer what changed, when and by whom, and it gives you a known-good state to restore to. Store secrets outside the repository and keep the export process itself under change control.

Documenting exceptions such as long-lived legacy clients

Some older applications cannot meet the baseline, for example a legacy client that needs a longer token lifetime or a relaxed redirect rule. Record each exception with the business owner, the technical reason, the compensating control, the scope limited to that client and an expiry or review date. Review the exception register at each scheduled review so that temporary deviations do not become permanent by default.

Questions buyers ask about hardening Keycloak

How much hardening work does a Keycloak deployment need?

The effort depends mostly on how many realms, clients and environments you run, and on how much of the hardening is already in place. A single realm with a few OpenID Connect clients and one production environment is a much smaller job than several realms, SAML and OIDC clients, directory federation and separate development, test and production stacks. Each realm carries its own password policy, brute force settings, token lifetimes and event configuration, so the count multiplies the review work. Ask any partner to list the realms, clients, hostnames and environments in writing before agreeing on scope, because that list is what the quote should follow.

Can our internal team harden Keycloak without an outside partner?

Yes, if you have people who already know Keycloak administration, reverse proxy configuration and your application token requirements. Hardening is mostly configuration and verification work, not new software development, so a capable internal team can do it. The usual gaps are time that identity engineers can spare, experience with proxy path rules that separate the admin console from public endpoints, and someone who can test token and session changes against every application. An outside partner is most useful when those gaps are real, when the timeline is short, or when you want an independent review of the result. Either way, write down who owns each control before the work starts.

What does the internal team need to provide during hardening?

Three groups of people are needed. Identity owners decide password policy, MFA expectations, brute force thresholds, session lengths and which events must be logged. Network and proxy owners control DNS, TLS certificates, load balancer and reverse proxy rules, and the separate hostname or path for the admin console and Administration REST API. Application owners confirm token lifetimes, redirect URIs, scopes and whether their APIs accept the tokens that will be issued. Application owners often need the most lead time, because a shorter access token lifetime can break a client that was never tested against it. Name one decision-maker for each group so that conflicting requirements are resolved before testing begins.

How long does Keycloak hardening take?

Duration depends on scope, so the honest answer is that it grows with the number of realms, clients, environments and integrations that need changes and retesting. Work that touches only the admin console exposure and TLS is usually contained. Work that also changes token lifetimes, federation, event auditing and proxy path rules across several applications takes longer, because each change needs application testing and a rollback plan. Ask for a written schedule that separates analysis, configuration in a non-production environment, application testing, production change and handover, and confirm which of those steps depend on your application teams' availability.

Does hardening Keycloak make our identity system audit-ready?

No. Hardening can put controls in place and produce evidence, but it does not make a system compliant on its own, and nobody can certify it by configuring it. DeployOpen plans and implements hardening and prepares controls and evidence for compliance assessments, such as configuration records, access reviews inputs, logging settings and change history. Independent auditors and certification bodies are the parties that assess the controls and issue reports or certifications. Before engaging anyone, ask which framework applies to your organization, which control IDs it maps to, and what evidence your auditor will expect to see.

How should we handle Keycloak security releases?

Treat security releases as a planned change, not an emergency that bypasses testing. The Keycloak project plans four minor releases a year and documents that breaking changes in a minor release are opt-in, but each upgrade still needs a read of the upgrade notes for behavior changes. Recent notes have included enforced SMTP StartTLS without plaintext fallback, mandatory signature validation of backchannel logout tokens from external providers, and login failures persisted to the database by default. Keep a non-production environment that mirrors production realms, test your critical sign-in flows after each release, and if you use the Keycloak Operator, consider manual approval mode so that updates are not applied automatically. Confirm with any partner whether support for security patches is included in their retainer or quoted separately.

Which hardening settings should we review first?

Start with the settings that change what an attacker can reach, then move to the settings that change user experience. First, confirm TLS is used on every connection and that the admin console and Administration REST API are reachable only through a separate hostname or context path from public frontend URLs. Second, review brute force protection, password policy and MFA options for the realms that handle sensitive access. Third, set token and session lifetimes per client, and check that event logging captures sign-in and administrative activity. Test each change with the application owners, because a setting that is correct for an administrator may break a mobile or API client.

How DeployOpen scopes, hardens and hands over Keycloak security work

DeployOpen plans, implements, hardens, documents and supports self-hosted Keycloak inside your own infrastructure, including your cloud accounts, data centers or air-gapped networks. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.

How we scope

Inventory the current Keycloak version, realms, clients, hostnames and reverse proxy layout before recommending any change.
Agree in writing which controls are in scope, such as TLS, admin console separation, password policy and event auditing.
Confirm the target database, high availability design and environments so hardening matches how Keycloak will actually run.

How we build

Configure TLS on all communication paths and expose the admin console and Administration REST API on a separate hostname or context path.
Write reverse proxy path rules that allow only the public endpoints users and applications need, and test each blocked route.
Set brute force detection, password policies, token lifetimes and event logging in test realms first, then promote the settings through your environments.

How we hand over

Deliver a configuration record that lists each hardening setting, its value, the reason for it and where it is applied.
Provide test evidence for proxy rules, login protections and token behavior so your security and audit teams can review them.
Document how to monitor login failures and metrics on the management interface and how to apply future security releases.

How we support

Ongoing support, upgrades and continuous testing are available as retainers, scoped separately from the original engagement.
Review upgrade notes for each security release and plan changes such as enforced SMTP StartTLS or signature validation of backchannel logout tokens.
Re-test hardened settings after upgrades or realm changes, and confirm with your team which controls the retainer covers.