The EU Cyber Resilience Act is no longer a distant policy debate for companies that make, import, distribute or sell connected products. Most product requirements apply from December 2027, but one important part starts sooner: from 11 September 2026, manufacturers must report actively exploited vulnerabilities and severe cyber incidents affecting products with digital elements.
For many UK small businesses and manufacturers, that date is easy to miss. The Act is an EU law, but it can still matter if a product is placed on the EU market. That includes connected devices, embedded software, desktop applications, mobile apps and other products where software or network connectivity is part of the product’s function.
The practical point is not to panic or rewrite everything in a hurry. It is to work out whether your products are in scope, who carries which responsibility, and whether your business could detect, assess and report a serious issue within the required timescales.
What the Cyber Resilience Act Covers
The European Commission describes the Cyber Resilience Act as a framework for cyber security requirements across the lifecycle of products with digital elements. In plain terms, it is aimed at reducing insecure connected products entering the market and improving how vulnerabilities are handled after sale.
The law is deliberately broad. It can apply to physical connected products such as routers, smart sensors, industrial controllers, cameras, access-control devices and other internet-connected equipment. It can also apply to software products, including applications and components, depending on how they are supplied and used.
The Act entered into force in December 2024. Most obligations apply from 11 December 2027, giving businesses time to prepare. The earlier date is 11 September 2026, when the reporting duties for actively exploited vulnerabilities and severe incidents begin.
The 2026 Reporting Duty Is the Near-Term Issue
The Commission’s guidance on Cyber Resilience Act reporting sets out a staged reporting process. In broad terms, manufacturers must provide an early warning within 24 hours after becoming aware of an actively exploited vulnerability or severe incident, follow with a notification within 72 hours, and later provide a final report.
The same Commission guidance says reports will be submitted through a single reporting platform and routed to the relevant authorities. That matters operationally: businesses should expect a formal notification process, not an informal email exchange.
This is the part most likely to catch smaller firms off guard. A 24-hour early warning is not compatible with a vague support inbox, unclear product ownership, no vulnerability intake route and no internal decision-maker for incident severity. Even if a business rarely sees itself as a software company, the reporting clock may start when it becomes aware of a relevant issue.
Who Should Pay Attention?
The most obvious audience is manufacturers of connected products. But the Act can also affect importers, distributors and businesses that place software-enabled products on the EU market under their own name or trade mark.
A UK business should look closely if it:
- sells connected products, apps or software into the EU;
- builds software that is supplied as part of a physical product;
- imports connected devices and sells them under its own brand;
- adds firmware, apps, cloud dashboards or remote access to equipment;
- uses third-party components that could introduce product vulnerabilities;
- supplies manufacturing, logistics, energy, health, building-management or security technology.
The exact legal role matters. A reseller will not always have the same duties as a manufacturer, and not every internal system is a product placed on the EU market. Businesses with complex supply chains should check the text of the law and take specialist advice where the answer affects market access, contracts or product liability.
What “Product With Digital Elements” Means in Practice
The official Regulation (EU) 2024/2847 text defines a product with digital elements broadly. The useful business test is simpler: if the product includes software, firmware, connectivity or a digital component whose cyber security could affect the product, treat it as something to review.
That review should include less obvious dependencies. A product may rely on open-source libraries, cloud APIs, mobile apps, update servers, administrative dashboards, remote maintenance tools or supplier firmware. The customer sees one product, but the security picture is usually spread across several systems and organisations.
Why This Is a Business Systems Problem, Not Just a Technical One
Cyber compliance often fails at the handover points. The engineering team may know a firmware version is affected, customer support may receive the first complaint, the website may have no vulnerability disclosure route, and commercial teams may not know which EU customers received which product batch.
The Cyber Resilience Act therefore pushes businesses towards better operational records as well as better code. You need to know what you sell, which software versions are in the field, which components they contain, who monitors vulnerabilities, who can approve a report, and how customers will be told what to do.
This connects directly with website and digital operations. A public security contact, product-support page, update policy, documentation area and customer notification process may all become part of the evidence that a business can manage vulnerabilities responsibly.
A Practical Readiness Checklist
Small businesses do not need a giant compliance programme to make progress. They do need a controlled way to answer the basic questions quickly.
- List the products that may be in scope. Include connected hardware, software, apps, firmware and digital components supplied with equipment.
- Map your role for each product. Are you the manufacturer, importer, distributor, software supplier, white-label seller or service provider?
- Create a vulnerability intake route. Provide a monitored security contact or disclosure form, and make sure reports reach someone who can act.
- Record software versions and dependencies. A basic software bill of materials process is better than trying to reconstruct component use during an incident.
- Define severity and escalation rules. Decide who assesses whether an issue is actively exploited or severe enough to report.
- Prepare report information in advance. Product identifiers, affected versions, exploit status, mitigations, customer impact and contact details should not be improvised under time pressure.
- Check contracts with suppliers. You may need faster vulnerability notification, component information and support for fixes.
- Plan customer communication. Security fixes, update instructions and workarounds must be understandable to the people actually using the product.
Do Not Wait Until 2027
It is tempting to focus on the December 2027 date because that is when the wider product requirements apply. For a business that has never built a vulnerability management process, September 2026 is the more urgent milestone. Reporting depends on detection, ownership, evidence and decision-making. Those are hard to create during an incident.
There is also a commercial reason to start early. Larger customers, public-sector buyers and EU distributors may begin asking for Cyber Resilience Act readiness before the full application date. A clear product security process can support procurement, reduce support confusion and make software updates less chaotic.
What Website and Software Teams Can Do Now
For many smaller firms, the first visible improvements are modest:
- add a clear security contact page or vulnerability disclosure route;
- keep product documentation and update notes accurate;
- track which customers or distributors receive which product versions;
- separate marketing claims from verified security commitments;
- make sure web forms, support systems and CRM records can route security reports quickly;
- review software dependencies and update processes for connected products.
None of this replaces formal legal or product compliance work. It does, however, give the business a much better foundation for meeting the reporting deadline and for preparing for the wider 2027 requirements.
The Takeaway
The Cyber Resilience Act is part of a broader shift: connected products are being judged not only by features and price, but by how responsibly their security is managed over time. For UK businesses selling into the EU, the safest approach is to treat September 2026 as a practical readiness deadline.
Start with the products, software versions and customer routes you already have. Then make vulnerability reporting, supplier coordination and customer communication explicit. That is a manageable first step, and it will make the larger 2027 compliance work less rushed.
This article is general guidance, not legal advice. Businesses placing connected products or software on the EU market should check their specific obligations before relying on a particular interpretation.