Cybersecurity for IoT Device Makers: RED EN 18031, CRA and Device Tests

Which rules apply to you

Connected devices with a radio are regulated today, not in 2027.

RED delegated act (EU) 2022/30 has applied since 1 August 2025. It activates Article 3(3)(d), (e) and (f) of the Radio Equipment Directive for internet-connected radio equipment, radio equipment that processes personal data and radio equipment that handles money. The harmonised standards are EN 18031-1 (network), EN 18031-2 (privacy) and EN 18031-3 (financial). The standards are listed with restrictions: where a product relies on a restricted clause, for example letting the user operate without a password, self-assessment is not available and a notified body must be involved.

Cyber Resilience Act (EU) 2024/2847. Reporting of actively exploited vulnerabilities and severe incidents under Article 14 applies from 11 September 2026. From 11 December 2027 every product with digital elements needs the Annex I essential requirements, the vulnerability handling process (software bill of materials, coordinated disclosure, free security updates during a support period of at least five years under Article 13(8)), technical documentation and CE marking. Annex III makes smart home security products, connected toys and health or children’s wearables important products with stricter conformity assessment.

UK PSTI Act 2022 and its regulations have applied since 29 April 2024 to consumer connectable products sold in the UK: no universal default passwords, a published vulnerability disclosure policy and a stated minimum security update period.

ETSI EN 303 645 is the consumer IoT baseline that EN 18031 and the CRA grew from and that retail buyers still reference.

NIS2 via the German BSIG reaches manufacturers of electronic products with 50 or more employees as important entities, and your enterprise customers forward their supply chain duties to you.

Where attackers start

Every connected device has the same seven doors.

• Debug interfaces: UART, JTAG and SWD left active, giving a console or full memory access.
• Flash and boot chain: unencrypted external flash, secure boot not enabled, eFuses never programmed, so firmware and keys can be read and modified.
• Wireless: BLE pairing without authentication and writable control characteristics, Wi-Fi provisioning over an open access point, proprietary 2.4 GHz links with replayable frames.
• Device-to-cloud: MQTT brokers with one shared credential or no access control lists, TLS without certificate validation, device identities that are not unique.
• Cloud API and companion app: object-level authorisation, token handling, secrets embedded in the app.
• Updates: images checked for version but not for signature, or signed with a key present in the firmware.
• Local interfaces: web servers, telnet and manufacturing test modes still reachable in production units.

What assessments typically find

Typical findings from IoT penetration tests of ESP32-based communication modules, MQTT brokers, cloud APIs and apps, with BLE, Wi-Fi and proprietary radio analysis, anonymised: flash encryption and secure boot available on the chip but never enabled, so the firmware with Wi-Fi and broker credentials was read in minutes; an MQTT broker that let any authenticated device subscribe to the wildcard topic and read or control every other customer’s devices; one device certificate for the entire production run; a BLE control characteristic writable after “Just Works” pairing from any phone in range; a proprietary 2.4 GHz protocol whose commands could be captured and replayed; an over-the-air update that validated a version string and nothing else; and a companion-app API returning other users’ devices when the identifier was changed.

Each item maps to a specific requirement in EN 18031-1 (access control, secure update, secure storage, secure communication) and to Annex I of the CRA. Found before certification, they cost a sprint; found by a researcher after launch, they cost a recall and, from September 2026, a report to the authorities.

A sensible first project

Start with the product that ships in the largest numbers or the one going through RED assessment next.

1. Scoping and classification: which RED outcomes apply, whether the product is an Annex III important product, which support period you will declare, what the companion app and cloud do. One day.
2. Device penetration test in our lab: hardware and debug ports, firmware extraction and analysis, boot chain, wireless interfaces, device-to-cloud protocol, companion app and cloud API against a test tenant. Two to three weeks.
3. Gap analysis against EN 18031-1 and, where relevant, -2, and against CRA Annex I, delivered as a prioritised fix list and as evidence for your technical documentation.
4. Hardening and retest: secure boot and flash encryption, programmed eFuses, per-device keys, signed updates, broker access control lists, API authorisation; then reuse the platform decisions across your product line.

Typical effort for steps 1 to 3 is 15 to 25 person-days, which is 18,000 to 40,000 euros at market rates. The hardening is mostly your engineers’ time; we review it.

What Zyberum does and does not do here

We test devices end to end, from the PCB to the cloud API, do the EN 18031 and CRA gap analyses, set up vulnerability handling and the 24-hour reporting process, and help your engineers with secure boot, eFuses, SELinux and nftables on Linux devices and secure firmware on microcontrollers. We train embedded teams in secure coding. We are not a notified body and do not issue RED or CRA certificates or CE marks; we make sure you pass when the assessment comes.