Who should approve just-in-time access requests when both security and business owners are involved?

Why This Matters for Security Teams

Just-in-time access only works when approvals are tied to the actual task, the expected duration, and the risk of the target system. If both security and business owners are involved, confusion usually appears at the approval boundary: business leaders know why access is needed, while security knows when the request crosses into privileged change, separation-of-duties, or regulatory territory. That distinction matters because NHI misuse often happens through ordinary operational workflows, not dramatic intrusions.

NHIMG’s Ultimate Guide to NHIs notes that 97% of NHIs carry excessive privileges, which is a strong reminder that approval design is not a paperwork exercise. Current guidance in the OWASP Non-Human Identity Top 10 also points to privilege sprawl and weak governance as recurring failure modes. In practice, many security teams encounter approval ambiguity only after an elevated request has already been granted and logged as “temporary” without clear revocation ownership.

How It Works in Practice

The usual operating model is a split decision. The resource owner approves the operational need because they understand the workflow, the system dependency, and whether the access is actually required. Security sets the guardrails for who may approve, what can be approved, how long access lasts, and which request types require escalation. That aligns with CISA Zero Trust Maturity Model principles and with the broader NHI governance emphasis in The State of Non-Human Identity Security.

Practitioners usually implement this through policy-based routing rather than a single universal approver. For example:

• Low-risk, pre-approved tasks go to the resource owner only.
• Privileged, production, or sensitive data access requires resource owner approval plus security review.
• Separation-of-duties cases require an independent approver, often a control owner or platform security lead.
• JIT access is time-boxed, automatically revoked, and revalidated if the task changes.

This works best when the approval workflow is backed by clear entitlement boundaries, ticket linkage, and audit evidence. For agentic or highly dynamic workloads, current best practice is evolving toward runtime policy evaluation rather than static request templates, because the request may change once the system starts executing. These controls tend to break down in environments with shared service accounts, unclear asset ownership, or emergency operations where the “business owner” is not actually available to confirm the task.

Common Variations and Edge Cases

Tighter approval control often increases delay and coordination cost, so organisations have to balance speed against assurance. That tradeoff is real, especially when the requester is a platform team supporting multiple applications or when the access spans cloud, CI/CD, and production data paths.

There is no universal standard for this yet, but current guidance suggests a tiered model. Resource owners should approve ordinary operational access, while security should approve exceptions, privileged changes, and requests that could weaken segregation of duties. For recurring JIT requests, the safer pattern is to predefine policy and thresholds instead of asking humans to reinterpret risk every time. NHIMG’s Guide to NHI Rotation Challenges is also relevant here because approval and revocation must stay synchronized, or the temporary grant quietly becomes standing access.

Edge cases include outsourced operations, shared production support, and machine-to-machine workflows where no single business owner fully understands the request. In those cases, approval should shift from individual discretion to documented policy, with security defining what “allowed” means and what requires escalation. For higher-risk environments, the answer is not “more approvers” but clearer approval authority, shorter access windows, and stronger post-approval monitoring.

Related resources from NHI Mgmt Group

• How should security teams run access reviews for non-human identities?
• How should security teams govern non-human identities that have persistent access?
• When do NHI access reviews create more value than a one-time cleanup?
• How should security teams make NHI best practices usable across the business?