Who should own JIT access governance across DevOps and IAM teams?

Ownership should sit with the team that can enforce lifecycle controls across the full access path, but it must include DevOps, IAM, and PAM stakeholders. The critical issue is accountability for revocation, auditability, and exception handling. Without shared ownership, temporary access quickly turns back into standing privilege by another name.

Why This Matters for Security Teams

JIT access governance is not just an access-request workflow problem. It is a control-plane issue that determines whether temporary privilege stays temporary or silently becomes another standing entitlement. That is why ownership has to be defined across DevOps, IAM, and PAM boundaries, with a single accountable team for revocation, evidence, and exception handling. NHI Management Group’s analysis of lifecycle risks shows that weak lifecycle discipline is a recurring failure point in Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs and in the Top 10 NHI Issues.

The practical risk is that DevOps teams often automate issuance but not revocation, while IAM teams can define policy but not always see runtime context, and PAM teams may control elevation without owning the underlying workload identity. Current guidance from the NIST Cybersecurity Framework 2.0 points toward shared accountability across governance, protection, and monitoring functions, but there is no universal operating model for JIT ownership yet. In practice, many security teams encounter privilege drift only after an access window was left open, rather than through intentional review.

How It Works in Practice

The cleanest model is to assign a primary owner for JIT governance and then split execution responsibilities. That owner is usually the function that can enforce the full lifecycle: request, approval, issuance, session limits, telemetry, and revocation. In many organisations that means a security platform or IAM operations group, but the operating model matters more than the org chart. DevOps owns the workload context, IAM owns identity policy, and PAM owns privileged elevation controls. A shared RACI is essential because JIT fails when no one owns the teardown.

Practitioners should separate three layers of control:

• Policy definition: who can request access, under what conditions, and for how long.

• Runtime enforcement: whether the access is issued just in time, tied to ticket or pipeline context, and automatically revoked.

• Audit evidence: whether every grant, extension, and exception is logged in a way that satisfies review.

This is where OWASP Non-Human Identity Top 10 and NHIMG’s breach-oriented research help frame the issue: JIT is only effective when the identity is ephemeral, the secret is short-lived, and the revocation path is deterministic. If DevOps pipelines mint credentials but IAM cannot verify expiry or PAM cannot enforce session boundaries, then ownership is nominal rather than real. The result is operational convenience with weak accountability, which is exactly the pattern highlighted in 52 NHI Breaches Analysis.

Best practice is to route every JIT grant through a single control owner, even if approvals are distributed, and to require automatic expiry with no manual extension unless an exception is explicitly re-authorised. These controls tend to break down in fast-moving CI/CD environments because pipeline owners bypass shared governance to keep deployments unblocked.

Common Variations and Edge Cases

Tighter JIT governance often increases delivery friction, so organisations must balance release speed against revocation certainty and audit quality. That tradeoff is especially visible in platform engineering, where teams want self-service access but also need separation of duties. Current guidance suggests that self-service can work if policy is centralised and enforcement is automated, but there is no universal standard for this yet.

Some environments create useful exceptions. For example, a high-trust SRE function may need faster elevation than a traditional ticket queue can support, while regulated systems may require dual approval or immutable logging. In those cases, ownership should still remain singular even if approvals are federated. One team should own the control, and others should supply context, attestations, or approvals.

The hardest edge case is machine-to-machine JIT for non-human identities, where the requester, the workload, and the executing process are all different actors. If the organisation cannot tie access to workload identity, session purpose, and automatic revocation, then JIT degrades into long-lived service access with extra steps. For audit-sensitive programmes, Ultimate Guide to NHIs — Regulatory and Audit Perspectives is the more realistic reference point because it treats evidence, not convenience, as the control objective.

Related resources from NHI Mgmt Group

• Who should own access ticket governance across IT and IAM teams?
• Who should own EHR access decisions across HR, credentialing, and clinical teams?
• How should IAM teams govern access across large connector ecosystems?
• Who should own NHI governance when identity spans security, DevOps, and cloud teams?