Look at how the worst cloud incidents actually unfold and a pattern repeats itself. The initial compromise is rarely the disaster. Someone phishes a token, finds a key in a script, or social-engineers a help desk. The disaster is what that foothold can reach: a standing administrative credential, sitting in an account, always valid, waiting. The attacker did not need to escalate cleverly. The privilege was already there, standing, permanent, and pointed at everything.
So the highest-leverage identity control in AWS is almost boring to state. Nobody should have standing administrative access. Not your engineers, not your on-call, not your vendors. Access to do dangerous things should be requested when needed, approved by someone else, granted for a short window, and then gone.
The usual objection is cost and weight. Privileged access management has historically meant a heavyweight vault: a system that stores and rotates standing credentials, proxies sessions, and manages password checkouts, with a price tag and an operational footprint that only large enterprises absorb comfortably. Lean teams look at that and quietly decide standing admin is the price of getting work done.
It does not have to be. On AWS you can build the thing that matters most about privileged access management, short-lived access granted through an approval workflow, without vaulting a single password. We built exactly this into CloudDefender, and the design is simple enough to explain in one article.
The core idea: broker credentials, do not store them
The single decision that makes this lightweight is that we never hold a standing secret. There is no vault because there is nothing to vault.
Short-lived access is delivered by vending temporary credentials from the AWS Security Token Service. When a request is approved and active, the broker calls AssumeRole against an elevated role in the customer’s account, with a bounded duration, and returns either a federated console sign-in URL, raw temporary credentials for the CLI and SDKs, or both. Those credentials are never persisted. They live in the requester’s hands for the length of the window and then they stop working.
This inverts the entire premise of a traditional vault. A vault exists to protect standing secrets: it stores them, rotates them, and controls who checks them out. If the credential never stands still, most of that machinery has nothing to do. There is no password to rotate, no long-lived key to leak, and in the happy path nothing to revoke, because the access expires on its own. The security property you wanted, no standing privilege, falls out of the model instead of being bolted on by a heavyweight system.
Here is the honest comparison. A password vault stores and rotates standing credentials; we keep nothing standing. A vault records sessions through a proxy; we rely on the customer’s own CloudTrail, and can add recording later if a customer needs it. A vault manages password checkouts; there are no passwords, just a federated URL or temporary credentials issued on approval. A vault runs a heavy policy and workflow engine; we run a simple request, approve, and grant, with the one rule that the approver cannot be the requester. A vault ships connectors and agents; we use a plain IAM role and an API, the same trust pattern as a read-only integration.
The architecture, end to end
A requester, authenticated as a normal user, submits a request: which role profile, a written justification, and how many minutes they need. That request lands in a control-plane table with a pending status and notifies the approvers by email.
An approver who is not the requester approves or denies. Approval opens a window, from the moment of approval to the moment the requested duration elapses. Denial is terminal.
While the window is open, and only while it is open, the requester can ask for credentials. The broker performs the AssumeRole, setting the role session name to the request id, attaching session tags that record the request and the requester, and applying an optional session policy that can narrow the role’s permissions further at grant time. It returns the console URL or temporary credentials. When the window closes, credential requests are refused, and any credentials already issued simply expire.
The elevated role itself is the important structural detail. It lives in the customer’s account, not ours. It is opt-in and default-off, created only when the customer deliberately enables it, and its trust is gated by an external ID exactly like a read-only integration role. Critically, the customer scopes its permissions. They attach the managed policy, and ideally set a permissions boundary the role can never exceed. The broker can assume the role, but the shape of what that role can do is drawn by the account owner, not by us. We provide the workflow and the vending. You provide the boundary.
The security model, stated as non-negotiables
Introducing a broker that can assume an elevated role in a customer account is a real escalation of trust over a read-only integration, and it would be dishonest to pretend otherwise. That is precisely why the model has to be strict, and why the first version shipped with all of the following rather than deferring any of it.
Opt-in and default-off, always. The elevated role does not exist until the customer creates it. A fresh connection can look but never elevate.
Separation of duties, enforced on the server. The approver cannot be the requester. This is checked in the backend, not just hidden in the interface, so it cannot be bypassed by calling the API directly.
Hard duration caps and least-privilege session policies. There is a configured maximum window, and a session policy can narrow a broad role at the moment of granting so a single request gets only what it needs.
A kill-switch. A revoke action marks a grant terminal and refuses any further credential vends. There is one honest limitation to state plainly: the Security Token Service cannot force-expire a session that has already been issued. That is why short durations are the real control. Revocation stops future vends immediately, and the short window bounds how long any already-issued session can matter. A team that wants a hard cutoff mid-session can add a deny at the role trust level, but for most workflows a short duration plus revocation is the right balance of safety and simplicity.
Dual audit. Every privileged action is recorded twice: in the broker’s own request ledger, with the justification, approver, and timestamps, and in the customer’s own CloudTrail, where the request id in the session name ties every API call back to a specific approved request. The record you rely on for an audit lives in a log you control, not one the vendor controls.
And the broker itself, the control-plane role that can assume customer elevated roles, becomes the crown jewel of the whole system. It gets the tightest possible permissions, no human console access, and its own CloudTrail. If you are going to build a broker, you treat the broker like the sensitive thing it is.
What the first version does, and what it does not
Being precise about scope is part of being trustworthy, so here is the line.
The shipped first version does single-approver requests against one customer-scoped elevated role profile, delivers access as a federated console URL or temporary credentials, records the full lifecycle in the request ledger and in customer CloudTrail, enforces separation of duties and duration caps in code, and includes the revoke kill-switch. It is gated to the Growth tier and above, and demo tenants short-circuit the flow so no real AssumeRole happens in a demonstration.
What it does not do yet is equally worth saying. There is no multi-party approval yet, so no requirement that two of three named approvers sign off on the most sensitive roles. There are not yet multiple named access profiles for splitting read-heavy from write-heavy work. There is no session recording or proxy, because we rely on your CloudTrail today. And there is no integration with IAM Identity Center for shops already standardized on permission sets. Those are on the roadmap, in that rough order, and we will describe each as it ships rather than before.
We would rather ship a small, strict version that is completely honest about its edges than a broad one that quietly leaves the hard parts as an exercise for the customer.
Why lean teams should care most
The irony of privileged access management is that the teams who need it most have historically been the ones priced out of it. A security team of three covering dozens of accounts cannot run a heavyweight vault, so they tolerate standing admin roles and hope the audit does not look too closely. That standing access is exactly the thing an attacker converts a small foothold into a full breach through.
A broker built on short-lived credentials changes that math. There is no vault to run, no agents to deploy, and no standing secret to protect, because the whole design is a role, an API, and an approval step. The lean team gets the one control that actually moves the needle, no standing privilege, at an operational weight they can carry. And when the auditor asks how privileged access is granted and recorded, the answer is a clean request ledger and a CloudTrail trail keyed to individual approvals, rather than a shrug.
Standing administrative access is a habit, not a requirement. On AWS you can break the habit with temporary credentials, an approval step, and the discipline to keep windows short. That is the whole idea, and it is within reach of teams far smaller than the ones the vault vendors were built for.
Sources and reporting notes
- This article describes CloudDefender’s just-in-time privileged access capability as of publication: a Growth-tier and above feature that brokers short-lived AWS Security Token Service credentials against a customer-created, customer-scoped, opt-in elevated role, through a single-approver workflow with separation of duties, duration caps, a revoke kill-switch, and dual audit via the request ledger and customer CloudTrail. Multi-party approval, multiple access profiles, session recording, and IAM Identity Center integration are described as roadmap, not shipped.
- The mechanisms referenced (cross-account AssumeRole gated by an external ID, bounded session durations, session tags, session policies, role session names surfaced in CloudTrail, and permissions boundaries) are standard AWS Security Token Service and IAM features.
- The characterization of traditional privileged access management (vaulting, rotation, session proxying, password checkout) describes the general category, not any specific named product.
CloudDefender’s just-in-time access brokers short-lived AWS credentials on approval, against an opt-in role you create and scope in your own account. Nothing is vaulted, nothing stands still, and every session is traceable in your own CloudTrail. It is a lightweight way to remove standing administrative access without running a heavyweight vault.