Radio Equipment Directive & EN 18031 Compliance Guide for IoT Manufacturers

What Is the Radio Equipment Directive and Its Delegated Act?

The EU Radio Equipment Directive (RED), formally known as Directive 2014/53/EU, is a legislation designed to ensure that radio equipment sold on the EU market meets health, safety, and electromagnetic compatibility requirements. This directive was supplemented in 2021 by the Delegated Regulation (EU) 2022/30, introducing cybersecurity requirements.

The Radio Equipment Delegated Act (RED DA) "activates" the essential requirements listed in Article 3(3), points (d), (e) and (f) of the RED:

These essential requirements can be summarised as: not harm the network (d), protect user's personal data and privacy (e), and protect from (monetary) fraud (f).

The RED DA has been in application since 1 August 2025. From that date on, all radio equipment in scope must comply with the above essential requirements (where applicable) when placed on the EU market.

Radio Equipment in Scope of the RED DA

The three essential requirements apply to different types of radio equipment. As outlined in Article 1 of the RED DA:

Is my equipment "Internet-connected radio equipment"?

This concept is critical, as it can render equipment in or out of scope of 3(3)(d). There has been considerable industry debate about what exactly constitutes "internet-connected." We recommend aligning with the definition provided by the TIC Council in their position paper on the scope of the RED Delegated Act :

"TIC Council considers the term 'Internet-connected radio equipment' to be broader than radio equipment that connects itself to the Internet (e.g., implementing TCP/IP protocols). Radio equipment should be considered connected to the Internet if it has any pathway through which data is transmitted to or received from the Internet. This includes instances where data, such as an ID, is sent to the cloud or where information, like firmware updates, is received from the Internet. Any form of communication with the Internet, whether direct or indirect, in any part of the data chain, should fall under this definition."

— TIC Council Position Paper on the Scope of the RED Delegated Act

We consider this the most authoritative definition since the TIC Council is a global industry association representing the Testing, Inspection, and Certification sector, comprising the testing laboratories and Notified Bodies involved in RED and RED DA compliance. Therefore, should you work with a Notified Body for your compliance (more on that later), they will likely align with the position of the TIC Council.

Is My Equipment Childcare, Toy, or Wearable?

To determine if your equipment falls into one of these three categories, it is advisable to consult the explanations provided in the RED DA:

Does My Equipment Process Personal, Traffic or Location Data?

The answers to this question can be found in Article 1 of the RED DA, which outlines the applicability of the essential requirements along with necessary references and definitions.

• · Personal data is defined in the context of the GDPR (Regulation (EU) 2016/679), while
• · traffic and location data are defined within the ePrivacy Directive (Directive 2002/58/EC).

When conducting your risk assessment to determine whether requirement 3(3)(e) must be met, it's essential to refer to the GDPR for clarity on whether your equipment processes personal data. This involves understanding the definitions of "processing" and "personal data."

If you have any uncertainties, we recommend consulting with lawyers who specialise in GDPR and the ePrivacy Directive. Please feel free to reach out to us and we are happy to provide a recommendation of good lawyers!

Does my equipment transfer money or virtual currency?

Interpret this literally: does the equipment facilitate transactions involving money or virtual currency, such as payments or cryptocurrency exchanges?

Essential requirements applicability quick-reference

Three Documents You Need for the RED DA

To demonstrate compliance with the RED DA, you will need to create three key documents. Once all are in place with no Fail verdicts in the test report, you are ready to affix the CE marking and issue the Declaration of Conformity.

RED DA Risk Assessment

Risk Assessment as Defined in the EU Blue Guide

In the context of EU regulations, risk assessment refers to activities to assess the actual risks associated with their equipment to determine which essential requirements of a given regulation apply, as detailed in the EU Blue Guide, Section 4.1.2.2. Once these essential requirements are identified, manufacturers can implement the corresponding standards to demonstrate compliance.

What Is the RED DA Risk Assessment?

Sounds daunting? Actually, within the context of the RED DA, the risk assessment is surprisingly simple. Based on specific characteristics of your equipment, you can pinpoint which of the three essential requirements need to be addressed. The table in the scope section above summarises which characteristics trigger each requirement.

What to Capture in the Risk Assessment Report

While the regulation does not prescribe a specific format, a simple Word document capturing the following information suffices:

In the event of an audit by Market Surveillance Authorities, you can present this report to prove you have fulfilled your obligation to analyse the extent to which your equipment must meet the RED DA essential requirements.

RED DA Conformity Assessment Procedures

According to the RED DA, there are two approved paths for conformity assessment: self-assessment and certification by Notified Body. Self-assessment is a legally viable option for all manufacturers, provided the equipment does not fall under specific restrictions (covered below in the EN 18031 harmonization section).

Self-Assessment or Certification by Notified Body: Pros and Cons

Service Providers for Self-Assessment

The self-assessment route does not mean all tasks must be performed in-house — it simply means you are handling the assessment procedure independently, without obtaining a TEC from a Notified Body. The following service providers exist to help:

Notified Bodies and Where to Find Them

The EU's NANDO (New Approach Notified and Designated Organisations) Information System offers a portal for locating Notified Bodies. Filter the search on Legislation ("2014/53/EU Radio Equipment") and on Product (e.g., "Article 3.3 d"). Based on our experience working with multiple Notified Bodies, we recommend VDE! 😊👑 The quality of service providers can very - make sure to shop around and do your due diligence.

What Are EN 18031 Standards?

EN 18031 is the official series of standards for the RED DA. It comprises three standards, each corresponding to an essential requirement:

At a high level, these standards outline various mechanisms — security measures to be implemented in equipment. Each mechanism includes requirements designed to meet specific security objectives. For example, the Secure Update Mechanism (SUM) consists of three requirements: SUM-1, SUM-2, and SUM-3. Fulfilling these ensures equipment can be updated securely and automatically. The standards also specify assessment criteria for each requirement, facilitating the verification of their implementation.

Which EN 18031 Standard(s) Must I Apply?

Once you identify the applicable essential requirements through your risk assessment, the mapping to EN 18031 standards is direct:

EN 18031 as Harmonized Standards with Restrictions

What Does "Harmonized" Mean?

EN 18031 standards are "harmonized standards". This signifies that applying them confers the presumption of conformity, granting IoT manufacturers the possibility to self-assess — a conformity assessment procedure that does not require the involvement of a third party to demonstrate compliance with the RED DA.

Put simply, manufacturers applying EN 18031 can do everything in-house, from implementing the necessary requirements to performing the related assessments. Assuming all assessments are successful, manufacturers can then declare compliance by adding the standard(s) to the equipment's Declaration of Conformity (DoC) and affixing the CE mark.

On the other hand, applying any other standard will not confer the presumption of conformity — meaning self-assessment is not possible without a Notified Body. However, Notified Bodies will likely tell you to apply EN 18031 (see "Can I Use Other Standards?" below). This makes EN 18031 essentially the only standard suited for the RED DA.

What Do "Restrictions" Mean?

Although EN 18031 standards are harmonized, they have been harmonized with restrictions. Under certain conditions, they do not confer presumption of conformity — meaning if your equipment satisfies one of these conditions, self-assessment is not possible and you will need to involve a Notified Body. Details are in the Official Journal of the EU (OJEU) . In summary:

The consequences of these restrictions:

Where to Get EN 18031 Standards

This topic has been covered comprehensively by Steffen Zimmermann in his LinkedIn article, "How to access and comment on European harmonised Standards (hEN) for the Cyber Resilience Act (CRA)". As EN 18031 is harmonized, this article is directly relevant.

EN 18031 standards are available for free viewing (no download) via national standards bodies. You will need to create a free account. Access is through web viewer only — to download, you must purchase from national organisations. Here are free access links for EN 18031-1:

Can I Use Other Standards for RED DA Compliance?

We often hear: "Manufacturers can choose any standards for RED DA compliance, such as ETSI EN 303 645 or IEC 62443-4-2." It is true that EU regulations do not mandate the use of specific standards. However, in practice, these standards are not suitable for this purpose — and using them is a misconception which can be very costly.

There is currently no established method for translating the essential requirements of the RED DA into the frameworks of EN 303 645 or IEC 62443-4-2. As a result, compliance with these standards alone does not provide presumption of conformity (since they are not harmonized), and additional work is needed to address gaps. There is no recognized industry approach to demonstrate these gaps have been adequately filled, rendering these standards effectively unusable for RED DA compliance. While EN 18031 provides a "mapping" in its Annex for these standards, it is not sufficient — even the TIC Council cautions against its use.

Based on this experience, we also advise caution regarding claims that "you can use any standards" for the upcoming Cyber Resilience Act (CRA). We strongly recommend adhering to official harmonized standards whenever possible.

The "Asset-Based" Approach of EN 18031

The three standards follow an "asset-based" approach — they focus on the protection of assets. As stated in the introduction of the EN 18031 standards: "The security requirements presented in this baseline standard are developed to improve the ability of radio equipment to protect its security and [network/privacy/financial] assets against common cybersecurity threats and to mitigate publicly known exploitable vulnerabilities."

Assets can be generalised as:

Data in equipment whose access, manipulation or disclosure can impact the equipment.

When assets are compromised, this can lead the equipment to no longer fulfil a given essential requirement. Consequently, most EN 18031 requirements are about having security measures to protect these assets.

All three standards cover security assets, as well as another asset category specific to each:

The relationship between the asset categories and their types can be represented as follows. Asset categories encompass at least two types:

1. 1. Function
2. 2. Function configuration (or parameters in the context of security assets).

Function configurations define the behavior of functions. Privacy and financial assets include a third type,

3. 3. Data/information, which is processed by functions.

Both function configuration and data/information can be classified as:

Security functions are of special importance since they are used to protect all four asset categories. While used across all three standards, they are defined differently in each — since they fulfil different security goals in relation to the asset type.

How Can I Identify Assets?

Applying EN 18031 calls for the systematic identification and documentation of assets. This topic is expansive, so Zealience has published dedicated articles with detailed explanations and examples on each asset type, as well as techniques and tools to identify them:

Mechanisms and Requirements

The table below outlines the mechanisms of the EN 18031 standards and their respective requirements. In total, EN 18031 encompasses 14 mechanisms, which are further divided into 48 specific requirements.

At first glance, it may appear that there are many overlapping mechanisms and minimal differences among the standards. However, there are crucial nuances and intricacies that you need to be aware of, especially when applying multiple standards.

For example, SCM-1 is required for all three standards. However, EN 18031-3 works differently from EN 18031-1 and -2. While EN 18031-3 does not allow for any exceptions to permit the communication of assets over non-secure communication mechanisms, EN 18031-1 and EN 18031-2 do. Therefore, you need to be careful when applying multiple standards even when the requirement name is the same across the standards.

Applicability of Mechanisms and Requirements

Some mechanisms and requirements apply only to specific equipment types. For example:

• · Network Monitoring Mechanisms (NMM) and Traffic Control Mechanisms (TCM) — Only apply to network equipment, defined in EN 18031-1 as "equipment that exchanges data between different networks used to permanently connect directly other devices to the internet."
• · Access Control Mechanisms (ACM-2 to ACM-6) — Only apply if the equipment is classified as toy and/or childcare equipment (according to EN 18031-2).

Dependency of Requirements

When a mechanism has multiple requirements (e.g., SSM-1, SSM-2, SSM-3), it is often the case that the first requirement dictates whether the remaining ones are needed. In other words, if the first requirement (e.g., SSM-1) is deemed not applicable, it renders subsequent requirements (e.g., SSM-2, SSM-3) unnecessary. This is the case for the mechanisms ACM, AUM, SUM, SSM, SCM, LGM, UNM and CCK.

Exceptions to Dependency of Requirements

Some mechanisms have self-contained requirements where the above does not apply. This is the case for DLM, RLM, NMM, TCM (each has only one requirement). GEC requirements are also self-contained since they concern general equipment capabilities (hence the abbreviation) meant to be independently applied. For example:

The CRY mechanism is unique — it is "transversal," meaning CRY-1 applies across other mechanisms. It mandates that cryptography used by ACM, AUM, SUM, SSM or SCM must follow best practice.

Anatomy of a Requirement

Each requirement of EN 18031 consists of several sections and subsections:

The Assessment Criteria section is organised into the following subsections:

Assessment objective and Implementation Categories (IC)

The Assessment objective simply states which requirement is assessed (e.g., "The assessment addresses the requirement ACM-2") and is not very useful in itself.

Implementation Categories (IC) are common implementation methods that can be used to meet a requirement. Not all requirements provide ICs (in EN 18031-1, 13 out of 33 requirements have ICs). Between 2–5 ICs may be proposed per requirement. For example, AUM-6 "Brute force protection" allows one of four ICs (or any combination):

Required Information (E.Info identifiers)

The Required Information subsection lists what must be documented in your technical documentation. All information must be provided under a structured identifier following the pattern [E.Info.REQ.ITEM.SUBITEM], where:

To illustrate, let's look at the Required Information of ACM-1 — the first requirement of EN 18031. Each identifier is accompanied by a description of the information to be documented, as shown below.

Moreover, certain identifiers are conditional, meaning that you should only document them if their respective condition(s) is met. The condition is expressed within parentheses in front of the identifier.

We list in the table below all the identifiers for ACM-1 in the context of EN 18031-1, and indicate which ones are conditional. In the context of the other standards' focus, the identifiers related to network assets will be replaced by privacy assets in EN 18031-2 and financial assets in EN 18031-3.

The two identifiers [E.Info.DT.ACM-1] and [E.Just.DT.ACM-1] refer to the Decision Tree of ACM-1, depicted in the figure below.

Decision Tree (DT)

Each requirement in EN 18031 standards has a DT to determine whether the requirement is met or not, or not applicable. All DTs start with the equipment and narrow down on specific items in scope of the requirement (we elaborate later on the concept of "items in scope of requirements"). For each item in scope, we have to go through the DT, i.e., answer the Yes/No questions in the Decision Node (DN) until we exit the DT. Based on the exit node, the DT result can be Not Applicable, Pass or Fail. These results will be used later for conceptual assessments.

The standards require the documentation of the path through the DT under the identifier [E.Info.DT.REQ] and a justification under [E.Just.DT.REQ]. Pursuing our example with ACM-1, the standard reads:

• · [E.Info.DT.ACM-1]: "Description of the selected path through the decision tree in Figure 1 for each security asset and network asset documented in [E.Info.ACM-1.SecurityAsset] and [E.Info.ACM-1.NetworkAsset] where paths to access the asset exists, respectively."
• · [E.Just.DT.ACM-1]: "Justification for the selected path through the decision tree documented in [E.Info.DT.ACM-1], […]"

Depending on the exit node, the justification in [E.Just.DT.REQ] must be based on specific information. For most requirements, the justification for exit nodes leading to a DT result of Not Applicable must be based on one of the conditional identifiers.

In order to find which identifier must be used, refer to the text of the DN and identify the matching condition in the Required Information. For example, let's consider equipment that is deployed in an environment protected by a firewall. Considering a security asset, we can answer Yes to DT.ACM-1.DN-2 "Do the physical or logical measures in the targeted operational environment limit the accessibility to authorized entities?". You can then look at the Required Information to find the corresponding condition. Under [E.Info.ACM-1.SecurityAsset.Environment], we read "(if access control by the equipment is absent because physical or logical measures in the equipment's targeted operational environment exist, that limit accessibility to authorized entities)". Consequently, the justification in [E.Just.DT.ACM-1] must be based on the identifier [E.Info.ACM-1.SecurityAsset.Environment].

Although it may be a tedious process, it is essential to provide proper justification for the DT under the correct identifier. This is because the correctness of the justification is one of the assessment criteria for conceptual assessment to be later conducted.

Defence-in-depth: documenting beyond the exit node

Although reaching an exit node ends your DT path, you can continue documenting remaining decision nodes to capture multiple layers of security (defence-in-depth). For example, if an asset is protected by a logical measure (firewall) AND access control mechanisms, you can document:

This does not change the DT result (remains Not Applicable), but provides two benefits:

• 1The technical documentation more accurately reflects the actual implementation — stopping at DN-2 would omit the access control mechanisms that actually exist in the equipment.
• 2When engaging a Notified Body, it provides a "fallback" position: if the NB disagrees with your firewall/logical measure justification, they can revert to the access control mechanisms documented anyway.

The remaining three subsections cover the assessment procedure of EN 18031. We will unpack them in greater detail later in this article. For now, it is enough to know that each requirement (with a few exceptions) must be evaluated based on three types of assessments:

• · Conceptual assessment: Documentation review exercise to verify that your technical documentation is correct, with a particular focus on the justification of the DT discussed above.
• · Functional completeness assessment: Functional testing to verify whether the technical documentation is complete. The tests to be performed are focused on verifying that what is documented (e.g., assets, security mechanisms) can indeed be found in the equipment and that any discrepancies can be flagged (e.g., finding assets in the equipment not declared).
• · Functional sufficiency assessment: Functional testing to verify that the security measures described in the technical documentation are indeed implemented as documented and that they are sufficient to fulfil their security goals.

These three assessment subsections are divided into the following four points:

• · Assessment purpose: Explains the reason behind the assessment.
• · Preconditions: Provide some specific information about any conditions to be met prior to starting the assessment. For example, "The equipment is in an operational state". Only used for functional assessments.
• · Assessment units: What the tester must do to perform the assessment.
• · Assignment of verdict: How the tester should assign the verdict of Pass, Fail or Not applicable for the assessment.

Relationship between Requirements and Assets

Since the requirements of EN 18031 focus on the protection of assets, there is a strong relationship between the requirements and assets. For example, SSM-1 concerns assets that are stored persistently on the equipment. This means that you may have to apply SSM-1 (and subsequently SSM-2 and SSM-3) for each asset that is stored, while the other assets can simply be ignored. Understanding these relationships is critical as they dictate which requirements must be met to demonstrate compliance with the standards.

To illustrate some of these relationships, let's say that we are applying EN 18031-1. We need to consider security and network assets and identify those that are in scope or out of scope of a given requirement. We say that an asset is in scope of a requirement when it meets a certain condition we call a scoping condition (not an official term).

For example, ACM-1 requirement concerns the assets that are accessible by entities ("entities" are defined as "user, device, equipment or service"; see note below). Considering the scoping condition to be "accessible by entities", all the assets that are accessible by entities are "in scope" of ACM-1.

Another example is SCM-1 which targets assets that are communicated with other entities via network interfaces. If we have a password (security asset) that is communicated over a Wi-Fi interface, it will be in scope of SCM-1. Overall, this could lead to a situation similar to the figure below.

How to Identify Applicable Requirements to Assets

Zealience has created and made freely available (through Zealience GitHub) a table highlighting all scoping conditions and the relationship between requirements and assets across all three EN 18031 standards. Use it to quickly identify for each asset type the related scoping conditions and which requirements it may need to fulfil. We say "may" because, once an asset is in scope of a requirement, further conditions must be checked via the Decision Trees before confirming applicability.

The most prevalent scoping conditions for assets in EN 18031 are:

There are many more requirements, and some do not concern assets. For example, LGM-1 to LGM-4 apply to logging mechanisms and log events. Overall, these relationships make it very difficult to know upfront what requirements must be fulfilled — you need to draw up the full list of assets and interfaces first.

Creating EN 18031 Technical Documentation

What is EN 18031 Technical Documentation?

The EN 18031 technical documentation is the collection of all Required Information expected by the standards — descriptions of all items and documentation of Decision Trees for all relevant requirements. Assessments cannot be performed without complete technical documentation, whether assessments are conducted internally or externally.

What is the Format for EN 18031 Technical Documentation?

The standards do not provide any format guidance — the only instruction is to document information under the right E.Info identifier. This brings two issues: it is difficult for first-time manufacturers to get started, and Notified Bodies have a difficult time reviewing a broad variety of formats from customers.

To address this, Zealience has created and published a free template on Zealience GitHub — an Excel spreadsheet organised across tabs, one per item to be documented for a given requirement. For example, ACM-1 calls for documentation of security, network, privacy and financial assets accessible by entities (depending on the standard applied). Each tab is organised into four parts:

Zooming in the first part, we arrange the identifiers in columns. Some identifiers are marked as conditional for the reasons explained previously in the section "Anatomy of a Requirement".

The second part contains the DT nodes. The documentation of the path through the DT requires to answer Yes or No to each of them. Based on the exit node, a justification needs to be inputted in the third part, and the DT result can be set accordingly in the fourth part.

How to Create EN 18031 Technical Documentation

There are two approaches to create your technical documentation:

1. 1. Software-assisted approach with Z-CMS 🚀
2. 2. Manual approach

Regardless of the approach, completing technical documentation is an iterative process. You will likely revisit declared assets and mechanisms as assessments may reveal items that were forgotten. Update the documentation accordingly before returning to the assessment.

Managing Vulnerability for GEC-1

It may not be widely known that the RED DA mandates vulnerability management. When manufacturers begin applying EN 18031, many are surprised to discover the specific vulnerability management requirement: GEC-1.

How to Manage Vulnerability for EN 18031

GEC-1 requires that equipment must not contain publicly known exploitable vulnerabilities that could affect assets if exploited. However, vulnerabilities meeting one of the following conditions are exempted:

To fulfil GEC-1, manufacturers must assemble documentation that includes:

• The assets in the equipment (security, network, privacy and/or financial assets, depending on the standard applied)
• The software components (and their version) that affect these assets
• The hardware components that affect the assets
• The publicly known exploitable vulnerabilities in the software and hardware, including the source of vulnerability information

How to Create GEC-1 Technical Documentation

Manually creating GEC-1 technical documentation is near-impossible given the scale. An automated approach is essential.

Performing EN 18031 Assessments

EN 18031 assessments verify both the "normal" technical documentation and the GEC-1 specific technical documentation. Through these assessments, you verify the documentation is complete, DTs are properly justified, and security measures are in place and effective as documented.

Documents Relevant for Assessments

There are four documents involved in the assessment phase:

1. 1. Technical documentation
2. 2. GEC-1 Technical documentation
3. 3. Test plans
4. 4. Test reports

The assessment relies on both types of technical documentation as inputs. Conducting assessments without them is not possible, as they outline what needs to be assessed. As stated in Annex A of EN 18031, "the assessments depend on the information to be provided as part of the manufacturer's technical documentation."

Before starting the assessment, you will create a test plan detailing the test items in scope of each assessment unit to be executed. Once the assessment is completed, you will create a test report detailing the results and explanation of the assessments performed.

Three Types of Assessments

We discussed previously that the requirements of EN 18031 have three types of assessments to be performed (with a few exceptions):

1. 1. Conceptual assessments
2. 2. Functional completeness assessments
3. 3. Functional sufficiency assessments

These assessments require you to test specific items documented in the technical documentation, which we refer to as test items. The test items can be found in the description of the "Assessment Units" section corresponding to each type of assessment (usually starting with "For each …").

To understand how each assessment type works, let's take an example of ACM-1 in the context of EN 18031-1 and examine how they look.

How to Create Test Plans

Before commencing assessments, draft a test plan outlining what must be tested. Although EN 18031 does not explicitly mention test plans, creating them is standard practice in the Testing, Inspection, and Certification (TIC) industry. No professional tester would begin an assessment without one.

How to Conduct Conceptual Assessments

As discussed earlier, the purpose of the conceptual assessment is to verify the accuracy of the technical documentation. The standards require you to check three conditions for each test item:

1. 1. The DT result must be PASS or NOT APPLICABLE,
2. 2. A justification must be provided, and
3. 3. The justification is correct.

For example, referring to the GEC-2 requirement, you can see below how the documentation of the conceptual assessment can be done in our test plan. You can simply follow the instructions provided and perform the necessary actions accordingly.

How to Conduct Functional Completeness Assessments

The goal of this assessment is to verify that the technical documentation is complete. To achieve this, you must "functionally" check the equipment to identify any missing items. You can think of functional assessment as "penetration testing," where you try to uncover any assets or mechanisms before comparing them with those already documented in the technical documentation.

For example, in the case of GEC-2, you must identify whether any network interfaces or network services are exposed in the factory default state of the equipment that are not necessary for its setup or basic operation. To do this, you can utilise tools such as network scanners (e.g., Nmap) to scan the network interfaces and detect any exposed services. Any discrepancies between the discovered services and those documented will result in a verdict FAIL.

How to Conduct Functional Sufficiency Assessments

The purpose of this assessment is to verify that the security measures described in the technical documentation are implemented as documented and are sufficient to achieve their security goals. To perform these tests, you must refer to the assessment units outlined in the standards. Specific tests may also be required depending on the Implementation Category (IC) used to meet a requirement.

For a straightforward example, consider AUM-6, which focuses on brute-force attack prevention. This requirement mandates that authentication mechanisms must be resilient against such attacks. Suppose we have an authentication mechanism documented as implementing a 1-second delay between failed authentication attempts (aligned with the IC [IC.AUM-6.TimeDelay]). In this case, you will measure the time between consecutive failed authentication attempts to verify that the delay is indeed 1 second, as expected by the assessment units.

Converting the Test Plan to a Test Report

All assessment results must be documented in a test report — one of the mandatory documents for EN 18031 compliance. Together with the technical documentation and GEC-1 technical documentation, this comprises everything needed to demonstrate EN 18031 compliance. Assuming all assessments yield a verdict of Pass (or Not Applicable), you can update your EU Declaration of Conformity (DoC) by adding the applicable EN 18031 standard(s) and affix the CE marking.

Ensuring Compliance for All Equipment Placed on the EU Market

The EU Blue Guide (Section 2.3) defines "placed on the market" as: a product supplied for distribution, consumption or use on the Union market in the course of a commercial activity (whether in return for payment or free of charge) for the first time.

A frequent mistake is to think this concept applies to a product type or family as a whole — it does not. It applies to each individual product, regardless of whether manufactured in series or as an individual unit.

Now that we are post-August 2025, every radio equipment unit must comply with the RED DA when placed on the EU market (if in scope).

Keeping the Documentation Up to Date

The RED requires that "the technical documentation shall be drawn up before radio equipment is placed on the market and shall be continuously updated" (RED Art. 21(2)).

Impact of Product Updates on Compliance

Even after placing equipment on the market, technical documentation must be kept up to date for subsequent units. Consider: you launch version v1, begin placing units on the market, and continue managing vulnerabilities per GEC-1. When you update the firmware to add features and fix bugs, these changes must be reflected in the documentation (e.g., new assets introduced, mechanisms modified). Depending on the scope of changes, you may need to reconduct assessments — scoped only to the modifications made. Once documentation is complete and assessments are successful, you can place version v2 on the market.

Importance of Versioning Documentation

Documentation is closely linked to a specific equipment version. The EU Blue Guide states that RED technical documentation and the EU Declaration of Conformity must be retained for 10 years after the radio equipment has been placed on the market. Market Surveillance Authorities can inspect equipment and request the documentation corresponding to the version inspected — so maintaining separate documentation versions is essential.

Non-Compliance and Market Surveillance Authorities

Equipment placed on the market can be scrutinised by Market Surveillance Authorities (MSAs), established by EU Member States and empowered to "take corrective measures on non-compliant radio equipment" (EU RED DA). If an MSA has valid reasons to believe equipment in scope of the RED poses risk to individuals or public interests, it will assess compliance with all relevant essential requirements. Manufacturers must cooperate during this evaluation.

The MSA will request RED technical documentation. If documentation contains inadequate data or insufficient means to demonstrate compliance, the MSA may request manufacturer-funded testing through an accredited body within a specified timeframe.

If the MSA determines equipment fails to meet essential requirements, it will instruct the manufacturer to:

• Implement corrective measures to ensure compliance
• Remove the radio equipment from the market (withdrawal from sales and distribution channels)
• Carry out a recall within a reasonable timeframe

Corrective action is determined by the level of risk and must align with proportionality. Non-compliance with essential requirements should generally be treated as "substantial non-compliance." Further reading: EU Blue Guide, Section 7.4.2.2. Different types of non-compliance and actions.

The list of MSAs can be found on the European Commission's market surveillance website . Filter by Directive / Regulation and select the RED.

Looking Ahead to the CRA

Congratulations! 🎉 You've successfully navigated the journey to achieving RED DA compliant equipment! Despite some suggesting "What's the point of the RED DA? It will be superseded in December 2027 when the CRA takes effect," keep the following points in mind:

Approximately 2/3 of the requirements of the CRA horizontal standard correspond to those in EN 18031. Specifically:

Zealience has published a mapping highlighting EN 18031 requirements being reused to support CRA essential requirements — available on Zealience LinkedIn.

GEC-1 is expected to be reused as-is. This means all processes you put in place for vulnerability management will remain relevant under the CRA. When fulfilling GEC-1, you already fulfil the first CRA essential requirement.

Beyond EN 18031, the best way to prepare for the CRA is to look into its text and pay attention to the process-based requirements. Even without standards, there is already much that can be done.

Frequently Asked Questions

Common questions about EN 18031, the Radio Equipment Directive Delegated Act, technical documentation, assessments, and compliance maintenance.