The Confusing Scenario
An engineer requests JIT access for 30 minutes. Their request is approved. They sign into the AWS console through the SSO portal. They check the session information and see: session valid for 12 hours.
The natural reaction: “I requested 30 minutes of access. Why does AWS say my session is valid for 12 hours? Is JIT broken? Is my access really time-bound?”
This is one of the most common questions teams encounter when adopting JIT access with AWS IAM Identity Center. The answer isn’t a bug — it’s a fundamental architectural distinction between JIT duration (how long you’re allowed to have the permission set assignment) and AWS session duration (how long a single sign-in session remains valid once you’ve authenticated).
Understanding this distinction is essential for teams implementing JIT and for engineers using it daily.
Two Different Clocks
Clock 1: JIT Duration (The Gate)
JIT controls the permission set assignment — whether the association between your user and a specific permission set on a specific account exists at all.
- JIT grants for 30 minutes: The permission set assignment is created in IAM Identity Center at 10:00 AM and removed at 10:30 AM.
- Before 10:00 AM: The engineer cannot sign in with this permission set. It doesn’t appear in their SSO portal.
- Between 10:00 and 10:30: The engineer can sign in. The permission set is visible in their SSO portal.
- After 10:30 AM: The permission set assignment is removed. The engineer cannot initiate new sessions with this role. It disappears from their SSO portal.
JIT duration is the gate — it controls whether you can enter. Once the gate closes (JIT revokes), no new entry is possible.
Clock 2: AWS Session Duration (The Session)
When an engineer clicks a permission set in the SSO portal and signs into the AWS console or generates CLI credentials, AWS creates a session. This session has its own duration, configured in the IAM Identity Center permission set settings (often 1 hour, 4 hours, 8 hours, or 12 hours).
- At 10:05 AM (within the JIT window): The engineer signs in. AWS creates a session valid for 12 hours (per the permission set’s session duration setting).
- At 10:30 AM (JIT revokes): The permission set assignment is removed. The engineer cannot sign in again. But their existing session (created at 10:05) continues until it expires at 10:05 PM.
- At 10:05 PM: The AWS session expires naturally. The engineer must re-authenticate — but the permission set assignment no longer exists, so they can’t.
The session duration is configured in AWS IAM Identity Center — it’s an AWS setting, not a Cloudanix setting.
Why This Is Standard Behavior (Not a Bug)
This behavior is inherent to how AWS IAM Identity Center works, and it applies to any PAM or JIT system that manages permission set assignments:
- AWS sessions are independent of assignments. Once a session is created (tokens issued), it lives for its configured duration regardless of whether the underlying assignment still exists.
- This is a design decision by AWS. AWS separates authentication (session creation) from authorization at the assignment level. The session token is valid until its TTL expires.
- Every PAM and JIT system has this characteristic. Whether you use Cloudanix, Azure PIM, or any third-party access tool — once a user has an active session, the session duration is controlled by the IdP/cloud provider, not the access management tool.
The Gate Analogy
Think of JIT as a gate to a workspace:
- Gate opens (JIT grants access): You can walk through and enter the workspace.
- Inside the workspace: You have a visitor badge valid for 12 hours (the AWS session).
- Gate closes (JIT revokes): Nobody else can enter, and you can’t re-enter if you leave. But you’re still inside with your valid badge until it expires.
JIT controls the gate. AWS controls the badge duration. They’re independent mechanisms.
What This Means for Security
JIT Duration Controls Re-Entry
The primary security control JIT provides:
- After the JIT window expires, the engineer cannot start new sessions.
- If they close their browser tab, they cannot sign back in with that role.
- If they try to use the SSO portal, the role is gone.
- The next time they need access, they must submit a new JIT request and get approved again.
This is the security guarantee: no new access without re-authorization. The gate model ensures that every sign-in requires a valid JIT session.
AWS Session Duration Controls Active-Session Lifetime
The AWS session duration is a separate configuration:
- It determines how long an already-authenticated session remains valid.
- It’s set per permission set in IAM Identity Center settings.
- Common values: 1h, 4h, 8h, 12h (12h is the AWS maximum for console sessions).
The Practical Risk Assessment
If JIT revokes at 30 minutes but the session is valid for 12 hours, the practical risk is:
- The engineer has a valid session they obtained during their authorized window.
- They can continue using that session until it expires.
- They cannot get new sessions after JIT revocation.
- Actions during the session are still audited in CloudTrail and attributed to their identity.
For most organizations, this is acceptable because:
- The engineer legitimately obtained the session during their approved window.
- Their actions are still fully audited.
- The session will expire on its own (worst case: 12 hours).
- Immediate revocation of active sessions is available for security emergencies (terminate active sessions through Identity Center or IAM).
Configuring Session Duration for Your Risk Model
Organizations can align session duration with their security requirements:
Option A: Short Sessions (1–4 hours)
- Permission set session duration: 1 hour or 4 hours.
- Effect: Even if JIT grants for 2 hours, the AWS session expires in 1–4 hours.
- Trade-off: Engineers need to re-authenticate more frequently. For short JIT windows, this is invisible. For longer work sessions, they may need to sign in multiple times.
- Who uses this: High-security environments where minimizing residual session time is critical.
Option B: Work-Day Sessions (8–12 hours)
- Permission set session duration: 8 or 12 hours.
- Effect: An engineer who signs in during their JIT window has a session that covers their entire work day.
- Trade-off: Session persists well beyond JIT revocation. But the engineer can’t get new sessions after revocation.
- Who uses this: Teams that prioritize workflow (don’t want repeated re-authentication) and accept the trade-off that sessions are long-lived once created.
The Recommendation
Match session duration to the permission set’s sensitivity:
| Permission Set | Sensitivity | Suggested Session Duration |
|---|---|---|
| ReadOnly / SecurityAudit | Low | 8–12 hours (convenience) |
| Developers_Editor | Medium | 4–8 hours (balance) |
| Admin / PowerUser | High | 1–2 hours (tight) |
| Custom elevated roles | Variable | Match to typical task duration |
Higher sensitivity → shorter session → less residual access after JIT revocation.
Immediate Revocation: When You Need It
For security emergencies (credential compromise, suspicious activity), waiting for session expiry isn’t acceptable. Options for immediate session termination:
AWS-Level Options
- Revoke active sessions through IAM Identity Center: invalidates all active sessions for a user.
- Update permission set inline policies to add a deny-all condition on sessions created before a certain time.
- Disable user in Identity Center — prevents any further API calls.
Cloudanix-Level Options
- Early JIT revocation removes the permission set assignment immediately (prevents re-entry).
- For active sessions during security incidents — pair JIT revocation with AWS session revocation for full immediate termination.
In practice, immediate revocation of active sessions is rare — it’s reserved for active security incidents, not routine access management.
Communicating This to Engineers
When rolling out JIT, proactively explain the session model to avoid confusion:
What to tell engineers:
“When you request JIT access for 30 minutes, that means you have 30 minutes to sign in. Once you sign in, your AWS session is valid for [X hours] — that’s an AWS setting, not a JIT setting. After the 30-minute JIT window closes, you can’t sign in again without requesting new access. But your existing session continues normally.”
The key message: JIT controls when you can start a session. AWS controls how long the session lasts once started. Both are working as designed.
Key Takeaways
- JIT duration ≠ AWS session duration. They’re independent clocks serving different purposes.
- JIT controls the gate (can you sign in?). AWS controls the session (how long before you need to re-authenticate?).
- After JIT revocation, existing sessions continue but no new sessions can be created. This is standard for any system managing Identity Center assignments.
- Session duration is configurable per permission set. Align it with the role’s sensitivity for your risk model.
- Immediate session termination is available for security emergencies but isn’t needed for routine access lifecycle.
- This behavior is identical regardless of which JIT platform you use — it’s an AWS architectural property.
Want to Understand JIT Architecture Better?
If you’re evaluating or implementing JIT access and want clarity on how it interacts with AWS Identity Center sessions, permission set configurations, and your organization’s risk model — understanding the gate model vs. the session model is foundational.
Learn more about Cloud Console JIT or book a demo to discuss session duration configuration for your permission sets.
