Cyber Resilience Act: reporting obligations took effect on 11 September

Since 11 September 2026, every manufacturer of a product with digital elements sold in the European Union has to report actively exploited vulnerabilities and severe incidents affecting the security of that product. The pace is tight: an early warning within 24 hours, a notification within 72 hours, then a final report. The obligation also covers products already on the market, and failing to meet it exposes you to a fine of up to 15 million euros or 2.5% of worldwide turnover.

Almost everything written about the Cyber Resilience Act talks about December 2027. That is right for most of the text, but the reporting clock has been running for four days. And the real question for most of the companies that ask us is not the deadline: it is whether they are a manufacturer within the meaning of the regulation. A pure SaaS used in a browser generally is not. A mobile application backed by your own backend, on the other hand, very probably is.

What applies since 11 September

Regulation (EU) 2024/2847, known as the Cyber Resilience Act, entered into force on 10 December 2024. Its article 14, on reporting obligations, has applied since 11 September 2026. On the same day ENISA launched its Single Reporting Platform, through which every notification goes.

The principle is to report only once. The manufacturer files its notification on the platform, which passes it to the CSIRT designated as coordinator in the member state of its main establishment and makes it simultaneously available to ENISA. The CSIRT then disseminates the information to the other member states concerned.

A decisive point that is often missed: article 69 explicitly departs from the general timetable. The obligations in article 14 apply to all products within the scope of the regulation, including those placed on the market before 11 December 2027. There is therefore no grandfather clause for reporting: the application you released three years ago is covered just as much as a new one.

The full timetable, to find your way

The regulation applies in stages, and that staging is what keeps the confusion alive. According to the summary published by the Commission, the milestones are as follows.

• 10 December 2024: entry into force of the regulation.
• 11 June 2026: application of the chapter on notification of conformity assessment bodies.
• 11 September 2026: application of the article 14 reporting obligations for manufacturers.
• 11 December 2027: full application, with the essential cybersecurity requirements, manufacturer obligations and CE marking, as well as reporting for open-source software stewards.

In the meantime, on 27 July 2026 the Commission published non-binding guidance on applying the text. It covers scope, remote data processing solutions, free and open-source software, the notion of substantial modification, the support period and reporting, and includes 67 practical examples designed for micro, small and medium-sized enterprises.

Am I a manufacturer? Scope is where everything is decided

The regulation covers products with digital elements made available on the market whose intended or reasonably foreseeable use includes a direct or indirect data connection to a device or network. A product with digital elements is defined as a software or hardware product and its remote data processing solutions.

Everything hinges on that last notion. A remote data processing solution is processing designed and developed by the manufacturer or under its responsibility, the absence of which would prevent the product from performing one of its functions. The recitals specify that cloud solutions only fall under the regulation if they meet that definition, and that websites which do not support a product’s functionality remain out of scope.

Translated into concrete cases, the picture is fairly clear. Installed software you sell or distribute is in scope. A connected device and the cloud service it needs in order to work are in scope, together. A mobile application published on the stores that relies on an API you built is in scope, and its backend with it. Conversely, a SaaS used only in a browser, with no installed product depending on it, is generally not a product within the meaning of the regulation. Nor is a brochure website.

The manufacturer is the person who develops the product or has it developed and markets it under their own name or trademark, whether for payment, monetisation or free of charge. So the test is not who wrote the code, but who places the product on the market under their name. If an agency builds an application that you publish under your brand, you are the manufacturer. Software built to measure for a single client is more debated: it depends on how it is supplied, and it is exactly the kind of question where the examples in the guidance deserve a read before deciding.

Several categories are excluded because another text already covers them: medical and in vitro diagnostic devices, motor vehicles, civil aviation, marine equipment, and products developed exclusively for national security or defence. Free and open-source software developed outside any commercial activity is not covered, and open-source software stewards only have to report from 11 December 2027.

The deadlines, and what they really require

For an actively exploited vulnerability, article 14 imposes three steps, which the Commission sets out on its reporting page: an early warning without undue delay and at the latest 24 hours after becoming aware of it, a vulnerability notification within 72 hours, then a final report no later than 14 days after a corrective or mitigating measure is available.

You still need to know what an actively exploited vulnerability is. The regulation defines it as a vulnerability for which there is reliable evidence that a malicious actor has exploited it in a system without permission of the system owner. A flaw found in an audit, a security advisory on one of your dependencies or a warning from a researcher does not trigger the obligation on its own. It is evidence of real exploitation that starts the clock.

For a severe incident having an impact on the security of the product, the pattern is similar: early warning within 24 hours, notification within 72 hours, final report within one month. An incident is considered severe if it negatively affects or is capable of negatively affecting the product’s ability to protect the availability, authenticity, integrity or confidentiality of sensitive or important data or functions, or if it has led or is capable of leading to the introduction or execution of malicious code in the product or in a user’s network and information systems.

Finally, reporting to the authorities is not enough. Article 14 also requires the manufacturer to inform the impacted users, and where appropriate all users, of the vulnerability or incident, together with any mitigation or corrective measures to apply. That is a message to prepare in advance, not one to draft in the rush of a Friday evening.

What non-compliance costs

Article 64 sets three tiers. Failing to meet the essential cybersecurity requirements and the obligations in articles 13 and 14, reporting included, carries an administrative fine of up to 15 million euros or, for an undertaking, 2.5% of total worldwide annual turnover for the preceding financial year, whichever is higher. Next comes a tier of 10 million euros or 2% for other obligations, and a tier of 5 million euros or 1% for supplying incorrect information to the authorities.

The text includes an allowance for the smallest organisations, which needs to be read carefully. Microenterprises and small enterprises cannot be fined solely for missing the 24-hour early warning deadline, whether for a vulnerability or an incident. The 72-hour and final report deadlines, informing users and all other obligations apply to them in full. Open-source software stewards, for their part, are not subject to fines under the regulation.

CRA and NIS 2: two logics that add up

Confusing the two texts is common, and understandable since they share the vocabulary of CSIRTs and short deadlines. Their logic is nonetheless different. NIS 2 looks at the entity: your organisation, according to its sector and size, and the security of its own systems. The Cyber Resilience Act looks at the product you place on the market, whatever the size of the company selling it.

Both can therefore apply at the same time to the same company, for different reasons and about different events. A software vendor may fall under no NIS 2 obligation and still have to report an exploited flaw in its application under the CRA. Good practice is to build a single incident management procedure capable of routing to one regime, the other, or both.

What to have in place this week

You do not need a six-month compliance programme to be ready for reporting. You do need a few very concrete things, because 24 hours is short when nobody knows who decides.

First, the inventory. List the products you market under your name and qualify them: in scope, out of scope, to be checked. For those in scope, identify third-party components and dependencies. The software bill of materials will only be required from December 2027, but it is what will let you know within an hour, rather than three days, whether an exploited vulnerability in a library affects you.

Next, the decision chain. Designate who qualifies a vulnerability as actively exploited, who approves the notification and who files it on the ENISA platform, with a deputy for each role. The deadline runs from the moment the manufacturer becomes aware of the exploitation, not from the moment management is available. The platform’s frequently asked questions detail the practical filing arrangements.

Then the templates. Prepare an early warning template, a notification template and a standard message to users. These texts take a calm morning to write, and they save hours on the day they have to go out.

Finally, detection. A reporting obligation without detection capability amounts to knowing nothing, and therefore reporting nothing, until the day someone else does it for you. Usable logging, alerts on abnormal behaviour, monitoring of vulnerabilities in your dependencies: these are the fundamentals we highlighted after the tax data breach, and code analysis tooling can complement them, as we explained about Claude Code Security.

And in December 2027

Reporting is only the vanguard. From 11 December 2027, products in scope will have to meet the essential cybersecurity requirements by design, undergo conformity assessment and carry CE marking. The manufacturer will also have to set a support period during which it handles vulnerabilities, of at least five years unless the product is expected to be in use for less time, and every security update released will have to remain available for at least ten years or for the remainder of the support period, whichever is longer.

For an existing product, that last point often weighs the most: maintaining software for five years means a budget, a maintainable architecture and controlled technical debt. If your application has accumulated years of stacked fixes, a technical debt audit is a good starting point to size the effort before it becomes an obligation.

What we take away from it

The Cyber Resilience Act is no longer a 2027 topic. Since 11 September 2026, a manufacturer who discovers that a flaw in its product is being exploited has 24 hours to raise the alert, including for products sold for years, at the risk of a fine of up to 15 million euros or 2.5% of worldwide turnover.

The first question to settle remains scope. A SaaS used in a browser generally falls outside it, a mobile application or connected device backed by your own backend falls inside. Once that is established, the useful work comes down to four workstreams: inventory, decision chain, notification templates and detection capability.

We support software vendors on these topics as part of our application modernisation projects, from qualifying scope to setting up detection. If you do not yet know whether your products are affected, let’s talk.