An IAM trust relationship is the policy link that lets one identity or account assume another role or access its permissions. It defines who can be trusted, under what conditions, and with what authentication context, so a weak trust policy can create unintended privilege paths.
How IAM Trust Relationships Work
An IAM trust relationship is the policy layer that lets one principal assume a role or inherit another account’s permissions. The trust policy is separate from the permission policy, and that separation is what makes role assumption explicit, auditable, and controllable.
In practice, trust relationships define the trusted caller, the action used to assume the role, and the conditions that must be satisfied before access is granted. Those conditions often include account identity, external identity context, source network or source ARN, session attributes, or other request context that narrows who can cross the trust boundary.
Why Trust Policies Create Security Boundaries
Trust relationships are a boundary control, not just a configuration detail. They determine whether access is delegated at all, and they shape the blast radius when a workload, vendor, or sibling account is compromised. A broad trust policy can turn a single foothold into lateral access across roles, accounts, or environments.
Because trust is about who may assume power, weak patterns such as wildcard principals, overly broad conditions, or missing external identity constraints can create unintended privilege paths. The core security question is not only what a role can do, but who can reach that role in the first place.
Common Failure Modes and Abuse Paths
Trust relationships fail when the policy is too permissive, too hard to review, or too easy to reuse across environments. Common failure modes include confused deputy problems, cross-account role chaining that was never intended, and trust policies that remain valid long after the original business need has passed.
Attackers and insiders often target trust because it can bypass direct credential theft requirements. If they can influence a trusted principal, replay an assumed session, or satisfy weak trust conditions, they may obtain access without ever touching the target account’s native login flow. NHIMG’s How to review AWS cross-account trust policies for confused deputy is a useful practical reference for that failure pattern.
How Practitioners Should Evaluate Trust Relationships
Review trust policy design as part of access governance, not only during deployment. The important checks are whether the trusted principal is still legitimate, whether the trust conditions are specific enough to prevent unintended assumption, and whether the role’s permissions remain appropriate if trust is exercised more often than expected.
For cloud and federated environments, trust analysis should also consider role chaining, third-party access, and the relationship between trust policy scope and downstream permissions. NHIMG’s AWS IAM Policies and Roles Guide helps place trust policies in the wider role and permission model, while IaC identity policy checks shows how to catch risky trust patterns before they reach production.
Risk and Threat Considerations
Trust relationships are a high-value target because they convert one identity relationship into another account’s authority. If the trust boundary is too broad, a compromise in one place can become delegated access elsewhere, especially in cross-account, third-party, or federated setups.
Failure mechanism: The trust policy grants assumption rights to principals that are too broad, too persistent, or too weakly constrained, allowing an attacker or misconfigured workload to step into a more privileged role.
Impact: Unauthorized role assumption can lead to privilege escalation, cross-account lateral movement, persistent access, and exposure of sensitive cloud resources or secrets protected by the assumed role.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 provides the primary governance reference for this term.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | Trust assumptions depend on verifying the caller before role assumption is allowed. |
| AC-2 — Account Management | Trust relationships govern which accounts may be enabled to act across roles and boundaries. | |
| AC-6 — Least Privilege | A trust policy can expose excess authority if the assumed role has broader access than required. | |
| Recommendation — Bind role assumption to strongly authenticated organizational users and service actors. Review trusted accounts and disable any role paths no longer needed. Limit trusted principals to the minimum role scope needed for the business function. | ||
Practitioner Guidance
What to watch for: Treat trust policies as living security controls. Revalidate them whenever vendors change, accounts are merged, workloads move, or federated paths are added, because the original trust assumption often outlives the operational reason for it.
Governance implication: Assign a clear owner for every trust relationship and require periodic recertification of both the trusted principal and the business justification. NHIMG’s Identity Security Programme Guide is a strong reference for building that accountability into programme design.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 29, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org