Who reports to ENISA now, and since when?
Manufacturers of products with digital elements, which covers standalone software as well as connected hardware, have had to report two things since 11 September 2026: actively exploited vulnerabilities in their products and severe incidents affecting product security. That is Article 14 of Regulation (EU) 2024/2847. The rest of the Cyber Resilience Act, including essential requirements, conformity assessment and penalties, applies from 11 December 2027.
Reporting arrived fifteen months before everything else.
Three details in the scope catch teams out. The duty covers every in-scope product, not only those classed as important or critical (Eversheds Sutherland, 10 September 2026). It covers legacy products already on the EU market and continues after a product's support period ends. And there is no retroactive duty: exploitation you knew about before 11 September 2026 does not have to be reported, although new exploitation of the same flaw does (Hogan Lovells, 11 September 2026).
We are engineers, not lawyers. Check your product scope with counsel; this article covers what has to exist in your systems once scope is settled.
24 hours, 72 hours, 14 days: what each deadline needs from engineering
The clock starts when you become aware of active exploitation. An early warning is due within 24 hours, a notification with the nature of the exploit and the corrective measures within 72 hours, and a final report no later than 14 days after a fix or mitigation is available. For severe incidents the final report is due one month after the 72-hour notification (Article 14(2) and (4); Crowell, 11 September 2026).
Read those as engineering deliverables. Within 24 hours you need to know which product and which versions are affected and in which Member States they are sold. That is an inventory question, and nobody answers it from memory at 2 a.m. At 72 hours the authority wants a description of the vulnerability and what users can do. That is a triage write-up plus a mitigation, even a config flag. The 14-day final report needs severity, impact and the details of the fix, so your release notes and CVE record must already exist.
Article 14(8) adds a duty that most teams forget: affected users must be told about the vulnerability and the mitigations, in a structured, machine-readable format. If a manufacturer is too slow, the coordinating CSIRT may inform users itself (Eversheds Sutherland). We would rather write that advisory ourselves.
The reporting clock, stage by stage
| Stage | Deadline | What you need on hand |
|---|---|---|
| Early warning | 24 h from awareness | Affected product and versions, Member States where it is sold, an Assigned Representative who can log in |
| Vulnerability notification | 72 h from awareness | Nature of the exploit, affected components from the SBOM, corrective or mitigating measures available to users |
| Final report (vulnerability) | 14 days after a fix or mitigation is available | Severity and impact, known malicious actor if any, details of the security update |
| Final report (severe incident) | 1 month after the 72 h notification | Root cause, impact, mitigation applied and ongoing |
| User notice | Without undue delay after awareness | Machine-readable advisory with mitigations for affected users |
One report, one EU Login account, one named person
The Single Reporting Platform (SRP) means you file once. The notification goes to the CSIRT designated as coordinator, normally in the Member State of your EU main establishment, and is made available to ENISA at the same time; the coordinator forwards it to CSIRTs in every other country where the product is sold (ENISA, 11 September 2026). The operational consequence is that a person, not a team, submits. The SRP calls that role the Assigned Representative: one primary and up to 20 secondary ARs, each with an individual EU Login account protected by multi-factor authentication (Crowell; Help Net Security, 14 September 2026).
Some launch constraints shape the tooling. The platform had no API at launch, so reports are typed into a web form. It allows only one notification per event even if several product lines are hit. It started in English only. Choosing the wrong coordinating CSIRT can invalidate a report and force a resubmission.
According to Crowell, ENISA advises against registering as a manufacturer before you have something to report, and Eversheds notes that registration takes minutes, with the CSIRT validating the AR afterwards. What cannot wait is the EU Login account with MFA set up on a phone that the on-call person actually carries. What we set up: two named ARs in different time zones, and a quarterly login test in the on-call calendar.
What has to be in the repo and the pipeline before the clock starts?
Four things: an SBOM generated on every release build, a job that matches it against advisory feeds, a triage step that decides whether a match is actively exploited in your product, and an evidence log with timestamps. The formal SBOM duty (Annex I, Part II) applies only from 11 December 2027 and asks for at least the top-level dependencies in a commonly used, machine-readable format, kept in the technical documentation and not published (Anchore, updated 7 October 2026). Without one today, though, you cannot answer the 24-hour question of which versions are affected.
Our default is CycloneDX JSON generated in CI. CycloneDX 1.7 was released on 21 October 2025 and is the current spec. SPDX works as well; pick one and keep it. The SBOM is stored per release tag, because the question after an advisory is always "which shipped versions contain this", and the main branch cannot answer it.
The top-level minimum is thinner than it sounds. When we counted our own corporate site (a Laravel application), composer.json lists 6 runtime packages while composer.lock pins 80. The front-end has 12 direct dev dependencies and 254 entries in package-lock.json. A top-level SBOM would show roughly one PHP package in thirteen. We record the full tree; the legal minimum is not a useful engineering minimum.
Matching is the cheap part: composer audit, pip-audit, npm audit or OSV-Scanner on the stored SBOM, run nightly against every supported release, not only main. The CISA Known Exploited Vulnerabilities catalog is a useful exploitation signal. A third-party count put it at 1,733 entries on 2 October 2026, with 249 added in 2026 so far, already more than the 245 added in all of 2025 (The Uptime Report). A KEV listing does not prove your product is being exploited, though. HLC's reading of the Commission guidance is that for a flaw in a third-party component, the manufacturer reports only when it is actively exploited in its own product.
That last judgment is the expensive one, and it is human. We put a named owner on call for it, with a written definition: reliable evidence of exploitation by a malicious actor, which is how Eversheds paraphrases the regulation.
Legacy releases and open-source dependencies stay in scope
A product you sold in 2023 and stopped supporting in 2025 is still reportable if exploitation comes to light after 11 September 2026. For teams with old PHP or Python releases in the field, that changes the cost of a dead branch. You may not have to fix it, but you must be able to tell which customers run it and notify them.
EOL runtimes make the matching job noisier: advisory feeds stop listing fixed versions for branches nobody patches, so the scanner reports a hit with no upgrade path. We treat "no fix available on this branch" as a decision for the product owner, recorded in the evidence log, and usually the trigger for the upgrade conversation we describe in Legacy PHP: upgrade, strangle or rewrite.
Open-source software stewards (foundations and similar bodies that support open-source projects used in commercial products) get their own reporting duties from 11 December 2027 (ENISA). Until then, the maintainer of a library you depend on owes the SRP nothing. You do, if the flaw is exploited in your product.
A minimal runbook in about fifteen lines of Python
The runbook does two things: it pins the awareness timestamp the moment the on-call owner confirms exploitation, and it turns the triage record into a draft the AR can paste into the SRP form. Since the platform has no API, a draft for a human to paste is as far as automation goes.
from datetime import datetime, timezone, timedelta
from dateutil.relativedelta import relativedelta
def cra_clock(aware_at, kind, fix_at=None, notified_at=None):
d = {"early_warning": aware_at + timedelta(hours=24),
"notification": aware_at + timedelta(hours=72)}
if kind == "vulnerability" and fix_at:
d["final_report"] = fix_at + timedelta(days=14)
if kind == "incident" and notified_at:
d["final_report"] = notified_at + relativedelta(months=1)
return d
def early_warning(t): # t = triage record from the ticket
return (f"Product: {t['product']} {', '.join(t['versions'])}\n"
f"Exploitation evidence: {t['evidence']}\n"
f"Member States: {', '.join(t['markets'])}\n"
f"Aware at (UTC): {t['aware_at']:%Y-%m-%d %H:%M}")
The markets list comes from the sales or licence database, not from the engineer's memory. The deadlines go into the incident ticket as due dates with pages at 50% and 80% of each window. Store aware_at in UTC. The 24-hour window ignores summer time, and the coordinating CSIRT may sit two time zones away from your on-call engineer.
What we would do next time
We would start with the EU Login accounts and the market list. They take an afternoon, and without them the most complete SBOM in the world still misses the 24-hour window. The pipeline work comes second, and the one-off audit of releases still running in the field comes third. If you also ship AI features, the transparency duties are a separate timeline; we covered them in EU AI Act after the Omnibus, and agent tool servers deserve the same inventory discipline described in MCP servers in production.
We run a two-week CRA readiness audit of a delivery pipeline: SBOM generation, advisory matching across supported releases, and a reporting runbook your AR has rehearsed once. See our security services or get in touch.