EN 18031 is the harmonised standard supporting RED Directive Article 3.3 cybersecurity requirements – mandatory from 1 August 2025. Wireless products with network connectivity exported to the EU must meet this standard. Many manufacturers complete testing and obtain reports – then assume the job is done – ignoring post-market ongoing compliance obligations. If market surveillance finds security vulnerabilities, products face circulation restrictions and remediation penalties.
Key clarification: there is no independent "EN 18031 certificate". It is the cybersecurity assessment component within the overall CE RED compliance. If you go through an NB Module B type-examination, the NB issues a type-examination certificate – which the industry commonly calls "EN 18031 certification". The standard has three parts: EN 18031-1, -2, -3 – choose the appropriate part based on product use.
1.1 No statutory uniform validity period
Test reports and NB-issued type-examination certificates have no statutory expiry. They remain valid as long as: the standard has not been updated, the product hardware and security-relevant firmware are unchanged, and the security architecture remains as tested.
But this does not mean you can ignore it after obtaining the report. Under EU Market Surveillance Regulation (EU) 2019/1020, authorities can randomly test products on the market at any time. If known exploitable vulnerabilities are found post-market and the manufacturer fails to remediate, the product will be required to be withdrawn – even if the certificate is still valid on paper.
1.2 Standard version updates – must track
The current version is EN 18031-1/-2/-3:2024. CENELEC will issue amendments in the future – new applications will use the updated version; existing certificates will have a transition period. Historically, EU harmonised standard transition periods are 12–24 months – the exact duration awaits official EC notification. Companies must track revision updates – do not wait until the transition period ends to discover you cannot meet the new requirements.
1.3 Firmware version change assessment
Major firmware iterations – if they affect the security architecture (encryption protocols, authentication logic, secure boot, OTA verification) – require a change assessment and potentially supplementary difference testing. UI or general business-function changes that do not touch security modules can be documented internally. If you hold an NB type-examination certificate, even if no retest is required, most NBs will request a change notification – confirm the process with your NB in advance.
2. Post-Market Ongoing Compliance Obligations
2.1 Vulnerability monitoring and response
EN 18031 requires manufacturers to establish an ongoing vulnerability monitoring process. After market placement, continuously track security advisories for the operating system, open-source components, and third-party libraries used. When a public vulnerability affecting the device is disclosed, a remediation patch must be issued within a reasonable timeframe.
Note: ENISA's suggested 30-day for severe, 90-day for high-severity vulnerabilities are industry recommendations – not mandatory standard clauses. Companies must establish internal vulnerability grading, handling, and traceability processes – with written documentation for audit.
2.2 Secure update channel requirements
Remediation patches must be distributed through a reliable channel. For OTA-capable devices, update packages must include integrity and authenticity verification – to prevent malicious firmware injection. Devices without remote upgrade capability must provide a traceable offline upgrade solution.
All security update records must be fully archived – vulnerability description, affected models, fix version, and release date. These logs are the most important evidence of ongoing compliance during market surveillance.
2.3 Supply chain security obligations
Manufacturers must manage upstream supply chain security – retaining security assessment documentation for third-party modules and chips. At the procurement stage, include security patch support periods in supply contracts. Common trap: the chip supplier discontinues a product and stops issuing security patches – but the end product is still sold in the EU. You cannot transfer all security responsibility upstream – the manufacturer bears primary responsibility for end-device security. Define EOL security support periods at the product planning stage – and clearly state them in the product documentation.
3. DoC and Full Technical Documentation – Ongoing Maintenance
3.1 DoC updates
EN 18031 compliance is part of the RED technical documentation. After major security firmware changes, security architecture adjustments, or standard version upgrades – the CE DoC must be updated – the new declaration must be signed before products are placed on the market.
3.2 Full technical documentation – continuous maintenance
Required documents: security risk assessment, threat model, encryption scheme description, vulnerability handling records, security update logs, and third-party component lists. Documents are not a one-time submission – every change requires corresponding revisions. Authorities have the right to request full technical documentation within 10 working days – missing or outdated documents = non-compliance. RED also requires that technical documentation be retained for at least 10 years from the last batch placed on the market.
3.3 EU Authorised Representative (EC-REP) responsibilities
The EC-REP is responsible for holding technical documentation copies within the EU and cooperating with regulatory checks. When changing EC-REP, aim to complete document transfer and handover within 30 days (industry practice, not a statutory clause) – and ensure that during the transition, someone is available to respond to regulatory inquiries. The EC-REP contract must clearly define document retention and inspection cooperation responsibilities.
4. Common Industry Pitfalls
4.1 Stopping vulnerability monitoring after certification
Lab tests only prove the security level of the sample at that time. New vulnerabilities in open-source components are continuously disclosed – a compliant device today may have high-severity issues in a few months. Without ongoing monitoring, if surveillance finds known vulnerabilities left unpatched – the product will be restricted from sale.
4.2 OTA channel – functionality only, no security verification
OTA is a high-risk attack surface. Passing security validation at certification, but later firmware iterations relaxing signature/integrity verification – is ongoing non-compliance. Every OTA mechanism change requires internal re-validation.
4.3 Supply chain security promises – paper only
The procurement contract states 5-year security patch support – but the supplier stops maintenance after two years. Verify upstream support capabilities before committing – to avoid having no patches available after market launch – facing compliance risks.
Important note: EN 18031 is a RED-specific cybersecurity requirement – it runs parallel to the Cyber Resilience Act (CRA) – separate scopes, separate effective dates – do not confuse them when planning.
For EN 18031 validity and ongoing compliance, contact BlueAsia at 13534225140 (King) or king.guo@cblueasia.com.
Related News
