A SaaS vendor asks you to create an IAM role in your AWS account that its account can assume, and insists the trust policy pin an sts:ExternalId condition. What attack does that condition prevent, and who is supposed to choose the value?

## The setup that creates the risk A monitoring, backup or cost-analysis SaaS needs read access into your AWS account. The standard integration is cross-account role assumption: you create a role, its trust policy names the vendor's AWS account as the principal, you paste the role ARN into the vendor's console, and the vendor's service assumes the role when it needs to work. Now notice what that vendor is. It is one AWS principal that assumes roles in every one of its customers' accounts. It is trusted by all of them, and it does whatever its own configuration tells it to do. That is the shape of a **confused deputy**: an intermediary with more authority than any of its clients, taking instructions from clients about which authority to use. The concrete attack: another customer of the same vendor gets hold of your role ARN. Role ARNs are not secret — they turn up in tickets, screenshots, CloudFormation outputs, documentation and support threads, and they are guessable if you named the role something obvious. That customer enters your ARN in their own account settings at the vendor. The vendor dutifully calls `sts:AssumeRole` on your role, and your trust policy sees the vendor's account as the principal — exactly what it was told to accept — and issues a session. The attacker now reads your data through the vendor's UI. Nothing was breached; the trust policy did precisely what it said. ## What ExternalId does `sts:AssumeRole` accepts an optional `ExternalId` parameter, and `sts:ExternalId` is the matching condition key. Your trust policy pins it: ```json { "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::444455556666:root" }, "Action": "sts:AssumeRole", "Condition": { "StringEquals": { "sts:ExternalId": "c7f2a9e4-tenant-8831" } } }] } ``` Now an assumption succeeds only when the caller supplies that exact value. The attacker's request goes out with *their* external ID, the condition fails, and STS refuses. Your role ARN alone is no longer sufficient instruction. ## Who generates it, and why that is the crux **The vendor generates it.** This is the part candidates get backwards. The vendor allocates a unique external ID per customer and binds it internally to your account record; when it assumes your role, it sends the value bound to *your* configuration. Because the mapping lives on the vendor's side, another customer cannot cause the vendor to send your value — they can only ever cause it to send their own. If **you** picked the value, the protection evaporates in the case that matters. The attacker who obtained your role ARN would typically also have obtained the external ID from the same place, and vendors that let customers type in an arbitrary external ID reopen the hole: the attacker enters your ARN *and* your external ID, and the vendor sends both. The whole design depends on the value being assigned by the party that also decides which value goes with which customer. ## It is not a secret An external ID is an **identifier, not a credential**. It authenticates nobody; on its own it grants nothing. Its only job is to make the vendor's instruction specific to one customer relationship. So do not treat it like a password — but do expect it to be unpredictable and unique per customer, because a vendor that uses a sequential counter, or the customer's account ID, has given attackers a value they can derive rather than one they must be given. A useful consequence: because it is not a secret, storing or logging it is not an incident. What *would* be a problem is a vendor that reuses one external ID across all its customers — that is functionally the same as having none. ## Reviewing an integration When you are handed a vendor's setup instructions, check three things. Does the trust policy name a *specific* vendor principal rather than a wildcard? Is `sts:ExternalId` pinned with `StringEquals` — not `StringLike` with a wildcard, which quietly defeats it? And are the role's permissions actually scoped to what the vendor needs, usually read-only, rather than a broad managed policy pasted in for convenience? A vendor that cannot explain its external ID scheme, or that offers to let you choose the string, has told you something about its security engineering.