What fails when just-in-time access still leaves the provider in the trust path?

Where just-in-time access still fails

Just-in-time access only solves the standing-permission problem if it also changes who controls issuance, storage, and recovery of the credential or session. If a provider still sits inside that trust boundary, the access is temporary but the authority is not. The meaningful question becomes whether the customer has removed persistent provider custody, not whether the token itself expires.

That distinction matters because the attack surface shifts from “how long can the secret be used?” to “who can mint, retain, replay, or reconstruct it?” A design can look ephemeral while still concentrating control in the same platform operator, which leaves the control dependent on the provider’s internal safeguards rather than on the customer’s own trust boundary.

This is why JIT should be read together with Just-in-Time Access and Zero Standing Privilege Guide and Privileged Access Management Guide. The control objective is not merely to shorten duration, but to remove standing authority and narrow who can exercise privileged power at all.

Why temporary credentials can still preserve provider dependence

A temporary credential does not eliminate risk if the provider still performs issuance, vaulting, signing, or recovery. In that arrangement, the provider remains able to affect access even when the customer believes access is tightly time-bound. The control failure is architectural: the trust path is reduced in time, but not in custody.

Provider dependence becomes especially important when the platform can regenerate credentials, act as the broker for session creation, or retain enough material to reconstruct access. That means compromise of the provider-side control plane can still widen the blast radius, even if the end credential is short lived. For a broader operating model perspective, see Service Account Security Guide and Cloud PAM and CIEM Guide, which both emphasise effective permissions and custody-aware privilege design.

In practice, the control fails when the provider can still reconstitute access after the nominal TTL ends, because revocation is then only partial. That is the difference between a time-limited grant and a real reduction in trust.

What practitioners should verify before calling JIT effective

First, verify whether the customer controls the policy that issues the access or whether the provider can override, reconstruct, or silently extend it. Second, confirm whether the provider stores the secret, injects it on behalf of the user, or retains enough cryptographic authority to mint a new one. Third, check whether revocation actually breaks the provider’s ability to replay the same access path.

What to verify: If the provider can still create, hold, or recover the access material, JIT is a risk-reduction measure, not a trust-boundary removal. Treat that as a design constraint, not a minor implementation detail.

Decision rule: If the provider can exercise the same privilege path during an incident or support workflow, require stronger custody separation, customer-held issuance controls, or a different access design before relying on the control.

For implementation guidance on how this usually breaks at scale, compare the patterns in Break-Glass and Emergency Access Account Guide and Privileged Session Management Guide. Both show why authority, not just duration, must be bounded and observable.

Practitioner takeaway: The real test for JIT is whether the provider can still independently exercise the access path after the customer believes it has been removed.

Risk and Threat Considerations

A temporary secret that remains provider-controlled can still be abused if the platform, operator, or support process is compromised. The exposure is not limited to token theft; it also includes misuse of the issuance path, emergency recovery path, or any retained cryptographic control that can recreate the same privilege.

Failure mechanism: The trust boundary stays intact on the provider side, so an attacker who gains provider-side control, or a malicious insider with enough authority, may be able to mint, replay, or restore access even after the customer assumes the credential has expired.

Impact: The result is not just longer exposure, but a false sense of isolation. The organisation may think it has eliminated standing privilege when it has only moved the standing trust relationship behind the provider’s control plane.

Practitioner Guidance

What to prioritise: Focus on custody and override rights before tuning TTL values. A short-lived credential with provider-held recovery can still create a durable trust dependency, so evaluate who can issue, store, and reconstruct access under normal operations and under incident conditions.

What good looks like: The customer can independently govern issuance and revocation, the provider cannot silently extend or re-create access, and session or credential use is observable enough to prove that expiration actually ends authority.

Common mistake: Treating “temporary” as equivalent to “safe” even when the same platform still owns the control plane. In practice, that often reduces exposure window without reducing blast radius.

Practitioner takeaway: JIT only delivers its intended security benefit when the trust boundary moves, not when the timer changes.

Related resources from NHI Mgmt Group

• When do NHI access reviews create more value than a one-time cleanup?
• How should security teams run access reviews for non-human identities?
• How should security teams govern non-human identities that have persistent access?
• What is the difference between reviewing human access and reviewing NHIs?