Cybersecurity and product governance

The EU Cyber Resilience Reporting Clock Starts on 11 September. Estonian Product Companies Need a 24-Hour Process

The CRA’s main product requirements apply later, but reporting of actively exploited vulnerabilities and severe security incidents begins in September 2026.

By Martin Repinski25 August 2026

On 11 September 2026, one of the first operational deadlines under the European Union’s Cyber Resilience Act becomes applicable. Manufacturers must start reporting actively exploited vulnerabilities and severe incidents that affect the security of products with digital elements.

The timing can be easy to misread. Most of the CRA’s product-security, conformity and lifecycle requirements apply from 11 December 2027. The reporting duties in Article 14 start fifteen months earlier. An Estonian company that develops connected hardware, commercial software or a digital component for the EU market therefore cannot postpone its reporting process until the wider compliance programme is complete.

This is not a rule requiring every business to report every internal cyber event. The first management task is to establish whether the company is acting as a manufacturer of a product with digital elements and whether the event meets one of the CRA reporting triggers. That classification depends on the product, the company’s role and the facts of the event.

Two compliance clocks are running

The CRA entered into force on 10 December 2024. The European Commission’s official summary separates the implementation calendar into distinct stages:

notification rules for conformity-assessment bodies have applied since 11 June 2026;
Article 14 reporting obligations apply from 11 September 2026;
the CRA’s main provisions apply from 11 December 2027.

The separation matters for budgets and responsibility. A company may still be developing its full risk assessment, technical documentation, support-period policy and conformity route for 2027, while already needing an operational method for recognising and reporting specific vulnerabilities and incidents in 2026.

Reporting also reaches further back than the full application date. The Commission states that the reporting duties cover products with digital elements made available on the EU market, including products placed on the market before 11 December 2027. A legacy product cannot automatically be excluded merely because it was released before the CRA’s main provisions apply.

Which products and organisations are in view

The CRA describes a product with digital elements as software or hardware, including relevant remote data-processing solutions and components placed on the market separately. The general scope concerns products made available on the EU market whose intended or reasonably foreseeable use includes a direct or indirect logical or physical data connection to a device or network.

The main reporting duty is directed at the manufacturer: the person or organisation that develops or manufactures such a product, or has it developed or manufactured, and markets it under its name or trademark. The definition can apply whether the product is supplied for payment, monetised in another way or provided free of charge in a commercial context.

Importers, distributors, authorised representatives and open-source software stewards have different roles under the Regulation. ENISA notes that open-source software stewards have reporting duties to the extent specified in Article 24. A company should therefore record its role product by product instead of assuming that “software user”, “reseller” or “open source” provides a complete answer.

The reporting sequence is measured in hours

The reporting process begins when the manufacturer becomes aware of an actively exploited vulnerability or a severe incident affecting the security of the product.

An actively exploited vulnerability is one for which there is reliable evidence that a malicious actor has exploited it without the system owner’s permission. A severe incident is assessed against the security impact on the product, including availability, authenticity, integrity or confidentiality and the possible introduction or execution of malicious code.

The official timetable has three stages:

Early warning within 24 hours. The first notice must be submitted without undue delay and in any event within 24 hours after awareness.
Notification within 72 hours. The manufacturer provides general information and an initial assessment, including available corrective or mitigating measures.
Final report for a vulnerability. It is due no later than 14 days after a corrective or mitigating measure becomes available.
Final report for a severe incident. It is due within one month after the 72-hour notification.

Reports are submitted once through the CRA Single Reporting Platform established and operated by ENISA. The platform routes the notification to the CSIRT designated as coordinator for the Member State of the manufacturer’s main establishment and, as a rule, to ENISA. The Commission and ENISA say the platform will be operational when the reporting obligations start on 11 September.

ENISA’s August guidance says representatives will use EU Login. An EU Login account can be created in advance, while validation of authority to report for a manufacturer takes place in connection with use of the platform and must not prevent submission. The practical consequence is that access ownership and internal authority should be decided before an incident, even though the reporting clock starts only when the company becomes aware of a reportable event.

A workable readiness plan for an Estonian product company

1. Build a product-and-role register

List each connected device, software product, application and separately marketed component. Record the legal entity that markets it, the product name used in the EU, its support owner, the countries where it is available and the company’s role in the supply chain.

2. Connect security monitoring to legal product ownership

Security teams may detect a vulnerability in code, a cloud service or a third-party component, while the manufacturer’s legal responsibility sits elsewhere in the group. The escalation route should connect the technical alert to the entity, product and decision-maker that can assess the CRA trigger.

3. Define the awareness moment

The 24-hour period leaves little room for uncertainty about when the company became aware. The process should preserve timestamps, the source of the alert, the evidence available, the first assessment and the person who accepted responsibility for classification.

4. Prepare the 24-hour and 72-hour data separately

The early warning is not the final technical report. ENISA’s template guidance distinguishes the minimum information required at each stage. A company should prepare internal forms that capture the product, notification type, reporting time, known impact, available mitigations and the information that remains under investigation.

5. Include suppliers and third-party components

Vulnerabilities often enter a product through a library, firmware module, cloud dependency or other component. Supplier contracts and security contacts should support rapid notification to the product manufacturer. The company should know who can provide evidence, a patch and customer-facing mitigation outside normal office hours.

6. Rehearse one realistic scenario

A short exercise can test whether product, security, management, legal and communications teams can reach a reasoned decision before the 24-hour deadline. The goal is not to predetermine every legal classification. It is to remove avoidable delay from access, ownership, evidence collection and approval.

Reporting readiness is part of product economics

The CRA reporting deadline turns vulnerability management into a board-level operating capability. A product with unclear ownership, unsupported dependencies or fragmented incident evidence is not only a technical risk. It can create emergency management cost, customer uncertainty and regulatory exposure.

For Estonian technology companies, the useful response is proportional. Not every alert is reportable, and not every company is the manufacturer. But every company that places connected hardware or software on the EU market should be able to identify its role, start the clock consistently and reach the right decision-maker quickly.

The first deadline is no longer a distant 2027 conformity milestone. It is a September 2026 incident-response requirement measured in hours.

Information was checked on 25 August 2026. This article provides general business analysis and is not individual legal, cybersecurity or compliance advice. Product scope, economic-operator roles and reporting triggers depend on the facts of each case.

Main sources

Martin Repinski