Why Red Hat Keycloak Is Not What You Think "Open Source" Means

There is a conversation I keep having with CISOs across Southeast Asia and beyond. It goes something like this: we recommend Keycloak for their identity platform, and the room gets uncomfortable. "We looked at it," someone says. "It's open source." The tone tells you everything. In that sentence, open source means unsupported, unvetted, and unsuitable for production workloads that carry regulatory weight. And if we were talking about community Keycloak downloaded from GitHub and dropped into a bank's infrastructure, they would be right to be nervous.

But that is not what we are recommending. Red Hat build of Keycloak is a different proposition entirely, and the distinction matters more than most CISOs realise.

The perception problem

The enterprise scepticism around open source IAM is not irrational. Identity is the perimeter now. Eighty percent of breaches involve some form of credential compromise. When a CISO signs off on an identity platform, they are personally accountable for the thing that sits between every user and every system. The idea of trusting that to a community project with no contractual SLA, no guaranteed CVE response window, and no one to call at 2am on a Saturday is, frankly, a reasonable concern.

The mistake is assuming Red Hat Keycloak is that.

What Red Hat actually changes

Red Hat build of Keycloak takes the community Keycloak codebase and applies the same enterprise rigour that Red Hat has brought to Linux, OpenShift, and Ansible for decades. The differences are not cosmetic.

Curated release cycle.

Community Keycloak ships quarterly, including odd numbered minor releases that function as development milestones. Red Hat skips those entirely, shipping only even numbered releases (26.0, 26.2, 26.4 and so on) that have been through additional hardening and certification. Each minor release carries approximately twelve months of maintenance and patch support.

CVE response with accountability.

When a vulnerability is disclosed against Keycloak, community users wait for the next release. Red Hat customers get backported security patches within defined SLA windows, tracked through Red Hat's security advisory process. That is not a nice to have when your regulator wants evidence of your vulnerability management programme.

FIPS 140 2 compliance.

Community Keycloak does not ship in a FIPS compliant configuration. Red Hat build of Keycloak includes documented, supported FIPS 140 2 mode using BouncyCastle FIPS libraries. For any organisation operating under US federal requirements, or increasingly under APAC financial regulators adopting similar standards, this is table stakes.

Certified platform matrix.

Red Hat tests and certifies Keycloak against specific JVM versions, operating systems, databases, and container platforms. Community Keycloak works on whatever the community happens to test. When your auditor asks whether your IAM platform is running on a supported and certified stack, the answer needs to be unambiguous.

Operator lifecycle on OpenShift.

For organisations running Kubernetes, Red Hat provides an operator that manages Keycloak deployment, upgrades, and scaling as a first class citizen on OpenShift. This is not a Helm chart someone contributed. It is maintained, versioned, and backed by Red Hat engineering.

What you keep

Here is the part the proprietary vendors do not want you to think about. Red Hat Keycloak gives you everything above and you still get the core benefits that made Keycloak the most widely deployed open source IAM platform in the world.

No per user licensing. No seat based pricing that punishes you for growing. Full protocol support for OIDC, SAML 2.0, and OAuth 2.0 out of the box. A federation model that handles Active Directory, LDAP, and social identity providers without bolt on modules. An extension architecture that lets you customise authentication flows, user storage, and event handling without forking the product. And a community of over a thousand contributors ensuring the platform evolves faster than any single vendor's roadmap team could manage.

You get vendor backed enterprise software with the economics and extensibility of open source. That is not a compromise. It is the point.

The real comparison

The question CISOs should be asking is not "should we use open source for identity?" It is "should we pay seven figures annually for a proprietary IAM platform when a commercially supported, FIPS compliant, Kubernetes native alternative exists at a fraction of the cost?"

When we run this comparison for clients, whether against traditional IAM providers, the total cost of ownership gap is significant. Not because Red Hat Keycloak is cheap. Because the licensing model does not penalise scale.

The bottom line

Red Hat Keycloak is not open source in the way your board imagines it. It is enterprise software built on open source foundations, with the support, certification, and accountability that regulated industries require. The open source part is not the risk. It is the advantage.

If your current IAM vendor's next renewal proposal makes you flinch, it might be time to look at what Red Hat Keycloak actually is, rather than what you assume it to be.

Writer’s Overview

Ajit Gupta – Co-Founder & CEO, Midships  

Ajit leads Midships Group’s transition from a specialist identity consultancy to a portfolio of autonomous, AI-native business units. He focuses on long-term business relevance through platform thinking, customer outcomes, and scalable operating models.

Short bio: Ajit is a strategic founder with deep expertise in IAM, platform delivery, and AI services, driving Midships’ expansion across Asia, the Middle East, and beyond.

📧 ajit@midships.io  

🔗 LinkedIn: Ajit Gupta