Supply Chain Attacks: How to Protect Yourself from Compromised Suppliers

TL;DR

Supply chain attacks compromise trusted suppliers, software, or components, completely bypassing traditional perimeter security.
The three main types are software supply chain attacks (manipulated updates), hardware attacks (compromised devices), and service provider attacks (hacked providers with access to the network).
NIS2 explicitly requires supply chain security in Article 21, including risk assessment of direct suppliers and critical dependencies.
A structured supplier assessment with risk categorization, contractual security requirements, and regular reviews is the most important protective measure.
Technical measures such as Software Bill of Materials (SBOM), dependency scanning, network segmentation, and zero-trust principles significantly reduce the attack surface.

The Attack Nobody Saw Coming

In December 2020, it became known that attackers had compromised the update infrastructure of IT management vendor SolarWinds over a period of months. A manipulated software update for the Orion platform was distributed to approximately 18,000 customers, including US federal agencies, Fortune 500 companies, and numerous technology corporations. The attackers had not targeted these organizations directly. They had taken a detour through a trusted supplier, bypassing all firewalls, endpoint protection solutions, and access controls in one stroke.

This incident was not an isolated case — it marked a turning point. Supply chain attacks have become the preferred method by which sophisticated attackers penetrate organizations that would be difficult to attack directly. The reason is simple: why launch a frontal assault on a well-secured fortress when you can walk in through the supplier entrance?

For mid-market companies, the topic is doubly relevant. On one hand, you are a potential target yourself if your suppliers are compromised. On the other hand, NIS2 has explicitly required since December 2025 that you assess and manage the security of your supply chain. Both require a structured approach — and that is exactly what this article provides.

What Exactly Is a Supply Chain Attack?

In a supply chain attack, an attacker does not compromise the actual target organization directly but rather an upstream supplier, service provider, or software component that the target organization trusts. The attack exploits existing trust relationships and legitimate access paths to bypass security measures.

The insidious part: the malware or access comes through a channel the organization consciously trusts. A software update is installed because the vendor is considered reputable. A service provider gets VPN access because they need it for maintenance. An open-source library is integrated because thousands of other projects use it as well. It is precisely this trust that becomes the attack vector.

The distinction from other forms of attack is clear: in a classic phishing attack, an employee is manipulated. In an exploit, a technical vulnerability is exploited. In a supply chain attack, a trust relationship between organizations is abused. This makes detection so difficult and the impact so far-reaching — because when a supplier is compromised, potentially all of their customers are affected.

The Three Attack Types in Detail

Supply chain attacks can be divided into three main categories, each requiring its own protective measures.

Software Supply Chain Attacks

In this variant, a vendor's software is manipulated before it reaches the customer. This can happen in various ways: by compromising the build system, injecting malicious code into the source code, manipulating update servers, or taking over developer accounts in open-source projects.

SolarWinds (2020) is the textbook example. The attackers had access to the build system and were able to inject malicious code into the regular build process. The signed, legitimate update contained a backdoor that remained undetected for months. Through this backdoor, the attackers were able to selectively penetrate the networks of particularly interesting customers.

Log4j (2021) represents a different variant: a widely used open-source library contained a critical vulnerability (CVE-2021-44228) that was trivially exploitable. Since Log4j was embedded in hundreds of thousands of Java applications, a global crisis ensued. Many organizations didn't even know they were using Log4j because the library was buried deep within other dependencies.

Further variants include the takeover of npm, PyPI, or Maven packages by attackers, so-called typosquatting (packages with names similar to popular libraries), and the compromise of code-signing certificates. What all variants have in common is that the malware is distributed through trusted channels.

Hardware Supply Chain Attacks

Hardware attacks target physical devices and components. A device is manipulated during manufacturing, shipping, or maintenance. This can range from pre-installed backdoors on network devices to manipulated firmware to additionally soldered chips.

This form of attack is harder to carry out but also harder to detect. If a router's firmware is already compromised at delivery, the best network segmentation is of little use. Devices from manufacturers whose production chain cannot be transparently traced pose an elevated risk.

For SMEs, this scenario is less acute than software attacks but should be considered when procuring network infrastructure, servers, and IoT devices. Selecting trustworthy manufacturers with a transparent supply chain and verifying firmware integrity are the key protective measures here.

Service Provider Attacks

In this variant, a service provider with access to the target organization's infrastructure is compromised. IT service providers, managed service providers (MSPs), cloud providers, and external administrators are typical targets.

Kaseya (2021) demonstrated this attack type impressively. The attackers compromised the remote management software Kaseya VSA, which was used by numerous MSPs worldwide. Through the MSPs, ransomware was then distributed to their end customers. A single compromised access point led to ransomware infections at an estimated 1,500 organizations worldwide.

This attack type is particularly relevant for SMEs. Many SMEs outsource IT operations, maintenance, and monitoring to external service providers who often have extensive access to systems and data. If this service provider is compromised, the attacker has open access to the network — through a completely legitimate access path that appears in no firewall rule as suspicious.

Why Supply Chain Attacks Are So Effective

The effectiveness of supply chain attacks is based on several factors that distinguish them from other forms of attack.

Trust relationships bypass security controls. Software updates are installed because the vendor is trusted. Service provider connections pass through firewalls because they are explicitly allowed. Open-source libraries are integrated because the community reviews them. Attackers exploit exactly this systematic trust.

Leverage and scalability. A single compromised supplier can affect thousands of customers simultaneously. This makes supply chain attacks extremely efficient for attackers. Instead of attacking 1,000 organizations individually, you compromise one common supplier.

Difficult detection. Since the malicious code comes through legitimate channels, classic detection mechanisms don't trigger. A signed software update is waved through by endpoint protection. A VPN connection from a known service provider doesn't trigger an alarm. The average detection time for supply chain attacks, according to various studies, was several months.

Complex liability landscape. Who is responsible when a software vendor's update contains malware? Clarifying liability and responsibility in supply chain incidents is significantly more complex than in direct attacks. This also complicates incident response.

NIS2 and Supply Chain Security

The European NIS2 directive has included supply chain security as a dedicated focus area. Article 21, Paragraph 2, Letter d explicitly requires "security of the supply chain, including security-related aspects of the relationships between each entity and its direct suppliers or service providers."

Concretely, this means: if your organization falls under NIS2, you must be able to demonstrate that you assess and manage the cybersecurity risks of your supply chain. This is not an optional best practice but a regulatory obligation.

What NIS2 Specifically Requires

Risk assessment of suppliers. You must assess the cybersecurity risks of your direct suppliers and service providers. This includes both IT service providers and suppliers of software and hardware components used in your infrastructure.

Contractual security requirements. Relationships with suppliers must include contractual provisions for information security. This includes security requirements, incident reporting obligations, audit rights, and minimum standards for handling your data.

Consideration of the overall supply chain. NIS2 requires that you not only consider your direct suppliers but also account for critical dependencies in the deeper supply chain. If your IT service provider in turn relies on a cloud provider, that is relevant to your risk assessment.

Regular review. The assessment of supply chain security is not a one-time action but must be regularly updated. Changes at suppliers, new threats, and incidents in the supply chain require a reassessment.

Practical Implementation of NIS2 Requirements

For most mid-market companies, implementing these requirements means three essential steps: first, an inventory of all suppliers with access to systems, data, or infrastructure. Second, a risk categorization of these suppliers by criticality and access level. Third, the implementation of assessment and monitoring processes appropriate to the risk category.

The good news: you don't have to assess every supplier with equal intensity. A risk-based tiering is explicitly intended and also sensible. The office supplies vendor doesn't need a comprehensive security assessment. The IT service provider with administrator access to your systems, however, does.

Protective Measures: The Supplier Assessment

The supplier assessment is the centerpiece of supply chain security. It enables you to systematically identify, assess, and treat risks. A practical supplier assessment involves several steps.

Step 1: Create a Supplier Inventory

Before you can assess, you need to know which suppliers are relevant in the first place. Create a complete list of all suppliers that fall into one of the following categories:

Software vendors: All vendors whose software runs in your infrastructure, from the ERP suite to the monitoring tool.
IT service providers: All external service providers with access to your systems, whether remote or on-site.
Cloud services: All cloud services you use, including SaaS applications, IaaS platforms, and PaaS services.
Hardware suppliers: Vendors of network components, servers, endpoints, and IoT devices.
Data processors: All service providers that process personal or business-critical data on your behalf.

Don't forget the indirect dependencies. If your ERP system is hosted in a specific provider's cloud, that cloud provider is part of your supply chain even if you have no direct contract with them.

Step 2: Risk Categorization

Not every supplier poses the same risk. Categorize your suppliers into at least three tiers:

Critical (Tier A): Suppliers with direct access to production systems, access to confidential data, or whose failure would immediately endanger business operations. Typical examples: IT systems house with admin access, ERP vendor, cloud provider for business-critical applications.

Elevated (Tier B): Suppliers with limited access, access to non-critical data, or whose failure would impair operations but not bring them to a standstill. Examples: email marketing tools, HR software, specialized applications.

Standard (Tier C): Suppliers without access to systems or data and without immediate impact on IT security. Examples: office supplies vendor, cleaning company (provided they have no access to IT rooms), printing service.

Step 3: Conduct the Assessment

The depth of assessment depends on the risk category.

For Tier A suppliers, a comprehensive assessment process is recommended: security questionnaire (oriented toward ISO 27001 Annex A or BSI baseline protection), review of existing certifications (ISO 27001, SOC 2, TISAX), examination of audit reports and penetration test results, assessment of incident response capabilities, and contractual anchoring of security requirements and audit rights.

For Tier B suppliers, a simplified questionnaire, review of the data processing agreement, and an assessment of basic security measures (encryption, access management, backup) are usually sufficient.

For Tier C suppliers, reviewing the contractual framework and event-driven review is generally adequate.

Step 4: Contractual Safeguards

The results of the supplier assessment must be reflected in contracts. Key contract clauses for Tier A suppliers include:

Commitment to defined security standards
Obligation to promptly report security incidents that could affect your organization
Right to security audits or access to audit reports
Data deletion provisions upon contract termination
Subcontractor clauses ensuring that sub-service providers also maintain adequate security standards
Liability provisions for security-related contract breaches

Step 5: Continuous Monitoring

A supplier assessment is a snapshot. The security posture can change at any time. Therefore, implement a continuous monitoring process:

Annual reassessment of all Tier A suppliers
Every two years for Tier B suppliers
Event-driven review when security incidents, acquisitions, or significant changes at the supplier become known
Monitoring of public sources (security advisories, CVE databases, industry news) for critical suppliers

Technical Protective Measures

Beyond the organizational supplier assessment, a range of technical measures can reduce the risk of supply chain attacks.

Software Bill of Materials (SBOM)

An SBOM is a complete list of all software components contained in an application, including all libraries and their dependencies. When a new vulnerability like Log4j emerges, an SBOM enables immediate identification of all affected systems. Without an SBOM, a time-consuming search begins that can take days or weeks.

Require SBOMs from your critical software suppliers and maintain your own SBOM for internally developed applications. Tools like Syft, CycloneDX, or SPDX support automated creation.

Dependency Scanning and Vulnerability Management

Automated dependency scanning of software dependencies identifies known vulnerabilities in the libraries used. Tools like Dependabot, Snyk, or OWASP Dependency-Check regularly check whether deployed components have known vulnerabilities.

For SMEs that buy software rather than develop it themselves, this means: ensure that your software suppliers have implemented such processes. Actively ask how the vendor handles vulnerabilities in their dependencies and how quickly patches are provided.

Network Segmentation

Even if a supplier is compromised, this doesn't have to mean access to the entire network. Through consistent network segmentation, you limit the damage of a supply chain attack to the area the supplier has access to.

Specifically, this means: VPN connections for service providers should only be able to access the systems required for their task. Maintenance connections should be time-limited and logged. And administrative connections from external service providers should run through jump servers or Privileged Access Management (PAM) solutions.

Zero Trust Principles

The zero trust model assumes that no actor is automatically trusted — not even internal systems or trusted suppliers. Every access is verified, every action is logged, and permissions are granted according to the principle of least privilege.

For supply chain security, zero trust means: supplier connections are controlled just as strictly as external access. Software updates are not blindly trusted but tested in staging environments. And all network traffic to and from supplier systems is monitored.

Monitoring and Anomaly Detection

Implement monitoring for all access and activities related to suppliers. Watch for unusual patterns: access outside normal working hours, data outflows of unusual volume, access to systems outside the supplier's scope of work.

A central Security Information and Event Management (SIEM) system, or at least structured logging of all security-relevant events, is the prerequisite. Set up alerting rules that automatically trigger on suspicious activities from supplier accounts.

The Incident Response Plan for Supply Chain Incidents

Your incident response plan should explicitly include scenarios for supply chain attacks. These differ from classic incidents in several ways.

Detection: Supply chain incidents are often not discovered by your own monitoring systems but through external reports, vendor warnings, or industry information. Ensure that such external information sources are considered in your detection process. Subscribe to security advisories from your critical suppliers and follow relevant threat intelligence feeds.

Assessment: In a supply chain incident, you need to quickly assess whether and to what extent your organization is affected. For this, you need current information about which software in which version is deployed where and which suppliers have access to which systems.

Containment: Containment can be more difficult in supply chain attacks because you may not be able to immediately replace the compromised component. Plan for the case that you need to block a critical supplier connection or isolate software. What impact does this have on business operations? Are there alternative solutions?

Communication: If you are yourself a supplier to other organizations, you must also notify your customers in the event of an incident. NIS2 explicitly requires this. Prepare communication templates and define clear reporting paths.

Practical Example: Supply Chain Security in an SME

A mid-sized manufacturing company with 200 employees built its supply chain security as follows:

In the first step, a supplier inventory was created. The result: 8 Tier A suppliers (IT systems house, ERP vendor, cloud provider, two software vendors for production control, an external IT security consultant, the hosting provider, and the backup solution vendor), 15 Tier B suppliers, and approximately 40 Tier C suppliers.

For the Tier A suppliers, a detailed security questionnaire with 60 questions was created, updated annually. Three of the eight suppliers were already ISO 27001 certified, which simplified the assessment. For the remaining five, the assessment identified areas for improvement: missing encryption of backup data at one vendor, inadequate patch management at another, and missing incident reporting processes at a third.

All Tier A contracts were supplemented with IT security clauses: mandatory incident reporting within 24 hours, annual audit rights, defined minimum standards for access management and encryption.

Technically, the IT systems house's VPN access was restricted to the actually required systems, and privileged access management was introduced. All access is logged and reviewed weekly. ERP system software updates are first tested in a test environment before being rolled out to production.

The entire setup process took approximately three months. Ongoing maintenance requires about two person-days per month, with an ISMS tool like ISMS Lite significantly simplifying supplier assessment through templates, automatic scoring, and reminders for reassessments. This is a manageable effort that pays off many times over in an emergency.

Common Mistakes in Supply Chain Security

When implementing supply chain security measures, we regularly observe the same mistakes.

Only considering direct suppliers. If your IT service provider delegates their tasks to a sub-service provider, that sub-service provider is part of your supply chain. Actively ask whether and to what extent sub-service providers are used, and ensure that adequate security standards apply to them as well.

Misunderstanding certification as a guarantee. An ISO 27001 certification means that a management system is in place and has been audited. It does not guarantee that no security incidents will occur. Use certifications as one component of your assessment, but not as the sole criterion.

One-time assessment instead of continuous process. Your suppliers' security posture can change at any time. An assessment conducted two years ago says little about the current situation. Establish a regular review cycle.

Focusing on questionnaires instead of evidence. A completed questionnaire shows what the supplier claims. Evidence such as certifications, audit reports, penetration test results, and technical proof shows what is actually implemented. Always request evidence from critical suppliers.

Forgetting contractual safeguards. The best assessment is of little use if the results are not contractually secured. Without a contractual agreement, you have no leverage if a supplier fails to implement promised security measures.

Supply Chain Security as Part of the ISMS

Supply chain security is not an isolated topic but an integral part of your information security management system. ISO 27001 addresses the topic in several Annex A controls:

A.5.19 Information security in supplier relationships
A.5.20 Addressing information security within supplier agreements
A.5.21 Managing information security in the ICT supply chain
A.5.22 Monitoring, review, and change management of supplier services
A.5.23 Information security for use of cloud services

Integration into your ISMS means: supplier risks flow into your risk assessment. Security requirements for suppliers are defined in your policies. Supplier assessments are documented and reported in the management review. And incidents in the supply chain are handled in your incident management process.

If you have built your ISMS properly, you add supply chain security as another building block without having to reinvent everything. The risk management framework, documentation structure, and review processes already exist. You simply extend them to include the supplier dimension.

Summary of Key Measures

For getting started with supply chain security, we recommend the following priorities:

Create a supplier inventory and capture all suppliers with access to systems, data, or infrastructure.
Conduct risk categorization and tier suppliers by criticality.
Assess Tier A suppliers with security questionnaires, certification review, and evidence.
Adapt contracts and anchor security requirements, reporting obligations, and audit rights.
Implement technical measures: network segmentation, access restrictions, monitoring of supplier activities.
Extend the incident response plan with supply chain scenarios.
Establish regular reviews and anchor supplier assessment as a continuous process in the ISMS.

Supply chain attacks will not decrease. Increasing interconnection and dependence on external services continuously expand the attack surface. But with a structured approach that combines organizational and technical measures, you can significantly reduce the risk while simultaneously meeting the regulatory requirements of NIS2.