The Cyber Resilience Act Nobody Is Planning For

Ask a European software team when the Cyber Resilience Act affects them and most will say December 2027. That is the date in the slide decks, the date in the budget requests, and the date the CE marking work is planned around.

It is also the wrong date.

Article 14 of Regulation (EU) 2024/2847 takes effect on 11 September 2026 — thirty days from now. From that morning, any manufacturer of a product with digital elements on the EU market must report actively exploited vulnerabilities and severe security incidents to their national CSIRT and ENISA, on a clock measured in hours.

There is no phase-in. There is no grace period for small teams. And the obligation reaches backwards to products you shipped years ago.

Here is what the rule actually demands — and, just as importantly, what it does not.

The trigger is narrower than most teams assume

The single most common misreading of Article 14 is that it turns every CVE into a filing.

It does not. There are exactly two triggers:

1. An actively exploited vulnerability in your product (Article 14(1)). The operative word is actively. A published CVE with a CVSS of 9.8 and no evidence of exploitation in the wild does not start the clock. Credible evidence that someone is using it against real systems does.
2. A severe incident affecting the security of your product (Article 14(3)).

This distinction matters enormously for workload. A mid-sized product with a few hundred dependencies might accumulate dozens of critical CVEs a quarter. Almost none of them will be reportable. Teams that build their process around "report everything critical" will drown in filings they never owed, and — worse — will be so busy that they miss the one that actually counted.

The first operational decision you need settled before September is not technical. It is this: who in your organisation is authorised to judge that a vulnerability is being actively exploited? That call has to be made quickly, by a named person, possibly at 2am on a Sunday.

The cascade: 24 / 72 / then it depends

Article 14 runs in three stages, and the clock on all of them starts from awareness — not from confirmation, not from triage, and not from when your incident channel gets around to it.

Within 24 hours — early warning. This is deliberately thin, and this surprises people who have prepared for something heavier. The mandatory fields amount to the notification type and level, the manufacturer name, the product, a title, and whether unlawful or malicious activity is suspected. You are not expected to have a root cause. You are not expected to have a fix. You are expected to have told someone.

Within 72 hours — full notification. Now the substance is due: the nature of the vulnerability, its impact, and any corrective or mitigating measures taken or available. This stage also asks for your product's classification under Annex III or IV — which is a question you want answered in advance, not while a three-day clock is running.

The final report — and this is where the two triggers diverge.

For an actively exploited vulnerability, the final report is due within 14 days of a corrective or mitigating measure becoming available.

For a severe incident, it is due within one month of the 72-hour notification.

Note the trap in the vulnerability timeline. The 14-day clock starts when a fix or a workaround is available — not when a complete permanent patch ships. You cannot defer the final report indefinitely by arguing that the proper fix is still in development. If you have published a mitigation, the clock is running.

Three things about the platform that change how you prepare

Reports go through ENISA's Single Reporting Platform. You file once; it routes to your designated CSIRT coordinator and ENISA simultaneously. ENISA states the platform "will be operational by 11 September 2026", with a testing period expected beforehand.

Three practical details are worth more than any amount of policy documentation:

There is no API. ENISA's own FAQ is explicit: organisations "might automate reporting workflows and integrate reporting requirements into their systems and databases, however no Application Programming Interfaces will be provided at this stage." You can automate detection, correlation, and drafting — but the final step is a human being completing a browser form. Which means the person who does it needs to exist, needs to know they are that person, and needs access out of hours.

You need an EU Login account, and you can create it today. Access to the platform is via EU Login, the Commission's authentication service. This is the one piece of preparation that does not depend on anything ENISA has yet to publish, and it is the single most common way a first filing goes wrong: not the drafting, but discovering at hour three that nobody on call can authenticate. Create the accounts now, for the deputy as well as the primary, and verify they work.

Note also that the platform's public URL has not yet been published — ENISA says it "will be communicated and published in due course" before go-live. So you cannot bookmark it yet, and somebody should be watching that page. Representative authorisation is validated by your CSIRT after first access, in parallel with the reporting process, so you are not blocked waiting for pre-approval — but the first filing carries a validation step the later ones will not.

Build the 24-hour form internally, now. Create an internal template that mirrors ENISA's mandatory early-warning fields. ENISA published step-by-step platform instructions at the end of July, so the field list is knowable in advance. Then your first real filing is a transcription exercise rather than a composition exercise under time pressure. This is a two-hour job that will save you on the day it matters.

The scope problem: it reaches backwards

Article 69(3) extends the reporting duty to products with digital elements placed on the market before December 2027. If it is still on the EU market on 11 September 2026, it is in scope.

For most software organisations, this is the uncomfortable part. Article 14 compliance depends on knowing what is inside your products — and for anything shipped three or four years ago, that knowledge often does not exist in any retrievable form.

This is also where end-of-life open source becomes a specific legal exposure rather than a general engineering concern. When an upstream framework stops receiving patches and a new CVE in it is actively exploited, your 24-hour clock starts anyway. There is no upstream fix coming. You still owe the report, and at 72 hours you still owe a description of your mitigating measures.

That calculus used to be a risk-management judgement. It is now a compliance question with a defined deadline.

If you are a distributor or importer rather than a manufacturer, you do not file under Article 14 — but Articles 20 and 24 require you to pass vulnerability information to the manufacturer without undue delay, precisely so they can meet their deadlines. Your contracts should say so explicitly.

The real obstacle is detection, not filing

Here is the observation that reframes the whole problem.

Filing a report is easy. It is a form. The hard part is knowing there is something to report while there are still 24 hours left to act on it.

A manufacturer cannot report what it cannot detect. That means Article 14 compliance rests on three capabilities that are pure DevSecOps and cloud security work, none of which are themselves mentioned in Article 14:

• An accurate, current SBOM for every product still on the EU market — generated in CI, versioned with the release, and retrievable for builds you shipped years ago.
• Continuous matching of that bill of materials against known-vulnerability and exploitation sources, including the NVD, the EU vulnerability database (EUVD), and active-exploitation feeds such as CISA KEV.
• A coordinated disclosure channel that a security researcher can actually find and use, because a meaningful share of first notifications will arrive from outside your organisation.

A manufacturer without these can breach Article 14 not by failing to report, but by never learning there was anything to report. That is a harder failure to defend, because it looks like negligence rather than delay.

Penalties under Article 64 reach €15 million or 2.5% of worldwide turnover, whichever is higher.

What to do in the next thirty days

Realistically, nobody is achieving full CRA maturity before 11 September. That is not the goal. The goal is to be able to file correctly and on time if something happens in October.

Five things, in order:

1. Inventory what is in scope. Every product you manufacture, import, or distribute in the EU that connects to a network or another device. Settle your Annex III/IV classification while you have time.
2. Name the humans, and give them EU Login accounts. Who judges that a report is owed. Who drafts it. Who submits it. Who covers nights and weekends. Write the names down, then make sure each of them can actually authenticate — this is the one step that can be completed today and finished.
3. Build the 24-hour template. Mirror ENISA's mandatory fields.
4. Get SBOM generation into CI for everything currently shipping, and reconstruct what you can for legacy products still on the market.
5. Run one tabletop exercise. Simulate an exploitation report arriving on a Friday evening. The teams that succeed in September will be the ones that have practised before September.

The short deadline does not reward the perfect report. It rewards the timely one.

How DevSpark helps

We work with product teams on exactly this gap: turning a regulatory obligation into a detection-to-disclosure workflow that runs without heroics.

That means SBOM generation wired into your existing pipelines, continuous correlation against EUVD, NVD and active-exploitation feeds, and a reporting runbook with named owners and pre-built templates that your on-call can execute at 2am.

Not sure where you stand? Our CRA Article 14 readiness check takes about two minutes and produces a scored gap report against the September obligations. It runs entirely in your browser, nothing you enter leaves the page, and there is no sales call attached.

---

This article is general information about regulatory requirements and is not legal advice. Consult qualified counsel on your specific obligations under Regulation (EU) 2024/2847.