Summary
- ENISA records a version 1.1 upgrade on 12 October 2026.
- Updated guidance describes assigned representative registration, notifications, updates, and dashboards.
- The upgrade is an operational change to an existing service, not the introduction of new legal duties.
The EU Agency for Cybersecurity, ENISA, has upgraded the Cyber Resilience Act Single Reporting Platform to version 1.1 and refreshed the documentation available to manufacturers and their representatives. A notice on the agency’s official platform page dates the upgrade to 12 October 2026.
The service provides a route for reporting actively exploited vulnerabilities and severe security incidents associated with products containing digital elements. It is intended to support the flow of information to relevant national computer security incident response teams and other competent authorities. The October change concerns the operation and documentation of an already established reporting mechanism, rather than the creation of a new legal duty.
ENISA’s updated assigned representative manual describes practical platform tasks including registration, notification submission, subsequent updates, association management between manufacturers and representatives, reminders, and dashboard monitoring. The agency marks the manual as version 1.1, last updated on 12 October. That gives users a current reference for performing reporting tasks and checking which account roles can carry them out.
ENISA has not published a comprehensive public change log on the platform overview page. The version number alone therefore cannot substantiate claims about newly introduced fields, automation, or security controls.
Reporting depends on operational preparation
The Cyber Resilience Act creates a regulatory structure for cybersecurity in products with digital elements, reaching beyond voluntary disclosure arrangements maintained by individual manufacturers. Reporting of actively exploited vulnerabilities and severe incidents is designed to help authorities coordinate across borders when a product problem may affect organisations in more than one member state.
That reporting is separate from the work required to contain an incident, repair a product, and communicate with customers. It nevertheless depends on information generated through those activities: what product is affected, which versions or deployments may be exposed, what evidence supports exploitation, and what corrective action has been taken. A notification form cannot compensate for missing internal incident records.
Manufacturers often rely on product security incident response teams, engineering units, customer support, and legal advisers to establish the necessary information. Where responsibilities are divided among a parent company, an importer, a representative, and component suppliers, an account’s technical permissions need to match the organisation’s legal and operational reporting arrangements.
ENISA’s representative guidance reflects that practical problem. Registration is only the starting point; authorised users also need to understand how a submission is completed, amended, and associated with the correct manufacturer. In a cross-border event, mistaken account ownership or outdated contact records could complicate notification, even when the security team has identified a vulnerability accurately.
The agency’s single platform is also designed to reduce fragmented reporting while allowing competent authorities to obtain relevant information. It should not be confused with a public vulnerability database: regulatory notifications may contain sensitive incident detail and follow their own distribution and handling procedures.
The platform was already operational before the October update. Version 1.1 and the refreshed assigned-representative guidance give manufacturers a current reference for checking registration, notification, and update procedures, while ENISA has not identified additional functionality in its public notice.
