Who should own JIT governance across cloud and workload identities?

Why This Matters for Security Teams

JIT governance fails when it is treated as a narrow provisioning task instead of an operating model for both cloud and workload identities. If the wrong team owns it, temporary access becomes either too slow for engineering teams or too broad for auditors to defend. Current guidance suggests the control boundary must cover approval logic, entitlement hygiene, and revocation timing across people and machine identities, not just one side of the house. That is why identity architecture, IAM, PAM, cloud platform, and workload identity teams all need explicit decision rights, with clear escalation paths.

The risk is not theoretical. NHIMG research in the The 2026 Infrastructure Identity Survey found that 67% of organisations still rely heavily on static credentials despite the risks they pose to agentic AI deployments. That is a strong signal that ownership gaps quickly become exposure gaps. For the technical baseline, the NIST Cybersecurity Framework 2.0 reinforces that access governance must be managed as an operational capability, not a one-time approval.

In practice, many security teams encounter standing access sprawl only after an audit finding or an incident has already exposed how loosely JIT was governed.

How It Works in Practice

Effective JIT ownership starts with one accountable function, usually IAM or identity architecture, then federates implementation to the teams that control the underlying identity types. That owner defines the policy model, while PAM, cloud, and workload identity teams implement the lifecycle rules for their platforms. For workload identities, the control plane should favor short-lived cryptographic identity over static secrets, using patterns such as the SPIFFE workload identity specification where appropriate.

Practitioners usually separate governance into four decisions:

• Who can approve JIT access, and under what business justification
• Which entitlements are eligible for temporary elevation
• How long the grant lasts, and what automatically revokes it
• How the event is logged, reviewed, and linked to audit evidence

For cloud identities, ownership often sits with the platform team for implementation and IAM for policy control. For workload identities, the platform or SRE function may operate the runtime, but the identity team should still own lifecycle standards, secret TTL, and revocation requirements. That split matters because workload identity issuance needs to align with service deployment, not human ticketing delays. NHIMG’s Guide to SPIFFE and SPIRE is useful here because it frames identity as a workload-native control, not a password replacement. The practical target is simple: policy at the centre, execution at the edge, and evidence captured at every grant and revoke event. These controls tend to break down in fast-moving CI/CD environments because ephemeral services can outlive their tickets and leave approvals disconnected from actual runtime access.

Common Variations and Edge Cases

Tighter JIT governance often increases operational overhead, so organisations have to balance speed against the risk of over-privilege. That tradeoff becomes sharper in hybrid estates where human admin access, cloud roles, and service accounts are all elevated through different mechanisms. Current guidance suggests there is no universal standard for ownership in these mixed environments, but the accountable owner must still define the policy boundary and the audit boundary, even if implementation is shared.

One common edge case is when application teams create their own service principals or API keys to avoid ticketing friction. That is not really JIT, even if the credential rotates occasionally. Another is incident response, where short-term exceptions are legitimate but should still be time-boxed, reviewed, and fully traceable. NHIMG’s Top 10 NHI Issues and Ultimate Guide to NHIs — Regulatory and Audit Perspectives both support this view: the ownership model must survive exceptions, mergers, and inherited cloud estates. The best practice is evolving, but the principle is stable: if no single owner can explain how a JIT grant is approved, bounded, and revoked across both human and machine identities, the control is already too weak for real-world assurance.

Related resources from NHI Mgmt Group

• Who should own identity governance when it spans cloud and enterprise systems?
• Who should own access governance in cloud-native environments?
• How do JIT controls change IAM and PAM governance for cloud workloads?
• Who should own NHI governance when identity spans security, DevOps, and cloud teams?