What the Cyber Resilience Act actually asks you to test

What is in scope, and what is deliberately out

Regulation (EU) 2024/2847 applies to products with digital elements made available on the market whose intended purpose or reasonably foreseeable use includes a direct or indirect logical or physical data connection to a device or network. That description covers almost every connected product and a great deal of software.

The exclusions in Article 2 are narrow and specific. The Regulation does not apply to products covered by Regulation (EU) 2017/745 or Regulation (EU) 2017/746, the medical device and in vitro diagnostic regulations; to products covered by the vehicle general safety Regulation (EU) 2019/2144; to products certified under the aviation Regulation (EU) 2018/1139; or to marine equipment within Directive 2014/90/EU. Identical spare parts are out, as are products developed or modified exclusively for national security or defence.

Annex I Part I: thirteen properties, all testable

Part I opens with a general obligation: products shall be designed, developed and produced in such a way that they ensure an appropriate level of cybersecurity based on the risks. It then lists thirteen specific properties which apply on the basis of the risk assessment required by Article 13(2), and where applicable.

That “where applicable” is not an escape hatch. Article 13(4) requires that where a requirement is not applicable to the product, the manufacturer includes a clear justification to that effect in the technical documentation. You do not get to skip a requirement quietly.

Point (j) deserves attention from anyone shipping hardware. The obligation to limit attack surfaces including external interfaces is the first time EU horizontal law has said, in an operative provision, that leaving a debug header live on a production board is a compliance problem and not merely bad practice.

Annex I Part II: the process duties, including regular testing

Part II sets eight vulnerability-handling requirements that apply to the manufacturer’s processes rather than to the product. Manufacturers shall identify and document vulnerabilities and components, including by drawing up a software bill of materials in a commonly used and machine-readable format covering at the very least the top-level dependencies. They shall address and remediate vulnerabilities without delay, and where technically feasible provide security updates separately from functionality updates.

Point 3 is the one that concerns this site directly. Manufacturers shall apply effective and regular tests and reviews of the security of the product with digital elements. There is no defined interval, no named methodology and no exemption for small products.

The remaining points require public disclosure of fixed vulnerabilities once an update is available, a coordinated vulnerability disclosure policy, a contact address for reports, secure update distribution mechanisms, and dissemination of security updates without delay and free of charge for non-tailor-made products.

Manufacturers shall ensure, when placing a product with digital elements on the market, and for the support period, that vulnerabilities of that product, including its components, are handled effectively.Regulation (EU) 2024/2847, Article 13(8)

Important and critical products: who loses self-declaration

Article 7 designates products whose core functionality matches a category in Annex III as important products with digital elements, and subjects them to the conformity assessment procedures in Article 32(2) and (3).

Class I

The hardware-relevant Class I categories are: physical and virtual network interfaces; operating systems; routers, modems intended for connection to the internet, and switches; microprocessors, microcontrollers, ASICs and FPGAs with security-related functionalities; smart home general purpose virtual assistants; smart home products with security functionalities, including smart door locks, security cameras, baby monitoring systems and alarm systems; internet connected toys with social interactive or location tracking features; and personal wearable products with a health monitoring purpose outside the medical device regulations, or wearables intended for use by and for children.

Commission Implementing Regulation (EU) 2025/2392, adopted on 28 November 2025, gives the technical description of each category. It is worth reading before assuming a product is out. The description of switches, for example, expressly includes bridges such as wireless access points.

Class II and Annex IV

Class II covers hypervisors and container runtime systems, firewalls and intrusion detection and prevention systems, and tamper-resistant microprocessors and microcontrollers. Annex IV, the critical products, lists hardware devices with security boxes, smart meter gateways and other devices for advanced security purposes including secure cryptoprocessing, and smartcards or similar devices including secure elements.

What that means for the route

For a Class I product where the manufacturer has not applied harmonised standards, common specifications or a European cybersecurity certification scheme at assurance level at least “substantial”, or has applied them only in part, or where they do not exist, Article 32(2) requires EU-type examination plus conformity to type, or full quality assurance. For a Class II product, Article 32(3) removes the self-declaration option altogether. The structure mirrors the RED, which the note on the RED cybersecurity requirements describes.

The support period is the real commitment

Article 13(8) requires the manufacturer to determine a support period reflecting how long the product is expected to be in use, and sets a floor: the support period shall be at least five years, or the expected use time where that is shorter. Article 13(9) then requires each security update issued during that period to remain available for at least ten years, or the remainder of the support period if longer.

Read together with the Part II duty to apply effective and regular tests, the support period is what turns device testing from a launch activity into a programme. A product with a seven-year support period has seven years of vulnerability handling, seven years of update obligations, and seven years in which “regular” has to mean something defensible.

This is also the failure mode governments are now naming publicly. The April 2026 joint advisory on China-nexus covert networks found that the edge devices absorbed into those networks were vulnerable because they were end of life, out of date and no longer receiving updates or security patches from their manufacturers.

Third-party components, and what the user has to be told

Two obligations sit either side of the product boundary and are easy to overlook because neither is a security control in the usual sense.

On the way in, Article 13(5) requires manufacturers to exercise due diligence when integrating components sourced from third parties, so that those components do not compromise the cybersecurity of the product. That expressly includes components of free and open-source software that were never made available on the market in the course of a commercial activity. Article 13(6) then says what happens when due diligence finds something: on identifying a vulnerability in a component, including an open-source component, the manufacturer shall report it to the person or entity manufacturing or maintaining that component, address and remediate it, and where they developed a software or hardware modification, share the relevant code or documentation upstream, where appropriate in a machine-readable format.

On the way out, Annex II sets what must accompany the product. Alongside the usual identification data it requires the single point of contact where vulnerabilities can be reported and where the coordinated vulnerability disclosure policy can be found, the type of technical security support offered, and the end-date of the support period during which users can expect vulnerabilities to be handled and security updates to arrive. It also requires instructions on secure commissioning, on installing security updates, on turning off the default automatic update setting, and on secure decommissioning including how user data can be securely removed. Article 13(17) requires that single point of contact to be designated and easily identifiable by users.

Both of these are testable claims rather than paperwork. A stated end-of-support date can be checked against what the device tells its owner. A published reporting contact can be checked by using it.

Article 14: the clocks are already running

Article 71(2) sets three application dates. Chapter IV, on notification of conformity assessment bodies, applied from 11 June 2026. Article 14 applied from 11 September 2026. The rest of the Regulation applies from 11 December 2027. Crucially, Article 69(3) extends the Article 14 duty to all in-scope products placed on the market before that date, so the installed base is already covered.

A 24-hour clock is short. It is short enough that the practical question is not whether you can write the notification, but whether you will know. That depends on having a disclosure channel people actually use, monitoring that surfaces exploitation, and a relationship with testers who report to you before they report elsewhere.

A defensible testing cadence

Since the Regulation does not define “regular”, a manufacturer has to define it and be able to justify it. A cadence that stands up to questioning usually has four elements.

• At first placing on the market. A full assessment across board, firmware, radio, application and service, on the revision that ships.
• On substantial modification. Article 69(2) makes substantial modification the trigger that pulls an older product into the Regulation, so it should also trigger reassessment.
• On a fixed periodic interval across the support period. Annually is the common choice for a product with an active development team; a stable product with infrequent releases can justify longer, if the justification is written down.
• On material change in the threat picture. A new class of attack against your radio stack, your chipset or your update mechanism is a reason to test, and documenting that trigger is cheaper than defending its absence.

Whatever cadence you choose, record the reasoning in the same place as the risk assessment. Article 13(3) requires that assessment to be documented and updated as appropriate during the support period, which makes it the natural home for the testing schedule as well.

For the hardware half of the work – which is where Annex I point (2)(j) actually lands – see the note on the hardware attack surface, or use the attack surface mapper to sketch the scope before you talk to anyone about price.