The CRA deadline you filed under "2027" was eleven days ago, and its clock is 24 hours.

Article 14 reporting went live on 11 September. It applies to apps you shipped years ago, the only filing channel is a web form with no API, and the login you need to use it is not something you can obtain at hour 23.

Almost every summary of the EU Cyber Resilience Act you've read ends with the same reassurance: it applies from December 2027, you have time. That sentence is true about the part of the Act that will cost you the most work, and it is wrong about the part that is live right now.

Reporting obligations under Article 14 have applied since 11 September 2026. That's eleven days ago. I went and read the Commission's own reporting page and ENISA's platform FAQ rather than the coverage, because Murror ships a mobile app into the EU and I wanted to know what I'd actually have to do at 2am. Three things in there surprised me, and one of them is a live bug in the platform.

First, whether this is you.

The CRA covers "products with digital elements" made available on the Union market. A manufacturer is whoever markets the product under their own name, and the definition says explicitly "whether for payment, monetisation or free of charge." Free doesn't get you out. Small doesn't get you out either; there is no size threshold on the obligation, only on one of the fines.

A mobile or desktop app you distribute in the EU is in scope. Pure browser-based SaaS is generally treated as a service rather than a product and sits outside, but your backend is in scope the moment it counts as remote data processing, which the Act defines as processing at a distance, developed by or for you, whose absence would stop the product doing one of its functions. If your app is a thin client over your API, that API is not a separate service you can wave at. It's part of the product.

This product-versus-service line is the genuinely contested bit, and I'm reading the Commission's guidance and a pile of law firm notes rather than a court ruling. I'm a founder, not a lawyer. If you're near the boundary, get an actual opinion.

Second, the clock, and what starts it.

Once you become aware of an actively exploited vulnerability or a severe incident affecting your product's security: early warning within 24 hours, full notification within 72 hours, and a final report no later than 14 days after a corrective or mitigating measure is available for actively exploited vulnerabilities, or within one month of the 72-hour notification for severe incidents.

"Actively exploited" has a specific meaning: reliable evidence that a malicious actor has exploited it in a system without the owner's permission. Not theoretical. Not a scary CVE in a dependency. Someone used it.

Two details the summaries skip. The obligation is not retrospective, so if you already knew about the exploitation before 11 September you don't have to file. But if you learn about it after that date the clock starts, even where the vulnerability itself is old and previously known. And reporting applies to products already on the market, including everything you shipped before the CRA's 2027 date. The December 2027 grace applies to the design requirements. It does not apply to this.

Third, the mechanics, which are worse than the rules.

There is exactly one channel: ENISA's Single Reporting Platform, launched on 11 September at initial operating capability. Some sharp edges, all of them documented by ENISA itself.

There is no API in the initial release. You file by hand in a web form. The platform is English-only at launch. If it's down, ENISA's instruction is to wait; you may contact your CSIRT directly in the meantime, but you still have to file through the platform once it's back.

To file, you need an EU Login account with MFA enabled, and you register on the platform as an Assigned Representative. ENISA's advice is to register only when you actually need to submit, to keep validation workload off the national CSIRTs. I understand why they say it and I'm not going to follow it, at least not for the EU Login half. Registration on the platform is a few minutes provided you already have an active EU Login account. Getting that account is the step I don't want to be discovering at hour 23 of 24. Go create it this week. It costs nothing and it's the only irreversible bottleneck in the chain.

You also have to pick the right CSIRT yourself, and ENISA says plainly that if you select the wrong one the notification may be invalidated and has to be resubmitted. Normally it's the Member State of your main establishment, defined as where decisions about your products' cybersecurity are predominantly taken. If you have no EU establishment at all, there's a waterfall: your authorised representative's Member State, then the importer's, then the distributor's, then, as a last resort, the Member State with the most users of your product. That last clause is why "we're not an EU company" is not an answer.

And the bug. ENISA's own FAQ says the 72-hour counter currently displays a due date 48 hours after you submit the early warning, rather than 72 hours after you became aware. So the platform may show your notification as overdue before it legally is. They say this will be fixed in a future release. Until then, the platform's clock and the regulation's clock are different clocks, and the regulation's is the one that counts. Keep your own timestamp of when you became aware.

What it costs to get this wrong.

Article 64 puts non-compliance with Articles 13 and 14 in the top tier: up to 15 million euro or 2.5% of total worldwide annual turnover, whichever is higher.

Before you panic: microenterprises and small enterprises cannot be fined for missing the 24-hour early warning specifically. Read that narrowly, because it is narrow. The obligation to report still applies to you. The 72-hour notification and the final report still apply to you, and are still fineable. The carve-out is one deadline, not a general exemption, and for a small team the realistic exposure was never a nine-figure fine anyway. It's a market surveillance authority taking an interest in a company with no process at all.

One thing that is genuinely in your favour: ENISA operates a helpdesk, and its own description of the role says "especially for SMEs."

The exercise.

Thirty minutes, this week, and most of it is not compliance work.

Create an EU Login account with MFA. That's the bottleneck. Do it before you need it.

Write down which CSIRT is yours, using the Article 14(7) order above. One line in a file.

Decide, in advance, who on your team is allowed to say "this is actively exploited." The 24-hour clock starts on awareness, and the thing that eats those hours is nobody being sure it's their call to make.

Write a paragraph of what you'd do in the first hour. Not a policy document. A paragraph.

For Murror the honest answer is that we're in scope, we hadn't thought about it, and until I sat down with the FAQ I was carrying the same "CRA is 2027" assumption as everyone else. The four steps above are what I did this week. The EU Login account took about five minutes; deciding who gets to call it took longer, which I think is the real finding.

If you skim one primary document, make it ENISA's SRP FAQ. It's the operational one, it's updated regularly, and the last time it changed was 17 September, five days ago. The coverage is not going to tell you about the counter.

13 views

Add a comment

Replies

Best

this is genuinely useful, thank you for actually reading the ENISA FAQ instead of recycling the 2027 headline. the part I'm chewing on is where a pure telephony/voice API sits relative to your product-vs-service line. we're not shipping an app at all, customers call our API and we hand back a phone call. no client, no installed thing, just a backend that happens to be reachable from the EU. does that read to you as closer to the "thin client over an API" case you flagged as in-scope, or does it fall on the service side since there's genuinely no product artifact a user ever holds? the CRA's own examples all seem to assume there's a shippable thing, and API-only businesses seem to fall into a gap none of the guidance addresses directly.