Most access decisions are made once, at login, and then frozen for the life of the session. The identity provider checks who you are, evaluates policy, issues a token, and steps back. For the next eight hours, or eight days, that token is the truth.
The world does not hold still for eight hours. HR terminates an employee in the system at 9 a.m. A laptop drops off patch compliance in the EDR console at noon. The SIEM correlates a credential-theft pattern at 2 p.m. None of it reaches the session that is still running on a decision made at 8 a.m. The access layer is the last to know, if it finds out at all.
Continuous authorization closes that gap. Instead of deciding once, you keep deciding as the signals change. The idea was never the hard part; the plumbing was. Every tool speaks its own dialect, and wiring each one to every other is an N-by-N mess that nobody finishes.
That is the kind of problem the Shared Signals Framework is designed to address.
The shared language already exists
The Shared Signals Framework, or SSF, is an OpenID standard for one system to tell another that something security-relevant just happened. A transmitter emits a small, signed event, a Security Event Token, and a receiver acts on it.
Two profiles sit on top. The Continuous Access Evaluation Profile, CAEP, carries access-relevant changes: a session revoked, a credential changed, an assurance level dropped, a device fallen out of compliance. RISC covers account takeover and risk-incident sharing.
I contribute to this work in the OpenID Foundation, and the way I frame it is a stack. CAEP gives us continuous access evaluation: the standardized signal layer that says an access-relevant state has changed. Continuous authorization is the layer above it, the decision about what to do when that signal arrives. The signal vocabulary is already standardized. You do not have to invent the events. You have to connect the participants, and you have to own the decision.
The signal fabric: one bus, many participants
Instead of picturing integrations as point-to-point, think of them as a fabric.
Every security tool you own is one of three things on that fabric. A transmitter that emits signals. A receiver that acts on them. Or, most usefully, both. If SSF is the bus, CAEP is the shared vocabulary the passengers speak on it. Once a tool is on the fabric, it does not care how many others are listening. It publishes what it knows, and the fabric carries it.
That single shift, from N-by-N integrations to one shared bus, is what turns continuous authorization from a slide into something you can actually build.
One caveat before the map.
Transmitter and receiver are roles, not features you can assume. A handful of vendors speak SSF natively today, and recent OpenID Foundation interoperability events show that several platforms can operate in both roles while others currently transmit only. The adoption is growing, but production support still varies by vendor, so confirm it for each product rather than assuming it.
The rest of your stack is probably not on that list. Your HR system, your SIEM, your PAM, and most EDR consoles have rich native events and no SSF endpoint. For those, the role is played by a thin adapter you build: a small Java or Python service that conforms to the spec, turns the tool’s native events into signed Security Event Tokens, and on the receive side consumes events and calls the tool’s own API to enforce. The fabric is assembled, not bought, and the adapters are likely to account for much of the implementation work.
With that in mind, here is how the systems most enterprises already run map onto the fabric.
HR and HCM are your source of lifecycle truth: terminations, role changes, leaves of absence, and other changes that should affect access. In the fabric, HR is primarily a transmitter, pushing those changes into the access layer as they happen.
The identity provider is the hub. It transmits session-revoked, credential-change, and assurance-level-change events, and it is also the natural enforcement point, the place where a session actually dies. In my experience, most fabrics are anchored here.
The SIEM correlates signals across systems. It sees patterns no single tool sees and can emit risk-level changes and incident signals for the fabric to act on.
EDR and XDR own endpoint truth. When a device falls out of compliance or shows signs of compromise, that is a device-compliance change the access layer needs immediately, so it can cut access from that one endpoint without disrupting the user everywhere else.
PAM is where the highest-value sessions live. It is both a transmitter, flagging privileged-session anomalies, and a receiver, able to terminate a privileged session the moment risk crosses a line.
The piece that ties them together is a policy decision point. Call it a broker, an authorization service, whatever your architecture names it. It consumes the signals, applies policy, and decides. This is where continuous authorization moves from event sharing to access control.
The reference architecture
Put together, the fabric has four layers.
Sources emit. HR, EDR, SIEM, PAM, and the identity provider itself publish CAEP and RISC events as things happen, natively where the vendor supports SSF and through a thin adapter where it does not.
The fabric carries. An SSF stream, often routed through a central hub that aggregates and distributes, moves signed events from transmitters to receivers.
The decision point evaluates. It fuses the incoming signals with policy, identity context, and risk, then decides whether access should continue, step up, or stop.
Enforcement points act. The identity provider kills the session. PAM drops the privileged connection. A proxy or the application attenuates access. The decision becomes reality in the target system.
The elegance is that no layer needs to know the internals of any other. HR does not know what CrowdStrike is. The proxy does not know how the SIEM scored the risk. They agree on the vocabulary, and the fabric handles the rest.
CAEP notifies. The receiver decides.
One point is easy to miss, and it matters. CAEP events are notifications that a state changed. They are not decisions. There is no step-up event and no deny event. A CAEP message tells you a session was revoked, a device fell out of compliance, an assurance level dropped, or a risk level moved too high, along with the direction of the change and a reason. It does not tell you what to do about it. The specification is explicit that the receiver is the one that attenuates access.
That is not a gap in the standard. It is the design. The standard carries the facts. Your policy makes the call.
So step-up and step-down are decisions you own, expressed as a simple mapping. A risk level that moves to high forces a re-authentication. An assurance level that dropped pulls back sensitive entitlements until it is restored. A device that fell out of compliance loses access to high-value apps, and regains it when it turns compliant again. The same events can drive different outcomes depending on your policy and enforcement model.
This is the whole reason the decision point exists. CAEP delivers the trigger and the context. The decision point turns that into allow, step-up, or stop. For the synchronous, per-request version of the same decision, the emerging OpenID AuthZEN work is the natural complement to CAEP’s event-driven model.
Start with one high-value use case
You don’t need to build the whole fabric on day one; start with one wire and prove the pattern.
HR termination to session revocation is a useful place to begin. When someone is terminated, the event should reach the identity provider quickly enough to end live sessions rather than waiting for the next login or an offline lifecycle process.
From there, add posture by connecting EDR device-compliance signals to conditional access, so a compromised laptop can lose access without a human opening a ticket. Then add risk, allowing the SIEM’s risk signal to force a step-up or a stop. Finally, bring privileged access into the same model so PAM can act on those signals as well. Each use case delivers value on its own and makes the next easier because the signaling pattern is already in place.
Crawl, walk, run. But start with the wire that pays for itself.
The hard parts nobody demos
A vendor demo can make this look effortless, but production is harder, and it is worth being honest about where.
Trust and stream management. A receiver is about to act on a transmitter’s word, so the trust between them has to be real, authenticated, and revocable. Running those streams at scale is its own discipline.
Signal quality. A false positive on the fabric is not a wrong number on a dashboard. It can mean revoked access. One misfiring EDR rule can lock out a whole population. Continuous authorization needs confidence scoring, damping, and a human in the loop for the highest-impact actions, or it becomes an outage in itself.
Interop maturity. The spec is ready, but vendor support is uneven. Some tools transmit but do not receive. Some receive but cannot enforce. The interop profiles are closing that gap, but you will still find edges.
The quieter problem is that many tools can ingest a signal, but far fewer can act on one. That gap between knowing and doing is where continuous authorization actually lives or dies.
What identity leaders should do in the next 12 months
.avif)
- Inventory your signals. List what each tool already knows and already emits. Most teams are surprised how much is sitting there unused.
- Name your decision point. Continuous authorization needs a brain. Decide where policy gets evaluated before you wire anything to anything.
- Build the first wire. HR termination to session revocation. Prove the pattern on the highest-value case before you scale it.
- Put CAEP in procurement. Make transmit-and-receive a requirement in your next identity provider, EDR, and PAM renewals. The market moves when buyers ask.
- Design for bad signals. Decide up front how you damp false positives and where a human confirms before a high-impact action fires.
The access layer should never be the last to know
Continuous authorization is not a product you buy. It is an architecture you assemble from tools you already own, using a vocabulary that is already standardized. SSF is the bus. CAEP is the language. Your HR system, your EDR, your SIEM, and your PAM are already speaking. They are just speaking to themselves.
The work is to put them on the same fabric, give them one place to decide, and let the decision reach the session before the damage does. Access is often decided once today, but it does not have to stay that way.
If the signal-fabric framing is useful, take it into your own architecture reviews and adapt it. Tell me which wire you built first, and tell me where it broke. That is how the pattern gets sharper.
Sahil Mukhija is an identity and access management architect with 19+ years of experience governing enterprise identity at scale, including real-time authorization deployments across more than a million human and non-human identities. He contributes to the OpenID Foundation’s Shared Signals Framework Working Group, works on runtime authorization for AI agents, and is a SailPoint Ambassador and IEEE member.