CRA, what changes with version 1.3 of the ENISA reporting platform

Since 11 September 2026, manufacturers of products with digital elements have had to report actively exploited vulnerabilities and severe incidents through the Single Reporting Platform (SRP) run by ENISA, as required by Article 14 of the Cyber Resilience Act. On 4 November 2026 the platform was upgraded to version 1.3 and a new manual was published for Assigned Representatives, that is, the people who operate the platform on behalf of the manufacturer.

The update introduces no new obligations and does not move the legal deadlines. It does, however, clarify several practical aspects of access, roles and notification handling, which are worth adding to internal procedures straight away, because procedures are what make the difference when the time available is measured in hours.

The deadlines stay the same

• An early warning within 24 hours of the manufacturer becoming aware of the exploited vulnerability or severe incident.
• A notification within 72 hours, with the general information available and an initial assessment.
• A final report, due within 14 days of a corrective or mitigating measure becoming available for actively exploited vulnerabilities, and within one month of the 72-hour notification for severe incidents.

The clock starts when the manufacturer becomes aware of the issue, so internal procedures must clearly state who records that moment and how.

What the new manual clarifies

• Access to the platform uses EU Login with multi-factor authentication, and accounts are personal, so credentials cannot be shared between colleagues.
• Once their association with the manufacturer has been validated, the Primary AR can invite one or more Secondary ARs, who ensure continuity when the main contact is unavailable.
• The invitation to a Secondary AR is time-limited, which the manual sets at seven days, so it must be accepted and completed in time.
• Validation of the association between the Assigned Representative and the manufacturer runs in parallel with reporting and does not prevent notifications from being sent, up to a maximum of twenty before verification becomes mandatory.
• A Secondary AR can request to take over the Primary role, subject to approval by the competent CSIRT, for example when the main contact leaves the company.
• The reference CSIRT is chosen at registration, and choosing the wrong one can invalidate the notification.

Assigned Representative does not mean authorised representative

The terms are easily confused. The Assigned Representative is an operational role within the platform, the person who actually submits notifications. The authorised representative under Article 18 of the CRA is a legal figure acting on behalf of the manufacturer in the Union. They may be the same person, but not necessarily, and internal documents should say so explicitly.

Three cases not to confuse

One of the most common mistakes is treating in the same way events that the CRA clearly distinguishes. Runbooks and procedures should clearly separate three situations.

• A severe incident affecting the product, meaning an event that compromises, or could compromise, the product’s ability to protect the availability, authenticity, integrity or confidentiality of data and functions. It must be reported under Article 14.
• An actively exploited vulnerability, for which there is reliable evidence that someone has exploited it without authorisation. This too must be reported under Article 14.
• An ordinary vulnerability, found internally or reported by a researcher but with no evidence of exploitation. It does not fall under the Article 14 reporting obligation and is handled through the normal vulnerability handling and coordinated disclosure process.

An ordinary vulnerability can become actively exploited at any time, for example when an exploit appears in the wild. The process must include continuous reassessment and state who decides when a case moves from one category to another.

What to update in your CRA documentation

• The reporting runbook, with the operational steps on the platform, templates for the early warning, notification and final report, and the information to collect at each stage.
• A RACI matrix showing who is responsible, who approves, who is consulted and who is informed across PSIRT and product teams, SOC, compliance, legal and the Assigned Representative.
• The escalation chain, with timings and alternative contacts, so that the 24 hours are not spent looking for the right person.
• Account management, with at least two active Assigned Representatives, MFA configured and a periodic check that access works.
• A decision log recording when the company became aware of the event, how it was classified and why.

An example workflow

1. The SOC or the product team detects an anomaly or receives a report and opens a case.
2. The PSIRT assesses whether it is a severe incident, an actively exploited vulnerability or an ordinary vulnerability and records the time of awareness.
3. If the case falls under Article 14, compliance and the Assigned Representative prepare the early warning and submit it within 24 hours.
4. Within 72 hours the notification is completed with the information available and an initial assessment.
5. The product team develops the fix or mitigation, while the PSIRT keeps the CSIRT and, where needed, users informed.
6. The final report is submitted on time and the log is updated with lessons learned.

In short

Version 1.3 of the platform does not change the rules, but it makes clearer how to apply them. Now is the right time to check that accounts, roles and procedures are ready, because a good report depends far more on internal organisation than on the tool.

For a full picture of the obligations, see the page on CRA and Machinery Regulation and the article on the 2027 Machinery Regulation. If you want to set up or review your reporting processes, get in touch and we can integrate them with the monitoring provided by our SOC.