EN 18031 or ETSI EN 303 645: Which One Applies to Your Connected Product?

Your team already has an ETSI EN 303 645 assessment. The product has Wi-Fi, relies on a mobile app, and is due to launch in the EU. Can the existing report carry the RED cybersecurity work, or does the product still need EN 18031? 

The report may save work, but it can't answer a legal scope question it wasn't designed to answer. If the product is radio equipment covered by the RED cybersecurity requirements, the manufacturer still has to identify the applicable RED articles, select the relevant EN 18031 parts, check the Official Journal restrictions, and document the conformity route. 

The Choice Starts With The Claim

Control lists make the two standards look more interchangeable than they are. Both address passwords, software updates, secure communications, sensitive security parameters, exposed interfaces, software integrity, and personal data. That overlap is useful, but it sits below the decision that matters first: what must the manufacturer prove? 

For RED conformity, the answer begins with the product and the law. Four product facts drive the initial scope decision: 

• whether the product is radio equipment 

• whether it can communicate over the internet, directly or through other equipment 

• whether it processes personal, traffic, or location data, including the specific rules for toys, childcare equipment, and wearables 

• whether an internet-connected radio product enables transfers of money, monetary value, or virtual currency 

 Those facts select the applicable RED essential requirements and the relevant EN 18031 part or parts. 

More than one part can apply to the same product. Internet connectivity isn't required for every Article 3(3)(e) case. A Bluetooth wearable that processes personal data may fall under EN 18031-2 even if it doesn't communicate over the internet. 

ETSI EN 303 645 begins from a different question. It defines a cybersecurity and data-protection baseline for consumer IoT devices connected to network infrastructure and their associated services. Its product view can include the device, mobile application, cloud service, cloud storage, and relevant third-party APIs required for the intended functionality. 

That makes ETSI EN 303 645 valuable during product design, customer assurance, and consumer IoT assessment. It doesn't create a presumption of conformity for RED Articles 3(3)(d), (e), or (f), because it isn't cited in the Official Journal for those requirements. 

Why Similar Controls Can Still Produce Different Answers

Evidence transfer should pass three tests. Skipping any one of them can turn a useful report into false confidence. 

The claim test explains the legal difference. The boundary test explains why a cloud service can matter without becoming radio equipment. The traceability test explains why a report with the right title can still be unusable for the released product. 

A mapping can show that two clauses discuss secure updates. It can't establish that the same update mechanism, signing key, backend command path, failure behavior, and firmware version were assessed. Similarity is a search hint, not an equivalence decision. 

The useful unit of reuse is the individual evidence of an artifact, not the report. Its product version, boundary, test method, and original claim have to remain attached.

Build One Evidence Core, Then Add Claim-Specific Overlays 

When compliance is organized by standard, one folder is created for ETSI EN 303 645, another for EN 18031, and the same architecture diagrams, update records, interface lists, and test reports are copied between them. That structure creates duplication and makes evidence drift harder to see. 

A stronger operating model starts with a controlled product evidence core. It can contain: 

• the exact assessed hardware, firmware, app, backend, and market configuration 

• architecture and trust-boundary diagrams 

• radio, physical, logical, and service-interface inventories 

• assets, data flows, authentication paths, and access-control design 

• software-update, key-storage, secure-communications, and software-integrity evidence 

• vulnerability handling, protocol testing, penetration testing, fuzzing, and negative-test results 

• change records showing what was reassessed after a product or service update 

The EN 18031 layer then adds the RED scope statement, applicable essential requirements, selected EN 18031 parts, asset and mechanism decisions, decision-tree paths, Official Journal restrictions, and the Module A or notified-body route. 

The ETSI EN 303 645 layer adds the consumer IoT scope, associated-service boundary, implementation conformance statement, assessment method, and the result against its provisions and recommendations. 

Technical controls can be shared while the claims remain separate. This allows evidence to travel without allowing conclusions to travel with it. 

It also exposes a less obvious risk: evidence reuse is a configuration-control problem before it's a standards-mapping problem! A perfect crosswalk won't rescue a test report produced against a development build when the technical file covers a later release with a different app, backend, or enabled feature set. 

For a dedicated assessment route, see QIMA's ETSI EN 303 645 testing and compliance page.

Reuse EN 303 645 Evidence Without Importing The Wrong Conclusion 

An existing ETSI EN 303 645 assessment can shorten the EN 18031 project when the underlying artifacts are current and traceable. This sequence keeps the reuse decision controlled without creating another set of duplicate documents. 

ETSI is developing TS 104 120 to provide more specific guidance on combining ETSI EN 303 645 with EN 18031 and reusing evidence for internet-connected consumer radio equipment. As of 28 August 2026, it remains an early draft and isn't ready to serve as a current conformity reference. Its existence is still revealing: evidence reuse is a recognized standards problem, not an invitation to treat the two standards as interchangeable. 

Edge Cases That Expose The Scope Traps

• An Ethernet-only smart home hub may fit ETSI EN 303 645 while remaining outside RED if the marketed product has no intentional radio interface. The bill of materials matters. A Bluetooth commissioning interface or embedded radio module changes the RED analysis, even if customers rarely use it. 

• A Bluetooth wearable processing of health or location data may trigger Article 3(3)(e) without internet connectivity. Treating internet access as the only RED cybersecurity trigger would miss the specific wearable and personal data rule. ETSI EN 303 645 may also be relevant when the consumer product connects to network infrastructure and depends on associated services. 

• A cellular industrial gateway can remain within RED even though it's sold for professional or industrial use. ETSI EN 303 645, however, excludes products primarily intended for manufacturing, healthcare, or other industrial applications from its stated scope. Connectivity alone doesn't make it the right broader baseline. 

• A connected smartwatch with payments can engage EN 18031-1, EN 18031-2, and EN 18031-3. Where EN 18031-3 clause 6.3.2.4 applies, the Official Journal restriction removes presumption of conformity for that assessment criterion regardless of the design. The Commission guidance states that third-party conformity assessment is mandatory in that case. 

These examples show why product labels such as "connected," "consumer," or "industrial" aren't enough. Scope follows the marketed configuration, intended purpose, data, connectivity, and functions. 

When EN 18031 Changes The Conformity Route 

Applying a harmonized standard is voluntary. Manufacturers often choose EN 18031 because a full application can provide a presumption of conformity for the RED requirement it covers. That route has conditions, and the standards were cited with restrictions. 

• The sections named "rationale" and "guidance" are informative only. They don't create presumptions of conformity. 

• The password clauses don't provide a presumption when the implementation allows the user not to set and use any password. The Commission guidance says the restriction can be avoided when the manufacturer disregards that option and requires a password. 

• EN 18031-2 doesn't provide a presumption for the specified toy and childcare access-control cases when parental or guardian control isn't ensured. 

• Where EN 18031-3 clause 6.3.2.4 applies, the manufacturer doesn't benefit from the presumption that criterion and third-party conformity assessment are mandatory. 

Module A, internal production control, may be available when the relevant EN 18031 standard is fully applied, and the product isn't affected by the restrictions. The manufacturer still needs product-specific technical documentation, evidence, risk reasoning, production controls, and the EU declaration of conformity. If the relevant harmonized standard isn't applied, is only partly applied, or can't provide a presumption for the design, the RED conformity route requires notified-body involvement under Article 17 for those requirements.

The 2027 Date Belongs in Evidence Planning

The RED-delegated cybersecurity requirements have been in effect since 1 August 2025. Commission Delegated Regulation (EU) 2026/339 repeals Delegated Regulation (EU) 2022/30 with effect from 11 December 2027, when the Cyber Resilience Act becomes fully applicable. 

That date shouldn't be treated as a reason to postpone RED work for products placed on the EU market before the repeal. Market surveillance can still examine equipment placed on the market while the RED-delegated requirements are applied. A product program crossing the date needs a coordinated RED and CRA transition review based on when the product is placed on the market, the applicable obligations, and the configuration covered by the evidence. 

Well-controlled EN 18031 and ETSI EN 303 645 evidence may provide useful technical input to later CRA work, but it won't establish CRA conformity by itself. The same discipline still pays off: preserve product versions, evidence boundaries, decisions, and change history so later claims can be assessed without reconstructing the product's security story from scattered reports. 

Best Way to Plan Both Standards

Standards should act as claim-specific views of the same controlled product record, rather than separate collections of copied documents. Start by defining the claim and product scope. Build the evidence core around the released configuration. Add the EN 18031 and ETSI EN 303 645 reasoning that each conclusion requires. Reopen those decisions when the product, app, backend, or market configuration changes. 

That approach reduces duplicate work while preserving the distinction between technical overlap and legal effect. It also makes gaps visible earlier: before a certificate, technical file, or launch plan depends on evidence that belongs to another product version or another claim. 

If you're deciding which EN 18031 parts apply, whether a citation restriction changes the route, or how much of an existing ETSI EN 303 645 evidence set can be reused, start with a Free Cyberexpert EN 18031 scope and compliance review.