Should organisations remove all secrets and replace them with workload identity?

Why This Matters for Security Teams

Replacing every secret with workload identity is the right direction, but it is not a universal cutover. Modern environments still include legacy databases, partner APIs, and SaaS integrations that cannot yet authenticate with short-lived workload tokens. That is why current guidance favours a phased reduction of secret sprawl rather than a risky big-bang migration. The scale of the problem is already visible: the Ultimate Guide to NHIs reports that 96% of organisations store secrets outside of secrets managers in vulnerable places such as code, config files, and CI/CD tools.

For security teams, the real issue is not whether workload identity is preferable. It is whether every machine-to-machine trust path can be re-authenticated with cryptographic proof of identity, then authorised at runtime with least privilege. The OWASP Non-Human Identity Top 10 and the 52 NHI Breaches Analysis both show how static credentials persist long after teams believe they have been removed from circulation. In practice, many security teams discover this only after a leaked API key or service account has already been used laterally, rather than through intentional secret retirement.

How It Works in Practice

The practical model is hybrid. Use workload identity wherever a platform supports it, and reserve stored secrets for systems that cannot yet move. With workload identity, an application or agent proves what it is by presenting a signed identity assertion, then receives a short-lived token for the next action only. The SPIFFE workload identity specification is the clearest example of this pattern: it binds identity to workload runtime rather than to a manually managed credential file.

Operationally, that means four things:

• Issue credentials just in time, with short TTLs and automatic revocation after task completion.
• Prefer intent-based authorisation, where policy evaluates the requested action, context, and target resource at runtime.
• Use vaults for exceptions, not as the default source of truth for every integration secret.
• Track ownership, rotation, and offboarding for the remaining long-lived credentials as a separate control plane.

This is where the Guide to the Secret Sprawl Challenge remains useful: it shows why many organisations fail not because they lack tooling, but because they have no clean inventory of where secrets live or which services still depend on them. The point of workload identity is to remove static trust from the hot path, not to pretend every integration has already modernised. These controls tend to break down in brittle CI/CD estates and partner-managed SaaS connectors because the identity boundary ends at systems you do not control.

Common Variations and Edge Cases

Tighter secret elimination often increases integration overhead, so organisations need to balance security gain against migration risk and operational fragility. There is no universal standard for when a legacy secret should be removed first versus wrapped in a vault, but current guidance suggests prioritising externally exposed systems, high-privilege service accounts, and credentials with poor rotation discipline.

One common edge case is certificate-based infrastructure. Certificates are still secrets in the operational sense, but they often sit inside mature lifecycle tooling rather than ad hoc storage. Another is autonomous software that changes behaviour at runtime. For agents and other goal-driven workloads, static RBAC alone is too blunt because the agent’s path is not fully predictable. Best practice is evolving toward runtime policy checks, JIT credential issuance, and workload identity tied to the exact action being attempted. That aligns with Guide to SPIFFE and SPIRE implementation patterns, while Ultimate Guide to NHIs — What are Non-Human Identities is a useful anchor for distinguishing identity from secret material. The safe rule is simple: remove static secrets wherever the platform supports identity-based authentication, and keep vaults only for the exceptions that still need them.

Related resources from NHI Mgmt Group

• When should organisations move from vault-based secrets to workload identity?
• What breaks when workload identity and access management are merged?
• Why do shared JWT secrets increase identity risk in microservices?
• When should organisations prioritise Zero Standing Privilege for non-human identities?