CRA reporting starts 11 September 2026 for products you have already sold

Some EU Cyber Resilience Act guidance treats every manufacturer as if the answer is to re-architect the product urgently. For industrial devices operating inside larger systems, that is usually not true. The rules apply. The re-architecture usually does not. 

The EU CRA full requirements apply from 11 December 2027. Most industrial manufacturers we talk to know this date. Fewer have noticed that Article 14 starts fifteen months earlier, on 11 September 2026. Under Article 69(3), Article 14 applies to products already placed on the EU market before the full regulation applies. 

The CRA is often described as a new-product problem. For most industrial manufacturers with long product lifecycles, it is an installed-base problem first. 

Your installed base is every product you have shipped that is still in use somewhere in the EU. For an industrial manufacturer, that population is usually much larger than what you will ship this quarter. 

What Article 14 requires from 11 September 2026 

From 11 September 2026, manufacturers must report two categories of event: actively exploited vulnerabilities, and severe cybersecurity incidents that affect product security. Each category has its own reporting steps. 

For actively exploited vulnerabilities: 

• 24 hours: an early warning to the CSIRT designated as coordinator for the manufacturer’s main establishment. The notification is made simultaneously available to ENISA. One submission, not two. 

• 72 hours: a fuller notification with an initial assessment 

• 14 days after a corrective or mitigating measure is available: a final report 

For severe incidents: 

• 24 hours: an early warning 

• 72 hours: a fuller notification 

• One month after the 72-hour notification: a final report

Reporting goes through the ENISA Single Reporting Platform. Status as of 25 August 2026: ENISA has published the SRP factsheet, FAQ, and user guidance for Assigned Representatives (registration, notification submission, interface functions). The platform itself becomes operational on 11 September 2026. Manufacturers cannot yet test the full workflow, but they can read the guidance and rehearse a report on paper against the documented field list. 

Article 14 also requires manufacturers to notify affected users about the vulnerability or incident, and where appropriate the corrective measures. This is a legal obligation, not good practice. 

Article 14 is written to apply going forward. What you become aware of on or after 11 September 2026 falls under the reporting duty. Pre-existing knowledge is not automatically pulled in by the date. 

What happens if you miss a deadline 

Fines are the headline penalty: up to €15 million or 2.5% of worldwide turnover, whichever is higher, under Article 64(2), with national market surveillance authorities setting the actual amounts case by case. But the fines are not the reason this matters. 

The less visible risks matter more: 

• Every notification you file becomes a record on the CSIRT and ENISA  

• A notification of a vulnerability you cannot fix creates a documented finding while your customers are still using the product 

The last point turns the conversation from paperwork to customer relationship. 

Your real problem is the products you have already shipped 

For a new product in development, CRA compliance is a design and documentation problem. You make the architecture decisions once. You include the requirements from the start. You ship the product with a completed EU CRA Declaration of Conformity behind you.  

For products already in use, the shape of the problem is different. What has to work from 11 September is not the secure-by-design status of the product. It is your ability to detect, classify, report, and remediate a vulnerability across a product portfolio that shipped years ago. Different product generations may have different architectures. Different technical documentation. Different customer commitments. 

If you make drives, HVAC controllers, or connected industrial equipment, your installed base is usually much larger than a quarter of new shipments. Article 14 applies to all of it. 

Four questions about your own product 

The 24-hour, 72-hour, and 14-day clocks look manageable on paper. In practice, they are four engineering capabilities. 

1. Would you know? The 24-hour clock starts when you become aware of an actively exploited vulnerability. To become aware in a device you shipped in 2017, you need field telemetry or logs that could show exploitation. You also need a way to link a published CVE to the components inside your deployed firmware image. Most industrial devices do not produce security-relevant logs, and they do not store history. For many manufacturers, the honest answer is: we would not become aware, and if a customer told us, we could not confirm it. 
2. Could you scope it? The 72-hour notification asks which products and which versions are affected. If your fleet has no unique per-device identity and no reliable version reporting, you cannot scope the exposure. You will either report too many products and alarm every customer, or report too few and give a regulator wrong information. On legacy embedded platforms, even the SBOM often has to be built by hand. Off-the-shelf tooling does not always work for older toolchains and firmware images. 
3. Could you build a fix? The 14-day clock starts when a corrective measure is available. For a 2016 product family, “available” means the build chain still works. Is the toolchain archived? Is the build reproducible? Do you hold the signing keys? Does the device accept a signed update at all?  
4. Could you deliver it to the field? Even if the fix exists, delivery is a separate problem. Does the field procedure require a technician with a laptop and a serial cable? Can you update the device over the air? Can you roll back a bad image without breaking a fleet of devices? 

The Article 14 rule that changes the conversation 

Article 14 does not require you to fix the problem. It requires you to tell an EU authority, and your customers, that you found it. 

If you cannot deliver a fix, you have created a documented finding with an EU authority that a product you shipped has a security problem. That is not a paperwork problem. It is a market access and customer relationship problem. Your customers then choose what to do. Some accept the risk. Some replace the product. Some wait for a fix. Where you sit in that conversation depends on whether you can offer one. 

The trap is not the patch. It is the architecture you build to deliver it. 

Under Article 69(2), legacy products become subject to the full CRA requirements if they are substantially modified after 11 December 2027. The Commission’s guidance from 27 July 2026 is clear that security updates are generally not substantial modifications. Patching input validation, fixing an authentication flaw, disabling unused ports, rotating a deprecated crypto algorithm. All safe. Most CRA compliance work does not require you to re-architect the product. 

The exception is where a security fix changes the product’s intended purpose, alters data flows, changes its boundaries, or adds new externally reachable interfaces. That is where the trap sits for legacy platforms. 

Fixing the vulnerability is not the risk. Building the ability to fix it might be. If your answer to “could you deliver it to the field?” is to add remote update capability to a product line that never had one, you are adding an externally reachable interface and changing the product’s data flows. The architecture you build to deliver that update is a different question.

The security patch is safe. The architecture you build to deliver it is a design decision with market-access consequences. 

If you have IEC 62443 work already 

Most of the CRA essential requirements map across from IEC 62443. The standard covers most of the substantive security requirements in CRA Annex I Part I. It covers fewer of the vulnerability-handling and reporting requirements in Part II. If your product line has IEC 62443 documentation and processes in place, the remaining gap is smaller than it looks. 

The other clock: a decade-scale support obligation

Article 13(8) sets a minimum five-year support period for products placed on the EU market from December 2027, and requires longer where the product is reasonably expected to be in use longer. For equipment with 7 to 20 year field lifecycles, that is a decade-scale sustaining-engineering commitment covering security updates, technical documentation, EU Declaration of Conformity maintenance, and user instructions. Most industrial manufacturers have not planned for this yet. Worth asking now: which product families would you commit to supporting under Article 13 conditions, and which would you phase out before December 2027? 

What to do now 

Short and sequenced. 

1. Inventory what is on the EU market. For each product family, name the legal entity that acts as the manufacturer under CRA. 
2. Name two people. A process owner for Article 14 reports and a deputy. Set up EU Login accounts for both now. 
3. Register with your national CSIRT. ENISA’s guidance states that CSIRT validation of a registration is not a prerequisite for meeting the reporting obligation. 
4. Rehearse one report on paper. Use a real product family and ENISA’s published field list. Time yourselves. 
5. Ask the harder question separately. Could you actually ship a fix to that product family within the 14-day corrective-measure window? That answer takes months, not weeks, to change. 

Four of these are process work. Any competent consultancy can help. The fifth is engineering work on the actual device: whether you can build a fix, deliver it to the field, and prove which units received it. That is where Proekspert comes in. 

How we help 

We work on connected industrial devices that operate inside larger systems: drives, HVAC, weighing, process control. Not consumer electronics. The engineering that makes items like “could you build a fix” and “could you deliver it to the field” answerable: secure firmware update paths, device identity and versioning, IEC 62443 documentation, and CRA-readiness delivery for legacy platforms. 

We supported Danfoss Drives in achieving IEC 62443 Security Level 1 readiness on the VLT® platform and MCT10 configuration tool, without hardware redesign. The TÜV SÜD audit passed with no major issues. 

“Their team supported risk analysis and certification feasibility on legacy platforms, working closely with us to balance compliance, usability, and real customer needs. Their hands-on experts ensured our products are fit for today’s market and tomorrow’s regulations.” 

Tim Flintholm Fink, Product Owner, HVAC and Aqua Drives, Danfoss Drives 

We also supported BLH Nobel with CRA compliance analysis on a long-lived industrial weighing device deployed in cranes, mining, and process industries. Same conclusion: CRA and CE-marking alignment achievable through targeted software upgrades. No hardware redesign. 

The same engineers who find these gaps build the software that closes them. That is the difference between assessing CRA readiness and delivering it. 

Challenge us!

Bring one real product line. Tell us the product family, roughly how many units are in the field, and who owns the firmware. Our engineers will review what Article 14 actually means for that specific product and come back with a first read. 

This is for manufacturers placing connected products on the EU market. Get in touch through our CRA service page or by email at jukka.halttunen@proekspert.com. 

About Proekspert

Proekspert is a European industrial software engineering partner with over 30 years of experience building mission-critical systems for manufacturers and OEMs. We modernize legacy systems, develop secure connected products, and deliver cybersecurity compliance — including IEC 62443 and the EU Cyber Resilience Act. Our expertise spans embedded software, device-to-cloud integration, industrial AI, and cybersecurity for regulated sectors.