Just-in-Time (JIT) access is a privilege model in which no user holds permanent elevated access to cloud resources. When elevated access is needed, the user requests it for a defined time window. The platform evaluates the request, issues ephemeral credentials, monitors the session in real time, and automatically revokes access when the window closes. JIT eliminates the long-lived IAM credentials that are the primary attack vector in cloud breaches - credentials that attackers find, steal, and use at leisure.
Cloud intrusions increased 75% year-over-year in 2023, according to the
CrowdStrike 2024 Global Threat Report. The primary enabler: long-lived IAM credentials and standing cloud privileges that allow attackers to move laterally once initial access is gained. JIT directly eliminates this attack surface.
If you've spent any time in cloud security in the last three years, you've heard the phrase "just-in-time access." Every PAM vendor uses it, every cloud provider talks about it, and every CISO has it on their roadmap. But the gap between the slogan and a working JIT implementation is enormous. This post explains, in concrete terms, what just-in-time access actually is, how it works in modern cloud environments, and how a platform like SWOT Cloud PAM makes it operational.
What Just-in-Time (JIT) Access Actually Means
Just-in-Time (JIT) access is a privilege model in which no user holds permanent elevated access. Instead, when a user needs to perform a privileged action - say, connect to a production database or assume an AWS IAM role with administrative permissions - they request access, the request is evaluated (often automatically), access is granted for a bounded time window, and at the end of that window the access is revoked.
The two important words in that definition are bounded and revoked. JIT is not access that you have to request - that's just an approval workflow on top of standing privileges. JIT is access that does not exist until you request it, and ceases to exist when the window closes.
Why the Cloud Demands JIT
Standing privileges are dangerous everywhere, but they're particularly toxic in the cloud, for four reasons:
- The blast radius is larger. A single AWS IAM principal with a permissive policy can spin up infrastructure, exfiltrate data, and destroy resources across an entire account in seconds.
- Credentials live longer than they should. Long-lived API keys and access tokens end up in repos, config files, CI/CD systems, developer laptops, and forgotten test environments.
- The attack surface is constantly changing. Cloud infrastructure is ephemeral - instances and services come and go - but identity rarely keeps pace.
- You can't see all the privileges you've granted. A typical AWS account has thousands of IAM policies. Almost no one can answer the question "who has admin access right now?"
JIT directly attacks all four. There are no long-lived elevated credentials to leak. There is no permanent attack surface. The privilege graph becomes auditable because access is by definition short-lived and intentional.
How JIT Works in Practice
Step 1: Access Request
A user - engineer, DBA, SRE, support - needs elevated access to a cloud resource. Instead of using a permanent role assignment, they open the PAM console (or trigger a chat-ops command in Slack or Teams) and request access. The request specifies: what resource, what role, how long, and why.
Step 2: Risk Evaluation and Approval
The platform evaluates the request. Low-risk routine requests can be auto-approved by policy. Higher-risk requests - production access, new role, off-hours - escalate to a human approver with full context: the requester's behavioral baseline, current risk score, recent activity, and the sensitivity of the target.
Step 3: Ephemeral Credential Issuance
Once approved, the platform mints ephemeral credentials. On AWS, this is typically a short-lived STS session. On Azure, it's a time-bound Entra ID role assignment. On GCP, it's a temporary IAM grant. The user does not see the underlying credential - they connect through a session proxy that uses the credential on their behalf.
Step 4: Session Monitoring
The session is monitored in real time. Commands are recorded. Sensitive actions are scored against the user's behavioral baseline. If a command crosses a risk threshold, the platform can pause, block, or terminate the session.
Step 5: Automatic Revocation
At the end of the requested time window - or earlier, if the user finishes - the credential is revoked. No cleanup task to run. No human to remember. The access does not exist anymore.
JIT for AWS, Azure, and GCP - out of the box
SWOT Cloud PAM federates with AWS IAM Identity Center, Microsoft Entra ID, and Google Cloud Identity. JIT, ephemeral credentials, and session monitoring across all three providers from one console.
Explore SWOT Cloud PAM
JIT Across AWS, Azure, and GCP
One of the underrated complexities of cloud JIT is that each cloud has a different identity primitive. A good cloud PAM platform abstracts this so you don't have to think about it.
- AWS. JIT typically uses AWS IAM Identity Center (formerly SSO) with permission sets that are assumed via short-lived STS sessions. The PAM platform federates with Identity Center and brokers the assumption.
- Microsoft Azure. JIT uses Entra ID role assignments, often through Privileged Identity Management (PIM). The PAM platform extends PIM with approval workflows, behavioral context, and session-level controls.
- Google Cloud. JIT uses time-bound IAM bindings on the target resource. The PAM platform manages binding creation and revocation, and overlays its own session governance.
For organizations running across multiple clouds, the value of a single PAM control plane is significant - one approval policy, one session-recording standard, one audit trail.
JIT for Databases and Kubernetes
Cloud JIT is not just for VM and IAM access. It applies equally well to databases and Kubernetes:
- Databases. Instead of issuing a permanent DB user, the platform creates a temporary DB role with a short TTL, scoped to the specific schemas the user needs. Pair this with SWOT DAM 3.0 for full audit coverage of the actions taken during the JIT session.
- Kubernetes. Instead of permanent
kubeconfig credentials, the platform issues short-lived tokens scoped to a specific namespace, with a defined RBAC role and an end time.
Common Mistakes When Rolling Out JIT
- Treating it as a tool, not a policy change. JIT only works when standing privileges have been intentionally removed. If they're still there, JIT is just a layer on top.
- Approval bottlenecks. If every request needs a human, your engineers will work around the system. Auto-approve low-risk routine requests by policy.
- Ignoring service accounts. Machine identities outnumber human identities by orders of magnitude in the cloud. JIT for human users is necessary but not sufficient - extend ephemeral credentials to your service accounts too.
- No baseline period. Before you start auto-approving by risk score, give the platform time to learn each user's normal pattern.
The Bottom Line
Just-in-Time access is not a feature - it's the operating model that everything else in modern cloud security assumes. Done correctly, it eliminates standing privileges, dramatically reduces blast radius, makes the privilege graph auditable, and removes the most common attack vector in cloud breaches: the long-lived credential.
If your cloud PAM strategy is still based on standing IAM roles, the upgrade path is to start with JIT for your highest-sensitivity systems (production databases, payment infrastructure, customer data) and expand outward. SWOT Cloud PAM can run this entire model across AWS, Azure, and GCP - talk to our team for a walkthrough.
Frequently Asked Questions About Just-in-Time Cloud Access
What is the difference between JIT access and an approval workflow on standing privileges?
An approval workflow on standing privileges means the user has to request before using access - but the underlying privilege still exists permanently in IAM. JIT access means the privilege does not exist at all until the request is approved, and ceases to exist when the time window closes. With standing privileges, a stale or forgotten role assignment remains a live attack surface. With JIT, there is no standing privilege to attack between sessions.
How does JIT access work in AWS?
In AWS, JIT access uses IAM Identity Center (formerly SSO) with permission sets. When a request is approved, the PAM platform assumes the target IAM role via AWS STS, generating a short-lived session token. The user connects through a proxy that uses the ephemeral credential on their behalf - they never see the underlying access key or secret. The session token expires automatically at the end of the JIT window, leaving no residual access in IAM.
How does JIT work in Microsoft Azure?
In Azure, JIT uses Entra ID time-bound role assignments through Privileged Identity Management (PIM). The PAM platform extends PIM with additional approval workflows, behavioral risk scoring, and session-level controls beyond what PIM natively provides. For VM management, Azure Security Center also offers JIT VM access that restricts inbound management ports (RDP, SSH) to approved time windows and approved source IPs only.
Does JIT access work for database connections?
Yes. Instead of a permanent database user or role, the PAM platform creates a temporary DB credential scoped to specific schemas, with a short time-to-live. At the end of the JIT window, the credential is revoked and cannot be reused. Pairing JIT database access with SWOT DAM 3.0 provides complete coverage: JIT controls who connects and when; DAM records every query executed during the session.
What is the typical duration for a JIT access session?
JIT time windows are policy-defined and vary by sensitivity. Common configurations: routine production read access (30–60 minutes), administrative changes (15–30 minutes aligned with a change window), emergency break-glass access (4–8 hours with enhanced monitoring and mandatory post-incident review). The principle is to set the window to the shortest duration that allows the legitimate work to complete - with no standing buffer time built in.
What happens if a JIT session needs to be extended?
Most enterprise JIT platforms allow in-session extension requests. The extension request goes through the same evaluation and approval workflow as the original request. Sessions below a risk threshold may be auto-extended by policy; higher-risk sessions require human approver action. All extension activity is logged to the audit trail. Sessions can also be terminated early by the user, the approver, or the platform if behavioral anomalies are detected mid-session.
- Rudratic Technologies. Related reading: Zero Standing Privileges Explained · AI in PAM
