The Cyber Resilience Act's reporting clock starts today

The EU Cyber Resilience Act's reporting obligations apply from today. This is the first substantive deadline in the regulation — the main body of obligations follows at the end of 2027 — and it is the one with the shortest clock.

what applies now#

Manufacturers of products with digital elements sold in the EU must report, to ENISA and the relevant national CSIRT:

Actively exploited vulnerabilities in their product:

• Early warning within 24 hours of becoming aware.
• Vulnerability notification within 72 hours, with corrective measures taken or planned.
• Final report within 14 days of a corrective measure being available.

Severe incidents affecting the security of the product:

• Early warning within 24 hours.
• Incident notification within 72 hours.
• Final report within one month.

The trigger is actively exploited, not merely discovered. A vulnerability you found yourself and are patching quietly is not in scope. One being used against your users is.

the part that is an engineering problem#

24 hours is short, and the clock starts when you become aware. That makes two things load-bearing that most organisations have never tested.

Can you tell that something is being exploited? Reporting an actively exploited vulnerability requires knowing it is being exploited, which requires detection you either have or do not. Exploitation of a deployed product is frequently discovered by a customer, a researcher, or a vendor — and the path from "a customer mentioned something odd" to "our security team knows" is where the 24 hours goes.

Who is authorised to file? At 2 a.m. on a Sunday, with an active exploit, somebody has to decide that the threshold is met and submit a report to a regulator. If that requires a lawyer who is asleep and a VP who is on a plane, you will miss the window.

Both of those need to be settled in advance, written down, and rehearsed. They are not legal problems; they are incident-response problems with a legal deadline attached.

what to do this week#

1. Determine whether you are a manufacturer under the Act. If you place a product with digital elements on the EU market, you probably are. If you provide a service, the rules differ. This is a legal determination and it should already have been made — if it has not, that is the first task.

2. Write the decision tree. What counts as awareness. Who assesses. Who authorises. What the fallback is when they are unavailable. One page.

3. Pre-register and pre-fill. Know which portal, which national CSIRT, and have the product identifiers, version ranges and contact details ready. Do not be looking those up during the 24 hours.

4. Wire your intake. Every path by which you could learn of exploitation — support, your security contact address, your bug bounty, your CSIRT relationships — needs a route to the person who assesses. Test it by sending something through and timing it.

5. Run the drill. A tabletop exercise with a fictional exploited vulnerability. Time how long it takes to reach a filing decision. That number is your actual capability, and it is usually much worse than people expect the first time.

the open source position, again#

Worth restating because it keeps being misunderstood: an individual maintaining open source outside a commercial activity is not a manufacturer and has no reporting obligation. The duty sits with whoever puts the product on the market.

What will happen anyway is that companies with the obligation start asking their dependencies for security contacts and disclosure policies. Those requests are not legally owed. Publishing a SECURITY.md is a kindness, not a compliance requirement, and no maintainer should be pressured into treating it as one.

If you are the company with the obligation: build the reporting capability yourself, from information that is already public, and fund the projects you depend on. That is the response that actually works.