Smartphones, mobile apps and connected production machinery make everyday life and business operations easier. Their security weaknesses, however, can lead to data leaks, financial losses or outages of services or production. The European Cyber Resilience Act (CRA) therefore introduces security requirements for digital products, from development through updates to the handling of vulnerabilities during the support period.
The CRA covers hardware and software made available on the EU market in the course of a commercial activity whose intended or reasonably foreseeable use includes a direct or indirect data connection to a network or another device. It also covers related remote data processing solutions if they were developed by the manufacturer or under its responsibility and the product could not perform one of its functions without them. One example is a cloud service that lets users control a smart thermostat through a mobile app.
By contrast, a standalone web service used only in a browser generally falls outside the CRA, unless it performs a function of the product under the conditions described above. Nor does the regulation apply to software that a company develops exclusively for its own internal use and does not place on the market — for example, its own development or testing tool. Open-source software supplied outside a commercial activity is also excluded; being available free of charge, however, does not by itself guarantee the exemption. Specific exemptions apply, for example, to medical devices and motor vehicles where the products concerned are subject to the relevant sector-specific EU rules.
Reporting also covers products sold years ago
The main CRA requirements will apply from 11 December 2027, generally to products newly placed on the market, and to older products when they undergo a substantial modification. Reporting, however, has applied since 11 September 2026 and extends to all older products within the scope of the CRA, including those whose support period has ended.
The CRA reporting obligation does not replace reporting under other legislation — such as the GDPR or NIS2 (in the Czech Republic, the Cybersecurity Act). Each regime targets something different — the CRA the security of the product, the Cybersecurity Act the organisation and its services, and the GDPR personal data — and a single event can trigger two or even three of them at once. The Czech National Cyber and Information Security Agency (NÚKIB) therefore points out that where the CRA and the Cybersecurity Act both apply, the event must be reported both through the Single Reporting Platform (SRP) and through the NÚKIB Portal.
A discovered flaw does not yet mean a mandatory report
Two situations must be reported. The first is an actively exploited vulnerability: there is reliable evidence that an attacker has exploited a vulnerability in the product in someone else’s system without the owner’s permission. For example, a customer shows that someone bypassed the login through a flaw in the app. This also applies to so-called zero-day flaws, i.e. flaws for which no fix is yet available. A finding during testing or a report from an ethical hacker does not by itself trigger reporting, provided there is no evidence of exploitation.
The second situation is a severe incident having an impact on the security of the product. This may be a compromise of the update system through which malicious code reaches customers, but also an intrusion into the cloud part of the product that gives the attacker access to customers’ data or to remote control of their devices. What matters is the security impact — on the availability, authenticity, integrity or confidentiality of important data or functions, or the possibility of malicious code being executed — not whether the flaw lay in the product itself.
A manufacturer may learn of exploitation from a customer, a supplier or an authority, from a public report or from its own monitoring. The reporting obligation does not require it to monitor all of these sources; once it becomes aware of a suspicion, however, it must assess it without delay. If a flaw in a third-party component is exploited in the product, the component supplier’s report does not replace the manufacturer’s own obligation.
First report within 24 hours, weekends included
The deadlines run from the moment when the manufacturer, after an initial assessment, has a reasonable degree of certainty that a reportable event has occurred. There is no waiting for the investigation to be completed or for a fix. Reporting takes place in three steps and is gradually supplemented:
- An early warning within 24 hours with basic information, where applicable stating the Member States in which the product has been made available.
- A notification within 72 hours on the affected product, the nature of the problem and the measures taken and recommended.
- A final report — for a vulnerability, within 14 days of a corrective or mitigating measure becoming available; for a severe incident, within one month of the notification being submitted.
The first two deadlines run from the same moment and are outer limits: the regulation requires action without undue delay. A discovery on Friday at 3 p.m. therefore means sending the early warning by Saturday at 3 p.m. at the latest.
Exploitation that the manufacturer already knew about before 11 September 2026 is not reported retroactively. If, however, it knew about the vulnerability but not about its exploitation, and the exploitation occurs or comes to light only after that date, a report must be made.
Reporting to the authorities is not enough
Reports are submitted exclusively through the Single Reporting Platform (SRP); each submission goes simultaneously to the designated national CSIRT and to ENISA. For manufacturers with their main establishment in the Czech Republic, that CSIRT is NÚKIB.
That is not the end of the obligation, however. The manufacturer must also inform the affected users — or, where appropriate, all users — of the vulnerability or incident in good time and, where necessary, of the measures users can take to mitigate its impact.
Penalties
Breaching the reporting obligations can lead to a fine of up to EUR 15 million or, for an undertaking, up to 2.5% of its total worldwide annual turnover for the preceding financial year, whichever is higher. Fines, however, can only be imposed from 11 December 2027, when the rest of the regulation starts to apply.
Who will carry out supervision in the Czech Republic will be determined by a Czech act now in preparation. Under the draft, most products are to be covered by the Czech Trade Inspection Authority, with specialised authorities in their respective fields.
Micro and small enterprises enjoy an exemption from penalties: they cannot be fined for missing the 24-hour deadline.
How to prepare
Map your products and the components they use. Including older products and versions whose support has ended. If, for example, a supplier reports a vulnerability in a library, the company must be able to establish within a few hours which of its products contain it and whether they are affected.
Set up responsibilities and procedures. Customer support, developers and sales staff need to know whom to pass a suspicion to immediately. It must be clear who assesses the event, handles the report and its follow-ups, informs users, and who stands in for these people outside working hours. The time when information was received and assessed must also be recorded. The deadline does not wait for management approval or for the investigation to be completed.
Update contracts with suppliers and business partners. Agree on prompt notification, ongoing updates and cooperation in assessment and remediation. Supplier deadlines should leave enough time for your own assessment and reporting.
Connect the CRA with your existing incident procedures. Assess a single event from the perspective of the CRA, the GDPR and the Cybersecurity Act at the same time, where they apply to the company. A common internal procedure can make the work easier, but each report has its own conditions and deadlines.
