Keycloak security assessment

Why commission a Keycloak security assessment

A Keycloak security assessment reviews a self-hosted Keycloak deployment against its production guidance and produces a written findings report with prioritized remediation, so you can show a compliance assessor, a customer security reviewer or an insurer that the identity layer has been tested and its weaknesses are tracked. Teams usually commission one when a framework requires evidence of access control, when a customer questionnaire asks how user authentication is protected, when a product launch depends on single sign-on, or when an insurer asks about administrative access. DeployOpen prepares the evidence and the testing record. It does not issue audit reports, attestations or certifications; your independent auditor or certification body makes that determination.

Keycloak is often the trust anchor for every application behind it. A weak realm setting, an overly permissive client redirect configuration, a long-lived token lifetime or an administration console reachable from the public internet can affect many applications at once, because each relying party trusts the tokens Keycloak issues. The same goes for identity brokering: a federated identity provider configured with weak trust settings can admit users that the rest of the estate never intended to accept. Because of this reach, the assessment should cover the realm and client configuration, the token and session settings, and the admin console exposure together, not as isolated checklist items.

Before you commission the work, confirm which Keycloak version you run, how the reverse proxy routes traffic to the administration endpoints, and whether an inventory of clients, identity providers and realm roles exists. Ask the provider how findings will map to the production guidance, which controls the review will touch and how retesting will confirm fixes. The Keycloak production configuration guide is the reference point most reviewers will use, so agreeing up front that it defines the baseline keeps the scope and the final report aligned with what your assessor expects.

What a Keycloak security assessment can include

A Keycloak assessment usually spans the identity configuration inside the realms, the way the server is exposed through the network edge, and the internal links between nodes. The scoping decisions below determine which of these are tested, against which environment, and with what access.

Realms and clients

Reviewers check how each realm is separated, which clients are public or confidential, which redirect URIs and web origins are registered, and whether clients are limited to the grant types they actually use. Overly broad redirect patterns and clients with unnecessary service account roles are common findings. Reviewers also compare password policy, brute-force protection and required actions per realm against the organization's own identity requirements.

Admin console and Administration API

The assessment confirms whether the Administration REST API and Console sit on a separate hostname or context path, as Keycloak's production guidance recommends, and whether non-public REST endpoints are blocked at the reverse proxy. Reviewers check admin account count, MFA on administrator logins, and who can reach the console from outside the internal network.

Token and session settings

Token lifespans, refresh token rotation, session idle and maximum timeouts, and logout behavior are reviewed against the risk profile of each application. Reviewers look at how long access tokens remain valid after a user is disabled and whether sessions survive password changes. Signing key handling and token audience validation on the client side are included where the client code is in scope.

Identity brokering

Where Keycloak federates to external identity providers, the assessment checks trust configuration, how claims are mapped into local users and roles, and whether first-login account linking could let an external identity take over an existing local account. Reviewers also check whether brokered users can self-register and which attributes the broker can set.

Reverse proxy rules and TLS

Keycloak's guidance says all communication to and from the server requires TLS. The review covers certificate chains, cipher and protocol settings at the proxy, forwarded header trust, and whether the proxy blocks paths that should not be public. Overload behavior, including the http-max-queued-requests option, is confirmed where the deployment relies on it.

Cluster node communication

In a multi-node deployment, the assessment confirms that traffic between cluster nodes is encrypted with TLS, as the production guide describes, and that the cluster and its caches are not reachable from untrusted network segments. Reviewers also check how database credentials and TLS material are stored and rotated on each node.

How the assessment runs, phase by phase

The sequence moves from a written scope to evidence-backed findings, then to a report and an optional retest, so the client can see what was checked, how it was checked and what remains open. Each phase has a defined output that the next phase depends on.

Agree scope and rules of engagement in writing
Before any testing, DeployOpen and the client agree in writing which realms, clients, hostnames, reverse proxy paths, identity brokers and environments are in scope, which are excluded, and what testing is permitted against production. The client confirms who owns each system and who receives notifications during testing. The step closes when both parties have signed the scope document and the named contacts are recorded. Confirm with your team whether a separate test environment exists, since that affects what can be exercised safely.
Collect deployment and configuration evidence
The client provides the Keycloak version, the deployment topology (single node or cluster), the realm exports, the reverse proxy configuration, the TLS certificates and the relevant server options. DeployOpen reviews how these are supplied, including whether exports are sanitized of secrets. The step closes when an inventory lists every component in scope and every artifact needed for the review is on file, with gaps noted for the client to fill.
Review configuration against production guidance
DeployOpen compares the deployment against Keycloak's production configuration guide. The review covers whether all communication to and from Keycloak uses TLS, including node-to-node traffic in a cluster, whether the Administration REST API and Console sit on a separate hostname or context path, whether non-public REST endpoints are blocked at the reverse proxy, and whether overload protection such as the http-max-queued-requests option is set. Realm, client, token and session settings are checked against the client's own policy. The step closes with a configuration worksheet that records each setting, the observed value and the guidance it was compared against.
Test exposure and authentication behavior
Within the agreed scope and time window, testers confirm what an outside or low-privileged party can reach, including admin paths behind the proxy, unauthenticated endpoints, login and token flows, session lifetime, brokered identity flows and error handling. Testing is controlled and read-only where possible, and any action that could affect availability is agreed in advance. The step closes when each test case has a recorded result, evidence such as request and response captures with secrets redacted, and a note on any test that could not be completed.
Triage findings by impact and priority
Each candidate issue is validated, deduplicated and rated by impact and exploitability in the client's context, so a misconfiguration exposed only to internal networks is not weighted the same as one reachable from the internet. DeployOpen records the rationale for every rating and flags issues that need the client's own risk decision. The step closes when every finding has a unique identifier, a severity, an affected component and a recommended remediation, and false positives are documented rather than silently dropped.
Deliver the written report and walk through findings
DeployOpen issues a written report covering scope, method, the Keycloak production guidance used as the reference, each finding with reproduction-level detail for the client's engineers, and a remediation plan. Where the client needs the work mapped to CIS Controls, the report references Safeguard 16.13, which asks for application penetration testing, and notes that Safeguard 18.3 covers remediation of findings on a timeline set by impact and priority. A debrief with the technical team confirms the findings are understood. The step closes when the client has accepted the report and the remediation owners are named.
Retest remediated findings on request
After the client applies fixes, DeployOpen can retest the specific findings to confirm each one is closed or to identify what remains. The retest scope is agreed in writing and may be limited to the original findings. Confirm with DeployOpen whether a retest is included in the quoted scope or priced separately. The step closes with a short retest addendum that states each finding as closed, partially addressed or open, with the evidence used to decide.

How Keycloak is checked against its production guidance

The review starts from Keycloak's production configuration guide, not from a generic checklist, because that guide is the vendor's own statement of what a production deployment should look like. The first item is transport. The guide says all communication to and from Keycloak requires TLS, so the assessor confirms that the public hostname, the reverse proxy listener, the connection to the database and the connections between Keycloak and any backend it calls are all encrypted, and that no plain HTTP path accepts logins or tokens. The second item is separation of the administration surface. The guide recommends exposing the Administration REST API and Console on a different hostname or context path from the public realm endpoints, and the assessor checks where each is actually reachable from the internet, from the corporate network and from the management network.

The third item is the reverse proxy rule set. The guide says REST APIs that are not meant to be public should be blocked at the proxy, so the assessor compares the routes the proxy forwards against the endpoints the deployment needs for its own clients. Each allowed path is confirmed as intentional, and each blocked path is confirmed with a controlled request from outside the trusted network, recorded with its response. The fourth and fifth items cover availability and cluster traffic. The guide recommends the http-max-queued-requests option so that excess requests are rejected with a 503 response under overload, and it states that communication between cluster nodes is encrypted with TLS. The assessor reads the effective startup configuration and confirms both settings on every node, then runs a bounded load check to see the rejection behavior. Confirm the exact Keycloak version you run and which revision of the production guide applies to it before the review starts, because option names and defaults change between releases.

Which Keycloak weaknesses the assessment looks for

This table lists the weakness categories an assessment examines in a self-hosted Keycloak deployment, what each one looks like in practice, and why it matters to the organization. Read each row as a question to answer about your own realm, clients and proxy layer, not as a finding. The main takeaway is that most Keycloak weaknesses come from exposure and configuration choices made around the product, so the review covers the surrounding network and proxy as well as the realm itself.

Weakness category	What it looks like in Keycloak	Why it matters
Admin console or admin API reachable from the public internet	Administration Console or Administration REST API served on the same hostname and path as the public login pages, with no network restriction in front of it	Keycloak's production guidance recommends a separate hostname or context path for administration, so exposure on the public face widens the target for credential attacks and misuse of administrative functions
Overly broad client redirect or origin settings	Wildcard or loosely matched valid redirect URIs and web origins on clients, including clients that were created for testing and never removed	Permissive redirect rules can let an attacker steer authorization responses to a location they control, which weakens the trust a client places in tokens it receives
Weak token lifetimes and session handling	Access, refresh or SSO session lifetimes set far longer than the application needs, or idle timeouts left at defaults that do not match the data's sensitivity	Long-lived tokens and sessions extend the window in which a stolen token or unattended browser remains usable, which matters most for administrative and regulated applications
Misconfigured identity brokering trust and mappers	External identity providers trusted without reviewing their scope, or attribute mappers that copy claims into roles, groups or user fields without validation	A broker that is trusted too widely or a mapper that promotes an unverified claim can grant access that the originating identity provider never intended to issue
Excessive realm or client roles	Broad composite roles assigned to default groups, service accounts holding administrative roles, or client scopes that expose more attributes than each application uses	Over-privileged roles turn a single compromised account or client into a much larger impact, and make access reviews for auditors harder to answer
Unencrypted internal traffic	Traffic between Keycloak and the reverse proxy, database or other cluster nodes not protected by TLS, or certificates that are not validated	Keycloak's production guidance requires TLS for all communication to and from the server and encrypts cluster traffic, so gaps here can expose credentials and tokens inside the network
Reverse proxy rules that expose internal paths	Proxy configuration that forwards administrative, management or non-public REST paths to the internet, or that does not block them at all	Keycloak's guidance says REST APIs not meant to be public should be blocked at the reverse proxy, so a missing rule can expose functions that were never meant to face users
Missing overload controls	No limit on queued requests, so the server accepts excess load until it degrades instead of rejecting it	Keycloak's production guide recommends the http-max-queued-requests option to return a 503 response under overload, and without it a traffic spike or login flood can become an availability incident

How the assessment changes by Keycloak deployment model

A single-node instance is usually a proof of concept, a staging system or a developer environment. It runs one Keycloak process, often with an embedded or simple database and little or no reverse proxy. Because there is no cluster, cluster-to-cluster TLS and node discovery do not apply, and the review concentrates on whether the instance is accidentally reachable from places it should not be. Test instances frequently inherit realm exports, client secrets and admin accounts from production, so the assessor will check what data was copied and how the instance was reached.

Exposure path: Confirm whether the instance has a public address, a VPN-only address or only local access, and whether the admin console is reachable from the same hostname as the login pages.
Imported data: Identify realm exports, client secrets, user records and signing keys copied from other environments, since these can carry production trust into a lower-control system.
TLS termination: Establish whether TLS is terminated at the instance itself or at a proxy, because production guidance expects encryption for all communication to and from Keycloak.
Admin accounts: List the bootstrap and named administrator accounts and check whether they were removed or reused.
Promotion path: Ask how configuration moves from test to production and whether that process is documented.

What to check: whether this environment can be promoted to production without a rebuild, and whether anyone outside the test team can reach it.

Compliance and customer requirements this assessment supports

Few frameworks name Keycloak directly, but many expect application and identity testing, and a remediation timeline for what the test finds. The cards below connect those expectations to what a Keycloak assessment produces. Confirm with your auditor and customers which controls they map to identity.

Application penetration testing expectation

CIS Controls v8.1 Safeguard 16.13 asks for application penetration testing. For Keycloak, the identity provider is itself an application that issues tokens for every connected system, so an assessment of its login flows, client configuration and token handling is a natural way to evidence this safeguard. Confirm with your auditor whether they accept a scoped identity assessment or expect the testing to cover your relying applications too.

Remediation timelines for findings

CIS Safeguard 18.3 asks that penetration test findings be remediated within a timeline set by each finding's impact and priority. A Keycloak report should rate findings such as an exposed admin console or a permissive redirect URI by impact, so you can set and defend remediation dates. Ask the provider how severity ratings are assigned and whether they map to your own risk register.

Customer security reviews

Enterprise customers and partners often ask how users authenticate to your product and whether the identity provider has been tested. A Keycloak assessment gives you a dated report covering realm settings, TLS and token lifetimes that you can share under a non-disclosure agreement. Agree in advance which parts of the report a customer may receive, since full findings can reveal exploitable detail.

Cyber insurance questionnaires

Insurers frequently ask whether external authentication is protected by multi-factor authentication, whether administrative interfaces are restricted, and whether testing occurs regularly. Keycloak findings on admin console exposure and brokered identity configuration answer those questions directly. Ask your broker which evidence format they accept and whether a summary letter from the provider is sufficient.

Production configuration baseline

Keycloak's production guide requires TLS for all communication and recommends separating the Administration REST API and Console onto a different hostname or context path. Testing against that baseline gives an auditable record of which settings were checked, which were changed, and which were accepted as risk. Ask for a control-by-control mapping that your auditor can trace to their own framework.

What you prepare before the assessment starts

Before any testing begins, the client supplies a written scope and rules of engagement that name the Keycloak hostnames, realms, clients and identity brokers in bounds, the activities that are excluded (for example, load testing of the token endpoint or changes to production realms), and who may authorize a change to a live system. Alongside that, prepare a current Keycloak version and deployment diagram showing the nodes, the database, the cluster links and where TLS terminates. Confirm the version against the release notes and the production guidance in the Keycloak production configuration guide so the assessor can see which settings were in force when the review started. Also send the reverse proxy configuration, since the rules that hide the Administration Console and Administration REST API from public networks are often the first thing we check and are usually held by a different team than the Keycloak administrators.

Provide test accounts with defined roles rather than shared administrator credentials. A reasonable set includes a standard user in each realm, a user with a limited client or realm administration role, and, where the assessment covers it, an account for each identity broker such as an external identity provider. Keep an inventory of realms and clients with their redirect URIs, grant types and whether they are confidential or public, because this inventory is the baseline against which realm and client configuration is reviewed. Name the people who receive findings during testing and the contacts for incidents, including who can stop a test if a login outage or lockout occurs. Agree change freeze windows in advance, since many organizations do not allow configuration changes during quarter close or peak business periods.

A backup or an agreed rollback path must exist before any activity that could alter configuration, such as testing session limits, brute-force protection or lockout settings, or a review that requires temporary admin changes. Ask the client to confirm that the database backup is recent, that the realm export procedure works in their environment, and who can restore it within the agreed window. Keycloak stores realm, client and user data in its database, so a rollback plan should cover that layer as well as the container or configuration files. Confirm these steps with your own operations team and document them in the rules of engagement, so that a failed setting can be reverted quickly and the assessment record shows exactly what was changed and when.

What to check when choosing a Keycloak security provider

A Keycloak assessment is only as useful as the scope, method and evidence behind it. The cards below cover the checks that separate a provider who tests your identity platform from one who runs a generic web scan. Use them to compare proposals before you sign.

Written fixed scope first

Ask for a written scope that names the realms, clients, identity brokers, hostnames, reverse proxy rules and admin console paths in play before any testing starts. Fixed-scope engagements make it clear what is covered and what is not. Confirm whether the provider will test a staging copy or the production realm, and who approves that choice in writing. A proposal that only says "identity platform" leaves the key surfaces unagreed.

Method tied to production guidance

The method should be measured against Keycloak's published production configuration guidance, not only a generic checklist. Ask how the provider checks TLS on all communication, admin console separation from the public hostname, blocking of non-public REST endpoints at the proxy and queue limits under overload. A good answer names each check and the evidence it produces.

Experience operating self-hosted Keycloak

Testing Keycloak well requires knowing how it is deployed, clustered and upgraded in a self-hosted setting. Ask who on the team has operated Keycloak in production, how they handle cluster node encryption and database configuration, and how they distinguish a product default from a site-specific choice. Ask for a description of comparable work without client names, and confirm it can be checked through references.

Clear handling of credentials and tokens

Testing an identity platform means handling admin credentials, client secrets, test user accounts and sometimes live tokens. Ask where those are stored during the engagement, who can access them, how long they are kept and how they are destroyed at close. Confirm test accounts are created for the engagement and removed afterward, and that no production user data is copied out of your environment.

Findings separated from observations

The report should separate confirmed, reproduced findings from observations, hardening suggestions and items that could not be verified. Each confirmed finding should state the affected component, the evidence, the risk and the remediation direction. Ask for a sample report structure before you commit, and check that it shows severity and a clear basis for each rating.

Retest included or priced separately

Remediation of Keycloak configuration usually needs a second look. Ask whether one retest round is included in the fixed scope or quoted separately, and how the provider confirms that a fix works without re-running the whole assessment. Clarify the timing, the evidence accepted for closure and how a retest supports your remediation timeline under the CIS Controls penetration testing and remediation safeguards.

Keycloak security assessment questions buyers ask

How much does a Keycloak security assessment cost and why does the price vary?

The cost depends on the written scope, not on a standard package. DeployOpen does not publish a price list, and a quote follows from the agreed scope. The main drivers are the number of realms, clients and identity brokers in scope, whether the admin console and REST API are tested from the internet or only from inside the network, how many environments (production, staging, disaster recovery) are covered, and whether the review includes testing or only configuration review. A quote should list each component, state whether it is a one-time fee or a recurring retainer, and name the deliverables, including the report and any retest. Ask the provider to show which items are included and which are optional.

How long does a Keycloak security assessment take?

Duration is set by scope and by how quickly the client provides access and answers questions. The largest factors are the number of realms and clients, the number of identity providers configured for brokering, the complexity of the reverse proxy and TLS layout, and whether a cluster is involved. Delays usually come from waiting for configuration exports, change windows, or sign-off on test accounts. Ask for a timeline in the written quote that separates preparation, testing, reporting and the readout, and confirm which of these depend on client actions.

What does our team need to provide before the assessment starts?

Most reviews need the Keycloak version and deployment method, a realm configuration export, a list of clients with their redirect URIs and grant types, the reverse proxy configuration, TLS certificate details, and the identity brokering setup. For any testing, the client should name test users with roles that match real use, confirm the testing window, and name a technical contact who can respond during the engagement. Access rules and the scope boundaries should be documented in writing before work begins.

Can our internal team run a Keycloak security review without an outside provider?

Internal teams can review many items themselves, such as checking whether the admin console is reachable from the public internet, whether TLS covers all traffic, and whether token lifetimes and client settings match the production configuration guidance from the Keycloak project. An external assessment adds value when the organization needs independent validation, a second set of eyes on realm design, or a report that a customer or regulator will accept. Ask any provider to explain its methodology, how it documents findings, and how it avoids disrupting production identity services.

Will a Keycloak security assessment satisfy our auditor?

An assessment produces evidence, but it does not create an audit opinion or certification. DeployOpen prepares systems, controls and evidence for compliance assessments, while independent auditors and certification bodies issue reports and attestations. Before commissioning work, confirm with your auditor which framework and controls apply, which evidence they expect (for example, configuration records, test results and remediation tracking), and whether they accept testing performed by the organization's chosen provider. Relevant control references, such as the penetration testing and remediation safeguards in CIS Controls v8.1, should be agreed in advance.

How does retesting work after the findings are fixed?

Retesting checks whether agreed findings have been remediated and whether the fix introduced new issues. Whether retesting is included depends on the written scope. Ask the provider to state the retest window, how many retest rounds are included, how fixed items are verified (configuration review, repeated testing, or both), and how the updated report is issued. Remediation timelines should follow the impact and priority of each finding, as CIS Controls v8.1 Safeguard 18.3 describes. Retesting can be a fixed part of the engagement or an option under a retainer.

Does a Keycloak security assessment touch our production identity services?

It can, depending on the agreed scope. Configuration reviews are read-only and carry little operational risk, but any active testing against login flows, token endpoints or the admin API may affect live users or sessions. The safer approach is to test in a staging environment that mirrors production configuration, with production limited to agreed, low-impact checks in a defined window. Confirm in the written scope which environments are tested, who approves production activity, how the provider handles accounts and data it encounters, and what rollback or escalation contacts apply.

How retesting confirms Keycloak fixes

Retesting closes the loop on a Keycloak assessment by checking each finding against the remediation that was agreed in the scope, not against a general sense that things look better. For every finding, the retest repeats the original check on the same realm, client, proxy rule or setting and records one of a small set of outcomes: fixed, partly fixed, not fixed, or accepted risk with a named owner. The report is then updated so each finding carries its original evidence, the change that was made, and the retest result. Ask for this per-finding format in the quote, because a single pass or fail line for the whole engagement gives an auditor or customer nothing to trace.

Remediation timing should come from the client's own vulnerability management policy first. Where the organization has no written timeline, CIS Controls v8.1 Safeguard 18.3 asks that penetration test findings be remediated on a timeline set by each finding's impact and priority, so the client should agree those timelines with the tester and the platform owner before the report is final. Typical Keycloak items to plan for include admin console and Administration REST API exposure at the reverse proxy, TLS on all communication including cluster node traffic, and token and session lifetimes. Confirm with your own change process whether a configuration change to a production realm needs a maintenance window, since that determines when the retest can run.

Some findings will depend on upgrades, realm restructuring or brokered identity providers that take longer than one cycle to change. Plan a follow-up retest for those items instead of marking them closed on paper. If your organization wants continuous assurance rather than a single retest, ongoing review of configuration drift, Keycloak version currency and new findings can be arranged as a retainer, with the scope, cadence and deliverables agreed in writing before work starts. Ask for the retest fee and any retainer terms to be stated separately in the quote so the one-time and recurring costs are visible.

How DeployOpen scopes, tests, reports and retests Keycloak

DeployOpen is a Chainscore Labs company that plans, implements, hardens and supports self-hosted open-source platforms inside the client's own infrastructure, and runs security testing on them. Each Keycloak assessment starts from a written, fixed scope that sets out what is reviewed, tested, documented and handed over.

How we scope

Agree in writing which realms, clients, identity brokers and hostnames fall inside the assessment.
Confirm the Keycloak version in use and whether the administration console and REST API are reachable from outside.
Set out deliverables, timelines and testing windows in the written scope before any work begins.

How we build

Review realm, client and token settings against Keycloak's production configuration guidance.
Test admin console exposure, reverse proxy rules, TLS on all traffic and cluster node encryption.
Check session lifetimes, brokered identity trust and overload handling such as the http-max-queued-requests option.

How we hand over

Deliver findings mapped to Keycloak's own production guidance, with severity, evidence and affected configuration.
Provide remediation steps written for the platform team that operates the Keycloak deployment.
Document the tested configuration so it can be shared with an internal audit team or an independent assessor.

How we support

Retest agreed findings after fixes are applied to confirm the configuration now matches the guidance.
Offer ongoing support, upgrades and continuous testing for Keycloak as a retainer if the client wants it.
Confirm with the client which controls and evidence their own compliance assessor will need from this work.