When companies first encounter EN 18031, most assume it's a single regulation — read the standard, pass the test, get the certificate. Then they open the document and discover three sub-standards, limitation clauses in a separate implementing decision, a cross-reference to an entirely different regulation called CRA, and external normative references that carry just as much weight as the standard itself. This article breaks down the entire EN 18031 regulatory architecture from the ground up.
EN 18031 is a harmonized standard under the RED Directive (2014/53/EU). Its legal function is to provide a "presumption of conformity" for the cybersecurity requirements set out in RED Article 3.3. In plain terms: if your product meets all applicable clauses of the relevant EN 18031 sub-standard, regulators presume your product complies with the corresponding RED requirement.
But there's a prerequisite that's easy to miss. The presumption of conformity applies only to the clauses that are relevant to your product. If your device doesn't process financial transactions, you don't need to comply with EN 18031-3. If it doesn't collect children's data, the parental control clauses in -2 don't apply. You don't have to complete all three sub-standards to enjoy the presumption of conformity — you just need to cover the ones that match your product's functionality.
The Three Sub-Standards and What Each One Covers
EN 18031-1:2024 — General Security Requirements
This covers all wireless devices with radio capability that can connect to the internet, directly or indirectly. The indirect part is where companies get caught. A device that has no public network module of its own but connects to a phone app via Bluetooth, and that app sends data to the cloud — that device falls under -1. Bluetooth fitness bands and wireless earbuds with companion apps are the most common offenders here.
EN 18031-1 defines 14 categories of security mechanisms, all of which must be tested if applicable. Failing a single applicable clause means the product fails -1. However, failing -1 doesn't invalidate -2 or -3 results — it just means the product can't meet the overall RED cybersecurity requirement. Each sub-standard's pass/fail is independent.
EN 18031-2:2024 — Personal Data Processing Requirements
This layers on top of -1. It applies when the device collects location data, biometric information, children's personal data, health metrics, or captures voice or images on-device. The core requirements: data minimization, encrypted storage, user access and deletion rights, and a 72-hour dual-notification obligation for data breaches — you notify both the affected users and the EU member state market surveillance authority. Notifying consumers alone doesn't satisfy the requirement.
One important boundary: only devices that collect children's data are subject to the mandatory parental control requirements in clauses 6.1.3 through 6.1.6. A regular adult fitness tracker doesn't need parental controls. Don't add unnecessary development cost by blanket-applying children's privacy features to all products.
EN 18031-3:2024 — Financial Transaction Requirements
This covers wireless POS terminals, NFC payment devices, hardware crypto wallets, and any device that handles monetary or virtual currency transactions. It mandates a hardware Secure Element (SE), transaction logs with dual local-plus-cloud backup retained for at least 5 years, and mandatory multi-factor authentication for payments.
A common misunderstanding about the three sub-standards: they're not tested in complete isolation. The -2 and -3 specialized test cases run on the same hardware sample as -1, sharing the test environment. Only the specialized use cases are tested separately. You don't ship three different sample sets to three different labs.
Inclusion Timeline and the Limitation Clauses
All three sub-standards were added to the RED harmonized standards list via Implementing Decision (EU) 2025/138, published in the Official Journal of the EU on January 30, 2025. The effective date was January 30, 2025, with mandatory enforcement starting August 1, 2025.
The Implementing Decision didn't just rubber-stamp the standards — it attached limitation clauses that fundamentally affect how you apply them. There are three key limitations:
First, the Rationale and Guidance annexes in EN 18031 have no compliance value. They're explanatory text, not normative requirements. Gap analysis and NB audits evaluate compliance based on the normative clauses only. Don't try to argue compliance using guidance text — it won't hold up.
Second, devices that ship with blank password login enabled and don't force a first-time password change are barred from the self-assessment path. They must go through NB third-party assessment. No exceptions.
Third, devices processing sensitive personal data or financial transaction data are recommended for NB assessment. The children's privacy and payment scenarios aren't two separate clauses — they're sub-scenarios under the same limitation. Read the limitation clauses alongside the standard text, not separately.
CRA Cross-Reference and Transition Rules
The Cyber Resilience Act (CRA), Regulation (EU) 2024/2847, is a separate piece of legislation from RED. It takes full effect on December 11, 2027. Between August 1, 2025, and December 10, 2027, both EN 18031 (under RED) and CRA run in parallel.
Here's where it gets nuanced. CRA compliance doesn't automatically exempt you from all of EN 18031. Only the overlapping general cybersecurity mechanisms can be mutually recognized. The -2 children's privacy provisions and -3 financial payment provisions have no direct equivalent in CRA — they remain under RED's scope. A children's smartwatch or wireless POS manufacturer who completes CRA compliance still needs to pass -2 and -3 separately.
After December 11, 2027, new wireless devices placed on the market fall under CRA rather than EN 18031. But products that were already certified and in continuous production before that date can continue under their existing EN 18031 compliance until the product is retired. No need to rush a CRA recertification for legacy products.
Exemptions and External References
The exemption list is straightforward. Original equipment manufacturer (OEM) automotive T-Boxes and infotainment systems fall under UN R155 and EU 2019/2144 — not EN 18031. MDR-regulated medical devices, EASA-regulated aviation equipment, purely local Bluetooth audio devices without OTA or data upload, and purely wired devices with no radio module are all exempt.
What trips companies up is the external normative references. These aren't suggested reading — they're mandatory evaluation criteria. Key management references NIST SP 800 series. TLS implementation references RFC 5246 (TLS 1.2) and RFC 8446 (TLS 1.3). Secure boot references NIST SP 800-193. If your product passes every EN 18031 clause but your TLS implementation doesn't meet the RFC requirements, or your key management doesn't satisfy NIST SP 800 guidelines, the lab will still fail you. The external references are part of the standard whether you read them or not.
One practical tip: when selecting a test lab, ask whether they have the capability to evaluate against the external referenced standards. Some labs only test against the EN 18031 normative text and don't dig into the RFC and NIST references. A report from such a lab might look clean but won't hold up under NB review or market surveillance scrutiny.
Summary
EN 18031 is not one standard but three — each covering a distinct domain under RED Article 3.3. The regulatory framework includes the harmonized standard itself, the limitation clauses in (EU) 2025/138, the CRA transition arrangement, and external normative references that carry equal compliance weight. Understanding how these layers interact is essential for determining which sub-standards apply to your product, which compliance path you can take, and what your ongoing obligations look like as the regulatory landscape shifts toward CRA.
For EN 18031 standards compliance consultation, contact BlueAsia Testing at 13534225140 (Benson).
相关新闻
