Who should own just-in-time access governance for infrastructure identities?

Why This Matters for Security Teams

Just-in-time access governance only works when ownership is explicit, because the control spans approval, policy enforcement, telemetry, and revocation across platforms that rarely share the same operating model. When IAM owns policy but cloud teams own the actual privilege path, delays and exceptions quickly appear. That is why NHI Management Group consistently frames lifecycle control as a joint responsibility, especially for infrastructure identities that behave more like workloads than users.

The issue is not only process ownership. It is also the speed at which access must be granted and removed without creating standing privilege. Static admin access is still common, but it is the wrong default for cloud infrastructure, machine identities, and automation pipelines. Current guidance from the OWASP Non-Human Identity Top 10 and NHIMG research on Top 10 NHI Issues points to the same failure pattern: access is usually over-granted first and reviewed later, if at all.

In the The 2026 Infrastructure Identity Survey, 67% of organisations still rely heavily on static credentials despite the risks they pose to agentic AI deployments. In practice, many security teams encounter privilege sprawl only after an incident has already forced a postmortem rather than through intentional access design.

How It Works in Practice

Operationally, just-in-time governance for infrastructure identities should be treated as a control plane problem, not a one-time approval workflow. IAM defines who can request access, PAM enforces privilege elevation boundaries, cloud platform teams integrate the control into orchestration, and security owns auditability, thresholds, and exception review. That division of labour is important because the person approving access is often not the team capable of revoking it in the target environment.

The practical model is to issue short-lived access based on request context, not standing role membership. For example, an engineer, service account, or agent can receive access only for a task, with automatic expiry and revocation on completion. The underlying identity should be a workload identity or equivalent cryptographic proof of what the entity is, while authorisation is evaluated at request time against policy as code. NIST’s Cybersecurity Framework 2.0 supports this kind of accountable access governance, while NHIMG’s Ultimate Guide to NHIs, Lifecycle Processes for Managing NHIs reinforces that lifecycle ownership must include issuance, rotation, logging, and retirement.

• IAM sets policy for eligibility and request routing.
• PAM enforces elevation, session boundaries, and revocation triggers.
• Platform teams wire JIT controls into cloud and infrastructure tooling.
• Security validates logging, reviews exceptions, and tests revocation.

This works best when access is measured in minutes or hours, not days, and when every grant is tied to a ticket, workflow, or automation event that can be audited end to end. These controls tend to break down in highly automated environments with brittle legacy admin paths because access can be re-created outside the JIT workflow faster than it can be revoked.

Common Variations and Edge Cases

Tighter JIT access often increases operational overhead, requiring organisations to balance speed of delivery against the need to prevent standing privilege. That tradeoff is real, especially where infrastructure teams need emergency access, cross-account cloud operations, or non-interactive machine-to-machine workflows.

For human administrators, current guidance suggests using approval gates plus session recording. For service accounts and machine identities, best practice is evolving toward ephemeral secrets, workload identity federation, and runtime policy evaluation instead of shared credentials. There is no universal standard for this yet, which is why ownership should be defined in operating terms rather than by a single tool team. NHIMG’s Ultimate Guide to NHIs, Regulatory and Audit Perspectives is useful here because auditors typically ask who approved, who enforced, and who could revoke the access, not just who documented the policy.

Edge cases become especially difficult when agents or automation can chain privileges across systems. The 2026 Infrastructure Identity Survey found that only 13% of organisations feel extremely prepared for agentic AI, which aligns with the reality that governance often lags automation. In those environments, ownership should sit with a cross-functional control owner for the JIT program, with IAM, PAM, platform, and security each accountable for a specific control outcome.

Related resources from NHI Mgmt Group

• Who should own access governance when IT infrastructure is scaling quickly?
• Why do SSO tools often fail to solve access governance on their own?
• Who should own SaaS governance when access, licensing, and renewals overlap?
• Why do authentication tools fail to solve access governance on their own?