On 10 December 2024, the EU Cyber Resilience Act entered into force as Regulation (EU) 2024/2847. Reporting of actively exploited vulnerabilities starts on 11 September 2026. From 11 December 2027, a product with digital elements has to meet the CRA's essential cybersecurity requirements to carry the CE marking, and without the CE marking it can't be sold in the EU (Regulation (EU) 2024/2847).
Three years sounds like a lot of time. For a product that's in design today, it's one release cycle.
The idea behind the regulation is simple. European consumers expect the food they buy in the EU to be safe, and the CRA asks the same of digital products. Years of self-regulation didn't get there, so the EU chose to regulate. That ends two habits many vendors still rely on: licence terms that sell software "as is", and components bought in and built into products without anyone assessing their risk.
We've written up the seven aspects of the CRA that we think matter most for anyone who releases, develops or integrates software or hardware for the EU market. The full whitepaper covers each one with the relevant articles and annexes, and what we'd do about it. Here's the short version.
1. It reaches far beyond IoT
Most vendors and manufacturers we speak to assume the CRA targets cheap connected gadgets. It doesn't. It covers any product with digital elements whose intended or foreseeable use includes a data connection to a device or a network (Art. 2(1)), including the remote data processing it needs to work. Accounting software, a mobile operating system, a network card and a programmable logic controller are all in scope. Medical devices, motor vehicles and civil aviation stay under their own rules (Art. 2(2)).
2. Security is designed from a risk assessment
The manufacturer assesses the cybersecurity risks early and designs the product to match them (Art. 13). Annex I lists what the design has to cover, from secure-by-default configuration and access control to data minimisation, exploit mitigation, logging and secure updates. We use STRIDE threat modelling for this, and we document every decision to accept, mitigate or transfer a risk, with the reason.
3. What you designed is implemented and tested
The product reaches the market without known exploitable vulnerabilities (Annex I Part I(2)(a)), and the manufacturer runs effective and regular security tests (Annex I Part II(3)). In practice, that means positive and negative tests in the development pipeline, and at least one end-to-end penetration test of the whole system by people who know firmware, hardware and back ends.
4. You can prove it
The CE marking is a declaration, so the manufacturer keeps technical documentation that shows how each requirement was met (Art. 31). That includes a machine-readable software bill of materials covering at least the top-level dependencies (Annex I Part II(1)). Of all the requirements, this is the one our clients find hardest. If your suppliers can't tell you what's inside the components you buy from them, start asking now. Those answers end up in your own SBOM, and in your own risk assessment.
5. Users get a security handbook
Users receive information on the product's security: the environment it's meant for, how to install updates, how long security support lasts, and how to decommission it and remove their data (Annex II).
6. Security runs for the whole lifecycle
The manufacturer handles vulnerabilities for the support period, at least five years unless the product's expected use is shorter (Art. 13(8)). That covers secure updates, a coordinated vulnerability disclosure policy and, from September 2026, reporting actively exploited vulnerabilities within 24 hours (Art. 14). Update mechanisms are among the weaknesses we find most often when we test embedded products. They're often the quickest way to administrative access.
7. It takes legal and technical people together
The CRA sits next to GDPR, NIS2 and the AI Act. Cybersecurity is technical, but it now carries legal weight, and getting a product to market needs both views from the first design review onwards. For years, a lawyer joining a cyber deal meant trouble. Under the CRA, product teams need one at the table.
Download the whitepaper
The whitepaper goes through all seven aspects in detail, with the Annex I requirements, the handbook checklist, the key dates and three steps to start with. It's written for product, engineering and compliance leads.
Download The Critical 7 of the Cyber Resilience Act
If you'd like to check a product against the CRA, from threat model to hardware and firmware testing, book a demo and we'll walk you through how we'd approach it.
The Crimson7 Research Team tests hardware, firmware, industrial systems and connected products in our own lab, and turns what we find into detections and fixes. This article is general guidance, not legal advice.
