From September 11, manufacturers of connected products must report actively exploited vulnerabilities to ENISA within 24 hours of becoming aware. We set up the process, then run the daily watch — so the first time you hear about a KEV hit, you already have everything you need to respond.
Article 14 CRA — mandatory from September 11, 2026. The 24-hour window starts the moment you become aware of active exploitation — regardless of whether you have confirmed it internally.
An SBOM file is the starting point, not the finish line. Article 14 requires that you can query your SBOM against live vulnerability feeds, determine which products are affected, assess whether exploitation is active, and file with ENISA — all within 24 hours. A spreadsheet cannot do this at 2am on a Friday.
The regulation is explicit: "becomes aware" is a low bar. A market surveillance authority will ask what monitoring process was in place. "We had no process" is not a compliant answer — it is evidence that you could not have become aware, which is itself a violation. The obligation to monitor is implicit in the obligation to report.
Two weeks to set up a documented, tested vulnerability monitoring process — with signed delegation, escalation path, and pre-filled ENISA templates. Then we keep watching: daily automated scans against your component inventory, immediate alerts on actively exploited vulnerabilities, dated evidence for your audit file. You own the process. We operate the watch.
The fine ceiling is €15 million or 2.5% of global annual turnover. But the operational cost lands first: a crisis-mode legal review of a missed 24-hour window, the scramble to reconstruct what components were in which products, the reputational cost of a late or incomplete filing. This engagement costs less than one hour of that review.
Your component inventory is checked against the OSV vulnerability database and the CISA Known Exploited Vulnerabilities catalogue. Every day. No human in the loop. Results are stored with timestamps for your audit trail.
If a component you ship is confirmed as actively exploited, your designated reporter receives an email within minutes — not hours, not days. The email names the affected component, the CVE, which of your products are impacted, and what to do next. Your 24-hour clock starts at the timestamp of that email.
A dated report covering every scan, every finding, and every assessment for the month. Filed in your shared folder. When a market surveillance authority asks what monitoring was in place, you hand them this.
You install nothing. You run no tools. The watch runs whether you are in the office, on holiday, or asleep.
requirements.txt, package-lock.json, a Yocto manifest, or a spreadsheet — whatever form it currently exists in. If you have nothing, that is also an answer, and we start from there. We generate a machine-readable SBOM and run the first vulnerability scan.
One scoping call to map your connected products and who handles incidents. One working session to walk through the 2am scenario end to end — detection, triage, 24-hour filing. Around three hours of your team's time across the two weeks.
Your team reviews the document pack, signs the designated-reporter delegation, and files it in your quality system. Daily monitoring goes live. From that point: you do nothing until something hits — and when it does, everything is already in place.
Dated baseline: what components you ship, which carry known vulnerabilities, which are confirmed as actively exploited. Establishes your starting position on a specific date.
Your SBOM in CycloneDX format, queryable against vulnerability feeds — plus the procedure for keeping it current on every release.
The core procedure defining awareness triggers, monitoring inputs, triage decisions, and the full reporting cascade. Written in QMS format with document control and approval signatures.
Signed delegation naming who may submit an ENISA notification without further approval, with the limits of that authority stated explicitly. The document that evidences "without undue delay."
One page, three questions. Is the component in a marketed product? Is it actively exploited? Is it reachable as shipped? Designed to be printed and put on a wall.
Three pre-filled templates matching the 24-hour early warning, the 72-hour notification, and the 14-day final report. Your reporter completes a form, not composes one.
Dated evidence that the procedure was tested with the people who would actually run it, including gaps surfaced and how they were closed.
A drop-in section for your CRA technical documentation, formatted to sit alongside your existing CE marking evidence.
The running record of every scan, every finding, every assessment. Populated automatically by the daily watch. This is how you demonstrate you had the capability to become aware.
Delivery is one engagement at a time. Capacity before September 11 is limited to six engagements.
Your team built the product. Nobody built the incident response process. You need a documented, tested reporting workflow and someone watching the feeds — before September 11, not after the first fine.
You have connected products on the EU market. You are not certain your SBOM is queryable or your reporting path is clear. This produces an honest gap assessment, closes the critical ones, and keeps watching after the assessment is done.
You need CRA Article 14 readiness before September. You do not have a dedicated PSIRT or security team. This engagement is designed for exactly this situation: a working process delivered in two weeks, with ongoing monitoring so the process stays operational — without building internal capability you don't yet need.
CRA Article 14 reporting begins September 11. NIS2 incident reporting follows a compatible cascade structure — 24h early warning, 72h notification, final report. A process built for CRA Article 14 satisfies the NIS2 reporting workflow for the same incident. One engagement addresses both.
A cybersecurity consultant maps your gaps against a checklist and tells you what to fix.
A legal firm explains what Article 14 requires and what the fines are.
Neither builds the process, watches your components every day, and wakes your reporter when something hits.
The combination that makes this work is specific: a physicist who has spent 15 years inside regulated industry development —
at the intersection of engineering, compliance, and data infrastructure — and who understands both what the
regulation requires operationally and how connected-product engineering actually works.
Firmware SBOMs are structurally different from web-application dependency trees.
Vulnerability triage for an embedded RTOS is different from patching a cloud service.
The process reflects that.
You own the process and the evidence. We operate the daily watch. No lock-in — the procedure, the delegation, and the documents are yours regardless.
A 30-minute call to understand your product landscape, your current SBOM status, and whether this is the right next step. No commitment. Honest answer even if this is not the right fit.
AI model in a medical device facing an EU AI Act deadline?
RE:MARK SaMD AI Validation →