NIS-2 Supply Chain Security and Third-Party Risk: A Compliance Guide

NIS-2 supply chain security and third-party risk management refer to the set of legal obligations under the NIS-2 Directive (EU) 2022/2555 that require essential and important entities to assess, govern and contractually control the cybersecurity posture of every supplier, managed service provider and software vendor that can affect the security of their networks and information systems. These obligations move supply chain risk from an internal IT concern to a board-level governance requirement with direct regulatory consequences.

What Article 21 Actually Requires from Essential and Important Entities

Article 21 of the NIS-2 Directive (EU) 2022/2555 establishes a non-exhaustive list of minimum cybersecurity risk management measures. Supply chain security sits explicitly within that list at Article 21(2)(d), which requires entities to address “security in supply chain, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers.”

The obligation is not limited to direct contractual counterparties. Recital 85 of the Directive makes clear that entities must consider the overall security quality of products and services, including the software development practices of their suppliers’ own suppliers where relevant. This extends to managed service providers (MSPs), managed security service providers (MSSPs), cloud platform operators and any third party with privileged access to the entity’s systems.

Critically, Article 21(4) places personal accountability on management bodies. Directors and senior executives of essential entities can be held personally liable if inadequate supply chain oversight contributes to a significant incident. This is not a GDPR-style organisational fine only: it is individual accountability designed to drive board engagement.

Commission Implementing Regulation (EU) 2024/2690: The Technical Detail That Matters

Commission Implementing Regulation (EU) 2024/2690 translates the high-level Article 21 principles into specific technical and organisational requirements. For supply chain risk, it mandates a structured supplier assessment methodology that covers at minimum: the supplier’s own cybersecurity policies, their incident response and notification capabilities, their access control and privileged access management practices, and their ability to demonstrate compliance with applicable standards.

The Regulation requires that assessments of MSPs and MSSPs be more rigorous than those applied to ordinary product vendors, because these providers have persistent network access rather than a one-time transactional relationship. Regulation 2024/2690 expects entities to:

• Classify suppliers by criticality and access level before applying a proportionate assessment depth.
• Require MSPs and MSSPs to provide evidence of their own NIS-2 compliance or equivalent certification.
• Conduct assessments at least annually for critical-tier suppliers and upon any material change in the supplier relationship.
• Retain assessment records in a form that can be produced to national competent authorities within a defined response window.

ENISA’s Technical Implementation Guidance published in June 2025 further recommends aligning assessment questionnaires with CEN/TS 18026:2024, the European technical specification for ICT supply chain security management, which provides a structured control catalogue directly cross-referenced to NIS-2 requirements.

Contractual and Technical Controls: What the Contract Must Contain

Regulation 2024/2690 is explicit that contractual provisions are a compliance requirement, not just good practice. Contracts with suppliers that have privileged or significant access must include clauses covering: mandatory incident notification to the entity within defined timeframes, the right of the entity (or its appointed auditor) to conduct security assessments of the supplier, minimum security baseline requirements aligned with the entity’s own NIS-2 obligations, and data handling and sub-processing restrictions.

When the Supplier Is a Non-EU Hyperscaler

The contractual picture changes materially when the supplier is a US-headquartered hyperscaler such as Microsoft, Amazon Web Services or Google. These providers are subject to the US CLOUD Act (2018) and FISA Section 702, which permit US government authorities to compel disclosure of data held or controlled by US persons regardless of where the data is physically stored. No contractual clause between the entity and the hyperscaler can override a US statutory obligation.

Under NIS-2, an essential entity that relies on such a provider must document the jurisdictional exposure in its risk register and either implement compensating technical controls (encryption with keys managed under sovereign control, for example using hardware security modules outside the provider’s key management infrastructure) or migrate critical workloads to a provider not subject to conflicting extraterritorial laws. ENISA’s June 2025 Guidance notes that contractual sovereignty clauses offered by hyperscalers do not constitute an adequate substitute for actual jurisdictional independence.

The Cyber Resilience Act Layer: Software Components and Open-Source Libraries

The Cyber Resilience Act (CRA), published as Regulation (EU) 2024/2847, introduces a parallel layer of supply chain security that intersects directly with NIS-2 for any entity that relies on software products with digital elements. The CRA requires manufacturers of such products to maintain a software bill of materials (SBOM), apply security-by-design principles and issue security updates throughout the product’s supported lifecycle.

For essential entities operating sovereign infrastructure built on open-source components such as Nextcloud, Nextcloud-integrated Mistral or Llama deployments, or other community-maintained software, the CRA creates a specific obligation. Open-source software distributed in a commercial context, or integrated into a commercial product or service, falls within CRA scope. Entities must verify that the open-source components they deploy either come from a commercially supported distribution that assumes CRA responsibility, or are maintained under a stewardship model that provides timely security updates and CVE remediation.

ENISA’s June 2025 Technical Implementation Guidance recommends that essential entities maintain an SBOM for all critical systems and review it quarterly against publicly disclosed vulnerability databases. This directly supports NIS-2 Article 21 compliance by making the software supply chain visible and auditable.

Building Audit-Ready Evidence for National Competent Authorities

National competent authorities in EU member states have supervisory powers under NIS-2 Article 32 and 33 that include the right to request documented evidence of supply chain security management at any time, not only after an incident. Effective audit preparation requires a structured evidence architecture.

Juhan Lepassaar, Executive Director of ENISA, stated in the June 2025 Technical Implementation Guidance that “supply chain security is not a procurement checkbox. It is an ongoing risk management discipline that must be embedded in the governance structures of every essential entity.” This framing is reflected in what authorities will look for: not a one-time assessment exercise, but a repeatable, documented process with clear ownership assigned through the European Cybersecurity Skills Framework (ECSF) role definitions.

The Proposed January 2026 Amendments: What Changes and What Does Not

The European Commission has proposed targeted amendments to NIS-2 expected to take effect in January 2026. The primary objective is proportionality for smaller entities and those classified as important rather than essential. The amendments are expected to clarify entity classification thresholds, which may result in some organisations moving from essential to important status and thereby benefiting from a lighter supervisory regime.

For entities that remain classified as essential, the substantive supply chain security obligations under Article 21 and Regulation 2024/2690 are not reduced. The amendments do not alter the contractual requirements, the assessment frequency for critical-tier suppliers, or the personal liability provisions for management bodies. What compliance officers and CISOs should watch is whether their entity’s classification changes, since a shift from essential to important affects the intensity of ex-ante supervision but not the underlying security obligations that a mature programme should already be meeting.

ENISA’s Technical Implementation Guidance of June 2025 anticipated the amendments and confirmed that the supply chain security guidance it contains applies to the post-amendment framework without material change for essential entities. Organisations that invest now in a Regulation 2024/2690-aligned programme are building to a standard that will remain valid regardless of the classification outcome.

FAQ: NIS-2 Supply Chain Security in Practice

Does NIS-2 Article 21 require a formal written contract with every ICT supplier?
Article 21(2)(d) requires essential and important entities to address security in supply chain relationships, and Commission Implementing Regulation (EU) 2024/2690 makes clear that this must be backed by documented contractual provisions covering incident notification, access controls, audit rights and security baseline requirements. Informal or purely verbal arrangements do not satisfy the obligation.

Does using a US hyperscaler such as AWS or Microsoft Azure automatically create a NIS-2 compliance problem?
Not automatically, but it creates a specific risk category that must be addressed. The CLOUD Act and FISA Section 702 give US authorities potential access to data held by US-controlled providers regardless of where the data is physically stored. Under NIS-2, an essential entity must document this jurisdictional exposure in its risk assessment and implement compensating controls, or migrate to a provider not subject to conflicting foreign-jurisdiction laws.

How does the Cyber Resilience Act affect open-source libraries used in sovereign infrastructure?
The CRA applies to products with digital elements placed on the EU market. Open-source software supplied in a commercial context, or integrated into a commercial product, falls within scope. Essential entities relying on open-source components must verify that those components either carry a CE mark where required or are maintained under a stewardship model that issues security updates. ENISA’s June 2025 Technical Implementation Guidance recommends maintaining an SBOM for all critical systems.

What does audit-ready evidence for supplier security management look like in practice?
National competent authorities expect a documented supplier inventory with risk classification, completed third-party risk assessments using a consistent methodology aligned with CEN/TS 18026:2024, signed contracts containing the security clauses required by Regulation 2024/2690, evidence of periodic review (at least annually for critical suppliers), and records of any supplier-related incidents and the remediation taken.

Will the proposed January 2026 amendments reduce supply chain obligations for essential entities?
No. The proposed amendments primarily target proportionality for smaller or lower-risk important entities. For essential entities, the supply chain security obligations under Article 21 and Regulation 2024/2690 remain unchanged. The amendments may affect entity classification thresholds, but do not soften the substantive requirements for organisations that remain in the essential category.