Red Hat Single Sign On, at the end of its line.

Red Hat Single Sign On licensing meters by core on the host running the identity server at runtime. The product is the Red Hat supported distribution of Keycloak, packaged as a JBoss EAP based identity provider for enterprise single sign on, identity brokering, and user federation. The metered unit is the execution core on the SSO server tier. Authentication transactions, identity brokerage federations, and registered application clients are not metered separately under the legacy entitlement.1

The product entered a maintenance posture as Red Hat brought the upstream Keycloak project under a refreshed support brand called the Red Hat build of Keycloak. The legacy Red Hat Single Sign On entitlement continues to renew for estates that have not migrated, but the seller side discourages new deployments on the legacy SKU and prices migration paths into the build of Keycloak. The two products share an engine; the entitlement, support boundary, and version cadence diverge.

For the broader middleware practice context, see the JBoss and middleware practice hub. For the benchmarking observations that anchor the unit price ranges, see the benchmarking service hub.

Three migration traps recur on Red Hat Single Sign On estates moving toward the build of Keycloak. Each is correctable through planning before audit or renewal.

The first trap is renewing the legacy entitlement at full volume while the migration is already underway. Estates that have committed to the build of Keycloak migration sometimes renew the legacy Red Hat Single Sign On entitlement at the same volume for another term, on the assumption that the migration will not complete before the renewal. The reshape is to right size the legacy renewal against the planned migration cutover and to negotiate a co term or step down where the seller side concedes the duplicate spend window.

The second trap is double licensing during the migration window because both the legacy product and the build of Keycloak are running. Where the migration runs in parallel for a calendar quarter or longer, both estates run concurrently and the entitlement applies to both. The reshape is to either compress the migration window with a hard cutover date or to negotiate a migration overlap allowance in the next contract; the seller side has occasionally granted a sixty to ninety day overlap window at no incremental cost.2

The third trap is leaving abandoned Red Hat Single Sign On instances live in development or staging environments after the production migration completes. The entitlement applies to any host running the supported binary, not just production hosts. Operators sometimes overlook development environments because the production fleet has migrated. The reshape is to decommission or migrate the non production fleet on the same timeline as production.

The relationship between Red Hat Single Sign On and the Red Hat build of Keycloak shapes every renewal conversation on identity estates. Both products derive from the upstream Keycloak project. The difference sits in the support boundary, the version cadence, and the operating model.

The legacy Red Hat Single Sign On product ran on a JBoss EAP base, used a server side rendered admin console, and tracked the Keycloak upstream conservatively. The build of Keycloak runs on a Quarkus base, ships a Keycloak first admin console and operator, and tracks the upstream more aggressively. The entitlement under the legacy product meters on EAP server cores. The entitlement under the build of Keycloak meters on the Keycloak runtime cores. The numerical count is often similar, but the runtime base and the support contract differ.3

For the sibling reading on the build of Keycloak entitlement, see the build of Keycloak licensing note. For the adjacent middleware that often fronts the identity tier in regulated estates, see the 3scale API management licensing note. For the sibling Runtimes product that the seller side often bundles alongside identity, see the Runtimes bundle economics note.

The renewal posture on a Red Hat Single Sign On estate has three components worth preparing before the seller side prices the next term. The first is the migration readiness assessment, which should resolve whether the estate is migrating to the build of Keycloak in this term, the next term, or staying on the legacy product through end of support. The second is the dual run overlap calculation, which should quantify the duplicate entitlement burden during the migration window and price the concession ask. The third is the version pin, which should document which Red Hat Single Sign On version the estate currently runs and confirm that version is still in supported maintenance.

The seller side at renewal often positions the move to the build of Keycloak as a forced migration with the legacy entitlement scheduled for end of life. The buyer side reading is that the migration is the seller side preference, not a regulatory obligation. The legacy product remains supported through its published lifecycle and the migration timeline is a negotiation lever, not a deadline imposed externally. For the surrounding bridge into security posture on identity heavy estates, see the Red Hat Advanced Cluster Security pricing note.

For estates evaluating Red Hat Single Sign On licensing ahead of a renewal or audit, the engagement is normally a subscription assessment scoped to the identity estate plus a migration readiness review. To begin, see the contact page.

Preparing a response? The practice keeps a one-page Red Hat audit response checklist — what to acknowledge, what to preserve, and what not to volunteer in the first fourteen days after the letter arrives.