The network of vendors, contractors, managed service providers, and platforms that can reach your environment through approved access. It matters because one weak link can create many downstream entry points, especially when credentials, support channels, or integrations are shared across multiple organisations.
Expanded Definition
A Third-Party Trust Graph is the practical map of who can access what through external relationships, including vendors, contractors, managed service providers, and integrated platforms. It is more than a procurement list or an access roster. It captures transitive trust, meaning a partner may not only reach your environment directly but may also extend access through support tools, shared credentials, federated identities, OAuth grants, API keys, or downstream sub-processors.
Definitions vary across vendors, but the security meaning is consistent: the graph shows how trust propagates across organisational boundaries and where a compromise can spread laterally through approved channels. That makes it especially relevant in NHI governance, where non-human identities often bridge systems and organisations far more broadly than human users do. Guidance from the OWASP Non-Human Identity Top 10 reinforces the need to inventory and constrain machine access with the same discipline applied to human identity. The most common misapplication is treating third-party access as a single account review, which occurs when organisations ignore delegated permissions, service-to-service paths, and forgotten vendor credentials.
Examples and Use Cases
Implementing a Third-Party Trust Graph rigorously often introduces visibility and coordination overhead, requiring organisations to weigh faster partner enablement against tighter control of shared access paths.
- A SaaS provider has admin access to a production tenant for support, but also maintains an OAuth integration that can refresh tokens without a fresh human approval cycle.
- A managed service provider uses a jump host and privileged automation accounts to administer multiple customer environments, creating shared exposure if one credential is stolen.
- A software vendor ships an update pipeline that can access build secrets, which then become reachable if the vendor’s CI/CD environment is compromised, as seen in incidents covered by the Reviewdog GitHub Action supply chain attack.
- An AI platform receives API keys from a customer to manage prompts or agents, creating a trust edge that can be abused if key rotation and scoping are weak, a pattern also reflected in the JetBrains Marketplace AI Plugin Campaign.
- A platform marketplace app is approved once, then silently inherits access to multiple downstream data sources through broad scopes and long-lived tokens.
NHIMG’s research shows that 92% of organisations expose NHIs to third parties, raising supply chain risk across the trust graph. That concern is not theoretical; in the 52 NHI breaches Report, compromised machine access repeatedly acted as the bridge between an external foothold and internal impact. NIST guidance on access control in NIST SP 800-53 helps teams translate these paths into explicit approval, scoping, and review steps.
Why It Matters for Security Teams
Security teams need the Third-Party Trust Graph because compromise rarely stays at the first boundary. Once a vendor account, shared secret, or delegated token is abused, attackers can inherit legitimate trust and move through business-approved channels that do not trigger obvious perimeter alarms. That is why this concept belongs at the center of identity governance, NHI management, and third-party risk reviews. The graph is also a governance problem: if access is granted faster than it is inventoried, expired, or revoked, the organisation loses sight of who can still reach sensitive systems.
This becomes especially important in agentic and platform-driven environments, where machine identities often outlive the workflows they were created for. NHIMG reports that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, which makes third-party paths a major attack multiplier rather than a niche concern. The same pattern appears in platform and package compromise research such as the Shai Hulud npm malware campaign and LiteLLM PyPI package breach, where trust in external dependencies became an access path. Organisations typically encounter the full consequence only after a partner compromise, at which point the trust graph becomes operationally unavoidable to map and reduce.
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 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5 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 | Defines machine identity risk where third-party access paths often expand unchecked. | |
| NIST CSF 2.0 | ID.AM-1 | Asset inventory includes external dependencies and trust relationships that shape exposure. |
| NIST SP 800-53 Rev 5 | AC-20 | External system connections govern how trusted third parties may access resources. |
| NIST SP 800-63 | AAL2 | Assurance levels matter when external parties authenticate into sensitive environments. |
Inventory and constrain every external machine identity, token, and delegated access path.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on July 10, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
