Software updates are becoming part of the product promise
Europe’s Cyber Resilience Act is moving through implementation. The practical change is simple: connected products will need clearer support periods, vulnerability handling and incident reporting.

A software update used to feel like an afterthought. Sometimes it arrived as a welcome fix. Sometimes it interrupted a working day. Sometimes, with cheaper connected devices, it never arrived at all. Europe is now turning that loose expectation into a formal product responsibility.
The law doing it is the Cyber Resilience Act, the EU regulation for products with digital elements. It entered into force on 10 December 2024, according to the European Commission. Its main obligations apply from 11 December 2027, but one earlier deadline is close enough to matter for product teams now: from 11 September 2026, manufacturers must report actively exploited vulnerabilities and severe incidents affecting the security of covered products.
That sounds like Brussels machinery, and some of it is. The reader-facing point is simpler. If a product is sold with software inside it, or as software that connects to a device or network, security can no longer be treated as a vague promise in the support page. The regulation covers hardware and software products made available on the EU market where the intended or reasonably foreseeable use includes a direct or indirect data connection to a device or network. The Commission’s own examples include apps, computer programs, baby monitors and smart watches.
The shift is clearest in the word “support”. The Commission’s manufacturer guidance says companies must design hardware and software to be foundationally secure, avoid insecure defaults such as “password” as the default password, maintain products for the time they are expected to be used, and handle vulnerabilities during the indicated support period. The EUR-Lex text says the support period is at least five years unless the product is expected to be used for less time.
For a buyer, that could make the boring pre-purchase questions more useful. How long will this device get security updates? Is the support period stated plainly? If a flaw is found, is there a route for reporting it and a process for fixing it? None of those questions is as easy to market as a brighter screen or a faster chip. They may matter more after the first month.
The first operational squeeze comes through reporting. The Commission’s CRA reporting page says manufacturers will need to submit an early warning within 24 hours of becoming aware of an actively exploited vulnerability or severe incident, followed by a full notification within 72 hours. Final reports are due no later than 14 days after a corrective measure is available for actively exploited vulnerabilities, and within a month for severe incidents. ENISA’s Single Reporting Platform is due to become the single tool for that reporting by 11 September 2026.
This is not only a compliance calendar. It changes what a responsible product operation has to know. A manufacturer cannot report quickly if it cannot tell which products are affected, who owns the incident internally, what versions are exposed, how users will receive a fix, and how to communicate without creating more risk. The software update becomes part of the product, not a favour done after the sale.
There are limits to how visible this will be. Most people will not read a vulnerability policy before buying a camera, router or app. CE marking is familiar but not self-explanatory. A support period on a page does not guarantee a painless fix. And the law does not magically secure products already sitting in cupboards, drawers and server rooms. The practical effect will depend on standards, enforcement and whether companies treat support as engineering work rather than legal copy.
The Act also avoids the crude version of the story where every piece of open-source code suddenly becomes a regulated product. The Commission says free and open-source software falls within scope when it is made available on the market in the course of a commercial activity. Non-monetised free and open-source software is generally not considered commercial activity, and individual developers contributing code to projects they do not control are not covered in the same way. The regulation also creates a separate category for open-source software stewards.
Nor does every app need a government inspector before release. The Commission’s conformity assessment guidance says most products, including many mobile applications, computer games and household appliances, can be self-assessed by manufacturers. Some important or critical cybersecurity products, such as certain operating systems, firewalls, routers, secure elements and hypervisors, face stricter routes that may involve harmonised standards or third-party assessment.
That balance matters. If the law becomes only paperwork, users will see little change beyond longer documents. If it works as intended, the most important difference may be cultural: product launches will have to carry a longer tail. Support periods, update availability, vulnerability handling and incident reporting will move closer to the product roadmap.
The useful question for readers is not whether a connected product can promise perfect safety. It cannot. The useful question is whether the maker can explain how long it will stand behind the software. In a market full of cheap connected things, that is a more practical promise than another glossy feature box.
Editorial note. This article is general technology and policy information. It is not legal, cybersecurity, procurement or product-compliance advice.
Sources
- European Commission - “Cyber Resilience Act” - - extracted 2026-06-07. Verified: CRA entered into force on 10 December 2024; reporting obligations apply from 11 September 2026; main obligations apply from 11 December 2027; scope covers products with digital elements and CE marking
- European Commission - “Cyber Resilience Act - Manufacturers” - - extracted 2026-06-07. Verified: manufacturer duties before, at and after market placement; security by default; no insecure default password example; support period disclosure; vulnerability handling and reporting duties
- European Commission - “Cyber Resilience Act - Reporting obligations” - - extracted 2026-06-07. Verified: 11 September 2026 reporting start; 24-hour early warning, 72-hour full notification and final report timelines; Single Reporting Platform route
- ENISA - “Single Reporting Platform (SRP)” - - extracted 2026-06-07. Verified: SRP purpose, mandatory reporters, voluntary reporting possibility and operational timeline
- EUR-Lex - Regulation (EU) 2024/2847 - - extracted 2026-06-07. Verified: legal title, subject matter, product-with-digital-elements definition, scope, support-period baseline and security update availability
- European Commission - “Cyber Resilience Act - Open source” - - extracted 2026-06-07. Verified: commercial-activity scope for free and open-source software, individual contributor treatment and open-source software steward category
- European Commission - “Cyber Resilience Act - Conformity assessment” - - extracted 2026-06-07. Verified: self-assessment for most products and stricter assessment routes for important or critical products
Help us improve
Was this article useful?
One anonymous tap helps Sona improve future reporting, headlines and source context.
Up next

The EU AI Act is no longer just a policy story. Its staged deadlines are turning abstract promises about trustworthy AI into records, labels and internal checks.
Continue reading

