Where do your keys actually live?

Policy describes intent, custody describes exposure

A key management policy is easy to review and tells you little. It says keys are generated in approved modules, stored securely, rotated on a defined schedule and destroyed when no longer required. Almost every organisation has one, and almost every organisation has keys that do not match it.

The useful review does not read the policy. It picks a specific key—the one that signs your firmware, the one that wraps customer data, the one your payment processor validates—and asks where it is. Not where it is supposed to be: where it is, including every copy.

The answers are consistently more interesting than the policy. A key generated in a hardware module three years ago, with an export taken during a migration that is still in an operations share. A signing key that lives in a pipeline secret because that was faster than integrating the module. A key-encryption key whose plaintext backup is in a password manager entry shared with a team that has since reorganised.

None of these are policy failures in the sense of someone deciding to do the wrong thing. They are the accumulated residue of operational necessity, and they are invisible to any review that works top-down.

Trace one key end to end

Pick a key and answer eight questions in order. The value is in doing it concretely, with names of systems, rather than in the abstract.

1. Generation. What produced it, using what randomness source, and was it generated inside the module that holds it or imported?
2. Storage. Where does the authoritative copy live, and is it exportable?
3. Protection. What protects it at rest—another key, a hardware boundary, an access policy—and what protects that?
4. Use. Which components can invoke an operation with it, authenticated how, and is each use recorded?
5. Copies. Every other place the key material exists: backups, escrow, a disaster-recovery region, a developer’s machine during an incident, a vendor’s system.
6. Lifetime. When did it come into use, when should it stop, and what is the defined cryptoperiod?
7. Rotation. What is the procedure, has it been executed, and what depends on the old key remaining available?
8. Destruction. What happens to it at end of life, including every copy from question five.

NIST SP 800-57 formalises this as key states and transitions, and the framework is worth reading for the vocabulary. The practical value comes from the exercise, because questions five and eight almost always produce a surprise.

The copies nobody recorded

Question five is the one that changes conclusions. The recurring sources of unrecorded key material are predictable enough to check directly:

Each of these is a legitimate operational need that created a copy. The problem is not the copy; it is that the copy is protected by a different, usually weaker, mechanism than the one the architecture describes, and that nobody owns it.

The break-glass path deserves particular attention because it is designed to bypass the controls. A recovery mechanism that lets two named people reconstruct a key is a reasonable design; the same mechanism where the shares were distributed in 2021 and one holder has left is not a control, it is an unmanaged copy.

Give every key a purpose and a lifetime

Two fields, recorded per key, prevent most of the drift: what this key is for, and when it stops being used.

Purpose enforces separation. A key with one recorded purpose can be checked against its actual uses, and a second use is a finding rather than a convenience. Keys without a recorded purpose accumulate uses—the token signing key that also encrypts a cache, the TLS private key that also signs webhooks—and each additional use makes rotation harder because more systems must change together.

Lifetime makes rotation a schedule rather than an emergency. NIST SP 800-131A is the record of how algorithm and key-length guidance has moved over time, and the implication for an operating estate is that keys and algorithms will both need replacing on a timescale shorter than most systems’ lives. A key with no recorded end date will be in use until an incident forces the question.

Where the key lives in a validated module, FIPS 140-3 gives you a defensible statement about extraction resistance. It says nothing about whether the key’s purpose has stayed singular, which is why the two fields matter independently of the hardware.

Rotation is a capability, not a schedule

Organisations write rotation intervals into policy and then discover, during an incident, that rotating a particular key requires coordinating four teams and a customer-facing change window.

The distinction worth making is between keys that rotate automatically as a matter of routine and keys that require a project. Ephemeral session keys, short-lived workload credentials and data keys wrapped by a key-encryption key belong in the first category and largely take care of themselves. Signing keys with external verifiers, root keys anchored in hardware, and keys embedded in deployed devices belong in the second, and for those the capability has to be built and exercised.

The test is simple: when was this key last rotated, and how long did it take? A key that has never rotated cannot be assumed to be rotatable. Where the answer is unacceptable, the fix is usually architectural—introduce a wrapping layer, move to short-lived credentials issued per workload, or add an algorithm and key identifier so multiple keys can be valid at once.

NCSC’s development guidance makes the broader point that secret handling has to fit how systems are actually built and operated. A rotation procedure that only works during a maintenance window will not be used during an incident, which is the moment it exists for.

Destruction is harder than it sounds

Destroying a key means destroying every copy, which is why question five determines whether question eight is answerable. A key deleted from the primary module and present in a backup has been withdrawn from use, not destroyed.

Practically, this means deciding in advance which copies exist and how each is destroyed: a module operation for the authoritative copy, a documented procedure for the disaster-recovery copy, retention expiry for backups that contain it, and collection of any physical shares. It also means accepting that a key present in a long-retention backup cannot be destroyed before that backup expires, and recording that as a known state rather than asserting destruction.

Cryptographic erasure—destroying a key to render the data it protected unreadable—is a legitimate and useful technique for data disposal, and it depends entirely on this. If a copy of the key survives, the data has not been erased.

A key inventory worth maintaining

A full inventory of every key in an estate is a project that finishes shortly before it becomes stale. A smaller artefact is sustainable and more useful.

Record, for the keys whose compromise would be material: purpose, location of the authoritative copy, module or service holding it, exportability, which components may use it, the complete list of other copies with their owners, the cryptoperiod, the date and duration of the last rotation, and the destruction procedure. Ten to thirty keys, one line each, reviewed when a system changes rather than annually.

The reason to keep it to the material keys is that this list gets read. It is what an incident responder needs in the first hour, what a customer’s due-diligence questionnaire is actually asking about, and what tells you whether the encryption in your architecture diagram means anything. A complete inventory that nobody maintains provides none of that. As NIST’s zero trust framing suggests, the useful question is always about a specific resource and a specific request—which for keys means a specific key and who can use it.