Cyber Resilience Act Requirements: A Plain Guide for Connected Device Brands

A product manager at a smart home brand asked me recently whether the EU Cyber Resilience Act was something to worry about in 2027. Partly, yes. But one piece of it has applied since September 2026, and the rest arrives in about 13 months, which in my experience lines up with roughly one hardware development cycle.

This is my plain reading of the Cyber Resilience Act's requirements for connected device brands. It's general information, not legal advice, and your legal and compliance team should have the final say on how the rules apply to your products.

What the Cyber Resilience Act is

The Cyber Resilience Act, or CRA, is an EU regulation (Regulation (EU) 2024/2847) that sets mandatory cybersecurity requirements for hardware and software products with digital elements made available on the EU market. It covers how those products are planned, designed, developed and maintained, and it requires manufacturers to handle vulnerabilities over the product's life. Products that meet the rules carry the CE marking, and national market surveillance authorities enforce them.

The dates that matter

These are the CRA dates I'd put on any connected device team's wall:

• 10 December 2024: the CRA entered into force.
• 11 June 2026: the rules on notifying conformity assessment bodies started to apply. These are the organizations that do third-party assessments.
• 11 September 2026: reporting obligations started to apply. This part is already live.
• 11 December 2027: the main obligations apply. This is the EU Cyber Resilience Act deadline most people mean.

The European Commission also published non-binding practical guidance on 27 July 2026 covering scope, support periods, reporting and risk assessment.

Is your product in scope?

For most smart home and IoT brands, probably yes. The CRA applies to products with digital elements made available on the EU market whose intended or reasonably foreseeable use includes a direct or indirect logical or physical data connection to a device or network. That describes nearly every connected device, whether it talks over Wi-Fi, Bluetooth LE, Thread or Zigbee.

Two details catch people out. First, the definition includes the product's remote data processing solutions: cloud processing designed by or for the manufacturer, without which the product couldn't perform one of its functions. If your device needs your cloud backend to work, that backend is part of the picture. Second, there are exclusions, mostly for products already covered by other EU legislation, so check where yours sits.

Some product categories get stricter treatment. The CRA lists important products in two classes, and class I includes smart home products with security functionalities, including smart door locks, security cameras, baby monitoring systems and alarm systems. For class I products, a manufacturer can use self-assessment only if it applies harmonised standards, common specifications or a European cybersecurity certification scheme at assurance level at least "substantial," where those exist. Otherwise a notified body has to assess the product.

What manufacturers have to do

Most obligations fall on the manufacturer, meaning whoever develops the product or has it made, and markets it under its own name or trademark, whether or not it's sold for money. Importers and distributors have their own duties too, such as checking for the CE marking and the manufacturer's contact details. In broad strokes, a manufacturer has to:

• Carry out a cybersecurity risk assessment and use it through planning, design, development, production, delivery and maintenance.
• Meet the essential cybersecurity requirements in Annex I. Examples include shipping without known exploitable vulnerabilities, a secure by default configuration with the option to reset the product to its original state, and a way to fix vulnerabilities through security updates. Where applicable, automatic security updates should be on by default, with a clear and easy-to-use opt-out mechanism.
• Do due diligence on third-party components, so a chip SDK or open source library doesn't undermine the product's security.
• Keep technical documentation, run the right conformity assessment, draw up the EU declaration of conformity and affix the CE marking.
• Set a support period and handle vulnerabilities effectively throughout it.

Support periods: the part owners will see

Under the CRA, a manufacturer sets a support period during which it handles the product's vulnerabilities. The support period must be at least five years, unless the product is expected to be in use for less time, in which case the support period has to match that shorter span. Manufacturers also have to set the support period to reflect how long the product is genuinely expected to stay in use, so a product expected to last longer than five years needs a support period to match. The end date, including the month and year, has to be stated clearly at the time of purchase.

I think this is the piece of the CRA that will change the customer experience most. Owners will be able to see, before they buy, how long a device will get security support. That makes your update track record something people can compare. It also means you need a plan for telling owners when a device reaches the end of its support period. The regulation's recitals say that where a product has a user interface, manufacturers should use it to inform users about that, while keeping notifications to what's necessary.

Reporting obligations, live since September 2026

Since 11 September 2026, manufacturers have had to report actively exploited vulnerabilities and severe incidents that affect the security of their products. This applies to products already on the EU market, including ones placed there long before December 2027. The timeline is tight:

• An early warning within 24 hours of becoming aware.
• A full notification within 72 hours.
• A final report no later than 14 days after a corrective or mitigating measure is available, for actively exploited vulnerabilities.
• A final report within one month of the 72 hour notification, for severe incidents.

Reports go through the CRA Single Reporting Platform run by ENISA, the EU cybersecurity agency. They're addressed to the national Computer Security Incident Response Team (CSIRT) in the country of your main EU establishment, which shares them with the CSIRTs in other countries where the product is sold. If you have no main establishment in the EU, the rules point instead to your EU authorised representative, importer, distributor or user base, in that order. One small relief: micro and small enterprises can't be fined for missing the 24 hour deadline.

If your team doesn't yet have a named owner and a written process for the exploited vulnerability someone finds at 6 p.m. on a Friday, that's the first thing I'd fix.

What about devices you already sell?

Products placed on the EU market before 11 December 2027 only fall under the CRA's main requirements if they get a substantial modification from that date. The reporting obligations don't wait for that: they apply to your whole installed base now. So the line between a routine update and a substantial modification is worth discussing with your compliance team early. The Commission's guidance covers that question too.

A practical CRA checklist for connected device teams

1. List every product you sell or plan to sell in the EU, plus the cloud services and apps each one needs to function.
2. Check which products might be important products in class I or class II, especially locks, cameras, baby monitors and alarm systems.
3. Name an owner for vulnerability reporting and write the 24 hour, 72 hour and final report process down. Test it with a dry run.
4. Decide realistic support periods per product, knowing the end date will be shown to buyers.
5. Review how security updates reach devices in the field, including automatic updates and a clear, easy-to-use opt-out.
6. Audit default settings, default credentials and reset behavior against the secure by default requirement.
7. Map third-party components, from chipset SDKs to open source libraries, and how you'll track their vulnerabilities.
8. Plan how you'll tell owners about security updates and the end of support, in the app and by email.
9. Book time with legal and compliance to confirm all of the above.

Hardware choices made today will ship into the 2027 rules, so they matter here as well. If you're picking a chipset or radio for a new product, our guides on ESP32 vs other IoT chipsets and Bluetooth LE vs Wi-Fi vs Thread for device onboarding are good companions to this post. And if Matter is on your roadmap, see our guide on whether your product should support Matter.

Your connected product's customer data needs the same attention. Copilot.cx Sphere is a secure and private customer cloud for IoT products. It handles registration, login and password recovery, supports OAuth 2.0 and OpenID Connect, manages user-to-device and user-to-household associations and helps you anonymize customer data. It won't make a product CRA compliant by itself, since that responsibility stays with the manufacturer, but it can take one piece of the security picture off your team's plate.