News · By Chris · 31 Jul 2026 · 3 min read
No API at launch: the CRA's 24-hour clock will be met by a human filling in a form
ENISA has confirmed the Single Reporting Platform will ship without an API. CRA vulnerability reporting from 11 September 2026 is manual web submission only, which changes who needs to be available at 2am on a Sunday.
Buried in ENISA’s Single Reporting Platform documentation is one line that quietly rewrites a lot of incident-response plans:
no Application Programming Interfaces will be provided at this stage
No API. From 11 September 2026, when CRA vulnerability and incident reporting becomes mandatory, notifications are submitted by hand through a web portal. That is the whole mechanism.
Why this matters more than it sounds
The CRA gives you 24 hours from becoming aware of an actively exploited vulnerability or a severe incident to file an early warning. Then 72 hours for a fuller notification, then 14 days for the final report.
Most teams that have been planning for this assumed some form of integration: a webhook from the vulnerability scanner, a step in the incident-response runbook that posts a payload, something that fires from the tooling they already run. That assumption is now wrong.
The practical translation is blunt. A named human, holding valid credentials, has to log into a web portal and fill in a form, within 24 hours, whenever a qualifying vulnerability surfaces. Including at 2am. Including on a Sunday. Including during the week in August when the person who normally does it is on a beach.
Four things this changes
Your rota is now a compliance control. If exactly one person can file, you have a single point of failure with a 24-hour SLA attached to it. That needs at least two trained people, realistically three for holiday and sickness cover.
Credentials become a prerequisite, not an afterthought. Reporting requires an EU Login account, and you can create one today. This is the single most useful thing you can do before September, and it costs nothing. Do not discover on the day of an incident that nobody has an account.
Your runbook needs the form fields in it. ENISA has published which fields are obligatory, optional and conditional at each of the 24-hour, 72-hour and final stages. Product Type and Product Category are optional at 24 hours but conditional by the 72-hour stage, so you want your product classification settled in advance rather than being worked out under pressure. If you have not done that, our free compliance check takes a couple of minutes.
Automation moves upstream. You cannot automate the submission, but you can automate everything that feeds it. Continuous SBOM generation and scanning is what tells you a qualifying vulnerability exists in the first place, and it is what populates the affected-component fields when you do sit down to type. That work still pays off. See the SBOM tutorial for the mechanics.
One counterintuitive detail
ENISA’s guidance says validation that a representative may report on behalf of a manufacturer happens after first access, in parallel with the reporting process, and does not block your ability to submit.
Their advice is to initiate validation when you actually need to file, rather than everyone registering early and overwhelming CSIRT workloads. That runs against the usual “get registered well in advance” instinct, so it is worth reading their guidance rather than assuming.
To be clear on the distinction: create the EU Login account now, because that is a genuine prerequisite. The CSIRT validation step is the one ENISA would rather you did not rush.
The short version
Reporting starts 11 September. There is no API. Make sure more than one person can log in, knows what the form asks for, and can be reached out of hours. That is the whole preparation, and it is not hard, but it does need doing before rather than during your first incident.