The CRA Article 14 checklist for a small software company.
Six items: a machine-readable SBOM, an exploitation watch on your dependencies, a timestamp on when you became aware, the three reporting clocks, your manufacturer details on file, and a filing dry-run against ENISA’s Single Reporting Platform. Work through them in order and you’re reportable-ready.
No tool makes you compliant, and this isn’t legal advice. Each item below names how OSPulse does the work, or links to the free readiness report that checks it for you.
Not sure a given product is even in scope? Run the scope check first, it’s free and takes a minute.
This is a working checklist, not a summary of the regulation.
CRA reporting duties under Article 14 apply from 11 September 2026, to products with digital elements placed on the EU market (including by non-EU manufacturers, and including products already on the market). Fines for the reporting duties run up to €15M or 2.5% of worldwide annual turnover, which is why the point of this list isn’t to read about the Act, it’s to have each item true before a finding fires.
None of the six needs a compliance department, and none of them needs a lawyer to start. They do need to be true, and provable, ahead of time.
Six items, in order.
Each builds on the one before it: you can’t watch components you haven’t listed, can’t timestamp a signal you’re not watching for, and can’t file a clean report without the first four already true.
- 01
Produce a machine-readable SBOM for every shipped product.
A software bill of materials (CycloneDX or SPDX, covering at least your top-level dependencies) is what every other item on this list is built on: you can’t watch or report on components you haven’t listed. OSPulse generates a CycloneDX SBOM from the scans you already run, and takes a manual upload for a legacy product with no live pipeline.
- 02
Put an exploitation watch on your dependencies, not a CVE firehose.
Article 14 doesn’t ask you to report every CVE. It turns on active exploitation and severe incidents. Cross-check your SBOM against exploitation intelligence (CISA KEV, in-the-wild exploit signals, supply-chain compromise) and keep only the reportable findings separate from the ones you merely track. OSPulse runs that classification continuously and tells you the difference.
- 03
Timestamp the moment you become aware of a signal.
The reporting clocks start at awareness, not at confirmation or at your next stand-up, so a timestamped record of when a signal reached you is the evidence that matters most if you ever have to show your working. OSPulse logs a KEV hit on your dependencies the moment it lands, naming the package, the advisory and the affected releases.
- 04
Know the three clocks before one starts.
Once a finding is reportable: an early warning is due within 24 hours, a full notification within 72 hours, and a final report within 14 days of a corrective measure, one month for a severe incident. Write these three numbers down somewhere your team will actually see them; OSPulse starts them automatically the moment a finding is classified Reportable.
- 05
Have your manufacturer details ready to file.
Every reporting stage needs the same manufacturer identity fields (legal name, contact, product and release identifiers) and hunting for them while a clock is running is time you don’t have. Set them once in OSPulse and every submission-ready pack pulls them in automatically.
- 06
Do a filing dry-run against ENISA’s Single Reporting Platform.
Reports go through ENISA’s Single Reporting Platform. There is no API, so a human files it, which means the first time your team sees that form should not be during a live 24-hour clock. OSPulse produces submission-ready report packs, laid out in the platform’s own field order, so a dry-run is a review, not a blank-page exercise.
The free report checks items 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 all six items running continuously (the SBOM, the exploitation watch, the awareness record, the clocks, the manufacturer details and the submission-ready pack), that’s what OSPulse itself does. See how OSPulse builds the pack.
Frequently asked
Do I need to report every vulnerability on this checklist?
No. The Article 14 duty covers actively exploited vulnerabilities and severe incidents affecting product security, not every CVE that turns up in a scan. Item two on this list, an exploitation watch rather than a CVE firehose, is exactly that filter.
Is the SBOM requirement enforceable today?
The CRA requires a machine-readable SBOM covering at least top-level dependencies, enforceable at full application on 11 December 2027. The reporting duties in Article 14 (the ones this checklist is built around) apply from 11 September 2026. Producing the SBOM now is what makes the other five items possible. It is not itself a live reporting deadline.
Does OSPulse file the reports for us?
No, and nobody else can either, because ENISA provides no API for the Single Reporting Platform. OSPulse produces submission-ready report packs, pre-filled in the platform’s own field order, and a human still reviews and files them. This isn’t legal advice, and no tool makes you compliant: OSPulse gives you evidence and speed, not absolution.
Are we in scope if we’re not based in the EU?
The CRA applies to products with digital elements placed on the EU market, including by non-EU manufacturers, and including products already on the market, so where you’re headquartered isn’t the test. Run the free scope check if you’re not sure about a specific product.
Work the list before a finding fires.
Evidence and speed when a reportable finding fires, not a scramble, and not a claim that a tool discharges the obligation.