TrustedBy Relationship

How a TrustedBy relationship works in Active Directory

A TrustedBy relationship is a trust boundary in Active Directory that changes which directory can make authentication or authorisation decisions for a principal. It is not just a naming convention, it is an access dependency that can redirect how users, groups, and delegated admins are evaluated across domains or forests.

That makes the relationship operationally important in environments where one directory is allowed to rely on another directory’s identity assertions. The trust can simplify cross-domain administration, but it also means that the security posture of the trusted side affects the effective access decisions made by the relying side.

Where TrustedBy relationships are used

These relationships are most often seen where organisations need delegated administration, cross-domain access, or phased directory integration. In practice, the relationship helps one security boundary accept identities managed elsewhere, so administrators do not have to duplicate accounts or manually recreate group structures for every domain.

That convenience is why trusts appear in large enterprises, mergers, shared services, and complex domain topologies. The same mechanism can also be used to support legacy application access patterns that depend on directory-wide authentication rather than local account stores.

Security implications of trust direction

Trust direction matters because it defines which side is being relied on for identity decisions. A poorly understood trust can widen access more than intended, especially when administrators assume that a boundary is stricter than it really is or when delegated permissions are broader than the trust was meant to support.

From a security perspective, the main issue is that a compromise on one side can create a path into another side if the trust is configured to accept those decisions. A trust therefore behaves like a control dependency, not merely a connectivity setting, and it should be treated as part of the access model.

For broader control context, trust relationships should be reviewed alongside directory access control, authentication policy, and monitoring practices described in NIST SP 800-53 Rev 5 Security and Privacy Controls, because the same trust path that enables delegation can also expand the blast radius of a compromise.

How organisations govern and validate trust relationships

Governance starts with knowing which trusts exist, why they were created, and whether they still match the business need. Teams should be able to explain the direction, scope, and administrative intent of each trust without relying on tribal knowledge, because undocumented trust dependencies are a common source of unexpected access.

That review should include vendor and platform guidance for the exact Active Directory design, plus validation of the trust boundary in the context of least privilege and segmentation. Where trust is used to simplify administration, the trade-off should be explicit: easier access management in exchange for a larger inter-domain dependency surface. For a control model that helps frame that trade-off, NIST Cybersecurity Framework 2.0 is useful for tying the trust to governance, protect, detect, and recover outcomes.

Risk and Threat Considerations

TrustedBy relationships can turn a directory trust into an attack path if the trusted side is weaker than expected. Once an attacker gains a foothold in the trusted domain, the trust boundary may allow them to move into the relying domain, abuse delegated permissions, or amplify what would otherwise be a contained compromise.

Failure mechanism: A trust that is broader than intended, poorly monitored, or combined with excessive privileges can let a compromise on one side influence authentication or access decisions on the other side.

Impact: The result can be cross-domain lateral movement, wider account abuse, and a larger recovery scope because the trust relationship can propagate the consequences of one breach into multiple directories.

Practitioner Guidance

Governance implication: Treat every TrustedBy relationship as a managed security dependency, not just an interoperability setting. Assign clear ownership for who approves it, who reviews it, and what business justification keeps it in place.

What to watch for: Watch for trusts that outlive the original project, stale delegated access, and assumptions that one domain’s hardening automatically protects the other. The safest posture is to validate the trust against current business need, then verify that the access paths enabled by the trust still match the principle of least privilege.

Related resources from NHI Mgmt Group

• Who is accountable for third-party access when a vendor relationship ends?
• How should security teams handle third-party NHI access that outlives the vendor relationship?
• What do teams get wrong about RBAC, ABAC, and relationship-based access control?
• When should teams re-evaluate a verification vendor relationship?