That split timetable puts a near-term operational burden on organisations that make in-scope products with digital elements available in the EU. The platform is not a general public vulnerability-reporting service, nor is it the finished version of every reporting channel contemplated by the Act. At launch, it is a limited system for mandatory manufacturer reporting under Article 14. That distinction matters for security teams, product leaders, incident responders, and Windows users trying to understand what the new EU regime will—and will not—change immediately.
What ENISA has actually launched
ENISA describes the deployment as the initial operating capability of the CRA Single Reporting Platform, often shortened to SRP. Its public landing page provides separate entry points for Assigned Representatives and CSIRT Representatives.
An Assigned Representative is the person submitting mandatory CRA notifications on behalf of a manufacturer or, where relevant under the platform’s terminology, an open-source software steward. A CSIRT Representative represents a computer security incident response team participating in the routing and handling of reports.
The careful phrase “initial operating capability” is important. It signals a live launch, but not a complete implementation of all anticipated functions. ENISA’s launch documentation says the first release supports only mandatory Article 14 reports involving actively exploited vulnerabilities and severe incidents. Voluntary reporting is not available in the initial release, and the platform has no API at launch. It is also available only in English initially.
Those limits are material. A company cannot assume its existing vulnerability-management system can directly submit notifications programmatically. Instead, it should expect a manual, portal-led process unless and until ENISA introduces an API. English-only availability also means multinational organisations should ensure the people who are authorised to submit reports can work accurately in that language during a time-sensitive incident.
The reporting duty begins before most CRA obligations
The main obligations of the Cyber Resilience Act apply from 11 December 2027. That is the date many product makers may have been using as their principal CRA readiness target.
However, the reporting requirement is already in force from 11 September 2026 for manufacturers. From that date, manufacturers must report actively exploited vulnerabilities and severe incidents affecting covered products.
This is not simply a matter for products introduced after the wider CRA regime takes effect. The reporting duty can apply to in-scope products already placed on the EU market before 11 December 2027. The transition rule makes the date on which the manufacturer becomes aware especially important.
ENISA’s guidance indicates that a manufacturer generally does not have to retrospectively report an actively exploited vulnerability that it already knew was being exploited before 11 September 2026. But if the manufacturer becomes aware of the exploitation on or after that date, the duty applies. Organisations should therefore not treat older products as irrelevant merely because their original release predates the core CRA compliance date.
For Windows-focused vendors, IT departments, and managed-service providers, the practical lesson is not that every Windows issue automatically falls under the CRA. The dossier does not establish the scope of particular products or services. Rather, organisations that may make covered products available in the EU need a defensible process for deciding whether an event is reportable, including for established products still in use.
The clock starts with awareness
The platform’s launch turns incident response into a formal regulatory workflow with short staged deadlines. Once a manufacturer becomes aware of a reportable event, the sequence is:
- an early warning within 24 hours;
- a notification within 72 hours; and
- a final report on a timetable that depends on the type of event.
For an actively exploited vulnerability, the final report is due within 14 days after a corrective measure becomes available. For a severe incident, the final report is due within one month after the 72-hour notification.
These are not interchangeable deadlines. A team that treats every final report as due one month after initial notice could mis-handle an actively exploited vulnerability once a corrective measure is available. Conversely, an incident-management playbook built solely around remediation milestones may not fit the separate severe-incident timetable.
The term “awareness” becomes operationally significant because it is the trigger in the reported material. That raises governance questions companies should settle before an urgent event: who can determine that the organisation is aware, who decides whether the matter reaches the Article 14 threshold, who is authorised to submit, and how will timestamps and decisions be recorded? These are practical preparedness questions, not evidence that every organisation will face a reportable event.
A sensible process must also account for the first 24 hours. Engineering teams may still be investigating root cause, exposure, and a fix when the initial warning is due. That means legal, security, product, communications, and designated reporting personnel need an escalation route that works before technical investigation is complete.
One submission, but not necessarily instant universal sharing
The SRP is designed around a “report once” model. The manufacturer selects a relevant coordinating CSIRT and files one notification for the reportable event. The coordinating CSIRT then shares the report with other relevant CSIRTs in Member States where the product is available. ENISA generally receives the report as part of this process.
This should reduce the need for manufacturers to make separate filings to multiple national authorities for the same event. In principle, a single structured notification can feed a coordinated EU response.
But “report once” should not be interpreted as “every authority receives every detail immediately.” ENISA’s guidance provides an important caveat: in particularly exceptional circumstances, ENISA may initially receive only partial information, and dissemination to other Member States may be delayed or withheld.
That caveat is significant for both incident planners and customers. It means the platform is a regulatory reporting and coordination mechanism, not a guarantee of simultaneous pan-European disclosure. A manufacturer should continue to think carefully about its wider obligations and communications decisions rather than assuming an SRP filing automatically settles every stakeholder-notification question. The supplied material does not set out those broader obligations, so firms should not infer their details from the platform workflow alone.
For enterprise Windows administrators, this is also a useful expectation-setting point. A report to the SRP does not necessarily translate into an immediate public advisory, patch notice, or direct notification to every affected customer. The platform may improve governmental coordination, but it should not replace ordinary vendor security bulletins, patch-management processes, or an organisation’s own monitoring of its technology suppliers.
Voluntary reporting is not available yet
One early public description of the upcoming platform said it would enable voluntary reporting from 11 September 2026. ENISA’s FAQ, updated immediately before launch, gives the more direct account of the live service: voluntary reporting under Article 15 is not available at launch and is planned for a future phase.
That correction matters because it changes who can use the service today and for what purpose. The initial SRP is not a broad intake channel for all useful cybersecurity intelligence, all researchers, or all organisations that may wish to report voluntarily. It is focused on mandatory Article 14 submissions.
Security teams should therefore avoid designing a process around functionality that has not yet been launched. A future voluntary-reporting phase may alter workflows, but its timing and detailed operation are not established by the available material.
Open-source stewards have a different deadline
The platform’s user terminology includes open-source software stewards, but that should not be confused with a current equivalent reporting duty for them. The corresponding mandatory reporting obligation for open-source software stewards under Article 24(3) begins on 11 December 2027, not on the manufacturer start date of 11 September 2026.
This distinction is especially relevant in the Windows ecosystem, where commercial products can depend on open-source components and projects may have complex stewardship arrangements. The current manufacturer reporting obligation should not be casually transferred to every open-source project or maintainer. The dossier supports a later statutory start for the steward obligation, and it does not provide enough detail to decide the status of any specific project or organisation.
At the same time, organisations relying on open-source components should not view the later steward date as a reason to postpone their own security planning. A commercial manufacturer’s reporting assessment and an open-source steward’s future statutory duty are separate questions. Dependency risk, remediation coordination, and internal evidence-gathering remain practical concerns even where the legal reporting trigger differs.
What the launch means for product and security teams
The immediate challenge is procedural maturity rather than portal sophistication. The initial SRP lacks an API, is English-only, and supports a narrow mandatory-reporting scope. Companies should therefore prepare for a human-led submission process under compressed deadlines.
Useful readiness work includes identifying the individual or individuals who can act as Assigned Representatives; connecting vulnerability discovery, incident response, product security, and legal escalation paths; and separating the evidence needed for an early warning from the fuller material needed for subsequent notifications and final reporting. Organisations also need to know which CSIRT they will select as coordinating CSIRT for a given product event.
The most consequential planning error would be to wait until December 2027 on the assumption that the CRA has not yet become relevant. Its main obligations may be later, but the Article 14 reporting clock is already running for manufacturers from 11 September 2026.
A live portal is not proof of operational assurance
The portal’s public availability and ENISA’s announcement establish that an initial service has been deployed. They do not establish every property an organisation might want to know before relying on it during a high-pressure incident.
The available evidence does not independently show that an authenticated manufacturer has completed a real production submission successfully. It also does not establish live uptime, throughput under reporting load, or real-world adoption on the first day. ENISA says the platform underwent user, security, and technical testing with selected stakeholders, but no public independent assessment report, test scope, findings, or remediation record is provided in the reviewed material.
That is not evidence that the platform is insecure or ineffective. It is a limit on what can responsibly be concluded from the public launch material. Companies should prepare to use the official system while avoiding unsupported assumptions about its production performance or comprehensive security assurance.
The practical bottom line
The SRP launch is a meaningful milestone because it makes the CRA’s early reporting regime operational. Manufacturers of in-scope products now face a 24-hour early-warning obligation after awareness of reportable actively exploited vulnerabilities or severe incidents, followed by 72-hour and final-report milestones.
Yet the first release is deliberately constrained: mandatory Article 14 reporting only, no voluntary reporting at launch, no API, and English-only access. Its one-report routing model should simplify cross-border coordination, but it does not promise immediate, complete dissemination in every circumstance.
For the wider Windows community, the near-term effect is likely to be most visible behind the scenes—in vendor incident-response procedures, vulnerability triage, and coordination with national CSIRTs. Users should not expect the platform itself to become a substitute for patches, advisories, or normal security communications. For manufacturers, however, the date is already consequential: CRA reporting readiness can no longer be treated solely as a December 2027 project.