2026-10-02

Cyber Resilience Act and the RED directive: what a connected-device manufacturer must plan for

Since 11 September 2026, reporting of exploited vulnerabilities is mandatory; cybersecurity for radio equipment has been since August 2025; the full CRA arrives in December 2027. How these calendars fit together.

For a manufacturer of connected devices sold in the Union, two European texts currently overlap: the Radio Equipment Directive (RED) and the Cyber Resilience Act (CRA). Their calendars differ, and mixing them up is the surest way to be caught off guard.

RED: already mandatory for radio equipment

Delegated Regulation (EU) 2022/30 introduced cybersecurity requirements into the RED: network protection, personal data protection, fraud prevention. They have applied since 1 August 2025, with the EN 18031 series of harmonized standards published in the Official Journal in January 2025 (Zühlke, RedComply). They concern any product with a radio link — Wi-Fi, Bluetooth, Zigbee, LoRa, cellular.

CRA: a two-step calendar

  • 11 September 2026: manufacturers must report actively exploited vulnerabilities and severe incidents — early warning within 24 hours, notification within 72 hours, final report afterwards — through a single platform run by ENISA (European Commission).
  • 11 December 2027: all essential requirements apply — secure design, vulnerability handling, technical documentation, security updates over the product's lifetime. At that point, according to legal analyses, the CRA becomes the main cybersecurity framework for these products, and the RED's cybersecurity provisions are expected to fade out to avoid duplication.

The CRA's scope is broader than the RED's: it covers all products with digital elements, with or without radio. A manufacturer of wireless products will therefore, in practice, need to answer to both.

What it means in practice

  • An operational vulnerability-handling process now: a reporting address, an on-call person, a way to qualify a vulnerability as "actively exploited" and notify it within 24 hours. 11 September has passed: the process must exist, not be in planning.
  • A component inventory (software bill of materials): knowing which library, in which version, runs in which product — including open source components, for which the manufacturer answers.
  • Signed updates: secure OTA is no longer a convenience but a compliance condition over the whole declared lifetime.
  • A declared and honored support period: the manufacturer must provide security fixes for the support period it states.
  • Up-to-date technical documentation: risk assessment, design choices, test results (see the article on embedded AI for the model and data dimension).

A design that makes everything easier

What is expensive is adding these functions after the fact to a product designed without them. Secure boot, protected key storage, unique per-device credentials (never a shared default password), encrypted communications and a signed update channel are planned at the circuit-board stage. Our Quality & standards page presents the normative reference we take as our design framework.

This article is general information, not legal advice: qualifying a product and choosing the conformity assessment procedure depend on each case.

Sources

Have an IoT project in mind?

Describe your context, we'll propose a tailored solution.