Who should own the risk when secrets storage and workload identity both matter?

Why This Matters for Security Teams

When secrets storage and workload identity both matter, the risk is not just technical ownership but operational ambiguity. Secrets stores control where credentials live, while workload identity controls whether a runtime can prove who it is and obtain access at the moment of use. If those boundaries are unclear, teams overprotect storage and underinvest in runtime access decisions, which is where most abuse occurs.

This is a recurring pattern in non-human identity governance. NHIMG research on Ultimate Guide to NHIs shows that 97% of NHIs carry excessive privileges, and 79% of organisations have experienced secrets leaks. That combination turns a custody problem into a blast-radius problem. Current guidance suggests treating custody and runtime authorisation as separate control domains, not competing responsibilities. The OWASP Non-Human Identity Top 10 reinforces that identity risk is often created by how credentials are issued, stored, and reused, not just by where they are saved.

In practice, many security teams encounter a control failure only after a leaked secret is reused faster than incident response can revoke it, rather than through intentional ownership design.

How It Works in Practice

The cleanest operating model is to separate custody, issuance, and runtime enforcement. Secrets storage teams own vault policy, encryption, backup, retention, and emergency revocation. Platform or identity teams own the workload identity plane, including cryptographic proof of workload identity and policy evaluation at request time. Application owners should know which service is allowed to request access, but they should not be manually distributing long-lived secrets.

In modern deployments, this usually means short-lived credentials, workload-bound tokens, and explicit trust between the workload and the access broker. The SPIFFE workload identity specification is a useful reference for proving workload identity without relying on static shared secrets. For secret lifecycle and exposure trends, NHIMG’s Guide to the Secret Sprawl Challenge documents how organisations keep credentials in code, CI/CD, and config paths that are hard to govern.

• Secrets storage owns where secrets are created, encrypted, rotated, and revoked.
• Workload identity owns how a runtime proves itself and requests access in context.
• Policy-as-code should decide whether a request is allowed at runtime, not a static RBAC mapping alone.
• JIT issuance should reduce standing exposure by issuing credentials only for the task and the shortest feasible TTL.

The NIST Cybersecurity Framework 2.0 supports this split by pushing organisations to define governance, protection, and response responsibilities clearly. These controls tend to break down when legacy services require shared API keys, because the runtime cannot reliably distinguish one caller from another.

Common Variations and Edge Cases

Tighter control over both vaulting and workload identity often increases engineering overhead, requiring organisations to balance stronger blast-radius reduction against delivery speed and migration cost. That tradeoff is real, especially when teams are replacing static credentials in brownfield systems or when multiple platforms share the same secret source.

There is no universal standard for who must own the full risk end to end. Best practice is evolving toward a split model: the secrets team owns the storage control, the platform or identity team owns runtime attestation and token exchange, and the application team owns correct integration. Where environments use multi-cloud, batch jobs, or third-party automation, governance should focus on the handoff between static credentials and ephemeral access rather than a single system of record. NHIMG’s Top 10 NHI Issues is especially relevant here because ownership gaps often appear alongside weak inventory and incomplete rotation. In long-lived hybrid environments, the model can fail when service accounts are shared across workloads or when access is granted before the workload identity signal is trustworthy enough for real-time policy decisions.

Related resources from NHI Mgmt Group

• Why do collaboration tools create such a large secrets risk?
• Why do leaked secrets remain such a persistent NHI risk?
• What makes idle secrets such a serious NHI risk?
• When does secret exposure become a broader identity risk?