Missed 11 September? You’re not too late. You’re on the clock.
The CRA Article 14 reporting duty has applied since 11 September 2026, but it’s forward-looking: it covers actively exploited vulnerabilities and severe incidents you become aware of from that date on. Missing the start date isn’t a fine. Being unable to report the next one in time is the risk, and that’s the gap you can close this week.
No tool makes you compliant, and this isn’t legal advice. What follows is the practical triage: know what you ship, know what’s being exploited, and be able to prove when you knew.
Not sure a given product is even in scope? Run the scope check first. It’s free and takes a minute.
What the date actually changed.
11 September 2026 is when the reporting duty switched on, not a filing you were meant to submit on the day. From that date, when you become aware that a component in a shipped product is being actively exploited, or that a severe incident has affected the product’s security, the reporting clocks apply. The penalty ceiling for the reporting duties is up to €15M or 2.5% of worldwide annual turnover, which is why the goal is to be ready to report cleanly, not to have panicked on a date.
So the useful question isn’t “how much trouble am I in for being late”: it’s “could I file an accurate early warning within 24 hours if a reportable finding fired tomorrow?” If the answer is no, the four steps below close that gap.
Four steps to reportable-ready.
None of these needs a compliance department. They need to be true, and provable, before a finding fires, not reconstructed after one does.
Establish what you actually ship.
The duty attaches to products with digital elements on the EU market, including software you shipped years ago. Before anything else, produce a machine-readable inventory of every component in every shipped release. OSPulse generates a CycloneDX SBOM from the scans you already run, and takes a manual upload for a legacy product with no live pipeline.
Find out what is being actively exploited, today.
Article 14 does not turn on every CVE. It turns on active exploitation and severe incidents. Cross-check your components against exploitation intelligence (CISA KEV, in-the-wild exploit signals, supply-chain compromise) and separate the findings that are reportable from the ones you only track. That single distinction is the difference between a manageable list and a panic.
Be able to prove when you became aware.
The clock starts at awareness, not at confirmation, so a timestamped record of when a signal reached you is the evidence that matters most. Wire alerting so a KEV hit on one of your dependencies is logged the moment it lands, naming the package, the advisory and the affected releases, not reconstructed from memory after the fact.
Know the three clocks before one starts.
When a reportable finding fires you have an early warning due within 24 hours, a full notification within 72, and a final report within 14 days of a corrective measure (one month for a severe incident). Reports go through ENISA’s Single Reporting Platform. There is no API, so a human files it, which means a pre-filled, submission-ready pack is the difference between reviewing and scrambling.
The free report does steps one and two in about 90 seconds.
Paste a dependency manifest (package.json, requirements.txt, go.mod, pom.xml, a .csproj) into the Article 14 readiness report and it returns your scope verdict, how many of your dependencies sit on known-exploited or abandoned lists, and what you would have to file. It runs in memory, asks for no email, and stores nothing.
When you want the same checks running continuously (the exploitation watch, the awareness record and the submission-ready pack for each reporting stage), that’s what OSPulse itself does. The report is the triage; OSPulse is the ongoing machinery. See how OSPulse builds the pack.
Frequently asked
I missed 11 September. Am I automatically being fined?
No. The Article 14 reporting duty is forward-looking: from 11 September 2026 it requires you to report actively exploited vulnerabilities and severe incidents you become aware of, on the 24-hour / 72-hour / 14-day clocks. The date passing does not create a penalty on its own. The exposure is being unable to report the next qualifying event in time. This is not legal advice. For your specific position, take counsel.
What is the fastest way to know where I stand?
Run the free readiness report on the Article 14 Signal site. Paste a dependency manifest and it returns your scope verdict, how many of your dependencies sit on known-exploited or abandoned lists, and what you would have to file, in about 90 seconds, with no email and nothing stored.
Does OSPulse make us compliant now that we are late?
No tool can, and being late does not change that. OSPulse gives you the inventory, the exploitation watch, the awareness record and a submission-ready pack the reporting duty demands. Your team, and for many firms your counsel, makes the compliance decisions. It makes them fast and defensible instead of panicked.
Does the CRA apply to us if we are a UK company?
If you place products with digital elements on the EU market, yes, regardless of where you are based, and including products already on the market. Whether a particular product is in scope is exactly what the free scope check answers.
Close the gap before the next finding.
Evidence and speed when a reportable finding fires, not a scramble, and not a claim that a tool discharges the obligation.