Cyber Resilience Act reporting has been mandatory for manufacturers of products with digital elements since 11 September 2026. When a manufacturer becomes aware of an actively exploited vulnerability or a severe incident affecting product security, the first warning is due without undue delay and no later than 24 hours.
That deadline cannot be met by the security team alone. Product ownership, legal entities, software and component dependencies, incident triage, evidence handling and reporting authority must already be clear before an event occurs.
What Changed for Cyber Resilience Act Reporting on 11 September 2026?
The CRA’s incident and vulnerability reporting obligations became applicable to manufacturers on 11th September 2026. The European Commission’s CRA reporting overview confirms that manufacturers must notify actively exploited vulnerabilities and severe incidents having an impact on the security of their products with digital elements.
The date matters because most of the CRA’s wider product obligations apply later, from 11 December 2027. Reporting is an earlier obligation. A company should not wait for its complete 2027 compliance program before establishing the process needed to meet a 24-hour deadline today.
The reporting duty can also apply to products already on the EU market. The Commission’s summary of the CRA legislative text states that the reporting obligations apply to all products with digital elements made available on the Union market, including those placed on the market before 11th December 2027, where they fall within scope.
This creates an immediate operational question: can the business identify the affected product, legal manufacturer, relevant event, awareness time and responsible reporter quickly enough to submit a defensible early warning?
Who Must Comply With Cyber Resilience Act Reporting Now?
The current mandatory reporting duty applies to manufacturers of in-scope products with digital elements made available on the EU market. A manufacturer can be established inside or outside the EU. The decisive questions include who develops or manufactures the product, under whose name or trademark it is marketed and whether the product falls within the Cyber Resilience Act’s scope.
The article does not attempt to determine legal status for every commercial arrangement. Contract manufacturers, software developers, importers, distributors, brand owners and group companies need a product-by-product analysis of their role. A reseller is not automatically the manufacturer, while a company marketing a product under its own name may have manufacturer obligations even when another party performs development or production.
Open-source software stewards have a separate timetable. ENISA’s Single Reporting Platform FAQ states that their corresponding reporting obligations apply from 11 December 2027, to the extent described by the CRA. Do not describe those obligations as already active in October 2026.
If role allocation is unclear, record the issue as a legal and product-governance decision. Do not let several companies assume another party will report.
What Must Be Reported?
The current mandatory workflow covers two event types:
Actively Exploited Vulnerabilities
An actively exploited vulnerability is a vulnerability for which there is reliable evidence that a malicious actor has exploited it in a system without the system owner’s permission.
The trigger is not simply that a vulnerability exists or has a high technical score. The company must determine whether there is reliable evidence of active exploitation and whether the vulnerability is contained in an in-scope product with digital elements.
Evidence may arrive through internal monitoring, customer reports, security researchers, component providers, public vulnerability information, incident investigation or a third party. The reporting process needs an owner who can evaluate that evidence and preserve it when the organization becomes aware.
Severe Incidents Affecting Product Security
A severe incident is not every operational or cybersecurity event. It must have a severe impact on the security of a product with digital elements under the CRA criteria.
ENISA (The European Union Agency for Cybersecurity) describes an incident affecting product security as one that negatively affects, or is capable of negatively affecting, the product’s ability to protect the availability, authenticity, integrity or confidentiality of data or functions. The legal severity test needs to be applied to the facts of the event.
Create a triage route that distinguishes:
• an event involving the manufacturer’s corporate systems only;
• an event affecting the security of a product with digital elements;
• a severe incident that meets the CRA reporting threshold;
• an actively exploited product vulnerability; and
• a vulnerability or near miss that may be relevant but is not currently supported by the mandatory SRP workflow.
Use qualified legal and cybersecurity personnel for difficult cases. This article provides an operating framework, not a legal determination.
When Does the 24-Hour Clock Start?
The reporting clock begins when the manufacturer becomes aware of an actively exploited vulnerability or severe incident. That makes “awareness” an operational control, not a phrase to interpret after the deadline has passed.
Define which facts and which roles can establish awareness for the organization. An engineer, managed service provider, customer-support team, product-security team or senior manager may receive the first credible evidence. If those channels do not feed one controlled triage process, the organization may lose hours debating whether the issue reached the right person.
Every potential report should have a timeline that records:
• the source and time of the first information;
• what the information showed at that point;
• when it was escalated and to whom;
• when active exploitation or incident severity was assessed;
• the decisions taken and evidence used;
• when each notification was submitted; and
• what new facts changed the assessment.
Do not reset the clock because the issue moved between teams or because the investigation was incomplete. The early warning exists so reporting can begin before every technical fact is known.
What Are the 24-Hour, 72-Hour and Final Deadlines?
The European Commission and ENISA describe a staged process.
| Stage | Deadline | Practical purpose |
| Early warning | Without undue delay and no later than 24 hours after awareness | Identify the event and provide the available early information |
| Main notification | Without undue delay and no later than 72 hours after awareness | Add general information and an initial assessment |
| Final report for an actively exploited vulnerability | No later than 14 days after a corrective or mitigating measure becomes available | Explain the vulnerability, action and outcome when the measure is available |
| Final report for a severe incident | Within one month after the 72-hour notification | Provide the fuller incident conclusion and response information |
The 24-hour submission should be treated as a controlled minimum-data decision. The team needs enough information to identify the manufacturer, product and event type, choose the correct coordinator and submit the required fields. It does not need to finish the root-cause analysis first.
The 72-hour stage requires a more developed assessment. Product, security, engineering, legal and communications teams may need to work in parallel so the reporter receives current, consistent information.
The final report must follow the correct trigger. For an actively exploited vulnerability, the deadline is tied to the availability of the corrective or mitigating measure. For a severe incident, it runs from the 72-hour notification.
ENISA’s October 2026 FAQ also warns that the platform’s displayed counters are reference aids. In the version described by the FAQ, the 72-hour counter may calculate 48 hours from the early-warning submission and can display an apparently overdue status before 72 hours have elapsed from awareness. The manufacturer remains responsible for calculating the legal deadline from the awareness time.
Where Are Cyber Resilience Act Reports Submitted?
Mandatory reports are submitted through ENISA’s CRA Single Reporting Platform. The platform became operational on 11th September 2026.
ENISA upgraded the platform to version 1.2 on 20th October 2026. At the time of publication, ENISA states that the process for inviting Secondary Assigned Representatives has changed and that supporting documentation is being updated. Teams should use the current platform instructions rather than relying on an older internal screenshot or training note.
Assigned Representatives use personal EU Login accounts with multi-factor authentication. The manufacturer selects the relevant CSIRT (Computer Security Incident Response Team ) designated as coordinator. In general, that choice is primarily determined by the manufacturer’s main establishment under the CRA rules.
Only one notification is required for a given event even where the manufacturer has several branches or subsidiaries in the EU or a parent company outside the EU. That does not remove the need for internal coordination. The group must know which manufacturer owns the product, who is authorized to submit and how duplicate or conflicting reports will be prevented.
The platform currently supports the mandatory notifications described by Article 14. ENISA says voluntary-reporting functionality will be introduced in a future phase. Do not submit a non-mandatory event through a workflow that is not designed for it without checking the current guidance.
What Information Should Be Ready Before an Incident?
The 24-hour window is too short to build the reporting system from scratch. Prepare a controlled reporting pack before an event occurs.
Product and Manufacturer Scope
Maintain a product inventory that connects:
• product name and model or other identifier;
• legal manufacturer and establishment;
• markets where the product is made available;
• product owner and product-security contact;
• support status and relevant versions;
• software and hardware components;
• key suppliers and service providers; and
• the responsible reporting representative.
A commercial product catalogue is not enough if it cannot connect the event to the responsible legal entity and affected versions.
Event and Awareness Record
Create a template that captures the awareness time, source, event type, affected product, current evidence, impact, containment and unresolved questions. Preserve updates rather than overwriting the original record.
Notification Data
Use ENISA’s current CRA SRP Glossary to identify which fields apply at the early-warning, 72-hour and final-report stages. The fields differ by event type and stage, and some become required only as more information is expected to be available.
Decision and Submission Authority
Name the people who can classify the event, approve the notification and submit it. Provide deputies for absence and time-zone coverage. Assigned Representatives must use their own EU Login accounts, so shared credentials are not an acceptable continuity plan.
Which Seven Controls Should You Put in Place Now?
1. Confirm Product and Legal-Entity Scope
Determine which products with digital elements are made available on the EU market and which legal entity acts as manufacturer. Record unresolved role questions and assign them for legal review.
Do not rely on a single group-level CRA statement. Connect each product family to the accountable manufacturer, product owner and reporting representative.
2. Register Primary and Backup Representatives
Create the required EU Login accounts, enable multi-factor authentication and complete the manufacturer association process in the SRP. Follow the current version 1.2 instructions for Primary and Secondary Assigned Representatives.
Test access before an incident. A named backup is useful only if the person can log in, see the correct manufacturer and perform the required workflow.
3. Define the Awareness and Triage Rule
Write a short decision procedure for potential actively exploited vulnerabilities and severe incidents. State which channels feed triage, who assesses reliable evidence, how severity is evaluated and how the awareness time is preserved.
Avoid a sequence in which the issue waits for several committees. Investigation can continue while the reporting decision moves through a defined escalation route.
4. Map Product, Component and Supplier Dependencies
Identify the components, software libraries, cloud services and suppliers that could create or help investigate a product-security event. Connect each dependency to affected products, versions, contacts and notification duties.
VECTRA’s guide to Supply Chain Mapping: 8 Blind Spots Hiding Supplier Risk explains how to separate legal entities, sites, components, data dependencies and evidence confidence. For CRA reporting, that map should make it possible to move from a third-party notice to the affected product and responsible manufacturer quickly.
5. Put Notification Duties Into Supplier and Service Agreements
Contracts and operating procedures should require relevant suppliers, developers and service providers to report vulnerabilities and incidents quickly enough for the manufacturer to meet its own deadline. Define the event types, contacts, minimum information, evidence preservation, cooperation and escalation expected.
VECTRA’s supplier onboarding guide shows how incident duties, subcontractor controls and system access should be established before activation. Existing suppliers may need a targeted contract or operating-control review.
6. Prepare Stage-Specific Templates and Evidence Control
Use separate checklists for the 24-hour, 72-hour and final stages. Mark which fields are required, conditional or expected when available. Record sources and uncertainty so early information is not presented as a confirmed conclusion.
Control access to sensitive vulnerability and incident information. Limit distribution to people who need it, preserve the investigation record and coordinate public or customer communications with the regulatory process.
7. Run a Timed Exercise
Choose a credible scenario involving an in-scope product, a third-party component and incomplete early information. Start the clock when the first credible evidence reaches the organization.
Test whether the team can:
• identify the manufacturer and product versions;
• classify the potential reporting trigger;
• contact the right technical and legal owners;
• access the SRP through an authorized representative;
• select the relevant CSIRT coordinator;
• assemble and approve the early warning;
• preserve the awareness and decision timeline; and
• continue toward the 72-hour and final stages.
Record actual delays and unclear decisions. Fix the process rather than declaring the exercise successful because a draft form was eventually completed.
How Should Suppliers and Third-Party Components Be Handled?
Manufacturers remain responsible for their own CRA reporting decisions. A component provider’s notice can create the information needed to investigate, but it does not automatically decide whether every integrating manufacturer has a reportable event.
Build an intake route for component vulnerability and incident notices. The intake should connect the component to products and versions, assess whether there is reliable evidence of active exploitation, evaluate product impact and preserve the time the manufacturer became aware.
The live supplier risk assessment checklist can help identify cyber access, product dependency, subcontracting and control evidence during relationship review. For ongoing operations, VECTRA’s article on technology in supply chain due diligence explains why digital risk and data controls need to sit inside the wider supplier process.
Avoid requiring every supplier to complete the same technical questionnaire. Focus on the supplier’s role, the component’s significance and the information needed to support investigation and notification.
What Should Management Ask Before Signing Off Readiness?
Management does not need to become the incident-response team. It should test whether the operating system is credible.
• Do we know which legal entity is the manufacturer for every in-scope product family?
• Can the team explain when the awareness clock starts?
• Are the Primary and backup Assigned Representatives registered and able to access the correct manufacturer account?
• Can a component notice be connected to affected products and versions quickly?
• Are legal, security, product, engineering and communications decisions sequenced for a 24-hour deadline?
• Do suppliers have notification and cooperation duties that support the manufacturer’s clock?
• Are the early-warning, 72-hour and final-report templates based on current ENISA fields?
• Has the full workflow been tested under time pressure?
• Is there a controlled record of the evidence, decisions and submissions?
If the answer depends on one person, one inbox or one untested spreadsheet, the process is not yet resilient.
VECTRA’s Independent Quality Assurance service can add separate reviews where readiness depends on verified controls and evidence. Where teams need support with regulatory scope, supplier controls and risk design, Compliance, Risk & Due Diligence provides the relevant commercial route.
Summary
Who?
Manufacturers of in-scope products with digital elements made available on the EU market. Open-source software stewards have a later corresponding reporting start date of 11th December 2027 under the provisions described by ENISA.
What?
Actively exploited vulnerabilities and severe incidents having an impact on product security. The early warning is followed by a fuller 72-hour notification and the applicable final report.
When?
The obligation has applied to manufacturers since 11th September 2026. The first warning is due without undue delay and within 24 hours of awareness. The main notification is due within 72 hours.
Where?
Through ENISA’s CRA Single Reporting Platform, using an authorized representative and the relevant CSIRT designated as coordinator.
Why?
The EU designed the process to support coordinated handling of vulnerabilities and incidents affecting products with digital elements. For the manufacturer, a controlled process also reduces delay, duplication and conflicting decisions during a time-critical event.
Frequently Asked Questions
Is the 24-Hour CRA Deadline Already in Force?
Yes. Article 14 reporting obligations apply to manufacturers from 11 September 2026. The wider CRA requirements generally apply from 11 December 2027, but that later date does not postpone the current reporting duty.
Does CRA Reporting Apply to Products Already on the EU Market?
The Commission states that Article 14 reporting applies to in-scope products with digital elements made available on the Union market, including relevant products placed on the market before 11th December 2027.
Must Every Known Vulnerability Be Reported?
No. The mandatory vulnerability trigger is an actively exploited vulnerability, which requires reliable evidence of malicious exploitation without permission. Other vulnerabilities may still require investigation, disclosure or action under different duties, contracts or security processes.
Can One Person Submit for Several Group Companies?
The SRP allows Assigned Representatives to act for associated manufacturers, subject to its registration and verification process. The group still needs clear authority, correct manufacturer associations and internal coordination for each affected product and event.
What If the SRP Is Unavailable?
Follow ENISA’s current platform-status and contingency guidance. Preserve evidence of the event, awareness time, attempted access and actions taken. Do not invent an alternative route or wait silently for the platform to recover.
Should the Company Wait for the 2027 CRA Program to Finish?
No. Establish reporting scope, representatives, triage, product dependencies, templates and exercises now. Those controls are necessary for the reporting obligation already in force and will also support the wider product-compliance program.
Related Posts
• Why Operational Resilience Is More Than a Dashboard
• Digital Compliance Transformation: How to Build Controls That Work
• EU AI Act Article 50: Transparency Requirements
VECTRA International is a trusted Business Resilience & Operational Capability Building Partner. Through our ecosystem of integrated solutions, we help organizations transform operational complexity into resilient performance, measurable business impact, and sustainable growth.
Chaussée de Wavre 1517B, 1160 Brussels, Belgium.
A Note on Our Visuals: At VECTRA, we combine human expertise with advanced technology. Some of the supportive imagery in this article was generated using artificial intelligence tools like Google Gemini. We ensure all conceptual AI assets align with our brand standards and accurately reflect our data.
