The single most common misreading of the EU Cyber Resilience Act is that all of its obligations arrive together on one date. They do not. The reporting duties under Article 14 come into force well before the rest of the regulation, and they apply to products that are already on the market. Understanding the timing is the difference between being ready and being exposed.
This post sets out precisely when mandatory reporting begins, what event triggers it, and which economic operators it binds. It is the first in a six-part series on CRA reporting. The companion posts cover which vulnerabilities and incidents must be reported, how reporting to ENISA and national authorities is organised, the timelines and follow-up obligations, how to prepare internal detection and escalation, and how reporting connects to broader product and risk management. For a single-page overview of the whole reporting regime, see our guide to which CRA reporting obligations apply, when they start, and how to be ready.
The two dates that govern the CRA
The CRA entered into force on 10 December 2024, but its substantive obligations apply on a staggered schedule. Two dates matter for most manufacturers.
The first is 11 September 2026. From this date, the reporting obligations under Article 14 apply. Any manufacturer of a product with digital elements placed on the EU market must be able to notify authorities when one of their products is actively exploited or suffers a severe security incident.
The second is 11 December 2027. From this date, the full body of CRA requirements applies: conformity assessment, CE marking, technical documentation under Annex VII, and the essential cybersecurity requirements in Annex I.
The gap between these two dates is deliberate, and it is the part organisations underestimate. The obligation to report an actively exploited vulnerability arrives more than a year before the obligation to have completed a conformity assessment. A manufacturer can be fully inside the reporting regime while still working through the rest of its compliance programme.
What "becomes mandatory" actually means
Reporting under Article 14 is not a continuous filing requirement. There is no quarterly return and no routine disclosure schedule. The obligation is conditional. It activates when a specific event occurs.
Two categories of event trigger the duty:
- An actively exploited vulnerability. A manufacturer becomes aware that a vulnerability contained in one of its products is being exploited in the field by a malicious actor.
- A severe incident affecting security. A manufacturer becomes aware of a security incident that has an impact on the security of the product, for example a compromise of the manufacturer's development or distribution infrastructure that affects users.
When either event occurs, the clock starts. The detail of what falls inside and outside these categories is the subject of the next post in this series. For the purposes of timing, the key point is that the trigger is awareness of a qualifying event, and the deadline runs from that moment of awareness.
The clock starts at "becomes aware"
Article 14 measures its deadlines from the point at which the manufacturer becomes aware of the qualifying event. This is the single most operationally significant phrase in the entire reporting regime.
It means the 24-hour early-warning window does not begin when a manufacturer decides to act, when legal sign-off is obtained, or when a fix is ready. It begins when the organisation first has knowledge that a product is being actively exploited. Knowledge held by a support engineer, a security researcher's report sitting in an unmonitored inbox, or an alert in a SIEM that nobody triaged all count toward awareness.
This has a direct consequence for readiness. An organisation that cannot reliably route incoming signals to a person with authority to assess them will struggle to evidence when awareness occurred, and may blow the deadline before anyone senior knows there is a problem. Building that intake and escalation path is covered in the post on internal detection and escalation.
Who the obligation binds
The CRA assigns obligations across a chain of economic operators. The reporting duty under Article 14 falls primarily on the manufacturer, but importers and distributors carry related responsibilities.
Manufacturers
The manufacturer is the entity that develops or manufactures a product with digital elements, or has it designed, developed, or manufactured, and markets it under its own name or trademark. The manufacturer holds the Article 14 reporting obligation in full. It must submit the early warning, the detailed notification, and the final report.
Importers
An importer places a product from a third-country manufacturer on the EU market. Importers must ensure the products they place on the market comply with the CRA. Where an importer becomes aware that a product presents a significant cybersecurity risk, it must inform the manufacturer and, where relevant, the market surveillance authorities. Importers cannot place non-compliant products on the market and must act when they learn of a problem.
Distributors
A distributor makes a product available on the market without being the manufacturer or importer. Distributors must act with due care, must not make available products they know or have reason to believe are non-compliant, and must cooperate with authorities. A distributor that learns of an actively exploited vulnerability has a duty to inform the manufacturer and the relevant authorities.
In practice, the reporting cascade to ENISA and national authorities is the manufacturer's to run. The importer and distributor obligations are a backstop that ensures problems surface even where the manufacturer is slow or absent.
Products already on the market are in scope
A frequent assumption is that the CRA only applies to products designed and released after the regulation takes effect. For the conformity requirements that take effect in December 2027, scope is more nuanced. For the Article 14 reporting obligations, the position is clearer and stricter.
From 11 September 2026, the reporting obligation applies to manufacturers of products with digital elements that are on the EU market, including products placed on the market before that date and still supported. A router shipped in 2024, a programmable logic controller installed in 2023, or a firmware-embedded device sold years ago can all generate an Article 14 reporting event if they are actively exploited while still in their support period.
This is why the September 2026 date is operationally demanding. It does not give organisations a clean slate of new products to worry about. It places the entire supported install base inside the reporting regime on day one. We covered the practical implications of this in our analysis of what Article 14 compliance actually requires.
Reporting depends on Article 13 being in place
Article 14 does not stand alone. It depends on the vulnerability handling obligations in Article 13, which require manufacturers to operate a coordinated vulnerability disclosure process and to provide a contact address through which vulnerabilities can be reported to them.
The connection is causal. For many manufacturers, the first sign that a product is being actively exploited will arrive through their disclosure channel, sent by a security researcher or a customer. Without a monitored intake point, the awareness that starts the Article 14 clock may never form in time, or may form only once exploitation is widespread and public.
A manufacturer that wants to meet Article 14 reliably therefore needs the Article 13 machinery working first: a published disclosure policy, a monitored intake channel, acknowledgement within a defined window, and a triage process that can recognise active exploitation when it appears. The relationship between handling and reporting is explored further in the final post of this series.
What to have in place before September 2026
Mandatory reporting becomes real on a fixed date, and the work to be ready for it is front-loaded. An organisation that intends to comply on 11 September 2026 should already have the following operational, not merely planned:
- A published, monitored vulnerability disclosure channel under Article 13.
- A triage process able to recognise active exploitation and severe incidents.
- A named individual or role with authority to declare a reporting event and start the cascade without waiting for executive sign-off.
- Verified access to the reporting platform and a documented contact for the relevant national CSIRT.
- Pre-drafted report templates for the early warning, the detailed notification, and the final report.
- An audit trail that records when awareness formed and when each action was taken.
CVD Portal was built to provide this infrastructure as a service, free to start. A manufacturer registering today gets a branded disclosure portal at yourcompany.cvdportal.com, structured intake with acknowledgement tracking, a CVSS-based triage workflow, report generation aligned to the Article 14 deadlines, and a complete audit trail. The intent is to make the September 2026 date a question of process readiness rather than a months-long engineering project.
The bottom line
The CRA's reporting obligations come into force on 11 September 2026, more than a year before full conformity is required, and they apply to the whole supported install base from the first day. The duty is conditional on a qualifying event, the clock runs from the moment of awareness, and the obligation rests primarily on the manufacturer with importers and distributors as a backstop.
The organisations that comply reliably will be those that treated September 2026 as the real deadline and built their intake, triage, and reporting capability ahead of it. The rest of this series works through exactly what to report, where to send it, on what timeline, and how to wire the internal process that makes it happen.