Just-in-time access in the cloud: AWS, Azure and GCP guide

Just-in-time access in the cloud means nobody holds an elevated AWS, Azure or Google Cloud role by default. An engineer requests a specific role for a specific window with a reason, an approver or policy decides, the cloud issues a short-lived credential or a time-bound role assignment, and the access ends when the window closes. The aim is to remove two things attackers rely on: long-lived access keys and standing administrator roles. This guide is for cloud security leads and platform engineers who want to know how just-in-time access works on each of the three clouds, what the native tools do, where they stop, and what to put around them.

Just-in-time (JIT) cloud access is a privilege model in which elevated cloud permissions do not exist until a request is approved, are scoped to one role and account for a bounded time, and are removed or expire automatically when that time ends.

What just-in-time access in the cloud actually changes

The important words are “do not exist”. An approval step placed in front of a role that is permanently assigned is a workflow, not just-in-time access: the privilege is still there between approvals, and a stolen session or forgotten assignment can still use it. Just-in-time access removes the standing privilege itself, so there is nothing to abuse between sessions.

The cloud makes this matter more than on-premises. A single cloud identity with a broad policy can reach every resource in an account through one API, from anywhere. Long-lived access keys also travel: into scripts, CI settings, laptops and repositories. AWS’s own IAM best practices ask you to require human users to use federation with temporary credentials, and to rely on temporary credentials instead of access keys wherever possible.

How the request, approve and expire flow works

Every just-in-time implementation, native or third-party, follows the same five steps. The differences between products are in how much control and evidence each step gives you.

1. Request. The engineer names the cloud, account or subscription, the role, the duration and the reason, ideally a change or incident ticket.
2. Decide. A policy routes the request: one approver for low-risk read access, more approvers or step-up MFA for roles that can change identities, policies or logging.
3. Issue. The cloud issues a short-lived credential (an AWS STS session, for example) or activates a time-bound role assignment.
4. Use and record. The session runs, ideally through a control point that records what was done and can block dangerous calls.
5. Expire or revoke. The credential or assignment ends at the close of the window, or earlier if someone revokes it.

Just-in-time access on AWS

AWS builds just-in-time access from roles and the Security Token Service. According to the AWS documentation on temporary credentials, STS credentials can last from a few minutes to several hours, are generated on request rather than stored with the user, and are no longer recognised once they expire. AWS recommends IAM Identity Center for centralised workforce access to accounts.

Session length is set per role. The AssumeRole family of APIs accepts a duration from 15 minutes up to the role’s maximum session duration, which can be set between 1 and 12 hours, with a default of one hour. When one role is used to assume another (role chaining), the session is limited to one hour.

Revoking an AWS session early

A temporary credential that leaks remains usable until it expires. AWS lets you revoke active role sessions by attaching an inline AWSRevokeOlderSessions deny policy keyed on aws:TokenIssueTime. It denies every session issued before the cut-off (and roughly 30 seconds after, to allow for propagation), and it applies to all users of that role, not just the one you are worried about. Roles created from Identity Center permission sets cannot be edited in IAM; their sessions are revoked in Identity Center instead.

Just-in-time access on Azure with Entra PIM

On Azure, the native building block is Microsoft Entra Privileged Identity Management (PIM). PIM distinguishes eligible assignments, which a user must activate, from active assignments, which work without any action. Activation asks the user to choose a duration within the administrator’s maximum and give a reason, and can require MFA and approval.

PIM also supports time-bound assignments with start and end dates, notifications on activation, access reviews and downloadable audit history. Users can request an extension before an assignment expires or a renewal after it does, and both need approval. Microsoft notes that PIM requires Entra ID Governance licensing, so check entitlements before you plan around it.

Just-in-time access on Google Cloud

Google Cloud offers several routes, described on its temporary elevated access page. The most direct is Privileged Access Manager: administrators define entitlements that set who can request, which roles are granted, whether a justification and approval are needed, and the maximum grant duration. An approved grant adds the roles until the grant ends, after which Privileged Access Manager revokes them, and events go to Cloud Audit Logs.

Two details are worth knowing. Requests that are neither approved nor denied within 24 hours expire. If you use IAM Conditions to create expiring role bindings instead, expired bindings stay in the allow policy until you remove them, and deny policies do not support time-based conditions.

AWS, Azure and GCP just-in-time building blocks compared

	AWS	Microsoft Azure	Google Cloud
Native JIT mechanism	IAM roles assumed through STS, managed with IAM Identity Center	Entra PIM eligible role assignments	Privileged Access Manager entitlements and grants
What the user receives	Temporary credentials for a role session	An activated role for a limited time	Roles bound for the grant duration
Duration control	15 minutes up to the role maximum (1 to 12 hours)	User picks a duration within the configured maximum	Maximum grant duration set per entitlement
Approval	Not built into AssumeRole; added by your process or tooling	Optional approval, MFA and justification on activation	Optional justification and approval
Early revocation	Deny policy on sessions issued before a time	End or remove the assignment	Grant can be ended early; bindings removed at expiry
Audit source	CloudTrail	PIM audit history	Cloud Audit Logs

Each cloud solves the grant well inside its own boundary. What none of them gives you is one request flow, one approval policy and one session record across all three, or inspection of what an engineer does with the role once it is active.

Where SWOT Cloud PAM fits

SWOT Cloud PAM adds that cross-cloud layer for the management plane of AWS, Azure and GCP: the console, CLI, SDKs and infrastructure as code. An engineer requests a role, account, duration and reason. Multi-stage approval decides, with deterministic risk scoring on escalation, exfiltration, IP, geography and timing that can add a second approver and step-up MFA before anything is issued.

The Access Gateway then brokers short-lived credentials: STS AssumeRole on AWS and OAuth credentials on Azure and GCP, clamped to the session, so engineers stop holding long-lived cloud keys. Calls pass through the gateway, where operations your policy marks as dangerous, such as deleting a CloudTrail trail, are denied before they leave it. A revoked grant stops working within 60 seconds, admins can end a live session in one click, and high-risk sessions end on their own. Every event sits on a SHA-256 hash chain for playback and export.

SWOT Cloud PAM is self-hosted, signs users in through Entra ID, Okta or Google, and keeps emergency access in break-glass accounts under dual control. For servers and databases, SWOT PAM applies the same just-in-time model through its proxy.

Common mistakes when rolling out just-in-time access

Most failed rollouts fail on process, not technology. The pattern is consistent: the new path is added, the old standing access is never removed, and engineers route around approvals that are too slow.

• Inventory every standing administrator role assignment and long-lived access key before you start, using IAM last accessed information on AWS.
• Remove standing assignments for each role as soon as its just-in-time path is live; do not leave both.
• Set windows per role, shortest for roles that can change identities, policies or logging.
• Pre-approve low-risk read-only requests by policy so approvers only see requests that need judgement.
• Require a reason or ticket on every request, and show it to the approver.
• Test early revocation on each cloud, including cached CLI credentials, and time how long it takes.
• Move workloads and pipelines to short-lived credentials through federation rather than giving them just-in-time human roles.
• Keep a break-glass path under dual control, and review every use.

Next steps

Just-in-time access in the cloud removes standing roles and long-lived keys by issuing short-lived, approved, recorded access that expires on its own. The native tools on AWS, Azure and GCP provide the grants; a gateway such as SWOT Cloud PAM adds one request flow, inline blocking and a tamper-evident record across all three. See how it works on the just-in-time access solution page, or book a demo on your own cloud accounts.