CRA Vulnerability Reporting: What Every Manufacturer Must Do Before 11 September 2026

The EU Cyber Resilience Act vulnerability reporting deadline arrives on 11 September 2026, and it applies from that date to every product with digital elements already on the EU market. Manufacturers who have been treating the Cyber Resilience Act (CRA) as a 2027 problem need to update their plans.

This is the first hard obligation under the regulation, landing fifteen months before full applicability in December 2027, and it catches your existing product portfolio as well as anything you ship after that date.

This article walks through exactly what the September 2026 deadline requires, when the 24-hour clock starts, what the penalties are, and the concrete steps your team needs to take before that date arrives.

What Is the CRA September 2026 Deadline?

The Cyber Resilience Act entered into force in December 2024, but its obligations are phased. The first obligation that affects manufacturers directly, on 11 September 2026, concerns vulnerability reporting and severe incident notification.

From that date, manufacturers of products with digital elements must report actively exploited vulnerabilities and severe cybersecurity incidents to two bodies simultaneously: the European Union Agency for Cybersecurity (ENISA) and the national CSIRT (Computer Security Incident Response Team) designated as coordinator under NIS2 in the relevant Member State.

This obligation is established under Article 14 of the CRA. It is also the only part of the regulation that explicitly covers legacy products already on the market. Article 69(3) extends Article 14 to every product with digital elements placed on the EU market before 11 December 2027.

The rest of the CRA applies to legacy products only if they undergo a substantial modification under Article 69(2). Reporting is the exception: it starts in September 2026 regardless of when the product was manufactured.

The Two Triggers: What Must Be Reported

Article 14 sets out two distinct triggers that require a manufacturer to initiate the reporting process. The first is an actively exploited vulnerability in the product. The second is a severe cybersecurity incident having an impact on the security of the product.

These are not the same thing, and the final reporting deadlines differ between them, which we explain in the next section. Both share the same initial 24-hour and 72-hour notification timetable.

The Three-Stage Reporting Timeline Explained

The CRA structures its notification process in three escalating stages. Each stage adds detail and requires input from different parts of the organisation. Understanding the timeline is essential for building the internal workflow that delivers compliant notifications every time.

Stage 1: Early Warning Within 24 Hours

Within 24 hours of becoming aware that a trigger event has occurred, the manufacturer must submit an early warning notification to ENISA and the relevant national CSIRT.

This submission is intentionally brief: the basic facts of the issue, an indication of the affected product, and any initial corrective steps known at that point. Speed matters here far more than completeness. The purpose of the early warning is to alert authorities, not to provide a full technical analysis.

Stage 2: Vulnerability Notification Within 72 Hours

Within 72 hours of becoming aware, a fuller notification follows. This typically includes general details about the affected product, the nature of the exploit, any corrective or mitigating measures already taken, and updated information that has come to light since the early warning. The 72-hour notification builds on the early warning; it does not replace it.

Stage 3: Final Report

For actively exploited vulnerabilities, the final report is due no later than 14 days after a corrective or mitigating measure becomes available. It must describe the vulnerability, its severity and impact, provide information on any malicious actors involved (where available), and detail the security update or corrective measure.

The European Union Agency for Cybersecurity is developing the single reporting platform that will handle these submissions, though manufacturers should not wait for the platform to launch. The obligations apply from 11 September 2026 regardless.

For severe incidents, the final-report deadline differs. The 24-hour and 72-hour stages work exactly as they do for vulnerabilities, but the final report is due one month after the 72-hour notification, not 14 days. The content is more substantial too: the report needs to describe the incident, its severity and impact, the type of threat or root cause behind it, and the mitigation measures applied and ongoing. The root-cause analysis is the main reason the legislator gave one month for incidents rather than fourteen days.

“Becoming Aware”: When the 24-Hour Clock Actually Starts

This is the question that catches manufacturers out most often, and it is where the European Commission’s Draft Guidance on the CRA is most important to understand. Paragraphs 193 to 196 of the Draft Guidance are clear: the clock starts when, after an initial assessment of a suspicious event, the manufacturer has a reasonable degree of certainty that a vulnerability in their product is being actively exploited, or that a severe incident has occurred and has compromised the security of the product.

The suspicious event that triggers the initial assessment can come from anywhere: internal monitoring, a customer report, a security researcher disclosing through your coordinated vulnerability disclosure (CVD) policy, a media story, or an enquiry from a CSIRT.

The manufacturer must assess it immediately. The 24-hour clock does not start at the first hint, but it does start as soon as the assessment gives reasonable confidence that a trigger event has occurred.

The guidance states that manufacturers should not delay the initial assessment in order to delay the clock. Prompt action is expected, particularly where a vulnerability may pose a significant risk.

In practice, this means every product team needs a defined intake-and-triage process for incoming vulnerability reports, and the data infrastructure to assemble a compliant 24-hour notification under real pressure, on a Friday afternoon, when the right people may not be available.

CRA Vulnerability Reporting Penalties: What Is at Stake

The CRA gives these obligations real commercial teeth. Under Article 64(2) of the Cyber Resilience Act, failure to comply with the obligations in Articles 13 and 14 (which include both vulnerability and incident reporting) exposes manufacturers to administrative fines of up to €15 million or, if the offender is an undertaking, up to 2.5% of total worldwide annual turnover for the preceding financial year, whichever is higher.

Reporting obligations sit in the highest fine tier under the CRA, the same tier as breaches of the essential cybersecurity requirements set out in Annex I. These are not paperwork risks. They scale directly with revenue, and they apply from September 2026.

Special Considerations for SMEs

The CRA does provide some proportionality for smaller manufacturers. Administrative fines for failure to meet the 24-hour early-warning deadline do not apply to micro and small enterprises as defined in EU Recommendation 2003/361/EC.

Member States are required to take the size of the enterprise into account when deciding the amount of any fine. Conformity assessment fees must also be reduced proportionately for SMEs. The CRA goes further for open-source software stewards: administrative fines do not apply to stewards at all, regardless of the infringement, in recognition that they play a different role from manufacturers.

None of this exempts SMEs from the underlying obligation. The penalty regime around timing is softer for smaller businesses, but the reporting obligation itself is the same. An SME with an actively exploited vulnerability in its products is still required to notify ENISA and the relevant national CSIRT within 24 hours. To make that workable, national CSIRTs are required to provide direct helpdesk support to manufacturers – especially SMEs – on the reporting obligations themselves. If you are unsure how to handle a specific question, your national CSIRT is a legitimate first call.

The CVD Policy Requirement: What Annex I, Part II Means for Your Business

Alongside the notification obligations, the CRA imposes three related but legally distinct requirements that together form the vulnerability disclosure framework. First, manufacturers must put in place and enforce a coordinated vulnerability disclosure (CVD) policy. Second, they must provide a contact address where researchers and customers can report vulnerabilities, and take other measures to facilitate the sharing of information about potential vulnerabilities in their products and in any third-party components they use. Third, manufacturers must designate a single point of contact through which users can communicate with them directly – including for the purpose of reporting vulnerabilities. In most companies the same security inbox serves all three; legally, they are three separate obligations.

A timing note: these CVD-related obligations sit within the broader vulnerability handling requirements in Annex I, Part II of the CRA, which become legally binding on the full application date of 11 December 2027 – not 11 September 2026. The September 2026 deadline applies specifically to the reporting obligation in Article 14. In practice, however, manufacturers need a CVD policy and contact address in place well before September 2026, because external vulnerability reports are one of the main ways manufacturers become aware of issues that trigger the 24-hour reporting clock.

What Your Team Needs to Do Before 11 September 2026

Four months is enough time to build a compliant vulnerability handling process, if you start now. The following steps represent the minimum operational scaffolding the CRA requires.

Curious about where your organisation stands today? Take the free CRA Readiness Assessment to find out.

1. 1. Confirm scope. Which of your products are in scope of the CRA, including any associated remote data processing solutions?
   2. Identify legacy exposure. Inventory the products already on the market that will become subject to vulnerability reporting from 11 September 2026.
   3. Build a vulnerability-intake process. A single, documented entry point for vulnerability reports — internal and external — with a clear ownership chain through to the team that will produce the 24-hour notification.
   4. Define your “becoming aware” trigger. Who is authorised to declare reasonable certainty that a vulnerability is actively exploited or that a severe incident has occurred? Document the decision and the chain of approval.
   5. Publish your CVD policy. These are essential cybersecurity requirements under Annex I, Part II of the CRA that become legally binding on the full application date of 11 December 2027 – but you need them operational well before 11 September 2026 to make Article 14 reporting workable. Without a public CVD policy and a monitored contact address, you will not reliably receive the external reports that trigger the 24-hour clock. Publish your CVD policy, name the contact, and link to it from your product documentation.
   6. Connect into the EU vulnerability ecosystem. Identify the CSIRT designated as coordinator under NIS2 in your relevant Member State, and ensure you have a route into ENISA’s reporting workflow.
   7. Rehearse the workflow. Run a tabletop exercise, a Friday-afternoon vulnerability disclosure lands in your support inbox. Can your team produce an early warning to ENISA and the CSIRT inside 24 hours? Iterate until the answer is yes.

The manufacturers who will handle 11 September without disruption are the ones who have practised the workflow, not merely the ones who have read the legislation carefully.

How AI Is Changing CRA Compliance for Manufacturers

Traditional approaches to regulatory compliance relied on consultants, legal review, and manual processes. These remain valid, but the September 2026 deadline creates a time pressure that consultants alone cannot solve: 59% of IoT manufacturers currently have no vulnerability disclosure process in place, according to the IoT Security Foundation’s 2025 vulnerability disclosure report. Building one from scratch within weeks, and operating it reliably under the 24-hour notification constraint, requires a systematic approach.
AI-assisted compliance platforms are changing how manufacturers approach this problem.

Rather than engaging a consultant to review a spreadsheet, manufacturers can use purpose-built tools that guide the triage process, generate draft notifications with the correct fields and level of detail at each stage, and maintain a timestamped audit trail that supports the technical documentation expected under Article 31. The AI drafts; the human team reviews and approves. This is the model that makes the 24-hour clock manageable at scale.

Attestra for Vulnerability Handling and Reporting

For most manufacturers, the honest answer to “how would you handle a CRA vulnerability report today?” is a shared inbox, a spreadsheet, and a frantic Slack thread. That stops working the moment a researcher emails about an actively exploited flaw and the 24-hour clock starts.

Cyber Cert Labs is launching Attestra in June 2026, three months ahead of the September deadline. Attestra is an AI-powered product security platform built specifically for manufacturers navigating the CRA, delivered as five modules that map to every regulatory milestone through December 2027. It’s how a mid-sized manufacturer without a dedicated security team gets compliant, without €1,200-a-day consultants or five tools stitched together.

The first module to launch tackles the most urgent obligation: vulnerability handling and reporting.

A branded portal, ready on day one. Annex I Part II requires a public CVD policy, a point of contact, and a secure channel for researchers. Only around 40% of IoT manufacturers have any of this today. Attestra gives you a fully branded portal, your logo, your domain with the disclosure policy, contact, PGP key, and a structured intake form that deduplicates and routes reports automatically. Version-aware advisories publish from the same place when a fix ships.

AI-assisted reporting workflow – Behind the customer-facing portal, Attestra runs the structured workflow your CRA programme depends on:

1. 1. • Triage and “becoming aware” decisioning – guided workflow to take a suspicious event from first received to a documented, timestamped “reasonable degree of certainty” decision, so the 24-hour clock starts on a defensible record.
      • AI-assisted notifications to ENISA and the CSIRT coordinator – guided generation of the 24-hour early warning, the 72-hour notification and the final report, with the right fields and the right level of detail at each stage. The AI drafts; your team reviews and signs off.
      • Full audit trail – every action timestamped and exportable into the technical documentation pack expected by market surveillance authorities under Article 31.

The September 2026 Deadline Is Closer Than It Looks

The CRA vulnerability reporting deadline on 11 September 2026 is the first real test of how manufacturers have prepared for EU cybersecurity regulation. It arrives earlier than most expect, applies to products already on the market, and carries fines that scale with the size of the business.

The obligation is not complex in principle: you become aware of an exploit, you notify ENISA and the CSIRT within 24 hours, you follow up within 72 hours, and you file a final report when a fix is available. The challenge is that doing this well under real-world conditions, on an unpredictable timetable, requires an operational process that has been built, documented, and practised before the event occurs.

Building that process takes time. The manufacturers who will handle September with confidence are the ones who start now, confirm their scope, map their legacy exposure, publish their CVD policy, and run their first tabletop exercise before the summer.

Attestra is purpose-built to make this manageable. The Vulnerability Handling and Reporting module launches in June 2026, giving manufacturers three months to get set up and practise the workflow before the deadline. Manufacturers who join the waitlist before launch are onboarded first, with priority access to CRA specialists for set-up support.

Join the Attestra waitlist

Frequently Asked Questions: CRA Vulnerability Reporting