Rotation gets deferred because nobody knows where the key went

Everyone agrees keys should be rotated. Almost nobody does it on a schedule, and the reason is logistical, not lazy.

A rotation pulse spreads out from the key and updates the four consumers anyone wrote down. Five more copies sit outside the ring, unrecorded, and the pulse never reaches them — they stay valid.

Rotating a credential is trivial at the provider: click revoke, click create, copy the new value. The hard part is the sentence that follows — now update it everywhere.

Everywhere is undefined. It is however many .env files, CI settings pages, teammates’ machines and half-forgotten staging boxes have a copy. Because the list does not exist, rotation becomes an open-ended search with a real chance of breaking production, so it gets postponed until an incident forces it.

How it actually bites

  1. The blast radius is unknown before you start

    You cannot estimate the work, so you cannot schedule it. A task with an unknown size and a non-zero chance of an outage loses every prioritisation argument it is ever in.

  2. Rotating breaks a service nobody remembered

    The one cron job on the old staging server that still uses the old key fails silently at 3am. The next rotation gets deferred harder because of it.

  3. A leaked key stays valid because revoking it is scary

    This is the worst version. The key is known to be exposed, and it stays live anyway because revoking it means finding every consumer first, and nobody wants to be the person who took down checkout.

  4. Departed colleagues still hold working copies

    Offboarding removes accounts. It does not remove the keys someone pasted into their personal notes app in their first week, and those stay valid until the key itself is rotated.

What we do about it

  1. One canonical copy to change

    The vault holds the value; everything else is a generated artefact. Update it in one place, regenerate the .env, and the machines that matter are current.

  2. The value is grouped by project

    Because keys are organised per project rather than scattered per machine, the set of things affected by a rotation is a list you can look at rather than a memory exercise.

  3. Revocation rotates the shared key

    Removing a teammate from a shared project does not just delete a permission row. It rotates the project data-encryption key and re-wraps it for the remaining members, so the copy they already had stops opening anything new.

  4. A catalog that tells you where to rotate

    The extension ships a reference of API providers with a direct link to each one’s key management page — verified against the live page, not guessed. It saves the ten minutes of hunting that starts every rotation.

Try it against your own keys

The extension is free and works offline. Set a master password, import an existing .env, and see what the vault looks like before you decide to trust it with anything.