Radio Equipment Directive - Delegated Act on Silicon Labs Series 2 devices

RED-DA targets wireless connected consumer devices in the European Market

It will be enforced starting August 1st 2025

The below guide aims at centralizing information based on the MCU usage, it is not in any way a guarantee that an end product compliance

What devices and products are these regulations targeting

These Cybersecurity Regulations are device level certifications.

Silicon Labs, as any other device manufacturer, cannot get any certifications that prevents device makers from meeting the requirements.

However, some features and other certifications can be useful in preparing an end device for compliance.

How ready is an EFR32 Series 2 based end device for compliance

To ensure your end device based on a Wireless MCU complies with RED-DA , you can start by following generated flow below.

A lot depends not only on the MCU, but also on the application and the communication protocol.

The ultimate responsibility lies with you in ensuring these security capabilities are fully activated and integrated into a complete solution

1. Cybersecurity Features and Standards Compliance

   a. Does the MCU support secure boot and secure firmware updates?

   b. What encryption standards (e.g., AES-128, AES-256) are supported for communication and data storage?

   c. Is the MCU compliant with relevant cybersecurity standards such as ETSI EN 303 645, EN 301 489-1, or similar?

2. Software and Firmware Security

   a. Does the MCU have mechanisms to ensure the integrity of firmware (e.g., cryptographic signing, checksums)?

   b. Is there a secure element or hardware security module (HSM) available for cryptographic operations?

3. User Data Protection

   a. What measures are in place to secure user data stored or transmitted by the MCU?

   b. How does the MCU ensure secure handling of credentials, such as keys and passwords?

4. Connectivity and Protocol Security

   a. Does the MCU support secure pairing or authentication mechanisms for connected devices?

   b. Are there protections against common wireless vulnerabilities, such as replay attacks or man-in-the-middle attacks?

5. Development and Testing Tools

   a. Does the manufacturer provide a cybersecurity checklist or design guide to ensure compliance with RED-DA?

   b. Are there tools available for penetration testing, fuzz testing, or vulnerability scanning for the MCU firmware and software?

   c. Can the manufacturer provide reports or certificates from independent cybersecurity audits or assessments?

6. Documentation and Compliance Support

   a. Does the manufacturer provide detailed documentation for implementing security features?

   b. Are there templates or guidance available for creating a technical file or declaration of conformity for RED-DA compliance?

   c. Can the manufacturer supply evidence of compliance with RED-DA requirements (e.g., test results, certifications)?

7. Post-Deployment Security

   a. Does the MCU support Over-the-Air (OTA) updates for firmware, and are these updates secure?

   b. How does the manufacturer handle vulnerability disclosure and response (e.g., firmware patches for identified vulnerabilities)?

   c. What is the lifecycle support for the MCU in terms of security updates?

Hardware - RED-DA compliance guidance

Below table aims at guiding through which EFR32 variants and what capabilities can be used to fully comply with RED DA

Some features will however depend also on which communication protocol is being used (please refer to next section for details)

Devices capable of RED-DA Compliance

EFR32xG2xA	EFR32xG2xB	EFR32xG22/27/29	EFR32xG22	EFR32xG22E (As for Series 1)
Yes*	Yes	Yes*	Yes*	No (See details below)

*Devices without Secure Vault High require developers to implement required features based on ARM Trustzone. Implementation varies based on the Communication Software Stack being used

Requirement based feature documentation

Cybersecurity item	EFR32xG2xA	EFR32xG2xB	EFR32xG22/27/29	EFR32xG22E	Comments
1. a.	Yes (AN1218 )	Yes (AN1218 )	Yes (AN1218 )	Yes (AN1218 )	Firmware updates may require additional storage space (i.e. external Flash memory) Despite Gecko Bootloader does support Firmware Update, developpers must ensure the communication protocol used also supports means to securely provide new images
1. b.	Communication : Protocol Specific (See Below) Secure Data Storage ( AN1271 ) : TrustZone based Encryption Standards : PSA Drivers (via HSE)	Communication : Protocol Specific (See Below) Secure Data Storage ( AN1271 ) : TrustZone based, Secure Vault based Encryption Standards : PSA Drivers (via HSE)	Communication : Protocol Specific (See Below) Secure Data Storage ( AN1271 ) : TrustZone based Encryption Standards : PSA Drivers (CRYPTOACC)	Communication : Protocol Specific (See Below) Secure Data Storage : None Encryption Standards : PSA Drivers (CRYPTOACC)
1. c.	See ETSI EN 303 645 map to Secure Vault	See ETSI EN 303 645 map to Secure Vault	See ETSI EN 303 645 map to Secure Vault	See ETSI EN 303 645 map to Secure Vault
2. a.	Secure Boot with RTSL (AN1218 )	Secure Boot with RTSL (AN1218 )	Secure Boot with RTSL (AN1218 )	Secure Boot without RTSL (AN1218 - Secure Vault Base)
2. b.	HSM (Secure VaultMid)	HSM (Secure VaultHigh)	VSE (Secure VaultMid)	No Secure Engine
3. a.	Secure Debug Lock to prevent flash and debug access TrustZone Secure Storage available to obfuscate flash contents	Secure Debug Lock to prevent flash and debug access DPA Countermeasures to detect tampering (HW and SW) and act accordingly TrustZone, Secure Vault Secure Storage available to obfuscate flash contents	Secure Debug Lock to prevent flash and debug access DPA Countermeasures (EFR32xG27/29 only) to detect tampering (HW and SW) and act accordingly TrustZone Secure Storage available to obfuscate flash contents
3. b.	Protocol Specific (See Below) TrustZone Secure Storage usage at the responsibility end device manufacturer	Protocol Specific Secure Vault Secure Storage implmented whenever possible TrustZone Secure Storage usage at the responsibility end device manufacturer	Protocol Specific (See Below) TrustZone Secure Storage usage at the responsibility end device manufacturer
4. a.	Protocol Specific (See Below)	Protocol Specific (See Below)	Protocol Specific (See Below)
4. b.	Protocol Specific (See Below)	Protocol Specific (See Below)	Protocol Specific (See Below)
5. a.	!	!
5. b.	!	!
5. c.	SESIP, Riscure, PSA Lvl 2 (Third Party Accreditation )	SESIP 3, Riscure, PSA Lvl3 (Third Party Accreditation )	SESIP, Riscure, PSA Lvl 2 (Third Party Accreditation )
6. a.	Centralized Security Documentation	Centralized Security Documentation	Centralized Security Documentation	Centralized Security Documentation
6. b.	!	!
6. c.	!	!
7. a.	Protocol Specific (See Below) for transport Gecko Bootloader supports Encrypted and Authenticated updates	Protocol Specific (See Below) for transport Gecko Bootloader supports Encrypted and Authenticated updates	Protocol Specific (See Below) for transport Gecko Bootloader supports Encrypted and Authenticated updates
7. b.	Vulnerability Disclosure Policy	Vulnerability Disclosure Policy	Vulnerability Disclosure Policy	Vulnerability Disclosure Policy
7. c.	SDK Maintenance Policy	SDK Maintenance Policy	SDK Maintenance Policy	SDK Maintenance Policy

Protocol based RED-DA compliance guidance

Requirement based feature documentation

The table below covers how each protocols cover the corresponding items

Cybersecurity item	Zigbee	BLE	OpenThread	Proprietary	Comments
3. b.	Zigbee Security Manager Software Component Secure Storage on Vault High Plain Storage on Vault Mid (Trustzone requires customer's implementation within Zigbee Security Manager Software Component)
4. a.	Zigbee R23 Protocol Standards
4. b.	Zigbee R23 Protocol Standards
7. a.	OTA Implmentation provided (AN1384)

Software Stack specific documentation

Below are pointers to documentation explaining how customers can implment required features by themselves

Trustzone Secure Storage with SL_Zigbee

Trustzone Secure Storage with SL_BLE

Trustzone Secure Storage with OpenThread (Matter)