By NHI Mgmt Group Editorial TeamPublished 2026-03-16Domain: Governance & RiskSource: Andromeda Security

TL;DR: Workflow-based JIT access can stall users for minutes to days and encourage approval fatigue, while static pre-approval rules can widen the attack surface when an identity is compromised, according to Andromeda Security. The real governance issue is that access decisions need context, not just a ticket and an inbox.


At a glance

What this is: This analysis argues that workflow-based JIT access is too slow and too rigid, and that context-driven approval models can reduce both requester friction and approver overload.

Why it matters: It matters because PAM, IAM, and IGA teams need to decide how to replace inbox-driven approvals with context-aware controls without turning JIT into another standing-access workaround.

By the numbers:

👉 Read Andromeda Security's analysis of context-driven JIT access


Context

Privileged access management often treats JIT as a workflow problem: a user asks, an approver reviews, and access is granted after a delay. That model can reduce standing privilege, but it still depends on human-paced decisions that are easy to overload and easy to turn into a rubber stamp.

The deeper governance issue is context. Access is safer when the decision reflects role sensitivity, device posture, geo, ticket state, shift status, and request pattern rather than a static rule or an inbox queue. For IAM and PAM teams, the question is no longer whether to use JIT, but what evidence should decide it.

That shift matters across NHI, agentic AI, and human identity programmes because the same lifecycle logic applies: the right actor should get the right privilege for the right duration, with enough context to justify the grant and enough control to avoid broad pre-approval.


Key questions

Q: How should security teams implement JIT access without creating approval bottlenecks?

A: Security teams should use JIT to remove standing privilege while reducing manual touchpoints for low-risk requests. The decision should be based on context such as role, device, geo, ticket state, and request pattern. Requests that fit a narrow trusted profile can be auto-approved, while exceptions should go to a human with full context.

Q: Why do static pre-approval rules increase risk in JIT access models?

A: Static pre-approval rules increase risk because they encode access in advance, before the actual situation is known. If an identity is compromised, the attacker can inherit every resource covered by the rule without fresh validation. The broader the rule, the larger the potential blast radius and the weaker the governance value.

Q: What do teams get wrong about context-driven access decisions?

A: Teams often treat context as a single risk score rather than a set of governance signals. That can hide which factor actually justified the grant and makes escalation decisions harder to audit. Effective programs define which signals are authoritative, which are advisory, and which always require human review.

Q: How do IAM and PAM teams know whether JIT is actually working?

A: Look for shorter approval times, fewer unnecessary escalations, lower approval fatigue, and a smaller number of broadly pre-approved access paths. If users are still waiting long enough to create anticipatory requests, or if reviewers are approving without context, the control is not functioning as intended.


Technical breakdown

Why workflow-based JIT creates approval debt

Traditional JIT systems still depend on a workflow engine that pauses execution until a human approves. That delay creates two failure modes: requester frustration, which drives anticipatory requests, and approver fatigue, which turns security review into compliance theatre. The access request becomes a paper trail rather than a control point. In practice, the workflow is not the security decision. It is only the container around a decision that may already be too late or too shallow to matter.

Practical implication: measure approval latency and rubber-stamp rates before treating JIT as a genuine control.

How context-driven access decisions work

Context-driven JIT replaces static pre-approval with a risk decision built from multiple signals. Those signals can include role sensitivity, business criticality, data sensitivity, trusted geo, device baseline, historical frequency, peer clustering, ticket state, and on-call status. The technical shift is from binary allow or deny logic to a multi-factor confidence assessment. That is still access governance, but it is governed by evidence rather than by one-size-fits-all policy text.

Practical implication: define which context signals are authoritative, which are advisory, and which must always trigger human review.

Static pre-approval rules and their blast radius

Static pre-approval looks efficient because it removes the approver from the loop, but it also creates a predictable path for abuse. If a compromised identity inherits a broad rule such as time-bound access to a role, the attacker can enumerate every resource covered by that rule without needing fresh approval. The problem is not JIT itself. The problem is substituting a blanket rule for a decision that should remain conditional on context. That turns a least-privilege pattern into a pre-authorised access lane.

Practical implication: restrict pre-approval to narrow, well-defined scenarios and review the full set of resources each rule unlocks.



NHI Mgmt Group analysis

Workflow-based JIT is an approval problem disguised as a security control. When access decisions wait on human inboxes, the process optimises for throughput rather than governance. That produces anticipatory requesting, reviewer overload, and shallow approvals that satisfy audit trails but do not materially reduce risk. For IAM and PAM teams, the key failure mode is approval debt, where the control exists in policy but loses value in practice.

Context-driven JIT is the right direction because access decisions should be evidence-led, not queue-led. The article’s strongest point is that role sensitivity, business criticality, device posture, geo, request frequency, and ticket state are all legitimate decision inputs. That is consistent with Zero Trust thinking and with NIST CSF access governance principles. The practical conclusion is that the decision engine needs richer context, not broader standing access.

Static pre-approval creates an identity blast radius that is larger than the request itself. A rule that grants access based on a role, a time window, or a name can be exploited once the identity is compromised, because the attacker inherits every resource the rule covers. That is a control gap in the literal sense: the grant is too broad to remain safe after compromise. Practitioners should treat the rule set as an attack surface.

JIT for human access and JIT for machine access are converging governance problems. The same pressure exists in service-account and workload workflows, where teams want speed without standing privilege. The lesson is not to copy human approval models into machine access, but to decide which context signals can safely replace manual review and which must remain explicit governance boundaries. The implication is that lifecycle design must be actor-specific, not workflow-specific.

From our research:

  • The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
  • Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to GitGuardian & CyberArk.
  • That gap matters because governance models that depend on human process discipline collapse when access decisions, secrets handling, and review cycles drift out of sync, as explored in the NHI Lifecycle Management Guide.

What this signals

Context-driven JIT will push more organisations to treat access decisions as policy plus telemetry, not policy alone. The practical signal is that PAM and IAM teams will need stronger integrations with device posture, ticketing, and shift systems so that fast approval does not become broad pre-authorisation by another name.

Approval debt: when users wait long enough to start requesting access in advance, the governance model is already shaping behaviour. Teams should watch for this pattern in global organisations where approvers and requesters operate across time zones, because delay is often the first sign that a control is being bypassed socially rather than technically.

The next step for mature programmes is to align JIT with access review and lifecycle design so that temporary access stays temporary in practice, not just in policy. That means using lifecycle controls to verify who can grant, when they can grant, and what gets revoked after the task ends.


For practitioners

  • Map your approval debt Measure median approval time, escalation frequency, and the share of requests approved without meaningful context. If the queue is the control, the queue metrics will tell you whether JIT is actually reducing risk or just moving it.
  • Define authoritative context signals Classify which signals can drive automatic grant, which require secondary review, and which must always force human approval. Treat geo, device posture, ticket state, on-call status, and request frequency as separate decision inputs, not one blended risk score.
  • Constrain pre-approval rules tightly Review every static pre-approval rule for the full set of resources it unlocks, then shrink any rule that behaves like broad standing access in disguise. A safe rule should be narrow enough that compromise does not create a large lateral movement path.
  • Separate requester speed from approver quality Give routine requests a fast path only when the context is strong enough to justify it, and route uncertain requests with a concise contextual briefing. That keeps human review for the cases that actually need judgment while avoiding approval fatigue.

Key takeaways

  • Workflow-based JIT often shifts the bottleneck from privilege exposure to approval fatigue, which weakens the control’s real security value.
  • Context-driven access decisions work better when they use multiple governance signals, including role, ticket state, device posture, and request history.
  • Static pre-approval rules should be narrow and explicit, because broad rules can turn a compromise into a large pre-authorised access path.

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.

FrameworkControl / ReferenceRelevance
OWASP Non-Human Identity Top 10NHI-03Addresses risky credential and access lifecycles in JIT-style governance.
NIST CSF 2.0PR.AC-4Access permissions should reflect least privilege and contextual validation.
NIST Zero Trust (SP 800-207)AC-3Zero Trust requires continuous verification before granting privileged access.

Require evidence-based authorisation for each privilege elevation, not just a workflow trigger.


Key terms

  • Just-in-time access: Just-in-time access is a pattern where elevated privilege is granted only when it is needed and for only as long as it is needed. In practice, it is a control for reducing standing privilege, but its security value depends on how the grant decision is made and how narrowly the resulting access is scoped.
  • Approval fatigue: Approval fatigue is the tendency for reviewers to approve access requests quickly, with minimal scrutiny, because the queue is too large, the context is too thin, or the request seems routine. It weakens governance by turning human review into an administrative habit rather than a meaningful decision point.
  • Pre-approval rule: A pre-approval rule is a policy that allows access automatically when predefined conditions are met, such as a role, time window, or resource class. It can improve speed, but it also creates a larger attack surface if the rule is too broad or survives changes in the identity’s risk profile.
  • Context-driven access decision: A context-driven access decision uses current evidence about the requester, device, environment, and business justification before granting privilege. It is stronger than simple workflow automation because it evaluates whether the request is appropriate now, not just whether the request matches a stored rule.

What's in the full article

Andromeda Security's full article covers the operational detail this post intentionally leaves for the source:

  • The exact decision signals the Approver-AI-Agent evaluates before granting or escalating access.
  • Examples of how business criticality, trusted geo, and trusted device inputs are combined in routing decisions.
  • The article's description of how risky requests are packaged for human review with contextual explanations.
  • The planned integrations with external posture and XDR signals that extend the approval model.

👉 Andromeda Security's full post covers the approval model, signal inputs, and escalation logic in more detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
NHIMG Editorial Note
Published by the NHIMG editorial team on 2026-03-16.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org