From 11 September 2026, manufacturers must report actively exploited vulnerabilities and severe incidents EU-wide — early warning within 24 hours, via ENISA's new Single Reporting Platform (SRP). We get you ready to report before the clock starts for the first time.
The Cyber Resilience Act does not apply in full until December 2027 — but the reporting obligations under Article 14 start 15 months earlier. From 11 September 2026, manufacturers of products with digital elements must report two types of events: actively exploited vulnerabilities in their products and severe incidents having an impact on product security. The obligation is product-based — it also covers products that have been on the market for years. There is no grandfathering for reporting.
Reports are submitted via the Single Reporting Platform (SRP): a central reporting platform operated by ENISA that automatically forwards each notification to your coordinating national CSIRT, to the CSIRTs of all member states where the product is made available, and to ENISA itself — report once instead of up to 27 times. The platform goes live on 11 September 2026; ENISA published the accompanying documents (factsheet, FAQ and user guides) on 31 July 2026.
All deadlines run from awareness (“becoming aware”) — not from remediation. Weekends count.
Within 24 hours of becoming aware: a brief notification to the coordinating CSIRT and ENISA — so that warnings reach others before the exploitation wave rolls.
Within 72 hours: general information and an initial assessment — severity, impact and, where already available, corrective or mitigating measures taken.
For vulnerabilities no later than 14 days after a corrective measure is available; for incidents one month after the 72-hour notification: root causes, timeline and countermeasures.
Two reportable events, one reporting channel: ENISA's Single Reporting Platform.
There is reliable evidence that an attacker has exploited a vulnerability in your product — regardless of whether the attempt was successful. Evidence can come from your own telemetry, reports from CSIRTs, customers or security researchers, or entries in exploit catalogues.
An incident is severe if it affects — or is capable of affecting — the product's ability to protect sensitive or important data and functions, or if it has led or could lead to the introduction or execution of malicious code. Potential is enough: compromised build servers and update channels are the textbook case.
The SRP routes your notification to the CSIRT designated as coordinator, makes it simultaneously available to ENISA and disseminates it without delay to the CSIRTs of all member states where the product is available. Market surveillance authorities receive selected information for their oversight.
The platform is designed for confidentiality. Dissemination can only be delayed in justified exceptional cases — for instance when a patch is imminent — and at the CSIRT's discretion (Art. 16(2) CRA, Delegated Regulation (EU) 2026/881). There is no opt-out for manufacturers.
The platform itself is deliberately lean — the real preparation happens on your side.
Access to the SRP requires an EU Login account. Set up accounts for at least two people and define deputies — real incidents don't respect holiday schedules.
After first access, your CSIRT validates the designated representatives — according to the ENISA FAQ, in parallel with the reporting process. Submitting a report is not held up by it.
According to the ENISA FAQ, the SRP will not provide an API at this stage: every report is entered manually in the web form — in three stages with common fields plus vulnerability- or incident-specific fields. Prepared text modules and a field mapping are your speed lever.
After an incident or an exploited vulnerability, you must also inform impacted users without undue delay — including risk information and remedies. If you fail to do so, the CSIRT can inform your users itself.
ENISA plans a testing phase before go-live and an onboarding webinar around two weeks before the platform enters service. Use both — with prepared reporting packages, 11 September becomes just another working day.
CRA and NIS2 report different things to different bodies. One event can trigger several obligations at once.
The manufacturer reports actively exploited vulnerabilities and severe incidents affecting the product — via the SRP to the CSIRT and ENISA, on a 24 h / 72 h / 14 days or 1 month cadence.
Operators of essential and important entities report significant incidents affecting their organisation via national channels (in Germany: BSI) — on a 24 h / 72 h / 1 month cadence.
Ransomware at a software vendor with an affected update server can trigger CRA, NIS2 and GDPR notifications at once — plus DORA in the financial sector. The SRP only takes the CRA report off your hands: build a reporting map with one shared process.
Six steps that make the 24-hour deadline reliably achievable.
Build a product inventory and assess CRA applicability per product — include legacy products, because the reporting obligation has no grandfathering.
Derive your competent CSIRT from your main establishment (Art. 14(7)), create EU Login accounts for at least two people and define deputy rules.
Specify internally when “awareness” exists, who determines it and how the timestamp is documented — it anchors every deadline. Arrange weekend availability.
Map the SRP form fields to internal data sources, prepare text modules for the 24-hour and 72-hour notifications and obtain approvals in advance — no committee loops in an emergency.
Run a tabletop exercise against the clock with a realistic scenario — including user communication under Art. 14(8) and the inconvenient Friday-evening case.
Set up component monitoring (e.g. the EU vulnerability database EUVD, CISA KEV), keep your SBOM current and contractually secure your suppliers' duty to inform you.
Concise answers — we cover your specific products in an initial consultation.
Yes. From 11 September 2026, the Article 14 obligation applies product-based — including products already on the market. The remaining CRA obligations, such as CE marking, apply from 11 December 2027.
Upon awareness (“becoming aware”): as soon as your company learns of the active exploitation or the severe incident. Not upon remediation, and not after internal sign-off — which is why awareness triggers and the reporting process must be defined and documented in advance.
There is reliable evidence that an attacker exploited the vulnerability without the system owner's consent, or attempted to — whether the attack succeeded is irrelevant (Art. 3(42) CRA). A credible external report, for instance from a CSIRT or a customer, can start the clock.
For severe incidents, potential is enough: even if the incident is merely capable of affecting the product's ability to protect data and functions, or could enable execution of malicious code, it is reportable (Art. 14(5)). When in doubt: report — a notification is not an admission of fault.
Not at launch. According to the ENISA FAQ, the SRP will initially operate without an API — reports are entered manually in the web form. That makes prepared text modules, a field mapping to your internal data and rehearsed procedures all the more important.
In principle, the CSIRT of the member state of your main establishment — where the essential cybersecurity decisions for your products are taken (Art. 14(7)). Without an EU establishment, the cascade runs via authorised representative, importer and distributor. In Germany, the BSI is the central point of contact; ENISA publishes the official CSIRT list.
Fines of up to €15 million or 2.5% of worldwide annual turnover — whichever is higher — plus market surveillance measures up to and including recalls. And if you fail to inform impacted users yourself, the CSIRT can do it for you — without your tone of voice.
From readiness check to a rehearsed 24-hour notification — pragmatic, product-focused, audit-proof.
Product portfolio, applicability and gaps assessed compactly: scope, reporting capability and vulnerability management — with a prioritised action plan up to 11 September.
Define awareness triggers, roles and escalation paths, prepare EU Login access and CSIRT assignment, create field mappings and text modules for 24-hour and 72-hour notifications.
Build or sharpen your product security incident response team: CVD policy, vulnerability contact point, SBOM maintenance and exploit monitoring as a reliable source of awareness.
We rehearse the real case against the clock — including the 72-hour assessment, the final report and user communication under Art. 14(8). Afterwards, every role knows its part.
When it happens: support with assessment, containment and on-time reporting — technical and regulatory from one team.
Reporting obligations today, Annex I requirements and conformity assessment tomorrow: we accompany you all the way to CE marking — as a project or as GRC as a Service.
In a no-obligation initial consultation we clarify where your portfolio stands, which gaps put the 24-hour deadline at risk and what your roadmap to 11 September looks like.
