“RED DA” cybersecurity rules apply Aug 1st 2025 – is your embedded/IoT device in scope?
TL;DR Summary
If your embedded/IoT device has a radio or modem, you may well be caught by RED DA immediately. You need to establish whether your device is in scope and act quickly. However even if you’re out of scope, then because EN 18031 is likely to form the backbone of the proposed standard for CRA compliance, it should be your starting point in the CRA journey.
What is “RED DA”?
The existing RED (Radio Equipment Directive) which has been evolving since 1999, but has not previously concerned itself with cyber-security, has been modified via an EU “Delegated Act” to enact stringent cyber-security requirements, effective August 1st 2025. RED DA has immediate effect on all devices that are connected to the internet directly or indirectly via wireless. Such devices cannot be shipped to the EU-bound supply chain, nor CE-marked from August, unless compliant.
However, if your device is not within scope – perhaps it doesn’t use any form of wireless – there’s still an important take-away for EU CRA (Cyber Resilience Act) compliance – so please read on!
The devices within the scope of RED DA are a wirelessly-connected subset of the “Products with Digital Elements” or PDEs which will have to comply with the CRA on its effective date of December 11th 2027. However, unlike the CRA, the requirements of RED DA are effective from August 1st 2025, and are already spelt out in a harmonized standard – EN 18031. Despite the different timing and narrower scope, it turns out that the provisions of EN18031 are also going to prove relevant to PDEs without radio connectivity as the CRA compliance countdown clock runs down.
Standards provide a mechanism, bridging the gap between regulations, which are couched in broad legal terms, and real-world projects needing a well-defined, tick-box set of requirements and metrics representing a knowable finishing-line to demonstrate conformity. Often, aligned standards give a foretaste of how the powers that be will interpret similar regulations, and EN 18031 has already been mentioned in committees of the EU standards-setting body (CENELEC) as a potential basis for the main part of the coming CRA standard. Additionally harmonized standards offer the opportunity to establish “presumption of conformity” – effectively waiving the need to repeat the compliance process for similar requirements in aligned standards. Until CRA has its own set of standards then, EN 18031 represents an oasis in the desert of scant technical detail offered by the CRA. A “mapped” approach based on this, and other adjacent standards such as EN 303645 and ISA/IEC 62243 is a far more reliable path to a declaration of conformity than a freelance interpretation of regulation. It’s unlikely that CRA-specific standards expected to appear in draft form in the second half of 2026 will offer detailed provisions incompatible with EN 18031 and other adjacent standards. So it is by clause-by-clause reference to the existing standards that CRA compliance can be demonstrated now, in a way that should avoid too much rework once the CRA harmonized standards are published.
RED DA – Scope and Basic Facts
RED DA and EN 18031 come in three parts. Article 3(3) d), e) and f) of the Delegated Act are represented by Parts 1, 2 and 3 of the Standard. We are chiefly concerned with EN 18031 Part 1 here, because the scope of this part is horizontally drawn, and includes all internet-connected radio equipment. The DA makes clear that the definition includes connection “via any other equipment”, so that any indirect internet connection, such as signalling via a low-power or low-bandwidth WAN is in scope. Part 1 concerns itself with general security requirements for such devices.
EN 18031 Parts 2 and 3 are concerned with setting higher cybersecurity standards when processing personal data and financial data respectively. Important matters, but only for a small subset of IoT/embedded devices, so these can be dealt with separately. Nevertheless it’s important to note that the scope of Parts 2 and 3 is not necessarily a subset of Part 1.
Meeting the challenge of EN 18031
Having looked at the scope, what are the provisions of EN 18031 Part 1? This is necessarily a somewhat superficial analysis but here are the headlines:
- Access Control with appropriate authentication mechanisms – considering both access to the device itself, and the radio protocols which are exposed. This requirement goes away if public accessibility is intended. Authentication covers password security including disallowing “factory defaults”.
- Secure Update Mechanism – an updating mechanism must be present. There is a need to be mindful of the CRA’s requirement for updating to be free of charge for the end-user from the end of 2027, so it would be pointless to explore mechanisms which are inherently expensive.
- Secure Storage – this is quite a broad provision – as well as assets being encrypted so they cannot be accessed, there must be defence against an attacker’s ability to “tamper or delete”. In particular “hardware protection” should ensure that no data asset can be manipulated. This could be achieved by various means including secure boot.
- Secure Communication – authentication, integrity protection, encryption and replay protection are mentioned
- Resilience Mechanism against denial of service attacks including network monitoring and anomaly detection
- Traffic Control Mechanism – detection of and defence against anomalous network traffic
- Best Practice Cryptography including appropriate strength of encryption
- No Exploitable Vulnerabilities – analysis of software composition which is assessed against published vulnerability databases
This seems like a rather broad set of rules. However there are some provisions of the CRA (effective in December 2027) which are under-represented or missing: EN 18031 does not mandate a risk assessment up-front. The need to evidence the implementation of a secure software development lifecycle is not present, and neither is the need to extend the secure environment to manufacturing. CRA also mandates incident reporting and has a more prescriptive approach to vulnerability management and the provision of security updates (and given this, EN18031 will likely not be the defining standard in this respect). Most of EN 18031 can be considered a subset of CRA provisions, although some of the networking-specific requirements may obviously be irrelevant to non-connected devices. The “missing” items are likely to be drawn from other standards such as ISA/IEC 62443.
Although the CRA’s overarching requirement for a risk assessment is absent, instead EN18031 gives item-by-item guidance on risk-based interpretation (for example, you don’t need access control on a button intended to be pressed by any member of the public) which is helpful in limiting the scope of the task for those scrambling to comply.
Timing and interaction between EN 18031 and CRA
The CRA directly addresses this question, stating “EU type-examination certificates and approval decisions issued regarding cybersecurity requirements for products with digital elements that are subject to Union harmonisation legislation other than this Regulation shall remain valid until 11 June 2028…” [Art. 69].
Therefore if RED DA compliance has already been achieved, that remains valid for an extra 6 months after the CRA deadline of December 11th 2027. Beyond that point, RED DA and EN 18031 disappear and the CRA and its by-then-effective standard will simply replace it.
In Summary
If your embedded/IoT device has a radio or modem, you may well be caught by RED DA and EN 18031 immediately. You need to establish whether your device is in scope and act.
However if you’re out of scope, then EN 18031 is the most significant nearby standard for CRA compliance, and should be your starting point in the CRA compliance journey.
What’s next?
I’m hoping to host a webinar giving a slightly more in-depth look at this topic during the summer. Mailing list subscribers will be the first to know!
Direct Insight is working on CRA-readiness for some generic system-on-module based platforms, with Linux (and also QNX) support, such as this one. If you are interested in our progress just let us know here, and we’ll keep you in the loop.
David Pashley