If you sell software or connected devices into the EU, there's one question on your desk right now: do we have to do something before 11 September, and how bad is it if we don't?
Here's the honest answer. If your company puts products with digital elements on the EU market as a manufacturer, then from 11 September 2026 you must report actively exploited vulnerabilities and severe incidents to ENISA and your national CSIRT, with an early warning due within 24 hours of becoming aware. If you run a pure SaaS business, this probably doesn't apply to you. And for most companies that are in scope, getting ready takes a few days of focused work, not a compliance program.
The fine for getting it wrong: up to 15 million euros or 2.5% of worldwide annual turnover, whichever is higher. That number exists to move this topic out of the legal team's backlog and onto yours.
What actually starts on 11 September
The Cyber Resilience Act entered into force in December 2024. Its full requirements, the CE marking, the conformity assessments, the security by design obligations, apply from 11 December 2027. But one piece was pulled forward: Article 14, the reporting obligation.
From 11 September 2026, a manufacturer of a product with digital elements, which in practice means software, or hardware that contains software, must report two things. First, any actively exploited vulnerability in the product. Actively exploited means attackers are using it in the real world, not that a scanner flagged it as theoretical. Second, any severe incident that affects the security of the product itself.
The clock is tight. An early warning goes in within 24 hours of becoming aware. A fuller notification follows within 72 hours. A final report is due within 14 days of a fix being available for an exploited vulnerability, or within a month for a severe incident. All of it flows through ENISA's Single Reporting Platform, which routes each report to your national CSIRT.
One detail that surprises people: this covers products you've already shipped. The obligation is not limited to products placed on the market after the date. If your product is out there and someone starts exploiting a hole in it on 12 September, you're on the clock.
First: does this even apply to you?
The CRA covers products with digital elements placed on the EU market. In practice:
- You're in scope if you sell or license software, or hardware with software in it, to EU customers as a commercial product. Desktop software, mobile apps, firmware, IoT devices, a Laravel application you license to customers who run it themselves.
- You're probably out of scope if you run pure SaaS. Cloud services fall under NIS2, a different regulation with its own reporting rules. The exception is a cloud component that exists only to make a product work, like the backend behind an IoT device. That counts as part of the product.
- Open source gets breathing room. Software developed outside a commercial activity is out of scope, and open source stewards, the foundations and similar bodies that support a project, face lighter obligations and no fines.
- Micro and small enterprises still have to report, but can't be fined for missing the 24 hour early warning deadline. The 15 million euro figure is not aimed at a four person team, though the duty to report still is.
If you've read that and you're still not sure, that uncertainty is the first thing to resolve, because everything else depends on it.
Your three real options
Assuming you're in scope, or think you might be, there are three ways to play the next two weeks.
Option 1: wait and see
Do nothing until the dust settles. There's a case for it, and it's not a crazy one: as of late August, the Single Reporting Platform is still not live. ENISA published step by step registration guidance on 31 July and says the platform will be operational by 11 September, but you can't finish registering today on a system that isn't there yet. Enforcement will also take time to ramp up, and market surveillance authorities have 27 countries of manufacturers to get through.
Who it suits: companies genuinely on the scope boundary, waiting for clarity on whether their product counts.
Option 2: the minimum reporting capability
Spend a few days building exactly what the obligation requires and nothing more. Decide who owns the 24 hour clock, by name, with a deputy for vacations. Write a one page runbook: how you learn about a vulnerability, who decides whether it's being actively exploited, who files the report, where the platform login lives. Wire up the inputs: a monitored security contact address, dependency alerts on your repositories, and an actual human looking at them. Then register on the platform the day it opens.
Cost: two to four days of a senior person's time, spread over a couple of weeks. Who it suits: most software companies in scope, which is why it's my recommendation.
Option 3: pull the full CRA program forward
Treat 11 September as the starting gun for the December 2027 requirements too: product classification, a software bill of materials, a documented vulnerability handling process, conformity assessment planning. Cost: weeks to months, depending on your product surface. Who it suits: hardware manufacturers, anyone whose product lands in the CRA's important or critical categories, and companies that will need a notified body in 2027 and should be booking that lead time now.
Where each option fails
Waiting fails the moment something is exploited. The obligation applies from 11 September whether or not you feel ready, and "we were waiting for clarity" is no defense when the early warning window was 24 hours and you took eleven days. It also fails quietly, earlier: buyers have started asking about CRA readiness in procurement questionnaires, and "we have no process" is an expensive answer in a sales cycle.
The minimum capability fails if you treat the paperwork as the deliverable. Here's my actual opinion on this whole topic: the report form is not your problem. Knowing is your problem. Most companies that miss the 24 hour window won't miss it because the runbook was bad. They'll miss it because nobody was watching the inputs, and they became "aware" weeks after the fact. A runbook without monitoring behind it is a document, not a capability. And to be fair about my own recommendation: the monitoring is the expensive part, and a few days of setup buys you an alert pipeline, not a security team.
The full program fails as a first move for a small software vendor because it piles months of work onto a deadline that only requires the reporting piece. You have until December 2027 for the rest. Spending that budget now, in a panic, usually buys worse decisions than spending it next year with a plan.
The decision in one table
- Wait and see. Cost now: zero. Risk: unbounded from 11 September. Pick it if: you're likely out of scope.
- Minimum reporting capability. Cost now: 2 to 4 days of senior time. Risk: monitoring gaps remain. Pick it if: you ship software commercially into the EU.
- Full CRA program now. Cost now: weeks to months. Risk: overspend, rushed decisions. Pick it if: hardware, important or critical class products.
So, what should you do?
If you're a software company with products on the EU market: option 2, this week. Name the owner, write the runbook, wire the alerts, and register on the platform when it goes live. Then schedule the 2027 work for early next year, calmly.
If you make hardware, or security software, or anything likely to be classed as an important product: option 2 is not enough. Start option 3 now, because notified body capacity in 2027 will be a seller's market.
If you're pure SaaS with no product component: confirm that conclusion in writing with someone who knows the regulation, file it, and go back to work. NIS2 is your regulation to check, not this one.
Where we fit
We build and maintain software for EU clients, in Laravel, React, and React Native, so this deadline lands on our desk too, from both sides. The practical work behind option 2 is work we already do: dependency and vulnerability monitoring wired into your repositories, an alert pipeline someone actually reads, and an honest assessment of whether your product is in scope at all. If nobody in your company owns the 24 hour clock yet, or you want a second pair of eyes on your scope call, get in touch.