The Factory Versus The Product

To understand the trap, look at the architecture. To generate a temporary token, you need a broker, a centralized engine, a pipeline runner or an identity provider that possesses the authority to create that access on demand. We've effectively replaced scattered, long-lived keys with a highly centralized "token factory," which requires persistent, overarching privileges to function. It needs "God-mode."

Hackers, as rational economic actors, have already adapted. They aren't trying to steal your 15-minute token; the window is too small, and the effort is too high. Instead, they're targeting the system that mints the tokens. If an attacker can compromise a workload, spoof a machine identity or hijack a CI/CD runner, they don't need to steal a secret. They can simply ask your JIT broker to mint them a brand-new, perfectly valid ephemeral token whenever they want.

When JIT is deployed without strict guardrails, you haven't eliminated the risk of unauthorized access. You've just automated it for the adversary.

The Missing Link: Zero Trust For Machines

The fundamental flaw in how most organizations implement JIT today is a lack of context. When a script or a microservice requests temporary access, the JIT broker usually checks a single box: Does this machine have the baseline permission to ask for this token? If yes, the token is granted.

That's the exact opposite of the zero-trust principle. We apply zero trust quite rigorously to humans. When an employee logs in, we don't just look at their password. We look at their location, the device posture, the time of day and the behavioral context. If something looks weird, we challenge it.

We must apply this exact same rigor to NHIs. If we want JIT to actually secure our environments, zero-trust principles for machines must gate the act of granting ephemeral access.

What We Tell Enterprise Security Teams

To prevent ephemeral access infrastructure from becoming the ultimate attack vector, security leaders must evolve their approach to machine identity. In working with enterprise customers navigating this shift, what we've seen consistently is that the hardest part is rarely the technology but the organizational work that comes before it.

Map the trust before you touch the tooling.

The first thing we tell security teams is to resist the urge to deploy controls before they understand what they're protecting. Most organizations have no clear picture of which NHIs carry implicit trust in their environment. We start by helping them build a complete inventory—which machine identities can request tokens, through which pipelines, how often and who actually owns them.

In most cases, nobody has ever mapped these relationships end to end. Without that visibility, any enforcement layered on top is guesswork. That mapping exercise alone has changed the internal conversation for many customers, giving security teams something concrete to bring to engineering and platform leadership.

Assign ownership or nothing moves.

One of the most common stumbling blocks we see with enterprise customers is that no one owns the machine identity layer. The developer who created a service account two years ago has moved teams. The platform group manages the pipeline but not the tokens it generates. Security sees the risk but has no authority over the workload.

We advise formalizing ownership early, treating it as a governance requirement rather than a security nice-to-have. Until every NHI has a clear human owner accountable for its behavior and life cycle, zero-trust policies stall in committee. This is a governance problem before it's a security problem.

Overcome the fear of breaking production.

Security teams we work with often stop at visibility because enforcement feels too dangerous. They can see that an NHI is overprivileged or behaving abnormally, but the risk of revoking access and taking down a production workflow is paralyzing.

We guide these teams to start small. Observe baseline behavior first, then introduce narrow restrictions targeting clearly risky actions rather than broad revocations. Confidence builds incrementally. If a team is afraid to enforce, the controls available to them are too blunt.

Embed into existing workflows, not around them.

A pattern we see repeatedly is security introducing a new gate in the CI/CD pipeline and engineering routing around it within a week. If JIT and NHI controls feel like external checkpoints, teams will treat them as obstacles.

The customers who succeed are those who integrate verification into the pipelines developers already use, making secure token requests and lineage tracking part of the default path rather than something bolted on from the outside.

Expect cultural resistance and address it early.

Perhaps the most underestimated barrier is human. Developers and platform teams often view new access controls as friction or a loss of autonomy. The enterprise teams we've seen succeed invest early in explaining not just what is changing, but why. Framing this evolution as enabling safer velocity rather than slowing teams down is critical. Without that narrative, adoption becomes a fight.

The Next Evolution Of Access

JIT access is necessary for the future of cloud security, but it's an action, not an architecture.

If you build JIT on top of an implicitly trusted network of NHIs, you're just building a faster, more efficient way for attackers to move laterally. The goal isn't just to make access ephemeral. It's to make access mathematically impossible to exploit.

The next time your team proposes rolling out JIT access, ask them one question: How are we verifying the machine asking for it?​

Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?