Implementing JIT Access in AWS, Azure, GCP: A detailed Guide

Imagine leaving the master key to every room in your office building hanging permanently on the front desk. Anyone who walks in — employee, visitor, or intruder — can pick it up and go anywhere. That is precisely what standing privileges do to your cloud environment. A developer granted permanent administrator access to production AWS resources, an engineer with always-on Owner rights in Azure, a service account with full GCP project permissions — each is an open door waiting to be walked through.

According to the IBM Cost of a Data Breach Report 2025, breaches involving stolen or compromised credentials are the most common attack vector and carry an average cost of $4.45 million per incident. In cloud environments, the blast radius of a compromised over-privileged identity is not limited to one server — it can span regions, accounts, and entire organizational hierarchies within minutes.

Just-in-Time (JIT) access is the architectural response to this reality. Rather than granting permanent privileged roles, JIT elevates users to the permissions they need, for only as long as they need them, with a full audit trail of every request, approval, and action taken. It is not a product you buy off the shelf — it is a capability you build, using a combination of cloud-native tools, approval workflows, and governance policies.

This guide delivers exactly that: a practical, platform-specific roadmap for implementing JIT access across AWS, Azure, and GCP. Whether you are a CISO building the business case, a Cloud Security Architect designing the controls, or a Security Engineer doing the implementation, you will find the depth and specificity you need here.

Foundational Concepts

What JIT Access Actually Means in the Cloud

Just-in-Time access is a privilege management model in which elevated permissions are granted dynamically, on demand, and expire automatically after a predefined period. In cloud environments, this means a user or service account does not hold a privileged IAM role permanently. Instead, they request elevation, receive approval (human or automated), assume the role for a bounded session, and have their access revoked the moment the session ends or the time-to-live (TTL) expires.

This is fundamentally different from traditional access models, where roles are assigned once and never revisited. JIT treats privilege as a transaction, not a property.

Why Standing Privileges Are the #1 Attack Vector in Cloud Breaches

Standing privileges create a permanently exploitable attack surface. When an identity — human or non-human — holds elevated permissions indefinitely, any compromise of that identity (through phishing, credential stuffing, insider threat, or API key leakage) immediately grants an attacker full, unrestricted access. There is no time window to detect and contain the breach before damage is done.

The Verizon 2024 Data Breach Investigations Report consistently identifies credential abuse as a top initial access technique. In cloud environments, this is amplified because IAM roles are the control plane — whoever controls them controls the entire infrastructure.

JIT vs. PAM vs. RBAC — How They Relate

These three concepts are complementary, not competing. Role-Based Access Control (RBAC) defines what roles exist and what permissions each role carries. Privileged Access Management (PAM) is the broader discipline of securing, managing, and monitoring privileged accounts — think vaulted credentials, session recording, and privileged session management. JIT access is a specific implementation pattern within the PAM discipline that ensures privileged roles are assumed temporarily rather than held permanently.

Think of it this way: RBAC builds the permission structure, PAM governs how privileged access is managed, and JIT controls when and for how long that access is active.

JIT’s Role in Zero Trust Architecture

NIST SP 800-207, the authoritative Zero Trust Architecture standard, is explicit: access to resources should be determined dynamically and re-evaluated continuously. The principle of “never trust, always verify” applies directly to privileged access. A user who authenticated this morning is not automatically trusted to have administrator access this afternoon.

JIT access is one of the most direct implementations of Zero Trust for IAM. By requiring explicit request, verification, approval, and time-bounding for every privilege elevation, JIT enforces continuous validation rather than implicit trust based on a previously assigned role.

Key Principles: Least Privilege, Time-Bound, Just-Enough-Access

Three principles underpin every effective JIT implementation:

Least Privilege: Grant only the minimum permissions required to complete a specific task — nothing more.
Time-Bound Access: Every privilege elevation has an expiry. Access that is not explicitly renewed dies automatically.
Just-Enough-Access (JEA): Paired with least privilege, JEA ensures the scope of access is scoped to the exact resource, action, and duration needed — not a broad administrative role when a narrower one will do.

The Real Risk Landscape: Why JIT Is Non-Negotiable

Credential Theft via Over-Privileged IAM Roles

The economics of cloud credential theft are deeply unfavorable for defenders. Attackers need to find and exploit one over-privileged identity; defenders need to secure every identity across every account, region, and service.

The IBM Cost of a Data Breach Report places the average cost of a credential-based breach at $4.45 million, and cloud environments consistently show that over-privileged IAM roles are the most commonly exploited entry point in post-breach forensics.

A compromised AWS access key attached to an over-privileged IAM user can enumerate S3 buckets, exfiltrate data, spin up cryptomining infrastructure, and delete CloudTrail logs — all within the same API session. The same pattern applies to Azure service principals and GCP service account keys. Standing privilege means the window of opportunity for an attacker is unlimited.

Lateral Movement Enabled by Standing Admin Access

In cloud environments, lateral movement does not look like an attacker jumping between servers. It looks like an attacker assuming IAM roles across accounts, escalating permissions through policy misconfigurations, and pivoting between services using the credentials of an already-compromised identity. Standing admin access is the expressway for this kind of movement. With JIT, every privilege elevation is an explicit, logged, time-bounded event — lateral movement using a JIT-issued token has a built-in expiry that limits the blast radius.

Compliance Mandates That Require JIT

Multiple major compliance frameworks either explicitly require or strongly imply JIT as a control:

SOC 2 (CC6.3): Requires that access to data and systems is restricted to authorized users and that access is reviewed and revoked when no longer needed. JIT operationalizes this control by making privilege temporary by design.
ISO 27001 (A.9 — Access Control): Mandates formal processes for the provisioning and revocation of access rights, with particular attention to privileged access management.
PCI-DSS v4.0 (Requirement 7): Requires that access to system components and cardholder data is restricted to only those individuals whose job requires such access. Permanent privileged access directly conflicts with this requirement.
NIST CSF 2.0 (Identity Management, PR.AC): Emphasizes managing identities and credentials for authorized devices, users, and processes, with explicit reference to least-privilege and need-to-know principles.

Beyond compliance checkboxes, regulators are increasingly scrutinizing cloud privilege management during audits. JIT provides the documented, time-stamped approval trail that auditors require.

The Cost of Inaction

Credential breaches are the costliest category of cloud incidents. But the cost is not only financial — regulatory fines, reputational damage, customer trust erosion, and the operational cost of incident response multiply the impact. JIT is not an expensive control to implement; the native tooling across all three major clouds is included in standard service tiers. The cost of not implementing it is orders of magnitude higher.

Core Technical Components for JIT Implementation

Approval Workflows

A JIT system without an approval workflow is just standing access with extra steps. The approval layer is what ensures that every privilege elevation is intentional, justified, and accountable. Effective approval workflows define who can approve requests (a designated approver, a team lead, a security operations role), how quickly approval must happen (service-level agreements on MTTA — Mean Time to Approve), and where every approval decision is recorded.

Most enterprise implementations use tiered approval: low-risk, pre-approved request types (e.g., read-only access to a specific S3 bucket) can be auto-approved with enhanced logging; high-risk requests (e.g., IAM administrator elevation) require human approval with a justification ticket number.

Time-to-Live (TTL) on Permissions

The TTL is the heartbeat of JIT. Every privilege elevation must have a defined expiry — typically ranging from 1 hour for routine tasks to 8 hours for extended maintenance windows, with anything beyond that requiring explicit re-justification. All three cloud platforms support time-bound role assignments natively. AWS STS tokens can be issued with session durations of 15 minutes to 12 hours. Azure Entra PIM allows eligible role activation for up to 24 hours (configurable). GCP Cloud PAM grants can be set to expire on a custom schedule. The key operational discipline: TTLs should be set as short as practically possible for the task at hand.

Session Recording and Monitoring

Knowing that JIT access was granted is table stakes. Knowing what happened during the session is what makes JIT forensically valuable. Session recording captures every command executed, every API call made, and every resource accessed during a JIT-elevated session. AWS Systems Manager Session Manager provides full session logging to S3 and CloudWatch. Azure Bastion offers session recording for VM access. GCP’s BeyondCorp Enterprise and Cloud Audit Logs provide comprehensive API-level visibility. This data feeds directly into SIEM platforms for real-time anomaly detection and post-incident forensics.

Break-Glass Accounts

JIT approval workflows are a control, and like all controls, they can become a bottleneck during genuine emergencies. Break-glass accounts are pre-configured emergency access identities with elevated permissions that bypass the standard JIT workflow. The critical governance requirements: break-glass account credentials must be vaulted (ideally in a physical safe or offline store), every invocation must trigger an immediate alert to the security team, and every break-glass session must be reviewed within 24 hours. Break-glass is not a get-out-of-jail-free card — it is an audited emergency bypass with full accountability.

MFA and Re-Authentication at Elevation

Requiring MFA at the point of JIT elevation — not just at initial login — is a critical defense against session hijacking and token theft. Even if an attacker steals an authenticated session, they cannot elevate privileges without completing a fresh MFA challenge. All three platforms support this: AWS IAM condition keys can enforce MFA for AssumeRole calls, Azure Conditional Access Policies can require step-up authentication for PIM activation, and GCP’s Context-Aware Access enforces re-authentication for sensitive resource access.

Auto-Revocation Mechanisms

JIT sessions must be terminated automatically when their TTL expires — this should require zero manual action. Auto-revocation should also be triggered by anomalous behavior (a JIT session suddenly accessing resources outside its declared scope), policy violations, or administrative override. Building auto-revocation into your SIEM/SOAR pipeline means that a detected anomaly during a JIT session can result in automatic role revocation within seconds, dramatically limiting the blast radius of a compromised session.

SIEM and SOAR Integration

JIT events — request submitted, approval granted, session started, session ended, anomaly detected, session revoked — are high-fidelity security signals that belong in your SIEM. Integrating JIT event streams with platforms like Splunk, Microsoft Sentinel, or Chronicle enables real-time correlation: if a JIT session for database access is suddenly making IAM policy changes, that is a detection rule that should fire immediately. SOAR playbooks can then automatically revoke the session, notify the approver, and open an incident ticket — all without human intervention.

Platform-Specific Deep Dives

AWS: Building JIT Access with Native Tooling

AWS IAM Identity Center and Permission Sets

AWS IAM Identity Center (formerly AWS SSO) is the recommended starting point for human identity JIT access in AWS. It provides centralized identity management across multiple AWS accounts, with Permission Sets defining the IAM policies attached to a user when they access a specific account. For JIT, the key capability is that Permission Sets can be assigned temporarily — a user requests access, the assignment is made, the session is used, and the assignment is removed. This integrates naturally with AWS Organizations and supports SCIM-based provisioning from external identity providers like Okta, Azure AD, or Google Workspace.

STS AssumeRole for Time-Limited Tokens

AWS Security Token Service (STS) AssumeRole is the technical mechanism that powers JIT privilege elevation in AWS. When a user or service needs elevated access, they call sts:AssumeRole for a specific IAM role, receiving temporary credentials (access key, secret key, session token) with a configurable session duration of between 15 minutes and 12 hours.

Critically, IAM trust policies can enforce conditions on AssumeRole calls: requiring MFA (aws:MultiFactorAuthPresent: true), restricting the source IP, requiring specific tag values on the requesting principal, and setting maximum session durations. This is the foundation of all JIT implementations on AWS — whether you use native tooling or a third-party platform, it is all AssumeRole under the hood.

IAM Access Analyzer for Policy Validation

Before granting JIT access to any role, you need to know what that role actually permits — including unintended permissions from policy inheritance and resource-based policies. AWS IAM Access Analyzer does exactly this: it analyzes IAM policies, identifies overly permissive grants, flags external access to resources, and generates policy findings that can be remediated before roles are made available for JIT elevation. Access Analyzer should be a mandatory gate in your JIT onboarding process: no role enters the JIT catalog without an Access Analyzer validation pass.

Systems Manager Session Manager for JIT Server Access

For privileged access to EC2 instances and on-premises servers managed by AWS Systems Manager, Session Manager provides a JIT-compatible access model without requiring bastion hosts or open SSH/RDP ports. Sessions are initiated through the AWS Console or CLI, logged entirely to S3 and CloudWatch Logs, and can be restricted using IAM condition keys to specific instance tags, time windows, and MFA requirements. This is the AWS-native answer to privileged server access — it eliminates the credential sprawl of SSH keys while providing full session auditability.

Third-Party Solutions on AWS

For organizations requiring more sophisticated approval workflows, entitlement catalogs, or multi-cloud JIT unification, several enterprise platforms integrate deeply with AWS:

Cloudanix: Cloudanix Just In Time (JIT) IAM ensures that your team gets the right access only when needed — no more, no less. Boost security, reduce IAM risks, and make access approvals seamless across your organization.
CyberArk Privilege Cloud: Provides full PAM capabilities on top of AWS, including credential vaulting, session isolation, and threat analytics integrated with CloudTrail.
BeyondTrust Privileged Remote Access: Delivers JIT access for both AWS infrastructure and application-level privileged sessions, with granular approval workflows and full session recording.
Ermetic (now Tenable Cloud Security): Specializes in cloud identity risk management, with automated JIT access provisioning based on discovered entitlements and usage analytics.

Azure: Microsoft Entra ID PIM — The Gold Standard for JIT

Entra ID PIM and Eligible vs. Active Assignments

Microsoft Entra ID Privileged Identity Management (PIM) is widely regarded as the most mature native JIT solution available on any cloud platform. PIM introduces a critical distinction between Active assignments (the user permanently holds the role) and Eligible assignments (the user can activate the role on demand, subject to approval and MFA). The shift from Active to Eligible assignments is the foundational move in any Azure JIT implementation. An eligible assignment means the role exists in the user’s profile but is dormant — it must be explicitly activated, triggers an approval workflow if configured, and expires when the TTL is reached.

PIM covers Azure RBAC roles (Contributor, Owner, specific service roles), Entra ID directory roles (Global Administrator, Privileged Role Administrator), and Groups (enabling group-based JIT access for application permissions). This breadth makes it the most comprehensive JIT surface on Azure.

Time-Bound Role Activation

When a user activates an eligible PIM assignment, they specify a duration (up to a configured maximum, typically 1–8 hours), provide a justification, and optionally reference a ticket number. PIM records the activation start time, duration, justification, approver identity, and MFA completion status — all queryable through Azure Monitor and exportable to Microsoft Sentinel. At the end of the activation window, the role reverts to eligible automatically. No manual deactivation required, no cleanup scripts needed.

Conditional Access Policies Tied to JIT Elevation

The power of Azure’s JIT implementation comes from its deep integration with Conditional Access. PIM activation can be gated by Conditional Access policies that evaluate device compliance state, location, sign-in risk score (from Entra ID Protection), and MFA completion — all at the moment of elevation, not just at login. This means an attacker who steals a valid session token still cannot activate a PIM eligible role if they are operating from an unknown device or flagged IP, because the Conditional Access evaluation happens fresh at activation time.

Microsoft Defender for Cloud — JIT VM Access

For privileged access to Azure virtual machines, Microsoft Defender for Cloud provides JIT VM Access — a capability that dynamically opens specific management ports (RDP on 3389, SSH on 22) for a defined time window and source IP, then automatically closes them when the window expires. The NSG rules are created and removed automatically; the requesting user’s IP is the only source permitted. This eliminates the exposure of permanently open management ports while maintaining operational flexibility. JIT VM Access requests are logged in the Azure Activity Log and Defender for Cloud security alerts.

Third-Party Solutions on Azure

Saviynt Security Manager: Provides identity governance capabilities on top of Azure, including fine-grained entitlement management, SoD (Segregation of Duties) conflict detection, and campaign-based access certification integrated with PIM.
SailPoint IdentityNow: Delivers enterprise-scale identity lifecycle management with JIT access request workflows that integrate with Entra ID PIM, supporting multi-cloud governance from a single control plane.

GCP: Cloud PAM and the Zero Trust Access Model

1. Google Cloud PAM — Generally Available in 2024

Google Cloud Privileged Access Manager (Cloud PAM) reached General Availability in 2024, establishing GCP’s native JIT capability on par with AWS IAM Identity Center and Azure PIM. Cloud PAM allows organizations to define Entitlements — named, pre-configured privilege grants that specify which IAM roles are elevated, on which resources, for what maximum duration, with what approval requirements, and under what conditions. Users request access against an Entitlement, approvers receive notifications, and upon approval, the IAM bindings are applied automatically for the duration of the grant, then removed.

Cloud PAM is built on top of GCP’s IAM and integrates natively with Cloud Audit Logs, ensuring that every request, approval, activation, and expiry is a logged, queryable event. It supports both human user JIT and service account JIT, which is particularly valuable given GCP’s heavy reliance on service accounts for workload identity.

2. IAM Recommender and Policy Analyzer

Before building your JIT entitlement catalog on GCP, you need to understand what permissions your principals are actually using. GCP’s IAM Recommender uses machine learning to analyze 90 days of audit log data and recommend role downsizing for principals whose permissions significantly exceed their observed usage. Policy Analyzer complements this by allowing you to query who has access to what across your GCP organization, making it possible to identify standing admin roles that should be converted to JIT entitlements. These two tools together form the discovery layer for your GCP JIT program.

3. Workforce Identity Federation for JIT External Access

For organizations using external identity providers (Okta, Azure AD, Ping Identity) rather than Google Workspace accounts, Workforce Identity Federation enables those external identities to authenticate to GCP and assume JIT-granted roles without requiring Google accounts. This is critical for multi-cloud and federated identity scenarios: your existing corporate identity becomes the principal that requests and receives JIT grants in GCP, without duplicating identity management.

4. BeyondCorp Enterprise for Zero-Trust JIT Access

Google’s BeyondCorp Enterprise extends JIT access to application-level access control using context-aware policies that evaluate device health, user identity, and network context at every access request. For GCP workloads, BeyondCorp can gate access to Cloud Console, internal applications, and GCP APIs based on real-time context signals — functioning as the zero-trust enforcement layer around JIT grants. A user with an active Cloud PAM grant who accesses GCP from a non-compliant device can be blocked at the BeyondCorp layer even while the IAM grant is technically active.

5. Cloud Audit Logs for JIT Session Visibility

GCP’s Cloud Audit Logs are the forensic backbone of any GCP JIT implementation. Admin Activity logs capture every IAM policy change — including Cloud PAM grant applications and revocations. Data Access logs capture API calls to GCP resources during JIT sessions. These logs feed into Google’s Security Command Center and Chronicle SIEM for real-time detection and historical investigation. For JIT programs, configuring log sinks to BigQuery enables long-term retention and complex analytical queries over JIT session data — essential for compliance reporting and security analytics.

Platform Comparison: JIT Capabilities at a Glance

Feature / Capability	AWS	Azure	GCP
Primary JIT Tool	IAM Identity Center + STS	Entra ID PIM	Cloud PAM (GA 2024)
Native Approval Workflow	Limited (needs Lambda/Step Functions)	Yes (built-in)	Yes (built-in)
Time-Bound Role Elevation	STS AssumeRole (max 12h)	Eligible Assignments (configurable)	Grants with TTL (configurable)
Session Recording	Systems Manager Session Manager	Azure Monitor / Defender	Cloud Audit Logs + BeyondCorp
Break-Glass Support	IAM root + SCP guardrails	Emergency Access accounts	Super Admin + Org Policy
MFA Enforcement at Elevation	IAM Condition Keys	Conditional Access Policy	Context-Aware Access (BeyondCorp)
Policy Validation Tool	IAM Access Analyzer	Azure Policy / Defender for Cloud	IAM Recommender + Policy Analyzer
SIEM Integration	CloudTrail + Security Hub	Microsoft Sentinel	Chronicle + Security Command Center
Recommended 3rd-Party Tool	CyberArk / BeyondTrust / Ermetic	Saviynt / SailPoint	BeyondTrust / SailPoint

Governance, Operations, and Common Pitfalls

Building the JIT Access Request and Approval Policy

A JIT implementation without a governing policy is a technical control without organizational teeth. Your JIT policy must define the entitlement catalog (what roles are available for JIT elevation), the approval tiers (which roles require human approval versus auto-approval with enhanced logging), the maximum TTLs per role tier, the justification requirements (free text, ticket number, or both), and the break-glass invocation procedure. This policy should be version-controlled, reviewed quarterly, and aligned with your overall IAM governance framework.

Defining Entitlement Catalogs per Platform

The entitlement catalog is the curated list of privileged roles available for JIT elevation. Not every role in your cloud environment should be JIT-eligible — some are too sensitive (root/Owner/Org Admin) and require break-glass procedures, while others are not privileged enough to warrant JIT overhead. The catalog should be built through an access review process: identify all standing privileged assignments, classify them by risk, and determine which should be converted to JIT entitlements. Start with your highest-risk roles — cloud administrator, IAM administrator, database administrator — and expand iteratively.

Common Implementation Mistakes

Even well-intentioned JIT programs fail due to avoidable implementation errors:

Setting TTLs too long: An 8-hour TTL for a task that takes 30 minutes is standing access with extra paperwork. Right-size TTLs to the actual task duration and enforce TTL reduction through policy reviews.
No approval workflow: Auto-approving all JIT requests eliminates the human verification layer that makes JIT meaningful. Even a lightweight approval step — a manager acknowledgment by email — adds accountability.
Missing audit log coverage: If your JIT sessions are not generating complete audit trails, you cannot detect anomalies, investigate incidents, or pass compliance audits. Verify log coverage before go-live.
Forgetting non-human identities: Service accounts, CI/CD pipeline identities, and automation service principals are frequently granted standing admin access and overlooked in JIT programs. They represent a significant and often underestimated risk — apply JIT principles to workload identities using short-lived tokens and Workload Identity Federation.
No regular entitlement catalog review: JIT programs can accumulate stale entitlements — roles that are JIT-enabled but no longer needed. Quarterly reviews keep the catalog clean and defensible during audits.

Multi-Cloud JIT: Unifying Policy Across AWS, Azure, and GCP

Organizations operating across multiple clouds face a significant governance challenge: each platform has its own JIT tooling, its own audit log format, and its own approval workflow. The goal of multi-cloud JIT governance is unified policy with platform-specific execution.

Practical approaches include: deploying a third-party PAM platform (Cloudanix, CyberArk, BeyondTrust, SailPoint) that provides a single JIT request interface while executing platform-native elevation under the hood; centralizing audit log aggregation in a single SIEM (Splunk or Microsoft Sentinel both support multi-cloud log ingestion); and standardizing entitlement catalog definitions so that the same governance policy applies regardless of which cloud the role lives in.

The key principle: do not attempt to build a custom multi-cloud JIT abstraction layer from scratch. Use the native tools on each platform, and unify at the governance and monitoring layer.

Metrics and Success Measurement

You cannot manage what you do not measure. JIT programs must be backed by a clear set of metrics demonstrating security improvements, operational efficiency, and compliance posture.

Metric	What It Measures	Target Benchmark
% Reduction in Standing Privileges	How many permanent admin roles replaced with JIT	> 80% within 6 months
Mean Time to Approve (MTTA)	Speed of JIT approval workflows	< 5 minutes for pre-approved tiers
JIT Session Anomaly Detection Rate	Unusual access patterns flagged during JIT sessions	> 95% detection via SIEM
Break-Glass Invocation Frequency	How often are emergency accounts used	< 2 per quarter; every use reviewed
Compliance Audit Pass Rate	Post-JIT control attestation success	100% for SOC 2 / PCI-DSS controls
Privilege Escalation Attempt Rate	Unauthorized elevation attempts blocked	Trending to 0; any spike = incident

Report these metrics monthly to security leadership and quarterly to executive stakeholders. Trend lines matter more than point-in-time values — a consistently decreasing standing privilege count and a decreasing MTTA demonstrate that the program is maturing and operationally sustainable.

Conclusion

Just-in-Time access is not a future-state aspiration for cloud security programs — it is a present-day necessity. The threat landscape, the compliance environment, and the architectural principles of Zero Trust all converge on the same conclusion: standing privileges are an unacceptable risk in cloud environments, and the tools to eliminate them are available on every major platform today.

AWS, Azure, and GCP each provide mature, production-ready native tooling for JIT implementation. Microsoft Entra PIM leads in approval workflow sophistication. GCP Cloud PAM brings strong entitlement management to Google Cloud. AWS’s combination of IAM Identity Center, STS, and Session Manager delivers flexible JIT across compute and identity planes. There is no reason to wait for a breach to discover that your standing privileges were the open door.

The path forward is iterative, not big-bang. Start with your highest-risk roles: cloud administrators, IAM administrators, and database administrators. Convert them to JIT-eligible assignments on your platform of choice. Instrument the audit logs, connect to your SIEM, establish the approval policy. Then expand the entitlement catalog, bring in workload identities, and unify governance across clouds.

Your Action for This Week: Start your JIT audit today — run IAM Access Analyzer on AWS, review Active PIM assignments on Azure, or use GCP IAM Recommender to identify over-privileged roles. Find your standing privileges before attackers do. Every standing admin role you convert to JIT is an attack surface you have permanently closed.

How to Implement JIT Access in AWS, Azure & GCP: A Step-by-Step Guide for Security Leaders