A router still works but no longer receives patches. A connected camera remains accessible from the Internet even though its manufacturer has abandoned its software. These products are not necessarily broken: they have become difficult to protect. The Cyber Resilience Act (CRA), the European regulation on cyber resilience, aims to change that. Its principle: selling a connected device or software is no longer enough; its security must also be managed over time. In September 2026, that promise enters its first operational phase, ahead of the general application scheduled for late 2027.
September 2026: an initial deadline, not the full switchover
Adopted in 2024, the CRA entered into force on 10 December that year. Its timetable sets out several stages. The provisions on the notification of conformity assessment bodies have applied since 11 June 2026. Reporting obligations for actively exploited vulnerabilities and severe incidents take effect on 11 September 2026. Most product requirements will follow on 11 December 2027. It would therefore be misleading to suggest that all devices sold in autumn 2026 are already subject to the entire framework.
This phased rollout allows time, but it also requires planning ahead. Equipment designed today may still be on sale after the general deadline. Above all, setting up a vulnerability response team, compiling an inventory of software components and securing patch distribution cannot be done in a matter of weeks. The outlook is fairly clear: manufacturers that wait until 2027 to get organised risk discovering that their biggest challenge is not legal, but technical and human.
Digital products become a lasting responsibility
The legislation broadly targets products with digital elements: software, equipment and components whose intended or reasonably foreseeable use involves a direct or indirect connection to a device or network. This could cover anything from a smart lock to an industrial system. There are exclusions, notably for certain products already covered by sector-specific rules. Not all online services are automatically covered, but some remote data processing functions essential to a product may fall within its scope.
The central change concerns the product lifecycle. Manufacturers must assess risks, design products with an appropriate level of cybersecurity and address their vulnerabilities throughout the support period. Security can no longer be reduced to a pre-launch audit. It becomes an ongoing activity: receiving an alert, checking which models are affected, developing a patch, testing it and then enabling users to install it without turning their equipment into a paperweight.
Vulnerability reports must no longer end up in a forgotten inbox
Recent history explains this priority. The Log4Shell vulnerability, disclosed in December 2021 in the Log4j Java library, served as a reminder of how a little-noticed component could be embedded in a vast range of software. Before it could be patched, organisations had to know where it was being used. Among other requirements, the CRA mandates component documentation, including a software bill of materials in a commonly used, machine-readable format. This inventory is not an absolute guarantee; it is a prerequisite for rapid investigation.
Another foundational requirement is to have a coordinated vulnerability disclosure policy and make reporting easier. In practice, a researcher should not have to contact the sales department to warn that a thermostat is exposing credentials. Behind the point of contact, there must be a process capable of assessing the problem, communicating with the person who reported it and preparing remediation. The real test will be less about whether an email address exists than whether it receives a useful response.
Report quickly, without treating every flaw alike
From 11 September 2026, the regulatory timetable requires an early warning within 24 hours of becoming aware of an actively exploited vulnerability, followed by a more comprehensive notification within 72 hours. The framework involves CSIRTs designated as coordinators and ENISA, the European Union Agency for Cybersecurity. Obligations also apply to severe incidents affecting product security. Not every newly discovered flaw therefore automatically requires a regulatory alert within 24 hours. This distinction helps separate day-to-day management from a confirmed emergency.
Support becomes a product feature
How long must a manufacturer support its product? The regulation requires a support period to be defined, taking into account, among other factors, the product’s expected period of use. This period must be at least five years, unless the product is expected to be used for less time. But five years is not a universal ceiling: equipment intended to remain in service for a long time may require a longer period. Manufacturers must make the support end date clearly accessible to buyers.
This information could become as decisive as battery life or storage capacity. Is a discounted device still a good deal if its support is nearing its end? Can a business buy sensors intended to operate for ten years without knowing their maintenance roadmap? In time, buyers could compare the cost of secure use rather than simply the purchase price. That shift remains a possibility, but the regulation provides a concrete benchmark for raising the question before signing.
Updates are free, but never free to produce
The CRA generally provides for security updates to be distributed free of charge, with a narrowly defined exception for certain specific business-to-business agreements concerning tailor-made products. It also requires secure distribution mechanisms. The challenge is not merely to publish a file: manufacturers must prevent attackers from replacing the patch, inform users and facilitate deployment. Where technically feasible, a security update should also be distinguishable from a functionality update.
For manufacturers, this continuity comes at a cost: retaining expertise, maintaining infrastructure and testing several generations of equipment. It could encourage simpler architectures and less fragmented product ranges. Conversely, compliance that exists only on paper would leave the problems unresolved. Using open-source components does not remove the manufacturer’s responsibility either: manufacturers must know their dependencies and arrange for them to be monitored, without treating all volunteer contributors as commercial manufacturers subject to the same obligations.
Trust will be measured after launch
The CRA does not promise invulnerable products. It establishes a framework for compliance, market surveillance and penalties to make security less optional. Its effectiveness will also depend on the resources available to authorities and the quality of assessments. For users, the tangible signs will be simple: a clear support end date, useful alerts and patches that are actually available.
What happens next? Ahead of the regulation’s general application in December 2027, manufacturers would be well advised to treat maintenance as part of the product, with a budget allocated from the design stage. Distributors and buyers can already demand specific commitments. If the regulation delivers on its promise, the best question will no longer simply be “Is it secure today?” but “Who will look after its security tomorrow?”
