JIT access reduces exposure but leaves standing trust intact

TL;DR: Just-in-time access reduces the lifetime of a credential, but it does not remove the trust assumptions behind the non-human identity requesting it, according to Entro Security. For IAM and NHI programmes, the real control problem is not expiration speed but whether the issuer, workload, or automation path can be trusted at request time.

At a glance

What this is: This is an analysis of why JIT access shortens credential exposure but does not, by itself, solve the trust problem in NHI governance.

Why it matters: IAM and NHI teams need to treat ephemeral credentials as one control layer, not a complete Zero Trust model, because compromised issuers can still mint valid access on demand.

By the numbers:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.

👉 Read Entro Security's analysis of the JIT paradox and NHI Zero Trust

Context

Just-in-time access is a time-bounded access model that reduces how long a credential can be used, but it does not automatically make the requesting non-human identity trustworthy. In NHI governance, that matters because service accounts, CI/CD runners, and workload identities can still become the path through which fresh privilege is requested and abused.

The core governance gap is not whether access expires, but whether the identity, broker, or automation path requesting access should be trusted at that moment. That is why JIT can lower blast radius while still leaving standing assumptions in place, which is a familiar pattern in modern NHI security programmes and, for many teams, an atypical level of enforcement maturity.

Key questions

Q: How should security teams govern just-in-time access for non-human identities?

A: Security teams should treat JIT as a timing control, not a trust control. Require contextual checks on the issuer, workload, and requested resource before granting access, and define deny rules for identities that behave outside baseline patterns. That approach limits abuse while preserving production continuity.

Q: Why does ephemeral access still create risk for NHI programmes?

A: Ephemeral access still creates risk because the mechanism that issues it can be compromised. If a service account, runner, or broker can request fresh privilege on demand, attackers may not need to steal long-lived secrets at all. The risk shifts from credential lifetime to issuance trust.

Q: What is the difference between JIT access and Zero Trust for NHIs?

A: JIT shortens the duration of privilege, while Zero Trust for NHIs validates whether the requesting identity should receive privilege in the first place. In practice, JIT answers how long access should last, but Zero Trust answers whether access should be granted now. Both are needed for machine identity governance.

Q: When does JIT access create more risk than it reduces?

A: JIT creates more risk than it reduces when the same compromised issuer can repeatedly mint valid access across multiple systems. In that case, the organisation has removed persistence from the credential but preserved persistence in the trust path. That is where blast radius grows instead of shrinking.

Technical breakdown

Why ephemeral credentials do not remove NHI trust assumptions

Ephemeral credentials change the duration of access, not the trust model that allows access to be issued. In a JIT flow, some issuer such as a token service, cloud policy, broker, or pipeline controller evaluates a request and mints temporary privilege. If the issuer, the automation path, or the non-human identity itself is compromised, the attacker can keep requesting fresh access that still looks legitimate. The real architectural weakness is upstream of the token, where authorization decisions are made repeatedly rather than permanently. That is why short-lived secrets are useful but insufficient on their own.

Practical implication: Treat the issuer and request path as first-class control points, not just the credential lifetime.

What the JIT paradox means for Zero Trust architecture

Zero Trust architecture assumes no implicit trust, but many JIT deployments still assume that the identity requesting access is trustworthy enough to deserve dynamic privilege. That creates a paradox. The access is temporary, yet the trust is standing. Proper Zero Trust for NHIs requires continuous evaluation of context such as expected behaviour, consumer identity, resource sensitivity, and policy drift before access is granted or renewed. Without that layer, JIT only narrows the window of abuse while preserving the same authorization assumptions that attackers can exploit.

Practical implication: Add contextual verification before each privilege grant so Zero Trust applies to machines as well as humans.

How attackers abuse the factory that mints access

Defenders often watch the token, but attackers increasingly target the factory that produces it. If a CI/CD runner, workload identity, integration layer, or service account can request privileged access on demand, compromising that component gives the attacker a cleaner route than stealing a static secret. The resulting actions can blend into normal operations because the access was issued through an expected mechanism. This is why machine identity governance must focus on the lifecycle and behaviour of the entities that generate access, not only the secrets they consume.

Practical implication: Map and harden every identity that can mint privilege, then monitor for abnormal issuance patterns.

Threat narrative

Attacker objective: The attacker wants on-demand privileged access that looks legitimate enough to bypass normal operational scrutiny.

1. Entry via compromise of a trusted intermediary such as a CI/CD runner, integration layer, or service account that can request fresh privilege.
2. Escalation by abusing the mechanism that mints temporary access, which produces valid credentials that appear operationally normal.
3. Impact through legitimate-looking privileged actions that blend into approved workflows and reduce the chance of immediate detection.

NHI Mgmt Group analysis

JIT is a necessary control, but it is not a complete trust model for NHIs. Short-lived access reduces exposure, yet the deeper risk sits in the request path that issues the privilege. If that path remains trusted by default, the organisation has merely shortened the abuse window rather than removed the abuse condition. Practitioners should treat JIT as a control layer inside a broader NHI governance model, not as the model itself.

The JIT paradox exposes a standing trust debt in machine access design. Organisations often remove long-lived secrets while preserving the same automation, broker, and workload assumptions that let attackers request new access on demand. That is especially dangerous in cloud and AI-driven environments where identities are numerous, dynamic, and difficult to baseline. The practical conclusion is simple: remove implicit trust from the grant process, not just from the credential lifespan.

Zero Trust for NHIs must verify behaviour at issuance time, not only at use time. If an identity, runner, or integration can request privilege, its current context matters as much as the role it was assigned last quarter. Behavioural context, expected consumers, resource sensitivity, and policy thresholds are what keep temporary privilege from becoming a standing invitation. Teams that ignore issuance context will keep finding that ephemeral access still behaves like persistent risk.

Identity blast radius is the right concept for this problem. The issue is not only how long a credential lives, but how far a compromised requester can reach before controls intervene. Once a brokered identity can mint access across multiple systems, the blast radius expands beyond the original secret. NHI governance should therefore measure how many downstream privileges each issuing identity can affect, then reduce that surface before attackers do.

Machine identity programmes need enforcement, not just visibility. Many teams can now detect risky NHIs, but detection without safe enforcement leaves the same exposure in place. The organisations that mature fastest will be the ones that combine visibility, contextual authorization, and narrow deny logic so that risky behaviour is contained before it becomes production impact. That is the operational meaning of Zero Trust in machine identity environments.

From our research:

• Only 19.6% of security professionals express strong confidence in their organisation's ability to securely manage non-human workload identities, according to The 2024 Non-Human Identity Security Report.
• 23.7% of organisations share secrets through insecure methods such as email or messaging applications, according to The 2024 Non-Human Identity Security Report.
• For a broader control baseline, review Ultimate Guide to NHIs and compare your access issuance model against lifecycle governance requirements.

What this signals

JIT adoption will not materially improve NHI governance if organisations continue to trust issuers by default. The next phase of programme maturity is to align access issuance with behavioural context, lifecycle state, and explicit policy thresholds so that temporary privilege cannot be minted from untrusted conditions.

Ephemeral trust debt: this is the gap between short-lived credentials and the persistent assumptions that allow them to be issued. As machine identities multiply across cloud and AI workflows, teams should expect this debt to show up first in brokers, runners, and integration layers rather than in the token itself. Programmes that treat the issuance path as a control surface will be better positioned to contain it.

For practitioners

• Inventory every identity that can mint privilege Map brokers, pipeline runners, workload identities, and token services that can issue fresh access so you can see where standing trust still exists. Pair the inventory with review of the control plane and the downstream systems each identity can reach.
• Apply contextual approval to JIT grants Require behavioural baselines, consumer checks, and resource sensitivity thresholds before issuing temporary access. This reduces the chance that a compromised identity can request new privilege through normal-looking workflows.
• Constrain the blast radius of issuers Limit which systems each brokered identity can affect, then test deny rules in production-safe ways before broad rollout. The goal is to stop one compromised requester from becoming a source of repeated privileged access.
• Review JIT as part of Zero Trust for NHIs Align access reviews, logging, and incident response around the point where access is granted, not only where it is used. That gives security teams a practical way to detect when temporary access is being generated from untrusted context.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

Key takeaways

• JIT access narrows the exposure window, but it does not eliminate the trust path that authorizes new privilege for NHIs.
• The security problem shifts from credential duration to issuer trust, which is why compromised runners and brokers remain high-value targets.
• Practical Zero Trust for machine identities requires contextual validation and enforcement at the moment access is granted.

Key terms

• Just-In-Time Access: Just-In-Time access is a model that grants privilege only for a short, task-specific window. It reduces standing exposure, but it does not by itself prove the requester is trustworthy. In NHI programmes, its value depends on contextual approval, issuer control, and safe revocation when behaviour changes.
• Non-Human Identity: A non-human identity is any digital identity used by software, workloads, scripts, service accounts, API clients, or AI agents to access systems. These identities can authenticate, request privileges, and interact with data and tools, which makes their lifecycle and trust model central to modern IAM governance.
• Identity Blast Radius: Identity blast radius is the amount of access and downstream system reach that a compromised identity can influence. For NHIs, the concept helps teams measure how far a stolen token, abused runner, or compromised broker can move before controls stop it. Smaller blast radius means narrower operational and security impact.

What's in the full article

Entro Security's full blog covers the operational detail this post intentionally leaves for the source:

• The specific behavioural signals the vendor uses to decide whether a non-human identity should receive fresh access.
• How baseline tracking is applied to sensitive operations, consumer usage, and policy changes in live environments.
• The operational logic behind targeted deny policies when an NHI crosses a meaningful risk threshold.
• The example workflow for enforcing least privilege without breaking production access paths.

👉 The full Entro Security post covers baseline tracking, enforcement logic, and production-safe deny decisions.

Deepen your knowledge

JIT access, ephemeral credentials, and machine identity trust are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building a governance programme around temporary privilege and Zero Trust for NHIs, it is worth exploring.