ICT supply chain: which suppliers could actually stop your information system?

An organization may have dozens of technology suppliers without knowing which ones actually represent a single point of failure for its information system.

A contractual inventory answers a simple question: who do we work with?

A cyber supply-chain analysis must answer a harder one:

if this supplier disappears, is compromised or becomes unusable tomorrow, which services actually stop working?

In February 2026, the NIS Cooperation Group, together with the European Commission and ENISA, published the EU ICT Supply Chain Security Toolbox. It proposes a common approach to identifying, assessing and reducing cybersecurity risks in ICT supply chains, including critical supplier assessment, multi-vendor strategies and the reduction of high-risk supplier dependencies.1

The shift is important: the objective is no longer only to know your suppliers, but to know the dependencies that connect them to the real operation of the information system.

An important supplier is not necessarily a critical supplier

A company may spend millions per year with a provider without its disappearance immediately stopping a critical activity.

Conversely, a relatively inexpensive service can represent a major dependency.

Examples include a DNS provider used by all internet-facing applications, a common IAM platform, a certificate service used by every API, a CDN in front of several critical platforms, a virtualization technology shared across datacenters, or a software component embedded in many products.

Supplier criticality therefore cannot be inferred from contract value, license count or supplier size alone.

It depends primarily on the supplier's position in the information-system architecture.

The right unit of analysis is the dependency chain

A useful operational representation can be:

business process → service → application → technical component → supplier → supplier dependency → alternative.

This chain helps answer several questions: which business process depends on the supplier? which technical components rely on it? is the dependency direct or indirect? is there an alternative? how long would a switch take? does the alternative itself rely on the same technology or subcontractor?

Two different suppliers do not necessarily mean two independent supply chains.

Multi-vendor can create a false sense of resilience

The European toolbox highlights multi-vendor strategies as one way to reduce dependency.1

But a multi-vendor architecture is resilient only if the underlying chains are sufficiently independent.

Imagine three applications: one hosted with cloud provider A, one with cloud provider B and one in an internal datacenter.

On paper, the organization has three different architectures.

Yet all three may use the same IAM provider, the same DNS service, the same CDN and the same backup technology.

The visible hosting diversity then hides common concentration points.

Supply-chain mapping therefore needs to look beyond the primary provider.

Constructed case: five applications, three clouds, one point of failure

Consider a company with five critical applications. Two run on one public cloud, one on a second cloud and two on-premises.

The architecture appears diversified.

A deeper analysis reveals that all five use the same identity provider for user authentication, administrator accounts, federation and access to technical consoles.

A major outage does not necessarily stop the servers. The applications may remain technically available, but users can no longer authenticate.

The business impact can therefore be almost equivalent to a full outage.

The decisive dependency was not the cloud. It was identity.

Separate supplier, technology and service

One supplier can appear in an architecture in many forms.

A hyperscaler may provide infrastructure, storage, IAM, databases, serverless functions, observability and AI services.

The relation application → supplier is therefore too simplistic.

A more useful representation is application → technology service → supplier.

It distinguishes an easily replaceable dependency from a deeply embedded one.

An application using a standard virtual machine may sometimes be migrated relatively easily. An application using many tightly integrated proprietary managed services may require months of redesign.

The supplier is the same. The dependency is not.

Substitutability should become an architecture attribute

The toolbox also focuses on reducing dependencies on high-risk suppliers.1

This naturally leads to an attribute that is still rarely documented in IT inventories: substitutability.

For each significant dependency, useful data includes whether an alternative exists, migration lead time, technical complexity, data portability, internal skills and shared dependencies.

A dependency with no realistic alternative deserves more attention than one that can be replaced quickly.

Indirect dependencies are often the hardest to see

Organizations usually know their direct suppliers much better than those suppliers' own dependencies.

A SaaS provider may itself rely on a hyperscaler, CDN, IAM platform, DNS infrastructure, payment provider or specific technology stack.

The customer does not necessarily control this chain, but can identify the elements that materially affect exposure.

EU Council conclusions on ICT supply-chain security already highlighted strategic dependencies and the need to consider the cybersecurity practices of suppliers and subcontractors.2

The practical question becomes: how far should the chain be mapped?

A useful answer is: as far as an additional dependency can change the risk assessment.

Mapping everything is unrealistic

Large organizations can have thousands of suppliers, applications and components.

Trying to document every chain immediately is likely counterproductive.

A progressive approach can start with the most critical business services, the applications that support them, major technology dependencies, associated suppliers, common concentration points and dependencies with low substitutability.

The objective is not a perfect representation of the ecosystem.

It is to identify concentrations capable of producing systemic impact.

Supply-chain risk is also becoming geopolitical

In January 2026, the European Commission proposed a revision of the Cybersecurity Act aimed in part at strengthening ICT supply-chain security and reducing certain risks associated with third-country suppliers.3

Supplier risk is therefore no longer limited to availability, technical cybersecurity or financial strength.

It may also include jurisdiction, ownership, technology dependence, the ability of a third party to interrupt a service, exposure to trade restrictions and strategic dependencies.

Technical mapping then becomes a much broader decision-support tool.

A simple exercise to test supply-chain visibility

Choose five services considered critical.

For each one, reconstruct: business service → application → critical technologies → suppliers → shared dependencies → alternatives.

Then ask: is one supplier present in several chains? is there a hidden common technology behind several suppliers? is there a dependency without a realistic alternative? do we know how long replacement would take?

If answering requires days of investigation, the main problem is probably not the absence of another supplier questionnaire.

It is the absence of a consolidated view of the information system's technology dependencies.

That is precisely the visibility ICT supply-chain security now requires.