Who should approve privileged access when JIT becomes the default model?

Why This Matters for Security Teams

When JIT becomes the default model, the approval question shifts from “who owns the account” to “who should trust this specific privilege grant right now.” That matters because static approval chains are built for predictable access patterns, while JIT is meant to reduce standing exposure and narrow the window for misuse. NHI Mgmt Group’s Ultimate Guide to NHIs notes that 97% of NHIs carry excessive privileges, which is exactly why approval discipline cannot be reduced to a formality.

Security teams often get this wrong by routing every request through the same manager or platform owner, regardless of sensitivity. That creates either bottlenecks or rubber-stamp approvals, both of which weaken the control. The better model is risk-based approval: routine, low-risk tasks can be pre-approved through policy, while privileged or unusual access should trigger human review plus fresh authentication. This is aligned with the direction of the OWASP Non-Human Identity Top 10, which treats over-privilege and weak governance as recurring failure modes.

In practice, many security teams discover approval gaps only after a privileged JIT grant has already been used for lateral movement, not through a clean access review.

How It Works in Practice

The approval model should map to the risk of the task, the identity being used, and the environment in which access will occur. For low-risk, repeatable work, current guidance suggests using policy-approved templates so the request can auto-advance if it matches prevalidated conditions. For high-impact access, the workflow should require a named approver, a fresh authentication step, and a clear expiry tied to the task window.

That typically means separating three decision layers:

• Request validation: is the task expected, documented, and within policy?
• Privilege validation: does the requested scope match the minimum needed?
• Context validation: is the request coming from the expected workload, network, or change window?

For NHIs, the approval chain should not be based only on org chart ownership. It should also consider the account’s role in production, whether secrets are stored and rotated correctly, and whether the request aligns with the patterns described in the Ultimate Guide to NHIs. If the access is for an agentic workload, the decision should be made at runtime using policy-as-code and workload context, not a static monthly approval list. That is consistent with NIST’s AI Risk Management Framework principle of managing risk continuously, not just at onboarding.

Operationally, the most defensible approver is usually the person or system best able to attest to task necessity and blast radius, often a service owner plus security for privileged or unusual requests. These controls tend to break down when approval is delegated to a single queue for mixed-risk workloads because the process becomes too blunt to distinguish routine JIT from genuinely sensitive elevation.

Common Variations and Edge Cases

Tighter approval control often increases latency and administrative overhead, so organisations must balance speed against the risk of privilege misuse. That tradeoff is especially visible in incident response, production support, and automation pipelines where delays can hurt availability.

There is no universal standard for who must approve every JIT grant. Best practice is evolving toward tiered approval: business-as-usual access can be policy-approved, operational access can be approved by the service owner, and high-risk elevation should require security or PAM oversight. In environments with strong Zero Trust maturity, approval can also be partially automated when workload identity, request context, and policy-as-code all align. That approach is more defensible when the identity is cryptographically verified and the grant is short-lived, as discussed in CSA MAESTRO guidance and in the NHI governance material from 52 NHI Breaches Analysis.

Edge cases deserve special handling: emergency break-glass access, vendor-supported operations, and agent-driven actions that can chain tools unpredictably. In those cases, approval should be explicit, logged, time-bound, and followed by post-event review. The model fails when organisations try to use one approval path for both routine automation and exceptional privilege escalation, because the governance signal becomes too weak to manage either safely.

Related resources from NHI Mgmt Group

• When does JIT access create more risk than it reduces?
• What breaks when DNS administration is not governed as privileged access?
• Who should own access reviews for privileged REST endpoints?
• Who is accountable when privileged access controls fail in cloud environments?