The September 2026 CRA Deadline: What Manufacturers Must Do Right Now
Time-sensitive
This article focuses on the 11 September 2026 vulnerability reporting deadline — the first hard enforcement milestone under the Cyber Resilience Act. As of 27 August 2026, you have 15 days to prepare.
Most companies treating the CRA as a 2027 problem are already behind. According to the 2026 CRA Awareness and Readiness Report from OpenSSF and Linux Foundation Research, 66% of software producers surveyed remain unfamiliar with the regulation — and that figure has risen year-over-year. The first enforcement date is not December 2027. It is 11 September 2026, when Article 14 vulnerability reporting obligations become legally binding. From that date, if a vulnerability in your product is being actively exploited, you are required to file an early warning through the ENISA Single Reporting Platform within 24 hours of becoming aware of it. Miss that window, and you are already non-compliant — with penalty exposure of up to €15 million or 2.5% of global annual turnover, whichever is higher.
What Exactly Must You Start Doing in September 2026?
The reporting obligation is triggered by two conditions, either of which requires action:
- An actively exploited vulnerability in any of your in-scope products, regardless of severity
- A severe incident affecting the security of your products — for example, a significant breach or systemic compromise
Once either condition is met, a three-stage reporting cascade begins:
Stage 1 — Early Warning: Within 24 Hours
Submit an early warning through the ENISA Single Reporting Platform confirming your awareness of an actively exploited vulnerability. You are not required to provide full technical details at this stage. The purpose is to flag that you are aware and managing the situation. The SRP will automatically route the report to your national CSIRT coordinator and to ENISA simultaneously. As of this writing, the SRP itself is not yet live — ENISA states it is scheduled to be operational by 11 September 2026, with a dedicated public URL to be communicated closer to go-live. Registration and onboarding guidance (EU Login access, Assigned Representative roles) has been rolling out from ENISA since 31 July 2026, so there is no need to wait for the platform itself to start that part of your preparation.
Stage 2 — Full Notification: Within 72 Hours
Submit a full notification including technical details of the vulnerability, an initial severity assessment (using CVSS or equivalent), affected products and versions, and any available mitigations or workarounds. This report must be accurate and complete — rushed or inaccurate reports can trigger Tier 3 penalties for providing incorrect information.
Stage 3 — Final Report: Within 14 Days of Issuing a Fix
For an actively exploited vulnerability, submit a final report to ENISA no later than 14 days after a security update or other corrective measure becomes available. For a severe incident, the final report is due within one month of submitting the Stage 2 (72-hour) notification — a separate clock that runs independently of when, or whether, a fix has shipped. Either report closes the reporting loop and must include a full description of what happened, an assessment of severity and impact, and a complete account of the remediation steps taken.
One Detail Most Teams Miss: It Applies to Existing Products Too
The September 2026 reporting obligations not only apply to products launched after that date. Under CRA Article 69(3), they apply to all products with digital elements already placed on the EU market, including products shipped years before the CRA existed. If a vulnerability in a product you released in 2021 is being actively exploited in September 2026, you are required to report it. This catches many teams off guard: your scope for this obligation is your entire active product catalogue, not just your next release.
That does not create a retroactive duty to report every vulnerability you already knew about the moment the clock starts. The obligation is triggered by becoming aware that a vulnerability is being actively exploited (Article 14(1)), not by the vulnerability’s mere existence. If you knew about an unexploited vulnerability before 11 September 2026, there is nothing to report on that date; the 24-hour clock only starts once you become aware of active exploitation, whether that happens before or after the deadline.
A second detail worth locking in: the 24-hour clock starts at reasonable belief of active exploitation, not confirmed forensic evidence. If your monitoring flags credible signals of exploitation, you cannot wait for certainty before submitting the early warning. Waiting for confirmation is how organisations will miss the window.
Why This Is Harder Than It Sounds
Most organisations do not have a tested, 24-hour vulnerability notification process. Building one requires:
Your September 2026 Readiness Checklist
- Identify all in-scope products and confirm their support periods, including legacy products already on the EU market
- Implement or verify continuous vulnerability scanning across all in-scope products and their components
- Document your internal escalation process for suspected actively-exploited vulnerabilities
- Identify who is responsible for submitting ENISA reports (legal, security, or a designated DPO-equivalent)
- Register with your national CSIRT and prepare for registration on the ENISA Single Reporting Platform (SRP)
- Conduct a tabletop exercise simulating a 24-hour reporting scenario
- Brief executive leadership on reporting obligations and liability exposure
- Ensure your vulnerability management tooling can produce audit-ready reports in the required format
The Other Deadlines in the Frame
September 2026 is the most urgent date, but it is not the only one. As of this writing, no CRA harmonised standard has been published in the Official Journal for any product category — the Commission's standardisation request (M/606) covers 41 standards in total. The first concrete milestone is ETSI's set of 17 draft standards for higher-risk product categories, which entered public enquiry on 13 August 2026, with comment windows closing between mid-September and mid-November 2026 depending on category. Full product conformity for all categories does not apply until 11 December 2027, but organisations that wait for the harmonised standards to land before starting work will have very little implementation runway.
This means that with the reporting deadline now just over two weeks away and the technical standards layer still taking shape, late summer 2026 is a period of compressed, parallel compliance activity for anyone not yet prepared. Starting this now is not early. It is the last moment to avoid being caught without a tested process when the clock starts.
→ Read the full guide
The Complete Guide to the EU Cyber Resilience Act — all requirements, product categories, and the full timeline in one place. Read the guide →
Sources
- Regulation (EU) 2024/2847 — Cyber Resilience Act (EUR-Lex, official legislative text)
https://eur-lex.europa.eu/eli/reg/2024/2847/2024-11-20 - 2026 CRA Awareness and Readiness Report — OpenSSF / Linux Foundation Research
https://openssf.org/blog/2026/05/18/taking-stock-of-the-state-of-european-cyber-resilience-act-cra-compliance-an-urgent-wake-up-call-for-the-open-source-ecosystem/ - Cyber Resilience Act — Summary of the legislative text (European Commission)
https://digital-strategy.ec.europa.eu/en/policies/cra-summary
