Regulation (EU) 2024/2847 · Article 14

CRA vulnerability reporting and incident response automation

Eight of the ten stages between a vulnerability arriving and an authority notification leaving can be driven by software. Two cannot, and knowing which two is the difference between a working process and an expensive one. This page maps the chain stage by stage with an explicit verdict on each, then shows what we built for the automatable parts.

The short answer

Intake, acknowledgment, enrichment, clock start, deadline tracking, package assembly, advisory generation and the evidence record are all automatable and should be automated, because each of them fails quietly when done by hand under a 24-hour clock. The exploitation judgement is not automatable, because someone has to decide and sign that a vulnerability is being actively exploited. The filing is not automatable either, because the Single Reporting Platform exposes no manufacturer submission API. Nobody has that feature.

The practical target is therefore not a hands-off pipeline. It is getting the manual step down to a person reviewing an assembled package and pressing submit, with the deadline still hours away rather than minutes.

The chain, stage by stage

From a report arriving to a notification leaving, with an honest verdict on each stage.

Stage	Verdict	What that means
Intake	Automatable	A branded HTTPS portal and a monitored address under your own domain, structured submission fields, PGP support, and safe-harbour language. Every report lands in one queue with a timestamp that later becomes evidence.
Acknowledgment	Automatable	Automatic receipt to the reporter and a tracked acknowledgment SLA, so the Article 13 single point of contact demonstrably works rather than merely existing.
Enrichment	Automatable	CVE and GCVE correlation, EPSS scoring, and known-exploited catalogue matching pulled in automatically against the reported identifier, so the exploitation question arrives at a human with the evidence already attached.
The exploitation judgement	Human	Deciding that a vulnerability is actively exploited, or that an incident is severe, is a determination a person makes and signs. Enrichment can present every signal. It cannot make the call, and a tool that claims to is creating liability rather than removing it.
Clock start	Automatable	The moment a case is marked exploited, the 24-hour, 72-hour and final-report timers start together and run visibly, with the awareness determination and its timestamp recorded as the anchor for all three.
Deadline tracking	Automatable	Hard timers per stage with escalation before each one lapses. The 14-day final-report clock for a vulnerability runs from a fix being available, and the one-month clock for an incident runs from the 72-hour notification, so they are tracked as different clocks rather than one.
Triage and remediation	Partly	CVSS scoring, severity workflow, assignment, status transitions and reporter correspondence are all driven by the system. The engineering judgement inside them is not.
Package assembly	Automatable	The submission package is built in the shape the Single Reporting Platform asks for at each stage, carrying forward the fields that migrate from mandatory to confirmed, so nothing is retyped between 24 hours and the final report.
The filing itself	Human	ENISA exposes no manufacturer submission API for the SRP. A person submits the package and records the reference. Every vendor is in the same position on this, whatever the marketing says.
Advisory and evidence	Automatable	A CSAF 2.0 machine-readable advisory on remediation, and a timestamped, exportable record of every intake, acknowledgment, status change and submission for the retention obligation.

Three claims to check before you buy anything

Each of these is a common vendor position that the Regulation or the platform contradicts.

Nobody can file to the SRP automatically

Article 14(7) routes notifications through the platform established under Article 16, and ENISA does not currently expose a submission API for manufacturers. Automated filing is not a feature any vendor has, because the receiving end does not accept it. Treat a claim of automatic filing as a reason to ask harder questions.

Automation does not lower the reporting threshold

The mandatory trigger is active exploitation, not severity. A critical-scoring vulnerability nobody is using carries no Article 14 duty, and a modest-scoring one being used in real attacks starts the clock immediately. Tooling that reports on CVSS alone will bury your coordinating CSIRT and train your team to ignore the timer.

The clock does not start when the report arrives

It starts on awareness, which Commission guidance C(2026) 5252 defines as reasonable certainty after an immediate initial assessment. That leaves a short documented triage window before the timers run. A system that starts the clock on intake will show you deadlines that are not real.

What we built

CVD Portal runs the automatable eight. A whitelabel disclosure portal on your own subdomain handles intake and acknowledgment, enrichment correlates the report against CVE, GCVE, EPSS and known-exploited data, marking a case exploited starts all three Article 14 timers against a recorded awareness moment, and the submission package is assembled in the platform's own field shape and carried forward between stages.

The property that matters is where those pieces sit. The vulnerability intake that produces the Article 14 trigger and the CRA workspace that classified the product live in the same account, so a report arriving at the weekend starts a clock against a product whose class, support period and Annex I position are already recorded. That is the join most setups are missing, because the disclosure inbox and the compliance spreadsheet were bought separately.

Receiving and tracking reports is free. The Article 14 filing package, CSAF 2.0 advisory export and the compliance workspace sit on the paid tiers. EU data residency by default.

Full feature list →How it works →Pricing →Buyer's guide to the category →

Frequently asked

Can CRA vulnerability reporting be automated?

Most of it, but not the filing. Intake, acknowledgment, CVE and exploitation enrichment, clock start, deadline tracking, triage workflow, package assembly, CSAF advisory generation and the evidence record can all be driven by software. Two steps stay human. The judgement that a vulnerability is actively exploited or an incident severe is a determination a person makes and signs. And the submission itself is manual, because ENISA exposes no manufacturer API for the Single Reporting Platform.

Is there an API for filing CRA reports to ENISA?

Not at this stage. Article 14(7) routes notifications through the single reporting platform established under Article 16, and ENISA does not currently offer a submission API to manufacturers. The filing is one manual step for everyone. What tooling can do is make that step take minutes by having the package assembled, the fields carried forward and the deadlines already tracked when you get there.

What is CRA incident response automation?

Driving the Article 14 chain from a vulnerability arriving to an authority notification leaving, with the deadlines enforced by the system rather than by memory. In practice that means intake under your own brand, automatic acknowledgment, exploitation enrichment against CVE and known-exploited data, hard 24-hour, 72-hour and final-report timers that start on the recorded awareness moment, a triage workflow, and a submission package built in the platform's own shape.

When do you need this in place?

Before 11 September 2026, when Article 14 enters application. That is roughly 15 months ahead of the rest of the Regulation. The awkward part of the ordering is that the Article 13 obligations, including the coordinated vulnerability disclosure policy and the single point of contact, do not formally bind until 11 December 2027. The duty that depends on having a disclosure process therefore lands more than a year before the duty to run one.

Does this replace a bug bounty platform?

They solve different problems. A bug bounty platform is built to attract and pay researchers, and it is good at that. The CRA obligations are about a documented single point of contact, an evidenced acknowledgment and handling process, a defensible awareness determination, and a submission package for an EU authority on a fixed clock. A programme can feed the first of those. It does not produce the rest.

What makes this different from a general GRC tool?

A GRC tool models controls and evidence in the abstract and expects you to define the framework. The Article 14 chain is not a control framework, it is an operational clock attached to a live security event. The distinguishing property is whether the vulnerability intake that produces the trigger and the CRA product record that was classified sit in the same account, so that a report arriving on Friday evening starts a timer against a known product rather than against a spreadsheet row.

Start the clock on something that can carry it

Set up a branded disclosure portal, connect it to your product records, and have the Article 14 timers ready before 11 September 2026 rather than during the first case that needs them.

Intake and tracking are free. No card required to start.

Set up your free portal Check your current exposure

CVD Portal supports CRA compliance work but does not provide legal advice and does not by itself establish conformity or a presumption of conformity. It is an independent platform, not affiliated with or endorsed by the EU or ENISA.