Key rotation in a KMS: what it does and what it definitely does not

Rotating a key in a key management service means giving the key object new cryptographic material to use from now on. It does not mean your data has been re-protected, and it does not mean anything that was previously exposed has stopped being exposed. This is the most reliably misunderstood operation in the whole subject, and getting it wrong produces compliance evidence that is technically true and operationally worthless.

What rotation changes, and what it leaves alone

Rotation of a key-encryption key

  changes    the material used to protect NEW operations

  does NOT   re-encrypt any existing data
  does NOT   rotate the data keys that key has generated
  does NOT   remediate a data key that has already leaked
  does NOT   change the key identifier, name or policy
  does NOT   delete, disable or retire the previous material

Read that list twice, because each line is a design decision that somebody has to make elsewhere. The vendors state it plainly. Key rotation has no effect on the data the key protects, does not rotate the data keys the key generated, does not re-encrypt any data, and will not mitigate the effect of a compromised data key. The equivalent wording elsewhere is that rotating a key creates new active key versions but does not re-encrypt your data and does not disable or delete previous key versions.

The identifier stability is the reassuring half. The key remains the same logical resource however many times its material changes, and its properties do not change with it. Nothing in your application configuration, your policies or your stored object headers needs updating when a rotation occurs, which is why automatic rotation is safe to enable in the first place.

The retention half is the half people forget to plan for. Old material is preserved indefinitely, because it is the only thing that can decrypt what it encrypted. Some services keep billing you for previous versions until you actively destroy them, and you cannot destroy them while any ciphertext still depends on them. A rotation policy without a re-encryption plan therefore accumulates versions, cost and a growing set of things you are not allowed to switch off.

Why the previous material has to survive

NIST gives the model that explains the retention. A key does not jump from useful to gone; it passes through states, and one of those states exists exactly for this situation.

stateDiagram-v2
    [*] --> Preactivation
    Preactivation --> Active: authorised for use
    Active --> Suspended: temporarily withdrawn
    Suspended --> Active: reinstated
    Active --> Deactivated: protection period ends
    Suspended --> Deactivated
    Active --> Compromised: compromise discovered
    Deactivated --> Compromised
    Deactivated --> Destroyed: no ciphertext depends on it
    Compromised --> Destroyed
    Destroyed --> [*]

A key in the pre-activation state has been generated but is not yet authorised, and must not be used either to protect or to process information. An active key may be designated for protection, for processing, or for both. When it is deactivated it must no longer be used to apply protection, but it may still be used to process information that was protected while it was active. That deactivated state is precisely what a rotated key version becomes: retired for new writes, still required for old reads.

Treat the diagram as a model rather than a mandate. The recommendation itself presents its state figure as an example, notes that an earlier revision had a separate destroyed-compromised state, and allows a system to decide that it will not use the suspended state at all. What is not optional is the underlying idea: retirement and destruction are different events, separated by however long it takes to stop depending on the key.

The key types nothing rotates for you

Automatic rotation is far narrower than the feature name suggests, and the exclusions are exactly the keys people care most about.

The asymmetric exclusion has a reason, not just an omission behind it: additional steps are required before a new asymmetric key version can be used, because the corresponding public key has to reach everyone who verifies or encrypts with it. That is a distribution problem, not a key problem, and no service can solve it on your behalf. Rotating a signing key is therefore a trust transition, with all the staged-overlap machinery that implies, and it belongs in a change plan rather than a scheduler.

Where automatic rotation is supported, know the parameters you actually have. The default automatic period is commonly a year and is configurable; on-demand rotation exists for the cases where you need new material immediately and does not disturb the existing schedule; and service-managed keys, as opposed to the ones you create, rotate on a fixed schedule you cannot change. One provider moved that fixed schedule from roughly three years to roughly one in May 2022, which is a useful reminder that “the default” is a moving target worth re-reading rather than memorising.

A cryptoperiod is two periods, not one

NIST defines a cryptoperiod as the time span during which a specific key is authorised for use by legitimate entities. The part that most policies drop is that it has two halves. The originator-usage period is the time during which the key may be used to apply protection. The recipient-usage period is the time during which it may be used to process protected data, and it typically extends beyond the originator-usage period.

The suggested figures make the asymmetry concrete. For symmetric data-encryption keys and for symmetric key-wrapping keys, the originator-usage period is given as under two years, and the recipient-usage period as under that period plus three years. A symmetric master or key-derivation key is given as about one year, and a private signature key as one to three years. The recommendation immediately warns that these are rough order-of-magnitude guidelines and that a longer or shorter cryptoperiod may be warranted by the application and environment.

Write your policy in the same shape. “We rotate the wrapping key every twelve months” is half a policy; it says nothing about how long you are prepared to keep reading data protected under a retired version, which is the number that actually decides when you can destroy material and stop paying for it. And note the hard rule that overrides all of it: if a key is compromised, its cryptoperiod is no longer considered valid. Compromise is not handled by waiting for the next rotation.

Building the re-encryption job you actually needed

For each object, in bounded batches:
  1. read the header and note the key version reference
  2. skip the object if it already names the current version
  3. unwrap the data key using the version it names
  4. request a fresh data key under the current version
  5. re-encrypt the body, or re-wrap the same data key if the
     data key itself is still within its own cryptoperiod
  6. write the new header atomically, keeping the old one until
     the write is durable
  7. record the object as migrated and emit progress metrics

Only when zero objects reference a retired version:
  8. disable that version and wait out an observation window
  9. destroy it, and only then stop paying for it

Step five contains the design choice. Re-wrapping the existing data key under the current wrapping key version is cheap, touches only the header, and is the right answer when the concern is the wrapping key’s cryptoperiod. Re-encrypting the body under a brand-new data key is expensive and is the right answer when the data key itself is old, has encrypted too much, or is suspected. Deciding which problem you are solving before you start is what keeps the job from taking a month for no benefit.

Step eight is not optional politeness. Disabling first turns an inventory mistake into a recoverable outage; destroying first turns it into permanent data loss.

Production discipline

1. Publish the oldest-dependency metric. For every key, report the oldest material version any live object still references, and alert when it exceeds the recipient-usage period you wrote down.
2. Never answer a compromise with a rotation. Rotation protects future writes. A compromised key needs the compromised state, revocation of whatever it authorised, and re-encryption of what it protected.
3. Plan asymmetric rotation as a trust transition. New key, overlap window, distribute the public half, verify relying parties, then withdraw the old one. A scheduler cannot do any of that.
4. Disable before destroying, always. Keep an observation window long enough for the slowest batch job and the quietest quarterly report to run at least once.
5. Do not let manual rotation be the primary control. The guidance is explicit that irregular or manual rotation should not be relied on as a primary component of an application’s security. Automate what can be automated and treat the rest as a scheduled change with an owner.

Cross-course references

• Observability for Production Sysadmins - Part XVII (RecordingRules) covers precomputing the kind of slow-moving inventory metric that an oldest-dependency figure needs in order to be alertable.
• Kubernetes for Production Sysadmins - Part LXV (SecretsSec) covers rewriting every Secret so that a new encryption provider takes effect, the cluster-shaped version of the re-encryption job described here.
• Git, CI/CD & GitOps for Infrastructure Engineers - Part XCIII (CredRotation) covers staged credential overlap, the pattern that asymmetric key rotation forces you to adopt.

Quiz