Customer Snapshot
| Attribute | Details |
|---|---|
| Industry | Technology / Enterprise SaaS |
| Cloud Environment | Multi-account AWS Organization with a master/management account |
| Identity Provider | AWS IAM Identity Center |
| Security Posture | Rigorous review; concerned about what a JIT tool changes inside each account |
| Access Mechanism | AWS switch-role, brokered through the master account |
| Key Question | “Does granting JIT access modify permissions in our production accounts?” |
| Cloudanix Scope | Cloud Console JIT via IAM Identity Center |
The Situation: “What Exactly Does Your Tool Change Inside Our Accounts?”
Security teams evaluating a just-in-time access tool ask one question before any other: what does this thing actually modify, and where? The fear is specific and reasonable. If a JIT tool works by rewriting IAM policies inside each production account every time someone requests access — attaching policies, editing roles, flipping permissions on resources — then the tool becomes a high-privilege actor with write access to the most sensitive configuration in your environment. That’s a lot of trust to extend to a vendor, and a lot of blast radius if the tool misbehaves.
This enterprise team held exactly that concern. They ran a multi-account AWS Organization with a master/management account and IAM Identity Center for federation. Before they’d let JIT govern access to production, they needed to understand — concretely — whether granting access would alter permissions inside their target accounts, or whether the mechanism lived somewhere safer.
The answer, and the architecture behind it, is the subject of this use case: access is granted through the master account using AWS switch-role, and the target accounts’ own permissions are not directly touched in the process.
The Core Challenge
A JIT tool that rewrites IAM inside every account it governs is both an operational risk (a bug could alter production permissions) and a review burden (the security team must trust the tool’s write access to every account). The challenge was to deliver time-bound access without the JIT engine becoming a policy-mutating actor inside each target account — keeping the mechanism centralized, auditable, and non-invasive to the accounts holding the sensitive workloads.
Where the Gaps Were
The “Policy-Rewriting JIT” Anti-Pattern
To understand why the switch-role architecture matters, it helps to name the pattern it avoids. A JIT tool could implement temporary access by, on each request, reaching into the target account and:
- Attaching an inline or managed policy to the user or role.
- Editing a role’s trust or permission policy to add the requester.
- Modifying resource policies to admit the requester for the window.
Every one of these is a write operation against the target account’s IAM configuration. Collectively they mean the tool needs standing write access to IAM in every governed account, and that each grant is a mutation of production configuration. The security concerns cascade:
- Blast radius. A bug or compromise in the tool could alter or corrupt IAM in production accounts.
- Audit noise. Every grant and revocation produces IAM configuration-change events in the target account, muddying the signal that genuine configuration drift would produce.
- Review burden. The security team must certify that the tool’s write access to every account is safe — a far higher bar than certifying read or a narrow central capability.
Where the Concern Was Legitimate
The team wasn’t being paranoid. In a rigorously reviewed environment, “the access tool has IAM write in all our accounts” is a finding, not a footnote. If the only way to get JIT was to accept that posture, JIT would have been a hard sell to the security function — the very group whose buy-in the deal needed. The gap, then, wasn’t technical capability. It was architectural trust: the team needed the access mechanism to be centralized and non-invasive, or it wasn’t going to pass review.
The Cloudanix Solution: Switch-Role Through the Master Account
Cloudanix JIT grants access using AWS’s native switch-role mechanism, brokered through the organization’s master account and IAM Identity Center — not by rewriting IAM inside each target account.
How the Mechanism Works
-
A user requests access to a target account and role for a bounded duration, via Slack or the console.
-
Approval routes by policy — auto-approve for low-risk roles, approver sign-off for sensitive ones.
-
The grant is realized at the identity layer, centrally. Cloudanix manages the time-bound assignment of a permission set in IAM Identity Center and the switch-role path that lets the approved identity assume the configured role for the window. The access flows through the master account’s federation, and the user ends up able to switch into the target role — without the JIT engine editing the target account’s own IAM policies to make that happen.
-
The target account’s permissions are not directly modified. The roles and their permission boundaries in the target account are pre-defined by the customer and remain as they are. JIT governs whether and for how long an identity may assume one of those roles — it does not rewrite what those roles can do, nor attach new policies inside the account per request.
-
Access auto-revokes when the window ends — the temporary assumption path is withdrawn, again centrally, with the target account’s configuration unchanged throughout.
Why This Satisfies a Rigorous Security Review
The switch-role-through-master architecture directly answers the concerns that the policy-rewriting pattern raises:
- No per-request IAM mutation in target accounts. Because grants are realized at the identity/federation layer rather than by editing target-account policies, there’s no stream of IAM configuration changes inside production accounts tied to routine access.
- Centralized, bounded capability. The mechanism concentrates in the master/management account and Identity Center — a surface the security team can reason about and review once — rather than distributing write access across every account.
- The customer still owns the roles. The permission sets and roles that define what access means are authored and bounded by the customer. JIT decides when they apply and to whom, for how long. That separation keeps the customer in control of privilege definition while JIT controls privilege lifetime.
- Cleaner audit. Access events are access events, recorded on a JIT timeline — distinct from genuine IAM configuration changes in the target account, which remain a meaningful signal rather than being drowned by routine grants.
Pairing It With Minimal Onboarding Permissions
The switch-role architecture pairs naturally with the discipline of giving the JIT platform only the permissions it needs. Teams that want JIT-only (not the full posture-management surface) can strip the onboarding footprint to the minimum required for the switch-role and Identity-Center operations, and even add explicit deny statements for defense in depth. The architecture and the right-sizing reinforce each other: a centralized, non-invasive mechanism, granted only the narrow capability it actually uses. This is explored in depth in right-sizing Cloudanix permissions for JIT-only use.
A Clarification That Comes Up in Review
One point reliably needs stating during a security review, because it’s a frequent source of confusion: when a user is granted access via switch-role through the master account, the access they obtain is defined by the role they switch into — it does not silently expand the target account’s own permission model, and it does not grant anything the pre-defined role doesn’t already allow. JIT is a gate on assuming a role, not a mechanism for inventing new privilege inside the account. Making this explicit early tends to turn a tense architecture discussion into a short one.
Separating Session Lifetime From Access Lifetime
A related question that always surfaces in review — and that genuinely confuses users if it isn’t explained — is the difference between how long JIT grants access and how long a session lasts once access is granted. These are two different clocks, owned by two different systems, and conflating them produces a predictable complaint.
Here’s the distinction. JIT controls the gate: whether a given identity may assume a particular role in a particular account, and for what window that eligibility exists. Once the user actually signs in and assumes the role, the session’s validity is governed by the AWS Identity Center session configuration — a setting the customer controls, often set to span a full working day so engineers aren’t re-authenticating constantly. So a user might request JIT access for thirty minutes of eligibility, sign in within that window, and then hold a session whose length is dictated by the Identity Center configuration rather than the JIT request.
To a user who doesn’t know the model, this looks like a contradiction (“I asked for 30 minutes but my session lasted hours”). It isn’t — it’s the normal, expected behaviour of any system that gates role assumption rather than proxying every action. JIT decides whether you get in; the identity platform decides how long your sign-in stays valid. Explaining this up front, and pointing out that the session length is a customer-controlled Identity Center setting, resolves the concern before it becomes a support ticket. It also reinforces the architectural point: because JIT is a gate and not a proxy, it doesn’t need to sit in the session path intercepting activity — which is exactly why it can stay non-invasive to the target account.
What the Security Team Actually Signs Off On
It’s worth being concrete about what a rigorous reviewer ends up certifying, because it’s a short list once the architecture is understood. They confirm that the JIT platform’s capability is concentrated at the master/management account and Identity Center, not distributed as IAM write across every account. They confirm that the roles defining what access means are authored and bounded by the customer. They confirm that routine grants don’t produce IAM configuration changes inside target accounts. And they confirm that the onboarding footprint can be scoped to the minimum the mechanism requires. That’s a reviewable, bounded surface — a far easier thing to approve than “the vendor can rewrite IAM anywhere,” which is precisely why the architecture matters as much as the feature set.
Platform Impact
| Dimension | Policy-Rewriting JIT | Switch-Role Through Master Account |
|---|---|---|
| IAM writes in target accounts | Per request | None for routine grants |
| Tool’s required access per account | IAM write everywhere | Centralized at master/Identity Center |
| Blast radius of a tool fault | Production IAM in every account | Bounded, central mechanism |
| Audit signal in target accounts | Diluted by grant churn | Preserved — access events kept separate |
| Who defines privilege | Blurred by per-request edits | Customer owns roles; JIT owns lifetime |
| Security-review burden | High (write access everywhere) | Lower (one central surface) |
Why Architecture Is the Real Differentiator in a Security Review
Feature lists win demos; architecture wins security reviews. Two JIT tools can both claim “time-bound access with approval and auto-revoke,” and still differ enormously in what they do to your accounts to deliver it. The team in this story didn’t need to be told JIT reduces standing privilege — they already believed that. What they needed was confidence that adopting JIT wouldn’t hand a vendor write access to IAM across their entire production estate.
The switch-role-through-master architecture provides that confidence by keeping the mechanism centralized and non-invasive: the customer defines and bounds the roles, JIT governs when and for how long they can be assumed, and the target accounts’ own permissions stay untouched. That’s the kind of answer that moves a deal from “the security team has concerns” to “the security team signed off.”
Does Your JIT Tool Rewrite IAM in Every Account?
If your security team is weighing a JIT tool and wants to know exactly what it modifies and where, Cloudanix grants access through the master account using native AWS switch-role — time-bound, centrally governed, and non-invasive to your target accounts’ permissions. Pair it with a minimal, JIT-only onboarding footprint and the whole mechanism becomes something a rigorous review can approve.
Book a Free Assessment to walk your security team through the switch-role architecture against your own org.
Related Resources
- Right-Sizing Cloudanix Permissions: Minimizing Access for JIT Functionality
- Agentless Cloud JIT: How Cloudanix Operates Without Deploying in Customer Environments
- Integrate Just-in-Time (JIT) Access with AWS Identity Center
- JIT Cloud for Multi-Account AWS Organizations: SSO and Permission Sets
- Permissions Assignment to Users vs Groups in Identity Center
