Third- and fourth-party blind spots are raising breach costs

At a glance

What this is: This analysis says third- and fourth-party risk is widening because many organisations still cannot inventory, monitor, or tightly scope vendor access across their extended ecosystem.

Why it matters: IAM, PAM, and NHI teams need to treat external access as a lifecycle control problem, because unmanaged delegated access turns supplier relationships into breach amplification paths.

By the numbers:

• 47% of organisations experienced a breach involving a third party in the past year, according to Imprivata.
• 34% of those breaches were due to vendors having too much privileged access, according to Imprivata.

Context

Third-party access risk is what happens when an organisation extends trust outside its own boundary without keeping equal control over inventory, privilege, monitoring, and offboarding. In this article, Imprivata argues that the problem is no longer limited to direct suppliers because subcontractors and unmanaged tools now sit inside the same access chain.

For IAM and PAM teams, the issue is not whether vendors are trustworthy in principle. The issue is whether every external identity, credential, and access path is actually governed well enough to survive audits, incidents, and changing vendor relationships. That becomes harder once fourth-party dependencies are added to the picture.

The article frames third- and fourth-party exposure as a governance gap rather than a one-off vendor management failure. That matters because the controls required to manage external access have to cover lifecycle, scope, and visibility at the same time, not as separate programmes.

Key questions

Q: What breaks when third-party access is not reviewed continuously?

A: The break is that access stays active long after the business relationship, vendor task, or application purpose has changed. Without continuous review, teams rely on outdated certifications that do not reflect live permissions. The result is uncontrolled delegated access, especially across SaaS and OAuth-connected systems.

Q: Why does fourth-party exposure create more risk than normal vendor management?

A: Fourth-party exposure matters because the organisation often has direct governance only over the first vendor, not the subcontractors and tools that vendor uses. That means access may exist without clear ownership, review cadence, or contractual visibility. Risk rises when downstream entities inherit trust without the same identity controls applied to the primary supplier.

Q: How should healthcare organizations reduce breach risk from third-party vendors with privileged access?

A: Healthcare organizations should treat third-party privileged access as a high-risk control point, not a standing trust relationship. Limit vendor access to only what is needed, monitor privileged activity continuously, and pair access governance with multifactor authentication and rapid reset procedures. A vendor breach can become your breach when access is broad, persistent, and poorly observed. Strong controls around vendor access reduce downstream exposure and speed containment.

Q: Who is accountable for third-party access when a vendor relationship ends?

A: Accountability should sit with the business owner of the relationship, but IAM, PAM, and security teams must own the technical revocation and validation steps. If no one is responsible for proving access removal, the organisation has governance in name only.

Technical breakdown

Why third-party access control breaks down in extended ecosystems

Third-party access becomes difficult to govern when organisations rely on broad VPN paths, shared credentials, or incomplete inventories to manage external users. Once access is delegated to vendors, the control problem shifts from simple authentication to ongoing scope management, monitoring, and revocation. If the organisation cannot say exactly who the external identity is, what systems it can reach, and when that access should end, the access model is already too loose for modern supply chain risk.

Practical implication: replace broad external access paths with inventory-backed, least-privilege access policies and explicit expiry.

Why fourth-party risk is a visibility problem, not just a contract problem

Fourth-party risk appears when a vendor’s own suppliers, subcontractors, or tools inherit indirect access to systems or data. That creates a governance blind spot because the primary organisation may have a contract with the first vendor but no direct line of sight into the downstream identities actually using access. In practice, this means the attack surface expands beyond approved vendors into the vendor ecosystem that supports them, often without equivalent oversight or technical controls.

Practical implication: extend vendor inventories and access reviews to downstream providers and tools before granting or renewing access.

How privileged access multiplies breach impact in vendor chains

Privileged vendor access turns a supplier relationship into a high-consequence control plane. When third parties hold broad entitlements, an attacker who compromises one external account can move quickly into sensitive systems, data, or operational tooling. The article’s breach examples point to a common pattern: excessive vendor access shortens the path from initial compromise to material impact, especially when access is not tightly bound to named users, time limits, or task scope.

Practical implication: bind vendor access to named users, task scope, and time limits, then review privileged entitlements as a separate control class.

Threat narrative

Attacker objective: The objective is to use trusted external access as a shortcut into systems that would be harder to reach through direct attack.

1. Entry occurs through a third-party or fourth-party relationship that already has access to internal systems, data, or operational tools.
2. Escalation follows when the external identity or its credentials have broader privilege than the task actually requires.
3. Impact lands when attackers exploit that overextended access to reach sensitive data, administrative functions, or downstream services.

Breaches seen in the wild

• BeyondTrust breach 2024: A stolen BeyondTrust Remote Support API key let a China state-sponsored actor reset accounts and reach US Treasury workstations in 2024.
• Azure Key Vault Contributor escalation 2024: Datadog found Azure Key Vault Contributor could add itself to access policies and read every secret, key and certificate in a vault.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Third-party access risk is now a lifecycle problem, not a procurement problem. Organisations often treat vendor approval as the end of governance, but access risk actually begins after onboarding and continues until every credential, entitlement, and downstream dependency is removed or re-scoped. The article shows that visibility gaps and weak access inventories are what keep external trust alive longer than intended. The practitioner conclusion is simple: vendor governance has to follow the identity lifecycle, not the contract signature.

Fourth-party exposure is the governance gap most programmes still cannot see. A vendor may be approved, but that approval says little about the subcontractors, tools, and service chains operating beneath it. That breaks the assumption that control over the first supplier equals control over the access path. The implication is that third-party programmes need a view of delegated access depth, not just vendor count.

Privileged external access creates identity blast radius. When vendors receive broad permissions, any compromise of those credentials affects far more than the original account. The article’s cost and breach data point to a simple pattern: access scope, not just access presence, determines how far an incident travels. Practitioners should think in terms of blast radius per vendor identity, not just vendor risk scores.

Named-user accountability is the missing control in many vendor ecosystems. Broad or shared external access makes it difficult to prove who used what, when, and for which task. That weakens both incident response and audit defensibility because responsibility gets blurred across organisations. The practitioner conclusion is that external access must be attributable at the user level, or governance becomes performative rather than operational.

From our research library:

• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to the Ultimate Guide to NHIs.
• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
• Read next: Cloud PAM and CIEM Guide

What this signals

Third-party access governance is converging with NHI lifecycle discipline. Once external users, service accounts, and subcontractors all sit inside the same access chain, the control question becomes whether every identity is named, scoped, and revocable. That is why vendor oversight now needs the same lifecycle rigor usually reserved for non-human identities.

Identity blast radius is the concept teams should use to prioritise remediation. The practical issue is not whether a vendor exists but how much privilege that external identity can accumulate before a compromise spreads. 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to the Ultimate Guide to NHIs. That figure matters here because external identities often fail in the same way: too much scope, too little containment.

Programmes that stop at supplier questionnaires will keep missing the real exposure. The article’s deeper message is that access governance must extend into downstream relationships, time limits, and named accountability. For practitioners, that means treating third-party and fourth-party access as an ongoing entitlement problem, not a one-time risk review.

For practitioners

• Build a full third- and fourth-party access inventory Map every external vendor, subcontractor, and unmanaged tool that can reach internal systems or data. Include owners, account types, access paths, and business purpose so the inventory can support review and offboarding.
• Tighten privileged vendor entitlements Replace broad network access with least privilege access, named user authentication, and time-bound credentials for all external identities that reach sensitive systems.
• Separate vendor onboarding from access governance Treat approval, provisioning, and ongoing review as distinct controls. Revalidate external access whenever the vendor relationship changes, the task changes, or the downstream chain expands.
• Extend oversight to downstream suppliers Require vendors to disclose subcontractors and supporting tools that inherit access, then include those relationships in access reviews and contractual security checks.
• Reduce manual investigation overhead Use centralized access governance to replace spreadsheet-driven tracking and ad hoc approvals, especially where teams are spending large amounts of time reconciling external privilege risk.

Key takeaways

• Third- and fourth-party risk becomes dangerous when organisations cannot see or control the full access chain beyond the first vendor.
• The article links third-party breaches to both excessive privileged access and meaningful financial impact, which makes access scope a board-level issue.
• Practitioners need inventory, named accountability, and short-lived external access to reduce the blast radius of supplier compromise.

Key terms

• Third-Party Access: Third-party access is access granted to vendors, contractors, or support partners who are not direct employees of the organisation. It is higher risk than internal access because accountability, device assurance, and access duration are harder to control, so it usually requires tighter time limits and stronger auditability.
• 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.
• Broken User Authentication: Broken user authentication occurs when attackers can compromise or bypass the controls that prove a user’s identity. In API environments, weak authentication lets an attacker take over sessions, impersonate legitimate users, steal data, or trigger fraudulent actions through trusted application flows.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.