Risky trust & cross-account access
Trust and cross-account access are the plumbing that lets one workload, account, or vendor act inside another — and the same plumbing is how an attacker turns a single foothold into lateral movement across your whole estate. A trust policy answers a deceptively simple question: which outside principal is allowed to assume this role or read this resource, and under what conditions? When that answer is too broad — an account-wide principal, a wildcard, a missing external ID, a vendor role with standing access nobody reviews — the boundary between accounts stops being a boundary. We assess this sub-topic specifically because cross-account trust is invisible in most day-to-day reviews: it lives in role trust documents and resource-based policies, not in the user list everyone watches. Getting it right is what keeps a compromise contained to the account where it started.
Overview
What this check looks like in practice
Trust policies and cross-account roles are how workloads talk to each other — and how attackers pivot. Confused-deputy conditions and over-broad trust turn one account’s compromise into many.
Why it matters
To an attacker, cross-account trust is the map for lateral movement: compromise a low-value account, enumerate which roles trust it, and assume your way toward the account that holds the data. The classic failure is the confused deputy — a role that trusts a third party without an external-ID or source-account condition, so any customer of that third party can trick it into acting on your resources. Over-broad trust also breaks the blast-radius assumption every incident plan depends on, because a single leaked credential no longer maps to a single account. Auditors probe this directly: they expect evidence that trust relationships are enumerated, condition-constrained, and reviewed, and that no external principal has access the business cannot name. Once data has been reached across an unintended trust path, the exposure has already happened — you cannot un-share what a trusted account already read.
What we assess
What we look for
- Role trust policies that name an entire account principal (e.g. account root) or a wildcard principal instead of a specific role or user
- Third-party / vendor assume-role trusts that lack an external-ID or source-account condition — the confused-deputy exposure
- Cross-account and cross-tenant grants scoped broader than the integration actually requires, or with no documented business owner
- Resource-based policies (bucket, key, queue, topic, function, registry) that grant access to external accounts or the public rather than named principals
- Trust relationships that no longer have a matching, active integration on the other side — orphaned trust nobody removed
- Missing organization-wide guardrails that would constrain who can be trusted (org-ID conditions, SCPs, domain-restricted sharing, cross-tenant access policy)
- Service-account impersonation and delegation chains that let one identity mint credentials for another across project or account lines
- No enforced condition on session context (source account, org ID, MFA, network) for privileged cross-account roles
Across your clouds
AWS, Azure & Google Cloud
AWS
IAM role trust policies (the sts:AssumeRole Principal document), including account-root principals and the sts:ExternalId / aws:SourceAccount conditions that prevent the confused-deputy problem; resource-based policies on S3, KMS, Lambda, SNS, SQS, and ECR; aws:PrincipalOrgID conditions and Service Control Policies as org-wide guardrails; IAM Access Analyzer to surface roles and resources reachable from outside the account or organization.
Azure
Entra ID cross-tenant access settings and B2B collaboration/guest access; multi-tenant app registrations and service principals; workload identity federation (federated credentials) that trusts external token issuers; Azure Lighthouse delegated resource management, where a provider tenant holds standing RBAC into yours; RBAC role assignments inherited from management-group and subscription scope that reach across boundaries.
Google Cloud
Cloud IAM bindings that grant roles to principals in other projects, or to allUsers / allAuthenticatedUsers on a resource; service-account impersonation via roles/iam.serviceAccountTokenCreator and roles/iam.serviceAccountUser, and cross-project service accounts; Workload Identity Federation and domain-wide delegation as external trust paths; the iam.allowedPolicyMemberDomains org policy (domain-restricted sharing) and Policy Analyzer to enumerate who can reach what.
Example finding
A vendor integration role trusts the SaaS provider's account with no external ID
Risk: The role's trust policy allows the provider's shared AWS account to assume it, but sets no sts:ExternalId condition. Because many of the provider's customers are served from that same account, any of them — or an attacker who learns your role ARN — could induce the provider to assume the role and act on your resources. This is the textbook confused-deputy exposure, and it grants whatever the role's permissions allow, silently and cross-account.
Fix: Add the vendor-supplied external ID as an sts:ExternalId condition on the trust policy (and an aws:SourceAccount condition where applicable), tighten the role's permissions to only the actions the integration uses, and confirm with IAM Access Analyzer that no other external principal can reach it.
Remediation
How to close it
- 1 Enumerate every trust relationship: role trust policies, resource-based policies, cross-tenant settings, delegated management, and impersonation grants — then attach a named business owner and active integration to each.
- 2 Replace account-wide and wildcard principals with specific role or service-principal ARNs, and remove any trust that no longer has a live integration on the other side.
- 3 Add condition constraints to every external trust — external ID and source-account for vendor roles, org-ID/domain restrictions for internal cross-account access, and session context (MFA, source) for privileged assumes.
- 4 Right-size the permissions behind each trusted role so that even a legitimately assumed session cannot exceed what the integration needs.
- 5 Enforce organization-wide guardrails — SCPs and aws:PrincipalOrgID, Entra cross-tenant access policy, and GCP domain-restricted sharing — so new over-broad trust cannot be created by default.
- 6 Stand up continuous external-access detection (IAM Access Analyzer, Policy Analyzer, cross-tenant reviews) and schedule a recurring review of third-party and cross-account access so drift is caught early.
Compliance evidence
Questions
What exactly is the confused-deputy problem in cloud trust?
It is when a trusted service can be tricked into using its privileges on your behalf without your intent. A common shape is a third-party SaaS whose single cloud account is trusted by many customers; without an external-ID or source-account condition pinning the trust to your engagement, one customer — or an attacker with your role ARN — can make the deputy act on your resources. The fix is a condition that ties the trust to a value only you and the legitimate integration share.
Isn't cross-account access covered by our IAM review already?
Usually not fully. Most IAM reviews focus on users, groups, and permission policies — who can do what inside an account. Trust lives in a different place: role trust documents, resource-based policies on buckets and keys, cross-tenant settings, and impersonation grants. Those are what let outside principals in, and they are frequently the paths a standard permissions review never opens.
Do you change our trust policies during the assessment?
No. The assessment is strictly read-only. We enumerate trust relationships and cross-account grants and rank them by the exposure they create, then hand you an ordered remediation plan. Nothing in your environment is modified — closing the findings is work you do with your team or a follow-on remediation sprint.
See where you stand
A health check finds and prioritizes real exposure. It is not a certification or a promise you will never be breached — closing the findings is what changes your risk.
Related domain surfaces
The rest of what we assess
The same read-only assessment covers every domain — see what else it looks at.
