An external trust is a trust relationship between two Active Directory domains. It is designed to allow authentication between those specific domains, but not beyond them. In practice, it is a boundary control that administrators often treat as narrowly scoped, even though attack paths may extend further through referral handling.
Expanded Definition
An external trust is a narrowly scoped Active Directory trust that allows authentication between two separate domains without creating full domain merger or forest-wide delegation. In NHI and IAM practice, it is often used when one organization needs controlled access to another organization’s directory resources, while preserving administrative boundaries and separate identity governance. The distinction matters because trust is not the same as privilege: a trust can make authentication possible, but it does not by itself authorize every resource or role.
Definitions and operational handling vary across vendors and implementations, especially when external trust is combined with referral processing, SID filtering, or legacy Kerberos dependencies. NIST Cybersecurity Framework 2.0 provides the broader governance lens for managing this kind of cross-boundary exposure, especially under NIST Cybersecurity Framework 2.0. In NHI programs, external trust should be treated as a controlled exception that demands explicit ownership, monitoring, and periodic validation. The most common misapplication is assuming an external trust is inherently limited to the intended peer domain, which occurs when administrators overlook how referral paths and transitive dependencies can extend effective reach.
Examples and Use Cases
Implementing external trust rigorously often introduces administrative overhead and monitoring complexity, requiring organisations to weigh interoperability against the risk of expanded attack paths.
- A parent company maintains a trust to a newly acquired subsidiary so users can authenticate across a short transition period without merging forests immediately.
- A partner organization uses an external trust for a single application domain, while keeping all other directory relationships isolated and separately governed.
- A legacy platform depends on cross-domain Kerberos authentication, and the external trust is retained only until the application is modernized or decommissioned.
- Security teams review the trust boundary alongside service account exposure, informed by guidance in the Ultimate Guide to NHIs, because directory trust often becomes a hidden path for NHI abuse.
- Identity architects compare the trust design to federation expectations in NIST Cybersecurity Framework 2.0 when deciding whether a direct trust or a more tightly governed access model is appropriate.
Why It Matters in NHI Security
External trust matters because it can silently widen the blast radius of compromised credentials, service accounts, or delegated administrative paths. In NHI environments, those risks often surface through referral handling, over-permissive authentication rules, or outdated assumptions that “external” means “fully contained.” NHIMG research shows that 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation, which is especially relevant when a trust boundary sits between two domains but is governed like a static network exception rather than an identity control. The operational question is not just whether authentication works, but whether the trust still serves a justified business purpose and whether the resulting pathways are observable.
Cross-domain trust also complicates incident response, because a compromise in one domain can require immediate review of linked authentication paths, privileged groups, and service identities in the other. Organisational risk becomes clearer when paired with the NHI governance lessons in the Ultimate Guide to NHIs, particularly around visibility and least privilege. Organisations typically encounter unexplained lateral movement or authentication anomalies only after an incident investigation, at which point external trust becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | External trust can widen identity attack paths across domains. |
| NIST CSF 2.0 | PR.AC | Access control governs trust boundaries and authentication exposure. |
| NIST Zero Trust (SP 800-207) | SC-7 | Zero Trust requires scrutinizing implicit trust between domains. |
| NIST SP 800-63 | Digital identity assurance informs how cross-domain authentication is trusted. | |
| OWASP Agentic AI Top 10 | Autonomous agents using cross-domain credentials can inherit trust risk. |
Treat external trust as an exception and enforce continuous verification at each boundary.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 27, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
