5 Ptfalls of self-hosting Keycloak – lessons from the field

Keycloak is powerful – it’s protocol-rich, mature, and driven by an active community. That’s exactly why it’s almost impossible to avoid if you’re working with modern Identity & Access Management. But "powerful" also means "powerfully complex," and self-hosting often feels very different in practice than it does during the initial setup.

Here are five patterns I see time and again in client meetings, migrations, and architecture reviews – not as a critique of Keycloak itself, but as a reflection of the gap between what is "technically possible" and what is "manageable in daily operations."

1. Auth flows are treated as a one-off project, not a maintenance burden

The classic scenario: Someone configures a login flow – let’s say MFA with an IP exception for the internal network. What is often underestimated is that changes to auth flows in Keycloak go live immediately. There is no draft mode, no staging environment within the UI. A configuration error can, in the worst case, lock out all users – instantly and without warning.

The problem often only becomes apparent later. Six months down the line, someone else needs to make a minor change – and is faced with a flow graph they didn't build themselves and that isn't documented anywhere. What was intended as a one-time setup becomes a silent maintenance burden that no one plans for until it’s too late.

2. Conditional MFA is reinvented for every project

One of the first questions in almost every enterprise discussion: Can we skip MFA for users on the corporate network and enforce it when they are outside? Keycloak has a concept for conditions in auth flows, but the built-in conditions are limited. There is no native condition for network context, such as IP range or "internal vs. external." If you want to implement this, you have to build a custom SPI – a custom condition authenticator that must be developed as an extension, deployed, and maintained across Keycloak updates.

The mistake isn't in the implementation itself, but in what follows: every team I know has solved this problem in isolation. There is no standard for it, no common foundation – just the same requirement, rebuilt individually time and again, with a multiplied maintenance effort.

3. No lifecycle concept – until compliance asks for one

Keycloak does not have a built-in concept for inactive user accounts. No automatic detection, no tiered deactivation, no cleanup routine. For many teams, this isn't an issue for a long time – until a NIS2 or ISO 27001 audit specifically asks for it.

That is exactly when a feature that could have been planned for in advance turns into a high-pressure project: How do we identify inactive accounts retroactively? How do we document this for the auditor? Compliance requirements like these can be prepared for – but only if you plan for them before they become urgent, not after.

4. Branding means software development – for every change

What many only realize during operation: Branding in Keycloak is not a one-time setup, but an ongoing burden. Every adjustment to login pages – whether it’s a logo, colors, or text – is a code change that requires a build and deployment. Keycloak updates can break existing templates – especially with major version jumps, manual rework is the rule, not the exception.

5. SCIM maturity is overestimated

SCIM is the standard used by HR systems like Entra ID to automatically create, update, and deactivate users. In current Keycloak versions, inbound SCIM is only available as a technology preview (as of mid-2026) – and is not recommended by the upstream project itself for production use. Outbound SCIM, i.e., actively pushing user data to other systems, is completely missing.

The mistake: Integration projects are planned based on this preview functionality because it works in initial tests. In production, it becomes clear that "works in testing" and "production-ready" are two different things – leading to significant rework if HR onboarding is already built on it.

What they have in common

None of these five points are bugs or weaknesses in Keycloak. They are deliberate limitations of an open-source project that provides an identity engine—not the surrounding product ecosystem: administration, operational processes, compliance tooling, or user experience.

Anyone running Keycloak themselves can solve every one of these issues. The question is simply whether you want to do that on your own—or whether you should offload that work to where it has already been solved, allowing you to focus on the architecture that is truly specific to your business.