Secret Rotation Compliance Audit Workflow
Verify every secret class rotates within its policy window, detect stale credentials mechanically, and drive exceptions to zero or documented expiry.
Objective
Replace assumed rotation with verified rotation: every secret class checked against its policy age, exceptions owned and expiring.
Environment
- A secret inventory with creation dates available
- Policy windows defined per secret class
- Read access to credential metadata (not values) across systems
Steps
1. Define rotation policy per class
Set maximum age per secret class: API keys 90 days, database credentials 180, TLS certs by expiry, break-glass after every use.
Expected state: A policy table exists that the audit can mechanically apply.
2. Collect credential ages
Gather creation or last-rotation dates from each system's metadata (never the values), joining into the inventory with the class and owner.
Expected state: Every secret has an age computed from authoritative metadata.
3. Report violations by class and owner
Generate the violation report: secret, class, age, policy, owner, and days overdue, ranked by exposure severity of the class.
Expected state: The report names owners and overdues, not just counts.
4. Drive exceptions to expiry
For items that cannot rotate immediately, require a documented exception with owner, justification, compensating control, and a hard expiry.
Expected state: No violation exists without either a rotation date or a registered exception.
5. Verify rotations actually invalidate
Sample rotated secrets and verify the old credential fails authentication, catching rotations that create new keys without revoking old.
Expected state: A sampled old credential fails everywhere it was valid before.
Expected outcome
Rotation compliance measured from system metadata, violations owned or exceptioned with expiry, and rotations verified to revoke the old credential.
Verification
The audit report reconciles with the policy table with zero unowned violations; a sampled pre-rotation credential fails authentication after its rotation.
Rotation that only adds keys is not rotation
The quiet failure of rotation programs is additive rotation: a new key is created, consumers migrate, and the old key keeps working forever. Auditing ages mechanically and sampling old-credential revocation catches both the stale and the undead.
policy: api-keys 90d | db creds 180d | tls: expiry
audit report (2026-10-22):
class total violations oldest
api-keys 142 11 341d (owner: data)
db creds 38 3 412d (owner: legacy)
tls certs 26 0 29d
exception register:
db/legacy-reporting 412d owner: eng-legacy
reason: vendor app hardcodes; control: egress allowlist
EXPIRES: 2026-12-01 (vendor patch)
revocation sample: key rotated 10-20, old key auth FAIL (OK)Audit metadata, never values
An audit process that reads secret values becomes the highest-privilege system in the estate and a target itself. Every system exposes enough metadata (creation time, last rotation, version) for age compliance; the audit needs dates, not plaintext.
Exceptions must die by date
Rotation programs stall on the immovable items: the vendor who hardcodes credentials, the appliance nobody dares touch. Registering those with a compensating control and a hard expiry keeps the program honest while capping how long immovable stays immovable.