The Gap in AWS IAM Identity Center
AWS IAM Identity Center (formerly AWS SSO) is the right foundation for multi-account access management. It gives you:
- Centralized identity: One place to manage users and groups.
- Permission sets: Reusable, auditable access templates.
- Multi-account coverage: One login, access to all accounts where assigned.
- IdP integration: Google Workspace, Okta, Azure AD, JumpCloud — your identity source feeds directly into AWS.
But it’s missing one critical dimension: time.
Permission set assignments in IAM Identity Center are static. You assign a group (or user) to an account with a permission set, and that assignment persists until someone removes it. There’s no built-in concept of:
- “This user has Developers_Editor on Production for the next 2 hours.”
- “This assignment expires at 5 PM today.”
- “This permission set is available only during active incidents.”
The assignment exists permanently — or not at all. There’s no middle ground.
Why Static Assignments Create Problems at Scale
Standing Privilege Accumulation
At 10 users across 2 accounts, static assignments are manageable. The admin knows who has what and can manually adjust when needed. At 150 users across 4 accounts with 5+ permission sets each, the math changes:
Potential assignments: 150 users × 4 accounts × 5 permission sets = 3,000 possible access paths.
In practice, not all of these exist — but significantly more exist than are actively needed at any given moment. Engineers who needed production access for a one-time incident still have that assignment. Team members who changed projects still have access to the old project’s accounts.
Static assignments only get added. They rarely get removed — because removal requires someone to remember, verify it’s safe, and execute the change.
The SSO Portal Problem
When an engineer opens their AWS SSO start page, they see every account and role they’re assigned to. For engineers with accumulated assignments, this might be:
- Development Account: SecurityAudit, Developers_Editor
- Staging Account: SecurityAudit, Developers_Editor
- Production Account 1: SecurityAudit, Developers_Editor
- Production Account 2: SecurityAudit
- Production Account 3: SecurityAudit, Developers_Editor
All available, all the time, 24/7/365. Whether the engineer needs them today or hasn’t used some in months.
With JIT, the same engineer’s SSO portal shows only what they’ve actively requested and been approved for right now. If they haven’t requested anything, they see nothing elevated. If they requested SecurityAudit on Production-1 for 2 hours, they see that — and only that — until the 2 hours expire.
No Temporal Audit Trail
CloudTrail logs when someone assumes a permission set role. But it doesn’t log why they have the assignment in the first place or when it was supposed to expire. For compliance:
- “Why does this engineer have production access?” → “Because they were assigned the permission set.”
- “When was it assigned?” → “Let me check CloudTrail for the CreateAccountAssignment event.”
- “When is it supposed to be removed?” → “…unclear.”
- “Why was it approved?” → “…let me check Jira/Slack/email.”
A static assignment doesn’t carry context. A JIT assignment carries all of it: who requested, who approved, when it was granted, when it expires, and why.
How JIT Adds Temporal Governance to IAM Identity Center
Cloudanix JIT doesn’t replace IAM Identity Center. It adds the temporal layer that’s missing:
Before JIT: Static Assignments
IAM Identity Center:
User: engineer@company.com
Account: Production-1
Permission Set: Developers_Editor
Status: Assigned (permanently)
Assigned Since: 2025-03-15
Expires: NeverAfter JIT: Dynamic Assignments
IAM Identity Center:
User: engineer@company.com
Account: Production-1
Permission Set: Developers_Editor
Status: Not currently assigned
Cloudanix JIT:
Policy: Engineering group can request Developers_Editor on Production-1
Current state: No active session
When engineer requests and gets approved:
IAM Identity Center:
User: engineer@company.com
Account: Production-1
Permission Set: Developers_Editor
Status: Assigned (by Cloudanix, expires in 2h)
Cloudanix audit:
Requested: 2026-08-14 10:00
Approved by: devops-lead@company.com
Granted: 2026-08-14 10:00
Expires: 2026-08-14 12:00
Reason: "INC-2341 debugging"What Changes in the SSO Portal
Before JIT (standing assignments): Engineer opens AWS SSO portal and sees 8 roles across 4 accounts. All available regardless of whether they have an active task.
After JIT (temporal assignments): Engineer opens AWS SSO portal and sees only roles for active JIT sessions. If no session is active, the portal shows no elevated access. When they request and get approved, the role appears within seconds.
The SSO portal still works exactly as before — same URL, same bookmark, same CLI. The only change: roles appear when needed and disappear when done.
Group-Based Policy, User-Based Assignment
A common architectural decision in JIT: should permission set assignments be to groups or individual users?
The Case for User-Based Assignment
With group-based assignments, assigning Engineering Group → Production-1 → Developers_Editor means all 100 engineers get production access simultaneously. This is:
- Against least privilege (99 engineers don’t need production right now).
- Impossible to time-bound per individual (the group assignment doesn’t expire per user).
- Difficult to audit per user (“the group has access” doesn’t tell you which individual used it).
With user-based JIT assignment:
- Only the specific engineer who requested access gets the assignment.
- The assignment is scoped to that individual for their requested duration.
- Audit is identity-stamped: this specific person, this specific time, this specific action.
Group Defines the Boundary, JIT Controls the Access
The mental model:
- Group membership = “what you’re allowed to request” (the policy boundary).
- JIT assignment = “what you actually have right now” (the temporal reality).
Being in the Engineering group means you can request Developers_Editor on Production-1. It doesn’t mean you have Developers_Editor on Production-1. That exists only during an active, approved JIT session.
The Migration Path: From Static to Temporal
Organizations don’t need to rip out all static assignments on day one. The migration path:
Phase 1: Add JIT Alongside Static Assignments
- Configure JIT policies for the most sensitive access (production admin).
- Remove static assignments for those roles (production admin is now JIT-only).
- Less sensitive access remains statically assigned (for now).
Phase 2: Expand JIT to Standard Production Access
- Remove static assignments for standard production roles.
- Configure auto-approval for common patterns (production read-only).
- Standard production access now goes through JIT (mostly instant via auto-approval).
Phase 3: JIT for Everything Elevated
- Remove remaining static assignments except baseline (SSO portal shows nothing by default).
- All access is JIT-governed: auto-approve for safe, approve for sensitive, multi-level for critical.
- Standing privilege: zero.
Each phase can be adopted independently. Teams can move at their own pace. There’s no “big bang” cutover required.
For Organizations Not Yet on IAM Identity Center
Many organizations still use direct IAM Users in AWS accounts rather than IAM Identity Center. The pattern still applies:
- Short-term: JIT can manage IAM User credentials, access keys, and console access using existing IAM infrastructure.
- Long-term: Migration to IAM Identity Center + JIT provides the cleanest architecture: one identity source, one assignment mechanism, one temporal governance layer.
The migration to IAM Identity Center is independently valuable (centralized identity, consistent permission sets, proper federation). JIT makes that migration even more valuable by adding the temporal dimension from day one of the Identity Center deployment.
Ready to Make Your Identity Center Assignments Temporal?
If your AWS IAM Identity Center has permission sets assigned statically — and you want those assignments to exist only during active, approved work sessions — Cloudanix JIT adds the temporal governance layer without changing your SSO architecture, your permission sets, or your developer’s portal experience.
Learn more about Cloud Console JIT or book a demo to see JIT working with your IAM Identity Center configuration.
