RED, the 14 most common pitfalls

Author Hugues Orgitello Last updated 25 May 2026

RED · Pillar

Fourteen recurring errors in RED certification that surface during market surveillance. Three families dominate: radio scoping errors, module reuse errors, post-market maintenance errors. The transition to 3.3 cybersecurity since 2025 has added a new set of specific pitfalls.

Family 1: Radio scoping errors

1: Missing the RED directive on a "non-radio" product

The number one pitfall. A sensor connected via Wi-Fi or BLE automatically falls under RED 2014/53/EU, even if the radio is marginal (OTA updates only). Many teams assess EMC and safety, forget RED.

How to avoid it: list all the product's intentional transmitters from the requirements stage, including third-party modules. Any active radio communication triggers RED.

2: Confusing the EMC emission class

EMC article 3.1(b) imposes a residential (Class B) or industrial (Class A with warning) classification. For B2C IoT products, target Class B systematically.

3: Ignoring 3.3 cybersecurity on a pre-2025 product

Any connected radio product placed on the market from 1 August 2025 must demonstrate compliance with EN 18031 standards. Products already marketed before that date remain valid in their state, but any new unit produced after must be compliant.

How to avoid it: cybersecurity audit of each portfolio product before the transition; compliance plan from 2024-2025.

4: Confusing receiver-only with out-of-scope

A GPS, FM, DAB receiver is in RED scope, even without transmission. Articles 3.1(a), 3.1(b) and 3.3 apply (article 3.2 does not apply to pure receivers as there is no emission to regulate).

5: Choosing a band without checking national assignments

Authorised frequencies differ slightly between EU countries. 5 GHz Wi-Fi sub-bands particularly have differing conditions. The 433 MHz band has variable limits. Verify the CEPT ECC decisions applicable to the bands used.

§ § §

Family 2: Radio module errors

6: Reusing a module's CE marking without reassessment

A CE-delivered Wi-Fi/BLE module keeps its compliance only in the precise test conditions: supplied antenna, minimum spacing, ground plane, power supply. Integrated in a final product, the slightest deviation invalidates the tests.

How to avoid it: require the module manufacturer's integration guide, verify compatibility point by point, redo at minimum final radio tests in the product configuration.

7: Modifying the firmware of a commercial radio module

If the integrator modifies the module's radio parameters (power, modulation, activated band), they become manufacturer in the RED sense. The original module's marking no longer applies. A complete new assessment is required.

8: PCB antenna instead of original external antenna

Many modules are certified with a specific external antenna. Replacing with an integrated PCB antenna modifies the gain, pattern, impedance, and thus article 3.2 tests. Always redo radio tests in this configuration.

9: Insufficient ground plane

Compact radio modules have strict ground plane requirements (minimum size, continuity). An undersized PCB degrades radio performance and often invalidates module tests.

Working on integrating a radio module into a PCB respecting the manufacturer's conditions for a real product? AESTECHNO can audit your design and certification plan. Get in touch →

Family 3: Post-market maintenance errors

10: Substituting an antenna after certification

A product tested with a specific external antenna may have its manufacturer substitute a cheaper antenna in production. Radio characteristics change (gain, pattern), invalidating the tests.

How to avoid it: lock the antenna in critical BOM. Any change triggers an article 3.2 retest minimum.

11: Firmware update affecting radio without reassessment

A firmware update that modifies power, timing, modulation, or adds a band triggers a new RED assessment. Many software teams modify these parameters without informing quality.

How to avoid it: lock radio parameters in firmware by signature or build control. Any modification goes through the product manager.

12: Not archiving distributed firmware versions

For an SDR (Software-Defined Radio) product, each distributed firmware version potentially modifies compliance. Retain the archive of all distributed versions during the 10 years after the last unit.

13: No cybersecurity vulnerability management procedure

With article 3.3 active, an uncorrected cybersecurity vulnerability can be considered a compliance defect. Without a formalised procedure, response is too slow.

How to avoid it: document the vulnerability disclosure & response procedure from placing on the market, reporting channel, response team, patch process, communication.

14: DoC not mentioning 3.3 cybersecurity

For products marketed from August 2025, the DoC must explicitly cite the applied EN 18031 standards. A DoC omitting these references is incomplete and exposes to market withdrawal.

In summary

The 14 RED pitfalls break down into three families:

1. Radio scoping (1–5), directive forgotten, incorrect emission class, 3.3 cybersecurity ignored, receiver misclassified, bands misassigned.
2. Radio modules (6–9), module misreused, firmware modified, antenna substituted, insufficient ground plane.
3. Maintenance (10–14), post-market antenna change, radio OTA not assessed, firmware not archived, cybersecurity not maintained, DoC incomplete on 3.3.

Three useful RED maturity indicators:

• Rate of portfolio radio products assessed for 3.3 (target: 100 % by end of 2025).
• Delay between a firmware modification and the file update (target: ≤ 4 weeks).
• Coverage of vulnerability management procedure (target: all connected radio products).

Without these indicators, the radio portfolio drifts, and with 3.3 activation, regulatory and reputational risk grows.

Sources & references

1. Safety Gate alerts, withdrawn radio products , European Commission ec.europa.eu/safety-gate-alerts/screen/webReport