No team claims a key in your manager and the register has no owner for it - how do you decide it is dead?

## Why nobody claiming it proves nothing An unclaimed key means one of several things, and they need different endings: the owning team was renamed and did not recognise the key's name; the owner left and nobody inherited the duty; the key was minted for a migration that finished; or it is genuinely load-bearing for a system whose current staff have never looked inside the manager. Absence of a claim distinguishes none of those. It is a prompt to investigate, never a verdict. ## The evidence you actually have - **Recorded use.** Most managers can say something about whether a key was used and when it last was, but designs differ in what they keep: some hold a last-used timestamp, some a counter, some only emit events that you must already have been collecting. If nothing was being collected, your observation window starts the day you turn collection on - not the day the key was created. - **The register's caller field**, where somebody ever filled it in, names the systems believed to call the key. Confirm it against those systems rather than trusting it. - **The systems themselves.** A configuration that still references the key is stronger evidence of life than silence is of death, even if no call has been seen. Note what none of this is: the record of *who* read a value is a different artefact with a different purpose, and enumerating which consumers still hold a credential before replacing it is a different job again. Here you only need the binary - is anything still calling this key. ## Choosing the observation window The window has to be longer than the slowest thing that could legitimately call the key. In most estates that means: 1. the monthly close or billing run; 2. a quarterly report or reconciliation; 3. an annual archive restore, or a restore from long-retention backups; 4. the recovery rehearsal that only runs once a year - and which is exactly the moment an unreadable archive is discovered. A year plus a margin is the honest floor when archives are in scope, and a month is only defensible for a key you can prove serves a live request path and nothing else. State the assumption out loud: "we watched for fourteen months, covering two annual restores." ## Deny, then destroy - the order is not reversible | action | reversible | what it achieves | cost if you were wrong | |---|---|---|---| | deny use of the key | yes | any remaining caller fails loudly and identifies itself | an outage you can undo in minutes | | destroy the key material | no | the key can never be used or recovered | ciphertext under it is unreadable forever, including in backups | Denial is the instrument that converts silence into information: the caller you could not find announces itself. Destruction converts a question into a permanent loss, so it belongs at the end of a staged retirement - announce, deny, wait a full cycle, then destroy - and only when nothing that must remain readable depends on it. Managers differ here too: some offer only enable and disable, some schedule destruction after a mandatory waiting period, some let you destroy immediately. Where a waiting period exists, use it; where it does not, impose one yourself. ## Encryption keys and signing keys do not retire alike Destroying an **encryption key** destroys access to the data it protected - that is the whole point, and it is also the whole risk, because the data may sit in an archive nobody thought about. Destroying a **signing key** ends the ability to produce anything new that verifies under it; whatever was already signed continues to verify against the verification material, which is usually held elsewhere and is not what you destroyed. So the question "what do we lose?" has a different answer for each, and a retirement plan that treats them the same will either lose data or claim a safety it did not buy. ## When a key may never be destroyed If long-retention backups or archives were written under the key, its earliest possible destruction date is bounded by that retention, not by anyone's tidiness. The register row is what tells you this, which is one more argument for recording what a key protected before you needed to know. Finally, this is the routine case - a key nobody claims, on a calm afternoon. A key believed to be exposed inverts the defaults: there, stopping use quickly outranks avoiding an outage, and the ordering of that work is a separate subject.