Supply chain attacks in 2026: the supplier you never chose

Nearly half of all breaches now involve a third party. The figure is 48%, from Verizon’s 2026 Data Breach Investigations Report published on 19 May 2026, and third-party involvement is up 60% year on year. It is almost always read as a verdict on vendor management — proof that companies are not vetting their suppliers hard enough.

Read the year’s actual incidents and a different picture appears. Two of 2026’s three routes sit largely beyond what a vendor questionnaire can settle: code nobody chose, and IT providers holding administrative access by design. Almost every supply-chain control an SMB owns is built for the supplier that fails, and that is only one of the three places 2026 came from.

The 48% is not a vendor-management number

A third-party breach is not the same thing as a supplier failure. The 48% counts relationships, and most organisations have far more of them than they have contracts. A mid-sized company in France or Belgium might run 40 vendors on its purchase ledger and several thousand software components in production, with no overlap between the two lists and nobody responsible for reconciling them.

Europe is not an observer here. Black Kite’s 2026 European Cyber Risk Report, published on 25 June 2026, analysed 2,066 ransomware incidents across 31 countries between January 2025 and April 2026. Publicly disclosed incidents rose 55.1% in the first four months of 2026 against the same months of 2025, from 441 to 684; the monthly rate went from 108 in the first half of 2025 to 171 in early 2026. Germany recorded the most, then the UK, France, Italy and Spain, together accounting for nearly 70% of the total. Manufacturing took 27.9% of disclosed incidents. The most targeted subindustry was IT services, and 64 organisations in the dataset were compromised through a third-party incident rather than directly.

That last pair of findings is the story in miniature. The subindustry attackers targeted most is the one that holds everyone else’s credentials.

Three routes in, and only one your contracts anticipated

Three routes into an SMB in 2026 — and only one of them is the risk your contracts anticipated.

The code you did not write. Open-source packages reach production through dependencies of dependencies. Your developer chose four libraries; the install pulled in nine hundred. None of the nine hundred was procured, assessed or signed.

The provider holding your keys. Managed IT providers, remote-monitoring tools and outsourced helpdesks hold administrative access to the estate by design. A compromise there is not an attack on a supplier — it is an attack delivered as your own IT.

The supplier holding your operations. The logistics platform, the payroll bureau, the scheduling system. This is the only route your contracts were written for, and the only one that behaves like the risk they anticipate.

Our Virtual CISO service spends more of its first quarter reconciling these three lists than on any other single task, because in most organisations they have never been in the same room.

What ChainDrop did in the minutes that mattered

In August 2026, a self-propagating worm known as ChainDrop — a successor to the Shai-Hulud campaign — compromised more than 400 npm packages that are collectively downloaded hundreds of millions of times a week. It ran automatically on install, harvested npm and GitHub tokens, cloud credentials, SSH keys and secrets from continuous-integration runners, then used those tokens to republish the maintainer’s other packages with itself inside.

The speed is the part a board should hear. Palo Alto Unit 42 found 453 exfiltration repositories across five accounts, the earliest created on 11 May 2026, and observed a newly poisoned version of a package landing six minutes after the one before it.

No questionnaire in the world asks the question that would have caught this. It is not about whether your supplier has multi-factor authentication. It is about whether a package your contractor installed on a Tuesday afternoon reached your build server before anyone had a name for it.

The limb of NIS2 everyone quotes, and the one that actually applies

This is where the regulation is more interesting than its summaries.

NIS2 Article 21(2)(d) requires supply chain security, and the relationships it names are those between each entity and its “direct suppliers or service providers”. Article 21(3) tells entities to take into account the vulnerabilities specific to each direct supplier and service provider, and the overall quality of the products and cybersecurity practices of their suppliers and service providers, including their secure development procedures. It is a duty to consider, not a duty to guarantee, and it is framed around direct suppliers. Deeper tiers are something the directive says entities “could consider” (recital 85): permission, not obligation.

So the limb of NIS2 that everybody cites in vendor discussions does not oblige you to look at a transitive dependency several levels down. The limb that does cover it is Article 21(2)(e): security in the “acquisition, development and maintenance” of network and information systems, including vulnerability handling and disclosure. We have not yet seen that filed under supply chain in a compliance matrix. In practice it is where your build pipeline lives.

Two further points of law are worth knowing. Since 11 September 2026 the Cyber Resilience Act has obliged manufacturers of products with digital elements to report actively exploited vulnerabilities — which means some of your software vendors now owe you a warning they did not owe last year. And as of 7 October 2026 France has still not transposed NIS2; the obligations described here bind through each member state’s transposition law, and the French bill, withdrawn from the National Assembly’s plenary agenda on 6 October with no new date set, has not yet been adopted.

The first-tier half of this problem is a solved problem, and we wrote the tool for it: the questionnaire you should be sending covers the suppliers you chose. This article is about the other half.

Four things to do in the next 30 days

The four questions to answer in the next 30 days. None of them requires buying anything.

1. Produce one list of what actually runs. Not the vendor ledger — the software bill of materials for anything you build or deploy, and the inventory of anything installed by an outside party.
2. Name everyone holding privileged access from outside. Providers, contractors, integrations with standing tokens. For each one, write down who inside your organisation approved it.
3. Decide who you would call. For each of the three routes, one named person, reachable out of hours. This is the answer that is missing most often.
4. Rehearse severing one connection. Not a tabletop discussion — an actual test of revoking one provider’s access and one build credential, timed. If nobody knows how long it takes, that is the finding.

None of this requires a platform purchase. It requires somebody to own the question, which is a governance problem before it is a technical one — and the same problem our NIS2 readiness work starts from.