CRA reporting obligations: Why manufacturers cannot wait until 2027
CRA reporting duties have applied since 11 September 2026. Understand the reporting stages, affected manufacturers and the decisions needed before using the SRP.
A vulnerability is being actively exploited. Your product might be affected. Engineering checks the versions while someone looks for the reporting channel. Who decides whether a report is required, and who owns the next step?
For manufacturers in scope, this is already a live question. Reporting duties under Article 14 of the Cyber Resilience Act (CRA) have applied since 11 September 2026. The main requirements taking effect in December 2027 do not postpone this part. The European Commission explains the reporting obligations here.
Which CRA reporting obligations already apply?
Article 14 concerns manufacturers of products with digital elements within the CRA's scope. It covers actively exploited vulnerabilities in those products and severe incidents affecting their security. A vulnerability report or an IT outage does not automatically trigger the same notification.
The ENISA FAQ updated on 15 October also distinguishes the parties concerned: the corresponding duties for open-source software stewards under Article 24(3) apply from 11 December 2027. Manufacturers, open-source projects and individual contributors are not interchangeable categories.
Start with the product, your organisation's role and the specific facts. Asking only whether your company falls under NIS2 misses the product-security question.
Still unsure about scope? Our interactive CRA scope check walks through product connections, market supply and your role, including a separate branch for cloud services.
24 hours, 72 hours — and then?
The Commission describes an early warning within 24 hours of awareness, followed by notification within 72 hours. Final-report deadlines differ:
- For an actively exploited vulnerability: no later than 14 days after a corrective measure becomes available.
- For a severe incident: within one month after the 72-hour notification.
This gives the timing structure. Awareness and the information required need to be assessed against the actual facts. ENISA refers to Commission guidance for interpretation and explains the fields required at each reporting stage. An incomplete initial picture should remain visible in the internal case rather than disappearing between teams.
A decision process comes before the portal
The Single Reporting Platform (SRP) has operated since 11 September 2026. It provides the submission channel to the relevant authorities. It receives the notification; it does not carry out your internal assessment.
Test your process with a worked example: a notice concerns a library used in several released product versions. It is not yet clear which version is exposed or whether the reported exploitation affects your product.
| Step | What your team should establish |
|---|---|
| Capture the signal | Record the source, receipt, known facts and open questions. |
| Check affected products | Identify the product, versions, component and available technical findings. |
| Assess the facts | Examine each potentially applicable reporting trigger and document the reasoning. |
| Assign responsibility | Name the decision owner, reporting person and deputy; assign deadlines to open work. |
| Maintain the case | Connect new findings, mitigation and later reporting stages to the original record. |
This is our organisational working aid, not an official checklist. Use it to test the handovers. Sharing the portal link alone does not identify affected products or establish an accountable decision.
Practical details of the SRP
ENISA describes submissions by Assigned Representatives associated with the manufacturer. They can work on notifications within their permissions. One handover detail matters: draft notifications are stored in the individual representative's account and are not visible to other representatives, according to the FAQ. A deputy should not discover that limitation during an incident.
ENISA also advises initiating the manufacturer association and validation when a notification is needed; having an active EU Login account helps. Preparation therefore does not mean registering every association in advance contrary to that guidance. Establish responsibility, EU Login readiness and the internal workflow first.
Do not assume a direct submission integration exists. ENISA states that the initial SRP release has no API. Internal work can be organised in your own systems; the described submission step still uses the platform interface.
Assess CRA, NIS2 and GDPR separately
One event can require several assessments: product security under the CRA, an entity's obligations under NIS2 and a possible personal data breach under GDPR. A shared internal incident record can keep the facts together. These remain distinct obligations, not one combined notification.
Our incident management guide covers roles, situational awareness and follow-up in more detail. This article focuses on the product connection and the handover into reporting.
The next useful test
Follow a fictional product-security notice through to a decision. Who knows the affected versions? Who maintains the open questions? Who takes over during an absence? Where is the reasoning recorded?
The useful outcome is a traceable case with an owner and a next step. A portal account alone does not answer those questions.