Ownership should sit with the identity governance and PAM function, with clear operational responsibility in the systems team that grants access. If request, approval, and revocation are split across too many teams, accountability becomes unclear and the control weakens. The accountable team must be able to show who approved, who used, and who removed the access.
Why This Matters for Security Teams
JIT access only works when ownership is unambiguous. The moment request handling, approval, provisioning, and revocation are split across identity governance, PAM, and platform teams without a single accountable function, the control becomes hard to evidence and easy to bypass. That matters because NHIs already carry excessive privilege in many environments, and standing access is often left in place longer than intended, which is exactly the pattern NHI Management Group highlights in the Ultimate Guide to NHIs. OWASP also treats weak lifecycle control as a core non-human identity failure mode in the OWASP Non-Human Identity Top 10.
Security teams often assume “shared responsibility” means shared ownership, but that usually creates gaps in audit trails, delayed revocation, and unclear exception handling. The accountable team must be able to answer who approved the access, what context justified it, when it expired, and who verified removal. In practice, many security teams encounter lingering access only after a service account abuse incident or a failed offboarding review, rather than through intentional control testing.
How It Works in Practice
The cleanest operating model is to make identity governance or PAM the control owner, with the system team that grants access as the operational executor. That split preserves accountability without diffusing it. Identity governance should define policy, approval paths, evidence retention, and review cadence. PAM or the access broker should enforce the session, issue the credential, and revoke it automatically at the end of the approved window.
For JIT to be defensible, the process should be event-driven and time-bound:
- A request is tied to a specific workload, ticket, or change record.
- Approval happens before issuance, with the approving role recorded.
- Access is issued as an ephemeral credential or short-lived session.
- Revocation is automated on expiry, task completion, or policy violation.
- Logs show who used the access, from where, and for what action.
This aligns with the broader direction of zero trust and workload identity, where access decisions are made from context rather than static role membership. NHI Management Group’s research on Ultimate Guide to NHIs — Key Challenges and Risks shows how excessive privilege and weak revocation are recurring failure points. NIST SP 800-207 Zero Trust Architecture and the OWASP Non-Human Identity Top 10 both reinforce the need for least privilege, continuous verification, and explicit authorization boundaries.
These controls tend to break down when access is granted through ad hoc break-glass paths, because the approval chain is bypassed and revocation evidence becomes incomplete.
Common Variations and Edge Cases
Tighter JIT ownership often increases operational overhead, requiring organisations to balance speed of remediation against the need for reliable evidence and revocation. That tradeoff is real, especially in production support, incident response, and regulated change windows.
There is no universal standard for exactly how much authority the platform team should hold during emergency access. Current guidance suggests the platform team may execute the action, but it should not own the policy that justifies it or the audit record that proves it. In high-risk environments, dual control or secondary approval is often appropriate, while low-risk maintenance tasks may use pre-approved policy templates with automatic expiry.
Edge cases also appear when access spans multiple systems. If one team owns request approval and another owns token revocation, accountability becomes fragmented unless the process enforces a single case record. A mature model keeps ownership with one governance function and assigns system-level teams the duty to execute and evidence the action. That is especially important where service accounts, API keys, and CI/CD credentials are involved, because revocation lag is a common source of residual exposure. In practice, the strongest control is the one that can prove not just who asked for access, but who removed it and when.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | JIT ownership depends on strong lifecycle control and timely revocation of non-human credentials. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access management is central to making JIT approvals and revocation accountable. |
| NIST Zero Trust (SP 800-207) | SC-1 | Zero trust requires explicit, context-based authorization rather than standing trust for access decisions. |
Assign one owner for NHI lifecycle actions and enforce automated expiry, revocation, and audit evidence.
