The Cyber Resilience Act starts reporting in September, repairing only in 2027

On 11 September 2026 a single article of the Cyber Resilience Act takes effect: Article 14, the reporting duty. Anyone who sells a product with digital elements under their own name must from that day report within 24 hours when a vulnerability in it is actively exploited.

Everything else people think of first with the Cyber Resilience Act does not yet apply on that day: no CE marking, no bill of materials for the software inside, no defined support period, no market surveillance. That comes on 11 December 2027.

This order sounds like relief. It is the opposite, and the reason sits in Article 69.

The misreading: "the CRA only applies from 2027"

The Regulation explicitly exempts legacy products. What was placed on the market before 11 December 2027 does not have to meet the security requirements, as long as it is not substantially modified. That is Article 69(2).

Paragraph 3 of the same article makes one exception, and it is the decisive one: the reporting obligations under Article 14 apply to all products within scope, including those placed on the market before 11 December 2027.

The guidance the European Commission published on 27 July 2026 draws the consequence plainly: the reporting obligation continues to apply even after a product is no longer supported. For such a product the manufacturer must report, but is not required to handle the vulnerability under Annex I.

In its answers to frequently asked questions the Commission even describes why that often would no longer be possible: tooling to scan or run old software versions may no longer exist, build environments for old code may be impossible to recreate, dependencies may be unavailable, and staff with knowledge of the old codebase may have left. And still, in its own words: for such products, manufacturers are required to notify the vulnerability or incident.

In short: from September you must report within 24 hours about products you no longer have to maintain, can no longer build and in part no longer sell. The duty to report arrives fifteen months before the duty to be secure, and it covers precisely the stock the security duty spares.

Anyone setting their timetable by "from 2027" plans away the one date that already counts in 2026.

And the relief that is just as little known

Nothing has to be reported retroactively. The guidance says explicitly that the Regulation does not require retroactive reporting: what the manufacturer knew to be actively exploited before 11 September 2026 stays out.

The catch is practical. If someone knew about the vulnerability but not about its exploitation, and learns of the exploitation afterwards, the duty applies. To use the relief you therefore need a documented state of knowledge as at 10 September. A note recording what you knew that day costs an hour and may be the only thing that counts.

Are we in scope at all?

The question can be answered in three steps, and the order matters.

First: do we place a product with digital elements on the market? Software or hardware, made available on the market, whose purpose or foreseeable use includes a data connection. The connection may be direct or indirect, and it need not be permanent: software that only goes online to update or to exchange data is covered too. In practice little is left that has no connection at all. What is built purely for own use falls outside. The Commission makes that clear in its answers: a tool a company builds for itself is not placed on the market, as long as it is not distributed as a product of its own.

Second: is our name on it? A manufacturer is anyone who develops a product or has it developed and markets it under their own name or trademark, whether for payment or free of charge. The own name is the criterion, not the own programming work. Anyone assembling third-party components into a device and shipping it under their own brand is the manufacturer of the whole product, as the guidance states expressly.

Third: do we substantially modify third-party products and pass them on? Then you count as the manufacturer of the modified part. Both conditions must come together. Modifying for your own use is not enough.

Anyone answering all three with no is not subject to the reporting duty. That covers the vast majority of companies that use IT rather than sell it.

Who nevertheless falls in: machine and plant builders with their own control software. Anyone offering an app that is installed on a device. Anyone reselling devices under their own brand. All three rarely think of a cybersecurity regulation first, and all three carry products from before 2027 in their stock.

And who does not fall in, although it seems close: anyone running a pure web service, a customer portal say, or an application that only runs in the browser. Such services do not fall under the Cyber Resilience Act, per recital 12. The Regulation names a website as the counter-example expressly.

The recital points to NIS2 for cloud services. That does not mean an obligation automatically arises there: NIS2 only bites if the operator itself falls into one of the covered sectors and meets the size thresholds. Anyone doing neither is subject to neither reporting duty.

The line runs where a service becomes part of a product. If a cloud function remotely controls a device, and without it the device could not perform one of its functions, that function is part of the product and falls in with it. A portal that only displays data does not.

What a systems integrator does, and what it does not

For the case where a service provider is involved, the Commission has included an example in its guidance that draws the line.

Anyone providing technical assistance related to software not under their responsibility is not placing that software on the market, as long as they do not substantially modify it. The example given: a service provider does not publish the software but helps a customer install it on the customer's own server, without substantially modifying it. It is therefore not considered to be placing the software on the market.

In practice that means:

• Installing, configuring, operating, monitoring, training and patching are services. No placing on the market, no manufacturer duty.
• Substantially modifying and passing on makes you the manufacturer of the modified part.
• Building your own product and shipping it under your own name makes you the manufacturer of the whole.

The expectation that "tailor-made" exempts you from the Regulation does not hold either. The special status only allows two individual requirements to be varied by contract: the secure default configuration and the free security updates. And standard software sold to many customers and lightly adapted along the way is, in the Commission's express words, not tailor-made.

What must be reported, and what must not

There are two triggers, not one. The second is regularly overlooked.

The first is the actively exploited vulnerability. Actively exploited means there is reliable evidence that a malicious actor has exploited it in a system without the system owner's consent. A finding from a commissioned penetration test without such evidence is not an actively exploited vulnerability. The same goes for a finding from a bounty programme. Both may be reported voluntarily, but need not be.

The second is the severe security incident affecting the security of the product. What is meant is something other than a flaw in the product: it is about your own development, production or maintenance processes. The textbook case from the recitals is an attacker who successfully injects malicious code into the channel through which the manufacturer ships its security updates.

On supplier components: if the exploited vulnerability sits in a bought-in component, the manufacturer of the end product reports, and the component manufacturer as well, provided the component was placed on the market in its own right. If the vulnerability is not exploitable in your product at all, because the affected code cannot be reached there, the reporting duty falls away. The report to the supplier is unaffected.

When the clock starts

The guidance of July 2026 answers the question that was open before: knowledge exists when, after an immediate initial assessment, there is a reasonable degree of certainty that a vulnerability in your own product is being actively exploited, or that a severe incident has compromised the security of your product.

The emphasis is on immediate. The clock cannot be stopped by leaving the assessment lying around.

Three stages then apply:

• Early warning within 24 hours. It is short. Required are manufacturer, product, title and, where known, the Member States in which the product was made available.
• Notification within 72 hours. Now the nature of the exploitation, the nature of the vulnerability, measures taken, recommendations for users and a sensitivity assessment are added.
• Final report. For a vulnerability at the latest 14 days after a remedy becomes available. For an incident within one month of the 72-hour notification.

The difference at the last stage is easy to miss: for vulnerabilities the period runs from availability of the fix, for incidents from the preceding notification.

There is also a duty without a deadline that still needs preparing: the manufacturer must inform the affected users. That is not a duty to publish; the guidance makes clear the information may be limited to the affected customers.

Where reports go, and why the BSI portal is not the route

The report goes to two places at the same time: to the CSIRT designated as coordinator and to ENISA. For manufacturers with their main establishment in Germany the CSIRT is the BSI.

The route there, however, is not the familiar BSI reporting portal. That is the portal for NIS2. For the Cyber Resilience Act, ENISA is building a platform of its own through which all reports run, and whose national endpoints the CSIRTs operate.

Three things about it worth knowing before September:

• The platform is meant to be operational by 11 September. Its public address had not been published at the beginning of August.
• Reports are filed through designated representatives with an EU Login account. That account can be created in advance at any time.
• ENISA expressly advises against registering on the platform as a precaution, so as not to overload the CSIRTs' validation work. Only in the reporting case.
• There will be no interface for automated reporting at launch. Anyone with many products needs people for this, not a connection.

NIS2 and the CRA are two duties, not one

Both require reports, and both work with 24 and 72 hours. But they address different parties and run through separate routes.

NIS2 covers entities in certain sectors above a certain size and asks about significant disruption to service provision. The CRA covers manufacturers and asks about the security of a product. In Germany NIS2 is reported to the joint reporting office of the BSI and the BBK, the CRA to the ENISA platform.

There is no set-off rule. The Regulation merely suggests that Member States consider single entry points. That is a recommendation, not a requirement.

In practice the two overlap in exactly one case: a company is both a NIS2 entity and a manufacturer, and one incident hits both. A compromised update route, for instance, disrupts your own operations and impairs product security. Then you report twice, through two channels, with partly different final deadlines.

For everyone else: an exploited flaw in your own product without disruption to your own operations is a pure CRA case. A ransomware attack on the administrative IT with no product involvement is a pure NIS2 case.

What about the fines

The range is high: up to 15 million euros or 2.5 per cent of worldwide annual turnover, whichever is higher, among other things for infringements of Article 14.

Except that it does not bite in September. The penalties article sits in a chapter that only becomes applicable on 11 December 2027, as does market surveillance. The German draft law accordingly brings the corresponding provisions into force only in 2027 as well.

The duty exists from September nonetheless. Only the apparatus that enforces it is not yet working. Anyone concluding from this that the date can be ignored is confusing two things: that something applies, and that it is enforced.

For micro and small enterprises there is an exception, but a narrower one than often reported: it concerns solely the failure to meet the 24-hour deadline, not the reporting duty itself, and it does not apply to medium-sized enterprises.

What to do before 11 September

• Establish your own role and write it down. The three questions above, answered once for each product. A no belongs on record too, because customers and auditors will ask.
• Draw up a product list, with the countries. In which EU Member States was each product made available? That detail belongs in the 24-hour early warning. Researching it under pressure costs more time than the deadline allows.
• Create EU Login accounts for the people who will report if it comes to that. At least two, with a clear deputising arrangement. Do not register on the platform in advance.
• Introduce an assessment step that records when the clock started. Anyone who does not document the moment certainty arose can later demonstrate neither compliance nor timeliness.
• Set up a point of contact for vulnerability reports. Formally required only in 2027, in practice the route through which you first gain knowledge at all from September onwards.
• Bind suppliers by contract to inform you immediately about active exploitation. Without that you learn too late about something you have to report yourself.
• Record your state of knowledge as at 10 September. See above: the relief for legacy cases only holds if it can be evidenced.

What this means for a company in practice

• If you only use IT: not in scope. It is still worth documenting your role cleanly and putting CRA conformity into your supplier requirements. From late 2027 it becomes visible through the CE marking.
• If you sell a product under your own name: in scope, from September, including for legacy products. The effort until then lies in preparation, not in technology.
• If you adapt or operate software for others: as a rule not a manufacturer. The line runs at the substantial modification that is passed on.
• If you are both, a NIS2 entity and a manufacturer: two reporting routes, prepared separately.

Where we help

We work out with you whether and for which products you are a manufacturer within the meaning of the Regulation, record the result in an evidenced form, and build the reporting route so that it holds the 24 hours. How that interacts with an existing NIS2 obligation we clarify in the same step. A first conversation is on us.

Sources

• Regulation (EU) 2024/2847 (Cyber Resilience Act), in particular Articles 3, 13, 14, 22, 64, 69 and 71
• European Commission, guidance on the application of Regulation (EU) 2024/2847, C(2026) 5252, 27 July 2026
• European Commission, frequently asked questions on the implementation of the Cyber Resilience Act, as at 2 July 2026
• ENISA, Single Reporting Platform, frequently asked questions, as at 3 August 2026
• BSI, Cyber Resilience Act
• Draft German Cyber Resilience Implementation Act, Bundestag printed paper 21/6134

Status: 23 August 2026. The German implementing act is at that point still in the parliamentary process; the first reading was on 11 June 2026. The address of the ENISA reporting platform had not been published at the beginning of August. Before deciding anything in your own organisation, check the current state there.