How OSPulse builds your reporting pack.
Article 14 asks for something harder than a CVE list: to know, within 24 hours, that a component in a shipped product is being actively exploited — and to prove when you knew. This is the machinery that does it, wired into the scans you already run.
begin · 11 September 2026
Not sure whether the Act applies to you at all? Article 14 Signal covers scope, the awareness clock, and what you would have to file.
Early warning within 24 hours — the law from 11 September 2026
Fines up to €15M or 2.5% of worldwide annual turnover
Applies to products already on the EU market
Alerted within about an hour when a dependency is actively exploited
Know what you’d have to report — before you have to report it.
The Cyber Resilience Act doesn’t ask you to report every CVE. It asks for something harder: to know, within 24 hours, that a component in one of your shipped products is being actively exploited — and to notify ENISA’s Single Reporting Platform with an early warning in 24 hours and a full notification in 72.
That’s three capabilities most small software teams don’t have:
A live inventory of what’s actually in your products.
OSPulse generates a CycloneDX SBOM for every product release from the scans you’re already running. Legacy product with no pipeline? Upload once — the CRA covers software you shipped years ago, and so do we.
An exploit watch, not a CVE firehose.
The reporting trigger is active exploitation. OSPulse maps every component against exploitation intelligence — CISA KEV, in-the-wild exploit signals, and our own supply-chain compromise detection — and separates Reportable from Track. You act on the four findings that matter, not the four hundred that don’t.
The finding comes to you.
Article 14 turns on awareness, so a finding nobody sees is a finding that has not happened yet. When a dependency enters CISA KEV — or a new Critical or High advisory affects the version in use — OSPulse emails your administrators within one detection cycle, naming the package, the advisory, the severity and the affected repositories. It is on by default, Medium and Low collapse into a single daily digest so the urgent channel stays worth reading, and Slack, Teams or a webhook can carry it instead. The record shows when the signal arrived and when you were told.
Clocks and reports that hold up.
The moment a Reportable finding fires, OSPulse starts the legal clocks: 24-hour early warning, 72-hour notification, and a final report within 14 days of a corrective measure (one month for a severe incident). Every stage assembles a submission-ready payload — pre-filled in the Single Reporting Platform’s own field order from the finding, the affected product and release, and your manufacturer details — with a full evidential trail from awareness to closure. ENISA provides no API, so a human files it: you review and submit, you don’t scramble.
A pre-filled SRP payload, not a blank template.
Most CRA tooling hands you a document to complete — a blank ENISA form, or a Word pack of the fields. OSPulse works the other way round: the payload assembles itself, pre-filled in the Single Reporting Platform’s field order from the real finding, the affected release, and the manufacturer details you set once. You review it and file it.
| Aspect | Fill-in template packs | OSPulse |
|---|---|---|
| What you get | A blank Word or PDF to complete | A pre-filled payload in ENISA SRP field order |
| “When did you become aware?” | A date you assert, after the fact | A timestamped, tamper-evident record that answers it for you |
| What fills it in | You, by hand, against the clock | The real finding, your product & release, and manufacturer details set once |
| From detection | A separate, manual job | A KEV hit on your dependency starts the pack |
| Every reporting stage | A fresh blank each time | Early warning, notification and final — each assembled |
| Your job | Write the whole thing | Review it and file it |
Early warning within 24 hours, notification within 72, a final report within 14 days of a corrective measure. OSPulse fills the payload for each; ENISA provides no API, so a human files it — evidence and a ready payload, not a claim that a tool discharges the obligation.
And when December 2027 arrives, you’re already there.
Reporting is only the CRA’s first act. Full application lands 11 December 2027: essential security requirements, technical documentation, CE marking. OSPulse’s Annex I readiness checklist tracks every requirement against linked evidence — so compliance is a byproduct of how you already ship, not a six-month archaeology project.
Built into your pipeline, not bolted onto your calendar.
Add a cra: block to your OSPulse CI policy and releases gate themselves: no SBOM, no ship; an unacknowledged Reportable finding, no ship — with baselines and expiring exceptions so day one doesn’t break every build.
Frequently asked
Does OSPulse make us CRA compliant?
No tool can. OSPulse gives you the inventory, monitoring, deadlines, and submission-ready evidence the CRA’s reporting duties demand — your team (and, for many firms, your counsel) makes the compliance decisions. We make those decisions fast and defensible instead of panicked.
We’re a UK company — does the CRA apply to us?
If you place products with digital elements on the EU market, yes, regardless of where you’re based.
Do we have to report every vulnerability?
No. The Article 14 duty covers actively exploited vulnerabilities and severe incidents affecting product security. That distinction is exactly what OSPulse’s classification engine is for.
We shipped our product years ago and barely touch it. Are we in scope?
If it’s still on the EU market, the reporting duties apply from 11 September 2026. OSPulse supports manual SBOM upload for products without an active pipeline.
Does OSPulse submit reports to ENISA for us?
No — and nobody else can either. ENISA provides no API for the Single Reporting Platform, so submission is manual. We export a submission-ready pack in the platform’s own field order for every reporting stage; a human still files it. We would rather say that plainly than promise an automation that does not exist.
While you’re in there: the same scan that answers the CRA answers the next deadline too. NIST deprecates RSA and ECC around 2030 — OSPulse’s Quantum Proofing Scanner already knows where yours are.
Get ahead of the clock.
Evidence and speed when a Reportable finding fires — not a scramble.