目标
轮换计划最安静的失败是“只加不减”：新密钥建好、消费方迁移，旧密钥却永远有效。用系统元数据机械审计密钥年龄，再抽样验证旧凭据确实失效，既抓超期未换的陈旧凭据，也抓换而不废的不死凭据；动不了的例外必须登记补偿控制与硬性到期日。
步骤要点
- 按类定义轮换策略：API 密钥 90 天、数据库凭据 180 天、TLS 证书按有效期、break-glass 每次用后即换，形成可机械应用的策略表。
- 采集凭据年龄：从各系统元数据（绝不碰值）取创建或最近轮换时间，连同类别与 owner 汇入清单。
- 按类与责任人出报告：密钥、类别、年龄、策略、超期天数，按类别暴露严重度排序，具名到 owner。
- 把例外逼向到期：暂不能轮换的项须登记理由、补偿控制与硬性到期日，任何违规项要么有轮换日期要么有登记例外。
- 验证轮换真的作废：抽样已轮换密钥，确认旧凭据在所有原有效处认证失败。
排错提示
旧密钥还能认证说明轮换只建新未吊销，把吊销验证设为轮换流程的收尾步骤；例外清单只增不减是到期日形同虚设，过期例外自动升级为违规上报；审计脚本去读密钥值本身是越权设计，年龄合规只需元数据。
适用边界
元数据采集依赖各系统的暴露程度，无法取龄的系统只能退回人工登记加抽验；补偿控制的有效性会随架构变化衰减，例外复审要跟着变更走。
代码示例
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)