TL;DR: Third-party breaches now account for 30% of incidents in Verizon’s 2025 DBIR, while SecurityScorecard says 35.5% of breaches are linked to third-party access, showing that vendor ecosystems have become a primary attack path, according to Secureframe’s compiled statistics. The governance problem is no longer assessment volume alone but whether risk controls can see beyond direct vendors into the nth-party chain.
At a glance
What this is: This is a Secureframe roundup showing that third-party risk has moved from direct vendor review to broader ecosystem governance, with fourth-party exposure now part of the problem set.
Why it matters: It matters because IAM, PAM, and NHI teams must govern external access paths, delegated trust, and downstream data sharing rather than treating each supplier as an isolated relationship.
Context
Third-party risk is no longer limited to contractual due diligence on named suppliers. The control problem now includes ecosystem governance, where vendors, sub-processors, managed service providers, and other downstream dependencies can all create access and data exposure that the primary relationship does not fully reveal.
In identity terms, this is a governance challenge around who can act, authenticate, and retain access outside the organisation's direct control. That matters for both human access and NHIs, because delegated credentials, integration tokens, and vendor-managed accounts often sit at the boundary where oversight becomes weakest.
Key questions
Q: What breaks when third-party risk is managed only at the vendor level?
A: Vendor-only review misses downstream processors, integrations, and sub-contractors that can inherit access or data handling responsibility. The result is a false sense of control, because the organisation can approve one supplier while the real exposure sits with another party that never went through the same scrutiny. That is why ecosystem tracing matters more than one-off assessments.
Q: Why does fourth-party exposure increase identity and access risk?
A: Because identity controls depend on knowing who holds the credential, who can delegate it, and who can revoke it. Fourth-party relationships obscure that chain, so service accounts, tokens, and support access can persist outside the original approval boundary. When ownership is unclear, offboarding and access review become incomplete by design.
Q: What are the signs that third-party tag governance is failing?
A: Common warning signs include reliance on manual checklists, limited understanding of how JavaScript behaves in production, and a gap between approved policy and actual tag activity. If teams cannot see which scripts are reading form data, or if they only review tags after deployment, governance is already weak. Ongoing alerts about non-compliant behavior are another sign the environment needs tighter control.
Q: Should organisations assess third-party risk continuously or on a schedule?
A: Continuous assessment is the right model for critical vendors because the attack surface changes faster than annual or quarterly reviews. New subdomains, new integrations, and new leaked credentials can appear between assessments, and attackers often act within days. Scheduled reviews still have value, but they should be the minimum baseline, not the only control.
Technical breakdown
Why third-party review no longer captures the full attack surface
Traditional third-party risk management treats each vendor as a discrete review unit. That model breaks when a supplier relies on sub-processors, SaaS integrations, or managed service providers that can inherit access to data or systems without being visible in the original onboarding decision. The real issue is not only whether a vendor passed review, but whether downstream relationships create untracked trust chains and unmanaged exposure. In identity terms, those chains often include service accounts, API tokens, or privileged support access that sit outside normal access governance.
Practical implication: Map vendor relationships beyond the first contract and require visibility into delegated access paths, not just direct supplier attestations.
Nth-party access creates governance gaps in credentials and privilege
Nth-party risk becomes an identity problem when a third party can share data or access with another party that your organisation does not directly know. That breaks common assumptions in IAM and PAM, where ownership, lifecycle, and revocation are tied to a known account holder or system. If a credential is re-used, inherited, or passed through an integration layer, offboarding and access review lose precision. The result is a control gap between the party you approved and the entity actually handling your data or systems.
Practical implication: Require contractual and technical controls that bind every external credential to an accountable owner and an auditable lifecycle.
Why AI adoption is amplifying third-party oversight problems
AI use inside vendor ecosystems adds a new layer of opacity. When suppliers use AI for support, analysis, or decision-making, TPRM teams must understand what data enters the model, how outputs are used, and whether the AI service itself has its own subcontractors or external dependencies. That creates governance questions that sit across privacy, security, and model risk. For identity teams, the important point is that AI-assisted third parties may generate or consume credentials, data, and access decisions faster than current review cycles can track.
Practical implication: Extend third-party governance to AI usage disclosure, data handling boundaries, and downstream service dependencies.
Threat narrative
Attacker objective: The attacker aims to reach sensitive data or systems through a trusted external relationship that the primary organisation cannot fully observe or control.
- Entry begins when an organisation grants a vendor, integration, or managed service provider access to systems or data without full visibility into the vendor's downstream dependencies.
- Credential or access abuse occurs when the third party shares data or permissions with an Nth party, or when a compromised vendor account is reused across connected services.
- Escalation follows because the original review did not cover the downstream party, leaving the organisation unable to revoke or constrain the true actor in time.
- Impact is broader data exposure, disrupted operations, or breach propagation across multiple linked organisations and services.
Breaches seen in the wild
- Klue OAuth Supply Chain Breach: OAuth tokens compromised in Klue integration breach affecting 700+ organisations via Salesforce data access chain.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Ecosystem governance is replacing vendor-by-vendor review as the relevant control model. The statistics in this article show that third-party risk is no longer a point-in-time questionnaire problem. Once fourth-party exposure, downstream sharing, and third-party access paths are part of the operating environment, governance has to shift from supplier approval to relationship tracing and continuous oversight. For practitioners, this means the control objective is visibility across the ecosystem, not just a signed assessment.
Third-party risk is now an identity governance problem as much as a procurement problem. External access only becomes manageable when every account, token, and delegated relationship has a lifecycle owner and revocation path. That applies directly to NHI governance because machine credentials often travel farther and faster than human access approvals can follow. Practitioners should treat third-party identity governance as a first-class control domain, not a spreadsheet attachment.
Fourth-party exposure is the named concept that best captures this article's signal. The article's data shows that risk often emerges one relationship beyond the vendor you actually reviewed, which means conventional vendor scoring can miss the actor that ultimately processes the data or touches the system. That is a governance failure mode, not just an assessment gap. Practitioners need to design for inherited trust and downstream accountability.
AI makes ecosystem governance harder because it obscures the processing chain. Once vendors use AI to handle support, analysis, or content generation, the question is no longer only who has access, but what system is making decisions on the vendor's behalf and where the underlying data goes. That intersects directly with agentic AI identity and NHI governance when AI services consume credentials or act through delegated integrations. Practitioners should extend third-party governance to AI-enabled processing paths.
Framework alignment should start with control visibility, then move to resilience and supply chain assurance. This topic maps most strongly to NIST CSF, NIST 800-53, DORA, and NIS2 because the problem is governance across external dependencies and recovery from third-party disruption. Where machine identities or delegated tokens are involved, OWASP-NHI becomes relevant as the identity layer of the same problem. Practitioners should align external-access oversight to both resilience and identity control ownership.
From our research library:
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
- Read next: Top 10 NHI Issues
What this signals
Fourth-party exposure is now the control boundary that matters. Third-party reviews still have value, but they do not explain who the supplier shares data or access with after onboarding. That means security and identity teams need to treat downstream dependency mapping as a standing governance task, not an exception workflow.
The practical shift is toward relationship-aware controls that combine vendor inventory, access ownership, and continuous change detection. For IAM and NHI programmes, that means every external token, integration, and shared account needs a revocation path that still works after the vendor relationship has been extended or subcontracted.
For practitioners
- Map all downstream dependency chains Inventory not only direct vendors but also their sub-processors, MSPs, and integration partners, then document where data, credentials, and support access can flow beyond the primary contract.
- Bind every external credential to an owner Assign a named internal owner for each vendor account, token, certificate, or support path so revocation, review, and exception handling are not dependent on the supplier's memory.
- Require downstream disclosure in contracts Add clauses that require suppliers to disclose third-party and Nth-party sharing, including AI usage and delegated processing, before access is granted or renewed.
- Rework reviews around continuous monitoring Move away from annual reassessment alone and track access changes, new integrations, and anomalous sharing events as part of ongoing third-party governance.
- Test offboarding against real access paths Validate whether access removal actually reaches vendor-managed accounts, shared tokens, and integrated systems, not just the supplier entry in the register.
Key takeaways
- Third-party risk is no longer contained by direct vendor review, because downstream sharing and fourth-party exposure now create the real governance gap.
- The most material failure is not lack of assessment volume, but lack of visibility into who actually handles data and access after the first vendor hop.
- Practitioners need continuous oversight, ownership of external credentials, and contractual disclosure of downstream dependencies to reduce ecosystem risk.
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 surface, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the technical controls, and DORA defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.SC-01 — Supply Chain Risk Management Policy | The article centers on governing external dependencies and downstream supplier risk. |
| PR.AA-05 — Access Permissions, Entitlements and Authorizations | Third-party access and delegated credentials are the core control problem here. | |
| Recommendation — Define supply chain risk governance that covers direct vendors and downstream third parties. Review external entitlements continuously and revoke access that exceeds approved scope. | ||
| NIST SP 800-53 Rev 5 | SA-9 — External System Services | The article focuses on managing risk from externally provided services and dependencies. |
| Recommendation — Apply SA-9 to define, monitor, and verify controls over external system services. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | Third-party credentials and downstream access paths are the attack mechanisms described. |
| Recommendation — Map third-party access paths to TA0006 and TA0008 to prioritise containment and detection. | ||
| DORA | ICT third-party risk — ICT third-party risk management | The article explicitly cites DORA as a regulatory driver for third-party resilience. |
| Recommendation — Align ICT third-party governance and resilience testing to DORA expectations. | ||
Key terms
- Fourth-party risk: Fourth-party risk is the exposure created by a vendor’s own vendors, sub-processors, and downstream service dependencies. It matters because direct contractual control usually stops at the first tier, while operational and data-risk propagation often continues much further through the chain.
- Ecosystem Governance: Ecosystem governance is the practice of managing risk across the full chain of external relationships, not just the immediate vendor. It combines inventory, access oversight, disclosure requirements, and monitoring so that downstream dependencies do not sit outside control boundaries.
- Nth-Party Access: Nth-party access is any data or system access that occurs through a chain of suppliers, sub-processors, or integrators beyond the direct third party. The main risk is loss of visibility, because the organisation may approve one party while another party actually handles the credential or data flow.
- Third-party risk management: Third-party risk management is the process of identifying, assessing, monitoring, and reducing risk introduced by external vendors and service providers. In identity terms, it governs who outside the organisation can reach systems or data, how that access is approved, and when it must be removed.
Deepen your knowledge
The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It is designed for practitioners who need to connect identity control to broader security and compliance programmes.
Published by the NHIMG editorial team on July 11, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org