Rotating device keys without downtime

Terminal key rotation is one of those operations that everyone knows they should do more often and no one wants to be the one running. The reason is straightforward: a bad rotation bricks devices, and a bricked terminal in the field is expensive. But the solution isn't to rotate less often; it's to make rotation routine.

Written September 2026 from a set of fleet operations reviews.

What makes a rotation risky

Three things:

• The device holds a single active key. If the rotation fails partway, the device is stuck between old and new.
• The rotation is a big-bang event. Everyone gets the new key on the same day, so one bad merge affects the whole fleet.
• The verification step is post-hoc. You find out the rotation worked when the next transaction succeeds — or doesn't.

What makes it safe

• Dual-active key windows. The device accepts both the previous and current key for a defined transition period. A failed rotation degrades to using the old key, not to a decline.
• Rolling deployment. Rotate 5% of the fleet on a Monday, 20% on Wednesday, the rest the following week. Any regression appears at low volume.
• Verification before completion. The terminal must successfully perform a canary transaction with the new key before the old key is retired locally.
• Server-side rollback capability. If a segment of the fleet is misbehaving, the server can revoke the new key for those devices and revert them to the old.

The operational overhead of running rotations this way is real but small — one on-call engineer for a rolling week, per rotation. The alternative is a large incident every eighteen months when a rotation goes wrong.