Borrowed trust is the security condition where one system relies on another system, package, token, or automation path to act legitimately on its behalf. In practice, it creates hidden attack paths because the trusted component often inherits permissions broader than the original use case requires.
What borrowed trust means in practice
Borrowed trust appears when a system is allowed to act through another system's legitimacy, such as delegated credentials, inherited permissions, package trust, or an automation chain. The trust relationship is often implicit, so the consuming system may gain more authority than the original use case really needs.
This makes borrowed trust a security design issue, not just a convenience pattern. The key question is whether the trust being reused is still bounded, observable, and narrow enough for the real workload.
Where borrowed trust comes from
Borrowed trust usually enters through delegation, shared tokens, trusted third-party components, or automation that quietly expands access on behalf of something else. It can also show up when a service uses another service's session, certificate, or deployment path to avoid re-authentication or repeated approval.
The danger is that the original trust decision is often made for one purpose, then reused in a different context. Once that happens, the second system inherits a trust edge it may never have been explicitly designed to hold.
Why borrowed trust creates hidden attack paths
Borrowed trust creates an attack path because compromise of the trusted intermediary can become equivalent to compromise of the dependent system. Attackers do not always need the final target directly, they only need the component whose authority is being borrowed.
NIST SP 800-207 Zero Trust Architecture is useful here because its never-trust, verify model directly challenges assumptions that one trusted path should automatically confer access elsewhere. That same logic also helps explain why borrowed trust is dangerous in service chains and automation pipelines.
If the borrowed component has broad standing permissions, the resulting path can bypass intended segregation, approval, or user-bound controls. That is why borrowed trust often turns a single dependency into a lateral movement opportunity.
How to recognise and reduce borrowed trust
Borrowed trust is easiest to miss when the trust boundary is hidden inside middleware, orchestration, packages, or delegated automation. A useful way to spot it is to ask whether the component performing the action is the same component whose authority was actually approved.
SPIFFE workload identity specification is relevant because it treats workload identity as something that should be explicit and verifiable rather than implied by network location or ambient trust. That makes it a strong counter-pattern to accidental trust borrowing in service-to-service access.
Reducing borrowed trust usually means making the actor, the audience, and the permission scope more explicit so that legitimacy is not silently inherited across components. When the trust chain is visible, it becomes much easier to see where delegation should end and where a separate authorization decision should begin.
Why borrowed trust matters for security architecture
Borrowed trust is important because it often grows faster than the security model around it. What begins as a practical shortcut can gradually become a standing privilege path, especially in systems with automation, reusable packages, or long-lived tokens.
NIST Cybersecurity Framework 2.0 supports the broader governance view of this issue because borrowed trust affects how organisations identify assets, protect access paths, detect misuse, and recover from dependency compromise. It is not only a technical concern, it is also an architecture and control ownership concern.
In mature environments, borrowed trust should be treated as a design assumption that must be justified, scoped, monitored, and revisited. If it is left to drift, the trust relationship can outlive the original need and become the very path an attacker uses to move through the environment.
Risk and Threat Considerations
Borrowed trust is risky because the trusted intermediary often holds more authority than the downstream task actually needs. That creates hidden exposure: compromise, misuse, or overreach in the intermediary can become direct access to the dependent system.
Failure mechanism: An attacker abuses delegated authority, trusted automation, or inherited permissions to act as if they were the legitimate component, then pivots through the borrowed trust path into broader access or persistence.
Impact: The organisation can lose containment between systems, enabling privilege escalation, lateral movement, unauthorised actions, and difficult-to-detect compromise through a relationship that appeared safe.
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 Zero Trust (SP 800-207), 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 |
|---|---|---|
| NIST Zero Trust (SP 800-207) | Zero Trust Architecture | Borrowed trust directly conflicts with implicit trust assumptions in access paths |
| Recommendation — Replace ambient trust with explicit verification and least-privilege authorization at each access decision. | ||
| NIST CSF 2.0 | PR.AA-05 — Identities and credentials are issued, managed, verified, revoked, and audited | Borrowed trust often depends on delegated or inherited credentials and access paths |
| PR.AA-01 — Identities and credentials for authorized users, services, and devices are managed | Borrowed trust commonly arises when service and automation identities are reused beyond intent | |
| Recommendation — Track and govern delegated credentials and revocation so inherited authority cannot linger unnoticed. Manage service and automation identities so trust is explicit, scoped, and separated by purpose. | ||
| MITRE ATT&CK | T1078 — Valid Accounts | Borrowed trust can let attackers operate through legitimate accounts or tokens |
| Recommendation — Monitor for abuse of legitimate access paths that let an attacker blend into normal trust relationships. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Borrowed trust expands authority beyond what the consuming task truly requires |
| Recommendation — Apply least privilege so trusted intermediaries do not inherit excess rights. | ||
Practitioner Guidance
Why practitioners should care: Borrowed trust is often introduced for speed, but it should be treated as an explicit control decision, not an architectural accident. The practical question is whether the trust path is narrower than the authority it unlocks.
Practitioner takeaway: If a system can act only because another component is trusted, document that dependency, limit its scope, and review it as rigorously as any other privilege path.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 31, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org