Who is accountable for making just-in-time access work across policy, approvals, and operational use?

Accountability should sit with identity governance, security leadership, and application owners together. Identity teams define policy and controls, business owners approve access based on need, and security teams monitor misuse and exceptions. If one group owns the policy while another owns the workflow, just-in-time access tends to fail at the handoff between governance intent and real operational execution.

Why This Matters for Security Teams

JIT access only works when policy intent, approval decisions, and operational enforcement are treated as one control system. If identity governance approves a ticket but the runtime system cannot issue, constrain, or revoke access fast enough, the result is standing privilege in disguise. That gap is exactly where misuse, over-approval, and delayed revocation turn a good policy into weak practice.

This is why NHI management guidance places lifecycle control and revocation discipline at the centre of operations in the Ultimate Guide to NHIs. The problem is not only access volume. It is also the frequency of privileged secrets, tokens, and service accounts that remain valid long after a task should have ended. NHIMG reports that 71% of NHIs are not rotated within recommended time frames, which shows how easily temporary access becomes durable access.

Security teams often assume the approval workflow is the hard part, but the harder part is operational follow-through: issuance, scoping, logging, and automatic expiry. In practice, many security teams encounter JIT failures only after an overbroad token has already been used, rather than through intentional policy testing.

How It Works in Practice

Accountability for JIT access has to be split by function but unified by outcome. Identity governance owns the policy model: who can request access, what qualifies as need, how long access may last, and what evidence is required for approval. Security leadership owns the control objectives: least privilege, separation of duties, monitoring, and exception handling. Application and platform owners own the operational path that makes the decision real at runtime.

For human users, that means access is granted only after approval and is revoked automatically at expiry. For non-human identities, the same idea usually needs stronger runtime discipline because workloads do not behave like people. Current guidance suggests combining approval workflows with workload identity, short-lived credentials, and policy evaluation at request time. NIST’s Cybersecurity Framework 2.0 and the OWASP Non-Human Identity Top 10 both support least-privilege and continuous control thinking, which is essential when access must be issued for minutes rather than days.

• Policy teams define the JIT rules, including TTL, approver thresholds, and break-glass conditions.
• Application owners expose enforcement points that can mint, scope, and revoke access automatically.
• Security operations monitor use, detect abuse, and review exceptions before they become normalized.
• Audit teams verify that approval, issuance, and revocation all leave a complete trail.

NHIMG’s Lifecycle Processes for Managing NHIs section is especially relevant here because JIT succeeds or fails on lifecycle ownership, not on the ticket alone. These controls tend to break down in legacy systems and shared-service environments because the platform cannot enforce time-bounded access without manual intervention.

Common Variations and Edge Cases

Tighter JIT control often increases operational overhead, requiring organisations to balance speed of access against approval quality and revocation reliability. That tradeoff becomes visible in production support, incident response, and automated pipelines where human approval can slow urgent work.

There is no universal standard for this yet, but current guidance suggests three common patterns. In high-risk environments, security or identity governance may require dual approval for privileged access. In lower-risk operational work, the application owner may approve pre-authorised patterns while security retains exception oversight. In automation-heavy environments, the approval may be expressed as policy-as-code, with runtime checks replacing manual sign-off for routine tasks.

The hardest edge case is when one team owns the policy language and another team owns the secrets store or runtime broker. That split creates a handoff gap where approvals are granted but the actual credential is not constrained to the approved task. NHIMG’s Top 10 NHI Issues and the broader Regulatory and Audit Perspectives discussion both point to the same operational truth: if no single control owner can prove the access was issued, used, and revoked as intended, accountability is effectively fragmented.

That fragmentation is most visible in hybrid estates, CI/CD pipelines, and vendor-managed platforms where approvals exist on paper but enforcement depends on manual human action.

Related resources from NHI Mgmt Group

• Who is accountable when access approvals and review reminders move into collaboration platforms?
• Who should be accountable for access governance when enterprises use a partner to implement identity controls?
• Who is accountable when contractor access is not revoked on time?
• Who is accountable when access reviews are delegated across compliance and resource owners?