EN 18031-1: What the EU Cybersecurity Standard Means for IoT Environmental Monitors

Every cellular air quality monitor, dust sensor, and noise meter sold in the EU is now subject to cybersecurity requirements that most manufacturers have never had to meet. EN 18031-1:2024 — the harmonised European standard under the Radio Equipment Directive — defines what "secure" actually means for internet-connected devices. It is not optional, it is not advisory, and it applies to every environmental monitoring station that uses cellular connectivity.

If you are purchasing or specifying monitoring equipment, this standard should be part of your evaluation criteria. If your supplier cannot demonstrate compliance, that is a question worth asking.

What Is EN 18031-1?

EN 18031-1:2024 is a harmonised European standard published by CENELEC (the European Committee for Electrotechnical Standardisation). It establishes common security requirements for internet-connected radio equipment under the EU Radio Equipment Directive (RED) 2014/53/EU, Article 3(3)(d).

In practical terms, it answers a simple question: what security mechanisms must a connected device implement to be sold in the European market?

The standard is part of the EU's broader push to secure IoT infrastructure. The delegated act under RED Article 3(3)(d) makes cybersecurity compliance mandatory for all internet-connected radio equipment — a category that includes every cellular environmental monitor on the market.

EN 18031 has three parts:

For environmental monitoring equipment, only Part 1 applies. Parts 2 and 3 are relevant to consumer electronics and payment terminals.

What EN 18031-1 Requires: The Eleven Security Mechanisms

The standard defines eleven security mechanism categories. Each addresses a specific aspect of device security. For manufacturers of environmental monitoring equipment, nine of these are typically applicable — two (Network Monitoring and Traffic Control) apply only to network routing equipment like routers and gateways, not endpoint sensor devices.

Here is what each mechanism requires, explained in the context of environmental monitoring hardware:

1. Access Control Mechanism (ACM)

The device must control who and what can access its security assets — cryptographic keys, configuration settings, firmware — and its network assets. This means protocol-level access control (such as LwM2M Access Control Lists), application-level role-based access in the cloud platform, and physical access protection for local interfaces.

2. Authentication Mechanism (AUM)

The device must authenticate itself to the server, and the server must authenticate itself to the device, before any data is exchanged. This is mutual authentication — both sides prove their identity. The standard also requires brute-force protection, password strength enforcement, and the ability to change credentials.

3. Secure Update Mechanism (SUM)

Firmware updates must be cryptographically signed. The device must verify the signature before accepting any update, regardless of the delivery method — over-the-air or physical. Unsigned, corrupted, or tampered firmware must be rejected.

This is perhaps the most important requirement for environmental monitoring. A compromised firmware update could manipulate sensor readings, disable monitoring, or turn the device into an attack vector on a construction site network. If your supplier cannot explain how their firmware updates are signed and verified, that is a serious gap.

4. Secure Storage Mechanism (SSM)

Cryptographic keys and sensitive configuration must be stored securely — ideally in hardware-isolated storage, not in plain text on flash memory. The standard requires that security assets cannot be extracted by an attacker with physical access to the device.

5. Secure Communication Mechanism (SCM)

All network communication must provide integrity (data has not been tampered with), authenticity (data comes from the claimed source), confidentiality (data is encrypted), and replay protection (old messages cannot be re-sent to manipulate the system).

6. Resilience Mechanism (RLM)

The device must continue performing its essential function during adverse conditions — network outages, power interruptions, or attempted denial-of-service. For environmental monitors, this means continued sensor sampling and local data buffering when the cellular connection drops.

7. Network Monitoring Mechanism (NMM) — Not applicable to endpoint sensors

Applies to network equipment (routers, gateways) that connects other devices to the internet. Environmental monitoring stations are endpoint devices — they do not route or forward traffic.

8. Traffic Control Mechanism (TCM) — Not applicable to endpoint sensors

Same rationale as NMM — applies to network routing equipment, not endpoint sensors.

9. Confidential Cryptographic Keys (CCK)

All cryptographic keys must be unique per device. No shared default keys across the production run. Keys must be generated using proper entropy sources (hardware random number generators), and there must be a mechanism for key rotation throughout the device lifecycle.

This is where many manufacturers fail. If every device ships with the same pre-shared key, or if keys are derived from predictable values like MAC addresses, the entire fleet is vulnerable when one device is compromised.

10. General Equipment Capabilities (GEC)

The device must minimise its attack surface: no unnecessary network services exposed, all interfaces documented, input validation on all data paths, and an ongoing vulnerability management process (CVE scanning).

11. Cryptography (CRY)

All cryptographic algorithms must be current best practices. No deprecated algorithms — MD5, SHA-1, DES, RC4, and 3DES are all explicitly unacceptable. Key sizes must meet minimum requirements (256-bit for ECDSA, 128/256-bit for AES).

How LwM2M Solves Half the Problem

If you have read our article on why LwM2M matters for air quality monitoring, you will already understand why we chose this protocol for all Sensorbee cellular products. But the security implications go further than we discussed there.

LwM2M was designed by OMA SpecWorks with IoT security as a foundational principle — not an afterthought. When you implement LwM2M correctly, you inherently satisfy a significant portion of EN 18031-1's requirements:

This is not a coincidence. LwM2M was built for exactly the kind of devices that EN 18031-1 regulates. The protocol's architecture aligns with the standard's requirements because both were designed to solve the same problem: making connected IoT devices secure by default.

The critical point for procurement teams: if your monitoring supplier uses LwM2M as their device protocol, they have already addressed a substantial portion of EN 18031-1 at the protocol level. If they use MQTT, HTTP, or a proprietary protocol, they have had to build every one of these security mechanisms from scratch — and you should ask them to prove it.

Questions Your Supplier Should Be Able to Answer

EN 18031-1 compliance is not a checkbox exercise. If your environmental monitoring supplier claims their devices are secure, they should be able to answer these questions clearly:

On firmware security:

• ·How are firmware updates signed? What algorithm and key size?
• ·Is the signing key unique, and where is the private key stored?
• ·What happens if a tampered firmware image is pushed to the device?
• ·Can you demonstrate a secure boot chain from power-on to application?

On credential management:

• ·Does every device ship with a unique cryptographic key, or do devices share default credentials?
• ·Where are keys stored on the device — in software on general flash, or in hardware-isolated secure storage?
• ·Can credentials be rotated without physical access to the device?
• ·What happens if one device's key is compromised — does it expose the entire fleet?

On communication security:

• ·Is device-to-cloud communication encrypted end-to-end?
• ·Is there mutual authentication — does the device verify the server's identity, not just the other way around?
• ·What cipher suites are supported? Are any deprecated algorithms in use?

On device management:

• ·How do you manage firmware updates across a fleet of 100+ devices?
• ·Can updates be scheduled and rolled out in stages?
• ·What happens if an update fails mid-transfer?
• ·How do you handle vulnerability disclosures (CVEs) in the device firmware stack?

If any of these questions produce vague answers, hand-waving about "industry-standard security," or blank stares — that tells you something important about how seriously your supplier takes cybersecurity.

The Risk of Homegrown IoT Protocols

Many environmental monitoring manufacturers have built their connectivity using MQTT over TCP, or entirely proprietary protocols, because these were the fastest path to market. The device sends readings to a cloud broker, the cloud stores them, and the customer accesses a dashboard. It works. But EN 18031-1 asks a harder question: is it secure?

The problem is that MQTT is a messaging protocol. It was designed to move data from point A to point B. It was not designed to manage devices.

When you build an environmental monitoring system on MQTT, every EN 18031-1 requirement becomes a custom engineering project:

• ·Secure firmware updates? MQTT has no firmware update mechanism. You must design, build, test, and maintain your own OTA update system — including signature verification, rollback handling, and campaign management.
• ·Device authentication? MQTT supports TLS client certificates or username/password. But mutual authentication at the protocol level — where the device verifies the server's identity before exchanging data — requires additional engineering.
• ·Access control? MQTT topic-based ACLs provide some control, but there is no standardised model for per-resource, per-role access control across devices.
• ·Credential rotation? If your devices use shared MQTT credentials, rotating them means updating every device simultaneously — or accepting a fleet-wide outage. Per-device credentials with remote rotation require a device management layer that MQTT does not provide.
• ·Resilience? MQTT's persistent TCP connection means the device must maintain an always-on connection, which drains batteries. Queue-based offline buffering, automatic reconnection with backoff, and session resumption must all be custom-built.

None of this means MQTT-based systems cannot be made secure. They can — with significant engineering effort. But the question for procurement teams is: has your supplier actually done that work? Have they implemented all nine applicable EN 18031-1 mechanism categories, tested them, and documented the evidence? Or have they focused on getting sensor data to a dashboard and treated security as a future concern?

The difference between a purpose-built IoT security protocol like LwM2M and a general-purpose messaging protocol like MQTT is not just technical — it is the difference between security by design and security as an afterthought.

Sensorbee's EN 18031-1 Compliance

At Sensorbee, we have assessed the Air Pro 2 Cellular (models SB8202 and SB8203) against EN 18031-1:2024 and published a self-declaration of conformity. Here is a summary of our compliance status:

Key technical facts about our implementation:

• ·Firmware signing: ECDSA P-256 digital signatures verified by MCUboot at every boot and every update. The private signing key never exists on the device — it is held exclusively in Sensorbee's secure build infrastructure.
• ·Credential storage: DTLS Pre-Shared Keys stored in the nRF9160 modem's hardware-isolated secure storage — physically separated from the application processor.
• ·Per-device unique credentials: Every device receives a unique PSK and identity during manufacturing provisioning. No shared default keys across the production run.
• ·Credential rotation: PSK can be changed remotely via LwM2M bootstrap or locally via the sealed USB-C service interface, without replacing the device.
• ·Cryptographic standards: AES-128/256, SHA-256, ECDSA P-256. No deprecated algorithms (MD5, SHA-1, DES, RC4, 3DES) anywhere in the firmware stack.
• ·Secure boot chain: nRF9160 ROM then MCUboot then Application. Each stage verifies the cryptographic signature of the next before execution.
• ·Physical security: IP65 sealed enclosure with tool-based disassembly required. Internal USB-C service port is inaccessible without opening the housing.

The full compliance evidence document is available for download:

Download: Sensorbee EN 18031-1 Compliance Evidence (PDF)

This document provides detailed evidence for each of the eleven mechanism categories, including firmware configuration references, architectural descriptions, and verification methodology.

What This Means for Your Next Procurement Decision

EN 18031-1 is not a future requirement — it is current law. If you are specifying, purchasing, or deploying environmental monitoring equipment with cellular connectivity, cybersecurity compliance should be part of your evaluation alongside accuracy, MCERTS certification, and data platform capabilities.

Three practical steps:

1. Ask your supplier for their EN 18031-1 compliance documentation. A legitimate claim of compliance should be backed by a detailed evidence document — not a vague assurance that devices are "secure."
2. Check how the device communicates. If it uses an open, security-focused protocol like LwM2M, many security mechanisms are inherent to the architecture. If it uses MQTT or a proprietary protocol, ask how each security mechanism is implemented and evidenced.
3. Verify the details. Per-device unique keys? Hardware-backed credential storage? Signed firmware with a secure boot chain? These are not optional extras — they are baseline requirements under EN 18031-1.

Environmental monitoring data informs regulatory decisions, construction site compliance, and public health policy. The integrity of that data depends on the security of the devices collecting it. EN 18031-1 sets the minimum bar — and at Sensorbee, we believe that bar should be the starting point, not the ceiling.

Download our product catalogue to learn more about Sensorbee's monitoring solutions, or contact us to discuss your requirements.

Frequently Asked Questions

What is EN 18031-1 and why does it matter for environmental monitoring?

EN 18031-1:2024 is a harmonised European standard that defines cybersecurity requirements for internet-connected radio equipment under the EU Radio Equipment Directive (RED) Article 3(3)(d). It matters for environmental monitoring because every cellular air quality monitor, dust sensor, and noise meter sold in the EU must comply with this standard. It establishes eleven security mechanism categories covering access control, authentication, secure firmware updates, encrypted communication, secure key storage, and device resilience — all of which directly affect the integrity of environmental monitoring data.

When did EN 18031-1 become mandatory?

The delegated act under RED Article 3(3)(d) makes EN 18031-1 compliance mandatory for all new internet-connected radio equipment placed on the EU market. Manufacturers must demonstrate compliance through self-declaration or third-party assessment. Devices that do not meet these requirements cannot carry CE marking for cybersecurity under the Radio Equipment Directive.

How does EN 18031-1 relate to the EU Cyber Resilience Act?

EN 18031-1 and the EU Cyber Resilience Act (CRA) both address IoT cybersecurity but through different regulatory frameworks. EN 18031-1 applies specifically to radio equipment under the RED, while the CRA covers a broader category of products with digital elements. For environmental monitoring equipment that uses cellular connectivity, EN 18031-1 under the RED is the current applicable standard. The CRA introduces additional requirements that will apply alongside the RED requirements as it comes into force.

Does my air quality monitor need EN 18031-1 compliance?

If your air quality monitor uses cellular connectivity (LTE-M, NB-IoT, 4G, or 5G) and is sold or deployed in the EU, then yes — it falls under the scope of EN 18031-1 as internet-connected radio equipment. Monitors that use only wired connections (Ethernet, RS-485) or local wireless (Wi-Fi used purely as a local interface without direct internet connectivity) may have different regulatory considerations.

What is the difference between EN 18031-1 and ISO 27001 for IoT devices?

ISO 27001 is an information security management system standard that applies to organisations and their processes. EN 18031-1 is a product security standard that applies to the device itself — its firmware, communication protocols, key storage, and update mechanisms. A manufacturer can have ISO 27001 certification for their company processes while their devices fail to meet EN 18031-1 requirements. Both are important, but they address different aspects of security.

How does LwM2M help with EN 18031-1 compliance?

LwM2M (Lightweight Machine-to-Machine) is an IoT protocol designed with security as a foundational principle. It natively provides DTLS-encrypted communication (satisfying SCM requirements), mutual device-server authentication (AUM), standardised secure firmware updates via Object 5 (SUM), per-resource access control via Object 2 (ACM), and resilience mechanisms including session caching and automatic reconnection (RLM). Devices built on LwM2M inherently address approximately half of EN 18031-1's mechanism categories at the protocol level. For a detailed comparison of LwM2M versus other IoT protocols, read our article on why LwM2M matters for air quality monitoring.

Can MQTT-based IoT devices comply with EN 18031-1?

Yes, but it requires significantly more custom engineering. MQTT is a messaging protocol without built-in device management, firmware update mechanisms, or standardised access control. Every EN 18031-1 requirement — secure firmware updates, credential rotation, mutual authentication, resilience mechanisms — must be designed and implemented from scratch on top of MQTT. The question is not whether it is possible, but whether your supplier has actually done the work and can provide documented evidence of compliance for each mechanism category.

What should I ask my monitoring supplier about EN 18031-1?

Key questions include: Can you provide your EN 18031-1 compliance evidence document? How are firmware updates cryptographically signed? Does each device have unique cryptographic credentials, or do they share default keys? Where are credentials stored — in hardware-isolated storage or in software? Can credentials be rotated remotely without device replacement? What protocol does the device use to communicate with the cloud? How do you handle CVE vulnerability disclosures for your firmware stack?

Is Sensorbee compliant with EN 18031-1?

Yes. Sensorbee has assessed the Air Pro 2 Cellular (models SB8202 and SB8203) against EN 18031-1:2024 and published a self-declaration of conformity. Nine of the eleven mechanism categories are applicable to the Pro 2 (two apply only to network routing equipment), and all nine are assessed as compliant. The compliance evidence is built on the LwM2M protocol stack with DTLS encryption, hardware-backed credential storage in the nRF9160 modem, ECDSA P-256 firmware signing via MCUboot, and per-device unique manufacturing provisioning. The full compliance evidence document is available for download.