Key Rotation

Key rotation is the practice of replacing credentials and cryptographic keys on a schedule, so that a key which has leaked without anyone noticing stops being useful after a bounded interval. It applies across the whole credential surface of a SaaS product: API keys issued to customers, keys the product holds for third-party services, database passwords, signing keys for tokens, and the data encryption keys underneath stored records. The reasoning is about blast radius over time, not about keys wearing out. Most credential compromises are discovered long after they occur, if ever — a key committed to a repository, pasted into a support ticket, or left on a decommissioned laptop. Rotation converts an unbounded exposure into a bounded one without requiring detection, which is why it is a standard control in SOC 2 and ISO 27001 programmes and a routine question on customer security reviews. The mechanism that makes rotation survivable is overlap. A rotation that revokes the old key at the same instant the new one is issued causes an outage for every client that has not yet picked up the change, so real implementations issue the new key first, allow both to authenticate for a defined window, migrate consumers, then revoke the old one. This means the system must support more than one valid key per identity, and that requirement is easier to design in than to retrofit. For token signing, the equivalent is publishing multiple public keys with key identifiers so verifiers can select the right one. Encryption keys have their own pattern: rather than decrypt and re-encrypt an entire dataset, envelope encryption lets each record keep its own data key while only the key encryption key is rotated, which turns a multi-day migration into a metadata operation. Rotation only produces security if revocation actually happens. A programme that issues new keys on schedule but never disables the old ones has increased the number of live credentials while feeling compliant. Practical note: automate rotation rather than calendaring it, and log every use of a credential with its key identifier. Without that, nobody can tell whether the old key is still in use, and the revocation step gets postponed indefinitely because it is the one that might break something.