CE certification for IoT: What RED DA changes

Why RED DA changes the development brief? Hundreds of companies have had their own IoT devices developed in recent years. Development went well, the product works. Then comes the CE certification phase and it turns out that something essential is missing.

Key takeaways

• Since August 2025, cybersecurity requirements under the RED Delegated Act have applied to certain categories of radio equipment placed on the EU market, making cybersecurity part of the conformity assessment manufacturers need to address before CE marking.
• For IoT products, technologies such as Wi-Fi, Bluetooth, LoRaWAN, NB-IoT, Zigbee or wM-Bus can bring a device within the relevant RED cybersecurity requirements depending on how the product connects and what data or functions it handles.
• Preparing for conformity assessment requires cybersecurity to be documented as part of the product design, including areas such as threat analysis, firmware updates, authentication and access control, communication security, credential management and privacy.
• The necessary cybersecurity documentation depends on detailed knowledge of how the product was designed and implemented. If it was not included in the original development scope, completing it retrospectively may require substantial input from the developer and, in some cases, changes to the product itself.
• The Cyber Resilience Act adds broader lifecycle obligations. Vulnerability and incident reporting requirements have applied since September 2026, while the main CRA requirements apply from December 2027, including cybersecurity requirements throughout the product lifecycle and documentation of product components and vulnerabilities.
• If cybersecurity documentation is missing, the first step is to determine what evidence already exists, what can be completed retrospectively and whether the product itself needs changes before conformity can be demonstrated.

Where most companies make a mistake

A company has an idea. It approaches an individual developer or a development firm and agrees on functionality, deadline, and price. Development is completed, the prototype works. And then the question comes: who will handle CE certification? Very often the answer is: we'll take care of it ourselves. And this is the stage where complications start to appear.

CE certification is not just a formal stamp. For wireless devices, it is a technical process that requires specific documentation, and that documentation can only be supplied by the developer. If you have not agreed on this with your hardware supplier in advance, the documentation may simply not exist.

And the result? Delayed market launch, unexpected costs, and in the worst case the need to redesign the product.

What is RED DA and why it concerns you

Since August 2025, the RED Delegated Act (RED DA) has been in force; an extension of the existing Radio Equipment Directive. Every product with a wireless interface sold in the EU must undergo a cybersecurity assessment as part of CE certification.

A wireless interface means anything that transmits or receives a signal: WiFi, Bluetooth, LoRaWAN, NB-IoT, ZigBee, wM-Bus, and others. In practice, every modern IoT device.

Who exactly is affected by RED DA

If you develop or place any of the following types of products on the market, RED DA requirements directly apply to you:

• smart meters and converters for remote reading (wM-Bus, NB-IoT, LoRaWAN)
• sensors and concentrators in industrial automation
• gateways and routers for IoT networks
• smart home and building management devices
• wearables and medical devices using Bluetooth or WiFi
• industrial controllers communicating wirelessly with a higher-level system

‍

If your product contains a wireless interface and does not meet RED DA requirements, it cannot be legally sold in EU countries. The certification laboratory will not issue CE, or will issue it with conditions you will need to fulfil retroactively.

What you specifically need from your developer

CE certification for IoT devices today requires technical documentation describing the product's security design. And only the party that actually designed the product can supply it. Specifically, the documentation must cover the following areas:

• Threat analysis and security design (threat model): how the product was designed with cybersecurity risks in mind
• Firmware update mechanism (FUOTA): how the device can be safely updated in the field
• Authentication and access rights: who can communicate with the device and how
• Communication encryption: how data is transmitted and stored
• Credential management: how default passwords and certificates are handled
• Privacy by Design: particularly relevant if the device collects any data

‍

If you do not request this documentation from your supplier, or if your supplier does not deliver it as a standard part of development, you face a choice: pay for it to be prepared retroactively, or redesign the product with a different partner.

Always ask your current supplier whether they will deliver cybersecurity documentation for RED DA as part of the project. The answer will tell you how prepared the supplier is for the current regulatory environment.

And that's not all that's changing: CRA is coming

RED DA is not the only regulation IoT device manufacturers will encounter soon. From October 2027, the Cyber Resilience Act (CRA) enters into full force. It goes considerably further.

While RED DA addresses the security design of the product as a condition of CE certification, CRA introduces cybersecurity as a separate and ongoing manufacturer obligation. Specifically, this means mandatory security support for the product throughout its entire lifecycle, reporting of actively exploited vulnerabilities within 24 hours, and maintaining an SBOM (Software Bill of Materials); documentation of all software components.

If you are developing an IoT product today, it is wise to design it with both regulations in mind from the start. Addressing them separately, retroactively, and under time pressure is usually significantly more expensive. A well-designed product compliant with RED DA also has a solid foundation for CRA; these are not two separate sets of requirements.

What to do if you find that documentation is missing

If you have concluded that your supplier probably does not have documentation prepared, here are the practical next steps:

1. Contact a certification laboratory as soon as possible. The earlier you know exactly what you need, the easier it is to still complete it in time.
2. Verify with your supplier what they can deliver retroactively. Sometimes it is possible; the question is the cost and time.
3. If the product is at the prototype stage, consider a redesign with a partner who includes RED DA in the standard development process.
4. If you are just starting: when selecting a developer, ask directly how they handle cybersecurity documentation as part of CE certification. The answer will tell you a lot about the supplier.

Our practice

At ACRIOS, technical documentation for cybersecurity, including the materials needed for RED DA, is a standard part of every development project. You don't find this out at the end. We address it from day one of architecture design.

This is why our projects pass CE certification without unexpected stops. And our customers know what they will receive; including what will be needed for the regulatory environment that is coming.

Every product has a different architecture, different communication interfaces, and a different scope of personal data processing. The exact scope of RED DA requirements for your product is best confirmed by an accredited certification laboratory together with the development team. We are happy to help you assess what your project needs for smooth CE certification, and what will be required for CRA, which enters into force from October 2027.

Glossary of terms used

• CE marking: a marking by which the manufacturer declares that a product conforms to the applicable EU requirements, affixed after the relevant conformity assessment
• Conformity assessment: the process of demonstrating that a product conforms to the requirements of the applicable EU legislation before it is placed on the market
• CRA (Cyber Resilience Act): the EU regulation establishing cybersecurity requirements for products with digital elements and related obligations throughout their lifecycle, including vulnerability handling and security updates
• FUOTA (Firmware Update Over the Air): a firmware update delivered to a device remotely over its communication network
• Privacy by design: an approach in which personal data protection is built into a product from the beginning of the design process rather than added later
• RED (Radio Equipment Directive): the EU directive setting requirements for radio equipment placed on the EU market, including safety, electromagnetic compatibility, efficient use of the radio spectrum and, where applicable, additional requirements such as cybersecurity
• RED DA (RED Delegated Act): the EU delegated regulation that makes specific cybersecurity requirements under the Radio Equipment Directive applicable to certain categories of radio equipment
• SBOM (Software Bill of Materials): a structured inventory of the software components contained in a product, typically including information such as component names and versions
• Threat model: a structured analysis of potential threats to a product, how they could affect it and the measures designed to reduce the associated risks