Article 14 is already in force. Since 11 September 2026, manufacturers of products with digital elements have had to report actively exploited vulnerabilities and severe incidents to ENISA and their national CSIRT — early warning within 24 hours, full notification within 72. It covers products already on the market, not just new ones. The rest of the CRA follows in December 2027; this part did not wait.

Here is the part most people miss. The obligation is to report what you become aware of. A manufacturer with no way of detecting exploitation in the field never becomes aware — and breaches Article 14 without ever seeing it happen. The duty to report and the ability to detect are the same problem, which is why the first five questions below are not about reporting at all. The reasoning is set out in full here.

Part one — can you see it?

A no here is an exposure you cannot measure, because by definition you don't know what you're missing.

  • Do you hold a software bill of materials covering at least the top-level dependencies of every product you place on the EU market?
    Including products shipped years ago and still in the field.
  • Is a named person checking vulnerability sources against that SBOM on a defined schedule?
    Not "we'd hear about it." A cadence, an owner, and a record that it happened.
  • Do you publish a security contact point, and does somebody actually monitor it?
    An unmonitored disclosure inbox is worse than none — it evidences that you were told.
  • If a customer reported a security problem to your sales or support team on a Friday, would it reach someone who can triage it?
    Test this one for real. It is where most reports quietly die.
  • Could you tell whether a vulnerability is being exploited in the field, rather than only that it exists?
    Active exploitation is the trigger. Theoretical findings and proof-of-concepts are not reportable — but you have to be able to tell the difference.

Part two — could you act in time?

A no here costs you the window. The clock starts when you become aware, and it does not pause for weekends.

  • Do you have written criteria separating an actively exploited vulnerability from a theoretical one?
    Made in advance, in daylight — not argued over at 2am.
  • Do you have written criteria for what counts as a severe incident?
    Impact on sensitive data or functions, or the execution of malicious code.
  • Do you record the date and time you became aware of a report?
    That timestamp starts the 24-hour clock. It is the first thing anyone will ask you for afterwards.
  • Can one named person declare a reportable event without waiting for consensus?
    Twenty-four hours does not survive decision-by-committee.
  • If you decided not to report something, would the reasoning be written down?
    Defensible non-reporting needs a record. Silence is not a defence.

Reading your answers

Ten yeses. You are in a small minority. Exercise the process against a live scenario before you rely on it, and keep the SBOM current as products change.

One or two noes. Fixable in weeks, usually without spending money. Close them now while it's a planning exercise rather than an incident.

Three or more, or any no in Part one. There is no reliable path from a field report to a filed notification. That is a live exposure on products already on the EU market, and it will not announce itself.

Download the PDF

Three things worth doing in the next fortnight

Whatever you scored, these cost nothing but attention.

This is the short version. The full assessment runs to 27 checks across scope, detection, triage, reporting mechanics, escalation, user communication and evidence, and scores you by domain. Ninety8 Compliance supports manufacturers and importers in meeting EU product obligations — across the CRA, CE marking, packaging, WEEE and RoHS — without building a compliance department to do it.