TL; DR - Top EN 18031 Compliance Queries
What is EN 18031 compliance?
EN 18031 compliance means your internet-connected radio equipment meets the cybersecurity requirements mandated by the EU Radio Equipment Directive (RED). The EN 18031 series consists of three standards covering network protection (EN 18031-1), personal data protection (EN 18031-2), and financial transaction security (EN 18031-3). Compliance has been mandatory for all new products placed on the EU market since 1st August 2025.
Which products must comply with EN 18031?
EN 18031 applies to three categories of internet-connected radio equipment:
- EN 18031-1 (Network Protection): All internet-connected radio equipment including industrial sensors, smart home devices, IoT gateways, Bluetooth wearables, Wi-Fi-enabled monitors, and Zigbee devices.
- EN 18031-2 (Personal Data Protection): Devices processing personal data including childcare monitors, wearables, fitness trackers, health monitoring devices, smart toys, and location-tracking equipment.
- EN 18031-3 (Financial Transaction Security): Devices enabling financial transactions or handling virtual currency including payment terminals, mobile payment devices, and cryptocurrency wallets.
If your device connects to the internet (directly or via another device), processes personal information, or handles financial transactions, EN 18031 compliance is required for EU market access.
Exemptions: Medical devices under MDR (EU 2017/745), aviation equipment under (EU) 2018/1139, transport equipment under (EU) 2019/2144, and non-connected products without radio modules.
Can I self-declare EN 18031 compliance or do I need a Notified Body?
This depends on whether your product triggers any "restricted clauses" in the harmonised standards.
Self-declaration pathway (faster, lower cost):
Available when your product fully complies with all applicable EN 18031 requirements without triggering restrictions. You complete a Declaration of Conformity (DoC) and affix the CE mark without third-party certification.Notified Body certification required when:
- Your product allows users to skip or bypass password requirements (clauses 6.2.5.1 & 6.2.5.2 in EN 18031-1)
- Childcare devices or wearables don't implement required parental access controls (clauses 6.1.3–6.1.6 in EN 18031-2)
- Financial transaction devices don't meet advanced encryption requirements (EN 18031-3)
- You cannot fully implement every requirement of the applicable standard
Partial compliance doesn't grant a presumption of conformity. If you meet 90% of the requirements but fail one restricted clause, you must involve a Notified Body.
When in doubt, assume Notified Body certification is required – it's the safer compliance pathway.
Does EN 18031 apply to individual modules or complete products?
EN 18031 certification applies to complete internet-connected radio equipment, not individual modules. Even if you use pre-certified secure modules (such as SESIP-certified components), the final product must be evaluated as a whole for compliance. Pre-certified modules simplify your compliance path but don't eliminate end-product certification requirements.
Table of Contents
Why Your EN 18031 Compliance Work is Actually Your CRA Head Start
EN 18031 compliance enforcement began on 1st August 2025. For UK manufacturers launching internet-connected radio equipment into the EU market, the regulatory environment has radically changed, and the competitive dynamics with it.
Current market reality:
- Products launching now: Must demonstrate full EN 18031 compliance or face market exclusion
- Competitive advantage: Compliant companies are capturing market share from delayed competitors
- Strategic opportunity: Your EN 18031 work builds the foundation for Cyber Resilience Act (CRA) compliance, which takes full effect December 2027
So What's Actually Happened Since August 2025?
The August 2025 EN 18031 enforcement marked a genuine shift in how manufacturers approach cybersecurity.
The European Commission listed the EN 18031 series in their Official Journal back in January 2025, giving companies six months to prepare.
Some companies used that time effectively and were ready. Others struggled with the complexity or hoped enforcement might be delayed.
It wasn’t.
Now, the market dynamics are clear. Companies that achieved compliance ahead of August enforcement are securing contracts that previously had multiple supplier options.
Market Surveillance
Enforcement has been proportionate and risk-based, focusing on high-risk categories -childcare devices, wearables processing personal data, and financial transaction equipment.
As such, non-compliant products have been excluded from the EU market since 1st August 2025.
Firmware updates:
If you push security-relevant firmware updates to devices already on the market, those updates might cause the device to be treated as “new” under the regulations. We’re advising clients to be conservative about updates in the short term.
For critical security patches, the update is worth the compliance risk.
For feature additions, it may be safer to wait.
Why EN 18031 Matters More Than You Think
EN 18031 compliance is your blueprint for the Cyber Resilience Act (CRA), which applies to a far broader range of connected products from December 2027.
CRA timeline
- 10th December 2024: CRA came into force
- 11th September 2026: Vulnerability reporting obligations begin
- 11th December 2027: Full CRA requirements apply
The EN 18031 series will almost certainly form the basis for CRA’s horizontal security requirements.
This means your technical file documentation, security architecture decisions, testing evidence, and internal processes created for EN 18031 transfer directly to CRA requirements.
Companies achieving EN 18031 compliance have gained a valuable head start on CRA preparation. Late adopters can still capture this advantage by treating EN 18031 compliance as CRA foundation work.
Understanding EN 18031 - Core Requirements
The EN 18031 documentation appears dense, and practical implications aren’t always immediately clear. Let me translate these standards into actionable technical requirements based on our implementation experience over recent months.
EN 18031-1: Network Protection Requirements
This standard applies to most connected device manufacturers.
If you’re building anything that connects to the internet – industrial sensors, smart home devices, IoT gateways – this applies to you.
The fundamental principle: your device shouldn’t harm the network it connects to, and it shouldn’t become a vector for attacks on other systems.
Translating that principle into specific technical requirements becomes complex quickly.
Authentication: The Complete Lifecycle
Yes, you need strong, unique passwords (or preferably certificate-based authentication), but requirements extend deeper.
Consider the entire authentication lifecycle:
- How do you handle password changes?
- What happens when authentication fails repeatedly?
- How do you prevent brute-force attacks?
- What session management controls exist?
Access Control: Beyond Simple Passwords
The standard requires appropriate access control for all security and network assets. This means systematically understanding what constitutes a security asset in your system and ensuring only authorised entities can access those functions.
For many embedded systems, this means moving beyond simple administrative passwords to role-based access control. A field technician might need diagnostic function access but shouldn’t modify security configurations. An integration partner might require API access with limited scope.
The standard pushes you to think about these access patterns systematically.
Secure Update Mechanisms: Where Many Devices Fail
Your device needs secure software update capabilities with cryptographic verification of authenticity and integrity. It must also be simple enough that users actually apply updates, and robust enough that failed updates don’t brick the device.
This requirement is particularly important because it’s where many IoT devices historically fail. Implementation requires:
- Signed firmware images with cryptographic verification
- Secure boot processes preventing unauthorised firmware
- Rollback protection against downgrade attacks
- Recovery mechanisms for failed update scenarios
Storage and Communication Security
At rest: Sensitive security parameters require integrity and confidentiality protection. No more storing cryptographic keys in plain text configuration files.
In transit: Communications need integrity, authenticity, confidentiality, and replay protection. This typically means implementing TLS or equivalent protocols correctly – not just enabling TLS, but configuring it properly with appropriate cipher suites and certificate validation.
EN 18031-2: Personal Data Protection
This standard builds on EN 18031-1 but adds privacy-focused requirements reflecting heightened sensitivity around personal data. If your device processes any personal information – location data, health measurements, usage patterns, even indirect identifiers – this standard most likely applies.
The requirements align closely with GDPR principles but translate them into technical specifications rather than legal obligations.
Data minimisation isn’t just a privacy concept – it becomes an engineering requirement to collect and process only data actually needed for the device’s function. You must demonstrate why each piece of collected data is necessary and how long it’s retained.
Privacy by design becomes mandatory rather than aspirational. Security controls must be built into the architecture from the start, not added as compliance afterthoughts.
EN 18031-3: Financial Transaction Security
The highest security tier for devices processing financial transactions or handling virtual currency. Requirements include everything from previous standards plus additional controls around:
- Transaction integrity mechanisms
- Anti-fraud protections
- Secure processing of financial data
- Additional authentication requirements for payment operations
Recovery Pathways for Late Adopters
If your products should have launched in Q3 or Q4 2025 but couldn’t due to compliance delays, you have three realistic options:
- Rapid Compliance Sprint (2-4 months): Works if you're close to compliance - most security controls implemented but documentation and testing incomplete. Requires honest assessment of your current security posture and access to experts who understand the standards intimately. You can launch by Q2 2026, though Q1 is now probably missed.
- Comprehensive Redesign (4-8 months): If your current design has fundamental security architecture gaps, proper redesign is safer than patching. Implements security-by-design from the ground up and ensures your architecture supports both EN 18031 and CRA. Results in more robust products but means Q2-Q4 2026 market entry.
- Parallel Development: Launch compliant versions of your most important products first while continuing development on your broader product range. Requires ruthless prioritisation and modular security architecture you can replicate across products.
Self-Declaration vs Notified Body: Which Path?
Self-declaration works when:
- Your product fully implements EN 18031 without exceptions
- Users must create and use passwords (no optional bypass)
- Parental access control is ensured (EN 18031-2)
- Secure updates follow approved implementation categories (EN 18031-3)
You need a Notified Body when:
- Your product allows users to skip password creation
- You’re implementing alternative solutions to specific requirements
- Your product falls into high-risk categories
SESIP Advantage: Annex D of EN 18031 includes direct mapping to GlobalPlatform’s SESIP framework. If you use SESIP-certified components, you can streamline self-declaration and reduce redundant testing of already-certified components.
ByteSnap's Experience: What Works
Since August 2025, we’ve identified clear patterns in successful compliance projects:
Companies achieving fastest compliance treat security as product improvement, not compliance burden. They use modern microcontrollers with built-in security features (dramatically reducing complexity), implement proper cryptographic key management from day one (practically unique keys per device), and build secure update mechanisms that customers trust.
Timeline reality: Security implementation changes your development process, not just adds time. For products close to compliance, 2-4 months is realistic.
Products needing significant rework need 4-8 months. Products starting from scratch should allow 6-12 months for proper security-by-design.
SESIP Advantage: Annex D of EN 18031 includes direct mapping to GlobalPlatform’s SESIP framework. If you use SESIP-certified components, you can streamline self-declaration and reduce redundant testing of already-certified components.
What are the Common Pitfalls to Avoid?
- Treating security as an add-on feature at the end of development (security architecture decisions affect everything from microcontroller choice to user interface).
- Inadequate key management causes about half of compliance failures.
- Insufficient penetration testing undermines otherwise sound designs. Security testing must adopt an adversarial mindset. If you are not actively trying to break your own system, a regulator or external attacker will do it for you.
What the CRA Timeline Means for You
September 2026: Vulnerability reporting obligations begin. Manufacturers must notify ENISA of actively exploited vulnerabilities within 24 hours. Start building your vulnerability handling processes now.
December 2027: Full CRA requirements apply, including security-by-design throughout product lifecycle, secure-by-default configurations, vulnerability handling throughout product lifetime, Software Bill of Materials (SBOM) creation, and 10-year documentation retention.
Companies working on EN 18031 compliance now are building the processes, documentation, and architecture that CRA will require. You’re not duplicating effort—you’re staging compliance work logically.
2026 Launch Planning
Should be in final testing and documentation phases now. If you’re still in active development, you’ve probably missed Q1. Consider pushing to Q2 with proper security implementation.
Ideally compliance work is underway or just starting.This gives time for proper security-by-design without rushed timelines.
At the time of publication, you have adequate time for comprehensive security architecture.
Use it wisely! Don’t squander the buffer by delaying your start.
Your next steps...
• Conduct honest gap analysis this week
• Decide on recovery pathway based on honest assessment of your security posture
• Engage experts immediately if you need external support
• Communicate with stakeholders about when products will be available
• Review your development timeline – add 25-40% for security implementation
• Define your security architecture now before products are in development
• Plan for both EN 18031 and CRA requirements—design once, comply twice
• Build internal security expertise or establish trusted partnerships
• Document your lessons learned for your next products and CRA preparation
• Position your security capabilities in market communications
• Start CRA preparation planning: December 2027 will arrive faster than expected
Ready to Ensure Your Products Meet EN 18031 Requirements?
Further reading
1. Nemko. (2025, February 4). https://www.nemko.com/blog/cybersecurity-in-europe-en-18031-is-now-a-harmonized-standard
2. Nemko. (2024, December 9). https://www.nemko.com/blog/cyber-resilience-act
3. Cetecom Advanced. (2025, February 28). https://cetecomadvanced.com/en/news/red-cybersecurity-standard-en-18031-harmonized/
4. European Commission. (2024). https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act
5. SGS. (2025, February). https://www.sgs.com/en/news/2025/02/safeguards-02625-eu-harmonizes-en-18031-standards
6. GlobalPlatform. (2025, March 27). https://globalplatform.org/red-alert-preparing-for-new-cybersecurity-regulations-on-connected-devices/
7. CCLab. https://www.cclab.com/news/beyond-2025-why-red-is-the-blueprint-for-cra-success
8. Espressif Developer Portal. (2025, April 8). https://developer.espressif.com/blog/2025/04/esp32-red-da-en18031-compliance-guide/
Founded in 2008, ByteSnap Design is an award-winning embedded systems design consultancy, offering a comprehensive range of services across the electronic product development lifecycle.
A highly skilled team of over 40 hardware and software engineers, our expertise spans several sectors, including IoT, automotive, industrial, medical, and consumer electronics.
The engineering consultants on the ByteSnap Editorial Team share their knowledge and practical tips to help you streamline your product development and accelerate designs to market successfully.
With their deep technical expertise and practical experience, they aim to provide valuable insights and actionable tips to guide you through the complex world of electronic product design and development, to help you bring innovative, reliable, and secure electronic products to market quickly and cost-effectively.
