The Cyber Resilience Act does not apply in full until 11 December 2027. Most teams have filed it accordingly, somewhere in the 2027 column of a roadmap. That filing is now wrong by fifteen months: Article 14, the reporting duty, has applied since 11 September 2026.
It is a narrow obligation and a fast one. If you manufacture a product with digital elements placed on the EU market, and you become aware that a vulnerability in it is being actively exploited, you have 24 hours to submit an early warning. Not a fix, not an analysis — a notification, through the single reporting platform, to the CSIRT designated as coordinator and to ENISA.
Who this lands on, including people who do not think of themselves as manufacturers
The word "manufacturer" reads as hardware, and that reading is the first mistake. A product with digital elements is any software or hardware product, and its remote data processing solutions, placed on the market as a distinct commercial offering. A SaaS platform sold as a product, a mobile application, a firmware image, a library shipped commercially, an embedded controller: all in scope.
Two further cases catch companies by surprise.
You put your name on it. A distributor or importer who markets a product under their own name or trade mark becomes the manufacturer for the purposes of the regulation, with the reporting duty attached.
You modified it substantially. Take an open-source component or a third-party product, change it in a way that affects its security properties, and place the result on the market: the obligations follow the modification.
Open source developed and supplied outside commercial activity stays outside. The boundary is commercial activity, not the licence, and it is thinner than people assume — a maintainer selling support or priority fixes is on the wrong side of it.
The three reports, and the clock on each
The duty is not a single filing. It is a sequence, and each step has its own deadline running from the moment of awareness.
Within 24 hours, the early warning. What the vulnerability is, that it is being exploited, and which member states you believe are affected if you know. This is deliberately thin. It exists so coordinators can start work, not so you can be thorough.
Within 72 hours, the vulnerability notification. General information about the product, the nature of the exploit, and any corrective or mitigating measures taken or available.
Within 14 days of a corrective measure being available, the final report. A description of the vulnerability, its severity and impact, and the fix.
The same shape applies to severe incidents affecting the security of the product, with the same 24-hour early warning and a one-month final report.
Two practical points. The clock starts at awareness, and awareness is an organisational fact, not a decision: a support engineer who sees exploitation in a customer's logs on Friday evening has started it. And the 24-hour report is not conditional on your understanding the vulnerability — you report what you know, then you report again.
What actually fails
We have run this scenario against product teams four times this year, as a tabletop with the clock visible. Nobody missed the deadline because they could not write the report. They missed it, or came close, for the same four reasons.
Nobody owns the trigger. Exploitation is noticed by support, by a customer, by a researcher, by threat intelligence, or by a vendor advisory — five entry points, and in every case the person who noticed it did not know that a 24-hour regulatory clock had just started. This is the single highest-value thing to fix, and it is an afternoon of work: one written rule about what "actively exploited" looks like at your company, and one route from any of the five entry points to the person who can file.
The product inventory is not a regulatory inventory. Firms know what they sell. They do not have a list that answers: which of these are products with digital elements, placed on which markets, under whose name, with which support period declared. That list is what tells you whether a given exploit is reportable at all, and building it under a 24-hour clock is not possible.
The platform account does not exist. Reporting goes through the single reporting platform. An account, the right people on it, and one test submission are not things you arrange at hour three of an incident.
The legal reflex is to wait. The instinct to confirm before notifying is right in almost every other context and wrong here. Twenty-four hours does not accommodate a review cycle. The early warning is designed to be revisable; the deadline is not.
If you have not started
Four days of work, spread over a fortnight, closes the gap:
- A scoping note that names your products with digital elements, their markets, and who the manufacturer is for each. One page per product, not a project.
- One written trigger definition, and a single internal route from any entry point to the filer. Put it where support can see it, not only in the security team's wiki.
- The platform account, provisioned, with two named people and one dry run.
- A tabletop, with the clock. An hour, once. It is where the missing route becomes obvious.
None of this is the December 2027 work: the conformity assessment, the technical documentation, the secure-by-design requirements, the declared support period and the vulnerability handling process. That is a real programme, and it should be planned now. But it is not what is due today. What is due today is a phone call that reaches the right person inside a day, and a form that somebody has already logged into once.
The question worth asking your team this week
Not "are we CRA compliant" — nobody is, and the question has no answer for another year. Ask instead: if a customer emails our support address tonight saying they are being attacked through our product, who files the early warning, and by when?
If the answer takes more than a sentence, that is the gap, and it is the cheapest one in the regulation to close.