Five things manufacturers of digital products need to do now
A cybersecurity vulnerability discovered in a product is no longer only a technical problem. From 11 September 2026, it can also trigger a regulatory reporting process with a first deadline measured in hours.
That is when Article 14 of the EU Cyber Resilience Act becomes applicable. Manufacturers of products with digital elements will be required to report certain actively exploited vulnerabilities and severe security incidents. An early warning must be submitted without undue delay and, in any event, within 24 hours of becoming aware of the relevant vulnerability or incident. A more detailed notification follows within 72 hours.
This is particularly important because the Cyber Resilience Act is often associated with 11 December 2027, when most of the Regulation becomes applicable.
Waiting until 2027 would be a mistake. The reporting obligations arrive more than a year earlier. For organisations developing or selling software, connected devices and other digital products in the European Union, the question is therefore no longer simply:
“Are we preparing for the CRA?”
It is:
“If a reportable vulnerability were discovered tomorrow, could we identify it, escalate it and report it within 24 hours?”
Here are five areas businesses should address now.
1. Determine whether your products fall within the CRA
The first task is scope.
The Cyber Resilience Act, Regulation (EU) 2024/2847, establishes cybersecurity requirements for what it calls products with digital elements.
The European Commission describes these broadly as software or hardware products and their remote data-processing solutions, including software and hardware components that are placed on the market separately. Products generally fall within scope where they are made available on the EU market and their intended or reasonably foreseeable use includes a direct or indirect logical or physical connection to a device or network.
That can include products far beyond traditional cybersecurity software.
Depending on the circumstances, relevant products can include:
- software applications;
- operating systems;
- connected consumer devices;
- network equipment;
- IoT products;
- hardware components;
- software components;
- other connected hardware and software products.
The Regulation contains exclusions and specific rules for certain product categories, so scope must still be assessed case by case.
Who is the manufacturer?
This question is also more important than it may initially appear.
Under the CRA, a manufacturer is not limited to a company physically operating a factory.
The Commission summarises the definition as a natural or legal person that develops or manufactures a product with digital elements—or has it designed, developed or manufactured—and markets it under its own name or trademark, whether for payment, monetisation or free of charge.
That means businesses selling software or digitally enabled products under their own brands should not assume that cybersecurity obligations sit exclusively with an upstream technical supplier.
Business question to ask
Which products do we place on the EU market under our name or trademark, and who has been assigned CRA responsibility for each one?
If that information is not immediately available, the organisation has a governance gap before the reporting clock even begins.
2. Understand what actually has to be reported
The CRA does not require manufacturers to report every vulnerability they discover.
That distinction matters.
From 11 September, Article 14 focuses on two categories:
Actively exploited vulnerabilities
and
severe incidents having an impact on the security of a product with digital elements.
ENISA explains an actively exploited vulnerability as one for which there is reliable evidence that a malicious actor has exploited the vulnerability without the permission of the system owner.
This is different from simply discovering a theoretical weakness through testing.
A newly identified vulnerability may be serious without necessarily being known to be actively exploited.
Conversely, evidence that attackers are already exploiting a vulnerability can immediately change the regulatory situation.
Severe incidents are also specifically defined under the CRA. ENISA describes them as incidents with a severe impact on the security of a product with digital elements, including effects on properties such as availability, authenticity, integrity or confidentiality, with the detailed severity criteria established by Article 14.
Why this distinction matters
Companies need a process capable of answering three separate questions:
Is there a vulnerability?
Is there reliable evidence of active exploitation?
Has a security incident reached the CRA threshold for a severe incident?
Those decisions cannot be left undefined until an incident occurs.
Security teams, product teams and legal or compliance teams should agree in advance how a potential Article 14 event will be assessed and escalated.
3. Build a process capable of meeting the 24-hour deadline
The most operationally significant feature of the new regime is its timeline.
Once a manufacturer becomes aware of a reportable event, the CRA establishes a staged reporting process.
Within 24 hours
An early warning must be submitted without undue delay and, in any event, within 24 hours after the manufacturer becomes aware of the actively exploited vulnerability or severe incident.
Within 72 hours
A further notification must be submitted without undue delay and, in any event, within 72 hours after awareness, providing additional information and an initial assessment.
Final report: vulnerability
For an actively exploited vulnerability, the final report is due no later than 14 days after a corrective or mitigating measure becomes available.
Final report: severe incident
For a severe incident, the final report is due within one month following the 72-hour notification.
The practical implication is straightforward.
A company cannot design this workflow after a serious vulnerability has already appeared.
Twenty-four hours is a short window when information may need to pass through:
Security Operations → Product Security → Engineering → Legal → Compliance → Management → Regulatory Reporting
Every unnecessary approval step consumes time.
A workable internal escalation model
Organisations should define in advance:
Detection
Who monitors vulnerabilities, threat intelligence, researcher reports and customer incidents?
Assessment
Who decides whether reliable evidence of active exploitation exists?
CRA classification
Who determines whether Article 14 is potentially triggered?
Escalation
Who must be contacted immediately?
Reporting authority
Who is authorised to submit the regulatory notification?
Technical evidence
Who provides the vulnerability details, affected versions, exploitation evidence and mitigation information?
Executive communication
Who informs senior management when a CRA-reportable event occurs?
The objective is not bureaucracy.
It is speed with accountability.
4. Prepare for ENISA’s Single Reporting Platform
The reporting process will be centralised through the CRA Single Reporting Platform, established and maintained by the European Union Agency for Cybersecurity, ENISA.
ENISA states that the platform is scheduled to become operational on 11 September 2026, coinciding with the start of the mandatory reporting obligations.
The purpose of the system is important.
Instead of manufacturers separately notifying multiple national authorities, the platform provides a single entry pointfor CRA notifications.
The manufacturer submits through the platform to the relevant Computer Security Incident Response Team, or CSIRT, designated as coordinator. Unless exceptional circumstances apply, the information is also made available to ENISA. The receiving CSIRT can then distribute the notification to relevant CSIRTs in other Member States where the product has been made available.
ENISA has already published guidance on registration, notification submission and platform functions, and states that its guidance may continue to be updated.
What companies should establish before 11 September
Do not simply bookmark the ENISA website.
Determine:
- who in the organisation will submit notifications;
- who will act as backup;
- which legal entity is responsible;
- which CSIRT is relevant to the organisation;
- where the information required for a notification will come from;
- how evidence will be preserved;
- who can approve a submission if senior staff are unavailable.
A reporting platform solves the technical problem of where to send information.
It does not solve the internal organisational problem of determining who knows what, who decides and who acts.
5. Map suppliers and third-party components into the vulnerability process
Modern digital products are rarely created entirely from components written or manufactured by one organisation.
A software product may rely on:
- open-source libraries;
- commercial software components;
- cloud infrastructure;
- APIs;
- operating-system components;
- embedded software;
- third-party development frameworks.
Hardware products can contain similarly complex chains of processors, firmware, operating systems, communication modules and other third-party components.
The CRA explicitly recognises this supply-chain reality.
The Commission explains that where manufacturers integrate third-party components, they must exercise due diligence so those components do not compromise the cybersecurity of their product.
This creates a direct connection between cybersecurity and procurement.
A company may be legally responsible for reporting a vulnerability but depend on a supplier for the technical information required to understand it.
That creates an obvious risk:
What happens when your 24-hour reporting clock has started but your supplier takes three days to respond?
The CRA makes supplier-response capability a business issue, not simply a technical one.
Procurement teams should review
Vulnerability notification clauses
How quickly must suppliers notify you of security vulnerabilities?
Security contacts
Is there a named escalation path, or only a generic support mailbox?
Component information
Do you know which third-party components are used in your products?
Security advisories
How are supplier security notices monitored?
Patch obligations
Who is responsible for developing, validating and distributing corrective measures?
Incident cooperation
Does the contract require suppliers to provide evidence during regulatory reporting or investigation?
Change management
Are material software, firmware or dependency changes communicated?
Cybersecurity clauses that exist only on paper but cannot operate within a 24-hour escalation window may not be sufficient for the reality of CRA reporting.
The overlooked issue: existing products can also be affected
One of the most important details in the CRA is easily missed.
Most CRA requirements generally apply from 11 December 2027, and special transitional rules apply to products placed on the market before then.
But Article 14 reporting is different.
The Commission explicitly states that the reporting obligations apply to products with digital elements made available on the EU market, including products already placed on the market before 11 December 2027.
That means businesses should not limit their September readiness work to products they plan to launch after 2027.
Existing product portfolios need to be considered too.
This substantially changes the preparation exercise.
A company may need visibility across products launched years ago, including:
- affected software versions;
- deployed hardware versions;
- active customers;
- current maintenance status;
- third-party dependencies;
- security contacts;
- vulnerability-response processes.
The key question becomes:
If exploitation were detected in one of our existing products, could we determine within hours which versions and customers are affected?
That is fundamentally a data-management problem as much as a cybersecurity problem.
The CRA is not only an IT-security project
It would be easy to assign the Cyber Resilience Act to the Chief Information Security Officer and consider the issue solved.
That would misunderstand the regulation’s operational impact.
CRA readiness crosses several business functions.
Engineering
Needs visibility into vulnerabilities, affected components and corrective measures.
Product management
Needs to understand which commercial products and versions are affected.
Security
Needs detection, triage and incident-response capability.
Legal and compliance
Need to assess reporting obligations and regulatory exposure.
Procurement
Needs cybersecurity requirements and escalation mechanisms for suppliers.
Customer support
May become an important source of information about security incidents in deployed products.
Executive management
Needs clear ownership and escalation rules for material cybersecurity events.
A 24-hour reporting requirement exposes weaknesses between departments very quickly.
The technical vulnerability might begin in one system.
The compliance obligation belongs to the organisation.
Five actions to complete before 11 September
Businesses that may fall within the CRA should use the remaining preparation period productively.
1. Map the product portfolio
Identify hardware, software and relevant components made available on the EU market and determine which legal entity acts as manufacturer.
2. Define the Article 14 decision process
Document how actively exploited vulnerabilities and potential severe incidents will be identified, classified and escalated.
3. Assign reporting responsibility
Name primary and backup personnel responsible for the ENISA Single Reporting Platform and internal approvals.
4. Test the 24-hour workflow
Run a tabletop exercise.
For example:
A security researcher reports evidence that attackers are exploiting a vulnerability in one of your products.
Then measure how long it takes the organisation to:
confirm receipt → engage security → identify the product → assess exploitation → involve legal/compliance → prepare an early warning.
The exercise will reveal bottlenecks far more effectively than another policy document.
5. Review supplier escalation requirements
Identify suppliers whose components could materially affect your products and verify that contractual and operational escalation channels are fast enough to support your obligations.
Do not confuse September 2026 with full CRA compliance
Another important distinction should remain clear.
The reporting obligations begin on 11 September 2026.
Most of the CRA’s wider requirements—including the broader framework concerning cybersecurity requirements, conformity assessment and product obligations—generally become applicable on 11 December 2027.
The European Commission published additional CRA implementation guidance on 27 July 2026 covering issues including scope, substantial modifications, support periods, reporting obligations and cybersecurity risk assessments. The Commission describes that guidance as non-binding but intended to support practical implementation.
September is therefore not the end of CRA implementation.
It is the beginning of its first major operational obligation for manufacturers.
The bigger business lesson
The most significant change introduced by the 24-hour deadline may not be the reporting form itself.
It is the expectation that manufacturers know enough about their products to respond quickly when exploitation occurs.
That requires visibility across:
Products
Versions
Components
Vulnerabilities
Suppliers
Customers
Security evidence
Regulatory responsibilities
Many organisations already possess most of this information.
The problem is that it may be distributed across engineering tools, supplier databases, spreadsheets, vulnerability-management platforms, contracts, ticketing systems and email.
The CRA therefore exposes a broader challenge:
Cybersecurity compliance increasingly depends on connected, reliable and accessible operational data.
The X3AI perspective
The Cyber Resilience Act illustrates a wider transformation in regulatory compliance.
Regulation is increasingly moving closer to real-time operations.
A company can no longer rely solely on annual compliance reviews when a regulatory response may need to begin within 24 hours of discovering a cybersecurity event.
This creates opportunities for better use of digital workflows, automation and AI.
Technology can potentially help organisations:
- correlate vulnerability information with affected products;
- analyse security advisories;
- identify relevant suppliers and components;
- classify incoming security information;
- retrieve supporting documentation;
- coordinate incident workflows;
- track reporting deadlines;
- maintain auditable records.
But automation does not remove accountability.
Decisions about whether a vulnerability or incident meets a regulatory threshold require appropriate technical, legal and human judgement.
The strongest approach therefore combines:
automation for speed
with
human oversight for accountability.
For manufacturers operating in the European market, 11 September 2026 is an important milestone.
The question is no longer whether the Cyber Resilience Act will affect cybersecurity processes.
The reporting clock is about to start.
X3AI — Enabling people and organisations to turn AI into practical value.
Primary sources
The legal basis is Regulation (EU) 2024/2847, the Cyber Resilience Act, including Article 14 and the application timetable in Article 71.
The European Commission’s official CRA overview explains product scope, manufacturer obligations, reporting deadlines and transitional arrangements.
The Commission’s dedicated reporting page confirms the 24-hour, 72-hour and final-report deadlines and the use of the CRA Single Reporting Platform.
ENISA’s current Single Reporting Platform FAQ explains the reporting mechanism, definitions, deadlines and planned platform operation from 11 September 2026.
The European Commission’s 27 July 2026 CRA guidance provides the latest implementation guidance for businesses.
This article is provided for general informational purposes and does not constitute legal advice. Organisations should assess the application of Regulation (EU) 2024/2847 to their specific products, activities and legal roles and obtain appropriate professional advice where necessary.
This one is particularly strong for x3ai.net because it is both current and actionable. It also gives you natural follow-up content: a “CRA 24-Hour Incident Response Checklist” could be turned into a downloadable one-page X3AI resource and used for LinkedIn lead generation.
Schreiben Sie einen Kommentar