Who is accountable when cross-account trust policies drift?

Why This Matters for Security Teams

Cross-account trust drift is not a cosmetic configuration issue. It changes who can assume roles, which permissions can be inherited, and how far a compromise can spread across cloud boundaries. When ownership is unclear, teams often assume the platform layer is responsible while security assumes the application or account owner is watching. That gap is where privilege quietly expands.

This is especially dangerous in environments that rely on permission sets, organization-wide trust policies, and federated role assumptions. The control plane can make a change appear routine while actually widening blast radius. NHI Mgmt Group’s Top 10 NHI Issues research repeatedly shows that excessive privilege and weak visibility remain core failure modes, and NIST’s Cybersecurity Framework 2.0 treats governance and ownership as first-order security responsibilities, not after-the-fact documentation.

In practice, many security teams encounter trust drift only after a role assumption has already been abused, rather than through intentional review.

How It Works in Practice

Accountability starts with assigning a named owner to each cross-account trust relationship, not just to the account itself. That owner needs authority to approve changes, review trust paths, and confirm that any role assumption still matches business intent. Shared governance constructs such as AWS Organizations, enterprise permission sets, and central identity providers can simplify administration, but they also make drift easier to miss if no one owns the effective trust boundary.

Operationally, teams should treat trust policies like other security-critical configurations: version them, baseline them, and review them continuously. Current guidance suggests pairing cloud security posture checks with identity governance so that changes to trust, session duration, external principals, and conditions are visible in the same workflow. The most useful control evidence is not a one-time approval, but a repeatable review trail showing who can assume what, from where, and under which conditions.

• Define one accountable owner for each trust policy, permission set, and management-account change.
• Monitor drift against approved baselines, including external principals and condition keys.
• Require joint review from platform and security teams for changes that expand trust scope.
• Use alerting for role assumption anomalies, especially in dormant or rarely used paths.

This aligns with the lifecycle and audit emphasis in NHI Mgmt Group’s Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs and with NIST SP 800-53 Rev. 5 control discipline around access enforcement and configuration management. These controls tend to break down when multiple teams can edit trust policies through separate consoles because accountability fragments faster than change records can reconcile.

Common Variations and Edge Cases

Tighter trust governance often increases review overhead, requiring organisations to balance change velocity against the risk of silent privilege expansion. That tradeoff becomes sharper in multi-account environments, where platform teams may own the landing zone but application teams depend on shared roles to keep delivery moving.

There is no universal standard for this yet, but current guidance suggests a few practical distinctions. If a central platform team administers the trust framework, it is accountable for the baseline and enforcement mechanism. If an application or workload team requests the trust relationship, it remains accountable for the business justification and ongoing use. In regulated environments, audit teams will usually expect both to be documented.

Edge cases often arise with temporary migrations, third-party integrations, and break-glass access. These scenarios need explicit expiry, named approvers, and post-use review, because “temporary” trust often becomes permanent drift. NHI Mgmt Group’s Ultimate Guide to NHIs — Regulatory and Audit Perspectives is useful here, especially when combined with lessons from the Salesloft OAuth token breach, where control-plane and token-governance weaknesses turned drift into exposure.

Where trust policies are delegated to many teams without central standards, accountability becomes shared in theory and invisible in practice.

Related resources from NHI Mgmt Group

• How should security teams govern AWS cross-account trust policies?
• Who is accountable when automated response disables an account or isolates a system?
• Who is accountable when encryption drift causes exposure in cloud environments?
• Extension Trust Drift