CRA reporting starts September 11, 2026

The mandatory reporting part of the EU Cyber Resilience Act starts in one month.

It does not reach type-approved cars. It reaches the machinery on either side of that carve-out: tractors, harvesters, construction and industrial equipment, connected devices, robots, and any component a vehicle maker sells that is not only ever a car part.

From September 11, 2026, when you become aware that a vulnerability in one of your products is being actively exploited, you have 24 hours to file an early warning, 72 hours for a fuller notification, and 14 days after a fix exists for a final report. A severe incident affecting the security of the product carries its own version of the same three filings. The rest of what the CRA asks of you, including risk assessment, technical documentation, conformity assessment and CE marking, waits until December 11, 2027.

Fifteen months apart, and the operational duty goes first.

It also reaches backward, which is the part most coverage skips. Article 69 says a product placed on the market before December 2027 is only subject to the CRA if you substantially modify it after that date. Then Article 69(3) opens with "by way of derogation" and names exactly one exception: the reporting duty applies to every in-scope product already on the EU market.

If you have fifteen years of connected machines operating in Europe, that is the population.

So September isn't a product-development deadline. It's an awareness deadline.

The carve-out is narrower than "vehicles"

If a vehicle is type-approved under the EU's general vehicle safety regulation, which covers categories M, N and O (passenger cars, buses, trucks, vans and trailers), the CRA does not apply to it. The Commission's July 2026 guidance says it in one line: vehicles to which those regulations apply are not subject to the CRA. R155 and ISO/SAE 21434 already own that ground. Motorcycles and quadricycles came out as well, through a delegated act in force since November 2025, on the reasoning that R155 had been extended to cover them. Pedal-assist L1e machines stayed in.

Everything else stays in. Agricultural and forestry tractors, their trailers and towed equipment, construction machines, non-road mobile machinery and industrial equipment are not carved out, so they reach the CRA through its general test: a product whose intended or foreseeable use includes a direct or indirect data connection to a device or network.

And the carve-out is written per product, not per company. A component is out only if it is designed and constructed exclusively for integration into an excluded vehicle. The Commission's guidance is direct about both edges of that: a manufacturer selling generic components that go into more than those vehicles is subject to the CRA, and offering a component through channels open to the general public puts it in scope regardless of what the stated intended use says. So the question that decides your scope isn't whether you are an automotive company. It is whether this product is only ever a car part.

A vulnerability report is not automatically a CRA report

The CRA does not ask you to report every vulnerability somebody finds.

Article 3(42) defines an actively exploited vulnerability as one for which there is reliable evidence that a malicious actor has exploited it in a system without permission of the system owner. The clock starts when you become aware of that.

A researcher who finds a flaw in your harvester and reports it responsibly has not started your 24 hours. A researcher who tells you somebody is already using it has.

Which is why September is an awareness problem before it is a reporting problem. Active exploitation is, by definition, something happening outside your engineering organization before anyone inside it knows. Somebody is doing it, and somebody is positioned to notice.

Two routes carry that to you. You find it, or somebody tells you.

Finding it yourself costs less than people assume

An industrial fleet we monitor is covered by a two-person team. Monitoring a deployed product against a known asset base is a different discipline from running a 24/7 IT security operations center: the work is telemetry schema, noise filtering and governance, not the real-time containment you couldn't perform on a machine mid-operation anyway. We wrote about that difference separately, in Continuous Monitoring Isn't 24/7.

That route is yours to build, and it is the only one you control.

The route in isn't required yet. It also isn't a black hole.

Annex I will require you to run a coordinated vulnerability disclosure policy and to publish a contact address for vulnerabilities in your product and in its third-party components. Annex II will require the information shipped with the product to name a single point of contact where vulnerabilities can be reported and where that policy can be found. Both bind December 11, 2027.

The EU did not leave the fifteen months empty. NIS2 makes every Member State designate a CSIRT as coordinator for vulnerability disclosure, acting as a trusted intermediary between the person reporting and the manufacturer, and the CRA's recitals expect vulnerabilities to arrive either directly or through that route, anonymously if the reporter asks for it.

So a researcher has somewhere to go. It just isn't necessarily you.

That is the real cost of waiting, and it isn't a compliance cost.

We have watched it run. A global industrial equipment manufacturer had no coordinated disclosure channel of any kind. A researcher who wanted to report a vulnerability in one of their products couldn't find a route in, and went through CISA to reach the company. Building that channel is part of the work we are doing with them now and is just an extension of similar occurrences we even still see in automotive today. A different shape of the same failure is public: a researcher who reported remote control of traffic light controllers got a legal letter about program limits instead of an engineer, posted the letter, and the response became the story instead of the vulnerability. We wrote that one up in Dear Vulnerable: How may I contact you?.

Awareness arrived both times. It just arrived on somebody else's schedule.

Run that sequence after September 11 and a missing channel does not put you in breach, but the clock still starts and chances are that if you haven't figured out your intake pipeline, then other areas of your vulnerability plumbing likely need work too.

The front door is the cheap part

The CRA does not name security.txt. RFC 9116 does, and it is the cheapest way to be findable: a file at /.well-known/security.txt saying where to send a report and where to read your policy. It is not a standard, since the RFC is published for information rather than as a standards-track document, but it is widely used and researchers and their tooling both look there.

It is usually associated with web applications, because that is where the file sits. RFC 9116 is explicit that a security.txt file may also apply to the products and services provided by the organization publishing it. A researcher taking apart a sprayer, a telehandler or a connected controller finds your corporate domain and reads that file. That is the contact address, done.

The policy behind it is the actual work, and the list is short. A response team spanning security, engineering, legal and communications. A monitored reporting address with a PGP key. A written policy for what happens after a report lands and when disclosure goes public. Tracking tooling, so a report becomes a record instead of a thread in somebody's inbox. Communication templates, so the first reply isn't drafted under pressure.

Then you have 72 hours to describe what you shipped

Getting the report in is the easy half.

The 72-hour notification asks for general information, as available, about the product, the general nature of the vulnerability and of the exploit, and any corrective or mitigating measures, including the ones users can apply themselves. "As available" gives you room to investigate. It does not make thin product knowledge useful, and by the final report your answer is on the record.

There is a second output that most summaries of the September deadline drop. Article 14 also requires you to inform impacted users, and where appropriate all users, of the vulnerability or incident and of the measures they can take to mitigate it. That one is not a filing. That one is public notification. More parts of the same plumbing with information exiting rather than entering.

So when somebody tells you a component in your products is being exploited, the work runs backward into the product. Which products contain it. Which software versions. Which configurations. Which machines in the field. Which users need the mitigation.

This is where it usually breaks, and the break is structural rather than a matter of diligence. Firmware scan output sits in one tool as an uncorrelated dump with no asset tree behind it. Threat analyses sit in documents, and dedicated TARA tooling models one assessment at a time, so an analysis done at feature level cannot be resolved against a firmware finding. Supplier data sits somewhere else again. Each of them can be individually correct and still not answer which machines carry a given component, because nothing in the stack holds that relationship.

The fix is unglamorous. Treat a risk as atomic: likelihood, impact, controls. There is no such thing as a risk type, only a risk origin. A researcher's report, a firmware finding, a CVE and a threat analysis are four origins feeding one kind of unit, and when all four attach to the same asset tree, "which machines carry this" stops being an investigation and becomes a lookup. Tracking assets and the risks attached to them on that model is built and in production use in VSEC today.

Check your own front door

Append /.well-known/security.txt to your own domain and read what comes back. Then try it on a supplier whose component ships inside your machine. You will learn something about your own readiness in about ten seconds, and something about your supply chain in twenty.

Then the harder question. If somebody handed you reliable evidence tonight that one of those components was being actively exploited, how long would it take you to name the machines carrying it?

‍