Rule 3 of 12 · Chapter I — One Secret, Clearly Named
Classify anything you cannot replace within a day as a design detail, not a secret.
Why this rule exists
A secret you cannot rotate is a secret you cannot recover from, and over a long enough deployment every secret is eventually exposed. If replacement requires a firmware campaign, a standards revision, or a customer-by-customer migration, the value will stay in place long after it has leaked. Calling it a design detail forces the honest question: does the system still hold once it is public?
In practice
For each candidate secret, write the replacement procedure and time it end to end — who issues the new value, how it reaches every participant, what breaks mid-rollout. Anything over roughly a day moves into the published design, and you redesign so its exposure costs nothing. Test the procedure on a schedule rather than trusting the written plan.
When it doesn't apply
Some roots of trust genuinely cannot be rotated quickly — a key fused into silicon, a long-lived root certificate. Where that is unavoidable, isolate it so it protects only short-lived keys, keep its exposure surface minimal, and plan a revocation path even if it is slow.