What is just-in-time (JIT) access?
Just-in-time (JIT) access is an access control model that grants a user, service, or workload elevated cloud permissions only for a specific task, then revokes them automatically when the time-to-live (TTL) expires.
In practice, your engineers still get admin rights when they need them. Those rights simply stop existing once the work is done. Because access is decided per session, JIT access also fits neatly into a zero trust architecture.
Most cloud environments start with static, persistent permissions. A role gets admin rights once, and those rights stay attached 24/7 whether anyone uses them or not. ZSP is the target state where no identity holds elevated access by default, and every elevation goes through a request.
The Cloud Visibility Playbook
Get the Cloud Visibility Playbook to master 10 key practices for eliminating blind spots, mapping true attack paths, and unifying multi-cloud security.
| Attribute | Static persistent permissions | Zero standing privileges |
|---|---|---|
| Default state | Elevated rights always attached | No elevated rights attached |
| How access is granted | Once, at onboarding or role assignment | Per request, after policy checks |
| Duration | Indefinite, until someone removes it | Minutes to hours, set by a TTL |
| What a stolen credential yields | Everything the role allows, for as long as the key works | One task's scope until expiry, or nothing elevated at all |
| Audit evidence | Assignment records, rarely tied to a task | Per-session record of who, what, when, and why |
That shift is what people mean by temporal least privilege. It extends the principle of least privilege (PoLP) with a time dimension. You grant rights only when needed, for the shortest useful window, scoped to the exact task. A role someone uses twice a month is a good example, since it stays usable by anyone holding its credentials the other 28 days.
Just enough access (JEA) complements JIT: JEA limits how much a grant allows, and JIT limits how long. JIT provisioning differs, since it creates an account at first single sign-on login instead of granting elevated permissions.
Why organizations are moving away from standing privileges
IBM X-Force tied 32% of the incidents it handled in 2025 to stolen or misused credentials, so identity remains a popular way in. Four drivers push teams toward JIT access: credential risk, privilege creep, audit pressure, and engineering speed.
Mitigating credential compromise
Verizon's 2026 Data Breach Investigations Report found credential abuse in 39% of breaches at some point in the attack chain, but only 13% started there. A leaked JIT credential works only until its session expires (often an hour or less) and only within one task's scope. That narrow window limits lateral movement (hopping between resources) and privilege escalation after unauthorized access to a cloud account.
Halting privilege creep
Privilege creep happens when permissions pile up as developers change roles and projects. The usual culprit is a temporary grant nobody remembers to remove. JIT access makes expiry the default, so access never outlives its purpose.
Streamlining compliance and audit posture
Time-bound JIT access produces per-session evidence: who requested access, what they touched, when, and for how long. That record supports evidence for SOC 2 logical access criteria (CC6.1–CC6.3), ISO/IEC 27001:2022 Annex A control 8.2 (privileged access rights), and the NIST SP 800-207 per-session access tenet.
Maintaining engineering velocity
Manual access tickets push engineers toward workarounds like shared admin keys. ChatOps approvals make JIT access faster than the workaround. An engineer requests access in Slack or Microsoft Teams, policy checks the on-call schedule, and approval lands in seconds.
Zero Trust Security: Core Pillars and How to Implement
Learn how to implement zero trust security with clear pillars, a practical roadmap, and tactics that solve challenges and cut risk across cloud environments.
もっと読む
How just-in-time access works across cloud infrastructure
Whether you build it or buy it, just-in-time access runs through the same four phases. Cloud-specific details mostly affect how credentials get created and expire.
Phase 1: Request and context collection
Every JIT access request starts with the requester signing in through single sign-on (SSO) with multi-factor authentication (MFA).
The request names a scope, such as an account, a role, or a specific Amazon Resource Name (ARN). It also carries a justification like an incident ID, plus a session TTL. Good tooling pre-fills most of this from the alert that triggered the request.
Phase 2: Policy and risk evaluation
Next, automated checks look at the requester's team, on-call status, and device posture. They also weigh the target: production versus sandbox, and its data classification.
Attribute-based access control (ABAC) fits this phase because policies can read those attributes directly. It builds on role-based access control (RBAC), which still defines the roles people can request. The evaluation then routes the request to auto-approval, a peer, or the resource owner.
Phase 3: Ephemeral provisioning
Once approved, the system creates credentials on the fly, and nothing permanent attaches to the identity. Each platform implements that idea with its own building blocks:
AWS: AWS Security Token Service (STS) issues a temporary role session through AssumeRole or a federated variant such as AssumeRoleWithSAML.
Azure: Microsoft Entra Privileged Identity Management (PIM) keeps assignments eligible until activation, which can require MFA, justification, or approval. Microsoft Entra ID Governance access packages grant time-limited assignments that expire automatically.
Google Cloud: Privileged Access Manager handles request-and-approve temporary elevation. IAM Conditions can also expire a grant with a Common Expression Language (CEL) time check on request.time.
Kubernetes: RoleBindings don't carry an expiration field, so human and machine access need different patterns.
For humans, enforce Kubernetes JIT at the authentication layer. The cluster trusts short-lived OpenID Connect (OIDC) tokens whose group claims come from your IdP, so temporary IdP group membership maps to an existing RoleBinding. Alternatively, an operator or dynamic admission controller creates temporary RoleBindings and removes them at expiry.
Machine JIT is simpler in Kubernetes because the platform handles it natively. Bound service account tokens from the TokenRequest API default to a 1-hour lifespan, and the kubelet refreshes them automatically.
Phase 4: Automated revocation and audit trails
Credentials expire when the TTL runs out, with no cleanup ticket required. To end a session early, AWS lets you revoke active sessions for a role, which denies any credentials issued before that moment. Session activity lands in AWS CloudTrail, Azure Activity Log, or Google Cloud Audit Logs. The JIT system ties each entry to its request and approval. When a reviewer asks who changed a setting and why, a single audit log query on the session tag answers it.
Plan for break-glass access too. This is emergency access that skips approval when the normal path is down. Keep two or three emergency accounts with phishing-resistant MFA and vaulted credentials. Time-box every use, alert on it, and review it afterward.
Watch 12-min demo
Learn what makes Wiz the platform to enable your cloud security operation
Core implementation models for just-in-time access
Most just-in-time access programs mix three models. The right choice depends on how fast access must arrive, how much infrastructure you'll run, and how detailed your audit trail must be.
Temporary role elevation: The identity assumes a higher-privilege role on demand through the cloud's security token service. Temporary IAM roles fit this model, and credentials expire at the role's session limit.
Ephemeral credential generation: A certificate authority or token issuer creates short-lived SSH certificates, Kubernetes client certificates, or single-use tokens. When the session ends, no reusable secret remains.
Just-in-time group membership: The system temporarily adds the user to an elevated IdP group that maps to cloud roles, then removes them at expiry. It's the most familiar pattern for teams already running IdP-driven RBAC.
Here's how the three compare in day-to-day use:
| Model | Latency | Operational complexity | Multi-cloud flexibility | Audit granularity |
|---|---|---|---|---|
| Temporary role elevation | Seconds (low) | Low to medium | Medium (per-cloud STS semantics) | High (per-session CloudTrail entries with session name and tags) |
| Ephemeral credentials | Seconds | Medium to high (you run a CA or token issuer) | High (works across SSH, Kubernetes, and databases) | High (per-certificate identity) |
| JIT group membership | Minutes, up to 30–40 with SCIM sync | Low | High (one IdP fronts all clouds) | Medium (group-level, so pair with session logs) |
Group membership is often the easiest starting point because it reuses your IdP. The catch is System for Cross-domain Identity Management (SCIM) sync latency, commonly 30–40 minutes depending on the IdP's provisioning interval. That's too slow for an on-call engineer mid-incident, so put emergency and sensitive production paths on role elevation, which also gives sharper per-session logs.
Private Cloud Security: Core Principles & Risks
Private cloud security is a term that describes the tools and techniques used to secure private cloud environments.
もっと読む
Implementing ephemeral cloud access: A practical configuration blueprint
Here's how JIT access works during a real incident. At 2 a.m., a latency alert fires on a production database, and the on-call engineer requests the prod-db-diagnostics role in Slack with the incident ID.
Policy confirms they're on call and auto-approves a read-and-diagnose role for 60 minutes. Their IdP session assumes the role and passes session tags for the incident and the approver. When the hour ends, the credentials stop working, and CloudTrail links every API call to the incident.
The trust policy below controls who can assume the role and what they must bring. It trusts a SAML identity provider, requires the AWS sign-in audience, and only accepts sessions tagged with an incident ID that starts with INC-.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::111122223333:saml-provider/ExampleIdP"
},
"Action": [
"sts:AssumeRoleWithSAML",
"sts:TagSession"
],
"Condition": {
"StringEquals": {
"SAML:aud": "https://signin.aws.amazon.com/saml"
},
"StringLike": {
"aws:RequestTag/incident-id": "INC-*"
}
}
}
]
}Then pin the role's maximum session length with one command:
aws iam update-role --role-name prod-db-diagnostics --max-session-duration 3600Maximum session duration is a role setting, so it lives outside the trust policy. It defaults to 1 hour and can be raised to 12 hours, so setting 3600 explicitly keeps the window from quietly widening later. Role chaining (one role assuming another) also caps sessions at 1 hour.
The sts:TagSession action lets your IdP pass session tags. With SAML, the IdP sends each tag as an attribute such as https://aws.amazon.com/SAML/Attributes/PrincipalTag:incident-id, and the condition rejects sessions without a matching value.
SAML trust policies are only one route. Many teams run cloud JIT through AWS IAM Identity Center permission sets, where session duration is configured on the permission set itself. Workloads and custom brokers often use OIDC federation through sts:AssumeRoleWithWebIdentity instead, and the same short-session and tagging logic carries over.
Keep the permissions policy (not shown) scoped to read-only diagnostics on that one database. Then check the role's effective permissions, meaning what it can actually reach once inherited policies, permissions boundaries, and cross-account trust paths count. An attached managed policy can still carry write access.
Best practices for building an effective JIT access program
A JIT access program works when engineers find it faster than the workarounds.
Establish sensible session durations: Match TTLs to real tasks, such as 30–60 minutes for production write or diagnostic access. Easy renewal keeps people from requesting all-day windows.
Automate standard low-risk elevation: Pre-approve read-only diagnostic tasks so engineers aren't stuck waiting. Save human approval for production writes and sensitive data.
Include non-human identities: Extend ephemeral credentials to non-human identities such as CI/CD pipelines, containers, and AI agents. GitHub Actions OIDC, for example, reaches cloud resources without stored long-lived secrets.
Correlate access logs with runtime activity: Confirm elevated sessions stay within their intended scope by pairing session logs with identity and resource context. A diagnostic session that suddenly calls iam:CreateAccessKey should trigger an alert.
In practice, static credentials on workloads, pipelines, and automated agents are often the biggest blind spot in a JIT program. Most JIT tooling is built around a human request flow, so machine keys never pass through it. AI agents fit the same fix: give each one short-lived credentials scoped to the task it's running.
Leftover long-lived keys and break-glass roles also bypass the broker, so treat them as part of your JIT scope. A month after the Shai-Hulud 2.0 npm attack, Wiz Research found only about 50% of leaked cloud credentials revoked, versus over 95% of GitHub tokens. Short-lived credentials would have expired on their own instead of waiting on rotation, which is why static cloud secrets should become ephemeral ones.
Secure cloud identities and access from code to runtime
JIT access shrinks how long privileges exist. You still need to know which standing privileges to convert first and whether removed access stays gone.
Wiz is the visibility, prioritization, and continuous governance engine around JIT rather than a request broker, working alongside tools such as Microsoft Entra PIM, AWS IAM Identity Center, Okta, and privileged access management brokers. Agentless coverage across cloud, SaaS, on-prem, and hybrid environments gives you the base layer of identity security in the cloud. From there, Wiz supports each stage of the JIT lifecycle:
Prevention in code: Wiz Code catches hardcoded secrets and over-permissive IAM in code and infrastructure as code before deployment.
Discovery: Wiz cloud infrastructure entitlement management (CIEM) maps effective permissions across human, machine, and AI agent identities. It flags standing, inactive, and over-privileged roles to convert.
Prioritization: The Wiz Security Graph connects those permissions to network exposure, vulnerabilities, and sensitive data. Your team removes standing access on high-risk attack paths first.
Dynamic visibility: Wiz models eligible and dynamic assignments, such as Entra PIM for Groups. You see what an identity could activate alongside what's active now.
Continuous governance: Wiz detects shadow access that bypasses JIT, such as long-lived static API keys and unrevoked break-glass accounts. That confirms converted access stays removed.
Runtime detection: Wiz Defend detects suspicious identity activity in real time with cloud context, so a session drifting from its task stands out.
Wiz runs just-in-time administration internally, as described in the Wiz Trust Center.
Get a demo to see how Wiz puts identity context behind every access decision.
Secure cloud access and identities across your environments
Watch Wiz connect effective permissions to network exposure, vulnerabilities, and sensitive data in your environment. Leave with a clear view of which access to move to JIT and how to confirm it stays removed.
