When organisations think about secrets management, they typically think about vaults — where to store API keys, database passwords and certificates securely. But the vault is the easy part. The hard part is everything around it: how secrets are created, who can access them, how they're rotated, what happens when they're compromised, and how you prove to an auditor that all of this is working.
The operational reality
A vault stores secrets securely, but it doesn't solve the operational challenges. Secrets still need to be injected into applications at runtime. Rotation needs to happen without downtime. Access needs to be scoped to the minimum necessary. And when an incident occurs, you need to know exactly which secrets were potentially exposed and rotate them immediately.
Automated, tested, verified
The single most important operational capability for secrets management is automated rotation. If rotating a secret requires manual steps, it won't happen on schedule and it definitely won't happen quickly during an incident. Every secret should have an automated rotation procedure that's tested regularly — ideally as part of the CI/CD pipeline.
Equally important is blast radius limitation. Secrets should be scoped as narrowly as possible — per-service, per-environment, per-integration. A compromised database credential for one service in staging shouldn't grant access to production data in another service.
Proving it works
Auditors don't just want to know that you have a vault. They want to know who accessed what secret, when, and why. They want evidence that rotation happens on schedule. And they want confidence that your incident response procedures for secret compromise are tested and effective. Build these audit capabilities from the start — retrofitting them is significantly harder.