Should organisations keep secrets management if they adopt workload access management?

Should secrets management remain in place after workload access management?

Yes, but only as a transition layer for legacy credentials that cannot be removed yet. The real shift is from protecting stored secrets to shrinking the set of credentials workloads ever need. That means secrets management becomes narrower, not redundant: it supports migration, exception handling, and controlled rotation until workloads can move to stronger, short-lived access patterns.

What role does secrets management still play?

workload access management changes the target state, not the entire control stack. Secrets management still has value where applications, integrations, or third-party dependencies cannot yet be refactored to use secretless or short-lived credential flows. In that phase, the job is to centralise storage, reduce exposure, and make rotation and revocation reliable.

The most practical way to think about the relationship is separation of concerns. Workload access management governs how workloads prove themselves and receive access; secrets management governs the safer handling of the credentials that remain. If a workload still depends on a static API key, certificate, token, or bootstrap secret, removing the vault too early usually increases exposure rather than reducing it.

That is why many teams keep secrets management as a bridge while they redesign authentication paths. A good transition programme inventories every remaining credential, classifies whether it is bootstrap, legacy, or unavoidable, and then pushes each one toward expiry, tighter scope, or replacement with workload-native access.

When does secrets management become a transitional control?

Secret sprawl is the clearest sign that secrets management is doing work that workload access management has not yet eliminated. If credentials are still embedded in code, environment variables, CI/CD jobs, or image layers, the vault remains important as a containment and rotation layer. The goal is not to store more secrets more safely forever, but to remove the reasons those secrets exist.

Transition use cases usually fall into three buckets: legacy systems that cannot support workload-native identity, vendor integrations that still require a shared secret, and bootstrap flows that need one initial trust artifact before a stronger channel is established. In each case, secrets management is a compensating control, not the end state.

Once the migration path is clear, the governance question changes from "Where do we keep this secret?" to "Can this workload stop possessing a secret at all?" That is the right point to reduce vault dependencies, shorten lifetimes, and replace static credentials with ephemeral access wherever the system supports it.

How should teams decide what stays, what moves, and what goes?

Use a simple decision rule: if the workload can authenticate without retaining a reusable secret, move it; if it cannot, keep the secret only for as long as the dependency remains. Workload identity is the cleaner target state because it reduces secret inventory, narrows blast radius, and makes authentication more attributable.

For the remaining secrets, prioritise by exposure and business criticality. High-value credentials with broad access, long lifetimes, or many replicas deserve first attention because they create the largest operational and compromise impact. Lower-risk secrets can stay under management longer, but they should still be time-bounded, scoped, and mapped to an owner with a removal plan.

The useful metric is not how many secrets are stored centrally. It is how many workload functions still depend on a reusable credential to operate. When that number keeps falling, the programme is moving in the right direction.

Risk and Threat Considerations

The main risk is treating workload access management as a reason to relax secrets hygiene before the migration is complete. If legacy credentials remain in circulation, they still can be leaked, reused, over-scoped, or abused for lateral movement. Hidden secret sprawl also makes it easy to lose track of which workloads still have standing access and which credentials should already have been retired.

Failure mechanism: Reusable credentials survive the transition, accumulate in applications and pipelines, and continue to provide durable access after the intended move to workload-based authentication.

Impact: A single exposed secret can still open multiple workloads, extend compromise duration, and create unnecessary operational and incident-response burden.

Practitioner Guidance

What to prioritise: Preserve secrets management only for credentials that are still required, then focus first on the secrets with the broadest access or longest lifetime. That is where the biggest reduction in risk and operational drag will come from.

What to verify: For each remaining secret, verify whether it is truly required, where it is used, who owns its rotation, and whether a workload-native alternative already exists. If the answer is unclear, the secret is probably doing too much.

Common mistake: Treating the vault as the destination. In practice, a strong programme uses the vault to buy time for removal, not to preserve indefinite credential dependency.

Practitioner takeaway: Keep secrets management as long as it is still needed to retire legacy access safely, but measure success by the shrinking population of secrets, not by the size of the vault.

Related resources from NHI Mgmt Group

• What breaks when organisations keep treating application secrets as if they are the same thing as workload identity?
• Should organisations keep classic PAM if they are moving to dynamic access controls?
• How do organisations keep secrets safe when they sync credentials into cloud services?
• How do organisations decide whether to prioritise secrets management or access governance first?