Keycloak Hardening Guide: 20 Security Best Practices

The Penetration Test That Found the Admin Console

Fatima Al-Rashid, CISO of a Dubai-based logistics platform handling customs documentation for 400+ freight forwarders, had deployed Keycloak eighteen months earlier. The deployment was solid — multi-realm setup, separate realms per enterprise client, MFA enforced across the board.

The penetration test her team commissioned before their ISO 27001 certification audit found something she hadn't expected. The Keycloak admin console — /auth/admin — was reachable from the public internet. It required credentials to access, and those credentials were strong. But the tester demonstrated a credential stuffing attack using a list of 50,000 breached email/password combinations against the admin login endpoint. The rate limiting was set to Keycloak's default: 30 failed attempts counted over a 12-hour window — after which the account locks for 15 minutes.

The tester's script tried 2,400 credential pairs spread across many different accounts. No single account locked out — because each account received only a handful of attempts, well under the 30-failure threshold. This is the fundamental weakness of per-account lockout against credential stuffing: the attacker gets two or three attempts per account and simply moves on. The real finding was the absence of IP-rate limiting. The admin password wasn't in the list, but the endpoint being internet-accessible — with no mechanism to throttle requests across accounts — was enough for the ISO auditor to raise a finding.

Fatima spent the following week working through a hardening checklist. Eighteen changes. Twelve of them were configuration defaults Keycloak ships with that are reasonable for development and wrong for production.

This guide covers the 20 controls that matter most for production Keycloak deployments, organized by impact.

---

Why Default Keycloak Configuration Is Not Production-Ready

Keycloak's default configuration is designed to get a developer running in under ten minutes. That goal shapes every default setting: HTTP is permitted, the admin console listens on any interface, brute force protection is permissive, session timeouts are generous, and token lifetimes are long enough that a developer doesn't have to constantly re-authenticate while building.

These aren't bugs. They are intentional defaults, optimized for a development environment, and every one of them is wrong for production.

Five categories account for most of the hardening work. Admin console exposure — the finding that surfaced in Fatima's audit — is the highest-risk default because it puts full platform control one successful credential attack away from compromise. Brute force settings are a close second: Keycloak's default of 30 failed attempts before lockout is permissive enough that credential stuffing attacks run for hours before triggering a response.

TLS requirements are the third category. Keycloak defaults to allowing HTTP connections, which means tokens can travel in plaintext if the deployment doesn't enforce HTTPS at every layer. Session timeouts and token lifetimes round out the list — defaults are set for developer convenience, not for environments where prolonged session persistence increases the value of a stolen token.

The audit consequences are consistent and well-documented. In ISO 27001 assessments, an externally reachable admin console is a non-conformance against Annex A control A.9.4 (Access to programs and utilities) in ISO 27001:2013 (equivalent to controls 8.3 and 8.18 in ISO 27001:2022). In SOC 2 Type II engagements, permissive brute force thresholds and long-lived access tokens appear as common observations under the Logical and Physical Access Controls category. PCI-DSS auditors flag both default session timeouts and missing MFA on privileged accounts as findings under Requirement 8. These are not theoretical. They are line items on audit reports that delay certifications and require remediation evidence before a finding is closed.

Working through these five categories systematically is what Fatima's team did. The 20 controls below are that systematic approach, organized so the highest-impact changes come first.

---

Admin Console and Network Controls (Controls 1–5)

Control 1: Restrict the admin console to your internal network. The Keycloak admin console — whether it lives at /auth/admin or /admin depending on your version — controls every user account, every client configuration, and every realm policy on your platform. It has no business being reachable from the public internet. Block it at the reverse proxy or load balancer layer, restricting access to your office IP ranges and internal VPC. This single change would have removed the finding in Fatima's audit before the penetration test even began.

Control 2: Separate the admin realm from your application realms. Keycloak's master realm is used for bootstrapping and for administering other realms. Application users should authenticate against dedicated application realms, never the master realm. This separation limits the blast radius if an application realm is misconfigured — a vulnerability in one realm's client settings doesn't automatically grant access to Keycloak administration.

Control 3: Enforce MFA for every admin account, with no exceptions. Admin accounts control the entire platform. A compromised admin credential without MFA is a full platform compromise. Configure authentication flows so that any user in an admin group must complete a second factor — hardware key or TOTP — before accessing the admin console. No exceptions for "I'm just checking something quickly." An attacker with admin access can create new clients, disable brute force protection, export realm configuration with all secrets, and create backdoor admin accounts — all in under three minutes. Password strength offers no protection against a credential that was phished or leaked in a prior breach.

Control 4: Create dedicated admin accounts and retire the bootstrap credentials. The initial admin username created during Keycloak setup is the first credential a threat actor will try. Create named accounts for each administrator — accounts tied to real individuals, tracked in your identity lifecycle process. Disable or delete the original bootstrap account. When an administrator leaves the organization, their account is deprovisioned. A shared bootstrap account has no owner and no lifecycle.

Control 5: Disable the master realm for application logins. The master realm should be reserved exclusively for Keycloak administration. Disable client logins against the master realm entirely. This means application users cannot authenticate against it even if a misconfigured client is accidentally created there.

KeycloakPro managed deployments include all 20 hardening controls applied at setup, with quarterly security reviews. View our Managed Keycloak plans →

---

Brute Force and Authentication Controls (Controls 6–10)

Control 6: Enable brute force detection and lower the failure threshold to 5. Keycloak ships with brute force detection disabled, and when you enable it, the default maximum failure count is 30. That's 30 password attempts per account before a lockout. In Fatima's case, 2,400 credential pairs spread across many accounts cycled through with no lockout — because each individual account saw only two or three attempts. Per-account lockout only helps when an attacker hammers one account; against credential stuffing, the attacker stays under the threshold on every account. Lowering the threshold to 5, and pairing it with IP-rate limiting, addresses both attack patterns. A legitimate user will not fail to log in five times in a row. A credential stuffing script will.

Control 7: Set a meaningful wait increment and maximum lockout window. After the failure threshold is crossed, Keycloak can apply a progressive lockout — each subsequent failure extends the wait time. Set the wait increment to 30 seconds and the maximum wait to 15 minutes. This makes automated attacks operationally expensive: after 5 failures, the attacker waits 30 seconds. After the next failure, longer. An attack that requires 15 minutes between attempts on each account becomes infeasible at scale.

Control 8: Enable permanent lockout for external-facing accounts. Keycloak's permanent lockout mode locks an account the first time it hits the failure threshold and keeps it locked until an administrator manually unlocks it — there is no automatic recovery. Enable this mode for external-facing accounts where the risk of a targeted attack outweighs the support overhead of manual unlocks. Establish an administrator review process for locked accounts before re-enabling them, so that unlocks are deliberate decisions rather than reflexive resets.

Control 9: Disable the direct access grant (Resource Owner Password Credentials flow) unless you have a specific, documented requirement. This flow allows applications to collect usernames and passwords directly and exchange them for tokens, bypassing the Keycloak login page and all its protections. Most modern applications don't need it. Legacy integrations that do need it should be documented as exceptions. For every other client, disable it. When this flow is left enabled, an attacker who discovers a client ID can run credential stuffing directly against the token endpoint, bypassing login-page rate limiting entirely and collecting valid tokens with no visible sign of attack in the UI-facing logs.

Control 10: Shorten the login timeout. Keycloak's default login action timeout — the window in which a user must complete the login process after initiating it — is 30 minutes. That's the time an attacker has to intercept a partially-completed authentication flow. Five minutes is sufficient for any legitimate login. Set it there.

---

TLS and Token Security (Controls 11–15)

Control 11: Require HTTPS for all connections — enforce sslRequired: all at the realm level. Keycloak allows this to be set to "external requests only," which sounds reasonable but still permits HTTP on what it considers internal traffic. In a production environment, every connection carries real credentials or real tokens. Set sslRequired to all in every realm's settings. This ensures Keycloak rejects any request arriving over HTTP regardless of its apparent origin.

Control 12: Verify that access token lifetimes are enforced at 5 to 15 minutes. Short-lived access tokens limit the window an attacker has if a token is stolen. Keycloak's default is 5 minutes for access tokens, which is reasonable — but confirm this hasn't been extended for developer convenience and never reverted. Many production deployments discovered in security reviews are running 60-minute or even 8-hour access tokens set during initial development.

Control 13: Enable refresh token rotation. When refresh token rotation is enabled, each time a client uses a refresh token to get a new access token, the old refresh token is invalidated and a new one is issued. If a refresh token is stolen, the attacker can use it once — but the moment the legitimate client's next refresh request fails (because the stolen token was already consumed), the session is invalidated. This limits the persistence an attacker gains from a single token theft.

Control 14: Set refresh token maximum reuse to zero. Maximum reuse of zero means a refresh token is invalidated immediately upon use. There is no scenario in a properly architected application where a refresh token should be usable more than once. Setting reuse to zero enforces rotation strictly, with no grace window that could be exploited. Note that this setting only takes effect when refresh token rotation (Control 13) is already enabled — without rotation, max reuse has no practical impact.

Control 15: Configure the token signature algorithm to RS256 or ES256 — not HMAC. HMAC-based algorithms (HS256, HS384, HS512) use a shared secret to sign tokens. Any party that can verify a token can also create one. In a distributed system where multiple services validate tokens, every service holds the signing secret, and a compromise of any one service compromises token integrity across the entire system. RS256 and ES256 use asymmetric keys: the private key signs, the public key verifies. Services can validate tokens without holding any secret that could be used to forge them.

---

Audit Logging and Monitoring (Controls 16–20)

Control 16: Enable admin events logging. Every change made through the Keycloak admin console — realm configuration changes, client modifications, user role assignments — should be recorded in the audit log. Admin events logging is disabled by default. Enabling it, with detail capture turned on, creates a record of who changed what and when. This record is essential for incident investigation and for compliance with frameworks that require configuration change tracking.

Control 17: Enable user events logging with 90-day minimum retention. Authentication events — successful logins, failed attempts, password resets, MFA enrollment changes — should be captured and retained for at least 90 days. Most regional compliance frameworks, including UAE PDPL and India's DPDP Act, require this retention window. Keycloak's internal event storage is configurable, but treat the internal store as a buffer, not a long-term retention mechanism.

Control 18: Configure the event listener SPI to ship logs to your SIEM in real time. Keycloak supports external event listeners through its Service Provider Interface. A properly configured event listener forwards every authentication and admin event to Splunk, Elastic, Datadog, or your organization's centralized logging platform as the event occurs. Keycloak's internal event database is not a SIEM — it has no alerting, no correlation, and no anomaly detection. Real-time forwarding means your security team can react to brute force patterns or admin console anomalies as they happen.

Control 19: Set up alerts for failed admin logins, brute force triggers, and realm configuration changes. Raw log data without alerting provides forensic value after the fact but no operational value during an incident. Three alert types cover the highest-risk events: failed admin console logins (indicating admin credential attacks), brute force protection triggers (indicating active user account attacks), and realm configuration changes outside business hours (indicating potential unauthorized admin access). These three alerts catch the scenarios most likely to precede a significant security incident.

Control 20: Monitor the Keycloak health endpoint and alert on response time degradation. Keycloak exposes a health check endpoint that reports the status of its dependencies — database connectivity, cache cluster health, and overall availability. Set up monitoring that polls this endpoint and alerts if response times degrade significantly. Keycloak performance degradation often precedes availability failures, and unusual slowdowns can indicate resource exhaustion from active attacks (such as login floods). The health endpoint also provides early warning of database connectivity issues before they become outages.

Security teams managing Keycloak in-house often find that controls 16–20 (audit and monitoring) are the ones that slip in practice. KeycloakPro's Full CIAM package includes SIEM integration setup and ongoing monitoring as part of the engagement.

---

Applying the Checklist: What Order Matters

Not all 20 controls carry equal risk, and not all of them can be implemented in a single afternoon. The order matters.

Do today — controls 1, 3, 6, 7, and 11. These five controls address the highest-probability attack vectors for a live Keycloak deployment: open admin console access, missing MFA on admin accounts, permissive brute force settings, and HTTP exposure. If your deployment is running in production right now without these five controls in place, you have active exposure. Every other item on this list can wait until tomorrow. These cannot. Verify this phase is complete by confirming that an external curl to /auth/admin (Keycloak pre-17, WildFly/Legacy distribution) or /admin (Keycloak 17+, Quarkus distribution) returns a connection refused or 403, that a test account locks after five failed logins, and that all Keycloak endpoints reject plaintext HTTP.

Do this week — controls 2, 4, 8, 9, and 12 through 15. This group tightens your authentication architecture and token security. Separating the master realm from application realms, retiring shared admin accounts, disabling unnecessary authentication flows, and enforcing proper token lifetimes and signature algorithms are all changes that require coordination — notifying the team, scheduling a brief maintenance window, verifying that client applications handle token rotation correctly. A week is a reasonable window to work through them with care. Before marking this phase complete, confirm that no application client still authenticates against the master realm, that all token introspection endpoints report the expected lifetime values, and that at least one named admin account can successfully authenticate end-to-end with MFA before the bootstrap account is disabled.

Do this month — controls 5 and 16 through 20. Disabling the master realm for application logins requires confirming that no application clients are using it — a check that takes time in complex multi-tenant environments. Audit logging and SIEM integration require procurement and configuration work on the SIEM side, not just Keycloak configuration. These are controls with broader organizational dependencies. Set a one-month deadline and track progress against it. Confirm this phase is complete by triggering a test login failure and verifying the event appears in your SIEM within two minutes, then confirm that a simulated admin configuration change generates an alert — those two checks validate that the logging pipeline and alerting are live, not just configured.

The structure here mirrors how Fatima's team worked through their hardening list: immediate risk reduction first, architecture improvements second, ongoing monitoring infrastructure third. Three weeks after the penetration test, her team had closed the ISO finding and had two additional monitoring controls live that the auditor hadn't required — controls she added because the process of working through the list made clear how much visibility had been missing.

---

This checklist covers configuration hardening. For the network and infrastructure layer, see our Keycloak on Kubernetes HA guide and Keycloak deployment in UAE for region-specific considerations.