A non-transitive trust is intended to stop trust from extending outside the two domains that formed it. Administrators use it to limit authentication scope between specific domains. In Kerberos environments, however, referral chaining can undermine that expectation and allow access to additional domains within the trusting forest.
Expanded Definition
Non-transitive trust is a trust relationship that is designed to stop at the two domains that created it, rather than propagating trust beyond that boundary. In identity architecture, that distinction matters because it defines where authentication evidence is valid and where it must be re-evaluated. In Kerberos-based environments, the intent can be weakened by referral chaining, which may let a user or workload reach additional domains inside the same forest even when administrators expected a strict two-party trust. That is why the term is best understood as an access-scoping control, not as a guarantee that no wider path can ever exist. For governance, the operational question is whether domain controllers, forests, and service dependencies are configured to preserve the intended trust boundary. Guidance varies across vendors and platforms, so teams should validate actual ticket flow rather than rely on the trust label alone. The most common misapplication is assuming a non-transitive trust automatically prevents lateral access when forest referral rules still permit chained authentication.
For the underlying protocol mechanics, see NIST SP 800-53 Rev 5 Security and Privacy Controls and the identity lifecycle context in Ultimate Guide to NHIs.
Examples and Use Cases
Implementing non-transitive trust rigorously often introduces administrative complexity, requiring organisations to weigh tighter authentication boundaries against the cost of cross-domain troubleshooting and policy drift.
- A parent and child domain create a limited trust so a service account can authenticate only to one approved domain, reducing broad forest-wide reach.
- A merger scenario uses a temporary trust while identity consolidation is in progress, then removes it once cross-domain dependencies are eliminated.
- A workload in one domain accesses a partner domain through carefully scoped federation, with administrators verifying that referrals do not extend beyond the intended boundary.
- An NHI program reviews service account access paths after learning that credentials were valid in more places than expected, using Ultimate Guide to NHIs as a governance reference for scope, rotation, and offboarding practices.
- Teams map the trust path against NIST SP 800-53 Rev 5 Security and Privacy Controls to confirm least privilege and boundary enforcement.
In practice, non-transitive trust is most useful when organisations need a narrow interoperability bridge without granting full forest-wide authentication, especially where service accounts or other NHIs must be constrained to specific business functions.
Why It Matters in NHI Security
Non-transitive trust matters because NHI compromise often spreads faster than teams expect once trust boundaries are too loose or misunderstood. When service accounts, API keys, or machine credentials operate across domains, a single mis-scoped trust can turn one compromised identity into access across multiple systems. That risk is especially relevant in environments where NHIs already outnumber human identities by 25x to 50x, and visibility into those identities is often limited. NHI Mgmt Group reports that only 5.7% of organisations have full visibility into their service accounts, which makes trust-path validation critical rather than optional. This is also why non-transitive trust must be reviewed alongside secrets governance, account lifecycle controls, and forest design, not treated as a one-time directory setting. The most mature programs test actual authentication routes, confirm where referrals can travel, and revoke assumptions that no longer match reality. See the broader NHI exposure patterns in Ultimate Guide to NHIs.
Organisations typically encounter this consequence only after an unexpected domain-to-domain access event, at which point non-transitive 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 CSA MAESTRO 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-05 | Trust scope and cross-domain access paths are part of NHI boundary control. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access depends on limiting how authentication trust propagates. |
| NIST Zero Trust (SP 800-207) | SC-7 | Zero Trust architecture requires explicit boundary enforcement between trust domains. |
| NIST SP 800-63 | Digital identity assurance depends on limiting where an authenticator is accepted. | |
| CSA MAESTRO | Agentic systems inherit risk when identity trust chains extend beyond intended bounds. |
Validate where identity assertions remain valid and revoke assumptions that exceed scope.
