Who is accountable for workload access governance when federated identities are used across cloud and CI systems?

Why This Matters for Security Teams

When federated identities span cloud platforms and CI systems, the real control point is the trust policy that decides who can assume what, from where, and under which conditions. The identity provider may issue the assertion, but it does not own the downstream authorization model. That distinction matters because machine identity sprawl is now a governance problem as much as a technical one, and NHIMG research shows 59% of companies struggle to audit machine identities because of unclear ownership and limited visibility in The Critical Gaps in Machine Identity Management report.

Security teams often get this wrong by treating federation as a point-in-time integration instead of an ongoing control relationship. A GitHub OIDC token, a cloud workload identity, and a CI runner all have different risk profiles, expiry expectations, and audit needs. If the org that approves trust is not explicitly named, nobody owns scope changes, issuer trust, or revocation when repositories are renamed, branches change, or service accounts are reused. Current guidance from the NIST Cybersecurity Framework 2.0 reinforces that governance and access control must be assigned, measured, and reviewed, not implied. In practice, many security teams discover overbroad federated trust only after a CI pipeline or cloud workload has already inherited privileges it should never have had.

How It Works in Practice

Accountability should sit with the organisation operating the trust policy, usually the platform security or cloud security function, with delegated input from application owners and CI platform owners. The identity provider acts as an assertion source, but the relying party owns the authorization decision. That means the team operating AWS, Azure, GCP, Kubernetes, or a CI control plane defines which issuers are trusted, which claims are required, which repositories or branches may authenticate, and which workloads can exchange tokens.

In practical terms, a sound model includes:

• Policy that binds a workload identity to a specific issuer, repository, branch, environment, or service account.
• Short-lived tokens with tight audience and subject constraints, rather than reusable long-lived secrets.
• Regular review of trust mappings, expiration windows, and break-glass paths.
• Audit evidence that shows who approved the trust rule, when it changed, and what it can access.

This is where workload identity patterns such as the SPIFFE workload identity specification help, because they separate the identity of the workload from the credential used to prove it. NHIMG’s Guide to SPIFFE and SPIRE and the Ultimate Guide to NHIs — Regulatory and Audit Perspectives both point to the same operational reality: federated access is only safe when the trust policy is owned, versioned, and reviewed like production code. These controls tend to break down when trust is inherited across multiple orgs or tenants because no single team can see every issuer, claim, and permission path.

Common Variations and Edge Cases

Tighter federated access governance often increases operational overhead, requiring organisations to balance automation speed against review depth and auditability. That tradeoff becomes sharper in multi-cloud or high-churn CI environments, where repositories are created frequently, runners are ephemeral, and service accounts are reused across pipelines. Best practice is evolving here, and there is no universal standard for how much context should be encoded into each trust rule.

Edge cases usually appear when one team owns the identity source and another owns the workload that consumes it. For example, a central IdP team may configure federation templates, but a platform team still owns the actual cloud role mapping and therefore the effective access boundary. The same issue appears with shared CI templates, where a single mis-scoped job token can be inherited by many repositories. NHIMG’s 2024 Non-Human Identity Security Report notes that 35.6% of organisations struggle most with consistent access across hybrid and multi-cloud environments, which is exactly where ownership assumptions tend to fail.

The practical answer is to assign one accountable owner for the trust policy, then require compensating controls for exceptions such as cross-org federation, external contributors, or temporary migration states. The OWASP Non-Human Identity Top 10 is a useful reminder that excessive trust and weak lifecycle control are recurring failure modes, not edge cases. In shared-platform environments, accountability becomes unclear fastest when multiple teams can edit trust rules but none of them owns the audit outcome.

Related resources from NHI Mgmt Group

• Who is accountable for maintaining right-time, right-level access across cloud and business systems?
• Who should be accountable for cleaning up inactive identities across cloud platforms?
• Should organisations prioritise cloud identity governance before expanding privileged access controls across applications?
• How should security teams govern federated access across cloud and SaaS systems?