Third-party vendor risk is now a core cybersecurity control gap

At a glance

What this is: This is an analysis of why third-party vendor risk has become a core cybersecurity control gap, with the key finding that breach exposure now extends well beyond the enterprise perimeter.

Why it matters: It matters because IAM and security teams have to govern external access, application patching, and vendor oversight as part of the same control plane, not as separate operational chores.

By the numbers:

• Nearly 30% of data breaches in 2025 were tied to third-party suppliers, according to JumpCloud citing Verizon.

Context

Third-party vendor risk is the exposure created when external applications, suppliers, or service providers become part of the attack surface. In practical terms, the security boundary extends into the vendor ecosystem, so compromise can arrive through an integrated service rather than a direct breach of internal systems.

The article argues that treating vendor management as a procurement or IT hygiene task leaves a control gap. For identity and access teams, that gap matters because third-party access, application patching, and ongoing assurance all influence whether external dependencies can be trusted in production.

The core message is not that all vendors are unsafe, but that reliance on them must be governed continuously. That is a familiar pattern across third-party access, SaaS governance, and workload-linked trust, and the article treats that as a mainstream cybersecurity requirement rather than a niche concern.

Key questions

Q: How should security teams govern vendor access across the third-party lifecycle?

A: Security teams should govern vendor access as a lifecycle, not a one-time approval. That means inventorying each third party, recording what it can access, setting review cadence based on exposure, and revoking every credential or integration at offboarding. The goal is to keep business need, access scope, and accountability aligned throughout the relationship.

Q: Why do supplier breaches often become IAM problems inside the customer environment?

A: Because the customer usually inherits the access relationship even when it does not control the supplier’s security posture. Once a trusted connection is in place, the attacker can operate through legitimate identity paths, so the internal failure is often poor entitlement scope, weak review evidence, or missing offboarding.

Q: What breaks when third-party patching is not centrally visible?

A: When patching is not centrally visible, security teams lose the ability to tell which external applications are exposed to known vulnerabilities. That creates unmanaged drift across endpoints and services, which weakens incident prevention and makes reporting unreliable. In practice, hidden version state becomes hidden risk, especially when vendors ship updates asynchronously.

Q: Should organisations prioritise vendor due diligence or ongoing monitoring?

A: They need both, but ongoing monitoring usually matters more after onboarding because risk changes over time. Due diligence screens the initial decision, while monitoring checks whether the vendor still meets the organisation’s trust threshold. If a programme stops at procurement, it misses patch drift, service changes, and new exposure paths.

Technical breakdown

Why third-party ecosystems become breach paths

A third-party ecosystem becomes part of the attack surface when an organisation depends on external software, hosted services, or partners for day-to-day operations. Attackers often prefer the weaker upstream target because compromise there can cascade into multiple downstream customers. The control problem is not only access permission, but trust propagation: once a vendor is integrated, its security posture can influence your own exposure even if your internal perimeter is well managed. This is why vendor oversight cannot be treated as a one-time questionnaire exercise.

Practical implication: model each critical vendor as a dependency with security impact, not just a contract with service levels.

Why patch visibility matters for third-party applications

Application patching is a vulnerability-lifecycle control, not just a device-maintenance task. Third-party Mac and Windows apps can drift out of compliance when update policy is inconsistent, end-user installation is unmanaged, or visibility into version state is missing. That creates an exposure window in which known issues remain exploitable even though the software is already in production. Centralised patch visibility matters because security teams cannot govern what they cannot inventory, version, or verify.

Practical implication: maintain current version state for all externally sourced applications and tie patch status to security reporting.

How vendor patching and due diligence fit together

Due diligence and patch governance solve different parts of the same problem. Due diligence asks whether a vendor is acceptable before onboarding, while patch governance asks whether that vendor and its software remain acceptable after deployment. The article’s point is that security assurance decays over time if ongoing maintenance is not monitored. In identity terms, this is the same lifecycle logic that applies to access reviews: approval at entry does not equal trust forever.

Practical implication: connect onboarding review, continuous monitoring, and update enforcement into one vendor governance workflow.

Threat narrative

Attacker objective: The attacker aims to use a weaker vendor dependency as a faster route to customer data and operational disruption.

1. Entry occurs through a trusted third-party application or vendor dependency rather than a direct attack on the enterprise perimeter.
2. Escalation happens when the vendor’s weakness becomes an effective bridge into customer environments or exposed data paths.
3. Impact follows as compromised vendor relationships can spread disruption across customers, data sets, and operational services.

Breaches seen in the wild

• Salesloft OAuth token breach: hackers stole OAuth tokens to access Salesforce data via Salesloft.
• 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.

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 risk is now an identity governance problem, not just a supplier management problem. Once external applications participate in business operations, they become part of the trust model that IAM and security teams are accountable for. The practical implication is that vendor oversight, access control, and operational assurance must be governed together.

Vendor patch latency becomes security latency: a partner that cannot be verified, updated, or monitored continuously turns every downstream customer into an exposure target. This is why onboarding assessments are necessary but insufficient. The field needs continuous assurance over the software and access paths that third parties create.

Interconnected services multiply blast radius faster than perimeter thinking can contain it. The article reflects a wider reality: dependency on SaaS and external applications means that one weak supplier can create repeated customer-side risk. Practitioners should treat concentration in third-party trust as a structural risk factor, not an isolated incident class.

Third-party patching is a governance control, not an IT convenience feature. If an organisation cannot see update state across externally sourced applications, it cannot defend the environment those applications sit inside. The conclusion is straightforward: vendor risk management belongs in security governance, because trust without lifecycle control is incomplete.

Identity blast radius: external access and external software both extend the range of damage when trust is misplaced. This concept matters because the same dependency that improves productivity can also widen the consequence set when a vendor is breached or left unpatched. Practitioners should use the blast radius lens to prioritise which vendors demand the strongest control coverage.

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: Third-Party, B2B and Contractor Access Guide

What this signals

Third-party dependencies should now be treated as governed security assets, not passive procurement choices. When an external service can affect customer data or operational continuity, the control problem becomes one of lifecycle assurance, access oversight, and update enforcement.

Identity blast radius: third-party trust expands the consequence set of a single compromise, which means security teams need to prioritise vendors by downstream impact rather than by contract value alone.

The practical shift is to connect vendor review, patch visibility, and access governance into one operating model. A supplier that cannot be monitored continuously should not be allowed to remain a blind trust assumption in the production environment.

For practitioners

• Map third-party dependencies to security-critical services Identify which suppliers, SaaS platforms, and externally managed applications can affect data, identity, or operational continuity. Rank them by business criticality and by the blast radius if they fail or are compromised.
• Tie onboarding to continuous vendor assurance Move beyond pre-purchase checks and establish recurring review of vendor security posture, patch practices, and service changes. Reassess vendors whenever their product scope, integrations, or support model changes.
• Inventory and patch third-party applications centrally Maintain a current view of installed third-party Mac and Windows applications, version state, and update policy enforcement. Use central patch visibility to reduce the window in which known vulnerabilities remain exposed.
• Separate access approval from trust renewal Do not assume that a vendor approved at onboarding remains acceptable indefinitely. Build a renewal cadence for access, integrations, and software trust so stale assumptions do not persist after the initial review.
• Prioritise vendors with downstream customer impact Focus governance effort on suppliers whose compromise or outage could disrupt customer data, employee productivity, or core workflows. These dependencies deserve the strictest review, reporting, and escalation thresholds.

Key takeaways

• Third-party vendor exposure is a governance problem because external services can become breach paths into customer data and business operations.
• JumpCloud cites Verizon data showing nearly 30% of data breaches in 2025 involved third-party suppliers, which underlines how common the risk has become.
• Security teams need continuous vendor assurance, central patch visibility, and recurring trust review instead of one-time onboarding checks.

Key terms

• Third-Party Vendor Risk: Third-party vendor risk is the exposure created when an external supplier has access to an organisation’s data, systems, or processes. The risk increases when the vendor handles sensitive records, uses broad privileges, or lacks strong monitoring, because a compromise can affect multiple customers at once.
• Patch Visibility: The ability to see which software versions are installed across endpoints and environments. Without visibility, patch enforcement is guesswork, because teams cannot tell where vulnerable or unsupported applications remain in use.
• Trust Boundary: A trust boundary is the point where one system’s authority should stop and another system’s authority should begin. For internal automation, weak trust boundaries let monitoring, remediation, and execution share privileges that should have remained separate.
• Blast Radius: The potential scope of damage if a specific credential or identity is compromised. Identities with broad permissions have a larger blast radius and represent a higher priority for least-privilege enforcement and security controls.

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.