EU Cyber Regulation and IoT Part 2 - RED Already Happened

As a hardware and IoT hacker, I love the FCC, mostly because they let me get internal pictures of devices for free without buying them. The reason for this is the FCC regulates anything that transmits a wireless signal, so a device with a radio in it that's sold in the US has to be certified and carry an FCC ID.

In the EU there is a similar set of regulations called the Radio Equipment Directive (RED). Why does this matter for cybersecurity? In 2022 the EU bolted three cybersecurity requirements onto it, and since August 1 2025 those requirements have been mandatory for a lot of IoT devices that are sold in the EU.

Same disclaimers as the last blog. I'm an engineer and a hacker, not a lawyer (IANAL as they say on reddit), so none of this is legal advice, and I work at a device manufacturer doing internal product security these days, so I'm reading this from both sides.

In this blog I'm going to cover what RED cybersecurity actually applies to, what the EN 18031 standards ask a device to do, and then the restriction problem, which is the part that decides whether you get to sign your own paperwork or whether you're paying a Notified Body (NB) to sign it for you.

The RED has an Article 3(3) with a list of extra essential requirements that sit dormant until the Commission switches one on. In January 2022 Delegated Regulation (EU) 2022/30 switched on three of them, points (d), (e) and (f), with an original apply-from date of August 2024 that got pushed back a year to give everyone time to catch up. This is a common theme here with RED and CRA, the regulators have been giving extensions to allow manufacturers to catch up, but don't expect that to keep happening.

Here's what each one covers, roughly:
3(3)(d), network protection. Radio equipment that can communicate over the internet, whether it does that directly or through some other piece of equipment. That is a very wide net, and in practice pretty much every consumer IoT device I've ever looked at lands in it.
3(3)(e), personal data and privacy. Radio equipment that processes personal data, traffic data or location data, plus toys, childcare equipment and wearables regardless of what data they handle.
3(3)(f), protection against fraud. Radio equipment that processes virtual money or monetary value.

The word doing the limiting there is "radio". If your device has no radio in it at all then RED doesn't touch it (it will still get caught by the Cyber Resilience Act in December 2027, so enjoy the break while it lasts). There are also carve-outs for things covered by their own sector rules, so medical devices, civil aviation equipment and type-approved motor vehicles are out of scope here.

Most devices hit (d). Plenty of them hit (d) and (e) together, because the moment there's an account, an app or a camera in the picture you're processing personal data. Not many hit (f), but if yours does, keep reading, because there's a surprise waiting for you further down.

You don't get told to be secure and left to figure it out. CEN and CENELEC wrote a harmonized standard for each objective, and on January 28 2025 the Commission cited all three in the Official Journal of the European Union (OJEU) through Implementing Decision (EU) 2025/138:

EN 18031-1:2024, internet connected radio equipment, supports 3(3)(d)

EN 18031-2:2024, radio equipment processing data, including childcare, toys and wearables, supports 3(3)(e)

EN 18031-3:2024, radio equipment processing virtual money or monetary value, supports 3(3)(f)

Citing a standard in the OJEU is what gives it teeth. If you build to a cited harmonized standard you get what's called presumption of conformity, meaning a regulator takes your compliance as read unless they have a reason not to, and you can self-declare through internal production control rather than involving anyone else. That's the cheap, fast route, basically you follow their guidance and they trust you did. This is the easiest way to conformity and is the one most manufacturers want.

If you've never opened one of these, EN 18031 is not what you'd expect from a security document. It doesn't say "no command injection in the web interface" or "don't hardcode the root password". It's built around mechanisms, each with a three letter name, and you assess whether your device implements each one properly or justify why that mechanism doesn't apply to you.

The mechanisms include things like Access Control Mechanism (ACM), Authentication Mechanism (AUM), Secure Update Mechanism (SUM), Secure Storage Mechanism (SSM), Secure Communication Mechanism (SCM), Confidential Cryptographic Keys (CCK) and General Equipment Capabilities (GEC), and you get there by first listing your device's assets and security assets and then walking a set of decision trees that tell you which requirements are in scope.

One way I like to think of it is that it's much closer to a threat model than to a pentest report. The standard is asking whether the safety rails exist and whether they're on by default, not whether someone can find a bug in them. Those are genuinely different questions and I think it's important to be clear about which one is being answered, because a device can be fully conformant with EN 18031 and still fall over in about ten minutes on a bench (this is not a knock on the standard, it's just what a baseline is).

The flip side, and this is the part I actually like, is that a lot of the sloppy defaults I've spent years finding in consumer gear are now things a manufacturer has to positively account for on paper. Shared credentials across a whole product line, unsigned updates, a debug interface left wide open, all of that has to survive a decision tree now instead of nobody asking.

All three standards were cited with restrictions and there are four of them spread across the three parts. Each one is a carve-out where the standard gives you nothing, and if a carve-out applies to your product then that part of the standard no longer covers you.

Notice 1, on all three standards. The sections named "rationale" and "guidance" don't confer presumption of conformity. Those are the sections that explain why a requirement exists and give examples of how you might implement it, which is to say the readable parts. They're there to help you, they are not the specification, and you can't point at them as evidence you complied.

Notice 2, also on all three standards. Clauses 6.2.5.1 and 6.2.5.2 deal with default passwords, and as written they offer a manufacturer the option of allowing a user not to set or use a password at all. The Commission's view, in its own words, is that the standard:

does not confer a presumption of conformity with the essential requirement set out in Article 3(3), first subparagraph, point (d), of Directive 2014/53/EU if, when applying its clauses 6.2.5.1 and 6.2.5.2, the user is allowed not to set and use any password.

The above legalese is very important so let's break it down in plain terms. If your setup flow has a "skip for now" button, or a "remind me later", or any path at all that leaves the device sitting on the network with no password on it, you have lost presumption of conformity. Not partial credit, not a finding to remediate later, you're just out of presumed conformity.

Notice 3, on EN 18031-2 only. For the toy and childcare categories covered by clauses 6.1.3 through 6.1.6, if parental or guardian access control isn't ensured, no presumption of conformity. The reasoning is that the standard lets you pick from several access control models and some of them just aren't compatible with a parent being in charge of what a kid's device does.

Notice 3, on EN 18031-3 only. (Yes, another Notice 3, the numbering restarts for each standard.) This one is different from the others and it's the surprise I promised. The assessment criteria in clause 6.3.2.4, which cover secure updates, don't confer presumption of conformity at all. There's no "if" on the end of that sentence. The Commission's position is that the four implementation options in that clause (digital signatures, secure communication, access control, or others) are each fine on their own for a normal device but none of them alone is enough when the thing being protected is money. So as I read it, and the Notified Body guidance I've seen on this reads it the same way, if you're in scope of 3(3)(f) then you are going to a Notified Body no matter how good your device is.

If the harmonized standard fully covers you, you self-declare. You do your testing, you write the technical file, you sign the Declaration of Conformity (DoC), you affix the CE mark, you ship. Nobody external has to agree with you.

If a restriction applies, that route closes. You go through EU-type examination with a Notified Body instead, which means submitting your technical documentation and your risk assessment, showing what you did in place of the restricted clause, likely doing extra testing, and then waiting for a certificate before you can issue the DoC and CE mark at all.

The certificate is the part that hurts. It isn't only the fee, it's that an external body is now in your critical path to market, there are a limited number of them, and every manufacturer selling into the EU discovered this at roughly the same time. If your ship date assumed a self-declaration and you find out during testing that the skip-password button puts you in the NB queue, now you're waiting on that.

RED cybersecurity is not the future, it's a year old and enforceable today, and I think a lot of people still haven't clocked that it applies to them. The three standards give you a real baseline, the restrictions are narrow but they're placed exactly where consumer devices tend to be weakest, and the difference between clearing them and not clearing them is the difference between signing your own paperwork and waiting in someone else's queue.

Next up I'll get into the CRA side and September 11 2026, which is the reporting deadline, the 24 hour early warning, the 72 hour notification, and what you actually need in place before then to have any chance of hitting those windows.
If you missed the first blog in the series, it's here.

Until next time...
Happy Hacking - DigitalAndrew