EN 18031 is surrounded by more misunderstandings than correct interpretations. Some treat it as a standalone certification; others confuse regulatory obligations with test items; still others expand the product scope beyond reality. This article clarifies everything.
1.1 Harmonised Standard – Not a Standalone Certification
EN 18031 is a harmonised standard under RED Directive 2014/53/EU Article 3.3 – not a standalone regulation. Passing the standard gives presumption of conformity – but it cannot be cited separately from RED.
There is no independent EN 18031 certificate. The test report is part of the RED technical documentation. For NB‑assessed products, the NB issues an overall RED type‑examination certificate covering 3.3 cybersecurity – no separate EN 18031 certificate.
1.2 Mandatory Date – Scope
The three EN 18031 parts became effective on 30 January 2025 and mandatory on 1 August 2025. This applies to new models first placed on the EU market after 1 August 2025.
Existing models with valid RED technical files – pure material changes not affecting security architecture – may not be required to retest – decided by the NB or manufacturer’s risk assessment. Not every new RED application needs a full retest.
2. The Three Sub‑Standards – Detailed Breakdown
2.1 ‑1 General Security – Don’t Over‑Apply
‑1 applies to radio equipment that has native capability to initiate internet communication – OTA, cloud reporting, remote control. The key criterion: can the device itself go online?
A standard TWS headset or basic Bluetooth band that only connects to a phone app and has no IP stack – does not trigger ‑1.
2.2 ‑2 Personal Data – Regulatory Obligation ≠ Test Item
‑2 builds on ‑1 – applies if the device collects location data, biometric data, or child data – or does on‑device voice/image capture.
Common confusion: the 72‑hour data‑breach notification is a GDPR regulatory obligation – not an EN 18031 test clause. The standard only requires an event‑logging mechanism – it does not make 72‑hour notification a lab‑testable item.
Parental‑control requirements: only devices that actually collect child data must implement clauses 6.1.3–6.1.6 – ordinary adult wearables are not subject to this.
2.3 ‑3 Financial Transactions – Not a Separate Regulation
‑3 applies to NFC payment terminals, hardware crypto wallets, etc. – SE hardware security mandatory, multi‑factor payment authentication mandatory.
However, 5‑year transaction‑log retention is a payment‑industry regulatory requirement (PSD2 etc.) – EN 18031‑3 does not have a clause mandating cloud backup or 5‑year storage – it cannot be used as a lab judgement criterion.
The three parts are not isolated in testing – ‑2 and ‑3 depend on the ‑1 whole‑device environment – hardware samples are shared; special‑purpose test cases are run separately.
3. Limitation Clauses and NB Mandatory Rules
3.1 Correct Interpretation of Limitation Clauses
(EU) 2025/138 has three limitation clauses – the Appendix Rationale has no legal effect. The core is Clause 2: if the device allows users to set no authentication (no password/PIN), then EN 18031 compliance cannot be presumed – NB assessment is mandatory.
Some online interpretations distort this – factory‑set default password with mandatory first‑boot change – that is not “allowing no password”. Getting this right can save unnecessary NB fees.
3.2 No Official “RED Device Classes”
The RED Directive has no official “Class 1/2/3” device classification – that’s industry jargon. NB assessment depends on whether the 2025/138 limitation clauses are triggered – not simply “automotive vs. payment”. Also, there is no statutory fixed 5‑year validity for certificates – that’s just some NBs’ internal practice.
4. Core Test Items
4.1 14 Security Objective Groups
The standard defines 14 groups – not all clauses are tested for every product. Labs eliminate inapplicable clauses based on product functionality. Devices without OTA – firmware‑update related clauses can be marked “not applicable”.
Key test items: firmware integrity verification, cryptographic key management, secure‑boot chain validation, logging, and TLS encryption.
4.2 Communication Security – TLS Version Priority
TLS 1.3 preferred – 1.2 allowed if necessary for compatibility – older versions prohibited. Labs check not only whether TLS is used, but also the version, cipher‑suite compliance, and certificate‑validation logic.
Secure‑boot misconception: EN 18031 does not mandate NIST SP 800‑193 as the sole criterion – it describes secure‑boot and anti‑rollback requirements, but labs may accept equivalent solutions.
4.3 Data Privacy Testing
‑2 checks whether the data‑collection declaration matches actual behaviour – if location data is collected but not declared – immediate failure.
5. External References and CRA Interactions
5.1 Reference Standards – Boundaries
External references are important – but the standard’s main text does not mandate specific documents as binding – labs may accept equivalent alternatives.
5.2 CRA Mutual Recognition – Not Guaranteed
CRA (EU) 2024/1384 becomes fully mandatory on 11 December 2027 (with extended transition for SMEs).
However: mutual recognition is not legally guaranteed – the EU has not issued formal guidance. Many NBs do not accept CRA reports as substitutes for EN 18031 testing – do not assume general items are automatically transferable.
6. Practical Implementation
6.1 Do a Gap Analysis First
Before submitting, compare your product’s current implementation against the 14 security objectives – identify gaps and fix them. Direct submission without gap analysis has a low first‑pass rate – this is a general industry observation.
6.2 Choose a Lab with Proven Experience
EN 18031 is new (mandatory from August 2025) – experienced labs are limited. Ask about the number of similar projects the lab has completed.
6.3 Integrate into Overall RED Certification
EN 18031 is one part of RED. Whether tests can run in parallel depends on lab capability – if the cybersecurity sample and RF sample have different firmware versions, they may not be fully synchronised.
For EN 18031 and RED cybersecurity, contact BlueAsia at 13534225140 (King) or king.guo@cblueasia.com.
Related News
