Third-Party & Supply Chain Attack Statistics 2026: The Data Security Teams Need to Know

With 82.4% of UK cyber security professionals reporting a third-party breach in the past year, supply chain attacks remain a critical, systemic threat in 2026. This article breaks down the latest data on supply chain dependencies, analyses recent high-profile incidents, and explains why security teams must transition from static annual questionnaires to active, network-level risk management to combat hidden concentration risks.
Risk Ledger
|
Company
September 1, 2026
10
mins read
Third-Party & Supply Chain Attack Statistics 2026:  The Data Security Teams Need to Know

A third-party or supply chain attack compromises one supplier, contractor or software provider, but could give threat actors access to multiple clients that depend on it. This possibility has made supply chain attacks a prominent attack vector. In 2026, that vector is increasingly being utilised: According to recent research based on a survey over over 500 cyber security professionals across the UK, 82.4% of respondents reported at least one supply chain incident in the past 12 months.

This article sets out the current data on how often these attacks happen, where software and open-source dependencies fit into the picture, why suppliers remain an attractive target for attackers, what recent UK incidents reveal, and what the data implies for how a TPRM programme should actually be run.

Key Third-Party & Supply Chain Breach Statistics

A third-party or supply chain breach is any security incident where a vendor, contractor or service provider is the point of entry rather than the organisation in question itself. In the past year alone, 82.4% of UK security and TPRM professionals reported at least one supply chain incident, while 47.2% reported two or more.

This high number has barely improved from the previous year, when it sat at 85%, according to Risk Ledger's 2025 State of Supply Chain Security report. Two years of high-profile incidents, tightening regulation and growing board attention have not reduced how often these breaches happen.

Accordingly, 86% of respondents still rank supply chain incidents among their top three concerns for 2026, down only slightly from 90% the year before. Globally, the World Economic Forum's Global Cybersecurity Outlook 2026 found that 65% of large organisations now cite third-party and supply chain risk as their primary resilience challenge, up from 54% the year before.

What makes this a structural problem is how large the gap still is between the scale of the problem and the response. The UK Government's Cyber Security Breaches Survey 2025/2026 found that still today just 15% of businesses formally review the cyber risk posed by their immediate suppliers, and only 6% review their wider supply chain. Those figures have also barely shifted from the 2024 survey, despite the intervening incidents at Synnovis, Jaguar Land Rover and Marks & Spencer and many others. Most organisations recognise the risk. Very few have built a process to manage it appropriately.

Richard Horne, CEO of the National Cyber Security Centre, described the current climate at CYBERUK 2026 as a "perfect storm": AI-driven technological change is colliding with sustained geopolitical tension. His assessment was blunt: most nationally significant incidents his team now handles originate directly or indirectly from nation states.

Software Supply Chain & Open-Source Risk Statistics

Software supply chain risk covers threats introduced through third-party code, open-source packages and build pipelines, distinct from risk introduced through other contracted vendor relationships. ENISA's Threat Landscape 2025 found that traditional software supply chain compromise accounted for 10.6% of the 4,875 incidents it analysed between July 2024 and June 2025, making it one of the report's ten leading threat categories.

The open-source dimension of that figure has grown sharply. Sonatype, which maintains the industry's most widely cited count of malicious open-source packages, identified more than 454,600 new malicious packages across npm, PyPI, Maven Central, NuGet and Hugging Face in 2025 alone, a 75% year-on-year increase. That brings the cumulative total of known and blocked malware to over 1.23 million packages. 

ENISA's report also points to a shift in who is doing the targeting. It documents state-linked exploitation of open-source ecosystems, including North Korea's Lazarus Group publishing npm packages that impersonate legitimate libraries to compromise developer machines. Sonatype's own research corroborates this: it attributes more than 800 malicious packages in 2025 to Lazarus-associated activity, concentrated overwhelmingly on npm.

The practical risk for buyers evaluating suppliers’ security postures is that a supplier's own software dependencies now sit inside their risk profile as well, whether or not that supplier writes much code in-house. A vendor that looks well-governed on paper can still ship a product built on compromised or poorly maintained open-source components. Traditional questionnaire-based assessments, built around checking policies and certifications, were not designed to capture this layer of risk, and most TPRM programmes still have no mechanism for asking about it.

Why Attackers Are Targeting Suppliers

A supply chain attack targets one organisation to gain access to many others that depend on it. That one-to-many structure changes the economics of an attack: instead of breaching a single target directly, compromising one shared supplier can open a route into dozens or even hundreds of downstream organisations at once.

This is why shared dependencies matter more than they first appear to. Take a simple example: six organisations in the same sector all rely on the same accounting software provider. None of them can see this by looking only at their own supplier list, because each one only has visibility of its own direct relationship with that provider. But to an attacker, that shared dependency is a single point of entry with six times the payoff. This is what security teams mean by systemic concentration risk, and it is invisible to any one organisation's own TPRM programme. Then there are also concentration risks affecting individual organisations, for example in a scenario where multiple critical third parties of an organisation all rely on the same fourth party provider.

Regulators have started treating this as part of their formal risk management requirements. DORA's Article 29 requires financial entities to assess whether an ICT arrangement creates substitutability risk or excessive dependence on a single provider, and to consider the downstream consequences where subcontracting is involved. 

AI adoption is compounding this risk rather than easing it. Suppliers are increasingly building services on a small number of foundational AI models, which means an organisation's exposure now depends partly on model choices made by suppliers it has limited contractual control over and often no visibility into. The National Cyber Security Centre's own 2026 assessment described AI as rapidly increasing attackers' ability to find and exploit existing vulnerabilities at scale, a dynamic that applies as much to supplier ecosystems as to any single organisation's perimeter.

The operational consequence is that point-in-time assessment struggles against this specific attack pattern. A supplier can pass a well-run annual review and still introduce concentration risk six months later, simply by changing which cloud provider or AI vendor it decides to use. Static assurance was built to check a supplier's own controls. It was not built to track who else that supplier depends on, or how its own external dependencies may be changing over time.

Notable Supply Chain Attacks (real-world examples)

Three incidents from 2024 and 2025 show how a single supplier compromise cascades into disruption for organisations that had no direct role in the breach. 

Synnovis, June 2024. Synnovis provided pathology services to several major London NHS trusts, including Guy's and St Thomas' and King's College Hospital. On 3 June 2024, the Qilin ransomware group encrypted its systems after exploiting a service account that lacked multi-factor authentication. The disruption cancelled over 11,000 outpatient and elective procedure appointments, caused a national shortage of O-negative blood, and contributed to a patient death, according to a UK Parliament written statement from November 2025. Full recovery took months; some NHS trusts were still working with only partially restored systems more than a year later. Synnovis itself was not the target. The NHS trusts that depended on it were.

Marks & Spencer, April 2025. M&S was hit by a ransomware attack attributed to the Scattered Spider group. The attackers did not breach M&S's own systems directly. Instead, they used social engineering against Tata Consultancy Services (TCS), the third-party contractor that ran M&S's IT helpdesk, phishing TCS employees and using their stolen credentials to access M&S's network. M&S chairman Archie Norman confirmed this to MPs as "sophisticated impersonation" through a third party. Online orders, Click & Collect and contactless payments were disrupted for around six weeks, contributing to underlying pre-tax profit falling 55.4% to £184.1 million in the first half of the year.

Collins Aerospace, September 2025. Collins Aerospace supplies the MUSE check-in and boarding software used by multiple airlines across numerous European airports, including London Heathrow. On 19 September 2025, a ransomware attack on Collins' MUSE platform, later confirmed by ENISA, took automated check-in and boarding systems offline at Heathrow, Brussels and Berlin simultaneously. None of the three airports were themselves breached. All three were forced into manual check-in processes for several days, with Brussels cancelling roughly half its scheduled departures at the peak of the disruption. One vendor's compromise reached passengers at three of Europe's busiest airports at once, a direct illustration of concentration risk in practice.

The pattern across all three: the breached organisation was unlikely to have been the intended end target.

What These Trends Mean for Your Supplier Risk Programme

Point-in-time assessment cannot keep pace with dependencies that shift and attacks that move fast. The practical shift for supplier risk programmes is towards evidence that stays current and visibility that extends beyond direct suppliers, not towards more frequent versions of the same annual questionnaire cycle.

The 2026 survey data shows exactly where current programmes fall short. Onboarding is slow: only 38% of organisations complete supplier due diligence within two weeks, while 34.6% take three weeks or more and 12% take over a month. Visibility drops off sharply beyond the first tier: only 30% of respondents have full visibility of the entire subcontractor chain supporting their critical business functions, and 24.8% named this the single biggest shortcoming in their current approach. Readiness under pressure is the starkest gap of all: only 8.8% of organisations can map their exposure across their supplier ecosystem within four hours of a major incident, while 23% need more than a week and manual supplier outreach to get this visibility.

These aren't failures due to lack of effort. They're what happens when assurance is built around annual, bilateral, questionnaire-led review. A process designed to produce a snapshot once a year cannot also serve as a live map of who depends on whom.

Three practical criteria follow from this. First, treat onboarding speed and visibility depth as measurable outcomes, not just process steps, since both are quantifiable and both are currently weak across the industry. Second, think about what triggers a reassessment: a fixed annual date, or an actual change in a supplier's environment, ownership, or fourth-party dependencies. Third, consider whether your programme has direct relationships with the security teams at critical suppliers, not just a completed questionnaire on file; only 43.8% of organisations currently do, which limits how quickly anyone can get a straight answer during an incident.

This is where reusable, current supplier evidence changes the mechanics. Instead of every customer sending its own questionnaire to the same supplier, the supplier maintains one structured profile shared across its client relationships, with each client applying its own policies and risk appetite on top. Reassessment can be triggered by an event or a control change rather than only by a calendar date. And because many organisations in a sector often share the same suppliers, mapping those connections at a network level surfaces concentration risk that no single organisation's own supplier list would show.

Risk Ledger's own platform data illustrates what this means in practice. Across a community of 30 UK financial institutions, connected to 2,780 direct suppliers on a shared network surfaced a further 6,529 nth-party dependencies and 1,322 potential concentration risks, 288 of them rated critical. Of those critical risks, 120 suppliers lacked Cyber Essentials certification, a control gap invisible to any one institution looking only at its own direct relationships. A separate community of 26 UK government organisations found a similar pattern at a smaller scale: 3,240 direct connections surfaced 5,886 further dependencies and 224 critical concentration risks.

Buyers evaluating any network-based platform against this problem should ask a few practical questions before taking coverage claims at face value: how many of our actual suppliers are already active on this vendor's network, rather than needing to be onboarded from scratch; what happens to the timeline and workload when a supplier isn't already connected; how much of that onboarding effort falls on the supplier rather than on our own team; and how current the evidence stays once a supplier is on the network, rather than only at the point of initial connection.

This connected approach to supplier risk, standardised evidence, ongoing updates, and network-level visibility into shared dependencies, is what Risk Ledger calls Active Supply Chain Security.

These figures are just a small sample of what's included in Risk Ledger's Every Link Matters: The State of Supply Chain Security 2026 report, including the full breakdown across government, local authority and financial services communities. You can access the full report here: https://riskledger.com/resources/every-link-matters-2026 

Conclusion

The data points to a clear conclusion. Supply chain incidents remain as frequent in 2026 as they were the year before, while formal supplier review has barely moved: still just 15% for immediate suppliers, 6% for the wider chain. Software and open-source dependencies have added a second, faster-moving layer of risk on top of vendor relationships. None of this means annual questionnaires are worthless. It means they're no longer sufficient on their own. The organisations narrowing this gap are the ones treating supplier evidence as something to keep current rather than refresh once a year, and treating dependencies beyond the first tier as something to map rather than assume away.

What security teams ask next about supply chain attack statistics


FAQ's

FAQ

What counts as a third-party or supply chain breach?
A breach where a vendor, contractor or supplier is the point of entry, rather than the organisation itself. This includes both compromised vendor relationships, such as the Synnovis and Marks & Spencer incidents, and software supply chain risk, where the vulnerability sits in open-source code or a build pipeline a supplier depends on.

Are supply chain attacks increasing in 2026?
Incident rates have stayed persistently high rather than falling: 82.4% of UK organisations reported at least one supply chain incident in the past year, close to 85% the year before. Concern levels remain similarly high, but formal review of supplier risk has not kept pace, with only 15% of UK businesses reviewing immediate supplier risk and 6% reviewing their wider supply chain.

Which industries are most affected by supply chain attacks?
The clearest UK evidence sits in sectors with heavy regulatory reporting requirements and high supplier interdependence: financial services, government, and retail. Risk Ledger's own platform data across a community of 30 UK financial institutions found 288 critical concentration risks from just 2,780 direct supplier connections, and a separate community of 26 UK government organisations found 224. Retail's exposure was demonstrated directly in 2025, when Marks & Spencer, Co-op and Jaguar Land Rover were all disrupted through compromised suppliers or logistics partners within the same few months.

What's the difference between a supplier breach and a software supply chain attack?
A supplier breach compromises a vendor's own systems or people, as in the Synnovis ransomware attack. A software supply chain attack compromises the code a supplier's product depends on, such as a malicious open-source package, and can affect an organisation even where the immediate supplier's own security controls are sound.

Why do attackers target suppliers rather than their intended victim directly?
Because one compromised supplier can provide access to every organisation that depends on it. Where several organisations share a common supplier, that shared dependency becomes concentration risk: a single point of failure invisible to any one organisation looking only at its own direct supplier list.

How can organisations reduce exposure to supply chain attacks?
By moving beyond annual, one-to-one supplier questionnaires towards evidence that's reused across relationships and refreshed by events rather than only a fixed date, and by mapping dependencies beyond direct suppliers to surface shared concentration risk before an incident forces the question.

Blog

Download for free

Pattern Trapezoid Mesh

Get the security manager's briefing

Monthly research, case studies and practical guides you won't find anywhere else.

Join thousands of security managers turning their TPRM programmes into success stories.