Cyber Resilience Act: Reporting Duty from 11 September 2026

The Cyber Resilience Act – Regulation (EU) 2024/2847 – has been in force since December 10, 2024, but its obligations take effect in stages. The next and, for practical purposes, most important key date is imminent: from September 11, 2026, the reporting obligations under Article 14 apply. Manufacturers must then report actively exploited vulnerabilities and serious security incidents within 24 hours in an initial notification – a process you do not improvise in an emergency, but build beforehand.

The topic is less dramatic than often portrayed, but logistically demanding – and it affects considerably more companies than currently feel addressed: anyone who places hardware or software with a direct or indirect data connection on the EU market under their own name is a “manufacturer” within the meaning of the regulation – including the machine builder with its own control software and the mid-sized software house.

Whom the CRA addresses as a manufacturer

The scope covers “products with digital elements”: hardware and software including associated remote data processing that are placed on the EU market. The term is deliberately broad. Many mid-market companies – machinery and plant builders, manufacturers of connected components, software houses with their own product – do not yet classify themselves as addressees, even though they are.

Anyone who falls within the scope carries, as a manufacturer, a package of obligations:

cybersecurity risk assessment for the product,
fulfillment of the essential requirements under Annex I,
technical documentation,
a defined support period with security updates,
CE marking and EU declaration of conformity.

For the handling of vulnerabilities, a support period of at least five years applies – shorter only if the expected useful life is itself shorter.

Three key dates – and why the middle one is the most important

Article 71 staggers the application of the regulation into three stages:

June 11, 2026: The rules on notified bodies (conformity assessment bodies) apply – this date has already passed.
September 11, 2026: The reporting obligations under Article 14 become binding.
December 11, 2027: The regulation applies in full, including all product requirements.

For existing products there is an important distinction: products placed on the market before December 11, 2027, are subject to the full requirements only if they are substantially modified afterward. The reporting obligations under Article 14, by contrast, apply under Article 69 regardless of when the product was placed on the market. Put differently: for the product portfolio already in the field today, the reporting process must be in place by September 11, 2026. That is precisely why this date is the actual driver of action – not the year 2027.

What specifically must be reported from September 11, 2026

Two case groups are subject to reporting: actively exploited vulnerabilities in a product and serious incidents with an impact on its security. A cascade of deadlines applies to both:

early warning within 24 hours of becoming aware,
notification within 72 hours with an initial assessment,
final report – for vulnerabilities, no later than 14 days after a corrective measure is available; for incidents, no later than one month after the 72-hour notification.

The recipients of the notifications are the CSIRT designated as coordinator and ENISA, technically via a central reporting platform (Single Reporting Platform). Here lies a peculiarity of the current situation: as of mid-July 2026, this platform was not yet operational – it must be ready for use by September 11, 2026. Waiting for the platform details is nonetheless the wrong strategy. In practice, the 24-hour deadline fails not because of the reporting form, but because the information does not reach the right place internally in time.

The remaining obligations: a look at December 2027

Anyone who has organized the reporting obligation should not lose sight of the second block. By December 11, 2027, newly placed products must meet the full requirements. Two points deserve particular attention:

Conformity assessment: Products classified as “important” (Annex III) or “critical” (Annex IV) are subject to stricter assessment procedures – pure self-assessment suffices for “important” class I products only if relevant harmonized standards are fully applied; for higher classes it is ruled out.
State of the standards: Harmonized standards for the CRA have not yet been published in the Official Journal of the EU; following the deadline postponement proposed by the Commission in July 2026, the first finished standards are expected between October and December 2026 – listing in the Official Journal follows thereafter. Manufacturers who begin implementation now are therefore working, for the time being, directly against the requirements of Annex I.

The threat of sanctions must be taken seriously: violations can be penalized with fines of up to 15 million euros or 2.5 percent of worldwide annual turnover – whichever is higher. There is one relief for micro and small enterprises: they are not fined if they merely miss the 24-hour deadline for the early warning. That is expressly not a free pass for the overall process.

Readiness check: five steps until September 11

The good news: the reporting obligation does not require a major project, but a clean process. Five steps, in this order:

1. Create a product inventory

Which products with digital elements do you place on the EU market – including firmware, apps, and associated remote data processing? Without this list, all further planning remains piecemeal.

2. Organize vulnerability intake

How do you even learn of a vulnerability in your product? A defined intake channel is needed – for external reports from security researchers and customers as well as for your own findings from development and operations.

3. Define an internal 24-hour escalation path

From the first indication to the decision “reportable or not,” no 24 hours may elapse. This requires clear responsibilities, deputizing rules, and reachability even outside office hours.

4. Assign reporting responsibility

Who files the notification, who approves it, who maintains the 72-hour update and the final report afterward? A named role with a deputy suffices – but it must be named before the key date.

5. Adopt a support-period policy

Define the support period per product and document the rationale. This is at the same time the basis for communication with customers and for later conformity work toward 2027.

Perspective: logistics, not panic

From September onward, the CRA demands nothing that an orderly-run company could not deliver. But it demands commitment: defined processes, named responsible parties, deadlines met. Anyone who tackles the topic now with a manageable preparation project will be able to act by the key date – and will at the same time have laid the foundation for the full product requirements from December 2027.

How sector7 helps

As an owner-led business, we combine compliance consulting (ISO 27001, NIS-2, DORA, TISAX) with the technical operations behind it – and apply the same systematic approach to CRA preparation. We wire the vulnerability intake and the 24-hour escalation path directly into our 24/7 NOC monitoring, so that indications don’t sit unread in an inbox but are escalated to the right place around the clock. All of this at predictable flat monthly rates, so that CRA preparation stays budgetable.

This article is a professional assessment and does not replace legal advice in individual cases.

Cyber Resilience Act: Reporting Obligation from September 11, 2026