EU Cyber Resilience Act: 6 Things Businesses Must Do by Sept 11

The EU Cyber Resilience Act is about to stop being a future problem and become a today problem. On 11 September 2026, the vulnerability and incident reporting obligations kick in, and any company that ships a product with digital elements into the EU is on the hook.

Here is the short version. If a vulnerability in your product is being actively exploited, you have 24 hours to report it. Not a week. Not “after the weekend.” Twenty-four hours. For a lot of engineering teams, that is a genuinely tight clock, and the deadline is days away.

What actually changes on 11 September

From that date, manufacturers must report actively exploited vulnerabilities and severe incidents to ENISA and their national CSIRT through a single platform. The timeline has three stages: an early warning within 24 hours, a fuller notification within 72 hours, and a final report within 14 days after a fix or mitigation is available. Severe incidents follow a similar path, with the final report due within one month.

The reporting runs through ENISA’s new Single Reporting Platform, which is scheduled to go live the very same day the obligations start. You file once, addressed to the CSIRT where your main establishment sits, and the information reaches ENISA at the same time.

Who this actually covers

Let me be direct: this is broader than most people assume. It is not just IoT gadgets. It covers software, connected devices, operating systems, networking gear, OT systems, medical equipment, and embedded systems. If it has digital elements and it lands in the EU market, it likely counts.

Two details catch companies off guard. First, it applies even to legacy products shipped years ago, not only new releases. Second, it does not care where your headquarters is. A software firm in Lahore, Dubai, or Austin selling into the EU carries the same obligations as one in Berlin.

Why 24 hours is the hard part

The 72-hour and 14-day steps are manageable with a decent process. The 24-hour early warning is where teams stumble. To hit it, you need to know within hours that something is being exploited, decide fast that it qualifies as reportable, and have someone authorized and ready to file. That is a monitoring problem, a decision problem, and a staffing problem all at once.

Most breaches are not discovered at 10am on a Tuesday. They surface at 2am on a holiday weekend. A 24-hour clock that starts whenever you become aware means your on-call and escalation paths have to work around the clock, not just in office hours.

The legacy product trap

So yeah, that product you shipped in 2021 and mostly forgot about still counts if it is on the EU market. Plenty of companies have no complete inventory of what they have sold, what components those products contain, or which are still in use. The Act quietly forces a reckoning: you cannot report a vulnerability in a product you have lost track of.

End-of-life dependencies make this worse. If your device relies on a library that no longer gets security updates, you are carrying risk you may not even be reporting on. Now is the time to map it.

The penalties are not a rounding error

Let me be direct about the stakes. The Cyber Resilience Act is not a voluntary code of conduct. Serious non-compliance can draw fines reaching into the tens of millions of euros or a percentage of global annual turnover, whichever is higher. Even setting the top-line numbers aside, market surveillance authorities can order a non-compliant product pulled from the EU market entirely. Losing access to the single market is often scarier than the fine itself.

Reporting failures sit in their own category. Miss the 24-hour window on an actively exploited flaw, and you are not just carrying a security problem, you are carrying a regulatory one on top of it. Regulators tend to treat a hidden, unreported breach far more harshly than an honest, timely disclosure.

Why your software bill of materials matters now

The quiet hero of CRA readiness is the software bill of materials, or SBOM. You cannot report on vulnerabilities in components you cannot see, and modern products are built from hundreds of open-source and third-party pieces. An SBOM is simply a complete list of what is inside each product, and it turns “we think we might use that library” into a definite yes or no when a new vulnerability lands.

Teams that already maintain an SBOM will find CRA reporting far less painful, because when a flaw hits a popular library they can instantly tell which of their products are affected. Teams without one will spend the first hours of every incident just trying to figure out whether they are exposed, and those are hours the 24-hour clock does not give back.

What to put in place before the deadline

You will not build a perfect program in a few days, but you can cover the essentials. Name the person and the backup who can file a report at 3am. Register early with your national CSIRT and get familiar with the Single Reporting Platform now, not during an incident. Write a one-page decision rule for what counts as “actively exploited.” And pull together a rough inventory of your EU-facing products and their key components.

Then rehearse. A single tabletop exercise, where someone pretends a vulnerability is being exploited and the team practices filing within 24 hours, will surface more gaps than any policy document.

How the CRA fits the wider EU rulebook

The Cyber Resilience Act does not live alone. It sits alongside the NIS2 Directive, which governs how essential and important organisations manage security, and the AI Act, which regulates high-risk AI systems. A single company can easily fall under all three at once, with overlapping reporting duties and different authorities to answer to. The good news is that the underlying discipline is the same: know your assets, monitor for trouble, and report quickly through the right channel.

Treating CRA readiness as a one-off box to tick would be a mistake. Build the monitoring, inventory, and reporting muscle once, and you cover a large slice of what NIS2 and the AI Act ask for too. That is the smart way to spend a compliance budget: solve the shared problem, not each rule in isolation.

Key Takeaways

• The date is fixed: vulnerability and incident reporting under the EU Cyber Resilience Act starts 11 September 2026.
• 24 hours is the crunch: an early warning is due within a day of becoming aware of active exploitation, then 72 hours, then a final report.
• One platform: you file through ENISA’s Single Reporting Platform, addressed to your national CSIRT.
• Very wide scope: software, IoT, OT, networking, medical, and embedded products all count, including legacy items.
• Location-blind: non-EU manufacturers selling into the EU carry the same duties.
• Prep beats panic: name your filer, register with your CSIRT, inventory products, and run one drill.

How TecniForge Can Help

At TecniForge, we help businesses navigate these technology shifts. Whether you need custom software development, AI integration, or cloud migration, our team can map your product inventory, wire up vulnerability monitoring, and build the incident-reporting workflow the CRA demands. Talk to our experts.

If a vulnerability in your product started being exploited tonight, could your team file that first report within 24 hours?

Sources: European Commission, ENISA, Crowell & Moring, Tech Times.