Two Regulations, One Incident: The Supply Chain Governance Gap Between NIS2 and CRA
The CRA reporting obligations begin on 11 September 2026. Your NIS2 programme is about to discover which parts of its supply chain architecture were theoretical
On 11 September 2026, the first enforceable obligations under the EU Cyber Resilience Act take effect. From that date, manufacturers of products with digital elements placed on the EU market must report actively exploited vulnerabilities and severe incidents within 24 hours through a dedicated ENISA-operated Single Reporting Platform.1 This is correctly framed in most coverage as a deadline for product manufacturers.
It is also, less visibly, a CISO deadline — even for organisations that manufacture nothing.
Every in-scope NIS2 entity procures products with digital elements. From industrial control systems in energy infrastructure to connected medical devices in hospitals to network equipment in managed service providers, the supply chain that NIS2 Article 21(2)(d) requires CISOs to govern is about to become the object of a parallel regulatory regime operating on a different timeline, through a different reporting platform, to a potentially different CSIRT. The two frameworks were designed to coexist. The operational interfaces between them were not designed jointly.
This article unpacks where NIS2 and the CRA intersect in a CISO’s supply chain programme, five operational ambiguities that the September deadline will surface, and what to do about them before the first dual-reporting incident occurs.
Two Frameworks, One Supply Chain
The conceptual division is clean enough. NIS2 regulates entities — the organisations that operate critical services. The CRA regulates products — the hardware and software placed on the EU market with digital elements.2 For the European Commission, this is a coherent framework: organisational resilience on one side, product security on the other.
For the CISO, it is the same supply chain viewed from two regulatory angles. A hospital running CRA-regulated medical devices is both an in-scope NIS2 essential entity and a downstream user of CRA manufacturers. An energy utility deploying grid control systems is both an Article 21 obligation holder and a party dependent on Article 13 manufacturer obligations. A financial institution running NIS2-regulated digital infrastructure is simultaneously a supply chain obligor and a beneficiary of its suppliers’ product-level security controls.
The practical reality is that most organisations now face one cybersecurity supply chain with two regulatory overlays. The governance question is not how to comply with each framework separately. It is how to architect a supply chain programme that operates coherently under both.
Where Article 21 Meets Article 14
The intersection points sit in specific articles that CISOs should read together, not separately.
NIS2 Article 21(2)(d) requires essential and important entities to implement cybersecurity risk management measures covering supply chain security, including “security-related aspects concerning the relationships between each entity and its direct suppliers or service providers.” ENISA’s technical implementation guidance, published to support the Commission Implementing Regulation (EU) 2024/2690, expects organisations to maintain a register of in-scope suppliers updated with regular risk management activity, including unscheduled reviews and incident reviews.3
NIS2 Article 21(2)(e) goes further: it requires entities to address “security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure.” This sub-paragraph is the direct operational interface with the CRA. The products that the NIS2 entity acquires are, increasingly, products whose vulnerability handling obligations sit with a CRA-regulated manufacturer.
NIS2 Article 23 establishes the incident reporting timeline for the entity: an early warning within 24 hours of awareness of a significant incident, a detailed notification within 72 hours, and a final report within one month, addressed to the national competent authority or CSIRT.4
CRA Article 14 establishes a parallel but structurally different reporting timeline for the manufacturer. Within 24 hours of becoming aware of an actively exploited vulnerability, the manufacturer submits an early warning notification to its designated CSIRT coordinator and simultaneously to ENISA through the Single Reporting Platform. A full vulnerability notification follows within 72 hours, and a final report within 14 days of a corrective measure being made available. For severe incidents affecting product security, the final report is due within one month.5
CRA Article 16 establishes the Single Reporting Platform itself, which ENISA will operate from 11 September 2026. The CSIRT initially receiving the notification then disseminates it to CSIRTs in other Member States where the product has been made available.6
These regimes were intended to operate in parallel. They were not designed to report to the same point, on the same schedule, about the same incident. That is where the governance gap lives.
Five Operational Ambiguities
1. Dual-channel reporting when one incident straddles both regimes.
Consider a concrete scenario that legal commentators have begun to model: a ransomware exploit of a vulnerability in a connected medical IoT gateway deployed in a hospital. The manufacturer is a CRA-regulated entity. The hospital is a NIS2 essential entity. Staff credentials are affected, triggering GDPR.7
Within the first 24 hours, the manufacturer must submit a CRA Article 14 early warning to its designated CSIRT coordinator and to ENISA via the Single Reporting Platform. Simultaneously, the hospital must submit a NIS2 Article 23 early warning to its own national CSIRT. The two notifications may go to different CSIRTs operating under different national transpositions. The Digital Omnibus single incident reporting entry point — which will eventually streamline notifications across NIS2, GDPR, DORA, eIDAS, and the CER Directive — does not currently include the CRA Single Reporting Platform.8
The operational consequence is that incidents originating from a product-level vulnerability require two coordinated reporting streams with no EU-level orchestration defined between them. The entity and the manufacturer must each meet their own 24-hour clock independently, and the two clocks start at different moments — the manufacturer’s when it becomes aware of the actively exploited vulnerability, the entity’s when it becomes aware of the significant incident affecting its operations.
2. The contractual timing gap between manufacturer notification and customer notification.
CRA Article 14 obliges the manufacturer to notify the authority within 24 hours. CRA Article 14(8) obliges the manufacturer to inform impacted users “in a timely manner,” without specifying a hard deadline.9 If the manufacturer fails to do so, the CSIRT “may” provide information to users where proportionate and necessary.
NIS2 Article 23, by contrast, gives the NIS2 entity 24 hours from its own awareness of a significant incident. But the entity cannot be aware of an incident rooted in a supplier’s product vulnerability until the supplier tells it.
The governance asymmetry is this: the manufacturer’s regulatory obligation runs to the authority before it runs to the customer. The customer’s own regulatory obligation runs in parallel but depends on information flowing from the supplier. Unless the contractual relationship between them explicitly requires sub-24-hour customer notification for actively exploited vulnerabilities, the NIS2 entity can find itself structurally unable to meet its own Article 23 obligation on product-originated incidents — not because it failed to detect or respond, but because its supplier was not contractually required to tell it fast enough.
Most supplier contracts in operation today do not contain this clause. They will need to.
3. Customer notification down the chain.
The problem compounds one layer further. When a NIS2 essential entity becomes aware of a significant incident, Article 23 may require it to inform recipients of its services where appropriate. If the incident originates in a CRA-regulated product, there are now three notification layers operating on three different regulatory logics: the manufacturer notifying the authority and users under CRA Article 14, the NIS2 entity notifying its competent authority under Article 23, and the NIS2 entity notifying its own customers under Article 23.
No EU-level instrument currently defines the orchestration between these three layers. The CISO of a NIS2 entity that sits mid-chain — a managed service provider delivering CRA-regulated products to other NIS2 entities, for example — inherits an orchestration responsibility that the regulations gesture towards but do not specify. The governance architecture must come from the entity itself, drafted into supplier contracts above it and customer contracts below it.
4. The questionnaire flood persists until certification arrives.
The European Commission’s January 2026 amendment proposal explicitly acknowledges that NIS2 supply chain obligations have generated burdensome and inconsistent supplier questionnaires, often cascading down the chain.10 The proposed solution is certification-based compliance: European cybersecurity certification schemes, including future entity-level cyber-posture certifications, will serve as portable evidence of compliance with Article 21 obligations.
The CRA creates the parallel mechanism on the product side. CRA conformity — CE marking, Software Bill of Materials (SBOM), technical documentation, conformity declarations — is by design portable evidence usable across the single market.11 A NIS2 entity’s supply chain audit of a CRA-regulated supplier should, in principle, be a review of that supplier’s standardised CRA conformity documentation rather than a bespoke questionnaire.
In practice, that “compliance handshake” does not yet exist at scale. The EU cybersecurity certification schemes that the January 2026 proposal anchors on are years from operational reality. Until they arrive, NIS2 entities continue to issue questionnaires and CRA manufacturers continue to respond to them — even though the underlying evidence base is, by regulatory design, converging. Vendor risk management frameworks built around proprietary questionnaire formats today will carry migration costs later. Those architected now to accept portable conformity evidence will compound in value.
5. End-of-life components and the lifecycle asymmetry.
CRA obligations on manufacturers extend throughout a defined “support period” that manufacturers must specify to users, which the regulation expects to reflect the reasonable useful life of the product.12 NIS2 entity-level obligations have no such sunset. Article 21 measures remain operative as long as the entity operates.
This creates a quiet liability that most CISOs have not yet surfaced. When a CRA-regulated product reaches the end of its declared support period but remains deployed in a NIS2 entity’s operations, the manufacturer’s reporting obligation does not terminate cleanly — it narrows and eventually exits. The vulnerability monitoring obligation, however, does not disappear. It shifts in practice to the NIS2 entity under Article 21(2)(e), which requires vulnerability handling in acquisition and maintenance of systems.
For CISOs currently operating fleets of industrial control systems, connected devices, or embedded software that will age through 2028–2030, the question is whether the in-use inventory has been mapped against anticipated supplier support periods, and whether the decommissioning plan aligns with the regulatory point at which the NIS2 entity inherits full operational responsibility for vulnerability handling.
The Compliance Handshake — Where the Frameworks Help
The picture is not entirely adversarial. The structural direction of travel is towards portable, EU-recognised evidence that reduces the duplicative supervisory burden across jurisdictions.
CRA technical documentation can, architected correctly, feed NIS2 supply chain evidence directly. SBOMs satisfy both NIS2’s vulnerability handling expectations (Article 21(2)(e)) and CRA’s Annex I requirements. Conformity declarations, technical documentation retained for ten years, and CE marking under CRA create standardised artefacts that supplier risk programmes can ingest at scale.13 The January 2026 amendment proposal makes this alignment explicit: where a CRA-style certification demonstrates compliance, supervisory authorities will be precluded from subjecting the entity to additional security audits on those matters.
The practical implication for CISOs is that CRA conformity evidence is not only a supplier’s burden — it is the CISO’s future evidence base. Vendor risk frameworks that are redesigned now to accept this evidence in standardised form will capture the efficiency gains as soon as the certification schemes become operational. Those locked into proprietary questionnaire-based assurance will face a migration project later.
What CISOs Should Do Before September
The September 2026 deadline is not a date at which compliance architecture becomes necessary. It is the date at which the absence of that architecture becomes operationally visible.
Map the intersection in your supplier base. Identify which of the products in your current NIS2 compliance scope are also in CRA scope. For most organisations, this is a larger subset than expected — the CRA’s definition of products with digital elements is deliberately broad, covering almost any hardware or software with direct or indirect network connection.14 The mapping exercise itself surfaces the scale of the interface.
Rewrite supplier contracts to close the notification timing gap. Master service agreements and product purchase contracts with CRA-scope suppliers should explicitly require customer notification of actively exploited vulnerabilities and severe incidents within a window that allows the NIS2 entity to meet its own Article 23 obligation. Sub-24-hour customer notification is not a contractual default. It must be negotiated in, and the negotiation is easier before September, when suppliers’ own programmes are still being designed, than after.
Build an integrated incident response playbook. Incident response plans drafted under NIS2 should be updated to pre-coordinate with the CRA Article 14 reporting flow. This includes identifying which CSIRT is the manufacturer’s designated coordinator, how dissemination from that CSIRT propagates to the entity’s own CSIRT, and where the entity’s own 24-hour clock starts relative to the supplier’s notification. Test the playbook before it is needed.
Align the vendor risk framework to accept CRA conformity evidence. The SBOM, technical documentation, and conformity declaration structures that CRA manufacturers will produce from September onwards should be ingestible by the vendor risk programme without reformatting. This is an architectural choice that the programme owner makes now or later, at different cost points.
Have the conversation with critical suppliers. Ask CRA-scope suppliers directly: are they on track for September readiness, what is their designated CSIRT coordinator, and what contractual notification flows will they support for NIS2-regulated customers. Their answer is a real input to your own risk posture. Their gap becomes your gap.
The Governance Principle
The first generation of NIS2 compliance programmes tested whether organisations could treat cybersecurity as governance rather than a project. The NIS2–CRA interface tests whether they can treat supply chain governance as architecture rather than paperwork.
The organisations that will struggle through autumn 2026 are those whose vendor risk programmes are built as annual questionnaire cycles rather than as continuous evidence pipelines; whose supplier contracts presume a pre-CRA notification regime; whose incident response playbooks assume a single reporting channel; and whose supplier inventory has not yet been mapped against the CRA scope they already rely on.
The organisations that will come through it with structural advantage are those that have recognised a basic governance reality: the regulatory architecture of European cybersecurity is now converging on portable evidence, coordinated reporting, and standardised conformity. The CISOs who build their programmes to that architecture — not to the current patchwork — are building the infrastructure that compounds.
The deadline is September. The governance question is earlier.
References
1. European Commission — CRA Reporting Obligations, accessed April 2026
2. Hyperproof — Understanding the Relationship Between NIS2 and the EU Cyber Resilience Act, February 2026
3. DLA Piper — NIS2 Directive Explained Part 3: Supply Chain Security, December 2025
4. NIS2 Directive (EU) 2022/2555, Article 23
5. Cyber Resilience Act (EU) 2024/2847, Article 14
6. ENISA — Single Reporting Platform (SRP), accessed April 2026
7. CRA vs NIS2 vs GDPR vs EU AI Act — Regulatory Decision Tree, March 2026
8. DLA Piper — NIS2 Directive Explained Part 3: Supply Chain Security, December 2025
9. Cyber Resilience Act (EU) 2024/2847, Article 14(8)
10. IAPP — EU Cybersecurity Reboot: Practical Impacts of the Proposed NIS2 and CSA2 Reforms, March 2026
11. European Commission — Summary of the CRA Legislative Text, December 2025
12. Cycode — The Complete Guide to the Cyber Resilience Act, December 2025
13. Bird & Bird — CRA’s Phased Entry into Application Starts in September 2026, March 2026
14. OpenSSF — EU Cyber Resilience Act, accessed April 2026