What breaks when organisations assume an external trust limits access to only two domains?

Why This Matters for Security Teams

Assuming an external trust only exposes two domains creates a false boundary. In practice, forest trusts and cross-domain authentication can allow referral traffic to continue beyond the intended pair, especially when service accounts, privileged groups, and legacy applications remain reachable through shared trust paths. That means the question is not just “can users log in,” but “what else can be requested once a ticket is issued.”

This matters because attackers do not need to defeat the trust relationship outright; they only need one valid path to enumerate reachable domains, request service tickets, and target privileged services for Kerberoasting or lateral movement. The OWASP Non-Human Identity Top 10 is clear that credential and trust misuse around machine identities is often where hidden exposure accumulates. NHIMG’s 52 NHI Breaches Analysis shows the same pattern across incidents: trust relationships are rarely abused in isolation.

In practice, many security teams discover the broader blast radius only after ticket activity has already crossed the boundary they believed was enforced.

How It Works in Practice

External trust in Active Directory does not mean “only two domains are reachable.” It means the authentication path and authorization scope must be examined at the ticket level. A user or attacker who obtains a referral ticket can often follow the trust path to additional domains in the forest, then request local tickets and service tickets for targets that were never intended to be in scope.

The operational issue is that access is evaluated dynamically as tickets are presented, not as a one-time network boundary. If privileged services are searchable, SPNs are exposed, or trust configuration is too broad, the attacker can pivot from the initial domain pair into higher-value domains. That is why NIST SP 800-53 Rev. 5 Security and Privacy Controls emphasizes access enforcement, least privilege, and continuous control over authenticated sessions rather than assuming a trust relationship is inherently safe.

• Review transitive trust paths, not only the explicitly paired domains.
• Inventory service accounts and SPNs in every reachable domain, then prioritise privileged services.
• Restrict where referral tickets can be used and monitor for cross-domain ticket requests.
• Harden Kerberos settings, especially around delegation, encryption types, and privileged service exposure.

NHIMG’s Ultimate Guide to NHIs is useful here because the same identity discipline applies to machine and service identities inside trusted AD forests: if credentials, tickets, or service principals are over-broad, the trust becomes an expansion path rather than a limit. These controls tend to break down in large forests with legacy trusts and unmanaged service accounts because ticket paths outpace the visibility of administrators.

Common Variations and Edge Cases

Tighter trust restrictions often increase administrative overhead, requiring organisations to balance interoperability against blast-radius reduction. There is no universal standard for every forest topology, so current guidance suggests treating trust scope as a continuously validated control rather than a static design assumption.

One edge case is selective authentication, which can reduce exposure but still leaves room for mis-scoped service access if SPNs and delegation are poorly governed. Another is when a trust looks limited on paper yet domain-local groups, shared admin tooling, or replicated secrets create indirect reachability. In those environments, the problem is often not the trust alone but the combination of trust plus excessive privilege.

For teams building detection, focus on anomalous cross-domain ticket activity, unexpected service-ticket requests, and the appearance of privileged authentication in domains outside the normal administrative model. NHIMG’s Microsoft SAS Key Breach and DeepSeek breach both reinforce a broader lesson: once a trust or secret is overextended, attackers usually look for the next reachable identity, not the first one.

Related resources from NHI Mgmt Group

• What breaks when access across trust domains is not tightly scoped?
• What breaks when organisations assume SASE automatically delivers Zero Trust?
• What breaks when organisations keep NTLM enabled as a fallback for too long?
• When should organisations treat on-prem access as a zero-trust problem?