Fire Drill, Not Fire Alarm: Is Your Product Ready for the CRA’s 24-Hour Clock?

Fire Drill, Not Fire Alarm: Is Your Product Ready for the CRA's 24-Hour Clock?

Every office building has a fire alarm. The ones that come through a fire also ran the drill: people knew the exits, the floor plan was up to date, and someone was named to call the fire brigade.

Since 11 September 2026, the EU’s Cyber Resilience Act (CRA) asks the same of software and connected products. Most of its rules arrive in December 2027, but one part is already live: manufacturers must now report actively exploited vulnerabilities and severe security incidents, starting with an early warning within 24 hours.

The alarm is installed. The question for every product team is whether they have run the drill.

From "Are we compliant by 2027?" to "Could we report by tomorrow?"

Many European teams still file the CRA under 2027. That is true for CE marking and the security-by-design rules. But the reporting duty under Article 14 already applies, and it covers products already on the EU market, not just new releases.

If you ship IoT devices, apps, smart energy hardware or connected health products in Europe, you are probably a “manufacturer” under the CRA. Missing the reporting duty can cost up to €15 million or 2.5% of global turnover, whichever is higher.

But the deadline itself is not the hard part. Knowing where to look is.

One alarm, three calls

The clock starts when you become aware that a vulnerability in your product is being actively exploited, or that a severe incident has hit its security. Reports go to ENISA and your national CSIRT through ENISA’s Single Reporting Platform.

24 hours Early warning Which product is affected and where. No full root-cause analysis needed yet.

72 hours Notification What is happening, and what users can do to protect themselves.

14 days Final report After a fix is available: root cause, the fix, remaining risk. For severe incidents, one month after the 72-hour notification.

To file the first call in time, you need one answer within hours: which of our products contain the affected component? If that takes a week, the window has already closed.

What fire safety looks like in your codebase

Every building rule has a software equivalent. Here is how the two line up, in the order we usually put them in place with our clients.

1Floor plan

A living SBOMA Software Bill of Materials generated with every release, so you always know what is inside each product.

2Smoke detectors

Exploit monitoringAlerts for vulnerabilities known to be exploited, rather than a growing list of every CVE.

3Fire warden

A named decision ownerOne person who decides whether an event must be reported, and who is authorised to submit it.

4Fire drill

A rehearsed 24-hour runbookClear steps, a registered account on ENISA’s platform, and at least one practice run.

5Clear exits

A tested update pathA reliable way to ship security fixes to every supported version, including devices in the field.

Who's on watch while Europe sleeps?

Exploits don’t keep office hours. Many are discovered overnight, and a 24-hour clock that starts at 2 a.m. has already lost a quarter of its time by breakfast.

Our engineers in Vietnam start their day while Europe is still asleep. Working as part of your team, under the escalation rules you set, they can pick up an overnight alert, check which products are affected and have the facts ready before your office opens.

Since 2008, TechSoft has built and maintained connected products for European companies in healthcare, IoT, mobility and energy. For CRA readiness we usually help in three ways: adding SBOM generation and vulnerability scanning to your CI/CD pipeline, modernizing legacy code that is hard to patch, and joining your on-call rota.

Not sure if your product is in scope? Let's walk the building together.

In a 30-minute session, we’ll look at which of your products the CRA covers, where your reporting gaps are, and what to fix first, whether or not we work together.