Two-way trusts expand the paths an attacker can use once one domain is compromised. If credentials or trust relationships are abused in a partner or acquired environment, the attacker can pivot into the connected domain and move laterally. That matters most when third parties share trust, because a weaker external environment can become the entry point into a more sensitive internal one.
Why Two-Way Trusts Expand Attack Paths
Two-way trusts create a bidirectional relationship between security domains, so compromise in either side can become a pathway into the other. That changes lateral movement from a single-domain problem into a cross-domain problem, especially when one side has weaker controls, broader privileges, or poorer monitoring.
The core issue is not the trust itself, but the expanded set of authenticated paths and implicit assumptions it creates. If an attacker gains valid access, they can often reuse that trust boundary to reach adjacent systems faster than by attacking each environment independently.
How Trust Relationships Become Lateral Movement Conduits
In an enterprise environment, a two-way trust often allows authentication or authorization decisions made in one domain to be accepted by the other. Once an account, token, or privileged session is abused on one side, the attacker may be able to enumerate resources, request access, or move into the connected environment without starting over.
This is why two-way trusts are especially sensitive in mergers, managed service relationships, and partner integrations. The risk is cumulative: each additional trust edge increases the number of places an attacker can pivot from, and every shared administrative path or directory relationship can become a reusable route for propagation.
When the connected environment is less mature, trust can also become a force multiplier for an attacker. A compromised partner domain, acquired business unit, or external tenant can provide the initial foothold, while the more sensitive environment supplies the higher-value target.
What Practitioners Need to Watch in Trusted Domains
Two-way trusts increase exposure when they are broader than the actual business need. Overly permissive trust settings, excessive admin groups, shared service credentials, and weak segmentation all reduce the effort required to translate one compromise into lateral movement.
Monitoring also becomes harder as trust relationships multiply. Security teams need to understand not just whether a trust exists, but what authentication methods, delegation rules, name resolution paths, and administrative privileges cross that boundary. Without that inventory, detection often arrives after the attacker has already used the trust to reach a second environment.
Risk and Threat Considerations
Two-way trusts create a larger blast radius because one compromised domain can be used to reach another through accepted trust paths. That is especially dangerous when the trusted environment has weaker identity hygiene, because the attacker can abuse the trusted relationship instead of defeating controls separately in each domain.
Failure mechanism: An attacker compromises credentials, a privileged session, or a delegated trust path in one domain, then uses the bidirectional trust to authenticate, enumerate, and pivot into the connected domain with less friction than a direct attack would require.
Impact: Lateral movement becomes faster, broader, and harder to contain, which can turn a local compromise into cross-domain access, privilege escalation, and wider data exposure.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1021 — Remote Services | Two-way trusts enable cross-domain pivoting via accepted access paths. |
| Recommendation — Hunt for cross-domain pivoting and remote-service use after trust abuse. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions and Authorizations are Managed, Enforced, and Reviewed | Trusted domains need reviewed cross-domain authorization paths and privileges. |
| PR.AA-02 — Identities and Credentials are Issued, Managed, Verified, Revoked, and Audited | Trust abuse often starts with stolen or misused credentials across domains. | |
| Recommendation — Review and constrain permissions that cross trust boundaries. Audit credentials and revoke any cross-domain access no longer required. | ||
| NIST SP 800-53 Rev 5 | AC-4 — Information Flow Enforcement | Two-way trusts are governed by enforced information-flow and boundary rules. |
| AC-6 — Least Privilege | Excess privilege across trusts materially raises lateral movement risk. | |
| Recommendation — Enforce boundary controls on what can traverse the trust. Limit cross-domain permissions to the minimum required. | ||
Practitioner Guidance
What to verify: Confirm whether the trust is actually needed in both directions, and map which identities, groups, and admin paths traverse it. If the answer is “broad access by default,” treat that as an architectural risk rather than a configuration detail.
Decision rule: If one side of the trust is materially less mature, less monitored, or more exposed to third parties, assume it is the higher-probability entry point and bound the trust accordingly. Narrow scope, isolate administrative functions, and review cross-domain privilege as part of the trust itself, not as a separate control exercise.
Practitioner takeaway: Two-way trusts are risky because they turn compromise in one environment into an access problem for both, so the control objective is to minimize reusable pathways, not merely to document the relationship.
Related resources from NHI Mgmt Group
- Why do service accounts increase lateral movement risk in enterprise environments?
- Why do third-party connections increase lateral movement risk in enterprise environments?
- Why do vulnerable SCP client implementations increase lateral movement risk in enterprise file transfer environments?
- Why do incomplete MFA deployments increase the risk of lateral movement and ransomware in enterprise environments?