The expensive EN 18031 mistakes get made at design review, months before anyone books electromagnetic compatibility and radio testing. A payment-capable device leans on the standard’s secure update criteria and finds they carry no presumption of conformity at all. A wearable ships with optional password setup and loses the presumption for its whole part. Both cost little to decide and a great deal to unwind. Since 1 August 2025 connected radio equipment on the European Union (EU) market has had to meet the cybersecurity essential requirements of the Radio Equipment Directive (RED). EN 18031 is the harmonised route to them.
This guide covers which parts apply to which equipment, which four restrictions send a product to a Notified Body, and why both are decided long before assessment.
What Is EN 18031?
EN 18031-1:2024, EN 18031-2:2024, and EN 18031-3:2024 each address a different RED Article 3(3) cybersecurity requirement, and together they give radio equipment a presumption of conformity with those requirements. Commission Delegated Regulation (EU) 2022/30 of 29 October 2021 activated them for specified categories of radio equipment; Delegated Regulation (EU) 2023/2444 then postponed the application date to 1 August 2025. Commission Implementing Decision (EU) 2025/138 cited the three parts in the Official Journal of the European Union (OJEU) in January 2025, ahead of that date. From 1 August 2025 market-surveillance authorities can evaluate products and require corrective action where they do not comply.
How EN 18031-1, -2, and -3 Map to the RED Essential Requirements
Each part covers one essential requirement and its protection objective, and the table below aligns those objectives with the applicable equipment and mechanism families.
| EN 18031-1:2024 | EN 18031-2:2024 | EN 18031-3:2024 | |
|---|---|---|---|
| RED Objective | Network protection | Personal data and privacy | Protection from fraud |
| In-Scope Equipment | Any radio equipment that communicates over the internet, directly or through a gateway | Internet-connected, childcare, toy, or wearable radio equipment, in each case only where it can process personal, traffic, or location data | Internet-connected equipment that lets the holder transfer money, monetary value, or virtual currency |
| Part-Exclusive Mechanisms | Resilience Mechanism (RLM), Network Monitoring Mechanism (NMM), Traffic Control Mechanism (TCM) | Logging Mechanism (LGM), Deletion Mechanism (DLM), User Notification Mechanism (UNM) | LGM (shared with Part 2), nothing unique to Part 3 |
All three parts share eight mechanism families: access control (ACM), authentication (AUM), secure update (SUM), secure storage (SSM), secure communication (SCM), confidentiality of cryptographic material (CCK), general equipment capabilities (GEC) and cryptography (CRY). Each part then adds its own: resilience, network monitoring and traffic control for Part 1, logging, deletion and user notification for Part 2, and logging alone for Part 3.
Which EN 18031 Parts Apply to Your Equipment
Applicability is additive, with Part 1 the baseline for anything that reaches the internet. Part 2 covers internet-connected, childcare, toy and wearable radio equipment, but only where it can process personal, traffic or location data. The childcare, toy and wearable categories qualify whether or not they connect. Part 3 applies where the equipment handles monetary value or virtual currency. Two exclusions sit outside that test, and which one applies decides whether equipment escapes all three requirements or still needs Part 1 scoping:
- Equipment outside all three parts: Medical devices under EU MDR and the In Vitro Diagnostic Regulation (IVDR) are outside all three requirements.
- Network-protection-only equipment: Civil aviation equipment, motor vehicles under ISO 26262 and electronic road toll systems stay in scope for network protection but are excluded from the privacy and fraud requirements.
Everything else resolves through the test above. The table works it against three devices, the middle one landing all three parts at once.
| Applicability | Industrial environmental sensor | Payment-capable smartwatch | Non-internet-connected wearable |
|---|---|---|---|
| Internet connection | Yes | Yes | No |
| Other triggers | None described | Wearable and payment capabilities | Wearable status, and processes personal data |
| Applicable parts | Part 1 | All three parts | Part 2 |
The manufacturer decides how many parts apply, supported by a documented risk assessment. The gateway case is where we see that decision go wrong most often. A Zigbee sensor reaching the internet only through a hub still communicates over the internet for Part 1 purposes. A short-range protocol establishes no exemption by itself, so we have to document the indirect connection in the scoping decision.
Scope EN 18031 Before You Freeze the Hardware Design
The design choices the restrictions turn on are settled months before electromagnetic compatibility and radio testing. A design-phase scoping checklist should cover:
- Credential setup: Decide at design review whether password creation is mandatory, before interface and firmware behaviour are fixed.
- Update architecture: For a device handling monetary value, decide at architecture review how secure update will be demonstrated, since the Part 3 assessment criteria for it carry no presumption of conformity.
- Asset inventory and part scoping: Classify the assets and fix the applicable parts before the hardware design freezes.
Leave any of the three unresolved and the cost arrives later as unplanned firmware and interface work, after the architecture is committed.
When EN 18031 Self-Declaration Is Allowed and When It Isn’t
Module A self-declaration is available only when we apply the relevant EN 18031 part in full and trigger no OJEU restriction. Any one of the four restrictions attached to Implementing Decision (EU) 2025/138 removes the presumption of conformity for the part it touches. Three are conditional on a design choice. The fourth is not: for Part 3 the secure-update assessment criteria confer no presumption at all, so a device handling monetary value has to demonstrate secure update another way.
| Restriction | Rationale and guidance text | Skippable passwords | Parental controls | Secure update alone |
|---|---|---|---|---|
| Applies To | All three parts | All three parts | EN 18031-2 only | EN 18031-3 only |
| What Triggers It | The conformity claim relies on non-normative rationale or guidance text | The device lets users skip or bypass password setup under clauses 6.2.5.1 and 6.2.5.2 | A toy or childcare device doesn’t ensure parental or guardian access control | Always, for any Part 3 claim resting on the clause 6.3.2.4 secure-update criteria |
| Design Decision It Depends On | Whether the conformity argument leans on non-normative text | Whether credential creation is mandatory | Whether the access control model admits a guardian role | None available; the criteria confer nothing |
Partial application also sends the product to a Notified Body, as does an alternative standard such as European Telecommunications Standards Institute (ETSI) EN 303 645 or International Electrotechnical Commission (IEC) 62443. Two routes are open: EU type-examination plus conformity to type under Annex III (Module B plus C), or full quality assurance under Annex IV (Module H). The password restriction catches consumer products most often: optional authentication for out-of-box convenience loses the presumption outright, and retrofitting mandatory credential creation means unplanned firmware work.
Not every wireless product needs a Notified Body. Either way, the technical documentation and the Declaration of Conformity (DoC) must be retained for 10 years from market placement.
What the EN 18031 Technical File Has to Contain
The evidence package begins with a complete asset inventory. It separates security functions from security parameters, then catalogues network assets and, where the parts apply, privacy and financial assets. An incomplete inventory leaves holes in every verdict built on it.
For each requirement the file records the justified decision-tree path and its verdict of PASS, FAIL or NOT_ASSESSED. A missing or incorrect justification can itself produce a FAIL, so the rationale carries as much weight as the mechanism.
The test plan then runs in three tiers. Conceptual assessment checks each test item against its decision-tree result and its written justification. Functional sufficiency asks whether the implemented measures are adequate rather than merely present. Functional completeness looks for requirements with no documented test item at all. Surviving the first tier on paper and failing the second is the common outcome, because the second is the one asking whether the mechanism does what the file says.
Four records have to stay consistent across firmware revisions: the decision-tree justifications, the asset list, the vulnerability records and the test evidence. Holding them together is the work the requirements traceability matrix does. Every firmware revision reopens a review of all four, so review time grows with each record a team has to reconcile by hand. Grifols, which makes plasma-derived medicines and diagnostic instruments, reduced review cycles from 90 days to fewer than 30 days after moving its requirements and risk management processes into Jama Connect®.
How EN 18031 Hands Off to the Cyber Resilience Act (CRA)
Delegated Regulation (EU) 2026/339 repeals Delegated Regulation (EU) 2022/30 with effect from 11 December 2027, the date the main CRA obligations apply. It was published in the OJEU on 29 April 2026. Until then RED cybersecurity requirements stay in force, and market surveillance of products placed during the window continues after the repeal.
CRA Article 14 of Regulation (EU) 2024/2847 takes effect on 11 September 2026. From then we must report actively exploited vulnerabilities and severe incidents: an early warning within 24 hours, a fuller notification within 72 hours, then a final report. Until 11 December 2027 a manufacturer can be subject to both regimes at once, and the CRA commits the Commission to guidance for anyone caught by both.
The CRA states that its essential requirements include all the elements of the RED cybersecurity requirements. It also asks the Commission and the European standards bodies to take the EN 18031 standardisation work into account as the CRA’s own standards are drafted. Under CRA Article 69(1) an EU type-examination certificate keeps its validity until 11 June 2028 unless it expires sooner. Products already on the market by 11 December 2027 are caught only once they undergo a substantial modification, whichever conformity route they took.
The CRA’s own harmonised standards are not ready. As of September 2026 the EN 40000 horizontal series, developed under standardisation request M/606, is still in development and not yet cited in the Official Journal. Only the vulnerability-handling part carries a near-term adoption deadline, 31 October 2026. “The CRA is ultimately asking for something pretty specific, can you prove a clean line from the cybersecurity risk to mitigation to verification, and then keep that story intact as the product changes?” That is Patrick Garman, Director of Solutions & Consulting at Jama Software®, on what the regulation actually tests. Keeping that line intact through engineering change management is the part that outlasts the certificate.
How Jama Connect Supports EN 18031 Compliance
Jama Connect is a web-based requirements management and traceability platform, and it holds the EN 18031 technical-file relationships, including test results, as linked items. A Traceability Information Model (TIM) configured for the standard defines the required relationships per item type, so any ACM, AUM or SUM requirement with no linked test is flagged before the functional completeness assessment finds it. Trace Scores measure test coverage against that model as the file grows. Reuse and Sync holds the three parts’ asset sets against one design, and baseline compare shows what changed between the baselines of two releases, including a change to credential setup or secure update that could trigger a restriction.
The matrix then derives from live relationships without spreadsheet reconstruction each release. When a justification, asset or requirement changes, traceability flags every downstream item linked to it as suspect until an engineer assesses the change and updates the item or clears the flag. Jama Software calls this approach Live Traceability™, and suspect links keep the evidence behind each DoC aligned across the 10-year retention period.
Getting Started With EN 18031 Scoping
If firmware changes keep reopening cybersecurity scope, you can start a free 30-day trial and model one EN 18031 part against your own asset list.
Frequently Asked Questions About EN 18031
What determines how long an EN 18031 assessment takes?
Documentation readiness dominates. A file whose decision-tree justifications and asset inventory are already consistent clears conceptual review quickly. One assembled retrospectively stalls there before any testing starts. Product scope, tooling and the need for security architecture changes set the rest.
Can a certified radio module make the end product compliant?
No. The RED cybersecurity requirements can only practically be met by the integrated hardware and software, so the complete end product is evaluated as a whole. Module certification reduces work on the module’s own mechanisms, but requirements traceability still has to cover the finished product’s assets.
How does EN 18031 relate to ETSI EN 303 645 and IEC 62443?
EN 18031 carries informative mappings to both, so products already meeting ETSI EN 303 645 start with an advantage. The mappings don’t close the delta, and either standard alone still requires a Notified Body for RED conformity. Teams structured around IEC 62443 can reuse that structure for the shared ACM, AUM and SUM families and manage the delta through requirements traceability.
What happens to legacy products still sold on the EU market?
New units of a legacy design placed on the EU market on or after 1 August 2025 must meet the RED cybersecurity requirements, though units placed earlier aren’t affected retroactively. A design that cannot comply cannot keep shipping new units. Reuse and Sync can carry validated cybersecurity requirements and test cases into an updated legacy design while preserving product-specific changes.
