Should organisations centralise workload secret handling or keep it inside applications?

Centralising the control path is usually better when the goal is consistent governance, but only if the platform can prove attribution, revocation, and least privilege at runtime. Keeping secrets inside applications creates hidden exposure and makes lifecycle governance inconsistent. The better test is whether the workload can function without ever holding the secret itself.

Why This Matters for Security Teams

The choice is not really about where a secret is stored. It is about whether a workload can prove who it is, obtain access only when needed, and lose that access cleanly when the task ends. Centralised handling can improve consistency, but only if the control plane has runtime attribution and revocation. If not, it becomes a new dependency that still leaves apps exposed to credential sprawl.

That distinction matters because machine identity risk is already hard to manage at scale: SailPoint reports that 66% of organisations say their current tooling is not adequate for the scale of machine identities they now have, and 59% face greater difficulty auditing them because ownership and visibility are weak. In practice, teams often discover the weakness only after a secret has been copied into code, logs, or a CI/CD path, rather than through planned governance. See also Guide to the Secret Sprawl Challenge for the operational reality behind that pattern.

How It Works in Practice

For most organisations, the best pattern is to remove long-lived secrets from application logic and replace them with workload identity plus just-in-time access. The application proves what it is, the platform evaluates policy at request time, and a short-lived credential or token is issued only for the specific action. That approach reduces blast radius, improves auditability, and makes revocation practical. The SPIFFE workload identity specification is relevant here because it frames identity as cryptographic proof of workload identity, not as a password hidden in an environment variable.

In a centralised model, secret brokers, vaults, or identity-aware proxies can mediate access so the application never sees the long-term secret. In a decentralised model, the application may retrieve and cache secrets itself, but that raises lifecycle risk: rotation, revocation, and ownership become harder to enforce. NHI Management Group research on the Guide to SPIFFE and SPIRE is useful because it shows how workload identity can support this shift without turning every app into a secret custodian.

• Use workload identity as the primary trust anchor for services, jobs, and agents.
• Issue ephemeral credentials per task or per session, not per application lifetime.
• Keep secrets out of code, configs, and build artifacts whenever the platform can mediate access.
• Log issuance, use, and revocation events so access can be attributed to a specific workload and time.

Current guidance suggests the control plane should own issuance and revocation whenever the workload can function with short-lived access. These controls tend to break down in legacy monoliths, batch jobs with offline dependencies, and third-party integrations that require static credentials because the application cannot yet authenticate as a distinct workload.

Common Variations and Edge Cases

Tighter centralisation often increases platform complexity and can create operational bottlenecks, so organisations must balance consistency against deployment friction. There is no universal standard for this yet, especially where applications are vendor-managed, air-gapped, or tightly coupled to older authentication flows.

One common exception is when a workload must call an external service that only supports static API keys. In that case, keeping the secret inside the application may be unavoidable for now, but it should be wrapped in strict retrieval controls, short rotation windows, and explicit ownership. Another edge case is local development, where engineers sometimes need access to test credentials that do not match production governance. That should remain a constrained exception, not the target operating model.

In practice, the real test is whether the workload can operate without ever holding the secret itself. If yes, centralise control and let the application consume ephemeral proof instead. If no, reduce the secret’s lifetime and exposure as aggressively as possible, because the longer the application retains it, the harder attribution and revocation become.

Related resources from NHI Mgmt Group

• How do organisations decide whether to use a policy-based authorization model or keep permissions inside applications?
• What common vulnerabilities do cloud applications face with OAuth tokens?
• Should organisations centralise secret storage or standardise secret governance first?
• How should organisations centralise password management without breaking legacy applications?