Supply Chain Attacks: Rethinking Third-Party Trust

Your next cyber incident probably won’t start with you.

The odds are it will start with a vendor you trust, a platform you barely notice, or an open-source maintainer you’ve never heard of.

On paper, most companies will say they “manage third-party risk”. In practice, they manage contracts, questionnaires, and certificates. The real exposure lives in the architecture: who has access to what, which SaaS systems sit on critical paths, where fourth- and fifth-party dependencies hide in the background.

This article looks at supply chain attacks and third-party risk from that angle. 

What actually counts as a “supply chain attack” (vs. a third-party breach)

Third-party incident vs. true supply chain attack

It helps to draw a very simple line.

A third-party breach is when your supplier is compromised. For example, your payroll provider gets hit with ransomware or your logistics partner suffers a data leak. It’s painful, but the damage is mostly between them and you.

A supply chain attack goes one step further. Attackers use that compromised supplier as a bridge to reach many other organisations downstream, including your own customers. Think of a poisoned software update, a hacked identity provider, or a widely used file-transfer tool that becomes an entry point into hundreds of networks at once.

In other words, every supply chain attack involves third parties, but not every third-party incident escalates into a supply chain attack. The difference is scale and leverage.

Four archetypes all leaders should be able to recognize

Most real incidents fall into a few clear patterns:

1. Compromised software updates

Attackers break into a vendor’s build or update system and insert malicious code into legitimate updates. When customers apply the update, they unknowingly install the attacker’s backdoor. Incidents like SolarWinds or 3CX are classic examples.

2. Zero-day in a shared platform

A critical vulnerability in a widely used tool. For example, a managed file-transfer system like MOVEit lets attackers break in before a patch exists. Anyone who runs that platform is suddenly at risk, whether they know it’s in their stack or not.

3. Open-source maintainer compromise

An attacker quietly takes over an open-source project or contributor account and slips malicious changes into a library that thousands of products depend on. The XZ Utils case showed how far this can go, deep in the infrastructure layer.

4. Central identity or access provider compromise

If an identity provider or SSO platform is breached, attackers can pivot into many customer environments by abusing trusted access paths. Okta-related incidents have highlighted how powerful this route can be.

European enterprises rely on the same cloud platforms, IAM providers, file-transfer tools, and open-source components. The patterns are global, which is exactly why leaders need a clear, shared definition of what they’re defending against.

The new third-party risk surface: cloud, SaaS, open source, OT, and AI

via GIPHY

SaaS, cloud, and shared platforms as single points of failure

Most organisations now run on the same stack of shared services. These include cloud platforms, ERP and SCM systems, identity providers, file-transfer tools, and collaboration suites.

Each of these connects many suppliers and customers at once. That makes them incredibly efficient and incredibly fragile. If one of these platforms is compromised, attackers don’t just reach one company. They get a shortcut to everyone who depends on it.

Leaders need to understand that those shared platforms are a systemic risk. A single failure can disrupt procurement, production, logistics, invoicing, and customer delivery at the same time.

Open-source and CI/CD pipelines as invisible attack paths

Modern software is built like Lego. Your own applications contain hundreds of open-source components you did not write and do not directly control. Those components are pulled into your systems automatically through CI/CD pipelines.

When an attacker compromises a popular open-source project or a build pipeline, the impact can spread quietly and very fast. A tainted library can end up in thousands of applications before anyone notices. From the outside, nothing looks different. The updates are signed, automated, and approved by existing processes.

This is why concepts like a software bill of materials (SBOM) and secure software development practices matter. 

Operational technology and physical supply chains

Supply chain attacks increasingly touch operational technology (OT). These are the systems that run factories, warehouses, pipelines, and transport networks.

In many organisations, OT environments are managed by external integrators and vendors, often with remote access. If those partners are compromised, attackers can move from IT systems into the physical world: halting production, freezing warehouse operations, or disrupting energy flows.

For executives, this is a major business continuity issue. You are no longer talking about lost records or regulatory fines only, but about downtime, missed orders, and long-term damage to customer trust.

Early signs of AI supply chain risk

The AI systems companies are now deploying (from recommendation engines to copilots and forecasting models), also sit on top of a supply chain. They rely on third-party models, training data, and external APIs.

If those upstream elements are corrupted, you can end up with models that are biased, unreliable, or actively manipulated. In more advanced scenarios, attackers may try to “poison” training data so that models behave incorrectly in very specific situations.

Today, this is still an emerging risk. But the lesson from software supply chains is clear: once AI is woven into critical processes, you inherit the vulnerabilities of every model, dataset, and provider behind it. The time to design controls and governance for that AI supply chain is now, while it is still manageable.

Why traditional TPRM is failing in the age of supply chain attacks

In Europe, boards are now formally responsible for third-party and supply chain cyber risk under NIS2 and DORA. 

The instinct has been to double down on questionnaires and policy binders as proof of control. NIS2 explicitly turns supply chain and third-party risk into a board-level responsibility. This is why we have created this free NIS2 self-assessment tool so our partners and clients can be smart about making changes.

Yet SecurityScorecard’s 2025 Supply Chain Cybersecurity Trends report shows that 56% of organisations still lean on vendor self-assessment questionnaires as a main control. Ironically, they are point-in-time and filled in by the vendors themselves.

Recorded Future’s analysis of third-party risk data tells a similar story: 44% of organisations assess more than 100 third parties each year, but only 4% say they are highly confident in the accuracy of those assessments. 

This is an “illusion of security,” and it’s why companies are vulnerable in the first place. Leaders feel covered on paper while remaining blind to critical vulnerabilities in practice. 

The blind spots multiply as you move beyond direct vendors. SecurityScorecard reports that more than 70% of organisations experienced at least one materially impactful third-party cyber incident in the last 12 months, yet fewer than half monitor even 50% of their “third-party” supply chains – the suppliers of their suppliers. 

In Europe’s financial system, this concentration risk is now formally recognised; under DORA, EU supervisors have created an oversight regime for “critical” ICT third-party providers. Most European institutions still lack an equally sharp view of concentration risk across the rest of their SaaS, payments, logistic,s and data-sharing providers.

What regulators now expect on supply chain and third-party risk

via GIPHY

NIS2 – supply chain security as a legal obligation

Under NIS2, the supply chain and third-party are explicitly part of your legal obligations. 

The directive requires Member States to adopt national cybersecurity strategies that include policies for supply chain security. It expects essential and important entities to address “security-related aspects with direct suppliers or service providers” in their risk management measures. 

In our own NIS2 pieces at Net Group (What is NIS2 & How to comply with NIS2), we’ve already highlighted this shift. Compliance is not just about your internal controls but about how you evaluate and govern cloud providers, software vendors, managed services, and AI partners. 

DORA – ICT third-party risk in European financial services

DORA does for financial services what NIS2 does at the horizontal EU level, but with sharper teeth on ICT outsourcing. 

Financial entities must maintain a detailed register of all ICT third-party service providers and outsourced ICT processes. The regulation also introduces an EU-wide oversight framework for “critical ICT third-party providers” to tackle concentration risk across the sector, not just at the level of individual banks or insurers. 

For European boards, the message is simple: you are expected to know who runs your critical digital services, how dependent you are on them, and what happens if they fail.. 

That is exactly the mindset we encourage in our NIS2 guidance for mixed-sector groups that fall under both NIS2 and DORA. 

Cyber Resilience Act – product manufacturers and software supply chains

The Cyber Resilience Act (CRA) pushes supply chain security one step upstream. It introduces requirements for hardware and software products with digital elements placed on the EU market. The focus is on security by design, vulnerability management, and timely security updates across the entire product lifecycle. 

That includes not just user-facing applications. It includes embedded firmware, integrated components and the open-source libraries manufacturers depend on. 

For European manufacturers, SaaS providers, and OT vendors, CRA effectively says: you are responsible for the security posture of the components you ship, not just your own proprietary code. 

That aligns with the way we talk about “crown jewels” and critical systems in our other cybersecurity content. If your product is part of somebody else’s critical infrastructure, your supply chain is now part of their regulatory story as well. 

Why “compliance-only” still fails against real attackers

Across NIS2, DORA, and CRA, the EU has made one thing clear. Boards and leadership teams are now visibly accountable for cyber and supply chain risk. 

But one thing is very obvious. Cyber risk is evolving faster than static controls. 

Companies are spending more than ever on compliance, yet attacks keep rising because the “attack surface” (especially through partners and platforms) changes constantly. 

That’s why, in our NIS2 articles, we position regulation as a starting point for better architecture and governance. But it’s not the finish line. 

Checklists, certificates, and policies are great. They give you a common language with regulators. 

But they don’t replace the hard work of mapping your digital ecosystem, understanding real dependencies, and designing it so that one supplier’s bad day doesn’t become an existential crisis for your organisation.