CRA vs. RED / EN 18031: Which Applies to My Device, and When?

The Radio Equipment Directive (RED) with the harmonised standard EN 18031, and the EU Cyber Resilience Act (CRA), are two separate pieces of EU law. They are not the same regime and one does not contain the other. RED is narrow - it applies to radio equipment. The CRA is broad - it applies to almost any product with digital elements. Many connected products fall under both, but for different reasons and on different timelines.

The cleanest way to think about it: RED/EN 18031 is a small, specific circle inside the much larger CRA circle. Almost every radio device is also a product with digital elements, so it sits inside the CRA's scope too. But the reverse is not true - the vast majority of CRA-covered products are not radio equipment at all.

RED applies only to radio equipment: products that intentionally emit or receive radio waves for communication or radiodetermination (Wi-Fi, Bluetooth, cellular, Zigbee, and so on). Its cybersecurity essential requirements - Articles 3.3(d) (network protection), 3.3(e) (privacy and personal data), and 3.3(f) (fraud prevention) - are met in practice by applying EN 18031, the harmonised standard that grants a presumption of conformity.

The CRA applies to any product with digital elements made available on the EU market whose intended or reasonably foreseeable use includes a direct or indirect, logical or physical data connection to a device or network. That definition is deliberately wide: it covers hardware and standalone software, including remote data-processing solutions the manufacturer is responsible for. The CRA's hard carve-outs are sector-based - products already governed by the Medical Devices Regulation, the In-Vitro Diagnostic Medical Devices Regulation, the motor-vehicle type-approval regulation, marine-equipment law, or civil-aviation certification, plus anything developed exclusively for national security, defence, or classified use.

Crucially, radio equipment is not carved out of the CRA. The CRA's sector exclusions do not list radio equipment, so a wireless connected product is in scope of both laws. The two regimes simply regulate different things about it - which is why they coexist rather than cancel each other out. For the conceptual deep-dive on how the two relate, see our companion article EN 18031 vs. the EU Cyber Resilience Act.

Work through these questions about your specific product. They resolve, in almost every case, to one of four outcomes: RED only, CRA only, Both, or Neither.

Does the product intentionally transmit or receive radio waves for communication or radiodetermination (Wi-Fi, Bluetooth, cellular, LoRa, Zigbee, NFC, GNSS, etc.)? If yes, RED applies and EN 18031 is your practical route to proving its cybersecurity essential requirements. If no, RED does not apply - skip to Question 3.

Is the product governed by a sector regime the CRA defers to - a medical device, an in-vitro diagnostic device, a type-approved motor vehicle, marine equipment, a civil-aviation-certified product - or developed exclusively for national security, defence, or classified use? If yes, the CRA does not apply (the sector regime carries the cybersecurity rules instead). If no, continue.

Is it a product with digital elements - hardware or software - whose intended or foreseeable use includes a direct or indirect data connection to a device or network? If yes, the CRA applies. If no (a truly stand-alone product with no code and no logical or physical data connection), the CRA does not apply.

The decision guide is easiest to trust when you see it applied to concrete products. Here are five common profiles and the verdict each one reaches.

The pattern these examples reveal is the directionality rule: a product that triggers RED almost always triggers the CRA as well, because radio equipment is a connected product with digital elements. The exceptions are narrow - either the product is sector-excluded from the CRA (like the medical example), or, very rarely, it is radio equipment with no data connection or digital elements at all. The reverse direction is wide open: software, wired devices, and non-radio hardware are squarely CRA-only and never touch RED.

To classify the radio side correctly, our RED cybersecurity overview and the essential cybersecurity standards for IoT explain which EN 18031 parts apply to which device functions.

"Which applies" is only half the question. The other half is "by when." RED/EN 18031 is already mandatory; the CRA's obligations switch on in stages, with reporting duties arriving well before the main requirements.

Two timing details catch manufacturers out. First, the CRA's reporting duties (11 September 2026) land more than a year before the main requirements (11 December 2027) - so you need an incident- and vulnerability-reporting process well before the rest of the regime is fully live. Second, the reporting obligations reach even products already on the market before the main date, so legacy connected products are not automatically off the hook.

The practical takeaway: if your product is radio equipment, EN 18031 is a today problem; the CRA is a 2026-then-2027 problem you should already be planning for. For a broader readiness plan across RED, CRA and NIS2, see how to prepare for new EU cybersecurity regulations.

No - and this is where the two laws are designed to interlock administratively even though they are separate. When a product falls under more than one piece of EU legislation, the CRA lets you consolidate the paperwork rather than duplicate it.

What you cannot do is assume that *EN 18031 conformity equals CRA conformity. The CRA grants a presumption of conformity only through harmonised standards published in its Official Journal, common specifications, or a European cybersecurity certification scheme - not* through RED or EN 18031. The cybersecurity ground does overlap: the CRA's essential requirements are designed to encompass the elements of RED Articles 3.3(d)/(e)/(f). But the CRA also adds whole categories of obligation that EN 18031 never imposed - lifecycle security, a support period with free updates, an SBOM and coordinated vulnerability handling, and ENISA/CSIRT reporting - and those must be implemented and documented separately.

It is also worth being precise about the future: EU policy signals that the RED cybersecurity delegated regulation (EU) 2022/30 will eventually be repealed or amended so it stops applying to products the CRA covers, with a transitional period in which both apply. That has not happened yet, and the CRA does not repeal it on its own - so for now, treat RED/EN 18031 and the CRA as two live, parallel tracks.

One of the biggest sources of confusion is assuming the CRA runs on EN 18031. It does not. The two regimes are proven against different technical material.

The practical consequence: doing excellent EN 18031 work gives you a strong cybersecurity baseline and a lot of reusable evidence, but it does not, by itself, discharge your CRA obligations. Plan the two tracks together, but keep them distinct.

No. The CRA grants a presumption of conformity only via CRA harmonised standards, common specifications, or a European cybersecurity certification scheme - not via RED or EN 18031. EN 18031 gives you a strong cybersecurity baseline that overlaps with the CRA's essential requirements, but CRA-specific duties (lifecycle security, support period with free updates, SBOM, coordinated vulnerability handling, and ENISA/CSIRT reporting) are not part of EN 18031 and must be met separately.

Not today. They are separate laws that currently apply in parallel. EU policy indicates that the RED cybersecurity delegated regulation (EU) 2022/30 will eventually be repealed or amended so it stops applying to CRA-covered products, with a transitional period during which both apply - but that step has not been taken yet, and the CRA does not repeal RED itself. RED (2014/53/EU) remains in force for radio equipment generally.

The CRA can apply; RED cannot. RED only governs radio equipment, so software alone is outside it. The CRA covers software products with digital elements that have a direct or indirect data connection, unless the software is part of a sector-excluded product (for example, software that is a medical device under the Medical Devices Regulation) or is standalone cloud service software governed instead by NIS2.

Both regimes scale assurance to risk, drawing their modules from the same EU framework. Under RED/EN 18031, you can self-declare via Module A when you apply the standard fully and trigger no restrictions; a notified body (Module B+C) is needed otherwise. Under the CRA, default products can self-assess against Annex I, while products classed as important (Annex III) or critical (Annex IV) face more rigorous procedures, up to third-party assessment - and certain critical products may require a European cybersecurity certificate. The structure rhymes, but the CRA adds an explicit, list-based product-criticality gate that RED does not have.

Yes. When a product is subject to more than one Union act, a single EU Declaration of Conformity is drawn up covering all of them (CRA Article 28(3)), a single CE marking indicates conformity with all applicable Union legislation (CRA Article 30(5)), and a single technical documentation set can hold what each act requires (CRA Article 31(3)). You consolidate the paperwork; you do not duplicate the underlying work.

RED/EN 18031 and the CRA are two distinct laws with different scope and different timelines - but for most connected wireless products they arrive together. The smart move is not to pick one, but to plan a single coordinated compliance programme that satisfies both.

Decide per device using the three questions above, mark the deadline that bites first, and build one evidence base you can extend - rather than running two disconnected compliance projects.

RedComply is purpose-built for EN 18031 and the RED cybersecurity regime. Today it automates the full EN 18031 workflow end to end; dedicated Cyber Resilience Act support is on our roadmap and coming soon. The structured evidence you build now for RED is exactly the foundation the CRA's lifecycle obligations will draw on.

On the CRA side, dedicated automation is coming soon. The structured documentation, asset inventories, and evidence trails you build today for EN 18031 are the same foundation we are extending toward CRA deliverables - vulnerability handling policies, SBOM references, support-period statements, and incident-reporting workflows - as that functionality ships.

Work out which laws apply to your device, then build one evidence base for both. Visit redcomply.com to automate your EN 18031 compliance today and get ahead of the CRA timeline for 2026 and 2027.