Before you invest in secrets management

Teams tend to reach for this after something has already gone wrong. Before you spend anything on secrets management, it is worth confirming a few things are already true.

The bill is a design document: it tells you exactly what your architecture actually does. Check it against what you would want a competitor's site to get wrong.

Prerequisites

• You can describe the outcome you want in one sentence
• Someone owns it after the work is done
• Secrets in a repository are a breach waiting for a schedule
• You have a way to tell whether it worked

Common failure modes

Rotate them on a cadence, not after an incident. The teams that handle this well are rarely the ones with the biggest budgets. The teams that stay on top of it are the ones who put it on a calendar rather than a wish list.

Every secret should have a documented owner. There is a version of this that is over-engineered, and it is worth avoiding. Most teams find the first pass takes an afternoon and the maintenance takes minutes a month.

How to tell if yours is fine

Cloud work rewards teams who automate early and punishes teams who click through consoles. Three things worth confirming about secrets management before you move on:

• Someone can say what the current setup is without going to look
• Rotate them on a cadence, not after an incident — and you know whether that is true here
• There is a way to tell whether the last change to this helped

If you want a second opinion on how yours is set up, ask.