The EU’s RED Cybersecurity Delegated Act (2022/30) comes into force in August 2025, making cybersecurity compliance mandatory for all internet-connected radio devices sold in the EU. This includes WiFi, BLE, and cellular-enabled devices, even if they are already CE-marked.
At Oxeltech, we provide RED Cybersecurity compliance support for connected devices. Many clients ask: Do we have to redesign our hardware?
In many cases, the answer is no.
Why RED Cyber DA Matters for Connected Devices
The RED Delegated Act activates Articles 3(3)(d), (e), and (f). These require that connected devices:
- Protect network communication
- Safeguard user privacy and personal data
- Prevent unauthorized access and misuse
To meet these goals, the EU references ETSI EN 303 645 as the baseline cybersecurity standard for connected products. The EU has also published EN 18031-1, EN 18031-2, and EN 18031-3 as the harmonized standards under RED, which are now the official references for demonstrating compliance.
What Can Be Secured Without Hardware Redesign?
| Security Requirement | Achievable Without Hardware Change |
| TLS/HTTPS Communication | Yes |
| Secure Boot and OTA | Often (depends on MCU) |
| Unique Credentials | Yes |
| Debug Interface Lockdown | Yes |
| Hardware Root of Trust | Not always |
| Tamper Resistance | No |
Oxeltech Offers RED Cybersecurity Compliance Support for Connected Devices
If you are developing or selling a connected device in the EU, Oxeltech can help you:
- Identify technical gaps using ETSI EN 303 645
- Implement secure firmware and OTA processes
- Prepare technical documentation for CE
- Meet RED Cyber DA requirements without delays
We support devices based on STM32, ESP32, nRF52, NXP, and other MCUs, especially in low-power IoT and embedded applications.
Read our case study of how we have helped customers make their devices RED Cyber DA compliant.
Get RED Cybersecurity Compliance Support Today
Avoid late-stage certification problems and shipping delays.
Talk to Oxeltech to assess your product and get a plan for RED Cyber DA compliance that fits your roadmap and hardware constraints.
Book a free consultation
FAQs
What are the risks if my device doesn’t support Secure Boot or OTA?
Without secure boot, attackers can load unauthorized firmware. Without secure OTA, users cannot patch vulnerabilities. Both are high-risk gaps that can block RED Cyber DA compliance.
Do I need to give each device unique credentials?
Yes. Default passwords or shared credentials are not acceptable. Every device should have unique credentials generated at production or during onboarding. This can be done in firmware without changing hardware.
Why do I need to disable debug interfaces for compliance?
Open debug ports (UART, JTAG, SWD) allow attackers to bypass protections. For compliance, debug interfaces must be disabled, locked, or password-protected once the device is in production.
When do I need to redesign my hardware for RED Cyber DA compliance?
You may need a hardware redesign if your current device cannot support key security requirements such as secure boot, hardware root of trust, cryptographic acceleration, or tamper resistance. In these cases, the limitations of the MCU or hardware platform prevent full compliance through firmware updates alone. For many devices, however, compliance can still be achieved without changing the hardware by focusing on firmware, OTA mechanisms, and secure credential management.
Can I achieve compliance without a hardware root of trust?
Yes, in many cases. You can rely on secure boot, cryptographic checks, and protected storage in the MCU. However, for high-value applications (payments, medical, critical IoT), a hardware root of trust may be required.
Do all devices need tamper resistance to comply with RED Cyber DA?
No. Tamper resistance is not required for every IoT device. It mainly applies to products where physical attacks could compromise security (e.g., payment terminals, safety-critical equipment). Many consumer IoT products can comply without tamper-proof hardware.
My device does not have a dedicated chip for hardware root of trust. How can I achieve compliance without redesigning?
If your MCU does not include a dedicated hardware root of trust, you can still achieve RED Cyber DA compliance by implementing firmware-based security measures. These include:
- Using secure boot to ensure only verified firmware runs.
- Protecting device credentials with secure storage mechanisms available in the MCU.
- Leveraging cryptographic libraries supported by the processor.
- Disabling debug interfaces after production to prevent unauthorized access.
While hardware root of trust provides stronger security, many IoT devices can meet compliance requirements with careful firmware design and proper documentation of risk mitigation.
Can I achieve Secure Boot without a dedicated chip for hardware root of trust?
Yes, in many cases you can. Even without a dedicated secure element, many modern MCUs (such as STM32, ESP32, and nRF52 families) provide features that support firmware-based secure boot. This typically works by:
- Storing a cryptographic key or hash in protected flash or OTP (one-time programmable) memory.
- Using the MCU’s built-in bootloader or a custom secure bootloader to verify firmware integrity at startup.
- Rejecting or halting boot if the firmware fails authentication.
While this approach is not as strong as using a dedicated hardware root of trust, it can still meet RED Cyber DA compliance if properly implemented and documented as part of your device’s risk assessment.
Can I add OTA (Over-the-Air) updates without redesigning hardware?
In most cases, yes. If your MCU has enough flash and RAM, you can implement a secure OTA mechanism in firmware. OTA updates must be authenticated and verified before installation to meet RED Cyber DA requirements. The main limitations are available memory and the communication stack your device supports (e.g., WiFi, BLE, LTE).
Is TLS/HTTPS mandatory for RED Cyber DA compliance?
Yes. If your device communicates over the internet, using secure protocols like TLS or HTTPS is expected. This protects user data from interception and is achievable on most MCUs without hardware redesign.
