EU Cyber Resilience Act Reporting from 11 September 2026: A Practical Guide

The EU Cyber Resilience Act’s reporting duty applies from 11 September 2026 to any manufacturer placing in-scope products with digital elements on the EU market, wherever that manufacturer is established. A manufacturer that becomes aware of an actively exploited vulnerability has 24 hours to file an early warning and 72 hours for what the Commission calls a full notification (European Commission, 2026). The product-security and vulnerability-handling requirements apply from 11 December 2027, fifteen months later. Reporting, however, covers products already on that market, including a controller placed on the market in 2019 and never revised since.

When each part of the EU Cyber Resilience Act applies

A manufacturer reading the September date could reasonably assume that full vulnerability handling must be operational by then. The September requirement, however, is narrower: Article 14 requires a working reporting process from 11 September 2026. Annex I Part II sets out the vulnerability handling requirements, and those apply from 11 December 2027. They require a software bill of materials, regular security testing and public disclosure of fixed vulnerabilities (European Commission, 2025). Article 71(2) sets three application dates rather than two: Chapter IV, on the notification of conformity assessment bodies, has applied since 11 June 2026.

Article 14 reporting is triggered when the manufacturer becomes aware of an actively exploited vulnerability or a severe incident affecting the security of the product. The broader Annex I vulnerability-handling requirements apply from 11 December 2027. The early warning is then due without undue delay and, in any event, within 24 hours. Both early warnings identify, where applicable, the member states where the manufacturer knows the product has been made available. For a severe incident, the early warning also states at least whether unlawful or malicious acts are suspected (Regulation (EU) 2024/2847, Articles 14(2) and 14(4)).

Article 14(5) sets the severity test. An incident is severe where it negatively affects, or could negatively affect, the product’s ability to protect sensitive or important data or functions. Availability, authenticity, integrity and confidentiality are all in scope. It is also severe where it has led, or could lead, to malicious code being introduced or executed in the product, or in the network and information systems of a user of the product (Regulation (EU) 2024/2847, Article 14(5)).

The 24-hour filing is an early warning, and what follows it depends on which event started the clock. For an actively exploited vulnerability, the 72-hour notification adds general information about the product, the general nature of the exploit and of the vulnerability, the corrective or mitigating measures the manufacturer has taken, and the measures users can take themselves. For a severe incident it gives the nature of the incident, an initial assessment and those same two sets of measures. The Regulation qualifies those lists, with “as available” for a vulnerability and “where available” for an incident, which sets the expectation that an early filing is incomplete. Both notifications must also indicate, where applicable, how sensitive the manufacturer considers the notified information to be. In exceptional circumstances, a Computer Security Incident Response Team (CSIRT) can take that indication into account and delay onward dissemination on justified cybersecurity-related grounds (Regulation (EU) 2024/2847, Articles 14(2), 14(4) and 16(2)). Article 14(9) required the Commission to specify those grounds, and it did so in Commission Delegated Regulation (EU) 2026/881, adopted on 11 December 2025. The final report on an actively exploited vulnerability is due no later than 14 days after a corrective or mitigating measure is available. For a severe incident it is due within one month of the 72-hour submission (European Commission, 2026).

Article 14 also requires the manufacturer to tell the users. After becoming aware of either event, the manufacturer must inform the affected users and, where appropriate, all users without undue delay (Regulation (EU) 2024/2847, Article 14(8)). Where necessary it must also give them the risk mitigation and corrective measures they can apply themselves. If the manufacturer does not inform users in time, the notified CSIRTs may do so where they consider that proportionate and necessary to prevent or mitigate the impact.

Article 2 determines whether a product falls within the CRA. For products that are in scope, Article 69 sets the transitional treatment for products already on the EU market. Products placed on the EU market before 11 December 2027 fall under the rest of the CRA only if, from that date, they are substantially modified. Article 69, however, expressly excepts Article 14 reporting from that treatment. It applies to all in-scope products, including those placed on the EU market before 11 December 2027 (Regulation (EU) 2024/2847, Article 69(3)). A modification is substantial where it affects the product’s compliance with the essential cybersecurity requirements, or changes the intended purpose it was assessed against (Article 3(30)). The question is compliance and intended purpose, not how large the change appears. This brings earlier products within the reporting framework, but the reporting clock is tied to the manufacturer becoming aware of the relevant event once Article 14 applies.

For a manufacturer of meters, controllers, chargers or telematics units, both statements are true of the same product. An in-scope unit placed on the EU market in 2019 is covered by the reporting duty from 11 September 2026. The reporting duty does not, by itself, bring the unit within the CRA’s conformity assessment, CE marking or EU declaration of conformity requirements. Those requirements apply if the unit is substantially modified from 11 December 2027.

Scope follows the market rather than where the manufacturer is established. A manufacturer outside the EU that places a product on the EU market is in scope. The Article 14 duty remains with the manufacturer, unless an importer, distributor or another person is treated as the manufacturer under Articles 21 or 22. A UK manufacturer placing products on the EU market is subject to the duty for those products. UK product security law, which runs to a different timetable, is a separate regime.

Microenterprises and small enterprises are not subject to administrative fines under the CRA for failing to meet the 24-hour early-warning deadline (Regulation (EU) 2024/2847, Article 64(10) and recital 120). The reporting obligations, however, still apply, including the 72-hour notification and the final report.

Article 14 places the duty on the manufacturer. Under the CRA the manufacturer is the natural or legal person that develops or manufactures a product, or has it designed, developed or manufactured, and markets it under its own name or trademark. That holds whether the product is supplied for payment, for monetisation or free of charge (Regulation (EU) 2024/2847, Article 3(13)). An estate operator, installer or maintenance contractor does not become a manufacturer by operating, installing or maintaining the unit. A person other than the manufacturer, importer or distributor that substantially modifies a product and makes it available on the market is treated as a manufacturer. Articles 13 and 14 then apply to the affected part, or to the whole product where the modification affects the cybersecurity of the product as a whole (Article 22). An importer or distributor is treated as the manufacturer where it places a product on the market under its own name or trademark, or where it substantially modifies a product already placed on the market (Article 21).

An importer or a distributor that becomes aware of a vulnerability in a product it has placed or made available must inform the manufacturer without undue delay. The corrective-action trigger differs for importers and distributors. An importer must act where a product it has placed on the market is not in conformity. A distributor must act where either the product or the manufacturer’s processes are not in conformity. The importer must take the necessary corrective measures, and the distributor must make sure they are taken. Withdrawal or recall follows where appropriate (Regulation (EU) 2024/2847, Articles 19 and 20). A vulnerability, however, is not by itself a finding of non-conformity.

The manufacturer uses one reporting route, the CRA Single Reporting Platform, rather than filing separately in each member state. ENISA established that platform under Article 16 (ENISA, 2026). The notification goes to the CSIRT of the member state where the manufacturer has its main establishment. For Article 14 that is where decisions about product cybersecurity are predominantly taken, and where that cannot be determined, the EU establishment with the highest number of employees. ENISA receives it at the same time, unless particularly exceptional circumstances apply. That CSIRT then normally passes it to the CSIRTs of the other member states where the product has been made available (European Commission, 2026).

Where a manufacturer has no main establishment in the Union, Article 14(7) sets an order for deciding which CSIRT receives the filing. The order starts with the member state of the authorised representative acting for the highest number of that manufacturer’s products. It then runs to the importer placing the highest number, the distributor making the highest number available, and finally the state with the most users. That order fixes the recipient rather than the duty-holder (Regulation (EU) 2024/2847, Article 14(7)).

The September reporting duty reaches legacy products but does not bring them within the support-period and vulnerability-handling requirements. Those apply to products placed on the market from 11 December 2027 and to earlier products that are substantially modified from that date. For remotely managed products, that can require a resilient update route designed into the product lifecycle.

A manufacturer can produce every document the Regulation asks for and still be unable to finish the sequence. Consider a product placed on the market in 2028 with a support period declared to 2035, managed remotely by the manufacturer over a mobile connection and installed on the customer’s own local network. Its bill of materials is current, disclosure is coordinated, an owner is named and the update pipeline has been tested. In 2034, six years into that period, an actively exploited vulnerability is found in the remote management agent. The early warning is filed within 24 hours and the notification within 72. The corrective measure is built, released and delivered to most of the estate. It does not reach part of the installed estate because the radio service those units depend on is no longer available.

Those units still run. Their local function is unaffected, and they remain reachable from the site networks they sit on, which is where the vulnerability is being exploited. An attacker on that network needs only the exposed service. The manufacturer needs its management channel, and that is the path that has gone. The reporting sequence completed on time and the corrective measure exists, but it cannot be delivered. The missing condition is the ability to reach the device at any point in the support period.

Article 13 requires the manufacturer to determine a support period within limits set by the Regulation. The period must reflect expected use, reasonable user expectations, the product’s nature and intended purpose, and relevant Union law. It must be at least five years, unless the product is expected to be in use for less. The end date, to at least the month and year, must be stated at the time of purchase (Regulation (EU) 2024/2847, Articles 13(8) and 13(19)). For equipment expected to remain in use for fifteen years, a three-year support period would fall below both the five-year floor and the expected-use test. Across whatever period it declares, it must handle vulnerabilities effectively.

Annex I Part II requires that where a security update is available, it is disseminated without delay and, by default, free of charge. The Regulation does not say how. For a device managed remotely, the update travels over the device’s connection, which makes connectivity resilience part of the CRA lifecycle risk conversation. If that route is no longer available, the manufacturer needs another update channel, or an engineer attends each device.

The support period in that example ends in 2035, and it spans known network retirements. In the UK, operators have confirmed to Government that they will retire 2G by 2033 at the latest. The announced start dates are May 2029, summer 2029 and during 2030 (Ofcom, 2026). UK 3G switch-off is complete across all the UK mobile networks.

Germany’s three established 2G operators have announced switch-off dates during 2028. Vodafone has said that, in exceptional cases, certain critical IoT applications may continue to use its network until the end of 2030 (Bundesnetzagentur, 2026). In the Netherlands, one 2G network has already closed, and a second closes on 1 December 2027, that operator having begun withdrawing 2G in March 2026 from customers who no longer need it (ACM, 2024; KPN, 2026). The third has published no date. A Dutch government decision note of March 2026 expects the last Dutch 2G networks to close within two to three years, which implies 2028 or 2029, and records that ministers considered requiring 2G to be kept available until 2030 (Ministry of Infrastructure and Water Management, 2026). A support period ending in 2035 extends past every published date above, and past the window the Dutch government currently expects, which could still move in either direction. A fleet reachable this month has been shown to be reachable on this month’s networks. A support period, however, extends into a network estate that will change during the product’s life.

Three lifecycle questions shape whether a remotely managed device can remain reachable across its support period: radio compatibility, connectivity-path resilience and profile lifecycle management.

• The first is whether the device stays compatible with the radio technologies available across its support period, which is a question about the radio rather than the core: no arrangement of cores makes a 2G-only modem use 4G.
• The second is whether the product’s availability requirement calls for resilience beyond multi-network radio access. A managed multi-network service can improve coverage and radio-network choice. Where the risk assessment also requires protection against a mobile-core failure, the design needs an alternative path through an independent core. CSL DualCore® architecture provides two independent mobile operator core paths. rSIM® can implement that architecture using two profiles on one SIM, with the switching decision made locally rather than depending on an instruction sent through the disrupted path. Where specified in the service design, both routes use private APN and encrypted routing rather than the public internet. Core independence acts in the connectivity layer. It does not protect the manufacturer’s own release channel. A compromise there could itself become a severe incident where it meets the Article 14(5) impact test.
• The third is how connectivity profiles are managed and selected during the product’s life. rSIM® technology holds two independent multi-network roaming profiles and selects between them on the SIM, keeping the local resilience logic out of host-device firmware. Most integrations are achieved through device configuration rather than host-device firmware changes, subject to compatibility assessment and validation for the product and deployment. Across the wider estate lifecycle, the CSL IoTM Platform can manage operators, subscriptions and eSIM profiles across supported providers and integrations. This orchestration layer prepares and governs the profile estate remotely, while local resilience can select between profiles already available on the SIM during a connectivity interruption.

An estate operator does not file under Article 14, and it depends on manufacturers that do. The support-period end date, update route, network dependencies and reporting responsibility can all be established before a vulnerability is found. Procurement therefore needs four answers:

• the declared support period end date for each connected product, and what continues once that period ends
• which mobile networks the product can use, and whether both routes depend on a single operator core
• how a security update reaches a unit in the field, and whether it needs a site visit
• which party files under Article 14 for this product, and the contact for a vulnerability report

Product documentation should state the support-period end date and the update route. Core-dependency information may come from the connectivity supplier rather than the manufacturer. The procurement record should also name the Article 14 reporting contact.

The reporting duty applies from 11 September 2026, and the main CRA obligations for manufacturers from 11 December 2027. A manufacturer placing connected products on the market from that date must determine a support period and state its end date at the time of purchase. For remotely managed products, its lifecycle plan should address how security updates will reach deployed devices throughout that period, including the device, radio, connectivity and application dependencies involved.

CSL designs and manages multi-network and independent-core connectivity for critical connected devices across Europe. We work with manufacturers and operators to assess how device compatibility, coverage, routing and connectivity resilience support their lifecycle requirements. To discuss a specific product or estate, contact sales@csl-group.com.

1. European Commission (2026), Cyber Resilience Act: reporting obligations. https://digital-strategy.ec.europa.eu/en/policies/cra-reporting. Page last updated 11 September 2026.
2. European Commission (2025), The Cyber Resilience Act: summary of the legislative text. https://digital-strategy.ec.europa.eu/en/policies/cra-summary. Page last updated 3 December 2025.
3. Regulation (EU) 2024/2847 (Cyber Resilience Act), Official Journal of the European Union, 20 November 2024. http://data.europa.eu/eli/reg/2024/2847/oj. Articles 2, 3(13), 3(30), 13, 14, 16, 19, 20, 21, 22, 64, 69 and 71, recital 120, and Annex I, in particular Annex I Part II. Article 64(10) read as corrected by the corrigendum of 2 July 2025 (OJ L, 2025/90555), http://data.europa.eu/eli/reg/2024/2847/corrigendum/2025-07-02/oj.
4. Commission Delegated Regulation (EU) 2026/881, adopted 11 December 2025, Official Journal of the European Union, 20 April 2026. http://data.europa.eu/eli/reg_del/2026/881/oj. Made under Article 14(9) of Regulation (EU) 2024/2847.
5. ENISA (2026), CRA Single Reporting Platform: frequently asked questions. https://www.enisa.europa.eu/topics/product-security/single-reporting-platform-srp/frequently-asked-questions. Page last updated 17 September 2026.
6. Ofcom (2026), Switching off the UK’s 2G and 3G mobile networks: what you need to know. https://www.ofcom.org.uk/phones-and-broadband/coverage-and-speeds/3g-switch-off. Page last updated 29 May 2026.
7. Bundesnetzagentur (2026), 2G-Abschaltung. https://www.bundesnetzagentur.de/DE/Fachthemen/Telekommunikation/Breitband/2GAbschaltung/start.html.
8. Autoriteit Consument & Markt (2024), Gevolgen van de afschakeling van 2G en 3G. https://www.acm.nl/nl/publicaties/gevolgen-van-de-afschakeling-van-2g-en-3g. Published 17 December 2024.
9. Ministry of Infrastructure and Water Management (2026), letter to the House of Representatives on the consequences of switching off the 2G and 3G networks for eCall, 18 May 2026 (Kamerstuk 24095, nr. 593), with its accompanying decision note of March 2026. Decision note: https://www.tweedekamer.nl/downloads/document?id=2026D22857.
10. KPN (2026), Netwerk update. https://www.kpn.com/netwerk-update.

The cited sources were checked on 17 September 2026. CSL retains a controlled source-verification record covering the source versions, the checks made and the qualifications that attach to them.