A team stores credentials in a secrets manager and considers the problem solved. What is still wrong, and what does a genuinely good secrets posture look like?

What a secrets manager does and does not fix

It fixes: secrets in source control, secrets in environment variables visible in process listings, secrets copied into wikis, and secrets with no access audit trail.

It does not fix the fundamental problem, which is that a long-lived credential is a persistent liability regardless of where it is stored. A database password held in a vault and retrieved by an application is still a password that works forever, that exists in the application's memory, that may be logged in a stack trace, and that an attacker who compromises the application obtains.

Storing it well is a smaller improvement than not needing it.

The genuinely better posture

• Workload identity instead of secrets. The workload proves what it is — through the platform's attestation, a signed token, or a certificate — and receives short-lived credentials automatically. There is no secret to store, leak, rotate or find in a repository. This is the single largest improvement available and it is supported by every major cloud platform.
• Short-lived credentials where a secret is unavoidable: minutes or hours, not months. This converts a leak from a permanent compromise into a bounded one, and it makes rotation continuous rather than an event.
• Automatic rotation that is exercised. Rotation configured but never executed fails on first use — usually during an incident, when the credential must be revoked. Rotate on a schedule so that the mechanism is proven rather than hoped for.
• Scoped narrowly. A credential that can read one table is a much smaller event than one with administrative rights. Most credentials are over-scoped because scoping them precisely required work at creation time.
• Distinct per environment and per service, so a leak from a test system is not production access.
• Never logged, enforced by redaction in logging and error handling — stack traces and request dumps are the most common leak path and they are almost never in the threat model.
• Detection: secret scanning in repositories and in CI, plus anomaly detection on credential use.
• A rehearsed revocation path, with a known time to revoke and replace. "How fast can we rotate everything if we must?" is a number every organisation should know and almost none do.

The question that reframes the work

"If this credential leaked right now, what could an attacker do, and how quickly could we stop them?"

Asked per credential, this immediately reorders the work: the over-scoped, long-lived, widely-distributed credential matters far more than the correctness of the vault configuration, and the effort usually goes to the vault because it is the visible artefact.