Closed-Loop Revoke: The Five Steps Nobody Else Completes
TL;DR: Most IGA platforms send a revocation request to the target system and log "revocation requested." They never check whether the access was actually removed. SidantiX runs five steps — Signal, Evaluate, Revoke, Verify, Seal — and produces an ECDSA-signed receipt proving the access is gone. Not "we asked." "It's gone."
The dirty secret of IGA revocation
I spent years building identity governance. I can tell you exactly what happens when most IGA platforms revoke access: they send a SCIM deprovision request, or an API call to the target system, and log the HTTP 200. Done. "Revocation complete."
But was the access actually removed?
Nobody checks.
Here is what really happens when you terminate an employee on a Friday afternoon. Your IGA platform disables their Okta account. The SSO session ends. The audit log says "access revoked." Your compliance team files the ticket as resolved.
Meanwhile:
- Their GitHub personal access token is still valid. They can push to your production repo from their personal laptop.
- Their AWS IAM role still has admin privileges. The role was assigned directly, not through SSO federation.
- Their Salesforce API key still works. Every customer record is still accessible.
- Their service account in your data warehouse still runs nightly ETL jobs under their name.
"Revocation complete" is a lie. It is a partial revocation that your platform reports as total. And every auditor who accepts that log entry is accepting a fiction.
Five steps, one hash chain
This is genuinely hard engineering. Every target system has a different API, different latency, different failure modes. There is a reason nobody else does it — it is expensive to build and painful to maintain. We built it anyway because the alternative is lying to auditors.
Here is how it works. Five steps. Every step produces evidence. The evidence is hash-chained into a tamper-evident pack you can verify offline.
Step 1: Signal
A trigger fires. This can be a leaver event from your HR system, a risk score crossing a threshold, a certification denial from a periodic access review, or someone pulling the enterprise kill switch. The signal is recorded with a timestamp, source system, and correlation ID. This is the "why."
Step 2: Evaluate
The policy engine determines the blast radius. What entitlements does this identity hold, across which systems? What depends on those entitlements — downstream service accounts, delegated permissions, shared credentials? The engine runs a blast-radius preview: here is everything that will be affected, here are the dependencies, here are the risks of partial revocation. This is the "what."
Step 3: Revoke
Fan-out to every connected system. Not just the SSO provider — every system where the identity has standing access. Okta, Entra ID, GitHub, AWS IAM, Salesforce, GCP, database accounts, API keys, personal access tokens, SSH keys. Each target gets a specific revocation action appropriate to the access type: disable the account, delete the PAT, detach the IAM policy, rotate the shared credential. This is the "do."
Step 4: Verify
This is the step nobody else runs.
After revocation, SidantiX polls each target system to confirm the access was actually removed. Not "we sent the request." Not "we got an HTTP 200." The platform makes a verification call: can this identity still authenticate? Can this token still authorize? Can this role still assume? Each verification produces a boolean result with a timestamp and the raw API response from the target system.
If verification fails — the access is still there — the platform retries, escalates, and alerts. It does not close the ticket. It does not log "revocation complete." The revocation stays open until the access is confirmed gone or a human is notified that automated remediation failed.
Step 5: Seal
Once every target system confirms the access is removed, the platform produces an ECDSA-signed receipt. The receipt contains the full chain: the signal that triggered revocation, the policy evaluation, the revocation actions, and the verification results. Each receipt is hash-chained into the identity's evidence pack — the same tamper-evident chain we use for every access decision in the platform.
The evidence pack is stored on your infrastructure. You can verify it offline with standard cryptographic tools. You do not need our platform running to prove what happened.
What the market shows you
SailPoint shows you "decision made." A certification reviewer denied the access. The decision is logged. What happened after the decision? You get a provisioning ticket. Whether the ticket was executed, whether the target system actually removed the access — that is somebody else's problem.
Okta shows you "session expired." The SSO session ended. But SSO is one layer. Every non-federated credential — PATs, API keys, service account passwords, IAM roles attached outside SSO — is untouched.
CyberArk shows you "privileged session terminated." The session is closed. But the standing privilege that allowed the session to be created is still there. Tomorrow, the same credential creates a new session.
Nobody shows you the complete chain: trigger, evaluation, action, verification, sealed proof. I understand why. Building verification logic for each target system is tedious, connector-by-connector work. You need to know the right API call to confirm a PAT is actually deleted, not just that GitHub returned 204. You need retry logic, timeout handling, partial-failure semantics. It is not glamorous engineering. But it is the difference between "we tried" and "it's done."
Why this matters now
Three reasons:
- Non-human identities outnumber humans 45:1 in the average enterprise. Service accounts, API keys, machine credentials, and AI agent identities do not log out when you disable an SSO account. They persist until someone explicitly revokes each one. Open-loop revocation was tolerable when you had 5,000 human users. It is not tolerable when you have 225,000 machine identities.
- Regulators are asking for proof, not logs. SOX auditors, HIPAA reviewers, and EU AI Act assessors are increasingly asking not "did you make the decision?" but "can you prove the decision was executed?" A log entry that says "revocation requested" is not proof. A signed receipt showing the target system confirmed the access is gone — that is proof.
- AI agents make the blast radius unpredictable. An AI agent with a revoked human owner may have delegated sub-agents, cached credentials, or tool authorizations that outlive the parent identity. Closed-loop revoke with blast-radius preview is the only way to know you caught everything in the chain.
What to ask your current vendor
Next time you evaluate an IGA platform — or audit the one you already have — ask these three questions:
- After you send a revocation request, do you verify with the target system that the access was actually removed?
- Can you show me the verification result — not the request log, the confirmation — for a specific revocation?
- Is that confirmation cryptographically signed and independently verifiable?
If the answer to any of these is no, your "revocation complete" is an assumption, not a fact.
We built SidantiX because I got tired of watching the same gap go unaddressed for two decades. Five steps, one hash chain, verifiable proof. Not because it is easy — it is not. Because it is what revocation actually requires.
About the author: SidantiX is founded by an identity governance veteran with over two decades of experience building identity governance and access management platforms at major enterprise software companies. SidantiX is an AI-native IGA platform delivering autonomous governance for humans, non-human identities, and AI agents — with cryptographic proof on every access decision.