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

At a glance

What this is: This is an Imprivata analysis of third- and fourth-party risk, showing that vendor privilege, weak inventory, and limited monitoring are driving breach exposure.

Why it matters: It matters because IAM, PAM, and NHI teams now have to govern not just direct vendors but downstream access paths, where visibility and revocation failures become breach multipliers.

By the numbers:

• Nearly half (47%) of organizations experienced a breach involving a third party in the past year.
• 34% were due to vendors having too much privileged access, with each related breach costing an average of $88,000.
• Organizations now manage access for an average of 20 vendors, yet only 50% maintain a comprehensive inventory of those vendors.
• 59% of organizations do not monitor third-party access at all.

👉 Read Imprivata's analysis of third- and fourth-party breach risk

Context

Third-party access risk is the governance problem that appears when outside organisations, subcontractors, and unmanaged tools are given entry into internal systems without the same lifecycle control applied to employee access. In this article, third-party access risk is the primary issue, and it is already showing up as breach cost, not just compliance noise.

The gap widens when fourth parties are added to the picture. A vendor may be assessed, but its subcontractors and connected tools often inherit access paths that are harder to inventory, monitor, and revoke, which turns vendor management into a broader identity governance problem across the supply chain.

Key questions

Q: What breaks when vendors have privileged access that is broader than their task?

A: Broad vendor privilege turns a supplier relationship into a high-impact intrusion path. If the account is compromised, the attacker can move beyond a single application or dataset and reach systems that were never intended for that vendor. The real failure is not just excess access, but the absence of blast-radius control, attribution, and rapid revocation.

Q: Why do fourth-party relationships make third-party risk harder to manage?

A: Fourth-party relationships hide the identities that actually touch your environment. You may know the primary vendor, but not the subcontractor, managed service, or tool operating underneath it. That gap weakens monitoring, approval, and offboarding because the organisation cannot fully see or govern the downstream access chain.

Q: How do security teams know whether vendor access is truly under control?

A: They should be able to answer four questions quickly: who has access, why they have it, when it expires, and who can revoke it. If any of those answers depend on spreadsheets, email chains, or ad hoc approvals, the access model is not under control. A complete inventory and named ownership are the baseline signals.

Q: Who is accountable when a vendor or subcontractor causes a breach?

A: Accountability sits with the organisation that granted or failed to govern the access, even if the compromise occurred through a vendor or fourth party. Contracts matter, but operational control matters more. Security leaders need clear ownership for approval, monitoring, and revocation so that third-party access is managed as an internal control domain.

Technical breakdown

Why third-party privileged access becomes a breach amplifier

Third-party access becomes dangerous when vendors receive broad, persistent, or shared privileges that exceed the specific task they need to perform. Once privileged access exists, attackers do not need to compromise your core IAM stack if they can reach the environment through a less governed external account. The operational weakness is usually not the vendor relationship itself, but the mismatch between access scope, monitoring depth, and revocation discipline. That is why privileged access in third-party paths behaves like a blast-radius multiplier rather than a simple perimeter exception.

Practical implication: map every vendor entitlement to a named business purpose, an owner, and a revocation trigger.

Fourth-party risk and the hidden access chain

Fourth-party risk arises when a vendor’s vendor, subcontractor, or connected service inherits access to data, systems, or credentials indirectly. This creates a blind spot because the organisation often has contractual awareness of the first vendor, but no operational visibility into the downstream identity chain. In practice, the access path may include VPNs, shared admin portals, API credentials, or delegated support accounts that were never inventoried as separate identities. The result is an accountability gap: the organisation can name the supplier, but not always the identity actually touching its environment.

Practical implication: extend inventory, approval, and offboarding controls to downstream entities that can reach production.

Time-bound credentials, named users, and zero trust for vendors

The article’s recommended shift from broad VPN access to fine-grained controls is important because vendor access should be treated as a temporary, scoped entitlement rather than a standing trust relationship. Time-bound credentials reduce exposure duration, named user authentication improves traceability, and least privilege limits the damage if a vendor account is abused. This is especially relevant where external access spans healthcare, manufacturing, and financial services, because the same control failure can affect very different regulated environments. Zero trust here is not a slogan; it is the operational discipline of verifying every vendor session and narrowing what it can do.

Practical implication: replace shared or persistent vendor access with time-limited, individually attributable access tied to a specific task.

Threat narrative

Attacker objective: The attacker aims to use trusted external access to reach internal systems, steal data, or expand compromise through a supplier chain.

1. Entry occurs through a trusted third-party or fourth-party access path, often because the external identity has broader network or privileged access than the task requires.
2. Escalation happens when the attacker abuses that privileged vendor access to move from a supplier foothold into internal systems, credentials, or sensitive data.
3. Impact follows when the organisation cannot quickly see, scope, or revoke the downstream access chain, increasing breach cost and response time.

Breaches seen in the wild

• LiteLLM PyPI package breach — LiteLLM PyPI supply chain attack, credentials stolen from users.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Third-party access governance fails when organisations treat vendor trust as a one-time decision. The article shows that many teams vet vendors but do not maintain continuous control over the identities those vendors use. That is not a procurement issue alone; it is a lifecycle problem spanning approval, monitoring, and offboarding across external identities. Practitioners should treat third-party access as an identity programme, not a contract appendix.

Fourth-party risk is the hidden extension of NHI governance into the supply chain. Once subcontractors and unmanaged tools can reach production, the organisation is no longer governing a single vendor identity but a delegated access chain. That chain often includes service accounts, support credentials, and API-based entry points that are difficult to inventory after the fact. The implication is clear: identity governance must follow the access path, not the vendor label.

Vendor privileged access is a blast-radius problem, not just an exposure problem. The article’s emphasis on overly broad access aligns with a familiar failure mode in NHI governance: standing privilege survives longer than the business need. In vendor ecosystems, that standing privilege is harder to detect because ownership is split across teams and companies. Practitioners should reframe third-party PAM as a control over how far compromise can travel, not simply whether a vendor was approved.

Named-user and time-bound access are the minimum viable controls for external identity traceability. Shared access and persistent sessions make it impossible to attribute actions, enforce review, or revoke cleanly when relationships change. The article’s Zero Trust direction is therefore less about architecture branding and more about account-level accountability. Security teams should use this to reset expectations for how vendor access is granted, observed, and retired.

Central inventory is the control that separates known supplier exposure from unmanaged shadow access. Imprivata’s finding that only half of organisations maintain a comprehensive inventory shows that visibility is still uneven even before fourth parties are considered. Without a current inventory, offboarding, review, and exception handling all operate on incomplete data. Practitioners should view inventory quality as the prerequisite control for any third-party governance model.

From our research:

• 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, according to The 2025 State of NHIs and Secrets in Cybersecurity.
• 91% of former employee tokens remain active after offboarding, leaving organisations vulnerable to potential security breaches.
• Track lifecycle controls with NHI Lifecycle Management Guide when offboarding, rotation, and revocation need to happen at the same pace as supplier change.

What this signals

Third-party governance is now a lifecycle problem, not a vendor checklist problem. As supply chains deepen, the question becomes whether external identities are reviewed, bounded, and revoked with the same discipline as internal accounts. Organisations that cannot answer that will struggle to contain the next supplier-linked incident. The most useful next step is to align external access governance with the NHI Lifecycle Management Guide and the OWASP Non-Human Identity Top 10.

Identity inventory quality is the leading indicator of supplier risk maturity. If half of organisations still lack a comprehensive vendor inventory, downstream access will remain partially invisible and partially unowned. That creates a structural delay between a supplier relationship changing and the access actually disappearing, which is exactly when attackers benefit. Teams should measure inventory completeness, access attribution, and revocation success together, not separately.

Vendor privilege should be measured by blast radius, not by relationship status. A trusted partner can still become a high-risk identity if its access is broad, persistent, or shared. The practical test is whether the organisation can shorten access duration, reduce scope, and prove removal without relying on manual follow-up. If not, the external identity model is still too permissive.

For practitioners

• Build a complete third-party and fourth-party access inventory Record every external vendor, subcontractor, support tool, and delegated service that can reach production or sensitive data. Tie each entry to an owner, access purpose, and last review date so offboarding and recertification can happen without guesswork.
• Replace broad vendor access with task-scoped entitlements Move external users off shared VPN-style access and onto named, time-bound credentials with least privilege permissions. Require each entitlement to expire automatically when the task, ticket, or maintenance window ends.
• Separate vendor approval from downstream identity approval Do not assume that approving a primary vendor covers subcontractors or connected tools. Require a second control point for fourth-party access, including explicit approval, logging, and revocation authority for any downstream identity.
• Audit privileged vendor accounts for standing access Review whether external privileged accounts remain active between engagements, whether they are shared, and whether activity is attributable to one named individual. Remove any standing access that cannot be tied to a current business need.
• Test revocation against actual supplier exit scenarios Run offboarding drills that start with vendor termination, contract change, or tool decommissioning and verify that access disappears across primary and downstream identities. Treat failed revocation as a control defect, not an administrative delay.

Key takeaways

• Third-party breaches are increasingly an identity governance problem because vendor access is often broader and less visible than internal access.
• The article’s numbers show that the gap is not theoretical: third-party breaches, privileged access abuse, and weak inventory all remain common.
• The control priority is clear, which is complete inventory, named ownership, time-bound access, and revocation that reaches fourth-party dependencies.

Key terms

• Third-Party Access: Access granted to an external vendor or partner to perform a business task inside an organisation’s systems. In identity terms, it is a governed entitlement that should have a clear owner, scope, expiry, and revocation path, just like any other privileged account.
• Fourth-Party Risk: Risk created when a vendor’s vendor, subcontractor, or connected tool can reach your environment indirectly. The challenge is not only contractual visibility but identity visibility, because the downstream actor may be the one executing actions, storing data, or exposing credentials.
• Privileged Vendor Access: Elevated access given to an external party so it can administer, support, or integrate with internal systems. This access is high risk because it can bypass normal user boundaries, expand blast radius, and make incident attribution and fast revocation much harder.
• Access Inventory: A current record of who or what can reach systems, data, and administrative functions, including third parties and their downstream dependencies. Without it, organisations cannot reliably review, offboard, or prove control over external identities and their privileges.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Imprivata: Third- and Fourth-Party Blind Spots Linked to $88K Average Breach Cost. Read the original.