RED Cybersecurity Requirements: How to Ensure Compliance for Connected Devices

TD;LR
Since 1 August 2025, internet-connected radio equipment, plus childcare products, toys and wearables that handle personal data, must meet RED Articles 3(3)(d), (e) and (f), assessed against EN 18031-1, -2 and -3. Products applying the standards in full with no restriction can self-declare (Module A); others need a notified body. Rules are repealed on 11 December 2027.

Imagine a smart lock, a baby monitor, or a wearable is about to ship to the EU, and sales wants to know if it’s “RED compliant yet”. Honestly, most teams can’t answer that straight away. RED, the Radio Equipment Directive, began enforcing its cybersecurity articles on 1 August 2025, and the RED cybersecurity requirements still catch product teams off guard.

This one’s practical. We’ll cover what the articles want, how to check a product against them, what testing involves, and which certification route you’ll probably land on. The UK wrinkles and the December 2027 switch get a mention too.

What the Radio Equipment Directive (RED) Cybersecurity Requirements Means for You

Three articles do the heavy lifting, and they split the job by risk for RED cybersecurity requirements. 3(3)(d) is about not harming the network. 3(3)(e) is about personal data and privacy, and 3(3)(f) is about fraud. The Commission activated them through Delegated Regulation (EU) 2022/30, which has been in scope since 1 August 2025.

The articles read like goals. Nobody says “turn on secure boot”. So the real detail lives in EN 18031-1, -2 and -3, which break each goal into named mechanisms you can test. BSI’s RED Directive guide lists them, and we have put them in plain English below.

Which ones apply to your device depends on your risk assessment and on which part of the standard you’re using. BSI’s overview suggests the exact mapping varies by part, so check the standard itself.

Is Your Product Even in Scope?

Ask three questions. Can it reach the internet, directly or through another device? Does it process personal, traffic, or location data? Does it let users move money or virtual currency?

A yes to any of them puts you in. If you’re unsure, assume you’re in and prove otherwise. Childcare equipment, toys and wearables get pulled in on the data article even without an internet link. So do hub-connected sensors, which catch teams out every time.

A RED Compliance Checklist You Can Hand to Engineering

BSI’s readiness guide groups the work into six stages and a 22-item checklist. I’d keep those six, since audits follow roughly the same order.

• First, list every SKU and hardware revision, with the radios and cloud services each one talks to.
• Then do the risk assessment: what are the assets (credentials, personal data, the update channel) and what could go wrong with each?
• Work out which of 3(3)(d), (e) and (f) apply, and which EN 18031 parts follow from that.
• Fix the gaps. Default credentials, unsigned updates, open debug ports, and clear-text traffic go first.
• Test the build you’ll actually ship, mechanism by mechanism.
• Last, update the technical file, sign the declaration of conformity, and only then put the CE marking on.

Somebody has to own each stage of the RED compliance checklist. Product management usually takes the product list, engineering takes the fixes, and compliance takes the file. Every “No” is a ticket. And if one’s still open at release, a senior person should be the one who decides to ship anyway.

Role of EN 18031-1, EN 18031-2 and EN 18031-3 in RED Compliance

These standards help manufacturers meet the relevant RED cybersecurity requirements and improve the security of connected radio devices.

Where Connected Devices Usually Fail

Read the restrictions in the standards and think about how connected devices usually get built, and the same weak spots keep turning up.

• A setup flow that lets the user skip creating a password, or falls back to a shared default
• Firmware updates that arrive unsigned, or that can roll back to an older, vulnerable version.
• Debug ports and test accounts that survived into production
• Secrets hard-coded in firmware, so one dumped image exposes every unit
• Local traffic between the device and its app sent in the clear
• No way to delete a user’s data when they sell the device or close their account
• Companion apps and cloud APIs that check the user once and then trust everything

None of these is exotic. Most come from schedule pressure, not ignorance. Somebody turned debugging on for a bring-up, and nobody turned it off.

I’d go further and walk through it with the person who wrote the firmware, not just the person who owns the spec. They usually know exactly which shortcut went in, and they’ll tell you if you ask nicely. So run this list against your own device before any lab does. It takes an afternoon, and it’s the cheapest testing you’ll ever do.

What Does RED Compliance Testing Look Like?

Expect two layers in RED compliance testing. First comes functional compliance testing against each mechanism: a lab tries the thing the mechanism says shouldn’t be possible and notes whether it worked. Then there’s the broader stuff, like firmware analysis and poking at the app and cloud back end. The standard doesn’t ask for that in so many words. It’s still how you find what a checklist misses.

Secure update is a good example, because one of the restricted points in EN 18031-3 sits there (clause 6.3.2.4, labelled SUM-2 in Ezurio’s summary of Decision 2025/138). Compare these two update handlers.

# Weak: installs whatever finishes downloading

def apply_update(url):

    blob = http_get(url)          # plain HTTP, no signature

    flash(blob)

    reboot()

# Stronger: verifies source, signature and version before flashing

def apply_update(url):

    blob = https_get(url)                          # TLS to a pinned host

    manifest = parse_manifest(blob)

    if not verify_signature(manifest, VENDOR_PUBKEY):

        raise UpdateRejected(“bad signature”)

    if manifest.version <= current_version():      # blocks rollback

        raise UpdateRejected(“older version”)

    flash(blob)

    reboot()

That’s illustrative code, not a client finding. A tester will push a tampered image at the first handler and watch it install. They’ll get nowhere with the second.

Want a pre-test pass on your update and credential flows? Qualysec can review them with you before the lab does.

RED Certification Europe: Notified Bodies and Routes

Here’s a point that trips up many UK teams. The Commission says a lab report isn’t an EU-type certificate and can’t replace one; it’s not that voluntary certificates “don’t prove compliance”. Two routes exist, and your design decides which one you get.

Restrictions in Implementing Decision 2025/138 push plenty of products into the second row, and a device that lets users skip password setup is the usual culprit. That route costs more and takes longer, so work out which row you’re in before anyone promises a launch date. Talk to the notified body early about what they want in the technical file, because that’s where teams stall. And check your chosen body is approved for radio equipment cybersecurity, since the Commission lists them by scope.

What the RED Directive Cybersecurity Rules Mean for UK Sellers

The answer splits by market. UK government guidance says CE-marked radio equipment can still go on the Great Britain market. It’s deemed to meet the Radio Equipment Regulations 2017.

Northern Ireland plays by different RED directive cybersecurity rules. The extra cybersecurity requirements apply there from 1 August 2025 under the Windsor Framework, so the full conformity assessment applies. PSTI applies separately in Great Britain; RED products supplied in Northern Ireland are exempt from it. 

Many UK teams ask whether they can ignore all this and sell only in Great Britain. You can, for now. But it limits your market, and most buyers want an EU option sooner or later. My view: build your RED directive cybersecurity to the EU standard once and sell everywhere. Maintaining a GB-only variant rarely saves money.

What Changes After December 2027?

2022/30 is on its way out. Delegated Regulation (EU) 2026/339 repeals it, and the repeal takes effect on 11 December 2027, the day the Cyber Resilience Act starts applying in full. If your product goes on the market between 1 August 2025 and 10 December 2027, market surveillance still judges it against the old requirements.

Don’t sit on the redesign, though. Hardware revisions eat months, and the CRA brings duties the old articles never asked for. Its vulnerability and incident reporting rules have been live since 11 September 2026 as well.

How Qualysec Supports Your RED Compliance Work

Qualysec is a CREST-accredited penetration testing company. It isn’t a notified body, so no certificates come from it. What you get is someone attacking your device the way a hostile tester would. The faults they hunt for are the ones that sink EN 18031 mechanisms in practice: weak authentication, insecure firmware updates, poor encryption, loose access control, unprotected protocols, and debug interfaces somebody forgot to switch off.

Firmware and Hardware Testing

Qualysec’s IoT and embedded device testing covers the firmware, the communication protocols, the hardware interfaces, and the server-side components. Testing is manual, and you choose the depth. Black box means the tester starts as an outsider and sees what they can reach. White box hands over your firmware, schematics, APIs, and source code, which is the fastest way to turn up hard-coded secrets and test accounts nobody remembered.

App and Cloud Testing

A lot of connected-device failures aren’t in the device at all. They’re in the app, or in the cloud API sitting behind it. Qualysec tests the cloud interface, the mobile app, and the APIs along with the hardware, so you find the “checked the user once, then trusted everything” flaws before a lab does.

Findings, Fixes and Retest

Every report gives you the vulnerabilities, each with a risk level, its impact, and a suggested fix. Qualysec’s dashboard lets your team track findings, assign them to developers, and request a retest, and every engagement ends with remediation testing. That fits neatly with the checklist above. Each finding becomes a ticket, and each closed ticket gets a retest behind it. File the retest report next to your risk assessment, so you’ve got supporting evidence if anyone asks.

Before anything starts, Qualysec sends over a pre-assessment form and a checklist of prerequisites. Get your architecture notes, update procedure, and test credentials together first, and the scoping call goes faster.

Want a pre-lab pass on your firmware, app, and cloud? Book a scoping call with Qualysec and bring your risk assessment.

Speak Directly With Qualysec’s Certified Security Experts

Discover vulnerabilities before attackers exploit them

Schedule Free Consultation
→

Conclusion

The RED cybersecurity requirements aren’t hard to understand. Fitting them around a release date is the hard part. Teams that start with scope, do a proper risk assessment, and test the build they’ll actually ship mostly get through fine. Leave it all to the last week, and you’ll probably regret it.

So the best way is to get the RED compliance checklist, give it to engineering, and ask where each line stands. And choose your certification route before you book any lab time.

Want a second opinion before you commit? Book a RED readiness review with Qualysec, and you’ll leave with a prioritised list of findings to fix.

Frequently Asked Questions

1. What are the Radio Equipment Directive RED cybersecurity requirements?

Three articles in the Radio Equipment Directive –

• 3.3 (d): Radio equipment must not harm networks or disrupt services.
• 3.3 (e): Radio equipment must protect users’ personal data and privacy.
• 3.3 (f): Radio equipment must include features to prevent fraud.

Since 1 August 2025, they apply to certain internet-connected kit, childcare equipment, toys and wearables.

2. Does the Radio Equipment Directive apply to UK manufacturers?

If you sell into the EU or Northern Ireland, yes. For Great Britain, CE-marked radio equipment is accepted and deemed to meet UK rules. PSTI applies separately.

3. What does RED compliance testing involve?

Mostly functional tests per EN 18031 mechanism, run on the firmware you plan to ship. Plenty of teams add firmware, app, and cloud testing on top, because the standard alone misses things.

4. Do I need RED certification Europe-wide, or can I self-declare?

You can self-declare (Module A) only if you apply the relevant EN 18031 standards in full and none of the Commission’s restrictions apply to your product. If a restriction applies, for example your device lets users skip setting a password, or it handles money or virtual currency under EN 18031-3, you need a notified body to issue an EU-type certificate. 

5. When do the rules end?

On 11 December 2027, when Regulation 2026/339 repeals 2022/30 and the CRA takes over. Products already on the market keep the old rules for market surveillance. Regulation 2026/339 was published in the Official Journal on 29 April 2026.