Reporting starts 11 September: six things to do this week

What just changed

Manufacturers' reporting obligations for actively exploited vulnerabilities and severe incidents apply from 11 September 2026.[Art. 71(2); Art. 14] 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 and there is one place to send it.

For an actively exploited vulnerability: an early warning within 24 hours of becoming aware, a vulnerability notification within 72 hours, and a final report no later than 14 days after a corrective or mitigating measure is available.[Art. 14(2)]

An incident that hits the security of the product itself follows the same shape. For a severe incident: an early warning within 24 hours, an incident notification within 72 hours, and a final report within one month after the incident notification.[Art. 14(4)]

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 what is live now, 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 most teams assume. An actively exploited vulnerability is one for which there is reliable evidence that malicious code was executed by an actor on a system without the permission of the system owner; a severe incident is one that has an impact on the security of the product.[Art. 3 (definitions); Art. 14(3)] 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.

"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 this week's work is making sure the signal reaches the right person.

Six things to do this 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 components of the product, including a software bill of materials in a commonly used 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 inform impacted users without undue delay, including corrective or mitigating measures they can take.[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 this week

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: it has to exist and be available if an authority asks.

Where the reports go

Notifications are submitted through a single reporting platform established and maintained by ENISA, with national electronic notification end-points operated by the CSIRTs designated as coordinators.[Art. 16] Find out this week how your company gets an account and who holds it. The first time you log in 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 how the company reaches the reporting system.
• Support and sales know who to forward a security report to.

If you want help

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.

Book a scoping call