On 11 September 2026, Article 14 of Regulation (EU) 2024/2847 — the Cyber Resilience Act — becomes enforceable, and every manufacturer placing a product with digital elements on the EU market must be ready to file a structured early warning within 24 hours of becoming aware of an actively exploited vulnerability or a severe incident impacting product security. The receiving system is the Single Reporting Platform (SRP), a federated portal that ENISA has been procuring under public tender throughout 2025 and that must be live, secured, and load-tested before that date. The SRP collapses what could have been 27 national filing systems into a single interface — but the operational and engineering demands on manufacturers are significant, and most are still scoping them.
What changed in the reporting model?
Until September 2026, vulnerability disclosure obligations on European manufacturers are governed by a patchwork: NIS2 incident reporting for essential and important entities, GDPR Article 33 for personal-data breaches, sectoral rules under DORA for financial entities, and voluntary coordinated disclosure to national CSIRTs. The CRA introduces, for the first time, a horizontal obligation to notify on the vulnerability itself — independent of whether it caused a personal data breach or a service outage. Article 14(1) requires the manufacturer of a product with digital elements to notify "any actively exploited vulnerability contained in the product" and any "severe incident having an impact on the security" of the product. The cadence is three-stage: an early warning within 24 hours, an incident notification within 72 hours, and a final report within 14 days for vulnerabilities (one month for severe incidents).
The notification is filed once. The SRP then routes the report simultaneously to the CSIRT of the manufacturer's main establishment and to ENISA, which retains a coordinating and risk-aggregation role. National authorities receive the report through the same interface, removing the need for parallel filings — at least in principle.
Who is in scope and what counts as "actively exploited"?
The reporting obligation applies to any manufacturer that places a product with digital elements on the Union market, irrespective of where they are established. There is no de minimis exception based on revenue or company size, although microenterprises receive lighter documentation duties elsewhere in the CRA. Open source software stewards — a category defined in Article 24 — have a narrower set of obligations and notify only severe incidents affecting the security of their software, not all exploited vulnerabilities.
"Actively exploited" is defined in Article 3(40) as a vulnerability for which there is reliable evidence that a malicious actor has executed code on a system without permission, or has accessed, modified, or disrupted systems, services, or data. The threshold is lower than CISA KEV — there is no public catalogue requirement — and is intentionally fact-based. A single proof-of-concept that was demonstrably used in the wild qualifies. A theoretical exploit, even with high CVSS, does not.
"Severe incident" is defined as an event that negatively affects or is capable of negatively affecting the ability of a product to protect availability, authenticity, integrity, or confidentiality of data or functions. The distinction matters because the 24-hour clock starts when the manufacturer becomes aware — interpreted by the Commission's draft guidance as "first knowledge that meets a reasonable threshold of plausibility," not formal confirmation by an incident response team.
What does the SRP actually do?
ENISA published the technical specification of the SRP in autumn 2025 and procured a contractor under a public tender to build and operate the platform. The architecture is a federated portal with the following components:
- A secure web frontend and machine-to-machine API for filing notifications.
- A routing engine that dispatches each filing to the CSIRT of the manufacturer's main establishment and to ENISA in parallel.
- Strict information classification — manufacturers can mark fields as restricted (TLP:AMBER+STRICT equivalent) and ENISA is bound to confidentiality under Article 14(6) which allows withholding of disclosure if disclosure would aggravate risk.
- Audit logs and access control aligned to the NIS Cooperation Group's information-sharing standards.
The structured notification fields, per the draft implementing acts, include: product identifier and version range, CWE category, evidence of exploitation, affected user base estimate, mitigations available, and a planned disclosure timeline. The format will be machine-readable JSON aligned with CSAF 2.0 conventions where possible.
{
"notification_type": "early_warning",
"product": {
"name": "ExampleCloudAgent",
"vendor_id": "EU-MFR-12345",
"affected_versions": ">=2.1.0,<2.4.1"
},
"vulnerability": {
"cwe": "CWE-78",
"active_exploitation_evidence": "telemetry_from_honeypot",
"first_known_exploit_date": "2026-09-15T08:30:00Z"
},
"impact_scope": {
"estimated_affected_installations": 18500,
"geographies": ["EU-DE", "EU-FR", "EU-NL"]
},
"mitigations_published": false,
"planned_disclosure": "2026-09-29T12:00:00Z"
}
How are manufacturers preparing?
Larger vendors are wiring CRA reporting into existing PSIRT processes. The hard part is not the form — it is the 24-hour clock. Most security organisations measure mean-time-to-triage in days, not hours, and "becoming aware" is interpreted broadly in the Commission's draft guidance. A confidential bug bounty report that includes credible exploitation telemetry can start the clock even before internal validation completes.
Three workstreams are common in 2025-2026 readiness programmes:
- PSIRT runbook updates that introduce a "CRA early-warning gate" — a senior analyst empowered to file the 24-hour notice on their own authority, with legal review running asynchronously.
- Inventory hygiene so that every shipped SKU, firmware build, and microservice version is mapped to a product identifier the SRP can recognise. Vendors who cannot list their own products cannot file accurate notifications.
- API integration so that PSIRT case management tools (typically Jira, ServiceNow, or a custom system) can push notifications to the SRP without a human cutting and pasting fields at 3 a.m.
The smaller end of the market — embedded device makers, niche industrial software vendors — is less prepared. ENISA's own readiness survey, published in February 2026, found that roughly 41% of SMEs in scope had not identified an internal owner for CRA reporting.
What are the penalties and what should defenders do now?
Article 64 of the CRA sets maximum administrative fines of €15 million or 2.5% of worldwide annual turnover, whichever is higher, for breaches of the essential cybersecurity requirements. For breach of the reporting obligations specifically, the ceiling is €10 million or 2% of turnover. Member State market surveillance authorities — the CRA's enforcement arm — also have powers to order withdrawal or recall of non-compliant products under Article 54.
For defenders, four concrete steps cover most of the gap before September 2026:
- Identify and name a CRA Reporting Owner in your PSIRT, with delegated authority to file the 24-hour notification.
- Build a CRA product registry that ties every shipped SKU to a stable product identifier, SBOM, and PSIRT contact.
- Pre-register your organisation with the SRP during ENISA's planned 2026 onboarding window — the Commission has signalled this will open three to six months ahead of go-live.
- Test the M2M API path. The SRP exposes a sandbox; treat it like an interbank settlement system, not a forms portal, and dry-run the JSON payloads end-to-end before September.
How Safeguard Helps
Safeguard's SBOM ingestion pipeline maps every product version to a stable identifier and links it to known vulnerabilities, so when a CRA reporting event is triggered, the affected-version range is generated automatically rather than reconstructed under a 24-hour clock. Griffin AI reachability analysis filters PSIRT signal: a high-CVSS finding in a dependency that is not reachable in your built artifact does not start the active-exploitation clock, but a reachable one does, and the platform tells you which is which. VEX support lets manufacturers publish machine-readable status statements alongside CRA notifications, satisfying the Article 14 requirement to communicate mitigations to users. Policy gates can be configured to block release of a build whose dependency manifest contains an active KEV entry, reducing the rate at which CRA-reportable events emerge in the first place. Together these features compress mean-time-to-file from days to hours and produce the structured evidence the SRP will demand from day one.