Two Regulators, One Supply Chain
The Cyber Resilience Act creates a product-security layer that most NIS2 supply chain programmes weren't built to see.
Every CISO who has spent the past eighteen months building a NIS2 supply chain programme has been working from the same mental model: assess vendors, contractualise obligations, monitor continuously. It is the right model. As NIS2 transposition laws take effect across Member States and supervisory enforcement accelerates through 2026, that model is being tested in practice.
But the mental model has a blind spot. It frames vendor risk as a question about how suppliers operate. It does not ask whether the products those suppliers provide are inherently secure — and that question now has a regulator attached to it.
The Cyber Resilience Act (CRA) is a product security regulation, not an organisational one. Its obligations fall on manufacturers, importers, and distributors of products with digital elements — a category defined broadly to cover hardware and software that includes software components or network connectivity, encompassing enterprise software, connected devices, embedded systems, OT equipment, and consumer IoT. It is not a directive requiring national transposition; it is a directly applicable regulation. And its first enforcement deadline arrives on 11 September 2026, six months from now.
For CISOs managing NIS2 supply chain programmes, this matters in a specific and underappreciated way: your NIS2 vendor assurance work and your vendors' CRA obligations are part of the same risk problem. They just have different regulators.
The Architecture of Two Frameworks
NIS2 and the CRA were designed as complementary instruments, not competing ones. The European Commission's explicit framing is that NIS2 builds operational resilience for the organisations deploying technology, while the CRA builds product resilience for the technology itself. In practice, as one technical analysis puts it, NIS2 ensures secure operations while CRA ensures secure products — together, they close the loop between governance and engineering.[1]
That complementarity creates a structural dependency that most CISOs have not fully mapped. Consider the logic:
Under Article 21(2)(d) of NIS2, essential and important entities must implement supply chain security measures covering their relationships with direct suppliers and service providers. This includes assessing supplier cybersecurity posture and, under some national implementations such as Poland's KSC amendment, formally excluding vendors that represent unacceptable risk.[2]
Under the CRA, the suppliers those entities are assessing now face their own mandatory obligations: to design products securely, manage vulnerabilities across the product lifecycle, provide security updates, and — from September 2026 — to report actively exploited vulnerabilities to ENISA and national CSIRTs within 24 hours.[3]
The dependency becomes a governance gap when the two frameworks are managed separately. An NIS2 supply chain programme that evaluates operational security practices but does not assess CRA readiness is evaluating half the picture. A vendor can have strong SOC processes and weak product security. Under the converging regulatory architecture, both matter.
The CRA Timeline in Practice
December 2024 — CRA enters into force
11 June 2026 — Conformity assessment body framework operational; notified bodies available for product assessments
11 September 2026 — Vulnerability and incident reporting obligations apply to all in-scope manufacturers
11 December 2027 — Full product conformity requirements enforceable; SBOM obligation formally applies
The September 2026 deadline is the immediate operational pressure point. It is six months away.
What the CRA Reporting Deadline Actually Means
The September 2026 deadline is frequently described as the CRA's "early" reporting obligation, as distinct from the full compliance requirements taking effect in December 2027. That framing, while technically accurate, understates the operational readiness it demands.
From 11 September 2026, manufacturers of products with digital elements must notify via the ENISA-managed single reporting platform, which distributes information to the relevant national CSIRTs, of actively exploited vulnerabilities and severe security incidents within 24 hours of becoming aware. A 72-hour detailed follow-up is required, and a final report within 14 days (for exploited vulnerabilities) or one month (for severe incidents).[4]
Critically, this reporting obligation applies to all products currently on the EU market — including those placed there before December 2027. Legacy products are not exempt from the reporting requirements even though they are exempt from the full conformity obligations.[5]
The operational implication of this is frequently missed: to report an actively exploited vulnerability within 24 hours, a manufacturer must already know what components are in the product. That knowledge requires a Software Bill of Materials (SBOM) and automated vulnerability monitoring. As one analysis summarises the hidden dependency: if you do not have a complete SBOM and real-time vulnerability monitoring, you will not even know whether your product is affected before the 24-hour clock expires.[6]
For CISOs, this has a direct supply chain governance implication. The NIS2 question "does this vendor have good security practices?" needs to be supplemented by a CRA-adjacent question: "does this vendor have the product transparency infrastructure to know when their products are compromised and report it within 24 hours?" Those are different questions with different answers.
The Supply Chain Accountability Chain
The CRA does not restrict accountability to the original manufacturer. It establishes what one legal analysis describes as a cascading chain of responsibility throughout the product lifecycle: manufacturers bear primary obligations, while importers and distributors assume secondary duties including verification of compliance and reporting of non-conformities to competent authorities.[7]
This matters for essential entities in a way that is not obvious from the NIS2 framework alone. Under the CRA:
Importers must verify that manufacturers have met CRA obligations before placing products on the EU market. Distributors must verify that the product bears CE marking and that required conformity documentation is present. Any entity in the supply chain that modifies a product in a way that affects its security characteristics takes on manufacturer obligations for the modified product.
The governance implication: an essential entity that procures digital products — servers, endpoint software, network equipment, IoT devices, industrial control systems — is operating in a supply chain that now has legally enforceable product-security accountability at multiple levels. When something goes wrong with a product that has been placed on the EU market without CRA conformity, the question of who failed their obligations runs from the original developer through importers and distributors to the end customer.
One analysis of the converging frameworks captures this clearly: a product that fails CRA requirements can create downstream compliance risk for customers subject to NIS2 or DORA.[8] The supply chain is not just a source of operational risk — it is a source of regulatory exposure.
The SBOM as a Shared Governance Instrument
The Software Bill of Materials has been discussed in cybersecurity governance circles for several years as a supply chain transparency tool. The CRA makes it something more specific: a product conformity instrument with regulatory teeth.
Under Annex I of the CRA, manufacturers are explicitly required to identify and document vulnerabilities and components contained in their products, including by drawing up a software bill of materials in a commonly used, machine-readable format covering at least top-level dependencies. That obligation becomes fully enforceable from December 2027. However, it is a practical prerequisite for the September 2026 reporting deadline: to report an actively exploited vulnerability within 24 hours, a manufacturer must already know what components are in the product. Market surveillance authorities may request the SBOM on a reasoned basis once the full framework applies.[9]
The NIS2 Directive does not explicitly require SBOMs from entities or their suppliers. But the ENISA guidance on NIS2 supply chain security — which functions as an interpretive guide for supervisory authorities during inspections — reinforces the expectation that essential entities can demonstrate software component transparency across their vendor relationships.[10]
In practice, the SBOM is becoming the point where CRA product obligations and NIS2 supply chain assurance converge. A vendor that can produce a current, machine-readable SBOM on request is demonstrating both CRA readiness and the kind of software transparency that NIS2 supply chain governance programmes should be requiring. A vendor that cannot is signalling both a CRA compliance risk and a NIS2 assurance gap.
CISOs designing or upgrading vendor risk programmes should treat SBOM availability as a tier-one assessment criterion for technology suppliers, not a future aspiration.
What Has Not Changed — And What This Means
It is worth being precise about scope. The CRA applies to manufacturers, importers, and distributors of products with digital elements. It does not directly impose obligations on essential entities as operators of those products — at least not under CRA's own provisions. The product-security obligations in September 2026 fall on the vendors, not the buyers.
This can create a false sense of separation. The argument runs: "CRA is a vendor problem; we just need to buy from compliant vendors." That argument has three weaknesses.
First, the September 2026 reporting deadline is live in six months. The SBOM and vulnerability management infrastructure required to meet a 24-hour reporting obligation is not trivial to build. Multiple industry analyses published in 2025 and early 2026 note that many manufacturers are still treating CRA as a 2027 problem — systematically underestimating that the September reporting obligation requires operational readiness now.[6]
Second, NIS2 supply chain obligations require essential entities to assess and manage the cybersecurity posture of their suppliers. CRA non-compliance is a material factor in that assessment. The inability to report an exploited vulnerability within 24 hours is not a hypothetical risk — it is an information asymmetry that leaves the downstream customer operating on outdated incident intelligence.
Third, the January 2026 NIS2 amendments explicitly acknowledged that supply chain questionnaire approaches are inadequate and signalled a shift toward certification-based supply chain assurance. The CRA's CE marking and conformity assessment framework is designed to operate at the product level — and the logical direction of the Commission's regulatory architecture is that these two certification layers will eventually reinforce each other. CISOs who design their vendor risk programmes around CRA readiness now are building toward a more coherent compliance model, not running ahead of it.
What CISOs Should Do Now
The governance response to converging NIS2 and CRA obligations is not complex, but it requires deliberate action rather than deferred attention.
Map the product exposure in your vendor base
Identify which of your critical vendors are manufacturers, importers, or distributors of products with digital elements and therefore subject to CRA obligations. This is not all vendors — it is specifically those whose products involve software, firmware, or network connectivity placed on the EU market. Prioritise vendors of OT systems, endpoint software, network infrastructure, and IoT equipment.
Add CRA readiness to vendor risk assessments
For technology product vendors, current NIS2 supply chain questionnaires assess operational security practices. Add a CRA readiness dimension: does this vendor have SBOM capability? Do they have a coordinated vulnerability disclosure process? Are they prepared to notify ENISA within 24 hours of an actively exploited vulnerability in their products? These are answerable questions — and the answers differentiate mature vendors from those that will struggle in September.
Treat SBOM availability as a procurement criterion
For new technology procurements, require that vendors can produce a machine-readable SBOM for relevant products on request. This is not yet a universal market expectation, but it is the direction of regulatory travel and should be embedded in procurement criteria and contractual terms now rather than retrofitted later.
Brief the board on converging regulatory exposure
NIS2 management accountability provisions mean that supply chain governance failures carry personal liability. The CRA adds a product-security dimension to that liability landscape. Boards that understand only the NIS2 operational compliance obligations are missing part of the risk picture. The message to deliver: your supply chain is now subject to two overlapping regulatory frameworks, with different deadlines and different accountability chains — and managing the intersection is a board-level governance question.
Engage vendors proactively on the September deadline
Essential entities have market influence with their technology suppliers. Using that influence proactively — asking vendors about their CRA readiness before the September deadline, rather than discovering non-compliance after an incident — is both a risk management and a vendor relationship action. Vendors that know their customers are tracking CRA readiness have an additional incentive to prepare.
The Governance Question the Frameworks Are Asking
The emerging European cybersecurity framework is no longer separating operational security from product security. NIS2 governs how organisations operate. The CRA governs the security properties of the technology they depend on.
For CISOs, the practical consequence is direct: vendor risk management can no longer stop at organisational controls. It must extend into product transparency, component visibility, and lifecycle security commitments.
Two regulators, one supply chain, and increasingly one governance problem. The organisations that manage them as a unified challenge will be better positioned for the enforcement environment ahead. The organisations that manage them as parallel compliance projects will discover the intersection the hard way.
References
[1] Avatao — CRA vs NIS2: What's the Difference and Why Both Matter (2025)
[2] nflo.tech — ICT Supply Chain Security: Vendor Audit and NIS2 Compliance (January 2026)
[3] European Commission — CRA Reporting Obligations (accessed March 2026)
[8] SCANOSS — Cyber Resilience Act (CRA) Requirements Explained (March 2026)
[9] TXOne Networks — The Cyber Resilience Act: A Guide for Manufacturers (April 2025)
[10] nflo.tech — ICT Supply Chain Security: Vendor Audit and NIS2 Compliance (January 2026)
[11] Hogan Lovells — EU Cyber Resilience Act: Key 2026 Milestones Toward CRA Compliance