SBOMReady
Blog

EN 18031 vs the CRA: your connected device is already regulated — and the no-password onboarding trap

16 July 2026 · SBOMReady · 7 min read

Most embedded teams selling into the EU have two dates in their calendar: September 11, 2026, when the Cyber Resilience Act's exploitation-reporting obligations start, and December 11, 2027, when the rest of the CRA applies in full. Both matter. But if your product contains a radio — WiFi, BLE, LoRa, cellular — and can reach the internet directly or through another device, you are not waiting for the CRA. You have been regulated since August 1, 2025, under the Radio Equipment Directive's Delegated Act (RED DA) and its harmonised standards, the EN 18031 series.

This article maps what applies to your device today, what carries over to the CRA, and one piece of fine print in the EN 18031 harmonisation that surprisingly few manufacturers know about — and that can quietly remove your right to self-assess.

Who is caught by the RED DA, exactly

The Delegated Act (Regulation (EU) 2022/30) activated three security requirements of the Radio Equipment Directive, each with its own scope:

Article 3(3)(d) — network protection. Applies to any internet-connected radio equipment: anything that can communicate over the internet, directly or via other equipment. That last clause is the one teams misread. A BLE sensor with no IP stack of its own still qualifies if it reaches the internet through your mobile app or a gateway. An isolated RF remote does not. The matching standard is EN 18031-1.

Article 3(3)(e) — personal data and privacy. Applies to internet-connected radio equipment that processes personal data, traffic data or location data — plus childcare devices, toys, and wearables. In practice, almost every connected consumer or building device processes something that qualifies. Standard: EN 18031-2.

Article 3(3)(f) — protection from fraud. Applies if the equipment lets the holder or user transfer money, monetary value or virtual currency. Standard: EN 18031-3.

If you sell radio equipment in the EU, your product already needs to conform to the applicable subset of these. This is not a 2027 problem.

The fine print: harmonised, with restrictions

In January 2025 the Commission listed EN 18031-1/-2/-3:2024 as harmonised standards under the RED (Implementing Decision (EU) 2025/138). Harmonised status is what gives you presumption of conformity — the thing that lets you self-assess instead of paying a Notified Body.

Here is what the compliance-tool marketing tends to skip: the listing came with restrictions. Complying with the standard does not give presumption of conformity for every clause. Three restrictions stand out:

  1. Passwords. For EN 18031-1 and 18031-2, if your equipment allows the user not to set or use a password, the password-related clauses (6.2.5.1 and 6.2.5.2) do not grant presumption of conformity. Think about what that means for the standard IoT onboarding flow: press a button, join the hotspot, no password anywhere. That pattern — the default UX of half the consumer IoT on the market — can mean self-assessment is off the table for those requirements, and a Notified Body has to get involved.

  2. Parental and guardian controls. For EN 18031-2, if the device is a toy or childcare-related and does not guarantee appropriate parental control mechanisms (clauses 6.1.3–6.1.6), no presumption.

  3. Payments. For EN 18031-3, one clause (6.3.2.4) simply does not grant presumption of conformity at all — if your device moves money, part of the assessment goes through an independent body regardless.

None of this makes compliance impossible. It changes who signs off and what it costs. If your onboarding relies on "no password needed", you have three options: change the UX, involve a Notified Body for those clauses, or argue an alternative mechanism meets the essential requirement — with documentation to back it. What you cannot do is tick "EN 18031: compliant" in a spreadsheet and move on.

(Standard caveat: this is an engineering summary, not legal advice. The restrictions live in the annex of Implementing Decision (EU) 2025/138 — read them against your actual product, and when in doubt, ask your test lab or Notified Body.)

What carries over to the CRA — and what doesn't

The usual estimate is that RED DA work covers a large share — commonly cited around 70% — of what the CRA will ask of the same product. The overlap is real: secure-by-default configuration, protection of network interfaces, secure update mechanisms, protection of stored and transmitted data. If you do EN 18031 properly in 2026, most of that engineering survives contact with the CRA in 2027, when the CRA replaces the RED DA for these products.

What the CRA adds on top is mostly process and evidence, not device features:

  • A Software Bill of Materials. The CRA requires you to identify and document the components in your product, including an SBOM in a machine-readable format covering at least the top-level dependencies (Annex I, Part II). The RED DA never asked for this.
  • Vulnerability handling as an ongoing obligation. Coordinated vulnerability disclosure policy, a contact point for reports, remediation "without delay", free security updates — for the whole support period.
  • The reporting clocks. From September 11, 2026: an actively exploited vulnerability in your product means an early warning to your coordinating CSIRT and ENISA within 24 hours, a fuller notification within 72 hours, and a final report after the fix — through ENISA's single reporting platform.
  • The technical file. Annex VII documentation — architecture, risk assessment, vulnerability handling process, SBOM, support period — kept for at least 10 years or the support period, whichever is longer.

So the honest framing is: EN 18031 is the device-hardening baseline you owe today; the CRA wraps it in a lifecycle operation you owe from 2026–2027. Teams that treat the RED DA as a one-off certification exercise will do the work twice. Teams that build the process once — inventory, monitoring, update evidence, documentation — get both regulations from the same machinery.

Where your SBOM fits (and why you probably already have one)

Here is the part of this that costs less than most teams assume. If you build on a mainstream embedded platform, your toolchain already generates the SBOM the CRA asks for:

  • ESP-IDF ships esp-idf-sbom, a first-party tool that emits SPDX from your actual project build.
  • Zephyr has west spdx.
  • Yocto has create-spdx built into the build system.
  • For companion apps and cloud containers, syft and trivy cover most stacks.

The SBOM itself is close to free. The compliance value is in what you do with it: checking it actually meets the minimum data requirements (supplier, version, unique identifiers — many generated SBOMs don't), matching it against known vulnerabilities and exploitation data on every release, and being able to answer, on the day a CVE drops in your RTOS or TLS stack, which of your products and versions are affected — because that answer is what the 24-hour clock will demand from you.

That loop — SBOM per release, continuous matching, documented triage, update evidence — is the operational core of both EN 18031's update requirements and the CRA's vulnerability handling. It is also exactly the thing a spreadsheet does not do at 2am.

The five-minute version

If your radio product touches the internet and sells in the EU: EN 18031 applies to you now, the CRA's reporting obligations start September 11, 2026, and full CRA compliance is due December 11, 2027 for products placed on the market from that date. Check which parts of EN 18031 apply (network / personal data / payments). Check whether your onboarding flow trips the password restriction — before a market surveillance authority or a competitor's lawyer does. Generate the SBOM from your toolchain, and start the vulnerability-handling loop early, because it is the part that carries over completely.

Want to see where you stand in two minutes? Upload the SBOM your toolchain already generates (or paste it, or try the built-in ESP32 sample — we never store your SBOM) and get your open CVEs, exploitation flags, and a CRA / EN 18031 readiness checklist: run the free check.

This article is an engineering-oriented overview, not legal advice. Primary sources: Regulation (EU) 2024/2847 (CRA), Delegated Regulation (EU) 2022/30 (RED DA), Commission Implementing Decision (EU) 2025/138 (EN 18031 harmonisation).