The 60-second summary
On 11 September 2026, ENISA deployed the initial operating capability of the Cyber Resilience Act Single Reporting Platform. Manufacturers must now use the platform for qualifying actively exploited vulnerabilities and severe incidents affecting products with digital elements. The Commission identifies a 24-hour early warning, a 72-hour notification and later final reports. The coordinating CSIRT initially receives the report, relevant CSIRTs can receive it, and ENISA receives access. Open-source software stewards have a distinct application date: Article 24(3) applies from 11 December 2027. The launch operationalises existing CRA duties; it is not a new law.
Timeline that matters
11 September 2026
Platform and manufacturer reporting live
ENISA deployed the initial platform capability and manufacturer reporting obligations began.
Within 24 hours of awareness
Early warning
Submit the required early warning for a qualifying event.
Within 72 hours of awareness
Notification
Submit the fuller notification identified by Commission guidance.
11 December 2027
Open-source steward reporting
Article 24(3) reporting applies to relevant open-source software stewards.
15 October 2026
Next review
Check ENISA guidance, platform functionality and Commission clarifications.
What changed
The statutory reporting workflow is no longer prospective: the reporting duties for manufacturers are active and the common electronic platform is available. Organisations should move from policy design to tested platform access, timed triage, submission governance and evidence retention.
Who should pay attention?
Manufacturers and product owners
Determine product scope and make qualifying notifications through the live platform.
Security and incident-response teams
Connect detection and triage to the 24-hour and 72-hour reporting clocks.
Legal and privacy teams
Validate role, threshold, disclosure and confidentiality decisions.
Engineering and vulnerability teams
Provide traceable technical evidence, mitigation status and corrective-measure dates.
Supply-chain and vendor-risk teams
Require timely upstream and downstream escalation of potentially reportable events.
What the guidance clarifies
- The reporting channel is operational
- ENISA deployed the initial operating capability of the Single Reporting Platform on 11 September 2026.
- Manufacturer reporting has started
- Manufacturers must report qualifying actively exploited vulnerabilities and severe incidents from 11 September 2026.
- The clocks are staged
- The Commission identifies an early warning within 24 hours, a fuller notification within 72 hours and later final-report deadlines.
- Open-source stewards have a different date
- Article 24(3) reporting applies to relevant open-source software stewards from 11 December 2027.
- One submission is distributed
- The coordinating CSIRT receives the notification, relevant CSIRTs can receive it, and ENISA receives access through the platform.
- This operationalises existing law
- The launch does not create a new legal instrument; it makes the CRA reporting mechanism available as the duties begin.
Product-security reporting now needs a tested, evidence-ready operating model
Why this matters for global organisations
Organisations that design, supply or support connected products need reporting workflows that cross security, engineering, legal, privacy and supply-chain teams. Fast clocks make ownership, reliable intake, decision evidence and rehearsed escalation essential.
- Connect vulnerability management to regulatory incident triage.
- Use one accountable workflow across products, entities and suppliers.
- Preserve evidence of awareness, thresholds, timing and corrective action.
- Test platform access and reporting roles before a real event.
13 actions to start now
- Confirm which products with digital elements and organisational entities fall within the manufacturer role.
- Name accountable product-security, incident-response, legal and executive owners for CRA reporting.
- Register authorised users and test access to ENISA’s Single Reporting Platform.
- Add CRA qualification criteria to vulnerability and incident triage.
- Create a 24-hour early-warning workflow from first organisational awareness.
- Create a 72-hour notification workflow with required technical and impact information.
- Define final-report triggers and deadlines separately for vulnerabilities and severe incidents.
- Map product availability so the correct coordinating CSIRT and affected markets can be identified.
- Integrate supplier, researcher, support and monitoring reports into one escalation channel.
- Protect sensitive submission data and restrict platform credentials using least privilege.
- Run tabletop exercises using realistic exploited-vulnerability and severe-incident scenarios.
- Retain decision logs for reports made, not made, updated or withdrawn.
- Track ENISA platform guidance, FAQs and functionality changes.
Suggested next steps
- Run a timed CRA reporting exercise now: start from a realistic alert, establish organisational awareness, make the reportability decision, prepare the 24-hour and 72-hour submissions and retain a complete evidence pack.
Evidence worth retaining
- Product and entity scope assessments.
- Manufacturer and supply-chain role determinations.
- Named reporting owners and escalation contacts.
- Platform registration, access-control and test records.
- Incident and vulnerability intake timestamps.
- Awareness-time rationale and reporting-clock calculations.
- Threshold assessments and legal review notes.
- Copies and receipts of early warnings, notifications, updates and final reports.
- Technical indicators, affected versions and exploitation evidence.
- Corrective-measure, patch and customer-communication records.
- CSIRT routing and product-availability analysis.
- Tabletop results, remediation actions and management reporting.
Questions to take to counsel or your conformity team
These are discussion prompts, not legal advice or conclusions.
- Which entities are manufacturers for each product supplied to the relevant market?
- What event establishes organisational awareness and starts the reporting clock?
- How will teams distinguish an actively exploited vulnerability from other vulnerabilities?
- What criteria identify a severe incident affecting product security?
- Can the business assemble a defensible early warning within 24 hours?
- Who approves a submission when facts remain uncertain?
- Which information could create security, confidentiality, contractual or privacy risks if disclosed?
- How are supplier and customer notices coordinated with the CRA submission?
- What evidence supports a decision not to report?
- Which separate notification regimes may apply to the same event?
Official sources
- ENISA — The CRA Single Reporting Platform is launched, 11 September 2026
- European Commission — Cyber Resilience Act reporting obligations, updated 11 September 2026
- ENISA — Single Reporting Platform
- EUR-Lex — Regulation (EU) 2024/2847
PrivacyBuilt / PrivacyBuilt is an independent educational publisher. It is not affiliated with, or endorsed by, any regulator or the European Union.
PrivacyBuilt publishes educational and technical guidance. Nothing on this site constitutes legal advice, and it should not be relied on as a legal determination for your organisation.