What is secrets management?
Secrets management is how an organization stores, distributes, rotates, and audits its secrets — the credentials that let systems authenticate to other systems. Done well, it means no human ever copies a production database password into a config file, and every credential can be traced, rotated, and revoked from one place.
What counts as a secret?
A secret is any credential that grants access and would cause harm if leaked: API keys and tokens, database and service passwords, private keys and TLS certificates, SSH keys, encryption keys, and the connection strings that bundle several of these together. The defining property is not the format — it is that possession equals access.
What does good secrets management require?
The practices that separate a secrets program from a pile of .env files:
- A central source of truth — a vault or managed secrets service, not credentials scattered across repos, CI configs, and laptops.
- No secrets in code — enforced by pre-commit and CI scanning, because a secret committed to git is compromised even after it is deleted.
- Least-privilege access — each workload reads only the secrets it needs.
- Rotation — credentials change on a schedule and on demand after exposure, ideally automatically.
- Audit — every read and write of a secret is logged and attributable.
How does secrets management connect to identity governance?
Secrets management and identity governance are two halves of the same access problem. IGA governs which identities should have access; secrets management protects the credentials that enforce it. A vault with weak access policy is just a more central place to steal from — so the audit trail on the vault is itself a governance artifact. Both feed the same question a CISO and CFO ask together in Cloud Identity & FinOps.