Today the European Union started a clock most product organisations cannot yet answer. Since 11 September 2026, any manufacturer whose product with digital elements reaches the EU market has 24 hours from becoming aware of an actively exploited vulnerability to file an early warning with a national CSIRT and with ENISA. The Single Reporting Platform that receives those filings was switched on the same day the duty became binding (ENISA, Industrial Cyber, The Register).
We covered the Cyber Resilience Act in general terms earlier this year. Here is the narrower question now that Article 14 is live and the rest of it is not: what the clock measures, who starts it, where the report goes.
The cascade, precisely
For an actively exploited vulnerability in your product, three filings are due. An early warning within 24 hours of awareness. A fuller notification within 72 hours, with an initial assessment and any corrective or mitigating measures already available. A final report within 14 days of such a measure becoming available.
For a severe incident affecting the security of the product, the first two deadlines match and the final report is due within one month of the 72 hour notification. Separately, you must inform impacted users without undue delay, including what they can do to reduce their own exposure (European Commission, Crowell & Moring, Article 14 text).
The part teams keep missing is scope in time. This applies to everything already on the EU market, not only to what you launch next. A control system shipped in 2019 and still supported sits in the same position as one shipped last month.
Awareness is a decision your company makes, and usually has not assigned
The trigger is an actively exploited vulnerability, meaning reliable evidence that a malicious actor exploited it on a system without the owner's permission. A proof of concept is not that. A researcher's disclosure with no evidence of use in the wild is not that. A customer's SOC forwarding you log lines that look like exploitation of your product very likely is.
Nothing in the regulation names the inbox at which your company becomes aware. In practice, awareness arrives at a support engineer, a PSIRT triage analyst, or an account manager with a customer on the phone. If nobody has written down which roles can declare awareness and how they escalate, the 24 hours have been running for most of a working day before anyone with signing authority hears the word vulnerability.
That makes the first hard part of Article 14 a detection and escalation problem rather than a legal one. Counsel can draft the filing. They cannot tell you a field device in a customer's plant started behaving differently on Tuesday.
Where the filing goes is settled in advance, or under pressure
A notification goes to the CSIRT designated as coordinator, and ENISA receives it at the same moment. That CSIRT then disseminates to others in Member States where the product is available (ENISA, Help Net Security).
Which CSIRT that is follows from your main establishment, defined as the Member State where decisions about the cybersecurity of your products are predominantly taken. That is frequently an engineering site rather than a registered office. For a manufacturer with no EU establishment at all, the chain runs through the Member State of the authorised representative, then the importer placing the most products, then the distributor, then the Member State with the most users. Appointing a representative resolves this to one known CSIRT with a known working language, decided before anything goes wrong.
One release valve exists, and it belongs to the regulator rather than to you. A coordinating CSIRT may delay onward dissemination on justified cybersecurity grounds, for instance where a coordinated disclosure is still running and wider circulation would itself create risk. It must tell ENISA, justify it, and say when the notification will go out, under Commission Delegated Regulation (EU) 2026/881. Your own filing deadline is unaffected.
The platform is a browser form
There is no Single Reporting Platform API at this release. ENISA has said automating your internal workflow is your business and that API access may come later, but the submission itself is a person logging in and filling in fields (ENISA FAQ, ENISA AR user manual).
Access runs through EU Login with multi factor authentication. Submissions come from an Assigned Representative acting for the manufacturer, one primary holding the administrative functions plus backups. Validation of a representative by the coordinating CSIRT happens after registration and is not a prerequisite for filing, which is sensible slack in the design. It is not a reason to meet the platform for the first time at hour 20 of 24, with the only credentialled person on a flight.
Half the products people assume are in scope are not
The CRA excludes products already governed by another Union cybersecurity regime. Medical devices under the MDR and IVDR are out. Motor vehicles under the EU type approval framework are out. Civil aviation products certified under the EASA regulation are out.
The exclusion is narrower than it sounds. The same component sold separately, outside the regime covering the finished product, is back in scope. A module that is part of a certified device once your customer integrates it is a product with digital elements when you sell it alone.
Exclusion as a product manufacturer is also not exclusion as an operator. A device maker running its own plants can be an essential or important entity under NIS2, with its own clocks to different authorities. One event can start more than one, and building separate functions to serve each is how organisations miss both.
What non-compliance is worth
Article 14 sits in the top penalty tier beside the essential requirements, with Member State fines of up to 15 million euro or 2.5 percent of worldwide annual turnover, whichever is higher (Freshfields, The Register). The rest of the regulation, conformity assessment and CE marking included, applies from 11 December 2027. Reporting came first because it required no product changes, only an organisation capable of noticing and saying so.
What to do in the next two weeks
- Write down whether you are in scope, and why. One page per product line, naming the exclusion you rely on if you claim one. An assumption never written down has never been checked.
- Name the awareness trigger. Which roles can declare the company aware, what evidence counts as reliable, and how it reaches the filer. Require a time stamp on the first record.
- Register on the platform now, with more than one person. A primary representative and at least two backups who have each logged in once.
- Fix your coordinating CSIRT before you need it. Establish where cybersecurity decisions for each product line are actually taken, and if you sit outside the EU, settle the representative question.
- Draft the early warning as a template. It is short by design. Pre agreeing the fields keeps the argument about wording out of the hours where wording is not the priority.
- Rehearse it once. Take a real vulnerability from your own history, run it through the awareness decision, and time how long it takes to reach someone who could file.
- Connect detection to the obligation. The trigger is evidence of exploitation in the field, meaning telemetry from deployed products and customer environments, not just your build pipeline.
Where MBCTG fits
The duty rests on something most manufacturers do not have, which is timely evidence of what their products are doing after they leave the factory. Continuous monitoring across plant and product networks, the core of our OT security services, turns a customer's vague report into the reliable evidence the regulation asks about, inside 24 hours rather than after a week of email.
The escalation path matters as much as the detection. Our 24/7 SOC compresses the distance between an analyst seeing something and a decision maker knowing about it, which is exactly the interval Article 14 now prices. Mapping scope, naming the awareness trigger, fixing the coordinating CSIRT and keeping the evidence a regulator will ask for is compliance and GRC work, and it takes days rather than quarters when it starts before the first qualifying event.
If you sell connected products into the EU and cannot say who files the early warning on a Sunday, talk to an MBCTG expert. That gap is cheaper to close now than to explain later.
