What should organisations measure to know whether just-in-time access is actually working during incidents?

Why This Matters for Security Teams

Just-in-time access is only valuable if it reduces standing privilege without slowing incident response to a halt. During real incidents, responders need fast, auditable elevation for a narrow task, then automatic revocation when the task is done. If the process is measured only by approval counts, teams can miss the two failures that matter most: delay at the point of need and lingering privilege after containment.

That matters because non-human identities are already a frequent failure point. NHIMG’s Ultimate Guide to NHIs reports that 97% of NHIs carry excessive privileges, which means incident-time elevation must be tightly bounded to avoid making a bad situation worse. The control also needs to align with current guidance from the OWASP Non-Human Identity Top 10 and NIST control expectations for access governance.

In practice, many security teams discover JIT failure only after responders have already waited on permissions or retained access long after the incident window closed, rather than through intentional measurement.

How It Works in Practice

Effective measurement starts by treating JIT as an operational control, not a policy statement. The core question is whether access is granted quickly enough for incident work and removed fast enough to prevent residual exposure. That means tracking the full request-to-revoke lifecycle, not just whether a ticket existed.

Security teams should measure a small set of incident-specific indicators:

• Request-to-approval delay for emergency access during incidents
• Time from approval to usable access on the target system
• Percentage of privileged sessions that are time-bound and task-scoped
• Revocation latency after task completion or incident closure
• Coverage of immutable audit logs for approvals, session start, and revocation
• Exceptions where access had to be extended because the initial window was too short

For AI-operated or highly automated response workflows, the same logic applies to workload identity and ephemeral credentials. The better model is per-task, short-lived access tied to the workload or agent doing the work, rather than reusable credentials that outlive the incident. Guidance from the NIST SP 800-53 Rev 5 Security and Privacy Controls supports this kind of bounded access design, while NHIMG’s 52 NHI Breaches Analysis shows how quickly identity misuse can become a breach multiplier when access is not tightly controlled.

Current best practice is to define acceptable service levels for emergency access, such as maximum approval delay and maximum revocation delay, then verify them with live incident drills. Teams should also separate “permission to start” from “permission to continue,” because many failures happen after initial approval when access is never automatically rechecked. These controls tend to break down in highly distributed incident response environments where multiple teams share the same elevated roles and revocation depends on manual coordination across tools.

Common Variations and Edge Cases

Tighter incident-time access often increases operational friction, requiring organisations to balance response speed against privilege exposure. That tradeoff becomes sharper in regulated environments, 24/7 operations, and major incidents where multiple responders need overlapping access.

There is no universal standard for exact thresholds yet, so current guidance suggests measuring performance relative to the business-criticality of the system and the severity of the incident. For a production outage, a few minutes of approval delay may be acceptable if access is safely scoped; for a ransomware event, the same delay may be too slow. The important point is consistency: the team should know whether JIT is helping, not assume it is because the policy exists.

Edge cases also matter. Emergency break-glass access should be tracked separately from normal JIT because it is intentionally exceptional. Shared admin accounts make measurement much harder because revocation cannot be tied cleanly to one operator. Multi-step incident workflows can also hide delay if each approval is fast individually but the total path to action is still too long. Where AI agents or automation tools are involved, the issue is even more sensitive because the access may need to be revoked based on task completion, not human sign-off. That is why practitioners increasingly pair JIT with policy-based controls and short-lived credentials rather than relying on static roles alone.

Related resources from NHI Mgmt Group

• How do organisations know whether just-in-time database access is actually working?
• How do organisations know whether their infrastructure access controls are actually reducing risk?
• How do organisations know whether temporary access is actually working?
• How do organisations know whether their access management controls are actually working?