Rule 11 of 12 · Chapter III — Running Keys in the Open
Make key replacement a routine, rehearsed operation that requires no change to the algorithm, protocol, or deployed code.
Why this rule exists
Rotation that requires an engineering project will not happen under pressure, which is exactly when it is needed. If replacing a key means a release, a migration, and a maintenance window, your real response to a suspected leak will be to hope. A system that rotates weekly by habit rotates in ten minutes during an incident.
In practice
Build for two live keys at once: accept the old and the new during an overlap window, then retire the old. Put rotation on a schedule and let it run unattended, so the path is exercised long before you need it. Rehearse the emergency version too — pick a key, declare it burned, rotate it, and time how long until the last consumer stops using it.
When it doesn't apply
Keys that are physically bound to hardware or printed into a device at manufacture cannot be rotated in place; for those, plan replacement at the device level and keep the rotatable layer above them. A short-lived key that expires faster than you could detect a compromise does not need separate rotation machinery.