Hardware

Hardware is a defined legal term in the Cyber Resilience Act (CRA). Article 3, point (5) treats it as a physical electronic information system capable of processing, storing or transmitting digital data, and as parts of such a system.

Two features carry the definition. The first is physicality: no physical substance, no hardware. The second is the reference to the electronic information system, which Article 3, point (7) describes as a system, including electrical or electronic equipment, capable of processing, storing or transmitting digital data.

The second half of the wording matters more in practice. Because parts of such a system are covered too, motherboards, microprocessors, memory chips and network interfaces fall under the term even though none of them amounts to a finished device.

Hardware and software

The counterpart definition sits immediately before it: Article 3, point (4) treats software as the part of an electronic information system which consists of computer code. Both terms point at the same system and divide it by substance, into code and matter.

They come together in the product with digital elements, which Article 3, point (1) defines as a software or hardware product and its remote data processing solutions, including software or hardware components placed on the market separately. CRA obligations attach to that umbrella term, not to the word hardware.

Whether a device is caught at all is settled by Article 2(1). The Regulation covers products whose intended purpose or reasonably foreseeable use includes a direct or indirect, logical or physical data connection to a device or network. A device with no data connection of any kind stays outside, even though it is hardware within the meaning of the definition.

The Regulation never uses the word firmware. A device with embedded code is therefore not a hybrid of the two categories but a hardware product which, as a whole and including its code, is subject to the essential cybersecurity requirements in Annex I.

Hardware as a component

Article 3, point (6) defines a component as software or hardware intended for integration into an electronic information system. Hardware can therefore be either thing: a product in its own right, or a building block inside someone else’s product.

One concrete supply-chain duty follows. Under Article 13(6) a manufacturer who identifies a vulnerability in an integrated component reports it to the person or entity manufacturing or maintaining that component. Where the manufacturer has developed a software or hardware modification to fix it, the relevant code or documentation is passed on, in a machine-readable format where appropriate. The provision names hardware modifications expressly alongside software ones.

Where hardware products are treated differently

Physical form shows up in these four places, among others:

• Identification: under Article 13(15) the product must bear a type, batch or serial number or another identifying element. Only where that is not possible may the information move to the packaging or an accompanying document.
• CE marking: Article 30(1) requires the CE marking to be affixed visibly, legibly and indelibly to the product itself. Where the nature of the product does not permit or warrant that, it goes on the packaging and on the accompanying EU declaration of conformity. For products in the form of software it goes either on the EU declaration of conformity or on the accompanying website. Paragraph 2 allows a height below 5 mm on account of the nature of the product, provided the marking stays visible and legible.
• Technical documentation: Annex VII, point 1(c) calls for photographs or illustrations showing external features, marking and internal layout, and only for hardware products.
• Version maintenance: the relief in Article 13(10), which lets a manufacturer maintain only the version last placed on the market, is written for software products alone.

Recital 40 draws the everyday consequence. Where a hardware product such as a smartphone is not compatible with the latest version of the operating system it was originally delivered with, the manufacturer should keep providing security updates for the support period, at least for the latest compatible version of that operating system.

Long life, decided early

Article 13(8) sets a floor of five years for the support period, unless the product is expected to be in use for less. Recital 60 names motherboards and microprocessors as components typically used for longer and expects correspondingly longer periods for them. Industrial control systems are singled out as well.

For hardware, whether that duty can be met is decided during circuit design. Annex I, Part I, point 2(c) requires, on the basis of the cybersecurity risk assessment and where applicable, that vulnerabilities can be addressed through security updates. A device with no update path, no writable memory or barely sufficient flash will not satisfy that across a long support period, and once production has started nothing can be added.

Hardware in the product lists

Annexes III and IV list categories whose conformity assessment Article 32 subjects to special rules, and hardware is well represented there. Class I of Annex III names physical and virtual network interfaces, routers, modems intended for connection to the internet and switches, along with microprocessors, microcontrollers, ASICs and FPGAs with security-related functionalities. Class II covers tamper-resistant microprocessors and microcontrollers. The first entry among the critical products in Annex IV is “Hardware Devices with Security Boxes”.

That classification decides the procedure under Article 32. For products with the core functionality of an Annex IV category, the Commission may by delegated act under Article 8(1) require a European cybersecurity certificate at assurance level at least ‘substantial’. As long as no such delegated act has been adopted, Article 32(4) points to the procedures in Article 32(3), which are the Class II procedures.