The future of Keycloak: the experimental and preview features that show where the project is heading
· IAM · IDPTrust
When people talk about Keycloak, they almost always talk about what it already does: single sign-on, federation with Active Directory, multi-factor authentication. But there's a more interesting conversation for anyone planning over the medium term: where is the project heading?
That answer lives in the features Keycloak is building in preview and experimental stages — early versions, not yet recommended for production, but that anticipate what will become standard within a year or two.
This article goes through them one by one: what they are and why they matter. (As of this article, the latest stable version is 26.6; some of these features arrive in 26.7, which is not yet released.)
A note first: what does "experimental" mean?
Keycloak classifies its features into three levels:
- Supported: production-ready, with stability and support guarantees.
- Preview: it works, but it may change before the final version. Not recommended for production.
- Experimental: under active development, may change radically or even disappear.
Experimental and preview features are disabled by default. You have to enable them explicitly, and doing so in a production environment without understanding the implications is a mistake. But knowing about them is exactly what lets you design an identity architecture that won't become obsolete too soon.
For the contrast, we recently covered the five features that 26.6 promoted from preview to fully supported: together they show the full path, from experimental to solid.
Let's look at the most relevant ones right now.
1. SCIM Realm API — automated user management through a standard
(Experimental · available since version 26.6)
What it is: SCIM is a standard for automatically creating, updating, and deleting users and groups across platforms. With this feature, Keycloak can act as a SCIM server: it exposes its user and group management through the SCIM protocol, so an external system can keep them in sync without manual intervention. In practice it's "Keycloak's Admin API, but speaking SCIM".
Why it matters: in many companies the source of truth for "who's who" isn't Keycloak but the corporate directory or HR system (for example Microsoft Entra ID). When someone joins the company, that system should be able to provision them into Keycloak automatically; when someone leaves, deprovision them immediately — which is where security risks pile up the most. The SCIM Realm API enables exactly that: it lets that upstream system provision users into Keycloak through a standard, instead of creating them by hand realm by realm.
The Keycloak team prioritized compatibility with Microsoft Entra ID, which is the most requested integration — in that scenario, Entra ID is the one provisioning and Keycloak the one receiving.
Don't confuse this with the reverse case: Keycloak provisioning users out to other applications (email, VPN, ticketing tools) acting as a SCIM client. That's a different use case and is not what this feature delivers today.
Available as experimental since version 26.6. Official announcement · Tracking issue on GitHub (#46227).
2. AuthZEN — a common language for authorization decisions
(Experimental · arrives with 26.7, not yet released; available today only in nightly builds)
What it is: AuthZEN is a new standard from the OpenID Foundation that defines a single way to ask "can this person perform this action on this resource?". From version 26.7, Keycloak will be able to act as the component that answers that question (technically called a Policy Decision Point).
Why it matters: today, when a company picks a system to manage permissions, its application code becomes tied to that specific system. Switching providers means rewriting code. AuthZEN breaks that dependency: it defines a common language, so any application can ask any compatible authorization engine without changing anything. It's the end of vendor lock-in in authorization.
Arrives as experimental with version 26.7 (not yet released). You can try it today with Keycloak's nightly builds. Official announcement · Technical discussion on GitHub (#45288).
3. OID4VCI — decentralized identity and digital wallets
(Experimental · under active development)
What it is: OID4VCI (OpenID for Verifiable Credential Issuance) lets Keycloak issue verifiable credentials — the digital equivalent of an ID card or a diploma that the user keeps in their own wallet and can present without depending on whoever issued it.
Why it matters: it's the foundation of decentralized identity, the model that initiatives like the European digital identity wallet (EUDI Wallet) are aiming for. In fact, the European Commission requires every member state to offer that wallet to its citizens by the end of 2026, and OID4VCI is the technical standard chosen to deliver it. Instead of every service storing your data, you carry your credentials with you and decide when and to whom you show them. Keycloak positioning itself here signals that the project takes this future seriously.
It remains experimental and under active development within Keycloak's OAuth SIG working group.
Tracking issue on GitHub (#42889) · Implementation discussion (#45743) · Guide: issuing credentials with OID4VCI.
4. Client authentication with OAuth SPIFFE — identity for machines
(Preview · the specification is still in draft)
What it is: SPIFFE is a standard for giving identity to workloads — that is, to services and machines themselves, not to people. It lets a service prove who it is without using passwords or stored secrets.
Why it matters: in modern architectures (microservices, containers, zero-trust), it's not only people who need to authenticate: the system's own components talk to each other constantly and must verify each other's identity. SPIFFE solves this without secrets to manage and rotate, which are a common source of security breaches.
It remains in preview because the specification is still in draft status.
Client authentication with SPIFFE/SPIRE issue (#41907) · Experimental SPIFFE identity provider (#42313).
5. CIMD for MCP — Keycloak in the age of AI agents
(Experimental · available since version 26.6)
What it is: the Model Context Protocol (MCP) is the emerging standard that lets AI agents connect to external tools and data. Since late 2025, MCP requires the authorization server to comply with a format called CIMD (OAuth Client ID Metadata Document). Keycloak already includes experimental support for it.
Why it matters: AI agents acting on behalf of a user need permissions: what they can access, what they can do, and on whose behalf. That's an identity and authorization problem — exactly Keycloak's territory. The project preparing for this means Keycloak wants to be the identity layer for AI applications too, not just traditional ones.
Experimental support (--features=cimd) for MCP version 2025-11-25 or later.
Guide: Keycloak as an authorization server for MCP · CIMD support issue (#45106).
6. Metrics export with OpenTelemetry — unified observability
(Experimental · available since version 26.5)
What it is: OpenTelemetry is the standard for collecting a system's metrics, logs, and traces. Keycloak already lets you export logs and, experimentally, metrics too, to any compatible backend.
Why it matters: when something goes wrong in production —slowness, intermittent errors, load spikes— you need data to find the cause. Keycloak speaking the same observability language as the rest of your infrastructure means you can see everything in a single dashboard, instead of having Keycloak as a separate black box.
Introduced in version 26.5. 26.5 release announcement.
What to do with this information
This isn't about turning these features on tomorrow. Most aren't production-ready and some will change before they stabilize.
The value is elsewhere: knowing what's coming lets you make better decisions today. If you're designing your identity architecture, knowing that SCIM, AuthZEN, or decentralized identity are on the way helps you avoid building something you'll have to rebuild in two years.
And if one of these features solves a concrete problem you have right now, it may be worth exploring in a test environment — with judgment and an understanding of its limits.
Are you weighing how one of these features will fit into your identity architecture? We can help you separate what's already solid from what's better to wait on. Tell us about your case.
At IDPTrust we specialize exclusively in Keycloak: deployment, migrations, and production operation. We work remotely with teams across Europe, the US, and Latin America that need a reliable identity system under their own control.