Key management: test rotation, revocation and recovery separately

Illustrative case: a leaked signing credential

Suppose a fictitious service finds its token-signing credential in a build artifact. Replacing it changes how the service signs new tokens. However, consumers may still accept tokens signed with the exposed key. Rotation at the issuer has succeeded while trust in the old key remains. Identify every affected consumer, decide when its acceptance must end, and check whether that change takes effect.

Token validity and cached verification keys affect the cutover. In a test environment, use a token signed with the old key and one signed with its replacement. After the planned change, the old signer must be rejected wherever revocation is required, while the replacement must work. If the design intentionally retains a validation window, document its duration and cache behavior. Do not report that window as immediate revocation.

Tracing the consumers of a key

Record identifiers and references, never private key material. The purpose is to find the systems that depend on each operation. Keep credentials, encryption keys and trust anchors distinguishable because the conditions for retiring them are different.

Exercise the lifecycle

Follow who can create, use, export, disable and destroy the key, including emergency access. Permission to use a key for one operation need not imply broad administration. Deny access in a controlled test and observe the failure. It should be visible, and the service should not silently fall back to unprotected processing.

Changing a key that wraps another key is different from re-encrypting the data. Establish which operation the incident or lifecycle event requires. Then test recovery from the historical backups that rely on older key versions. A successful change in the active system does not establish that those backups will remain readable after the old versions are retired.

• A trust change needs an inventory of the consumers expected to adopt it.
• Cache and configuration propagation determine when the change takes effect.
• A usable rollback must avoid restoring trust in a compromised signer.
• Usage and administrative audit records need to be available without exposing the secrets themselves.

The lifecycle test and the cryptographic design

These tests examine the deployment's handling of keys. They do not evaluate an algorithm's correctness, side-channel resistance or custody on an unexamined device. NIST control guidance and the Digital Identity Guidelines provide relevant context, while supported implementations and current protocol guidance inform platform choices. A custom cryptographic design still needs its own evaluation, even when rotation works correctly.