EU CRA REPORTING STARTS THIS FRIDAY
Friday, September 11, 2026
The EU Cyber Resilience Act's manufacturer reporting obligation starts this Friday, September 11, 2026. From that date, Article 14 requires manufacturers to report actively exploited vulnerabilities and severe incidents affecting product security. The European Commission's reporting guidance confirms the start date.
By Friday: confirm the reporting owner and backup, test the route for assessing reportable events and meeting the 24-hour and 72-hour limits, and prepare EU Login access with multi-factor authentication and the reporting route. Friday starts the obligation; individual reports are triggered by qualifying events, with deadlines measured from awareness.
Full product obligations follow on December 11, 2027. That milestone requires the product, its support arrangements and its conformity evidence to meet the CRA. Assign an owner to each outcome: a working reporting process this week and product conformity for 2027.
The dates remain in place. The European Commission reaffirmed them when it published its final implementation guidance on July 27, 2026. The Commission's September FAQ and ENISA's latest reporting instructions make the practical expectations more specific.
This Friday, September 11, 2026: the reporting process needs to work. Article 14 covers actively exploited vulnerabilities in the manufacturer's product and severe incidents affecting product security. A vulnerability with a high severity score does not automatically qualify. A proof of concept or a good-faith research finding does not, by itself, establish malicious exploitation. Severe incidents have a separate trigger and need not depend on a reportable CVE.
For a reportable event, the manufacturer must submit an early warning without undue delay and within 24 hours of awareness, followed by the main notification within 72 hours of awareness. Both clocks start from awareness. A final vulnerability report is due within 14 days after a corrective or mitigating measure becomes available. A severe incident's final report is due within one month after the incident notification. Manufacturers must also inform impacted users and, where appropriate, all users, with relevant mitigation information. The Commission's reporting guidance sets out these stages.
Those deadlines make internal handoffs consequential. The person who receives a supplier advisory may not own the product risk assessment. The security team may need engineering evidence to determine exploitability. Legal or regulatory staff may need to identify the right reporting route. A workable process connects those people before an event occurs.
The July guidance, section 9.1, provides a useful supplier example: exploitation of a third-party component elsewhere does not automatically trigger an OEM report if the vulnerability cannot be exploited in the OEM product or has not been exploited there. That determination needs evidence. It does not remove the manufacturer's later vulnerability-handling obligations.
Reporting also extends to in-scope legacy products, including products beyond their support period. An OEM should therefore account for older products in its reporting process. That does not suddenly impose every later CRA remediation and support requirement on an unsupported unit. The Commission FAQ, section 5.1, distinguishes the reporting obligation from the broader duties that apply in December 2027.
ENISA added a practical detail on September 8: representatives need an EU Login account with multi-factor authentication. Its guidance advises registering on the Single Reporting Platform when a specific notification is needed, rather than registering pre-emptively. Validation of a representative's authority does not block notification submission. Preparing account access and understanding the reporting route are useful immediate tasks. ENISA's registration instructions should guide the actual process.
December 11, 2027: the product and its supporting evidence need to conform. The broader work spans product risk assessment, secure design, component due diligence, vulnerability handling, secure updates, technical documentation and the applicable conformity assessment. It includes a machine-readable software bill of materials covering at least top-level dependencies. The CRA does not generally require publishing that SBOM to everyone.
Support deserves an explicit commercial and engineering decision. Manufacturers must determine a support period that reflects expected use. Five years is generally the minimum, with an exception for products expected to be used for less than five years. Long-lived industrial equipment may require longer support. Buyers must be able to see the support end month and year. These requirements are set out in Article 13 and Annex I.
Conformity is also a product-specific decision. Internal assessment is available for the default category. Important Class I products have conditions on the self-assessment route; Important Class II and critical products generally require third-party assessment, subject to the regulation's particular routes and exceptions. The Commission's conformity guidance explains the distinction. Existing security certifications and engineering evidence can help, but their coverage must be checked against the actual CRA requirements.
The transition turns on individual units placed on the market. New units placed from December 11, 2027 need to conform even if the model was designed or first sold years earlier. Earlier units generally become subject to the broader requirements if substantially modified from that date. Reporting still applies to those earlier units. This distinction in Article 69 matters for an OEM planning production, inventory and long product lifecycles.
The July guidance makes some of that work more manageable. Product variants with equivalent relevant architecture, intended purpose and cybersecurity risks can share assessment and documentation. Differences that change risk still need treatment. Support must be reassessed after a substantial modification, but a new five-year period does not automatically start. Regular testing should respond to threats, vulnerabilities and changes in product conditions. These are clarifications in the final guidance, not a postponement of the law.
The standards are progressing, and their status matters. ETSI announced 17 vertical final drafts entering approval procedures on August 13. A draft can help a team prepare, but it should not be treated as an Official Journal-cited harmonised standard. ETSI's announcement describes the work still underway.
There is evidence of feedback changing the technical approach. The rapporteur for the vulnerability-handling draft prEN 40000-1-3 describes 2,202 resolved comments, including simplification of the requirements structure and stronger multi-party disclosure guidance. His August update concerns a developing standard. Industry requests for standards-linked deadlines and narrower reporting duties, including those from DIGITALEUROPE, should be tracked as proposals rather than built into a plan as granted relief.
Two other distinctions can prevent confusion. The Commission's FAQ update of September 4 confirms that open-source software stewards' reporting obligations begin in December 2027. That does not change the September 2026 date for commercial manufacturers integrating open source. The CRA's market-surveillance and penalty framework also applies from December 2027. The maximum fine of €15 million or 2.5% of worldwide annual turnover, whichever is higher, for specified infringements should not be presented as beginning with this September's reporting deadline. See FAQ sections 5.5 and 7.1.
Sarah Fluchs's recent guidance puts the preparation work in a useful order. Her Security Briefing for Hard Hats and public CRA material connect the legal requirements with engineering decisions. In the comments on her September LinkedIn post, she agrees with the emphasis on governance: who makes the reporting decision, using which evidence, and with what escalation path.
Her six-step implementation post recommends moving promptly into risk-assessment work. The public method starts with damage scenarios and product modelling, assesses risks and protections, then checks regulatory completeness and produces documentation. The ordering matters: the risk analysis should inform the engineering decisions. These are practitioner recommendations; the regulation and official guidance remain the reference for legal obligations.
For a manufacturer turning the calendar into a work plan, the following internal milestones are practical. They are recommendations, not additional statutory dates:
- Before September 11, 2026: name the reporting owner and backup, establish the escalation route, include legacy products in the reporting scope, and prepare the account access and evidence needed for notification.
- During the next 30–90 days: group the product portfolio by relevant architecture and risk; assign the manufacturer role, support rationale, component responsibilities and conformity route for each group.
- Through 2027: implement and verify the product controls, vulnerability processes, technical files and user instructions; resolve assessment and supplier dependencies before the applicable units reach the EU market.
One useful exercise is to put an exploited OEM vulnerability, a supplier CVE with no exploitation in the OEM product, and a severe product incident through the same reporting process. Record the evidence, the awareness time, the decision and who owns the next action. That exercise will show where the September process needs work. The product assessments will establish the work that must follow for December 2027.
Based on official sources and public practitioner material reviewed on September 8, 2026. Commission guidance and FAQs are non-binding interpretations of the CRA. Product scope and conformity routes require a product-specific assessment.