The Cyber Resilience Act’s first deadline: reporting duties since 11 September 2026

The Cyber Resilience Act’s Article 14 reporting obligations have applied since 11 September 2026, including to products already on the market within its scope. Full application follows in December 2027. Manufacturers need a working reporting process now, with responsibilities and product information ready before an incident starts the clock.

What the CRA is, briefly

The Cyber Resilience Act is an EU regulation setting cybersecurity requirements for "products with digital elements" placed on the EU market — connectable hardware and software, from consumer devices to applications and the components that go into them. It entered into force on 10 December 2024 and phases in over three years. It sits alongside NIS2 rather than replacing it: NIS2 regulates how in-scope organisations operate, the CRA regulates the products they ship.

The shift it represents is that security stops being a quality attribute you may choose to invest in and becomes a market-access condition. Products that do not meet the requirements are not supposed to be on the market at all.

The phased timeline

• 10 December 2024 — the regulation entered into force, starting the clock on everything below.
• 11 June 2026 — the framework for notifying conformity assessment bodies applies, so notified bodies can be designated ahead of full application.
• 11 September 2026 — the reporting obligations in Article 14 apply. These duties are now in effect.
• 11 December 2027 — the bulk of the regulation applies in full: essential cybersecurity requirements, conformity assessment and CE marking.

The reporting duty arrives fifteen months before the requirements it reports against. You can be obliged to disclose an exploited vulnerability well before you are obliged to have completed a conformity assessment.

The reporting clock

From 11 September 2026, manufacturers must report actively exploited vulnerabilities and severe incidents affecting the security of their products. The sequence is three-staged:

1. 01An early warning within 24 hours of becoming aware.
2. 02A fuller notification within 72 hours.
3. 03A final report — no later than 14 days after a corrective measure is available, in the case of an actively exploited vulnerability, and within one month of the 72-hour notification for a severe incident.

Reports go through a single reporting platform, addressed to the CSIRT of the Member State where the manufacturer has its main establishment, with the information made available to ENISA at the same time. The receiving CSIRT then shares it with other relevant CSIRTs. The Single Reporting Platform became operational on 11 September 2026.

The operative phrase is "becoming aware". Twenty-four hours is not a long time to establish which products are affected, whether exploitation is actually occurring, and who is authorised to file a notification to a national authority. Every one of those questions is much harder to answer for the first time during an incident.

Who this actually binds

The obligations fall on manufacturers — those placing a product with digital elements on the EU market under their own name or trademark — with related duties for importers and distributors. Three things about scope are commonly misread:

• It is not limited to new releases. Products already placed on the market before full application are covered by the reporting duty, which is precisely the category most teams have stopped thinking about.
• It is not only hardware. Software placed on the market is in scope, and the definition reaches remote data processing solutions where they are integral to the product — so "we are a cloud service" is worth checking rather than assuming.
• Free and open-source software is treated distinctly, with obligations shaped around how it is actually developed and monetised. That is a genuine distinction, not a blanket exemption for anything with a public repository.

If you are not the manufacturer, the effect reaches you anyway. Anyone shipping a product with digital elements will be pushing security expectations down their supply chain, and answering those questions is going to look a lot like the security questionnaires that already arrive with enterprise deals.

What the reporting process needs now

1. 01A named owner and a decision path. Who decides that something is reportable, who files, and who does it when that person is on holiday. This is the single highest-value item and it costs a meeting.
2. 02An inventory of what you have placed on the market and what is in it. You cannot judge whether a disclosed vulnerability affects you within 24 hours if establishing which versions contain which dependency takes a week.
3. 03A route for someone outside your company to report a vulnerability to you. A monitored address, published where a researcher will look. Many disclosures arrive from strangers, and a report sitting in an unmonitored inbox still starts your awareness clock in the eyes of a regulator.
4. 04A way to tell exploitation from theory. The 24-hour trigger is an actively exploited vulnerability, which means having enough logging and alerting to distinguish "this is exploitable" from "this is being exploited".
5. 05A remediation path fast enough to matter. The 14-day final report is anchored to when a corrective measure becomes available, which quietly rewards teams that can ship a patch quickly.

What security testing does and does not give you

Being direct about the boundary, because this is where the market is about to fill up with claims that will not survive contact with the regulation.

What an OWASP-based assessment contributes is evidence: a systematic look at access control, authentication, injection, cryptographic handling, misconfiguration and vulnerable dependencies, with reproduction steps and prioritised remediation. That is directly useful for the essential requirements around shipping without known exploitable vulnerabilities, and for demonstrating that vulnerability handling is a process rather than an intention.

What it is not is a conformity assessment. We are not a notified body, an assessment report is not a CE marking, and no supplier can certify you against the CRA by testing your application — the same distinction that separates an assessment from a certified penetration test. Conformity is a manufacturer obligation with its own route, and for the more sensitive product categories it involves a third party designated for exactly that purpose.

Anyone offering to make you "CRA compliant" with a security test is selling you the wrong document.

The genuinely useful preparation between now and December 2027 is unglamorous: know what you ship, know what is in it, be able to find out quickly whether a disclosure affects you, and fix things fast enough that the reporting clock is an administrative task rather than a crisis. Teams in regulated sectors will recognise all of it, because it is what enterprise procurement has been asking for informally for years.