Who should be accountable for workload identity governance as teams adopt new standards and patterns?

Accountability should sit with the teams that own the workload and the security functions that set policy, review exceptions, and verify control performance. In practice, that means platform, cloud, IAM, and application owners need shared responsibility, with clear decision rights for identity issuance, secret handling, and access revocation across environments.

Why Accountability Has to Be Shared, Not Assumed

workload identity governance fails when ownership is vague. The workload team understands how the service behaves, the platform team understands how identity is issued and enforced, and the security team defines policy and validates exceptions. NHIMG’s Ultimate Guide to NHIs notes that only 5.7% of organisations have full visibility into service accounts, which makes unclear ownership a direct operational risk, not just a governance gap.

That shared model matters because workload identity is not a one-time setup. It includes issuance, rotation, revocation, secret storage, policy enforcement, and audit evidence across clouds, clusters, CI/CD, and internal services. The control objective is simple: every identity must have an owner who can explain why it exists, what it can reach, and how it is retired. NIST’s Cybersecurity Framework 2.0 reinforces that governance, risk, and control accountability must be explicit, while the NHI reality is that no single team sees the full path of a machine credential. In practice, many security teams discover ownership problems only after a secret leak, certificate expiry, or access review failure has already created an incident.

How Teams Should Divide Governance Responsibilities

Accountability works best when it is split by decision type rather than by organisational label. The workload owner should be accountable for the business purpose of the identity and for approving what the workload needs to do. Platform and cloud engineering should own the technical mechanics of identity issuance, workload registration, runtime binding, and revocation automation. Security or IAM should define policy, minimum standards, and exception handling, then verify that controls are actually working.

In practice, this means defining a simple RACI for each identity lifecycle step:

• Identity creation: workload owner requests, platform team issues, security defines policy constraints.

• Secret handling: platform team enforces storage and rotation patterns, workload owner avoids hardcoded use, security tests for compliance.

• Access changes: workload owner confirms business need, IAM or security approves risk exceptions, platform applies the change.

• Revocation and offboarding: platform automates removal, workload owner confirms retirement, security validates closure.

This is where workload identity primitives help. The SPIFFE workload identity specification gives teams a portable way to express what a workload is, while NHIMG’s Guide to SPIFFE and SPIRE explains why cryptographic workload identity is easier to govern than shared secrets scattered across pipelines and runtimes. The governance model should align to NIST SP 800-53 Rev. 5 control expectations for identification, authentication, and access enforcement, but the operating rule is still local: one owner for the workload, one control owner for the policy, and one evidence owner for auditability.

These controls tend to break down in fast-moving platform environments where teams ship ephemeral workloads across multiple clusters without a central registration or revocation workflow.

Where the Model Breaks Down and What Good Governance Looks Like

Tighter governance often increases coordination overhead, so organisations have to balance speed against control maturity. That tradeoff is especially visible in teams adopting new standards such as SPIFFE, short-lived certificates, or policy-as-code. Current guidance suggests that accountability should move with the workload lifecycle, but there is no universal standard for how to assign that responsibility across every platform.

Edge cases usually appear in three places. First, shared platform services can blur ownership, especially when one team runs the runtime and another team owns the business application. Second, third-party or vendor-managed workloads complicate exception handling because the issuing team may not control the downstream runtime. Third, legacy environments still rely on long-lived secrets, which makes runtime revocation harder and forces compensating controls. NHIMG’s Top 10 NHI Issues and Regulatory and Audit Perspectives both point to the same operational lesson: unclear ownership becomes visible only when inventory, rotation, or audit evidence is requested.

For that reason, mature programmes assign accountable ownership at the workload level, not the tool level. Security sets the rules, platform implements the guardrails, and application owners accept the risk of the identities their software consumes. The practical test is whether a reviewer can answer three questions without guesswork: who issued it, who can revoke it, and who is accountable if it is abused.

Related resources from NHI Mgmt Group

• Who should be accountable for workload identity security across platform, identity, and security teams?
• How do security teams decide whether to prioritise NHI governance, workload identity protection, or identity threat detection first?
• Who is accountable for identity governance outcomes when a global rollout spans multiple regions and teams?
• Who is accountable for hybrid workload identity governance during Windows to Azure migration?