Zombie keys: flagging unused credentials safely

Two different problems wearing the same word

“Stale” and “unused” get used interchangeably in most credential-hygiene advice, but they’re different failure modes — and conflating them is how you end up with a policy that either nags constantly or catches nothing.

Unused means nobody is calling the vendor’s API with this key. It might be perfectly scoped and owned; it’s just dead weight. The risk isn’t misconfiguration, it’s that nobody would notice if it leaked, because nobody’s watching it.

Stale means the key hasn’t been rotated in a while. It might be getting called every second. The risk isn’t neglect — it’s that a credential alive and copyable for months has had months of chances to end up somewhere it shouldn’t.

SubScope tracks both, as three separate rules, because “you should look at this” means something different depending on which one fired.

The three rules

Zombie key (30 days). Fires when a credential hasn’t been updated and has no recent usage signal. This is the “nobody’s using this” flag, and the recommendation is blunt: delete it. An unused key isn’t a rotation candidate, it’s a cleanup candidate.

Stale key (90 days). Fires purely on age since the credential was last updated — regardless of whether it’s actively in use. A key called a million times today still trips this rule if it hasn’t been rotated in 90 days. The recommendation is rotate, not delete, because deleting a credential something still depends on breaks that something.

Stale key (180 days). Same check, longer window, higher severity. By six months without rotation, “eventually” has become “overdue.”

The zombie rule and the two staleness rules can look at the same key and reach different conclusions, because they’re not measuring the same thing — one measures silence, the other measures age.

Why we flag instead of revoke

The honest answer: because SubScope doesn’t have the authority to revoke a credential at the vendor. Nothing does, unless it was built with that vendor’s cooperation specifically for that purpose — the one exception on our side is OpenAI, where a public leak triggers an automatic revoke via webhook. That’s a leak response, not a staleness response.

Even where the plumbing exists, auto-deleting on a 30-day usage gap is how you find out — via a page from whoever’s on call — that “unused” was doing more than the metrics showed. A batch job that runs monthly. A failover path that only fires during an actual incident. A partner integration with bursty usage. Automating the delete turns a Tuesday-morning review into a Friday-night incident.

So the flag sits in your register with an age, a reason, and a recommendation — and the fix happens at the vendor’s own console, by a person, on purpose. SubScope’s job stops at “you should look at this.”

What this looks like in practice

shodan_recon_11bd
  last update: 93 days ago
  fetch activity: none in the last 30 days
  → ZOMBIE_KEY_30D: flagged, recommend delete

openai_prod_key_7f3a
  last update: 34 days ago
  fetch activity: 1,400 calls in the last 24 hours
  → no rule fires: active use exempts the zombie check,
    and 34 days is under the 90-day staleness threshold

The takeaway

1. Unused and stale are different risks. One means nobody would notice a leak. The other means a credential has had a long time to end up somewhere it shouldn’t. Delete the first, rotate the second.
2. Automation should stop at the flag. SubScope has exactly one real automated revoke — OpenAI, leak-triggered. Everywhere else, the fix happens at the vendor, by a human.
3. The recommendation matters more than the threshold. 30/90/180 are reasonable cutoffs, not magic numbers. What actually helps is that every flag comes with a specific next action, not just a red badge.