Since 11 September 2026, manufacturers must report actively exploited vulnerabilities and severe incidents EU-wide — early warning within 24 hours, via ENISA's Single Reporting Platform (SRP). We get you ready to report before the clock starts for you for the first time.
The Cyber Resilience Act does not apply in full until December 2027 — but the reporting obligations under Article 14 have applied since 11 September 2026, 15 months earlier. Since then, 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 has been live since 11 September 2026; in Germany, CERT-Bund at the BSI is the coordinating CSIRT.
Early warning and notification 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 without the system owner's permission. 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.
Registering in advance is not mandatory — in an emergency, registration and submission take a few minutes. Your CSIRT verifies representatives in parallel without holding up reports; however, the primary representative can only invite further representatives once verified.
According to ENISA, there is still no API: every report is entered manually in the web form — in three stages with common fields plus vulnerability- or incident-specific fields, and in English. Prepared English 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.
Since launch, the BSI has offered a video tutorial on using the SRP. If the platform is unavailable, CERT-Bund accepts mandatory reports by e-mail as an exception. Submitted reports can be updated until the final report.
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 English 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. Since 11 September 2026, the Article 14 obligation has applied 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 (Art. 3(42) CRA). A credible external report, for instance from a CSIRT or a customer, can start the clock. Findings from security research or bug bounty programmes without any sign of malicious exploitation, by contrast, are not subject to mandatory reporting.
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 yet. According to the ENISA FAQ, the SRP launched without an API; one may be considered in a later phase. Reports are entered manually in the web form — in English. 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, CERT-Bund at the BSI is the coordinating CSIRT; 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.
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.
As soon as you log an incident or an actively exploited vulnerability, VamiGRC starts the relevant reporting workflows, tracks the deadlines and creates prepared notifications for BSI and ENISA that your team reviews and submits itself.
In a no-obligation initial consultation we clarify where your portfolio stands, which gaps put the 24-hour deadline at risk and how you become ready to report quickly.
