Changelog

Keycloak 26.8.0 is validated and available on all Cloud-IAM deployments. SCIM provisioning, client secret rotation with a grace period, and stateless multi-cluster (v2) are now production-ready. OID4VCI, parameterized scopes, token exchange delegation and the Client Admin API v2 arrive as preview features.

Three security fixes change existing behaviour: identity provider mappers no longer grant admin roles unless allowAdminRoleMapping is enabled, bare group names in claims resolve to top-level realm groups only, and disabled clients are dropped from the token audience. Check these before upgrading.

Upgrade from Pilot → Upgrade in the console. No downtime from 26.7.x, 15 to 20 minutes, backup taken automatically. Supported until the end of October 2027.

📖 Read the documentation

Keycloak 26.7.5 is a security and bug-fix release and it is now ready to be used for your Cloud-IAM deployments.

Refer to the Keycloak migration guide for a complete list of changes before upgrading.

📖 Read the documentation

Keycloak 26.7.4 is a security and bug-fix release and it is now ready to be used for your Cloud-IAM deployments.

Refer to the Keycloak migration guide for a complete list of changes before upgrading.

📖 Read the documentation

Your Active Directory groups now appear on your users

The groups an account belongs to in your directory can now be carried into Keycloak, so you no longer have to recreate them by hand and keep them in step.

It is off by default and enabled in your User Federation entry, where you also choose how far it goes. Add memberships only and never remove any. Align Keycloak on your directory, removals included. Or report, which brings the memberships in and merely logs the removals it would make, so you can see the effect on your real data before letting it act. Groups you created yourself in Keycloak are never touched, in any mode, and neither are the memberships you granted in them.

The AD Agent guide walks through the fields to set and the behaviour of each mode.

This comes with a new version of the connector. We update your deployment without interruption of service, and you pull the latest agent image on your side.

A directory outage no longer costs you accounts

A network outage, a restarting agent or a domain controller slow to answer was read as "this user no longer exists", and the Keycloak account was deleted, taking its group memberships, its roles and its attributes with it. Nothing warned you, and an account recreated afterwards came back empty.

A directory that cannot answer is never treated as an absence any more. Removing accounts your directory positively reports as gone has become a setting of its own, which is off unless you turn it on.

The user search shows each account once, and every page

Accounts were listed twice, once as imported in Keycloak and once as returned by your directory. Paging was worse: the second page repeated the first, which put every account beyond it out of reach from the console.

Both are fixed, and searches are now restricted to the population you configured, so computer accounts stop showing up among your users.

Renaming a user in your directory keeps their Keycloak account

An account was recognised by its login name, so a rename created a second, empty account while the original one was discarded with its groups and its roles.

Accounts are now matched on the identifier your directory assigns them for life, so a rename updates the account in place and its history survives.

A silent directory no longer holds your console

An unresponsive directory kept a Keycloak request waiting for 35 seconds, and a large directory was asked to compute results nobody would read.

Searches and logins now have their own ceilings, five and ten seconds by default and both yours to change, and your domain controller is only ever asked for what is needed.

A release being validated no longer reads as blocking

The Extension compatibility table has a fourth status: Validating update…

It covers the gap right after a release is created. Until now, the moment a publisher pushed the missing release, the row still said Update required with a Create release button, so there was nothing left to do and no sign that anything was happening. That row now shows Validating update… instead, names the version the extension is moving to, and drops the button. Hovering the status explains what's running: automated validation, which can take up to 15 minutes.

You don't have to reload to find out how it went. The console keeps watching the release, and the row turns into Update ready by itself once validation passes. The upgrade stays blocked while the release is being validated, and opens up on its own as soon as it succeeds.

The confirmation step says what our validation found

Before, the dialog warned that custom extensions "may not be compatible with the new version" on every deployment carrying one, whatever the state of those extensions. It now reports one verdict for your deployment:

• Every release validated by our pipeline: a confirmation naming the count and the version, for example "All 2 extensions are validated for 26.7.2".
• A release validated by hand rather than by our tests: a warning naming the file, plus one more consent so the risk is explicit.
• No extension of your own installed: nothing about extensions at all.

Every upgrade with extensions also asks you to acknowledge what our validation covers. It's technical, not functional: we check that Keycloak starts with your extension, not that the extension behaves the way your applications expect.

The dialog was tidied up at the same time. Current version, target version with its release notes, schedule, extension verdict and consents are now four clear groups, so the whole decision fits on one screen.

Your LLM agents can now talk directly to your IAM. We're introducing a dedicated MCP (Model Context Protocol) server that you can enable per deployment, giving any connected agent structured access to your Keycloak realm.

Query your IAM from your agent
Once enabled, the MCP server exposes around 20 tools covering your Keycloak deployment: realms, clients, users, roles, and more. Your LLM agent can call these tools directly instead of going through the Admin Console or writing custom API calls.

Getting started
Go to your deployment, then Configuration, then Keycloak MCP. A toggle lets you enable it for that deployment.

Prerequisites

• Premium plan or above
• Keycloak 26.6 or 26.7

This feature is currently in beta. We'd love your feedback as we expand it.

<span style="color: rgb(0, 0, 0);">📖 </span><span style="color: rgb(0, 0, 0);">Read the documentation</span>

Keycloak 26.7.3 is a security and bug-fix release and it is now ready to be used for your Cloud-IAM deployments.

Refer to the Keycloak migration guide for a complete list of changes before upgrading.

📖 Read the documentation

"Try it out" now works in the Developer section

You can test any Cloud-IAM API endpoint straight from the console. The interactive API explorer on the Developer page now sends your console session token with every call, so requests are authenticated automatically.

Before, calls made from the page came back with a 401 unless you fetched a token by hand and pasted it into the Authorize dialog. That step is gone: open an endpoint, hit Try it out, and the call runs as you.

Upgrade endpoint accepts a Keycloak version id

PUT /deployments/{deploymentId}/upgrade now accepts either the version id (26.5-quarkus) or the version display name (Keycloak 26.5) in the version parameter. Both forms are returned by GET /marketplace/organizations/{organizationId}/keycloak-versions, so you can pass whichever one your automation already holds.

If the version can't be resolved, the error now lists every accepted value instead of only echoing what you sent, which makes a failing upgrade script far quicker to fix.

Error responses link to the right documentation page

Every API error carries a documentation link so you can look up what went wrong. Those links pointed to a page that no longer existed and ended on a 404. They now resolve to the deployment lifecycle reference, where the error codes are documented.

Keycloak 26.7.2 is a security and bug-fix release and it is now ready to be used for your Cloud-IAM deployments.

Refer to the Keycloak migration guide for a complete list of changes before upgrading.

📖 Read the documentation

Keycloak 26.7.1 is a security and bug-fix release and it is now ready to be used for your Cloud-IAM deployments.

Refer to the Keycloak migration guide for a complete list of changes before upgrading.

📖 Read the documentation

Custom domains let your users reach Keycloak on your own hostname. Until now every deployment was capped at a single custom domain, with no way to see where you stood against that cap or to lift it short of a manual request. This release changes both.

See your usage at a glance (new) The Custom domains card now shows your usage right in its title, for example Custom domains (1/3): how many domains are configured against how many your deployment allows. The count only includes domains whose certificate is managed by Cloud-IAM.

Higher limits, set per deployment (new) Your custom domain limit is no longer a fixed value shared by everyone on your plan. It's now a per-deployment setting, so it can be raised for one deployment without touching any other. If you need more than your current limit, contact support and we'll raise it for that deployment.

Getting started Open your deployment, then go to Configuration → Custom domains. The card title shows your current usage and limit, and Register adds a new domain. Once you reach your limit, Register is disabled until the limit is raised.

Prerequisites Custom domains require a dedicated deployment on a plan that includes the feature.

📖 Read the documentation

🤖 New: Connect Your AI Assistant to Cloud-IAM with MCP

<span style="color: rgb(0, 0, 0);">Your Keycloak deployments hold a lot of operational context: audit logs, extension status, billing usage, upcoming upgrades. Getting to it usually means switching to the console. With our new MCP server, you can now ask your AI assistant directly.</span>

Talk to Cloud-IAM from your assistant (new) Cloud-IAM exposes its control plane through the Model Context Protocol, so any MCP-aware client (Claude Desktop, Claude Code, Cursor, and others) can list your deployments, inspect audit logs, check installed extensions, or compute a billing synthesis, straight from a conversation.

<span style="color: rgb(0, 0, 0);">Tool calls run with your own identity and permissions, not a shared API key or service account. Every action the assistant takes is logged in the audit trail under your user, the same as if you'd done it from the console.</span>

Nineteen tools, scoped to what you're allowed to see<span style="color: rgb(0, 0, 0);"> Four organization-scoped tools cover deployment listing, members, service accounts, and billing. Fifteen deployment-scoped tools cover things like deployment detail, plan usage, audit logs, extensions, custom domains, Keycloak feature flags, allow lists, themes, exports, backups, maintenance windows, and pending upgrades. The gateway resolves organizations and deployments by name or ID and only ever against resources you're a member of, so there's no way to reach into an organization or deployment you don't belong to. Note that deployment-scoped tools aren't available for freemium deployments; organization-scoped tools stay available to everyone.</span>

Getting started<span style="color: rgb(0, 0, 0);"> An </span>ORG_OWNER<span style="color: rgb(0, 0, 0);"> enables MCP from </span>Settings<span style="color: rgb(0, 0, 0);"> → </span>MCP<span style="color: rgb(0, 0, 0);"> in the console, then copies the connection URL that appears below the switch. In Claude, add it as a custom connector under </span>Settings<span style="color: rgb(0, 0, 0);"> → </span>Connectors<span style="color: rgb(0, 0, 0);"> → </span>Add custom connector<span style="color: rgb(0, 0, 0);">; in Claude Code, run </span>claude mcp add --transport http cloud-iam https://mcp.cloud-iam.com/mcp<span style="color: rgb(0, 0, 0);">. The first tool call opens a browser for you to sign in with your usual Cloud-IAM account and grant consent once. Turning the organization switch off immediately revokes access for everyone.</span>

<span style="color: rgb(0, 0, 0);">📖 </span>Read the documentation

📈 New: Deployment Availability in the Console and API

Your deployment page has always shown an availability badge, but it was an image loaded from our monitoring provider straight into your browser. That made it something to look at rather than something you could use, and it stopped working whenever the provider was blocked or unreachable. Availability now comes from the Cloud-IAM API.

A clear up or down on your deployment (new)

The Availability row on your deployment summary shows the current state of your instance as a status badge: Up when checks are passing, Down when they're failing, and Maintenance during a maintenance period. The same badge appears on each card in your deployments list. Nothing is fetched from an external provider any more, so the indicator no longer depends on ad blockers or on that provider being up.

Availability from the API (new)

You can read the same state programmatically:

GET /deployments/{deploymentId}/monitoring/uptime

The response is a single status field:

{ "status": "UP" }

Possible values are UP, DOWN, MAINTENANCE, PAUSED, PENDING and VALIDATING. Two more cover the cases where we can't report a live check: UNMONITORED when the deployment has no monitor, and UNKNOWN when the monitoring backend is briefly unreachable. Those two are distinct on purpose, so a hiccup in monitoring never reads as a false outage in your own tooling.

Getting started

Open a deployment and look at the Availability row on the summary page. For the API, call the endpoint above with your usual bearer token. The status refreshes about every 30 seconds, so a change of state shows up shortly after it happens.

Prerequisites

• A dedicated deployment. Shared plans have no monitor of their own, so they report UNMONITORED.
• The Owner, Editor or Monitoring role on the organization.

🔧 Fixed: Reading Product Updates in the Console

Thanks for the first feedback on the release notes feature. Three things made updates awkward to read, and they're all fixed.

Long updates now scroll

The notifications panel capped its height but didn't scroll, so anything below the fold was out of reach. The panel scrolls now, and you can read a release note in full without leaving it.

Wide content stays inside the panel

An update containing a code block or a long unbroken token stretched past the panel and got clipped on the right edge. Text now wraps to the panel width, and code blocks scroll in place.

A way back from the public page

The public Product updates page uses a standalone layout with no navigation, so signed-in readers had no way back. There's now a Back to console link at the top of the page.

Where to find it

Open the bell icon in the top bar for the panel, or View all updates for the full history.

Keycloak 26.7 (July 2026) is qualified and ready to deploy. Upgrading from 26.6.x involves no downtime.

Highlights

• SCIM API (preview): automate user provisioning with full CRUD, PATCH, filtering, and pagination.
• Identity Brokering API V2: retrieve tokens from external IdPs after federated login. Supported but disabled by default; V1 is now deprecated.
• Step-up authentication for SAML clients, not just OIDC.
• OAuth 2.0 for MCP: Keycloak can act as an authorization server for MCP clients.

Worth checking before you upgrade: the view-system admin role is removed, the Twitter IdP is deprecated, DPoP no longer works with implicit/hybrid flows, X509 client auth now needs a CA Subject DN, and token introspection now validates the audience claim.

Dedicated plan customers can upgrade on demand or ask support. A cold backup is taken beforehand.

📖 Read the documentation

<span>Even with a highly available setup, planned maintenance and certain internal processes can temporarily affect the running state of your cluster. If you need to know the state of your deployment at all times, you can now query it directly instead of waiting on status pages or support.</span>

<span>Deployment status endpoint (new)</span>

<span>A new API endpoint returns the current status of your deployment:</span>

GET /deployments/{deploymentId}/monitoring/status

<span>Use it to integrate deployment health into your own monitoring stack, trigger alerts on state changes, or verify that a maintenance window has completed.</span>

<span>Getting started</span>

<span>Call the endpoint with your deployment ID. You can explore the request and response format, and try it live, in our Swagger documentation.</span>

<span>Prerequisites</span>

<span>The endpoint is available to users with the Owner, Editor, or Monitoring role.</span>

<span>📖 </span><span style="color: rgb(0, 153, 255);">Check it in Swagger</span>

Even when we work hard to keep your deployment up, downtime can still happen under certain circumstances. Instead of your end users hitting a bare, default error page from the load balancer, Cloud-IAM now lets you customize what they see.

The maintenance page is served to your end users when your Keycloak deployment is temporarily unavailable. It's displayed by the load balancer sitting in front of your deployment, so your users still get a clear response even when no Keycloak server can answer their request. Because it's served by the load balancer and not Keycloak itself, it stays available even when your deployment is fully down.

This covers two situations:

• During maintenances — when your deployment is briefly down while we apply updates, patches, or infrastructure changes.
• During incidents — when no Keycloak server is available to handle incoming requests.

You can now choose between three modes:

• None — the default load balancer response, no custom page.
• Minimal — a clean, whitelabelled Service unavailable page with a retry button and automatic reconnection. No branding. A good default for most deployments.
• Custom — your own fully branded page (logo, colors, links, wording) via a self-contained HTML document.

Configure it in the console under Customisation → Maintenance page (Theme section). Note: saving restarts the deployment's load balancer to apply the change, so plan accordingly.

📖 Read the documentation

Your end users don't just see Keycloak at login. They also receive emails from it, like verification and password reset messages. Now you can make both match your brand, directly from the Cloud-IAM Console, with no code.

Login theming

Our no-code Theme Generator lets you visually customize your Keycloak login pages: accent colors, background color, image or custom CSS for effects like gradients, company logo, favicon, and element shapes. You can preview changes instantly with the WYSIWYG editor, then apply them with a single click. Themes are upgrade-safe, so you design once and Cloud-IAM keeps them compatible with future Keycloak versions. Since Keycloak supports realm-based theming, you can create and manage a distinct branded experience for each realm.

Email templates (new)

You can now apply that same branding to the transactional emails Keycloak sends your users, so the experience stays consistent from the login page to the inbox.

Getting started

Both features live under the Customisation section of the console. For login theming, open the Generator tab, click Create theme, configure it in the visual editor, Save, then Deploy. Changes apply after a 5 to 10 minute rolling upgrade. You then apply the theme per realm from Keycloak's Realm Settings, under Themes.

Prerequisites for login theming: a dedicated Keycloak deployment on a paid plan, the Editor role on your organization, and Keycloak 26.2 or higher.

📖 Read the documentation