Identity systems are excellent at granting access but weak at revoking it, because once an IdP issues a token the session length lives inside each application, beyond central control. Shared Signals and Universal Logout change that, letting one risk decision revoke access across the entire estate in near real time.
In short: Identity has spent thirty years perfecting how to grant access and staying quietly terrible at taking it away. We tried to fix logout before and mostly failed. Now Shared Signals and Universal Logout make revocation fan out across the whole estate in near real time, and AI agents make that shift non-negotiable.
I have a habit in these posts of pointing out that new things aren't new. This one breaks the pattern slightly. The problem is old. The fix, for once, is genuinely new.
For as long as I have been doing this, identity has been obsessed with getting people in. Authenticate, then transition smoothly from service to service without being asked again. That is the promise of single sign-on, and it is a good one. We spent years making the front door harder to beat, and in 'Authentication is a Moment. Risk is a Timeline' I argued the trust decision is strong but happens once, at login, and then the context drifts.
What we never got good at was the opposite motion. Killing access. Turning the flow off, cleanly, everywhere, right now.
Think about what single sign-on actually does. One authentication event, then free movement across a whole estate without further challenge. Now read a breach report and you will find the same pattern, an attacker moving quietly from system to system on credentials that are already trusted. We call that lateral movement, and it is the thing we all say we are terrified of.
So single sign-on is, in a sense, lateral movement we signed off. That is not a criticism, it is the point of it. But it does mean we built a superb, frictionless network for moving around and left the off-ramps half finished.
Here is the uncomfortable bit. Once the IdP issues a token and the application accepts it, the IdP steps back. It is not in the traffic path. Unless the application asks for re-authentication, it has no visibility and no control over what happens next. It is the bouncer who checked your ID at the door and then went back outside, with no idea what you are doing at the bar.
And it is worse than passive, because the application also decides how long the session lives. Session lifetime is set inside each service, app by app, often for reasons that have nothing to do with security.
The CFO does not want to log in to the finance reporting tool every morning? Fine. Someone bumps the session timeout for that service to thirty days and moves on with their day. You can publish all the enterprise standards you like, but the moment an application owner changes that setting, your IdP has no say in it and no sight of it. It cannot see the thirty-day session, shorten it, or end it on demand. The IdP can go whistle.
So the real length of access in your estate is not whatever your policy says. It is whatever the loosest application owner found convenient, and you probably cannot even list them.
This is the objection I expect. The whole industry is marching towards zero standing privilege, and rightly so. No permanent access, just-in-time elevation, continuous evaluation, tightly scoped agents.
But zero standing privilege only addresses one half of the transaction, the grant. It quietly assumes that when the context changes, you can pull that access back.
If you cannot, zero standing privilege is just short-lived standing privilege with better marketing. The privilege is still live, in an application you do not control, for the length of that session. That window, between granted and expired, is a breach vector. And here is the kicker. You do not get to decide how long the window needs to be for it to hurt. The attacker does.
We did. Repeatedly. This is the graveyard of good intentions.
First there was SAML Single Logout. Lovely on paper. Sign out once, propagate the logout to every federated application. In practice it was fragile and non-deterministic, and when it half worked, which was often, you got the worst outcome of all: a logout that looked successful while sessions quietly survived in the background. A false sense of being signed out is more dangerous than no logout at all.
Then came the OIDC logout family, RP-initiated and back-channel. Genuinely better, more predictable, more robust. But it is targeted. Point to point. You can end a session with an application. What you still could not do easily was kill the access, all of it, across the whole estate, from a single decision, the instant risk appeared.
So the standards existed. And mostly, nobody wired them up. Because reasons. Revocation never sold a deal the way a slick sign-in experience did. The off-ramp stayed a rough track while we kept resurfacing the motorway in.
Here is how you can tell something has genuinely shifted. Revocation has started turning up in stock market reports. In April, an equity analyst note tied Okta's valuation to its new AI agent "kill switch", an enterprise control for instant access revocation. Killing sessions, the least glamorous job in identity, is now a line item in how the market prices an identity vendor. When the analysts are talking about the off-switch, you know it has arrived.
Two things have matured from aspirational to usable. The first is Shared Signals, the open standard under the Shared Signals Framework that lets systems exchange risk events in real time without a bespoke integration for every pairing. The second is Universal Logout, which takes a decision made in one place and pushes the resulting action out across the applications that need to hear it.
Put them together and the shape of things inverts. A risk signal arrives, a compromised device, a termination from HR, a stolen-token alert. Your IdP evaluates it against policy, and instead of revoking one session and hoping the rest time out, it acts as a broker and fans the kill out to the whole estate. Okta frames this within its IPSIE work, and Universal Logout is the piece that matters most here.
If 'Authentication is a Moment. Risk is a Timeline' was about identity learning to react, this is the sequel. Identity learning to revoke. Everywhere. At close to the speed the risk appeared.
Because everything is an agent now, and agents have a nasty talent for finding precisely the muscles we never trained.
I have made this point about Non-Human Identities before. They did not invent a new problem, they reintroduced an old one at much higher velocity. Agents are doing the same trick to revocation, walking straight up to the one thing IAM has always been weakest at and leaning on it with their full weight.
Consider the timelines. A human with a session that should have ended is a slow-moving problem. An agent with a live, over-scoped token moving at machine speed is not. It does not get distracted, it does not go to lunch, and it will happily do a week's worth of damage in the ninety seconds between us spotting it and the session finally expiring.
Revocation stops being hygiene. It becomes the whole game.
Shared Signals and Universal Logout are not remote-control protocols. An IdP can make the decision, but the session only actually dies if the downstream application supports Universal Logout or token revocation and acts on it. Follow the documentation and you hit the line that gives the whole game away: configure your application to support Universal Logout.
That is the kicker. This only works if the vendors show up and implement Universal Logout in their products. So do the thing I have been saying in meetings for twenty years. Yes, we can do that. Does your application support it? Make Universal Logout and Shared Signals support a hard line in your selection criteria, and make it awkward for existing vendors if the answer is a shrug.
And do not wait for them before you act. Go to your service and business owners and ask for a simple report: what is the session length configured for each of their applications, right now? Some of the answers will surprise you and a few will alarm you. Then get session length change events flowing into your SOC. When an owner extends a session from eight hours to thirty days, that is a security-relevant event and your analysts should see it, the same way they would see a change to a firewall rule. No SOC, or no way of seeing any of this today? Come and talk to us.
We have spent our whole discipline being generous with access and stingy with revocation. Zero trust asked us to make trust dynamic. Agents are now insisting we make distrust just as dynamic. The tools to kill a session cleanly, everywhere, in real time have arrived. We just need the industry to pick them up.
Identity is entering its own Generation Kill era, and unlike the book and the series, this one is a good news story. After thirty years of being brilliant at yes and hopeless at stop, we are finally learning to kill sessions on purpose.