The Third Party Cloud Access Problem: What Happens When You Stop Using an Integration?
Nothing happens to it. When you stop using an integration, the cross-account IAM role stays in your AWS account, the trust policy stays in place, and the vendor's credentials still open the door. If those credentials are stolen, you carry the breach even though you left the product months ago. That means exposed customer data, stalled enterprise deals and a security review you did not plan for.
The Qubole incident showed this at scale. It is the clearest recent case for why AWS cloud security has to include the vendors you no longer use.
What the Qubole Incident Showed About Third Party Cloud Access
Between October 14 and October 26, 2026, a threat actor used IAM credentials from the AWS account Qubole's data platform uses to reach its customers. Wiz, working with Sentra and Mandiant, reported that the actor assumed integration roles that customers had created for Qubole. Public reporting puts the number of affected organizations at more than a dozen.
The detail that matters most is this. According to Wiz, most of the roles the attacker assumed were not otherwise in use. In a majority of the environments it observed, the attacker's requests were the only AssumeRole activity from the vendor account in October. Every request carried a valid External ID and every one succeeded.
Table 1: How the Qubole attack unfolded
| Stage | What the attacker did | Why it worked |
|---|---|---|
| Access | Called sts:AssumeRole with the vendor's credentials and a valid External ID | The trust policies were still in place |
| Discovery | Listed buckets, Lambda functions, secrets, keys and roles | The roles could read broadly |
| Credential harvesting | Read Lambda environment variables, Secrets Manager and SSM parameters, then tested the keys with TruffleHog | Secrets sat in places the role could reach |
| Data theft | Downloaded S3 objects, in some cases whole buckets in one session | Object reads are not recorded by default |
The stolen credentials were not only AWS keys. Wiz reported that TruffleHog was also used against Entra ID and Okta credentials found in victim environments. One compromised integration became a path into the identity layer.
How a Forgotten Integration Becomes an Open Door
Three IAM security weaknesses combined in this incident. Each one is common in startups that moved fast on tooling.
Table 2: Three failure modes behind a forgotten integration
| Failure mode | What it looks like | Business cost |
|---|---|---|
| Standing cross-account trust | A role trusts the vendor's whole AWS account | Anyone who holds vendor credentials can reach you |
| Excessive permissions | The role can read Secrets Manager, SSM, Lambda config and broad S3 | One role exposes data and credentials |
| Forgotten integrations | The contract ended but the role did not | Risk from a vendor that delivers you no value |
Cross-account IAM roles
A cross-account role lets a vendor act inside your AWS account. You create a role, and its trust policy names the vendor's account as a principal. The vendor then calls sts:AssumeRole with an External ID and receives temporary credentials.
{
"Effect": "Allow",
"Principal": { "AWS": "arn:aws:iam::<vendor-account-id>:root" },
"Action": "sts:AssumeRole",
"Condition": { "StringEquals": { "sts:ExternalId": "<external-id>" } }
}The :root principal trusts every identity the vendor account can authorize. Your exposure is therefore only as strong as the vendor's own credential hygiene.
Excessive permissions
Integration roles are often scoped for convenience on day one. Access to Lambda configuration, Secrets Manager, SSM parameters and broad S3 read gets granted so the setup works. Wiz specifically called out these permissions as commonly over-granted.
A role that was meant to manage compute should not be able to read your secrets. When it can, a compromised vendor can harvest keys to everything else.
Forgotten integrations
Offboarding usually ends with cancelling the subscription. Nobody owns the step where the IAM role is deleted. The role keeps working because AWS has no way to know the business relationship ended.
Dormant roles are also quiet. No legitimate traffic means no baseline, so the first sign of misuse can be the attack itself.
How to Run a Third Party Cloud Access Review
A review does not need a security team. A small engineering team can finish the first pass in an afternoon and repeat it each quarter.
1. Inventory every role that trusts an outside account
List every IAM role whose trust policy names an AWS account you do not own. Record the vendor, the permissions attached and the data the role can reach. Include old accounts, sandboxes and every region.
Example: a seed-stage payments startup finds eleven such roles. Four belong to tools nobody has logged into since last year.
2. Delete what you no longer use
Remove the role, or at minimum remove the vendor account from its trust policy. This is the single control that would have mattered most here, because the attacker needed those dormant roles to exist.
Example: before deleting, check CloudTrail for the last AssumeRole from the vendor account. If the answer is "never" or "months ago", delete it and note the date.
3. Narrow the principal and add network conditions
Where the vendor supports it, replace the :root principal with the specific IAM principal the vendor uses. Add an aws:SourceIp or aws:SourceVpce condition tied to the vendor's documented network ranges. Wiz noted that a source IP condition alone would have blocked every role assumption it observed.
Treat the External ID as non-secret. It appears in plaintext in CloudTrail and often sits in infrastructure-as-code. It prevents confused-deputy mistakes. It does not stop a stolen credential.
4. Cut permissions and log what matters
Remove access to Secrets Manager, SSM and Lambda configuration unless the integration genuinely needs it. Then confirm your logging can answer the question regulators and customers will ask. CloudTrail management events record the role assumption and bucket listing but not object reads, so enable S3 data events on sensitive buckets.
Example: a lending platform enables S3 data events on the bucket holding KYC documents only. The cost is contained and the audit trail covers the data that matters most.
Common Mistakes That Leave Integrations Exposed
Treating the External ID as a password
It is logged in plaintext and stored by the vendor. A valid External ID from an unexpected network should be rejected by a condition, not trusted.
Rotating keys and stopping there
Wiz notes that rotating a credential does not end temporary sessions already issued. Revoke active sessions for the role as well.
Reviewing only the vendors you use
The risk in this incident sat with organizations that had stopped using the product. Your list must include every role that exists, not every tool on your invoice.
FAQ
How do I check whether a former vendor can still access my AWS account?
Search IAM for roles whose trust policy names an external account ID. Any role that matches a vendor you no longer use is live access. Delete it or remove the vendor account from the trust policy.
Should I worry if I used Qubole?
Wiz advises anyone who has integrated Qubole to review CloudTrail from October 1, 2026 onward in every account holding a Qubole role. Look for AssumeRole events from account 805246085872 that come from non-AWS addresses. If you find one, rotate the secrets the role could read and revoke active sessions.
How often should I run a cloud access review?
Quarterly is a workable baseline for a small team. Add a trigger as well. Every time a vendor contract ends, deleting its IAM role should be part of the offboarding checklist.
The Takeaway for Small Security Teams
Third party cloud access is a business risk before it is a technical one. A tool you dropped can still put customer data and enterprise deals at risk. The fix is routine and cheap: inventory, delete, narrow and log.
Rezliant built Maestro for fintech teams that need this kind of coverage without adding headcount. If you want to see what is exposed in your own AWS account, start free with a Cloud Check. It scans a connected account and emails what it finds, ranked by reachability and severity.