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

At a glance

What this is: This is a vendor-published analysis of third-party breach risk and application patching, with the key finding that supplier exposure now accounts for a large share of breaches and must be governed as a cybersecurity issue.

Why it matters: It matters because IAM, NHI, and security teams must treat external dependencies, patch visibility, and access governance as part of the same control surface, not separate programmes.

By the numbers:

• 30% of data breaches in 2025 were tied, re tied to third-party suppliers.
• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job.

👉 Read JumpCloud's analysis of third-party vendor risk and app patching

Context

Third-party risk is the security gap that appears when an organisation depends on outside applications, suppliers, and services it does not fully control. The more those dependencies expand, the more a weakness in one partner can become a direct path into the organisation’s own environment.

For IAM and security leaders, this is not just a procurement or patching issue. Vendor access, application maintenance, and trust relationships now sit inside the same governance problem, because attackers increasingly work through the supply chain instead of straight through the perimeter.

Key questions

Q: How should security teams manage third-party vendor risk across external applications?

A: Security teams should treat third-party vendor risk as a living control process, not a one-time approval. That means maintaining a current inventory of suppliers, defining access paths into sensitive systems, checking patch posture regularly, and reassessing the relationship whenever the vendor’s control environment changes. The goal is to reduce downstream blast radius before it becomes an incident.

Q: When does third-party application patching become a governance issue?

A: It becomes a governance issue as soon as the organisation cannot prove which application versions are installed, who owns remediation, and how quickly unsupported software is removed. At that point patching is no longer just maintenance. It is a control over exposure, trust, and operational resilience across the endpoint estate.

Q: What do organisations get wrong about vendor due diligence?

A: Many teams treat due diligence as a gate at onboarding instead of a continuous control. That approach misses the fact that supplier posture changes over time, including patch delays, ownership changes, and new exposure in the vendor’s own environment. A partner that was acceptable six months ago may no longer be safe to trust today.

Q: Who is accountable when a supplier breach affects downstream customers?

A: Accountability is shared, but it is not diffuse. The vendor is accountable for its own security failures, while the customer remains responsible for the trust it extends, the data it exposes, and the controls it enforces around third-party access. Frameworks such as the NIST Cybersecurity Framework 2.0 support that shared-responsibility view.

Technical breakdown

Third-party breach paths and trust expansion

Third-party breaches usually start when an attacker finds weaker controls in a supplier, managed service, or software dependency rather than in the target organisation itself. Once trust is established, the compromise can move through shared data flows, delegated access, or integrated applications. The key issue is not just that a vendor is breached, but that the organisation has extended operational trust into systems it does not manage directly. That makes supplier security a control boundary, not an external concern.

Practical implication: map where partner access, integrations, and shared data create real trust dependencies, then review those paths as part of your access governance model.

Patch visibility and version control across third-party applications

Application patching becomes a governance problem when organisations cannot clearly see which third-party software versions are running across endpoints. Patch visibility is the precondition for version control, because without it security teams cannot tell which apps are out of date, unsupported, or exposed to known vulnerabilities. In practice, distributed Mac and Windows estates often accumulate patch drift faster than teams can track manually, especially when installation is decentralised and updates are inconsistent.

Practical implication: create a single inventory of third-party application versions and connect it to patch policy enforcement so outdated software does not persist unnoticed.

Vendor risk management as a lifecycle control

Vendor risk management is not a one-time onboarding check. It is a lifecycle discipline that includes due diligence before purchase, continuous review of security posture, and timely patching of the applications you rely on. That lifecycle approach matters because a supplier that looked acceptable at onboarding can drift into unacceptable risk later if its patch cadence weakens, its controls change, or its own dependencies become exposed.

Practical implication: treat third-party review as an ongoing control cycle with reassessment triggers, not a procurement checkbox completed once at contract signature.

Threat narrative

Attacker objective: The attacker aims to turn a weaker supplier into a faster route to the target’s data, systems, and business operations.

1. Entry begins with attackers exploiting weakness in a trusted third-party vendor or application instead of breaching the target organisation’s perimeter directly.
2. Escalation follows when the compromise reaches shared data, delegated access, or integrated systems that extend the vendor’s trust into the customer environment.
3. Impact occurs when the breach cascades into data exposure, service disruption, or customer compromise across the downstream organisation and its users.

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 risk is now a control boundary, not a procurement afterthought. The article’s central point is that organisations inherit risk from the suppliers and applications they trust, whether or not those systems sit inside their own perimeter. That is the same structural problem NHI governance faces when identities, tokens, and delegated access outlive the business process that created them. The implication is that trust relationships must be governed as active security assets, not static vendor records.

Patch visibility is the missing precondition for meaningful application control. The vendor’s application patching example is really a governance problem about knowing what exists, what version it is, and whether it is still defensible. Without visibility, patch policy becomes aspirational, because teams cannot prove coverage across dispersed endpoints. Practitioners should treat patch visibility as the control that makes patch enforcement possible.

Vendor access without continuous reassessment is the failure mode this article exposes. The security assumption behind third-party onboarding is that a partner that passed due diligence will remain safe enough to trust. That assumption fails when supplier risk drifts after onboarding, because patching, posture, and exposure can change long before the next review cycle. The implication is that lifecycle governance must follow the relationship after activation, not stop at approval.

Interconnected ecosystems create blast radius that traditional perimeter thinking cannot absorb. The article shows how a single vendor weakness can cascade into customers and downstream systems. That is the same logic behind identity blast radius in NHI programmes: once access is shared, reused, or delegated, compromise propagates faster than teams expect. Practitioners need to design for containment, not just prevention.

Third-party governance and IAM are converging into one operational discipline. Supplier security, application patching, and access control are no longer separable workstreams when external software is embedded in daily operations. The field is moving toward a model where vendor assurance, endpoint software control, and identity governance inform one another. Teams should align these controls under a single risk model rather than manage them in silos.

From our research:

• Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security, according to The 2026 Infrastructure Identity Survey.
• Only 13% of organisations feel extremely prepared for the reality of agentic AI, showing that policy intent is moving faster than governance readiness.
• That gap mirrors third-party risk management, where control ownership matters more than trust in the supplier, so practitioners should pair governance policy with a lifecycle model such as the NHI Lifecycle Management Guide.

What this signals

Third-party application control is moving from procurement hygiene into operational security governance. As external software becomes more embedded in daily work, the teams that own patch visibility, supplier review, and identity access need a shared control model rather than separate checklists.

Identity blast radius: this is the practical way to think about vendor risk when external tools connect to sensitive data and systems. Once trust is extended, downstream impact can spread faster than conventional perimeter controls can contain it, which is why lifecycle review and segmentation now belong in the same programme conversation.

With 70% of organisations granting AI systems more access than they would give a human employee performing the exact same job, according to The 2026 Infrastructure Identity Survey, the broader pattern is clear: organisations are already normalising over-trust in non-human access, and supplier governance will have to catch up.

For practitioners

• Build a live third-party inventory Track every external application, supplier integration, and managed service that can reach sensitive data or systems. Include business owner, access path, patch responsibility, and review cadence so vendor risk can be reassessed continuously, not only at onboarding.
• Enforce patch visibility across Mac and Windows fleets Create a central view of third-party application versions and tie it to policy that flags or remediates unsupported builds. If the organisation cannot see the installed version, it cannot claim control over exposure windows.
• Tie supplier due diligence to operational reassessment Re-run security reviews when a vendor changes ownership, patch posture, access model, or handling of sensitive data. A once-approved supplier should not be treated as permanently low risk if its control environment has changed.
• Map downstream blast radius before expanding trust Before adding a new third-party tool, document what data, identities, and systems it can touch if compromised. Use that mapping to decide whether the access path is acceptable or whether the integration needs stronger segmentation and tighter controls.
• Align vendor governance with incident playbooks Make sure procurement, endpoint management, and incident response teams share the same third-party risk record. That shortens the time to isolate a supplier-related issue and prevents a breach from being treated as a pure endpoint problem.

Key takeaways

• Third-party vendors are now part of the attack surface, so supplier risk must be governed as a security control rather than a procurement checkbox.
• Patch visibility is the operational prerequisite for controlling exposure across distributed application estates.
• The practical response is continuous reassessment of vendors, access paths, and blast radius, not a one-time due diligence review.

Key terms

• Third-Party Risk Management: The process of identifying, assessing, and continuously monitoring the security exposure created by suppliers, partners, and external services. It includes due diligence at onboarding, but it only becomes effective when review, patch posture, and access paths are revisited over time.
• 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.
• Blast Radius: The amount of damage that can spread when one trusted system, supplier, or identity is compromised. In third-party governance, blast radius depends on the reach of integrations, data access, and delegated trust, not just on the initial vulnerability.
• Vendor Reassessment: A repeated security review of an external provider after onboarding. It matters because a vendor's risk profile can change through patch delays, ownership changes, new integrations, or altered access patterns, and those changes can invalidate the original approval.

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 JumpCloud: third-party vendor risk and simplified app patch management. Read the original.