Secrets management, explained without the jargon

We end up explaining this on discovery calls often enough that it deserved writing down. Here is secrets management without the vocabulary that usually surrounds it.

The bill is a design document: it tells you exactly what your architecture actually does. It rarely shows up as a line item, which is exactly why it slips.

The short version

Secrets in a repository are a breach waiting for a schedule. The teams that handle this well are rarely the ones with the biggest budgets. Anything you cannot measure here, you are deciding by taste, which is fine as long as everyone knows it.

Why people complicate it

Most of the confusion comes from tooling rather than from the idea itself. The cost of getting this wrong is rarely visible on the day it happens.

Rotate them on a cadence, not after an incident. That sounds obvious written down. It is still the thing most often skipped. The failure mode is not doing it wrong, it is doing it once and assuming it stays done.

What to do next

Every secret should have a documented owner. The teams that handle this well are rarely the ones with the biggest budgets. It is worth deciding this deliberately rather than inheriting whatever the last person set up.

In practice

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
• Every secret should have a documented owner — and you know whether that is true here
• There is a way to tell whether the last change to this helped

Worth checking on your own setup before it becomes someone else's problem to fix.