The window between credential compromise and detection. Every action in that window is legitimate.
Most defensive thinking is about the moment of compromise. Keep them out. Watch the front door. Make the walls higher.
By the time you are looking at a real incident, the compromise already happened. The question is not whether they are inside. The question is how long their key stayed valid after the moment they got it, and what they did with the window.
Every credential has two clocks. The first clock is compromise: when the attacker gets the key. The second clock is revocation: when the key stops working. The gap between them is the revocation gap.
Inside the gap, the attacker is indistinguishable from the legitimate user. Their actions pass every auth check, because they have the key that auth is supposed to check. Their actions show up in the logs with the rightful name attached, because logs record who presented the credential, not whether the credential-holder was the person. Detection systems tuned to look for intrusions see nothing, because there is no intrusion to see. The authenticated session IS the attack.
This is why defensive spend concentrated on the front door often produces diminishing returns. Stronger locks on the door, while the attacker walks in wearing the maintenance uniform. The locks worked. The revocation gap is not a bypass. It is the legitimate product of a correctly functioning system.
The pattern is not a theoretical concern. Every organization running long-lived credentials is running on the bet that the gap will be short enough that no attacker uses it for anything meaningful. The bet usually holds. Occasionally it does not, and the failure is invisible until much later, when someone audits the authentication logs and realizes that a window of perfect stolen-credential access was open for weeks. The length of the window is a property the defender can measure. Most organizations have never measured it.
Oracle Cloud: The Breach They Technically Didn't Deny. A researcher found Oracle Cloud keys and credentials in an exposed store. Oracle's response was that nothing had been breached by their definition, because no Oracle-owned system had been compromised. The issue was with a legacy product, or a customer, or a labeling convention, depending on which statement you read. What the response did not address is the revocation gap. Every hour those keys sat valid was an hour of standing access for anyone who had them. The dispute about whose breach it was did not change the math of the window.
xrpl.js: The Official Package Was the Threat. The xrpl.js maintainer account was compromised. An attacker shipped a package version that harvested wallet credentials on install. The package was live for hours before takedown. The revocation gap was the hours between publish and detection, and every install during that window was a fresh victim. The harvested credentials then had their own revocation gaps, nested inside the first one, one per downstream user.
Not every slow detection is a revocation gap. Revocation gap is specifically about the authorization window. A worm replicating across machines with no credential involved is propagation, not revocation-gap. Revocation gap requires that credentials are doing the work.
Not every post-compromise dwell time is a revocation gap. Dwell time measures how long an attacker stays inside a system. Revocation gap measures how long their credentials remain valid. An attacker with long dwell and no valid credentials is noise on a quiet network; they are in a different threat model.
Not every patch window. Patch windows are about unpatched code, which is a vulnerability. Revocation gap assumes the bad thing already happened and the credential is live. These are different clocks and different playbooks. Conflating them is how oncall teams end up fighting the wrong fire.
Measure your revocation gap directly. For each credential type you issue, what is the latency from "we have evidence this is compromised" to "this credential cannot perform any action"? That number is your actual exposure window, and most teams have never produced it.
Tie revocation to threat signal, not to time. A quarterly rotation schedule is a revocation gap at the quarter granularity. Tokens should rotate when a signal says they should, not when the calendar says they should.
Log at token granularity, not user granularity. If your audit trail says "user X did Y" but cannot distinguish which of user X's keys authorized Y, you cannot close the gap selectively. You have to revoke everything for user X and hope the business tolerates the blast radius.
Treat long-lived credentials as already compromised and model exposure accordingly. Then shorten them. An access token with a 90 day TTL is a bet that nothing bad happens for 90 days. The house usually wins that bet. Until it does not.
Maintain a revocation playbook that does not require a postmortem. The instinct to investigate before revoking preserves the gap. First you close the window. Then you figure out who to tell.
Trust Inversion. Revocation gap is the temporal complement of trust inversion. Trust inversion captures the moment the attacker gets the authorizer. Revocation gap measures the damage they do while it stays valid. Almost every trust-inversion incident has a revocation-gap component.
Disclosure After Exploitation. The vendor-side analog. Vendors have their own revocation gap: the window between first evidence of in-wild exploitation and public CVE. During that window the vulnerability is live, and the only parties who know are the attackers using it.
Persistent Blindspot. Sometimes the revocation gap is not closable because the actions inside it were never logged in a way that distinguishes them from legitimate behavior. When the audit trail itself is blind, the gap lasts forever in the worst sense: you never knew it opened.
Your logs will say the attacker was authorized. Your logs will be correct.