They should manage workload identity as a shared control plane, with platform teams owning runtime attestation and transport security and IAM teams owning client policy, token issuance, and trust rules. If those responsibilities are split without an agreed operating model, assurance gaps appear between deployment and authorisation.
Why This Matters for Security Teams
workload identity fails when it is treated as either a platform concern or an IAM concern instead of a shared control plane. Platform teams usually control the runtime, deployment pipeline, service mesh, and node trust, while IAM teams control policies, token issuance, and federation. If those boundaries are not explicit, no one owns the full chain from attestation to authorisation, and machine identities drift into shadow territory.
This is not a theoretical gap. NHI programs often struggle because ownership is unclear and the operational model is split across teams. NHI Management Group’s Critical Gaps in Machine Identity Management report found that 59% of companies face greater difficulties auditing machine identities because of lack of clear ownership and limited visibility. That is exactly where shared responsibility breaks down in practice. The Ultimate Guide to NHIs — Standards also reinforces that workload identity needs consistent policy and lifecycle control, not just credentials.
In practice, many security teams encounter workload identity failures only after a deployment, certificate, or token problem has already become an outage or an access incident, rather than through intentional governance.
How It Works in Practice
The cleanest operating model is to treat workload identity as a shared system with separate duties, not shared ambiguity. Platform engineering owns what can be proven about the workload at runtime: where it runs, whether it is healthy, what environment it belongs to, and whether its transport is protected. IAM owns who or what may receive trust, under what conditions, and with what claims. The boundary is enforced through runtime attestation and policy evaluation, not through static approvals alone.
In mature designs, the workload proves its identity with cryptographic evidence aligned to the SPIFFE workload identity specification, then receives short-lived credentials or tokens only after policy checks pass. That allows IAM to define trust rules such as environment, namespace, workload type, or service account, while platform teams ensure the workload is actually running in the expected place. For many organisations, this also means moving away from static secrets toward ephemeral issuance and automated revocation, a pattern echoed in Guide to SPIFFE and SPIRE.
- Platform teams should own attestation signals, runtime controls, service mesh posture, and secure transport.
- IAM teams should own token brokers, trust policies, federation rules, and issuance conditions.
- Both teams should agree on a single source of truth for workload registration and identity lifecycle.
- Policy should be evaluated at request time, with revocation and rotation designed into the flow.
The practical test is whether a workload can be deployed, rotated, or rescheduled without breaking identity guarantees or creating a manual exception path. These controls tend to break down in hybrid and multi-cloud environments because runtime signals, policy engines, and certificate lifecycles are rarely governed consistently across platforms.
Common Variations and Edge Cases
Tighter workload identity control often increases coordination overhead, requiring organisations to balance speed of delivery against the need for explicit ownership and auditability. That tradeoff becomes sharper in large Kubernetes estates, service mesh deployments, and multi-cloud environments where the same workload may move across clusters, accounts, or tenants.
Best practice is evolving, but current guidance suggests three common variants. First, platform-led implementation with IAM approval works well when the runtime environment is highly standardised. Second, IAM-led trust governance with platform-enforced attestation fits regulated environments where policy consistency matters more than deployment freedom. Third, a federated model is often required when business units operate their own platforms but must still conform to enterprise trust rules. The right answer depends on whether the organisation can keep policy, telemetry, and credential lifecycle aligned without manual tickets.
Edge cases usually appear when workloads are ephemeral, cross-domain, or third-party managed. In those cases, ownership of the identity proof, token exchange, and revocation path must be documented before production. The 2024 Non-Human Identity Security Report found that only 19.6% of security professionals express strong confidence in their organisation’s ability to securely manage non-human workload identities, which helps explain why shared operating models matter so much. The same report also shows 88.5% of organisations acknowledge their non-human IAM practices lag behind or are merely on par with human IAM, underscoring that workload identity maturity is still uneven.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on July 6, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
