Integrate Just In Time (JIT) Access with AWS Identity Center

Updated August 2026: This article was originally published in March 2024 and has been comprehensively updated to reflect AWS Identity Center’s latest features including trusted identity propagation, multi-account JIT governance, and integration patterns for AI coding agents as of 2026.

Introduction: Why JIT Access Matters in a Zero Trust World

The security perimeter has fundamentally shifted. Network is not the perimeter anymore — instead, it’s IAM. Every API call, every console login, every service-to-service interaction begins with an identity assertion. In this reality, standing privileges — persistent access that exists whether or not someone is actively using it — represent the single largest attack surface in modern cloud environments.

Zero Trust architecture demands that access is never assumed, always verified, and strictly time-bounded. This is where Just-In-Time (JIT) access becomes the operational backbone of a Zero Trust IAM strategy. Rather than pre-provisioning roles and permissions that sit idle for weeks or months (accumulating risk with every passing hour), JIT access grants the exact permissions needed, only when needed, and automatically revokes them when the task is complete.

The combination of JIT access with AWS Identity Center creates a powerful control plane: centralized identity governance meets dynamic, ephemeral privilege escalation. For platform engineering teams managing dozens or hundreds of AWS accounts, this integration eliminates the impossible choice between security and developer velocity.

In this guide, we will walk through the architecture of IAM JIT with AWS Identity Center, explain how the request-approve-grant-revoke lifecycle works, cover AWS’s newer capabilities like Trusted Identity Propagation, address multi-account governance at scale, and show how Cloudanix operationalizes the entire workflow — including extending JIT to AI coding agents. If you want foundational context, our earlier blog post covers the core JIT concepts in detail.

What is AWS Identity Center (Formerly AWS SSO)?

AWS Identity Center is the centralized service for managing workforce identities and their access to AWS accounts and applications within an AWS Organization. It replaced the older AWS SSO branding and has evolved significantly since then.

At its core, AWS Identity Center provides:

• A single pane of glass for workforce access: One place where administrators define who can access which AWS accounts and with what permission sets.
• Federation with external identity providers: Native integration with Azure Entra ID, Google Workspace, Okta, and any SAML 2.0 or SCIM-compatible provider.
• Permission Sets as reusable policies: Define IAM policy bundles once and assign them across multiple accounts without duplicating IAM roles manually.
• SSO portal for end users: Engineers get a single login page listing all accounts and roles they can assume, eliminating credential juggling.

The critical insight for JIT architectures: AWS Identity Center’s permission set assignments are the control mechanism. When you assign a permission set to a user for a given account, that user can assume that role. When you remove the assignment, the access disappears. This assignment/de-assignment API is what JIT solutions automate.

Benefits of AWS Identity Center for JIT Architectures

Here are the key benefits that make AWS Identity Center the ideal substrate for JIT access:

• Centralized Identity Management: AWS Identity Center consolidates identity governance across your entire AWS Organization. Instead of managing IAM users and roles account-by-account, you define access centrally. This is a prerequisite for effective JIT — you cannot enforce time-bounded access if privilege grants are scattered across hundreds of accounts with no unified control.

• Native SSO and Federation: Identity Center integrates with all major Identity Providers, meaning your JIT workflow can leverage existing corporate identities. Users authenticate through their normal SSO flow; JIT just controls which permission sets appear on their SSO portal at any given moment.

• Permission Set Granularity: Permission sets allow you to define precise IAM policies — from read-only access to production databases to full administrative privileges for incident response. JIT eligibility can be configured per permission set, enabling fine-grained control over what can be requested on-demand versus what remains persistently assigned.

• Enhanced Security and Compliance: By combining Identity Center’s compliance capabilities with JIT’s ephemeral access model, organizations achieve continuous compliance. Every access grant has a paper trail: who requested it, why, who approved it, when it was provisioned, what was done during the session, and when it was revoked.

• API-Driven Architecture: Identity Center exposes APIs for managing account assignments programmatically, enabling external JIT orchestrators to automate the full lifecycle without manual intervention.

IAM JIT Architecture with AWS Identity Center

The architecture connects three planes: the identity plane (your IdP and AWS Identity Center), the control plane (the JIT orchestration layer that manages requests, approvals, and provisioning), and the data plane (the actual AWS accounts and resources being accessed).

Here is how the components interact:

1. Identity Provider (IdP) — Azure Entra ID, Google Workspace, Okta, or another SAML/SCIM provider federates identities into AWS Identity Center.
2. AWS Identity Center — Maintains the mapping of users/groups to permission sets and accounts. Acts as the enforcement point.
3. JIT Orchestrator (e.g., Cloudanix) — Receives access requests, routes them through approval workflows, calls Identity Center APIs to create/delete account assignments, and enforces time limits.
4. Notification Layer — Slack, Microsoft Teams, or email integrations for request/approval notifications.
5. Audit Layer — CloudTrail, Identity Center audit logs, and the JIT orchestrator’s own session recordings feed into your SIEM.

How JIT Works: The Request → Approve → Grant → Revoke Lifecycle

The JIT lifecycle is straightforward but rigorous:

Step 1 — Request: An engineer needs elevated access (for example, AdministratorAccess to a production account for incident response). They submit a request specifying the target account, the permission set, the desired duration, and a business justification.

Step 2 — Approve: The request routes to designated approvers (team lead, security team, or on-call manager). Approvers see the full context: who is requesting, what permission set, which account, for how long, and why. They approve or reject directly from Slack, Teams, or the JIT platform.

Step 3 — Time-Boxed Grant: Upon approval, the JIT orchestrator calls the AWS Identity Center API to create an account assignment — linking the user’s identity to the requested permission set for the specified account. The user immediately sees the new role appear in their SSO portal.

Step 4 — Active Session: The engineer assumes the role and performs their work. All API calls during this session are logged via CloudTrail and correlated with the JIT session for audit purposes.

Step 5 — Auto-Revoke: When the granted duration expires, the JIT orchestrator automatically removes the account assignment. The permission set disappears from the user’s SSO portal. No manual cleanup required.

This lifecycle ensures that privileged access exists only for the exact window it is needed — eliminating the risk of forgotten permissions, orphaned role assignments, and privilege accumulation over time.

Trusted Identity Propagation: End-to-End Identity Context

AWS introduced Trusted Identity Propagation in 2025, and it fundamentally changes how identity context flows through multi-tier applications. Previously, when a user accessed data through a chain of services (for example, a BI tool querying Redshift via a Lambda function), the downstream services only saw the service role — not the original user’s identity.

With Trusted Identity Propagation, the user’s identity token propagates through the entire call chain. This means:

• Fine-grained data access: Services like Redshift, S3, and Lake Formation can enforce row-level or column-level access based on the actual end user, not a shared service account.
• Complete audit attribution: Every action in the chain is attributed to the originating human identity, not an intermediary service role.
• JIT-aware downstream access: When a JIT session grants a user temporary elevated privileges, those privileges propagate correctly through service chains without requiring separate JIT grants at each tier.

For JIT architectures, Trusted Identity Propagation eliminates the gap where a user had JIT-granted access at the front door but downstream services still relied on over-privileged static service accounts. The identity context travels end-to-end, maintaining the least-privilege principle through every layer.

Multi-Account JIT Governance: Managing JIT Across 50+ AWS Accounts

Enterprise AWS environments routinely span 50, 100, or even 500+ accounts organized into OUs (Organizational Units) for workload isolation, environment separation (dev/staging/prod), and compliance boundaries. Managing JIT at this scale requires governance patterns beyond single-account workflows:

Hierarchical Eligibility Policies: Define JIT eligibility at the OU level. For example, all engineers in the platform team are eligible to request PowerUserAccess on any account within the infrastructure OU, but only on-call engineers can request AdministratorAccess on production OU accounts.

Tiered Approval Chains: Production accounts require multi-level approval (team lead + security), staging accounts require single approval, and development accounts can be auto-approved for limited permission sets. This tiered model balances security with velocity.

Cross-Account Visibility: Security teams need a single dashboard showing all active JIT sessions across every account — who has elevated access right now, in which account, with what permissions, and when it expires. This real-time visibility is non-negotiable for incident response.

Policy Guardrails via SCPs: Service Control Policies at the Organization level can constrain what permission sets are even eligible for JIT in specific OUs, providing a hard ceiling that no JIT approval can override.

Automated Compliance Reporting: At scale, manual audit is impossible. JIT governance must automatically generate reports showing: average session duration, approval response times, most-requested permission sets, and any sessions that hit their maximum duration limit (a potential signal of under-provisioned base access).

JIT for AI Coding Agents via MCP

The rise of AI coding agents — Claude Code, Cursor, GitHub Copilot, Kiro — introduces a new identity class that requires JIT governance. These agents operate on behalf of developers, executing code, accessing cloud resources, querying databases, and deploying infrastructure. Without JIT controls, they inherit whatever persistent permissions their host developer has, or worse, run with broad service account credentials.

Extending JIT to coding agents means:

• Session-scoped credentials: When Claude Code or Cursor needs to access an AWS account (for example, to query a DynamoDB table during development or run a Terraform plan), it requests time-boxed credentials through the same JIT workflow. The agent’s access expires when the coding session ends.
• MCP (Model Context Protocol) integration: The MCP framework provides the standard for AI agents to interact with external tools and services securely. JIT providers can expose an MCP server that agents call to request elevated access, receive credentials, and have them automatically revoked.
• Developer-approved escalation: When an AI agent needs access beyond its baseline permissions, the developer receives a prompt (in their IDE or via Slack) to approve the escalation — maintaining human-in-the-loop governance even for autonomous agent actions.
• Audit attribution: Every action the AI agent takes during its JIT session is logged and attributed to both the agent identity and the authorizing developer, maintaining accountability.

Cloudanix supports Coding Agent JIT as a dedicated flavor, purpose-built for the agentic development workflow. This extends the same governance, approval, and auto-revoke lifecycle to non-human coding identities.

How Cloudanix JIT Works with AWS Identity Center

For Cloudanix IAM JIT to work with AWS Identity Center, customers need integration with their Identity Provider — whether that is Azure Entra ID, Google Workspace, Okta, or another provider. AWS Identity Center works with all major Identity Providers.

Once AWS Identity Center is configured, Cloudanix synchronizes all Principals (Users, Groups), Permission Sets, and Account Mappings. From there, Cloudanix enables customers to configure the IAM JIT setup with multiple governance levers:

Configuration Options

1. Manage JIT Eligibility for Roles / Permission Sets — Define which permission sets are available for JIT requests versus persistently assigned. High-privilege sets like AdministratorAccess should always be JIT-only.
2. Auto-Approve for Limited Permissions — Permission sets with constrained, read-only, or low-risk policies can be configured for auto-approval, reducing friction for common development tasks.
3. Define Maximum Duration of JIT Access — Set hard limits on how long elevated access can persist. Common configurations: 1 hour for production admin, 4 hours for staging access, 8 hours for development environments.
4. Multi-Level Approver Configuration — Route approvals based on the sensitivity of the requested permission set and target account.

Request and Approval Workflow

Once configured, JIT requesters submit time-limited access requests for specific permission sets in target AWS accounts. Each request includes the business justification and desired duration.

Approvers receive notifications in Slack or Microsoft Teams with full context — the requester’s identity, target account, permission set, requested duration, and justification. They approve or reject directly from the notification without switching context.

Provisioning and Deprovisioning Automation

Cloudanix handles the provisioning and deprovisioning automatically. Once approved, the account assignment is created in AWS Identity Center within seconds. When the time limit expires, the assignment is removed — no manual intervention, no forgotten access.

Session Timeline and Audit

Every JIT session has a complete timeline: request time, approval time, provisioning time, session start, activities performed, and deprovisioning time. This timeline is the audit artifact that compliance teams need.

Session Monitoring

Cloudanix monitors all activities performed during the JIT session. Every API call, console action, and resource modification is captured and correlated with the JIT grant. If an engineer performs an unexpected action during their elevated session, security teams are alerted in real-time.

SSO Portal Experience

Once provisioned, users see the elevated access appear in their AWS Single Sign-On (SSO) portal alongside their persistent assignments. The experience is seamless — they click the role and begin working.

The Seven Flavors of JIT Access

Cloudanix provides JIT access across seven distinct surfaces, recognizing that privileged access extends far beyond the AWS console:

1. Cloud JIT — Time-bound access to AWS, Azure, and GCP cloud consoles and APIs.
2. Database JIT — Temporary credentials for RDS, DynamoDB, BigQuery, and other managed databases.
3. VM JIT — SSH/RDP access to virtual machines with session recording.
4. Kubernetes JIT — Temporary RBAC bindings for kubectl access to specific namespaces or clusters.
5. SaaS JIT — Elevated permissions in SaaS applications (admin panels, billing dashboards).
6. Agentic JIT — Governing autonomous AI agents that interact with cloud infrastructure.
7. Coding Agent JIT — Extending JIT to AI coding assistants like Claude Code, Cursor, and Kiro.

This breadth ensures that wherever privileged access exists in your stack, it is governed by the same request-approve-grant-revoke lifecycle.

Compliance Benefits: SOC 2, HIPAA, and DPDPA Readiness

JIT access directly addresses multiple compliance control requirements:

• SOC 2 CC6.1 (Logical Access Controls): JIT demonstrates that access is granted based on business need, with documented approvals and automatic revocation. Auditors can verify that no standing privileged access exists.
• HIPAA Minimum Necessary Standard: For healthcare workloads, JIT ensures that access to systems containing PHI is limited to the minimum necessary scope and duration for each task.
• DPDPA (India’s Digital Personal Data Protection Act): JIT supports the data minimization and purpose limitation principles by ensuring access to personal data stores is time-bounded and justified.
• ISO 27001 A.9 (Access Control): JIT satisfies requirements for access provisioning, access rights review, and removal of access rights.

The audit trail that JIT produces — request justification, approver identity, session timeline, and activity log — becomes the compliance evidence that auditors need without requiring teams to compile it manually.

Real-World Impact: Customer Proof Points

Organizations adopting JIT with AWS Identity Center see measurable security improvements:

• Moneyview eliminated standing privileged access entirely, moving all elevated permissions to JIT-only workflows. Engineers request what they need, when they need it.
• Finfinity achieved a 100% reduction in privileged access exposure by removing persistent admin roles and replacing them with time-boxed JIT grants.
• HugoHub transitioned from permanent role assignments to a robust JIT model, reducing their blast radius from always-on admin access to time-limited, audited sessions.

These results are not theoretical — they represent production environments where JIT replaced static privilege and the security posture measurably improved.

Best Practices for Implementing JIT with Identity Center

Based on production deployments across dozens of organizations, here are the practices that distinguish effective JIT implementations:

1. Start with high-privilege permission sets: Do not try to JIT everything on day one. Begin with AdministratorAccess and custom high-privilege sets on production accounts. Demonstrate value, build confidence, then expand.

2. Define sensible maximum durations: Production admin access should cap at 1-2 hours. If engineers routinely need longer, that is a signal to either fix the underlying tooling or create a lower-privilege permission set for the recurring task.

3. Auto-approve judiciously: Read-only access to non-production environments is a good candidate for auto-approval. Never auto-approve write access to production.

4. Integrate approvals into existing workflows: Slack and Teams integrations reduce friction dramatically. If approvers need to log into a separate portal, approval latency increases and adoption suffers.

5. Monitor session activity, not just access grants: Granting access is half the story. Knowing what was done during the session completes the picture and provides the forensic trail needed for incident response.

6. Review JIT metrics monthly: Track average session duration, request frequency per team, approval latency, and rejection rates. These metrics reveal both security posture and developer experience issues.

7. Combine with SCPs for defense in depth: JIT governs the happy path. SCPs provide the hard guardrails that prevent access even if the JIT layer is misconfigured or bypassed.

8. Plan for break-glass scenarios: Define an emergency access procedure for situations where the JIT system itself is unavailable. This should be heavily audited and rarely used.

Conclusion

The integration of IAM JIT access with AWS Identity Center transforms how organizations manage privileged access at scale. By automating the full lifecycle — request, approve, provision, monitor, revoke — JIT eliminates standing privilege while maintaining the velocity that engineering teams need.

With AWS’s continued investment in capabilities like Trusted Identity Propagation and the growing importance of governing AI coding agent access, JIT is no longer optional for security-conscious organizations. It is the operational mechanism that makes Zero Trust real in practice, not just in architecture diagrams.

Cloudanix IAM JIT operationalizes this entire workflow with AWS Identity Center, providing the governance layer that connects your identity provider, approval workflows, provisioning automation, session monitoring, and compliance reporting into a unified system. Whether you are managing 5 accounts or 500, Cloud JIT scales with your organization.

References:

• https://www.primeharbor.com/blog/aws-identity-center-azuread/
• https://learn.microsoft.com/en-us/entra/identity/saas-apps/aws-single-sign-on-tutorial
• https://docs.aws.amazon.com/singlesignon/latest/userguide/idp-microsoft-entra.html
• https://www.primeharbor.com/blog/aws-identity-center-google-v2/
• https://www.primeharbor.com/blog/aws-identity-center-google/
• https://docs.aws.amazon.com/singlesignon/latest/userguide/gs-gwp.html

People Also Read

• What is Identity and Access Management?
• Elevate your Security with IAM Just-In-Time (JIT) Access
• Cloudanix: Just in Time IAM
• Why IAM in the Cloud Needs Attention
• How to Implement JIT Access in AWS, Azure & GCP
• Non-Human Identity Security
• Coding Agent JIT