European platform for reporting digital-product vulnerabilities is now operational

The European Union Agency for Cybersecurity (ENISA) announced on 11 September 2026 that it had deployed the initial operational capability of the Single Reporting Platform, known by its English abbreviation, SRP. The agency says the tool will allow manufacturers and open-source software stewards to meet reporting obligations set out in the Cyber Resilience Act (CRA). This is a concrete implementation step, not an amendment to the law or a declaration that all its rules entered into force on that day.

The distinction matters because the platform’s name could suggest a general system through which any user can report any fault. ENISA’s announcement places it within the CRA’s reporting obligations and refers to manufacturers and open-source software stewards. The announcement confirms the deployment of an initial capability, but the information available does not show that the platform covers every vulnerability-management process, that every actor must already use it, or that a public register of notifications has been published.

The news does provide a verifiable date for an operational milestone. On its own, however, it does not allow us to infer that digital products sold in the EU have already been assessed against every requirement of the regulation. In practice, it is useful to distinguish three issues: the existence of the law, the timetable for its obligations, and the availability of tools intended to facilitate its implementation. These are not interchangeable events.

The CRA establishes cybersecurity requirements for products with digital elements, including hardware and software. The European Commission presents the Act as a framework covering the design, development and maintenance of these products, and imposing on manufacturers obligations related to vulnerability management throughout the product life cycle. General examples of covered products include connected devices and software; the precise scope depends on the definitions, exemptions and conditions set out in the legal text.

Rather than limiting security to a check at the point of sale, the regulation also addresses how problems identified later are handled. This helps explain why reporting and vulnerability management form part of its implementation. The obligation is not a promise that a product will never have flaws: it establishes requirements and processes, including those concerning responses to vulnerabilities, within the applicable legal framework.

The Commission also notes that some products considered particularly relevant to cybersecurity may be subject to specific assessment procedures. It is therefore not correct to assume that every device must follow exactly the same assessment or certification route. For a compliance decision, the general policy description is no substitute for reading the relevant categories and requirements in the Regulation.

The Cyber Resilience Act was adopted in 2024 and provides for a phased application. The Commission’s implementation page indicates that general application is scheduled for 11 December 2027, while certain reporting obligations begin earlier, on 11 September 2026. That second date coincides with ENISA’s announcement of the SRP’s initial operational capability. The fact that a specific obligation begins on the same date as a tool launches does not make the entire regulation applicable early.

This distinction is useful for manufacturers, developers and buyers. Some requirements may call for preparation before their full application date; at the same time, the set of obligations should not be presented as though it were already in force in its entirety. The 2027 date refers to the general timetable described by the Commission, not a guarantee that every product category has identical conditions or deadlines in every respect.

ENISA’s announcement documents a launch step, but does not in itself provide a complete inventory of functions, instructions for each class of notifier, or figures on the volume of reports received. For those details, manufacturers and stewards should consult the SRP guidance and frequently asked questions, as well as the legal text. If a later operational update is published, it should be distinguished from the legal milestones already established.

On the basis of the official sources available, reasonable checks are documentary. A manufacturer can review whether its products fall within the CRA’s scope, identify which obligations apply to it and verify the relevant dates. It can also check that it has a process for addressing vulnerabilities and is familiar with ENISA’s current instructions for submitting and updating notifications. The SRP is a tool associated with that process, not a substitute for the responsibilities of the obligated actor.

Open-source project stewards should avoid automatically extending business obligations to everyone who publishes code. ENISA mentions open-source software stewards in its platform announcement, but determining the legal role of a particular entity requires consideration of the regulation’s definitions and conditions. The words “open source” alone do not settle who is subject to each duty.

For buyers and users, the announcement does not establish a new security label or certify that a particular product is compliant. A practical review can focus on information the provider already supplies: its update policy, stated support period, vulnerability reporting channel and security documentation. These indications can help compare transparency and maintenance, but they do not constitute certification of CRA compliance.

The evidence supports the statement that ENISA announced the deployment of the platform’s initial operational capability on a specific date and linked it to CRA reporting obligations. It also supports a broad description of the Act’s purpose and timetable according to the European Commission. It is not enough, however, to claim that the platform is already fully operational in every function, that all companies have completed registration, or that submitted notifications are public.

Nor can these pages establish that buying a covered product guarantees timely updates, or that a legal obligation eliminates vulnerabilities. The Act sets requirements and responsibilities; assessing a specific product calls for evidence about that product and the actor marketing it. Initial operational capability describes the milestone announced, not an independent audit of availability or performance.

The editorial conclusion is more limited, but useful: there is a confirmed implementation milestone, and it falls within the timetable for reporting obligations. The announcement does not bring forward the CRA’s general application or certify specific products. For readers and buyers, the sensible approach is to treat the news as the start of a regulatory tool and continue consulting official information about deadlines, scope and procedures, without confusing preparation with demonstrated compliance.