Deep dive on RED

1. Article purpose

The Radio Equipment Directive (RED), RED Directive 2014/53/EU, mandates that all radio equipment produced in Europe or imported to the European market must be safe and free from harmful interference. Since October 2021, this directive has incorporated cybersecurity requirements within a delegated act, necessitating compliance, in case an RF device is connected directly or indirectly to Internet. A harmonized standard, EN-18031, has been created. This standard allows manufacturers to perform self-assessments to ensure that their products meet the required security criteria. Compliance can also be claimed using RED notified bodies. The application date of the directive was set to 1st August 2025.

2. Understanding EU RED cybersecurity requirements

In January 2025, the European Commission formally adopted the EN 18031 standard, titled "Common Security Requirements for Radio Equipment", as a harmonized benchmark under the Radio Equipment Directive (RED). This move sets a clear regulatory framework, aimed at strengthening cybersecurity measures for radio-enabled devices across the European market. The standard introduces mandatory cybersecurity obligations that manufacturers must meet:

• Article 3(3)(d): radio equipment does not harm the network or its functioning nor misuse network resources, thereby causing an unacceptable degradation of service.
  • Requires that any radio equipment capable of internet communication is designed to prevent any threat or damage to connect to network
• Article 3(3)(e): radio equipment incorporates safeguards to ensure that the personal data and privacy of the user and of the subscriber are protected.
  • Imposes strict requirements on safeguarding users' personal data and privacy within radio devices
• Article 3(3)(f): radio equipment supports certain features ensuring protection from fraud.
  • Protects end-users from scams and unauthorized monetary operations

These cybersecurity requirements apply to all radio devices that connect directly or indirectly to the Internet, like:

• Wi-Fi® enabled devices
• 5G enabled devices
• Bluetooth® enabled devices

Further guidance is available within an EC guide RED Guide.

3. RED essential security requirements

As stated in RED article 3, a list of essential requirements is given, so that manufacturers can develop and validate their products.

• Include elements to monitor and control network traffic, including the transmission of outgoing data.
• Design to mitigate the effects of ongoing denial of service attacks.
• Implement appropriate authentication and access control mechanisms;
• Provided, on a risk basis, with up-to-date software and hardware at the moment of placing on the market.
• Do not contain publicly known exploitable vulnerabilities as regards harm to the <d><e><f>.
• Provided with automated and secure mechanisms for updating software or firmware that allow, when necessary, the mitigation of vulnerabilities that if exploited may lead to <d><e><f>.
• Protect the exposed attack surfaces and minimize the impact of successful attacks.
• Protect stored, transmitted or otherwise processed <e> <f> against accidental or unauthorized storage, processing.
• Access, disclosure, unauthorized destruction, loss or alteration or lack of availability of <e><f>;
• Include functionalities to inform the user of changes that may affect data protection and privacy.
• Log internal activities that can have an impact on <e> <f>.
• Allow users to easily delete their stored personal data, enabling the disposal or replacement of equipment without the risk of exposing personal information.

4. EN 18031 cybersecurity harmonized standards for RED

The EN 18031 standards was harmonized and allows manufacturers to prepare their documents of conformance, in self-assessment, without the need for a notified body evaluation. It emphasizes the protection of "assets" as essential elements or functions that require safeguarding. These standards define a set of requirements that manufacturers must fulfill to ensure device security.

The key requirements are based on the RED essential requirements areas and include:

• General equipment security: Implement technical and operational measures to enhance vulnerability management, focusing on security by design, and minimizing attack surfaces.
• Access control mechanisms: Ensure that only authorized entities can access security and network assets through appropriate control measures.
• Authentication mechanisms: Manage and regulate access rights for reading, modifying, or using network configurations and security parameters.
• Cryptography and key management: Adhere to established international cybersecurity standards for cryptographic methods and key handling, referencing guidelines such as NIST SP 800-57, SOGIS Agreed Cryptographic Mechanisms, ETSI TS 119 312, and BSI TR-02102-1.
• Secure storage solutions: Protect the confidentiality and integrity of stored assets with robust storage mechanisms.
• Secure communication protocols: Safeguard communications involving assets to maintain authenticity, confidentiality, and protection against replay attacks.
• Secure update processes: Provide secure mechanisms for software updates, ensuring the integrity and authenticity of new software installations.
• Resilience features: Incorporate functionalities and best practices that improve resistance against denial-of-service (DoS) attacks targeting network interfaces.
• Monitoring capabilities: Establish mechanisms to detect and monitor DoS attacks within network traffic.
• Traffic control measures: Detect and respond to malicious behavior within network traffic to maintain system integrity.

5. From compliance to resilience: elevating IoT security beyond regulations

RED establishes mandatory cybersecurity requirements for connected devices in the European market, aiming to protect networks and personal data.

While RED compliance is essential, it does not ensure complete IoT security. Cyber threats evolve rapidly, and risks vary by application and use case.

Broad regulations cannot address all specific security challenges. Manufacturers and stakeholders must assess unique threats and implement tailored security measures to effectively mitigate vulnerabilities and risks.

6. The importance of security by design and life cycle management

Effective IoT security goes beyond mere regulatory compliance. Two key principles, namely security by design and continuous life cycle management, are essential to building and maintaining robust cybersecurity.

6.1. Security by design

Integrating security from the earliest stages of product development is critical. This approach involves:

• Conducting threat modeling and risk analysis to identify and evaluate potential vulnerabilities
• Reducing the attack surface to limit exposure
• Embedding consistent security requirements throughout design and development phases
• Following secure coding practices aligned with industry standards
• Implementing tailored security features to meet the needs of specific market sectors
• Performing rigorous testing, including penetration tests and automated security checks, to detect and fix weaknesses
• Establishing incident response procedures covering the entire product life cycle

6.2. Comprehensive lifecycle management

IoT devices often remain in use for many years, during which new threats can arise. Sustaining security requires proactive and continuous support, including:

• Rapid response mechanisms to handle security incidents as they occur
• Continuous monitoring to detect vulnerabilities early, often enabling preemptive updates
• Ongoing software maintenance and updates to counter emerging threats
• Regular security advisory and support services throughout the device operational lifecycle

7. Do STM32 products require formal conformance to RED?

STM32 products are composed of:

1. STM32 ICs (standalone hardware devices)
   1. Non-RF devices
      • STM32 general purpose MCUs and MPUs without an RF interface
   2. RF devices:
      • STM32WBx - Bluetooth devices
      • STM32WBAx - Bluetooth devices
      • STM32WB0x - Bluetooth devices
      • STM32WLx - Sub-Gigahertz devices
2. STM32 RF modules
   1. STM32WBxM - Bluetooth devices
   2. STM32WBAxM - Bluetooth devices
   3. STM32WB0xM - Bluetooth devices
   4. STM32WLxM - Sub-Gigahertz devices
3. STM32 RF Evaluation boards (such as Nucleo boards or Discovery kits)

By nature, none of the STM32 ICs (general purpose or RF centric) embed an antenna, or a software to connect to the Internet, and therefore they are not subject to RED compliance.

Modules or development and evaluation boards may be provided with an antenna, and a firmware, but not provided with a direct nor an indirect application connecting the module to Internet. Therefore, these modules and boards are not subject to RED cybersecurity compliance. Device manufacturers that connect these devices to the Internet (for example via an application connection acting as a gateway) must ensure compliance with the RED cybersecurity requirements.

Nevertheless, ST did several exercises to show the potential RED cybersecurity compliance:

1. Exercise done of an IC, STM32WB0x, as a result an Attestation of Conformity (AoC) is publicly available
2. Exercise done on a full Nucleo board, NUCLEO-WBA55CG, allowing ST to claim a public EU-TYPE EXAMINATION CERTIFICATE (EU-TEC) - Identification Number: 79389RNB.001A1

8. How can ST help for your RED conformance?

8.1. Security by design

Security at ST is part of our DNA. Indeed, since many years ST is leading in markets such as banking, digital identity, brand protection, eSIM, TPM and other secure applications. The know-how, skills, methodologies, infrastructures and processes have been extended to general purpose microcontrollers and microprocessors. Most of the achieved certifications, such as ISO-21434, are on our corporate webpage. Other product related certifications, such as Common Criteria, EMVCo, GSMA, GSMA-SAS, ISO-27001 are also available, but limited to certain sites and product families.

8.2. Comprehensive life cycle management

• A rapid response mechanism to handle security incidents as they occur is handled since several year by our Product Security Incident Response Team. The process is described at PSIRT.
• Continuous monitoring to detect vulnerabilities early, often enabling preemptive updates
  • performed according to our STM32Trust Software security charter of Trust (see STM32Trust software security policies - stm32mcu) including
    • Software composition analysis: generation and publication of software bill of material (SBOM) as well as machine automated vulnerability scans
    • Software security classification
    • Static and dynamic application testing (SAST and DAST)
    • Corrections and update policies scaled according to risks
• Ongoing software maintenance and updates to counter emerging threats
  • This is a common part of our software quality and security maintenance commitment
• Regular security advisory and support services throughout the device’s operational lifecycle
  • Performed via our PSIRT page, as well as on our dedicated product pages

8.3. A scale of security assurance and features across a wide product portfolio

STMicroelectronics provides a comprehensive portfolio of security solutions designed to help businesses meet the requirements of RED and CRA regulations.

Our offering ranges from basic software-based security measures (such as cryptographic libraries, secure boot, and secure update mechanisms) to advanced security assurances reaching Common Criteria EAL5+ certification levels.

For STM32 microcontrollers and microprocessors, the STM32Trust framework assists developers in choosing appropriate hardware and software security solutions. It also provides access to an ecosystem of security tools and certified ST partners.

Emphasis is put on delivering clear and extensive security assurance through adherence to standards like the Security Evaluation Standard for IoT Platforms (SESIP) and the Platform Security Architecture (PSA).

ST actively implements a security assurance program across the whole STM32 product portfolio. Current certification targets for products are publicly available on the websites previously mentioned.

8.4. Certification and mapping to RED

While ST focuses on security assurance based on SESIP, mappings exist between SESIP and other security standards, and the RED directive. The SESIP & RED mapping is public and available hosted by GlobalPlatform.

These mappings enable developers to demonstrate compliance by aligning the security functions defined in a SESIPsecurity target with the essential technical requirements of the RED. These resources are openly accessible on the SESIP certificates website.

The essential requirements can be mapped to the Security Function Requirements (SFR) claimed within our certificates, as well as to the Security Functions provided within our STM32Trust security framework.

For example, devices such as the STM32WBAx Bluetooth and STM32H5x demonstrate SESIP certifications closely aligned with the key requirements of RED, showcasing ST’s commitment to robust security compliance.

8.5. Mapping of RED essential requirements from Article 3(3) with STM32Trust security functions

A mapping of the essential requirements can be done accordingly to the 12 security functions provided by our STM32Trustframework. This can be used as a guideline for developers when they select products and security services within our STM32 portfolio.

• include elements to monitor and control network traffic, including the transmission of outgoing data;
  • Application specific, not done by STM32 hardware
• is designed to mitigate the effects of ongoing denial of service attacks;
  • Application specific, some functions of the STM32 like Isolation & Abnormal situation handling (for example with tamper mechanisms) can help developer cover the requirement
• implement appropriate authentication and access control mechanisms;
  • Can be covered by Cryptography, Identification, Authentication & Attestation
• Are provided, on a risk basis, with up-to-date software and hardware at the moment of placing on the market
  • Secure Boot, Secure Install and Update
  • PSIRTand vulnerability public information and automated scans
  • SAST and DAST security testing (see STM32Trust Software Security Policy wiki)
  • Nevertheless, vulnerability handling is part of the application, under developers' responsibility
• That do not contain publicly known exploitable vulnerabilities as regards harm to the <d><e><f>;
  • PSIRTand vulnerability public information and automated scans
  • Vulnerability handling is part of the application, under developers' responsibility. The exploitability must be analyzed on a risk-based approach, depending upon the application context
• Are provided with automated and secure mechanisms for updating software or firmware that allow, when necessary, the mitigation of vulnerabilities that if exploited may lead to <d><e><f>;
  • Secure Boot, Secure Install & Update, Secure Manufacturing, Application Lifecycle
• Protect the exposed attack surfaces and minimize the impact of successful attacks;
  • Secure Boot, Isolation, Abnormal situation handling, Software IP protection, Silicon Device Lifecycle
• Protect stored, transmitted or otherwise processed <e> <f> against accidental or unauthorized storage, processing, access, disclosure, unauthorized destruction, loss or alteration or lack of availability of <e><f>;
  • Cryptography, Secure Storage
• Include functionalities to inform the user of changes that may affect data protection and privacy;
  • Application specific, some functions of the STM32 like Abnormal situation handling (for example with tamper mechanisms), Attestation of platform state and physical attacker resistance can help developer cover the requirement
• Log the internal activity that can have an impact on <e> <f>;
  • Audit & Log, Abnormal situation handling (for example with tamper mechanisms), Attestation of platform state and physical attacker resistance
• Allow users to easily delete their stored personal data, enabling the disposal or replacement of equipment without the risk of exposing personal information;
  • Strongly application related, some functions of the STM32 devices have mechanisms to lock the Silicon device lifecycle, known as Readout Protections or Product State

8.6. Device Provisioning and Lifecycle Security

To streamline trust establishment, newer STM32 devices are manufactured with pre-installed certificates and keys embedded during production. These credentials are recognized by leading cloud service providers and support remote management, allowing secure and flexible device authentication throughout the device lifecycle.

This method reduces risks related to credential handling, and strengthens the overall security posture from initial provisioning through to end-of-life.

9. RED cybersecurity compliance process

Manufacturers have two main routes to demonstrate compliance with the cybersecurity requirements outlined by RED:

9.1. Self-assessment method

This method enables manufacturers to independently verify their products' compliance. Key advantages include:

• Cost savings by avoiding fees associated with third-party evaluations
• Faster process due to the absence of external reviews
• Greater control over the compliance workflow

To proceed with self-assessment, manufacturers must:

• Confirm that their products fully satisfy all relevant EN 18031 requirements
• Prepare comprehensive technical documentation demonstrating compliance with each EN 18031 criterion
• Produce a self-signed Declaration of Conformity

No additional steps are required, but documentation must be retained and made available for inspection by market surveillance authorities upon request.

9.2. Notified body assessment

Alternatively, manufacturers may engage a notified body (an independent organization authorized by EU member states) to assess compliance. This option is mandatory when products partially comply with EN 18031, but include exceptions. Examples include:

• Products requiring password protection as per sections 6.2.5.1 and 6.2.5.2 of EN 18031-1/2/3. If users can opt out of setting a password, the product does not meet RED cybersecurity requirements, despite following the harmonized standard.
• Toys and childcare products covered by EN 18031-2 (sections 6.1.3 to 6.1.6) that use access control methods incompatible with parental controls, thus failing to fully comply with RED.
• Secure update mechanisms described in EN 18031-3 (section 6.3.2.4), where single-method implementations (digital signatures, secure communication, or access control) are insufficient for financial asset protection and do not fully address authentication risks.

The notified body’s role includes:

• Reviewing the technical documentation
• Assessing the product against RED criteria
• Performing additional testing, if needed
• Issuing a formal certificate of compliance when all conditions are met

The list of RED •notified bodies is available to help manufacturers find the appropriate companies by country.

9.3. Documentation obligations

To fulfill RED cybersecurity requirements, manufacturers must prepare and maintain the following:

• Technical specifications detailing product design and features
• Risk assessment identifying potential hazards and mitigation strategies
• List of applicable EN 18031 standards applied to the product (18031-1/-2/-3)
• For notified body assessment
  • The end-product manufacturer prepares technical documents
  • Notified body provides an EU-TEC formal conformance declaration
• For the self-assessment
  • The end-product manufacturer signs Declaration of Conformity (DoC) itself

10. Summary and key takeaways

Compliance with the EU Radio Equipment Directive (RED) cybersecurity requirements will become mandatory by 1st August 2025, covering a large number of radio devices sold within the European Union. The harmonized EN 18031-x series standards represent the way for manufacturers to claim self-assessment conformance.

Achieving comprehensive IoT security involves not only meeting regulatory requirements, but also embedding security by design principles. Incorporating advanced cybersecurity features and providing continuous life cycle support help address vulnerabilities throughout the entire lifespan of IoT devices.

Navigating RED Cybersecurity (EN 18031) compliance poses challenges but also offers opportunities for IoT manufacturers to enhance their security posture and market readiness.

Within Security in mind ST is the right partner to help manufacturer develop and claim devices that are secure over their entire device lifecycle.

To assist in this process, a dedicated Q&A page Security:Q&A for RED is available to help you better understand and navigate RED cybersecurity requirements.

11. References

• Further guidance in EC RED Guide
• Question & Answer on RED: Q&A for RED
• STM32Trust security framework
• The list of RED •notified bodies
• The SESIP & RED mapping