Skip to main content

Key and certificate rotation

Authorization keys, transport identities and external-service credentials have different responsibilities. Replacing one does not automatically authorize changes to the others.

What rotation must preserve​

  • Changes have an approved scope, responsible owner and reviewable evidence.
  • Requests remain bound to their authorized signing context; rotation must not silently rewrite in-flight approvals.
  • New access is validated and retired access is rejected.
  • A suspected compromise does not justify lowering the threshold or bypassing policy.
  • Private material remains separated across its intended custody domains.

Reviewable outcomes​

A rotation review should establish what changed, who approved it, whether the replacement works, whether retired access is rejected, and how outstanding operations were handled. Public evidence can describe these outcomes without publishing private topology or operational configuration.

Current boundary​

Lifecycle and rollback checks have controlled non-production test evidence. Secure key delivery and destruction, HSM/KMS custody, independent administration and production multi-operator acceptance remain to be validated.

Exact activation procedures, identity configuration, emergency replacement steps and recovery instructions belong to the version-matched restricted runbook. They must be reviewed against the actual environment before use.

See Dynamic committees and key lifecycle, Failure recovery and Source and documentation access.