Keycloak CAEP & Shared Signals: Continuous Access Evaluation

Last updated: May 2026

Can Keycloak do continuous access evaluation today? Partially, and only at the experimental edge. CAEP, the Continuous Access Evaluation Profile, is part of the OpenID Shared Signals Framework. It lets systems push security event signals, such as a revoked session, so access gets re-evaluated continuously instead of only at login. An official SSF transmitter capability was merged into Keycloak in May 2026 behind an off-by-default experimental flag. Receiver support is still an open, in-triage issue. So Keycloak is not yet a production-ready CAEP implementation, but it is actively moving there, and you can approximate continuous evaluation now with primitives you already have.

The Bottom Line

• Keycloak’s official SSF transmitter was merged on 2026-05-12 (PR #48256), gated behind the experimental Profile.Feature.SSF flag, targeting v26.7.0.
• Receiver support remains an open triage issue (#43614), so Keycloak cannot yet consume signals from other transmitters.
• The OpenID Foundation approved SSF 1.0, CAEP 1.0, and RISC 1.0 as Final Specifications on 2025-09-02 (OpenID Foundation).
• You can approximate continuous evaluation today using short token lifetimes, revocation policies, and the Event Listener SPI.

Why is login-time-only validation a problem?

Most identity systems decide access once, at login, and then trust that decision for the token’s whole lifetime. That model breaks under zero trust, where the assumption is that any session can turn hostile mid-flight. The OpenID Foundation finalized the Shared Signals standards in September 2025 precisely to close this gap (OpenID Foundation, 2025).

Think about the gap a long-lived token creates. A user logs in at 9 a.m., their laptop gets stolen at noon, and IT disables the account at 12:05. If the access token lasts an hour, the thief still has a valid token until roughly 1 p.m. Nothing tells the resource server that the situation changed.

This is the core failure that continuous access evaluation addresses. Access should not be a one-time gate. It should be a running conversation between the identity provider and the things relying on it. When risk changes, devices fall out of compliance, or a session is killed, downstream services need to hear about it fast, not at the next scheduled token refresh.

Zero trust architectures depend on exactly this kind of signal flow. If you are building toward that model, our guide on zero trust authentication with Keycloak covers the broader pattern that CAEP slots into.

What are SSF, CAEP, and RISC?

The Shared Signals Framework (SSF) is the umbrella standard for securely sharing security event signals between cooperating systems. CAEP and RISC are two profiles built on top of it, and the OpenID Foundation approved all three as Final Specifications on 2025-09-02 (OpenID Foundation, 2025). They give the industry a common vocabulary for “something changed, re-check your assumptions.”

Here is what each piece actually means:

• SSF defines the transport: how signals are formatted, signed, and delivered between parties.
• CAEP stands for Continuous Access Evaluation Profile. It defines events about access conditions, like a revoked session or a changed assurance level.
• RISC stands for Risk Information Sharing and Coordination. It focuses on account-level risk events, such as account takeover indicators (OpenID Foundation press release, 2025).

A common mistake is to expand CAEP as “Continuous Authentication and Risk.” It is not. The official name is the Continuous Access Evaluation Profile, and the distinction matters when you read the specs.

What is a Security Event Token?

The unit of currency in all of this is the Security Event Token, or SET, defined in RFC 8417. A SET is a JWT that conveys a statement of fact about an event that already happened (IETF RFC 8417). That is the key conceptual difference from an ID token or access token, which assert something about the present authentication state.

Put simply: an access token says “this user is authenticated right now.” A SET says “this user’s session was revoked at 12:05.” One is a credential. The other is a notification. Continuous access evaluation is the practice of acting on those notifications.

What are transmitters, receivers, and streams?

SSF defines two roles. A transmitter emits signed SETs when events occur. A receiver consumes those SETs and attenuates access accordingly, for example by ending a session or forcing re-authentication. The two connect over a configured stream.

Delivery happens one of two ways. PUSH means the transmitter sends each SET to the receiver’s endpoint as events happen. POLL means the receiver periodically pulls queued SETs from the transmitter. PUSH gives you lower latency; POLL is easier to operate behind firewalls. Both are part of the standard.

What event types does CAEP define?

CAEP 1.0 Final defines eight event types, each describing a specific change in access conditions (OpenID CAEP 1.0 spec, 2025). These are the signals a transmitter can emit and a receiver can act on. They cover the lifecycle of a session and the trust assumptions behind it.

CAEP event type	What it signals
session-revoked	A session was terminated and should no longer be trusted
token-claims-change	One or more claims in an issued token have changed
credential-change	A credential was added, changed, or removed
assurance-level-change	The authentication assurance level moved up or down
device-compliance-change	A device fell into or out of compliance
session-established	A new session was created
session-presented	A session was presented to a relying party
risk-level-change	The assessed risk level for the subject changed

Notice how operational these are. A device-compliance-change event lets an endpoint management tool tell your identity layer that a laptop just failed a posture check, so sessions on that device can be cut. That is the kind of cross-system coordination that login-time checks simply cannot provide.

Where does Keycloak stand on CAEP and SSF?

Keycloak is partway down the road, with one foot in experimental territory. An official SSF Transmitter capability was merged on 2026-05-12 through PR #48256, gated behind the off-by-default Profile.Feature.SSF flag and targeting the 26.7.0 release. Receiver support is still an open issue in triage (#43614), opened 2025-10-20.

To be clear about what this means: Keycloak does not “support CAEP” in any production sense yet. The transmitter code exists but ships disabled behind an experimental feature flag, which means the project reserves the right to change or remove it before stabilization. The receiver side, which would let Keycloak consume signals from other systems, is not yet built at all.

Community demand has been visible since 2022, tracked in discussion #14217. In the meantime a third-party community extension exists, identitytailor/keycloak-ssf-support (Apache-2.0), but its authors describe it explicitly as a proof of concept, not a supported product.

Component	Status	Where	Notes
SSF Transmitter	Merged, experimental	PR #48256	Behind Profile.Feature.SSF, off by default, targets v26.7.0
SSF Receiver	Open, in triage	Issue #43614	Opened 2025-10-20, not yet implemented
Community PoC	Available, unsupported	identitytailor/keycloak-ssf-support	Apache-2.0, explicitly a proof of concept
Community demand	Tracked since 2022	Discussion #14217	Long-running feature request

The honest read for 2026: if you need standards-compliant CAEP in production today, Keycloak alone will not get you there. If you can wait for 26.7.0 and beyond, the transmitter is a real signal that first-party support is on the way. We have not run the experimental flag in any production cluster, and we would not recommend anyone else do so either until it stabilizes.

How can you approximate continuous evaluation in Keycloak today?

You can shrink the trust window meaningfully with primitives Keycloak already ships, though none of these are CAEP compliance. They are approximations that reduce how long a stale decision stays valid and give you a place to push security events. Treat them as a bridge until first-party SSF support matures.

Start with these building blocks:

• Short access-token lifetimes with frequent refresh. A 60-second access token forces re-validation far more often than a 1-hour one. This narrows the revocation window but is not real-time. Our JWT token lifecycle guide walks through the tradeoffs.
• Session and token revocation. Use the Admin API to revoke sessions, and apply not-before (notBefore) policies at the realm or client level to invalidate tokens issued before a cutoff time.
• OIDC backchannel logout. When a session ends at Keycloak, registered clients get a logout token so they can terminate their local sessions, rather than waiting for the next request to fail.
• Event Listener SPI. This is the closest analog to a DIY transmitter. You can emit security events to downstream systems the moment they happen. It is the same mechanism the official SSF transmitter builds on.
• Event streaming and webhooks to a SIEM. Forward events to your monitoring stack so detection logic elsewhere can trigger revocation back in Keycloak.

The Event Listener SPI is the piece worth dwelling on. It is genuinely a transmitter-shaped pattern: an event occurs in Keycloak, and you push a notification to whatever is listening. The difference from CAEP is that you are inventing the payload format and delivery semantics yourself instead of using signed SETs over a standard stream. For a working pattern, see our walkthrough on Keycloak event streaming and webhooks.

Pair these with step-up authentication so that when a downstream signal suggests elevated risk, you can force the user back through a stronger flow rather than simply cutting them off. And keep a clean event trail; our Keycloak auditing and event logging guide covers how to capture the data these patterns depend on.

One caveat from practice: short token lifetimes plus aggressive refresh shift load onto your token endpoint and your database. Size for it before you turn the dials down, or you will trade a security gap for an availability one.

Who is adopting Shared Signals?

Adoption is real but still concentrated among large platform vendors. The OpenID Foundation’s finalization announcement named Apple, IBM, and Okta among the organizations involved in the Shared Signals work (OpenID Foundation, 2025). That signals serious industry intent behind the standard, even if broad implementation is early.

What this tells you about timing matters. When Apple, IBM, and Okta back a finalized identity standard, the ecosystem around it tends to fill in over the following years: libraries, interop testing, and eventually first-party support in tools like Keycloak. The Keycloak transmitter merge in May 2026 fits that trajectory exactly. The standard is settled; the implementations are catching up.

For most teams, the practical move is to design your architecture so that adding a real CAEP receiver later is a swap, not a rebuild. If your services already react to revocation events from a webhook today, pointing them at standard SETs tomorrow is a smaller change.

Frequently asked questions

Does Keycloak support CAEP in production?

Not yet. As of May 2026, an official SSF transmitter was merged behind the experimental, off-by-default Profile.Feature.SSF flag, targeting v26.7.0 (PR #48256). Receiver support is still an open triage issue (#43614). Treat Keycloak’s CAEP capability as experimental, not production-ready.

What is the difference between CAEP and RISC?

Both are profiles of the Shared Signals Framework finalized on 2025-09-02. CAEP, the Continuous Access Evaluation Profile, carries events about access conditions like session revocation and assurance changes. RISC, Risk Information Sharing and Coordination, focuses on account-level risk such as takeover indicators (OpenID Foundation press release, 2025).

What is a Security Event Token?

A Security Event Token, defined in RFC 8417, is a JWT that states a fact about an event that already occurred, such as a revoked session (IETF RFC 8417). It differs from an access or ID token, which asserts present authentication state. SETs are the notifications that drive continuous access evaluation between transmitters and receivers.

Can I get continuous access evaluation in Keycloak right now?

You can approximate it, not implement it to spec. Short access-token lifetimes, Admin API revocation with not-before policies, OIDC backchannel logout, and the Event Listener SPI together shrink the trust window and push events downstream. These are approximations, not CAEP compliance, but they meaningfully reduce how long a stale access decision stays valid.

When will Keycloak fully support Shared Signals?

There is no committed date for full support. The transmitter targets v26.7.0 but remains experimental, and the receiver is unimplemented (Issue #43614). Community demand has been tracked since 2022, so the direction is clear, but plan around experimental status rather than assuming a stable release in any specific version.

Where to go from here

Continuous access evaluation is where identity security is heading, and the standards are now settled. Keycloak is moving toward it deliberately, but in 2026 the right posture is honest: use the experimental transmitter only for evaluation, lean on token lifetimes, revocation policies, and the Event Listener SPI to approximate continuous evaluation in production, and design your services so a real CAEP receiver is a future swap rather than a rewrite.

If you would rather not babysit experimental feature flags, upgrade cycles, and the operational load of short-lived tokens, a managed Keycloak service handles the infrastructure while you focus on policy. See Skycloak pricing or explore our managed Keycloak hosting to get started.