On 11 September 2026, ENISA deployed the initial operating capability of the Cyber Resilience Act Single Reporting Platform at 12:00 UTC, or 17:30 IST. The development matters because the Cyber Resilience Act’s Article 14 reporting phase for manufacturers began that day. It creates a common electronic path for specified product-security events, but it is not a public vulnerability database, a reporting portal for every software issue, or proof that the Act’s wider product requirements are already fully in force. The key date distinction is straightforward: 11 September marks the platform deployment and the start of the manufacturer reporting phase, while this article’s publication package is dated 12 September. They are different events and should not be treated as a retroactive change to the regulation’s earlier adoption date.
This article is part of the cybersecurity technology guide library.
What ENISA deployed on 11 September
ENISA describes the Single Reporting Platform, or SRP, as the common online reporting mechanism it develops, operates and maintains under the Cyber Resilience Act. The Act is an EU regulation that sets horizontal cybersecurity requirements for products with digital elements across their lifecycle. At launch, the SRP gives a manufacturer one route for notifications that meet Article 14’s reporting thresholds. ENISA characterises the deployment as initial operating capability and says further functionality will be developed in response to operational experience and user needs. That wording matters: a functioning reporting route is not the same thing as a feature-complete service or a claim about every future workflow.
The platform’s routing purpose is also narrower than a public disclosure service. A notification goes through the designated coordinating Computer Security Incident Response Team, usually called a CSIRT, linked to the manufacturer’s main establishment, while ENISA receives the information under the reporting arrangement. The receiving coordinator can share relevant information with CSIRTs in Member States where the affected product is available. This is a regulatory notification and coordination process, not a searchable catalogue of every flaw in a device or application. Readers following Techduopulse coverage of secure-by-design defaults and incident-response evidence preservation can treat the SRP as a reporting layer that sits alongside, rather than replaces, those product-security practices.
Which events trigger Article 14 reporting
The live Article 14 duty concerns manufacturers of in-scope products with digital elements when they become aware of either an actively exploited vulnerability in such a product or a severe incident affecting its security. A manufacturer is the economic operator responsible for placing a product on the market under its name or trademark; a team’s role, contractual position and product scope require a fact-specific assessment. An actively exploited vulnerability is not simply a bug or a vulnerability report. The regulatory threshold is reliable evidence that a malicious actor has exploited the weakness. A severe incident is likewise a defined security-impact threshold, not a label automatically attached to routine defects, outages or support tickets.
The distinctions reduce two opposite errors. Treating every newly disclosed vulnerability as reportable can blur the threshold and overload escalation processes; treating credible exploitation evidence as an ordinary defect can delay a time-bound notification. Product teams need to establish who can decide whether a product is in scope, whether an event affects product security, and when the organisation became aware of the qualifying facts. That does not establish that any particular company, product class or security event is covered. It identifies the questions that need resolving before a regulatory clock is assumed to have started.
How the 24-hour, 72-hour, and subsequent reporting sequence works
The reporting sequence is measured from the manufacturer becoming aware of the qualifying event, not from public disclosure, discovery by an outside researcher or deployment of a patch. For an actively exploited vulnerability, Article 14 calls for an early warning without undue delay and at the latest within 24 hours, followed by a vulnerability notification within 72 hours unless the relevant information was already supplied. The later notice covers available general information on the product, the nature of the exploit and vulnerability, and corrective or mitigating measures, including measures users can take. A final report is due no later than 14 days after a corrective or mitigating measure is available, unless the information was already reported. This staged structure permits an initial warning when the factual picture is incomplete; it does not remove the need to preserve and improve the underlying evidence as the assessment develops.
Severe incidents follow the same 24-hour early-warning and 72-hour notification pattern. The early warning includes, at minimum, whether the incident is suspected to result from unlawful or malicious acts; the subsequent notification adds the available detail required by the regulation. For a severe incident, the final report is due within one month of the 72-hour notification. In practical terms, the trigger–recipient–deadline matrix is: qualifying exploited vulnerability or severe incident; SRP to the coordinating CSIRT and ENISA; early warning at 24 hours, notification at 72 hours, then the event-specific final-report schedule. The deadlines are not a measure of incident resolution speed, and the sources do not establish a processing time or outcome for an SRP submission.
What remains phased in or outside this launch
The reporting start date and the Act’s broader application date must be kept separate. ENISA and the European Commission state that manufacturers’ Article 14 reporting obligations apply from 11 September 2026, while the main Cyber Resilience Act cybersecurity requirements apply from 11 December 2027. The SRP launch therefore operationalises an earlier reporting phase; it does not mean every obligation governing product design, documentation, updates, conformity assessment or market placement is now effective. A business cannot infer full CRA compliance merely because it can access a reporting path, and an affected reader cannot infer that all products are already subject to the same live requirements.
Open-source software also requires a more precise distinction than the phrase ‘open source’ alone suggests. The later reporting provision concerns designated open-source software stewards, a defined class of legal persons that provide sustained support for certain free and open-source products intended for commercial activity. That Article 24(3) reporting duty applies from 11 December 2027. It does not give ordinary individual maintainers the same live reporting duty on the platform’s 2026 launch date. The supplied implementation evidence also does not establish voluntary reporting as available at launch. Hosting code in a repository, contributing to a project, or using an open-source component does not by itself settle manufacturer or steward status.
Operational preparation: ownership, evidence, and escalation
For organisations that may manufacture an in-scope product, preparation begins with assigning accountable roles before a qualifying event occurs. The responsible teams need a way to identify the affected product and its markets, preserve timestamps and technical evidence, record the basis for an exploitation or incident assessment, and coordinate the information that may be needed at 24 and 72 hours. A secure product inventory, dependency records and clear vulnerability intake processes can make that work more reliable. Techduopulse’s explainers on software supply-chain SBOMs and build provenance, and on vulnerability prioritisation by exploitability, exposure and business impact, provide useful context for those underlying evidence practices.
Readers should verify their actual legal role, the product’s scope, the point at which awareness is established, the applicable coordinating CSIRT route, and the current ENISA and Commission guidance before treating a scenario as reportable. They should also distinguish an operational escalation decision from a conclusion that a regulator has found a violation. The platform is significant because it turns a phased statutory reporting requirement into an operating process shared across EU authorities. Its importance does not justify adding claims that the platform is public, universally available to every organisation, complete in all functions, or intended for every vulnerability. Those boundaries keep the explainer useful after the launch day while preserving what the available evidence does and does not show.
Source notes
Reporting record
techduopulse stores source destinations privately. Public notes remain non-clickable so every visitor journey stays on this website.
ENISA platform deployment source note
Primary source · Platform deployment and scopeEuropean Commission reporting source note
Primary source · Reporting workflow and deadlinesCyber Resilience Act legal-text source note
Primary source · Articles 14, 24 and 71Image updated: embedded writing removed; article content and factual claims unchanged.
