The reporting duty has started: six things to do in a week

Written before the duty applied and updated on the day it did. Nothing in the law changed with the date; what changed is that the deadlines below are now live ones. An earlier revision widened the second duty and the products the duty reaches — both are in the text as it now stands.

What applies now

Manufacturers' reporting obligations for actively exploited vulnerabilities and severe incidents apply from 11 September 2026.[Art. 71(2); Art. 14] That date has passed. If you make a product the Act covers, this is a duty you owe today, not one to put in the next planning round — and the first time it matters you will be working to a clock that started before you read the email.

A manufacturer must report an actively exploited vulnerability in its product, and any severe incident having an impact on the security of the product, simultaneously to the CSIRT designated as coordinator and to ENISA.[Art. 14(1), 14(3)]

The clocks are short. The first two filings are due without undue delay and in any event within the outer deadline — the hour figures are backstops, not an allowance to wait. For an actively exploited vulnerability: an early warning without undue delay and in any event within 24 hours of becoming aware, a vulnerability notification without undue delay and in any event within 72 hours, and a final report no later than 14 days after a corrective or mitigating measure is available.[Art. 14(2)]

A severe incident affecting the security of the product is a second duty, with its own test and its own last deadline. It does not have to be an attack: a failed update that takes out something essential, or a fault that lets one customer read another's data, meets the test just as an intrusion does — the law only asks you to say, in the first message, whether you suspect somebody did it deliberately.

An incident that has an impact on the security of the product counts as severe, and so has to be reported, if either of two things is true: it harms, or is capable of harming, the product's ability to protect the availability, authenticity, integrity or confidentiality of sensitive or important data or functions; or it has led, or is capable of leading, to malicious code being introduced or run in the product or in a user's own systems. Either limb on its own is enough, and "capable of" is enough — the duty does not wait for harm that has already happened. This test is for severe incidents only; it never applies to the vulnerability side.[Art. 14(5)] For a severe incident the first two filings carry the same two-part standard: an early warning without undue delay and in any event within 24 hours of becoming aware, and an incident notification without undue delay and in any event within 72 hours. The final report is due within one month after the incident notification is submitted — the month runs from the filing, not from the 72-hour deadline.[Art. 14(4)]

It also covers what you have already sold. The duty is not limited to products you ship from now on: it reaches every product in scope you have ever put on the EU market, whether or not you still support it. That is the part most people get wrong, and it is usually the part that turns a comfortable answer into an uncomfortable one.

Products placed on the market before 11 December 2027 fall under the essential requirements only if they are substantially modified from that date onwards, but the Article 14 reporting obligations are expressly carved out of that relief and apply to every product in scope that was placed on the market before then. From 11 September 2026 the reporting duty therefore covers a manufacturer's whole installed base, not only what it sells from now on.[Art. 69(2), 69(3)]

The rest of the law comes later. The main obligations of the Cyber Resilience Act (essential requirements, technical documentation, conformity assessment, CE marking, importer and distributor duties) apply from 11 December 2027.[Art. 71(2)] This post is only about the part that already applies, and what you can put in place in a week without starting a project.

"Aware" is earlier than you think

The clock starts when you become aware, not when you finish working out what happened. Two things follow.

The trigger is narrower than a security advisory, and wider than "malware". A vulnerability is actively exploited when there is reliable evidence that a malicious actor has exploited it in a system without the system owner's permission. Nothing has to run for that to be true: an authentication bypass, reaching another customer's data, or the use of stolen credentials where a weakness in the product let the attacker obtain or use them, all count, so the 24-hour clock can already be running where no malicious code was involved.[Art. 3(42)] A newly published weakness in a library you use is not, on its own, something to report; it is something to fix. A component of yours turning up on a public list of weaknesses under attack, or a credible report that your product is being attacked, is the event — and so is somebody walking past a login, or reading another customer's data, with nothing installed and nothing run.

"Aware" means the company, not the person. If your support desk reads a customer email describing an attack on Tuesday and nobody who owns reporting hears about it until Friday, the clock did not wait. Most of the work below is making sure the signal reaches the right person.

Six things to do in a week

1. Find out what you ship

You cannot learn that a component you ship is under attack unless you know that you ship it. If nothing produces a list of the software components in each supported release, produce one now. A common tool run against your build output gives you the file in minutes; putting it in your build system is an afternoon. Manufacturers must identify and document the vulnerabilities and the components contained in the product, including by drawing up a software bill of materials in a commonly used and machine-readable format covering at least the top-level dependencies.[Annex I, Part II, point 1] Hand-written lists do not count, because they are wrong by the next release.

2. Watch the right sources

Match that list against vulnerability data, and make sure the match includes the lists of weaknesses attackers are known to be using, not just severity scores. A frightening score with nobody exploiting it is a job for the queue. A middling score on the under-attack list is a reporting event. Free tools do this. The point is that somebody looks at the output every working day.

3. Name the owner and a deputy

Write down who decides whether an event has to be reported and who sends it. One name, one deputy, phone numbers, and a rule that either can act. If today's answer is "the CTO, probably", this step is not done. Put the same names in your public security contact so outsiders reach the right person first time.

4. Write the first-day plan

One page. When a signal arrives: who is told and how fast; what the owner checks (is it in a release we ship, can it be reached, is there a fix); what the first message says; who sends it and where; what goes in the log. That first message is short by design and goes out before the analysis is finished. Draft it now, with blanks, so nobody writes it from scratch under pressure.

5. Draft the message to your customers

The authorities are not your only audience. After becoming aware of an actively exploited vulnerability or a severe incident, the manufacturer must tell the users it affects — and where appropriate all users — about it, and where needed about the steps they can take to limit the damage, in a machine-readable form where that is appropriate. There is no fixed deadline: the standard is that it is done in a timely manner, and if the manufacturer does not, the CSIRT may tell users itself.[Art. 14(8)] Write the customer version now, next to the first one: what is affected, what to do, where the fix will appear. Decide who signs it and how it goes out. Support will be asked before your analysis is finished.

6. Rehearse it once

Take an afternoon. Pick a real component from your list, pretend it appeared on an under-attack list this morning, and run your plan with the people who would really be in the room. Every gap you find in the rehearsal is one you will not find during a real event. Keep the notes: they are evidence that your process exists.

What you do not need yet

You do not need finished paperwork, a signed declaration, an assessment or a CE mark — those belong to the later date. You do not need a security operations centre. You do not need to report weaknesses nobody is exploiting. And you do not need to publish your component list. The main obligations of the Cyber Resilience Act (essential requirements, technical documentation, conformity assessment, CE marking, importer and distributor duties) apply from 11 December 2027.[Art. 71(2)] From then it has to exist and be produced if an authority asks; before then it is simply the thing that makes the reporting duty workable, which is why it is step 1 here rather than a job for later.

Where the reports go

Notifications are submitted through a single reporting platform established by ENISA and run day to day by it, using electronic notification end-points that Member States and ENISA put in place. Two things a manufacturer should know: the reporting duty in Article 14 applies from 11 September 2026, but Article 16, which sets the platform up, is not among the provisions brought forward, so on the face of the text it applies from 11 December 2027; and we have not established whether the platform and the national end-points are operating today. The duty and its deadlines start regardless — where to file in practice is a question for the manufacturer's national CSIRT coordinator.[Art. 16(1); Art. 71(2)] A notification goes to the CSIRT designated as coordinator in the Member State of the manufacturer's main establishment in the Union, and reaches ENISA at the same time. Main establishment means where the decisions about the cybersecurity of the products are mostly taken — not where the company is registered; if that cannot be worked out, it is where the manufacturer has most of its Union employees. A manufacturer with no main establishment in the Union follows a set order: the Member State of its authorised representative, then of its importer, then of its distributor, then where most of its users are.[Art. 14(7)]

So this is one email, not a project: work out which coordinator is yours, ask them how they want to receive a report, and write the answer down where the person on duty will find it. The first time you go looking should not be the day it happens.

The checklist

• Something produces a component list for every supported release, from the build rather than by hand.
• That list is matched daily against vulnerability data, including the lists of weaknesses under attack.
• A named owner and deputy exist, with contact details, and the same contact is published where outsiders can find it.
• A one-page first-day plan exists, with the first message pre-drafted.
• A customer message exists, with an owner and a channel.
• One rehearsal has been run and the notes are kept.
• Someone knows which national coordinator is yours and how they want to be sent a report.
• Support and sales know who to forward a security report to.

If you want help

If you are not certain the Act reaches what you make, settle that first: our scope check takes eight short steps about your product and tells you whether the Cyber Resilience Act applies to it, free, in about two minutes. It is the same set of tests the Regulation uses, and where it cannot conclude it names the fact that would settle it. It is a form and not an inspection, so the answer is on the facts you give it, and it is our engineering reading of the law rather than a legal ruling.

Everything above is meant to be done without us, and a determined team can do it in a week. If you would rather not, the core of our sprint is this list done properly: the component list coming out of your build, the policy published, the owner named, the plan written and rehearsed once. If you want step 2 done as well, we will choose a monitoring tool with you, set it up in an account you own and point the alerts at your own people — then hand over the keys. We do not watch it for you and we are not sent your alerts, because you are the manufacturer and the judgement is yours. Almost all of it happens in writing, at whatever pace your week allows; our job is to make the decision an easy one to take on time.

Where this sits in the rest of the law: when a weakness is being exploited, or something goes badly wrong, in our plain-English explainer.

Run the free check