What is the difference between centralised secrets management and zero standing privilege?

Where centralised secrets management fits, and what it does not change

Centralised secrets management answers a storage and retrieval problem. It moves credentials, tokens, API keys, and certificates out of application code, files, and ad hoc owner memory into a controlled system with naming, access policy, rotation, and auditability. That changes where the secret lives, who can fetch it, and how consistently it can be protected across teams and environments. A practical overview is covered in the Secrets Management Guide.

Its security value is strongest when the organisation needs one governed source of truth for secret lifecycle. Centralisation can reduce secrets sprawl, improve rotation discipline, and make revocation more reliable, but it does not by itself ensure that access is temporary, narrowly scoped, or tied to a specific task. A central vault can still contain long-lived credentials with broad reach if policy is weak. For design and product evaluation, the Secrets Management Buyer's Guide is useful because it distinguishes platform capabilities from actual operating controls.

Think of centralised secrets management as a control over secret custody and secret handling. It changes the exposure surface by removing copies from many places, but the secret can still remain standing and reusable until something else shortens its life or constrains its use. The difference matters because many teams assume a vault automatically delivers least privilege, when in practice it often only makes the credentials easier to govern.

What zero standing privilege changes in the access model

zero standing privilege governs when access exists, not where a secret is stored. The goal is that no user, workload, or operator retains always-on privilege beyond the moment it is needed. Access is raised just in time, used for the approved action, and removed immediately after. That is why JIT and ZSP are closely related concepts in privileged access design, as described in the Just-in-Time Access and Zero Standing Privilege Guide.

In practice, ZSP reduces the attack window and the blast radius of privileged access. If an account, role, session, or agent does not have standing privilege, compromise is less likely to become durable misuse. The privileged access pattern can still rely on a vault, but the key control is temporal and procedural: approval, elevation, task completion, then revocation. The broader privileged access model is laid out in the Privileged Access Management Guide.

That makes ZSP a control over exposure time and privilege persistence, not a storage model. You can centralise secrets without ZSP, and you can implement ZSP while secrets remain distributed in a more limited way. In mature environments, the two controls are often combined: centralisation governs the credential, and ZSP governs whether that credential is continuously usable.

How the two controls differ in practice

The cleanest distinction is this: centralised secrets management asks, “Where is the secret kept and how is it governed?” ZSP asks, “When is access allowed to exist at all?” One reduces distribution and improves lifecycle control. The other removes persistent privilege and forces access to be ephemeral. For secrets that should not be reused freely, the lifecycle dimension becomes especially important, as explained in the static vs dynamic secrets section and the Guide to NHI Rotation Challenges.

In operational terms, centralised secrets management can still support long-lived access paths if the secret is checked out, copied, or reused without strong expiry rules. ZSP, by contrast, is meant to make standing access the exception, not the norm. A system may satisfy one control and still fail the other: a well-run vault with permanent admin entitlements is not ZSP, and a just-in-time elevation process backed by unmanaged local secrets is not strong centralised secrets management.

Risk and Threat Considerations

These controls fail in different ways. Centralised secrets management can become a high-value concentration point if access policies are too broad, rotation is inconsistent, or secrets are replicated into logs, build systems, or environment variables. ZSP fails when standing entitlements remain active in practice, when emergency access becomes routine, or when privileged sessions are easy to renew without re-approval.

Failure mechanism: Secret centralisation collapses many credentials into one control plane, so a vault or secret manager with weak access policy, poor rotation discipline, or excessive administrative access can expose many downstream systems at once. ZSP fails when elevation is treated as a checkbox and privilege remains effectively persistent through cached sessions, reusable approvals, or overbroad roles.

Impact: Centralised secrets failures usually widen the blast radius of credential compromise and make lateral movement easier across applications or environments. ZSP failures usually increase the chance that a single stolen session or abused privileged path becomes durable access, which is why privilege reduction and time-bounding are often paired with stronger monitoring and revocation controls such as those described in OWASP Non-Human Identity Top 10.

Practitioner Guidance

What to verify: Check whether the secret manager governs retrieval only, or whether it also enforces expiry, rotation, and access boundaries that make the secret materially safer. Then verify whether privileged access is actually time-bound end to end, including approval, session duration, and revocation, not just role assignment.

Decision rule: If the problem is secret sprawl, check-in risk, or inconsistent rotation, prioritise centralised secrets management. If the problem is persistent privilege, excessive admin reach, or high-impact standing access, prioritise ZSP. In many environments, the right answer is both, because one reduces credential distribution while the other reduces usable exposure time.

Practitioner takeaway: Centralised secrets management controls the credential’s home; zero standing privilege controls the privilege’s lifetime. Treat them as complementary, not interchangeable, and test each control against the failure mode it is actually meant to prevent.

Related resources from NHI Mgmt Group

• What is the difference between secrets rotation and zero standing privilege?
• What is the difference between attack surface management and NHI governance?
• What is the difference between least privilege and zero standing privilege for NHI governance?
• What is the difference between zero standing privilege and just-in-time access?