What do security teams get wrong about just-in-time access in mixed environments?

Why This Matters for Security Teams

Just-in-time access is often sold as a simple way to reduce standing privilege, but mixed environments expose a harder truth: JIT is only effective where the request, approval, provisioning, and revocation path is actually enforced. Outside the primary application catalogue, service accounts, scripts, CI/CD jobs, and legacy platforms often keep their own access paths. That creates a false sense of control and leaves revocation fragmented. The Ultimate Guide to NHIs notes that 97% of NHIs carry excessive privileges, which is exactly the kind of baseline JIT is meant to reduce.

The practical mistake is treating JIT as a permission model rather than an operating model. In mixed estates, temporary elevation in one control plane does not automatically translate to databases, cloud roles, SaaS admin consoles, or agent tooling. Security teams then measure success by the presence of a JIT workflow instead of by whether privilege was truly constrained end to end. Guidance from the OWASP Non-Human Identity Top 10 reinforces that non-human access must be governed across the full identity lifecycle, not just at the point of initial approval. In practice, many security teams discover this only after a privilege path was left outside the catalog and used during an incident.

How It Works in Practice

Effective JIT in mixed environments depends on boundary control, not just temporary approval. The question is where the entitlement is created, how long it lives, how it is scoped, and whether revocation is guaranteed across all connected systems. For human access, that may mean PAM integrating with cloud IAM and SaaS admin tools. For non-human identities, it usually means tying JIT to workload identity and ephemeral secrets, not long-lived static credentials.

At minimum, teams should align JIT with these mechanics:

• Use policy-based approval and enforce it at request time, not at ticket closure.
• Issue short-lived credentials with a clear TTL and automatic revocation.
• Prefer workload identity for agents and services, rather than shared secrets or manual key handoff.
• Validate that downstream systems honor the temporary grant, including APIs, queues, databases, and third-party integrations.
• Log the full chain: who requested access, what context justified it, where the privilege was applied, and when it was removed.

This is where current guidance suggests combining JIT with Zero Trust principles and secret hygiene. NIST’s Zero Trust Architecture emphasizes continuous evaluation rather than assuming a user or workload should retain trust once admitted. NHIMG research also shows that only 20% of organisations have formal offboarding and revocation processes for API keys, while 91.6% of secrets remain valid five days after notification, which shows why “temporary” access often outlives the incident response window. The Ultimate Guide to NHIs and the Guide to NHI Rotation Challenges both point to the same operational issue: if rotation and revocation are not automated, JIT becomes a manual promise instead of a control.

These controls tend to break down in estates that mix legacy apps, third-party SaaS, and custom automation because each platform enforces privilege differently and revocation is not uniformly supported.

Common Variations and Edge Cases

Tighter JIT often increases operational overhead, requiring organisations to balance faster access with stronger assurance. That tradeoff becomes most visible in environments where the catalog covers only part of the estate. Teams may have JIT for cloud consoles but still rely on permanent database roles, break-glass accounts, or embedded secrets in CI/CD pipelines. Best practice is evolving here: there is no universal standard for how every mixed environment should federate temporary access, so the control design has to match the weakest enforcement point.

One common edge case is third-party and contractor access. A JIT grant may be clean inside the primary identity provider, but if an external SaaS or vendor-managed connector still holds its own token, the temporary control does not reduce the effective attack window. Another edge case is automation that needs recurring access. For those workloads, the answer is usually not human-style JIT approvals, but workload identity, scoped tokens, and runtime policy checks aligned to the task. That distinction matters because a service or agent does not behave like a person and may trigger access in bursts, retries, or chained workflows.

Security teams should also distinguish between shortening session time and reducing standing privilege. Those are related but not equivalent. Without full revocation assurance, JIT may only hide long-lived access behind a short UI session. Current guidance suggests measuring success by coverage across systems, not by the number of approved temporary grants. Mixed environments fail when legacy systems cannot consume ephemeral identity and the team accepts exceptions as normal operating procedure.

Related resources from NHI Mgmt Group

• What do security teams get wrong about privileged access in mixed human and machine environments?
• What do security teams get wrong about vendor access in public safety environments?
• What do security teams get wrong about zero trust in agentic access environments?
• What do security teams get wrong about third-party access in CJIS environments?