What changes on Thursday

Article 14 of the Cyber Resilience Act applies from 11 September 2026. The rest of the regulation — the engineering obligations, conformity assessment, CE marking — does not apply until 11 December 2027.

So this week is not “the CRA arrives.” It is one article arriving, fifteen months early, on its own.

That article requires manufacturers to report certain vulnerabilities and incidents on a very short clock. Four things about it are routinely got wrong, and each of them changes what you should do.

Wrong thing #1: it is not only about exploited vulnerabilities

There are two independent triggers, and most write-ups cover only the first.

Actively exploited vulnerability — defined in Article 3(42) as one for which there is “reliable evidence that a malicious actor has exploited it in a system without permission of the system owner.”

Read that carefully. There is no severity threshold. There is no requirement that the exploited system belong to your customer. Evidence that someone, somewhere, exploited it without permission is enough.

Severe incident having an impact on the security of the product — Article 14(3), with the test in 14(5). Two alternative limbs: the incident negatively affects, or is capable of negatively affecting, the product’s ability to protect availability, authenticity, integrity or confidentiality of sensitive data or functions; or it has led, or is capable of leading, to the introduction or execution of malicious code in the product or in a user’s systems.

“Capable of negatively affecting” is doing a lot of work there. It catches near-misses with potential impact, which is wider than most incident-response playbooks are scoped for. If your severity matrix only fires on realised harm, it will under-report.

Wrong thing #2: there are more than two deadlines

Everyone quotes 24 and 72 hours. There are four report types, and the tails differ depending on which trigger fired.

ReportVulnerability (Art. 14(2))Severe incident (Art. 14(4))
Early warning24h from becoming aware24h from becoming aware
Notification72h from becoming aware72h from becoming aware
Final report14 days after a corrective or mitigating measure is available1 month after the 72h notification
IntermediateOn CSIRT request, Art. 14(6)On CSIRT request, Art. 14(6)

Note what the vulnerability final-report clock hangs off: fix availability, not awareness. It can land months later. Arguably it never starts if no fix ever ships — which is a gap someone will eventually test.

Both 24-hour clocks run from becoming aware, not from confirming. You get a reasonable interval to establish that you are looking at something real. You do not get to wait for certainty.

Wrong thing #3: you file once, but it reaches two places

Not “report to ENISA.” Not “report to your national CSIRT.” Article 14(1) requires notification simultaneously to the coordinating CSIRT and to ENISA — and Article 16 provides a Single Reporting Platform so that one submission satisfies both.

The part to sort out before Thursday is which CSIRT. Article 14(7) points at the Member State of your main establishment — where decisions about your products’ cybersecurity are predominantly taken. For manufacturers outside the EU there is a waterfall: authorised representative, then importer, then distributor, then the Member State with the most users.

That is a determination involving your legal team, and it is a bad thing to be working out at hour three of a live incident.

Wrong thing #4 — and this is the big one: it covers what you already shipped

Article 69(3) extends Article 14 to all in-scope products placed on the market before 11 December 2027.

There is no substantial-modification carve-out for reporting. A product you shipped in 2019, that you have not touched since, that will never be CE-marked under this regulation, still generates a 24-hour reporting obligation if someone exploits a vulnerability in it.

If your CRA programme is scoped to “products we are preparing for December 2027,” it is scoped wrong for this week.

What you do not need by Thursday

Worth saying plainly, because vendors are currently selling all of these as CRA-urgent:

  • SBOM — Annex I Part II. December 2027.
  • Coordinated vulnerability disclosure policy — Annex I Part II. December 2027.
  • A single point of contact as a legal requirement — Article 13. December 2027.
  • Security update obligations, support periods, conformity assessment, CE marking — all December 2027.

Have a contact channel anyway. Not because the regulation requires it yet, but because it is how you find out you are being exploited in time to file.

The structural gap nobody legislated away

From Thursday you must report exploitation within 24 hours. You are not legally required to have built the vulnerability-handling programme that would let you detect exploitation until December 2027.

The duty to report arrives fifteen months before the duty to be capable of noticing. That gap is real, it is in the text, and the practical consequence is that the first year of CRA reporting will be driven by whoever happens to tell you — researchers, customers, threat intel — rather than by anything you built.

What about the fines?

Here I have to be honest rather than dramatic, because a lot of current commentary is not.

Article 64(2) puts Article 14 in the top penalty tier: up to €15 million or 2.5% of total worldwide annual turnover, whichever is higher. Small and micro enterprises are exempt from fines for missing the 24-hour early warning specifically (Art. 64(10)(a)) — but not the 72-hour or final reports. Open-source stewards are exempt from fines entirely (Art. 64(10)(b)).

But: Article 71 advances only Article 14 and Chapter IV to 2026. It does not advance Article 64, or the market surveillance chapter. On the plain wording, the penalty machinery starts in December 2027.

Several law firms state flatly that fines apply to Article 14 breaches from 11 September. I could not find primary support for that, and the text does not obviously say it.

So: the obligation is unambiguously binding from Thursday. Whether a fine can be levied for a breach between September 2026 and December 2027 is genuinely unsettled. Anyone telling you €15 million is on the table this week is stating a contested reading as fact. Comply because it is the law, not because someone quoted a scary number at you.

One open question worth watching

As of today, the Single Reporting Platform is not live. ENISA says it will be used “as of 11 September 2026 onwards”; the Commission said in July that it “will be operational” by then, with functional and security testing under way.

Nothing published describes a fallback if the platform is unavailable. Article 16(4) only obliges ENISA to notify security incidents affecting the platform. The 24-hour clock is statutory; the platform is two days old; there is no documented answer to what a manufacturer does if it cannot file on day one.

ENISA has also asked manufacturers not to pre-register in bulk — register and start authorised-representative validation only when you actually have something to submit, to avoid overloading national CSIRT teams. Create your EU Login accounts in advance instead.

The 48-hour checklist

  1. Determine your main establishment and coordinating CSIRT. Legal question, not an engineering one. Do it before you need it.
  2. Create EU Login accounts with MFA for whoever will file. Do not bulk-register on the platform.
  3. Staff the clock. Twenty-four hours from awareness includes Friday nights and public holidays. This is the real operational lift and no tooling solves it.
  4. Write the two templates now — 24-hour early warning, 72-hour notification. Drafting under a live clock produces bad filings.
  5. Agree who decides whether something is “capable of negatively affecting” under Art. 14(5). That judgement call needs an owner and an escalation path.
  6. Scope your product list to everything shipped, not to the December 2027 conformity programme.
  7. Plan the user notification. Article 14(8) requires informing impacted users of the vulnerability or incident and, where necessary, of mitigations — in machine-readable format where appropriate.

References

Article text above is quoted from a public mirror of the regulation. For anything you are going to act on, read the authoritative text on EUR-Lex.