How to use this checklist
This is the gate a secret management platform passes before anything production-critical is allowed to depend on it. Run it once before the first real credential is stored, and again whenever the platform gains a new authentication method, a new storage backend, or a new class of consumer. The review is deliberately about the platform rather than about individual secrets: what lives inside it is reviewed by the rotation and leak-response checklists.
Work through it with the platform running and a scratch namespace you are willing to write to. Roughly half the items cannot be answered by reading configuration, because the question is not what the configuration says but what the running system does when a token asks for something it should not have. A review conducted entirely from a repository is a review of intentions.
Where the numbers come from
Lifetimes, thresholds and share counts are read back from the live system rather than from the document that requested them. A lease lookup reports the remaining time to live for a credential that was actually issued; a policy file reports what somebody meant. Where the two disagree, the live reading wins and the disagreement is itself a finding.
Four items are attested rather than measured, and no command can change that. Custody of unseal shares, ownership of each application identity, the justification for every remaining static credential, and the date of the last leak-response rehearsal are all statements a named person makes and signs. Write down who made each statement. An attestation with no name attached decays into folklore within one staffing change.
Access this needs
A read-only administrative token for the secret manager, enough to list mounts, read policies and inspect leases. A separate token carrying one ordinary application policy, so the refusal cases can be exercised without administrative rights masking them. Read access to the audit destination, whether that is a file on the host or an index in a search system. Read access to the repositories the platform deploys from, and to the infrastructure state backend. Nothing in this review requires the authority to write a production secret.
What the review produces
A dated record naming the reviewer, the platform version, and the disposition of every item. Attach the live readings taken during the review: the audit device listing, the refusal captured from the application token, the lease lookup with its remaining time to live, and the timing of the restore rehearsal. Findings go to the platform owner with dates; anything touching custody of unseal material or audit coverage goes to the security owner on the same day.
Sign-off
- Reviewer: ________________ Date: ___________
- Platform owner: ___________ Date: ___________
- Security owner: ___________ Date: ___________
Every critical item must pass. A failing critical item blocks the platform from holding production credentials at all; it is not a note for the next sprint. Record the date, the reviewer, and the disposition of every item that did not pass, together with the name of whoever accepted the residual risk.