A connected product can remain in homes and businesses for years after its first sale. During that time, researchers discover vulnerabilities, attackers develop exploits, and the software components inside the device continue to change. Europe鈥檚 Cyber Resilience Act is intended to make cybersecurity a product-lifecycle responsibility rather than a feature that ends at launch.
The regulation鈥檚 main provisions become fully applicable in December 2027, but an important earlier deadline is approaching. From September 11, 2026, manufacturers must report actively exploited vulnerabilities and severe security incidents affecting covered products with digital elements. The timetable will make vulnerability intake, triage, evidence, and communication operational requirements for companies that sell connected hardware or software in the European Union.
Which Products Are Covered?
The Cyber Resilience Act, or CRA, applies broadly to products with digital elements made available on the EU market when their intended or reasonably foreseeable use includes a direct or indirect data connection. That can include consumer devices, network equipment, business software, and software components. Some categories governed by other sector-specific EU rules are excluded or treated separately.
The main obligations generally fall on the manufacturer: the entity that develops a product, or has it developed, and markets it under its own name or trademark. Importers and distributors have their own checks and cooperation duties. The exact role matters because a product may be designed outside Europe, branded by another company, and sold through several channels.
Reporting Starts Before the Main Rules
The CRA entered into force in December 2024. Rules concerning conformity-assessment bodies started applying in June 2026. The vulnerability and incident reporting obligations apply from September 11, 2026, while the main product requirements apply from December 11, 2027.
The earlier reporting date matters because it covers products with digital elements already made available on the EU market, not only newly launched products. A manufacturer cannot wait for the 2027 product-compliance deadline before building a process for receiving security reports and deciding whether an event meets the notification criteria.
That process is different from a general customer-support queue. It needs people who can connect a report to affected product versions, reproduce the issue, determine exploitation status and impact, coordinate a corrective measure, and meet a short regulatory clock.
What Must Be Reported?
The reporting rules focus on actively exploited vulnerabilities and severe incidents that affect the security of the product. A vulnerability is not automatically reportable merely because it exists or has been disclosed. The exploitation and impact criteria matter, and manufacturers need documented methods for making those judgments.
The European Commission鈥檚 implementation page describes a staged timetable. An early warning is due within 24 hours after the manufacturer becomes aware. A main notification follows within 72 hours. For an actively exploited vulnerability, a final report is due no later than 14 days after a corrective or mitigating measure becomes available. For a severe incident, the final report is due within one month of the 72-hour notification.
One Platform Connects Multiple Authorities
Manufacturers will submit through the CRA Single Reporting Platform being established by the European Union Agency for Cybersecurity, ENISA. The notification is addressed to the Computer Security Incident Response Team, or CSIRT, in the member state where the manufacturer has its main establishment. Information is then shared with ENISA and relevant national CSIRTs under the regulation鈥檚 process.
The Commission says the platform will be operational by the September 2026 reporting date and will have a testing period before launch. Companies still need their own internal case system. The regulatory portal is the destination for a report, not a substitute for product inventories, on-call decisions, technical investigation, or customer communication.
ENISA鈥檚 European Vulnerability Database is related but separate. The CRA platform handles mandatory reports, including information about actively exploited vulnerabilities that may not yet be public. The EU vulnerability database is designed to make public vulnerability information accessible. Coordination between disclosure and remediation remains important so that a report does not unnecessarily give attackers a head start.
Software Inventories Become Operational Infrastructure
A manufacturer cannot respond quickly if it does not know which products contain a vulnerable library, service, or firmware component. A software bill of materials can help identify dependencies, but an inventory is useful only when it is current, connected to product versions, and paired with a way to assess whether the vulnerable code is reachable in a specific configuration.
Teams also need ownership information. A component may be maintained by an upstream open-source project, packaged by a supplier, integrated by a contractor, and shipped under the manufacturer鈥檚 brand. Contracts and incident plans should establish who investigates, who produces a fix, and who makes the regulatory decision.
The underlying implementation quality still matters. Moving security-critical code toward memory-safe languages can eliminate important classes of vulnerabilities, while code review, dependency control, testing, and secure update mechanisms address other failure modes. Reporting is the response layer, not the entire security program.
Support Periods Make Updates a Product Promise
The CRA鈥檚 broader requirements include effective vulnerability handling during the product鈥檚 support period and clear information for users. That pushes manufacturers to decide how long a connected product will receive security updates and to align hardware, software, suppliers, and update infrastructure around that period.
A long support statement has little value if an update cannot reach devices reliably or if installing it breaks essential functions. Products need authenticated updates, rollback or recovery where practical, version visibility, and a way to notify owners. Devices that are offline for long periods require special planning.
These concerns are visible in the smart-home security questions buyers should ask. Consumers benefit when update duration, reporting contacts, and end-of-support behavior are understandable before purchase rather than hidden in technical documentation.
Open Source Has a More Nuanced Role
Free and open-source software that is not supplied as part of a commercial activity is treated differently from a commercial product. The CRA also defines an open-source software steward: a legal entity that provides sustained support for particular open-source software intended for commercial activities and ensures its viability.
Stewards have duties involving cybersecurity policy, cooperation, corrective action, and reporting in the circumstances described by the regulation, but the framework is not identical to the obligations on a conventional product manufacturer. Companies that package open-source components into commercial products cannot assume the upstream project becomes responsible for the finished product.
What Good Preparation Looks Like
A workable program starts with a maintained list of products, software versions, components, support periods, and responsible teams. It provides a monitored channel for researchers and customers, a severity and exploitation triage method, protected evidence storage, and an escalation path that operates outside normal office hours.
Teams should rehearse the 24- and 72-hour timelines using a realistic scenario. The exercise can test who has authority to submit, which facts are available early, how legal and technical teams coordinate, and how communications avoid both delay and speculation. It should also test simultaneous remediation across several products that share one component.
Access to the reporting process should follow zero-trust principles. A platform account and sensitive vulnerability evidence should not be broadly shared. Strong identity, limited roles, logging, and recovery procedures reduce the chance that the response system itself becomes a target.
Limits and Unanswered Questions
Regulatory reporting does not guarantee that a fix arrives quickly, that users install it, or that every exploited vulnerability is detected. A short deadline may also produce incomplete early reports. The quality of later investigation, remediation, coordinated disclosure, and product updates remains decisive.
Implementation guidance and platform procedures will continue to mature. Manufacturers operating across several regimes may face overlapping incident definitions and reporting channels. Harmonized internal evidence can help, but each legal obligation still needs its own analysis.
What to Watch Next
Watch ENISA鈥檚 testing and launch of the Single Reporting Platform, Commission guidance on implementation, and how national CSIRTs coordinate submissions. Product makers should also watch the standards used to demonstrate conformity before the broader December 2027 requirements take effect.
For consumers, the most meaningful change will be quieter: clearer support periods, reachable security contacts, and products designed to receive fixes throughout their useful life. The reporting deadline is one visible milestone in a larger shift from optional device security toward accountable lifecycle engineering.
Leave a Reply