Rotating Credentials Is Not Revoking Them. The Revocation Unit Decides Whether You Can.

The revocation unit decides whether credential rotation can ever be atomic. It is the scope one revoke action removes: a token, an identity, or a trust root. Most teams treat rotation and revocation as one operation. They aren’t. Rotation issues new secrets. Revocation removes the authority of everything that could have used the old ones, and it works only if the architecture can name that set and remove it in a single step.

The Server Was Fixed. Persistent Access Wasn’t. covered what survives when remediation never reaches the layer where persistence lives. This post covers a layer remediation did reach: the credential layer itself, where a rotation can complete on schedule and still leave a surviving credential able to read whatever replaced the old one. The decision question is different. It is not which layers recovery has to validate, but what unit revocation acts on.

The Revocation Unit Is an Architecture Decision

Before any incident, the architecture has already answered a question, usually by default: when you revoke, what exactly are you revoking?

Revocation unit	One revoke action removes	What may remain outside the unit
Token	A single bearer credential	Other tokens the same identity can mint, and any secret that token could read
Identity	Every credential issued to one principal	Static secrets that principal already read and copied elsewhere
Trust root	Everything that chains to one issuer or signing key	Any credential that was never issued through that root

That answer belongs in data protection architecture, not in the incident runbook. A runbook can only sequence actions the architecture permits, and the revocation unit fixes what any single action is capable of removing before anyone is in the room.

A token-level unit is precise and narrow. An identity-level unit is wider but stops at the principal’s boundary. A trust-root unit can be the broadest, if the affected authority chains through that root, and it only reaches what was issued through it. None of the three is wrong. The decision is whether the unit you chose can enclose the set you will need to remove.

Reachability: What the Revocation Unit Has to Enclose

That set is the reachability graph: every credential that can read, write, or mint any secret in the affected set, followed transitively. A token that can read a vault path holding a signing key that can mint further tokens is in the graph, and so is everything those tokens can reach in turn.

Revocation is complete only if the unit encloses the full closure of that graph. Anything left outside is a survivor, and a survivor with read access to the store holding the replacement secrets can simply collect them.

Reachability is a graph property, not a list. It grows with every integration, every shared service account, every pipeline granted a convenient scope, and it is recorded nowhere unless the architecture is built to record it.

The usual response is to rotate everything. That does not escape the problem, it relocates it. The mechanism doing the rotating holds credentials of its own, and those are in the graph too. A rotation job that can write to every store can also be read through, impersonated, or replayed, so the revocation unit has to enclose the rotator as well as the secrets it rotates.

Atomicity: Why Rotation Opens a Window

Atomic revocation means that at one instant, no credential in the closure remains valid except those deliberately reissued. If the revocation unit is smaller than the closure, revocation stops being an operation and becomes a sequence: kill this token, rotate that secret, then the next. A sequence has a window.

A generic sequence shows the shape. A pipeline token can read a shared store. Responders revoke that token, then rotate the database password, then the signing key. Another token issued to the same service account was never in the revocation unit, so it is still valid. It reads the new database password the moment it is written, and the signing key after it. Every step in the sequence succeeded, and the closure still leaked.

Inside that window, the failure mode is replacement-secret exposure. Rotation writes fresh, valid, high-value material into a store that surviving credentials can still read. The rotation does not just fail to lock the attacker out. It hands them the new keys. The defenders see a completed rotation and a dead old secret, while the party holding a surviving credential holds a valid replacement.

Atomic at the unit is not instantaneous at every verifier. Cached validations, token lifetimes and propagation delay leave a residual window even under a trust-root revocation. The design property is not zero. It is a window that is bounded and known in advance, rather than one discovered afterward from logs.

Verification: You Can Only Prove Closure Over a Set You Can Name

Revocation is usually treated as an action: run it, confirm it ran. The stronger claim is about proof. If you cannot enumerate the affected authority set, you cannot prove that revocation closed it. You can show that the revocation action executed. You cannot show that no reachable authority survived.

Enumerability is a prerequisite for proving closure, not for every revocation. A trust-root revocation can invalidate an entire authority domain without listing each credential inside it. But the proof then moves up a level: you have to establish that everything with reach to the replacement secrets chains through that root. That is still a claim about a set, and it has to be checkable.

A closure test has three parts. Establish the set of principals that could read, write or mint any secret in scope, either by listing them or by showing they all chain through one revoked root. For each, show it is invalid or unreachable after the replacement was written. Keep that evidence somewhere the rotated system cannot rewrite. The question of who has standing to confirm that evidence is the governance problem Your Recovery Program Has a Recovery Evidence Boundary addresses. Here the problem is mechanical: whether the set can be established at all.

Restore Testing Is Becoming An Adversarial Discipline already assumes the recovery team’s own credentials can end up in the attacker’s hands. Closure verification extends that posture to replacement secrets: assume a survivor exists, and go and find it. Architectures built to survive adversarial compromise need credential closure as an explicit completion criterion rather than an assumption.

What the Trivy Incident Documents

Aqua Security’s advisory for the Trivy supply chain compromise records that after the March 1 initial disclosure, credential rotation was performed without being atomic: not every credential was revoked at the same moment. It adds that an attacker could have used a still-valid token to exfiltrate newly rotated secrets during a rotation window that lasted a few days. The wording is conditional, and this post keeps it conditional.

That makes it a documented demonstration of the mechanism, not a reconstruction of the attack. The advisory does not establish how many credentials survived or what was taken, and this post does not claim to.

One more detail from the same advisory is worth keeping. Exposure is scoped per component and per consumption path. Whether a workflow was affected depended on which component it pulled, how it pinned it, and when it ran, and a workflow that pinned one action safely could still pull a compromised one through it. That is reachability appearing in a dependency graph rather than as one clean window.

Design Properties That Decide Atomicity

Four properties, all fixed at design time, determine whether an architecture can revoke atomically. None depends on any particular incident.

Secret-store topology

Where replacement secrets are written, and who can read that location at write time. One shared store readable by an entire pipeline means one surviving credential reads every replacement. Scoped paths per consumer shrink the closure.

Issuer design and credential lifetime

Static, long-lived credentials have no built-in expiry, so they are revoked or they persist. Short-lived credentials issued from a central root let trust-root revocation collapse the unit onto the issuer: stop issuing and the survivors age out within a lifetime you chose in advance. That is the bounded window described above. For the case where authority keeps working after the trust behind it has failed, see also Your Cloud Isn’t Compromised. Your Vendor Is. Now What?. The question here is narrower: whether the unit can reach that authority at all.

Cross-secret reachability

Some secrets mint others: publishing credentials, signing keys, role-assumption paths. Rotating a leaf secret without the secret that can mint it leaves a way to recreate what you just removed. The closure has to include the minters.

Verification requirements

The architecture has to make the affected set answerable on demand: a record of which principals can reach which secrets, issuance records, and a way to query validity. If the answer has to be reconstructed from logs after the fact, the architecture cannot prove closure. It can only show that rotation executed.

Additional Resources