Continuous access evaluation and B2B SaaS. Here's what to build.

Most B2B SaaS apps make exactly one access decision per session: the login. A user authenticates through SSO, gets a token, and from that point forward your app trusts the token until it expires. Whatever happens in the next eight hours (the laptop gets stolen, IT disables the account, a conditional access policy changes) your app has no way of knowing. It finds out at the next login, or it never finds out at all.

That gap is the whole premise behind a standard that's been quietly maturing over the last year: the Continuous Access Evaluation Protocol, or CAEP, part of the OpenID Foundation's Shared Signals Framework. The pitch is simple. Instead of asking the identity provider "is this still valid?" on a timer, the identity provider tells you the moment something changes. Session revoked. Device out of compliance. Credentials compromised. Your app reacts in seconds instead of waiting for the next token refresh.

This has shown up in the trade press recently as "continuous identity," usually illustrated with some version of the same analogy: you let a repairman into your house once to fix the fridge, and that doesn't mean he gets to walk back in tomorrow uninvited. It's a fine way to explain the concept to a security team. It's less useful if you're the one who has to build the receiving end of this. So here's the practical version.

What actually changed

CAEP isn't new as an idea. Google proposed an early version of it years ago, and identity vendors have been talking about "continuous access evaluation" in the abstract for a while. What changed is that the OpenID Foundation finalized SSF, CAEP, and the related RISC (Risk Incident Sharing and Coordination) profile as 1.0 specifications in September 2025. That matters because finalized specs are what get vendors to actually ship, rather than experiment.

And they have. Microsoft has had a version of this in Entra ID for a while under the name Continuous Access Evaluation. Okta ships a CAEP transmitter for Identity Engine tenants. Google Workspace is running an SSF receiver in closed beta. Apple, IBM, SailPoint, and Jamf are all named participants in the working group, and Jamf already ships CAEP-based device posture signals to third parties. Keycloak merged transmitter support in May 2026, though it's still behind an experimental flag with receiver support unfinished. None of this is universal yet, but it's a real trend with real vendor weight behind it, not a conference buzzword.

The vocabulary

A transmitter is whoever generates the signal, usually the identity provider.

A receiver is whoever consumes it and acts, usually your application or an API gateway in front of it. T

he message itself is a Security Event Token, a signed JWT with a defined shape: who the event is about, what happened, and when.

CAEP defines a handful of event types worth knowing: session revoked, credential changed, device compliance changed, and assurance level changed (the user's authentication strength dropped, so re-authenticate before allowing a sensitive action). RISC covers account-level risk, most notably account disabled and credential compromised. In practice, those two RISC events are the highest-value, lowest-complexity place to start: both of them mean the same thing operationally, which is "kill everything, now."

What this actually looks like for your app

Say one of your enterprise customers fires an employee. Their IT admin deactivates the account in Okta. Today, if your app only checks identity at login, that employee's session in your product keeps working until the token expires, which could be hours. With a CAEP receiver in place, Okta pushes a session-revoked event to your app within seconds of the deactivation. Your receiver validates the signature against the transmitter's published keys, matches the subject identifier to an active session in your system, and kills it.

Building that receiver means a few concrete things: a publicly reachable endpoint (or a polling fallback) that can accept signed event streams, JWT validation against the transmitter's JWKS, a way to map the subject identifier in the event back to your own session or user record, and a session store that can actually be invalidated on demand rather than just left to expire. None of this is exotic. It's the same shape as any webhook consumer, with the added step of verifying you're hearing from a trusted transmitter and knowing what to do once you have.

Where this fits next to what you already have

SSO answers "who is this and are they allowed in." Audit logs answer "what did this user do, after the fact." Neither one answers "is this session still supposed to be valid, right now." That's the layer CAEP fills, and it's a layer most B2B SaaS products don't have today, largely because there hasn't been a standard way to build it. If you've ever had an enterprise security review ask how quickly access is revoked after an employee is terminated, and the honest answer was "whenever the token expires," this is the gap they were pointing at.

A practical way to start

You don't need full CAEP compliance to meaningfully close this gap, and given how early some of the receiver-side tooling still is, you probably shouldn't wait for it. A few things work today, independent of any specific standard:

Shorter access token lifetimes with real refresh checks reduce the exposure window even without any events at all. OIDC backchannel logout, which is older and more broadly supported than CAEP, already lets an identity provider tell your app when a session ends. If you do want to build toward CAEP specifically, start with the RISC events (account disabled, credential compromised) rather than the full CAEP event catalog. They're the simplest to handle, because the correct response to both is the same: revoke everything and stop asking questions.

The honest state of things

This is early. The specs are finalized, but implementations are uneven: some vendors have production support, some have it in beta, and some open source options have it gated behind experimental flags with half the pieces still missing. If you build a receiver today, expect to be one of the first in your category to have one, not one of the last. That's the point at which it's worth paying attention, not necessarily the point at which it needs to ship this quarter.

What's not early is the underlying problem. Session hijacking, delayed offboarding, and stolen device access all exploit the same gap: an app that only checks identity once and trusts it indefinitely. Whether the eventual standard is CAEP exactly or something that supersedes it, the direction is clear. Access decisions are moving from a single checkpoint at login to something closer to a running conversation between the identity provider and everything that relies on it. Worth understanding the shape of that now, even if the plumbing is still being built.