Here's a fun wrinkle about modern identity security: Just-in-time (JIT) access used to be a conversation about people like your admins, your contractors, the developer who needs to poke at production for forty-five minutes.
Today, organizations have a second audience that needs JIT just as badly: the sprawling collection of cloud services, pipelines, agents, and automations doing work on your behalf around the clock.
Both audiences are growing, and both generally skew to standing privilege by default. That is why JIT has quietly become one of the most strategic controls in your security program.
So, what is JIT, really?
JIT access is the idea that no human or non-human should have privileged access sitting around waiting to be abused. Instead, access is granted at the moment it's needed, for a specific task and duration, and then it goes away. Permissions are ephemeral. The blast radius of a compromised credential shrinks dramatically because there's nothing to compromise most of the time.
It isn't a new concept. Security teams have been chasing the principle of least privilege long before "zero trust" got its keynote slot. What is new is where JIT has to live now. It's no longer enough to wrap JIT around a handful of admin accounts.
Then cloud happened. Then DevOps happened. Then the CI/CD pipeline grew up, started running its own errands, and quietly became the most privileged identity in your environment.
JIT has expanded from "tighten up the admin account" to "manage privileged access for every human, machine, workload, and automation that touches something sensitive." That's the whole game now.
Audience #1: Humans with privileged access
This is the classic use case, and it's still the one that keeps your auditors happy. Domain admins, database owners, network engineers and third-party support are the people who can do the most damage with one bad day or one phished credential. Standing privilege for these accounts is a liability, full stop.
JIT for privileged users typically works like this: The user requests elevated access for a defined task, the request gets evaluated (often automatically, based on policy), access is granted for a limited window, and every action during that session is recorded. There is a big trend around having a “human-in-the-middle,” with a heartbeat user evaluating access requests and approving them. Sometimes this is desired, but increasingly, decisions using heuristics or even artificial intelligence are being accepted.
When the access window closes, the privilege disappears. Compliance frameworks like SOX, HIPAA, PCI-DSS, or NIS2 (the list is long) love this model because it gives auditors a clean answer to "who had access to what, and when?" Instead of explaining why twelve engineers have permanent root, you can show that access was granted, used, and revoked in eighteen-minute slices.
The win here is twofold. You shrink your attack surface in the obvious way, fewer accounts with standing privilege means fewer accounts worth attacking, and you get an audit trail that practically writes itself.
Audience #2: Your cloud, your code, and everything they touch
Here's where it gets interesting. Walk into a modern engineering org and look at what's actually accessing sensitive systems. It's not just people.
It's the build agent that needs to push to production. It's the Terraform run that needs to spin up an RDS instance. It's the ephemeral container that needs to read a database secret for exactly one query. It's the AI agent your platform team just deployed that needs to query three internal services to answer a single prompt. It's the developer's laptop, sure, but it's also the laptop's IDE plugin, the local dev environment, the staging cluster, the GitHub Action, the Lambda, the cron job nobody documented in 2021.
Every one of those identities used to get handed a long-lived credential and a hopeful pat on the back. That doesn't fly anymore. The credentials get committed, leaked, scraped from logs, harvested from caches, or just sit in environment variables waiting for the right (wrong) person to find them.
Static keys in a cloud-first world are the new sticky-note-under-the-keyboard
JIT for cloud and developer environments means those workloads and tools authenticate, request access for a narrow purpose, and get a credential that expires before anyone could meaningfully misuse it. Same principle as the human side, just applied to the thousand non-human identities running your business.
The kinds of things in your dev environment that need JIT
A non-exhaustive tour:
- Production databases and data warehouses (Postgres, MySQL, Snowflake, BigQuery, you name it)
- Kubernetes clusters and the kubectl access that comes with them
- Cloud consoles and APIs (AWS, Azure, GCP)
- CI/CD systems and the secrets they pull during builds
- Internal services accessed over SSH, RDP, or HTTPS
- Source control, container registries, artifact stores
- Observability platforms holding sensitive customer data
- AI and ML platforms that touch training data or model endpoints
If a developer or a workload can reach it, it probably needs JIT around it.
Things developers genuinely hate
This is the part security teams sometimes underestimate. Developers will route around any control that gets in their way, especially when the control makes their day worse than it needs to be.
The fastest way to lose developer trust is to tell them they have to abandon the tools they already use. If your engineers SSH into Linux hosts and RDP into Windows boxes today, asking them to learn a new proprietary client just to get short-lived access is a non-starter.
They will find a workaround. The same goes for replacing kubectl with a web UI, or swapping their database client for a "secure portal" that has a worse autocomplete. The other quiet productivity killer is vault sprawl. One vault for app secrets, another for infra credentials, a different one for cloud keys, and a fourth one the platform team is "migrating off of." Every additional vault is another login, another integration, another place where something breaks at 2 a.m. Developers don't want to be vault archaeologists. They want to do their work.
The right model meets developers where they already live with the same protocols, clients and workflows and handles the JIT plumbing invisibly underneath. Done well, JIT doesn't slow developers down. It speeds things up because they no longer have to wait in a ticket queue to have a credential rotated or added to a static access group.
Compliance and efficiency, in the same breath
It's tempting to frame JIT as a tradeoff: more security, less speed. The reality is the opposite for most teams. Auditors get the clean access records they've been asking for, engineers stop maintaining shadow lists of who has access to what, and platform teams retire the spreadsheets. Risk goes down. The mean time to "yes, you can access that" goes down. The boring, expensive overhead of standing privilege—the access reviews, the offboarding checklists, the "wait, does so-and-so still need this?" emails—gets a lot smaller.
JIT done right is one of the rare controls where the security win and the productivity win point in the same direction.
Where Delinea fits
Delinea has built privileged access management (PAM) for human users for a long time, and our Delinea platform handles JIT for privileged accounts at scale. Request, approve, elevate, record, expire. That's the foundation.
What's new and worth paying attention to is that, with the acquisition of StrongDM, Delinea now extends that same JIT model deep into the developer and cloud infrastructure stack. StrongDM brings short-lived access to databases, Kubernetes, cloud consoles, servers, and internal services through the tools developers already use. SSH still works like SSH and kubectl still works like kubectl. The credentials underneath are ephemeral, the access is governed by policy, and every session is logged for compliance.
Two audiences, one platform, no asking your developers to relearn their jobs.
If you've been thinking about how to retire standing privilege for your admins, engineers, pipelines or all of the above, we'd love to talk. Reach out to Delinea to map out a JIT strategy that covers both of your audiences without slowing either down. Your auditors and your developers will, for once, agree on something.