Guide
CRA compliance for firmware and connected devices
Hardware with software inside is the Act’s original target: the device, its firmware and the cloud features it depends on are assessed together, and the CE marking goes on the product.
Updated . Based on the Permenta regulatory catalogues, version 1.0.0, sources retrieved 23 September 2026.
Does the Act apply to a device?
A connected device is a hardware product with digital elements (Art. 3(1), (5)) and its firmware is software (Art. 3(4)). Sold together they are one product; a firmware image or module supplied separately is a product in its own right (Art. 3(1); FAQ 1.3). Cloud features the device cannot work without are remote data processing and part of the product (Art. 3(2); Recital 12).
Any direct or indirect, logical or physical connection counts: Wi-Fi, Bluetooth, USB, a fieldbus or a serial port (Art. 2(1); Art. 3(8)–(10); FAQ 1.3). Only a device with no capability to connect to anything is outside, and even then its firmware may be in scope when supplied separately (FAQ 1.3). Selling in the EU is commercial whatever the price (Art. 3(22)); own-use manufacturing is not placing on the market (FAQ 1.5).
Sector exclusions matter for hardware: medical devices, vehicles, certified aviation products and marine equipment are excluded (Art. 2(2)–(4)), as are identical spare parts (Art. 2(6)) and products developed exclusively for national security or defence (Art. 2(7)).
Many device categories are important or critical: routers, modems and managed switches, smart home security products, smart speakers, interactive connected toys, health-monitoring wearables, network interfaces, boot managers and security microcontrollers are class I (Annex III); tamper-resistant microcontrollers are class II; hardware security modules, payment terminals, smart meter gateways and secure elements are critical (Annex IV). Implementing Regulation (EU) 2025/2392 decides the match by core functionality alone (FAQ 3.2). Class I products self-assess only with harmonised standards or a certification scheme applied in full (Art. 32(2)); class II and critical products need a notified body or certification (Art. 32(3)–(4)).
What happens when
Reporting is already live. Since 11 September 2026, every manufacturer of an in-scope product, including products already on the market, must notify actively exploited vulnerabilities and severe incidents through ENISA’s Single Reporting Platform (Art. 14; Art. 69(3); Art. 71(2)): early warning within 24 hours of becoming aware, notification within 72 hours, final report within 14 days of a corrective measure or one month for an incident (Art. 14(2), (4)), all to the CSIRT coordinator of your main establishment (Art. 14(7)); impacted users must be informed (Art. 14(8)).
From 11 December 2027 the rest of the Regulation applies to products placed on the market from then: Annex I essential requirements, Annex VII technical documentation, Annex V declaration of conformity, CE marking and Annex II user information (Art. 71(2)). Earlier products stay under Article 14 alone unless substantially modified (Art. 69(2)–(3); Art. 3(30)); placing on the market is counted per unit and per version (FAQ 7.2).
Notified bodies have been designated since 11 June 2026 (Art. 71(2)). No harmonised standard has been cited in the Official Journal yet, so there is no presumption of conformity to rely on (Art. 27).
Five things to do first
1. Inventory products, firmware lines and cloud dependencies
Register every model and separately supplied firmware image, record the scope reasoning, and determine the class against the Implementing Regulation descriptions; class II or critical means a notified body and its lead time.
2. Engineer the essential requirements into the device
Secure by default with a factory reset (Annex I, Part I, point (2)(b)); security updates, automatic where applicable (point (2)(c)); access control (point (2)(d)); confidentiality and integrity of data (points (2)(e)–(f)); limited attack surfaces (point (2)(j)); availability after an incident and no burden on other networks (points (2)(h)–(i)); security logging with an opt-out (point (2)(l)); permanent, secure data removal (point (2)(m)).
3. Build a secure update channel and set the support period
Distribute updates securely (Annex I, Part II, point (7)), ship security updates free with an advisory (point (8)) and keep each available for ten years (Art. 13(9)). Set a support period of at least five years reflecting the expected time in use (Art. 13(8)), show its end date at purchase on the product, packaging or digitally, and, where feasible, have the device announce end of support (Art. 13(19)).
4. Keep an SBOM per firmware release and do supplier due diligence
Produce a machine-readable SBOM covering at least the top-level components (Annex I, Part II, point (1)), including the firmware of bought-in chips and modules; exercise due diligence on third-party components (Art. 13(5)); report component vulnerabilities upstream (Art. 13(6)); and be ready to provide the SBOM to an authority on request (Art. 13(25)).
5. Contact, disclosure policy, technical file and CE marking
Provide a vulnerability reporting address and a disclosure policy (Art. 13(17); Annex I, Part II, points (5) and (6)) and rehearse the Article 14 routine. Build the Annex VII technical file with the risk assessment (Art. 13(2)–(3); Art. 31), ship the declaration of conformity or the Annex VI simplified declaration pointing to it (Art. 13(20)), affix the CE marking visibly, legibly and indelibly (Art. 30), and supply product identification, manufacturer contact details and Annex II user information with the product (Art. 13(15)–(16), (18)).
How Permenta helps
Permenta holds every model and firmware line in the registry with its scope result and class, keeps an SBOM per release matched against vulnerability feeds daily, and runs the Article 14 desk against the Single Reporting Platform field list. The Annex VII workspace tracks evidence coverage per section, the trust page publishes the support period and advisories, and the ledger keeps the record for ten years.
Sources and a note
Every statement above names the provision it rests on. The texts are Regulation (EU) 2024/2847, Implementing Regulation (EU) 2025/2392 and the Commission FAQ, version 1.4.
- Art. 2(1), (2), (3), (4), (6), (7)
- Art. 3(1), (2), (4), (5), (8), (9), (10), (22), (30)
- Art. 13(2), (3), (5), (6), (8), (9), (15), (16), (17), (18), (19), (20), (25)
- Art. 14
- Art. 27
- Art. 30
- Art. 31
- Art. 32
- Art. 69(2), (3)
- Art. 71(2)
- Annex I, Parts I and II
- Annex II
- Annex III
- Annex IV
- Annex VI
- Annex VII
- Implementing Regulation (EU) 2025/2392
- Commission FAQ v1.4: 1.3, 1.5, 3.2, 7.2
- Recital 12
Not legal advice
This guide explains the Regulation as Permenta reads it and is not legal advice. Whether your product is in scope, which class it is in and what it must do is your assessment, or your adviser’s. Permenta provides tooling and record-keeping; it does not certify compliance.