EU Cyber Resilience Act and IoT: What It Means for MQTT Devices

The EU Cyber Resilience Act (CRA) changes how connected products are designed, shipped and maintained in the European Union. This article summarises what the EU Cyber Resilience Act means for IoT manufacturers whose devices communicate over MQTT, covering secure defaults, updates, vulnerability handling and documentation, and shows which engineering decisions in your messaging layer support that work. It is a technical overview, not legal advice; confirm your obligations with qualified counsel and the official text.

What the Cyber Resilience Act Is

The CRA is an EU regulation that sets horizontal cybersecurity requirements for "products with digital elements", meaning hardware and software products whose intended use includes a data connection to a device or network. It entered into force in December 2024, and its obligations apply in stages: reporting obligations for actively exploited vulnerabilities and severe incidents apply from September 2026, and most other obligations from December 2027.

For IoT teams, the important point is scope. A sensor, gateway, smart appliance or industrial controller that connects to a network and is placed on the EU market is very likely in scope, along with its firmware and the software components it includes. Some sectors with their own rules, such as certain medical and automotive products, are treated differently.

Products are split into categories. Most fall into a default category, where manufacturers can assess conformity themselves. Products listed as "important" or "critical" face stricter assessment routes. Which category your device falls into determines how much third-party involvement is needed.

Core Obligations for Manufacturers

The regulation's essential requirements fall into two groups: properties of the product and processes for handling vulnerabilities. Simplified for IoT:

Secure Defaults in the MQTT Layer

Many historical IoT problems came from insecure defaults. In MQTT terms, the CRA's direction translates into concrete design decisions:

1. No shared or default credentials. Each device gets unique credentials during manufacturing or onboarding. See secure IoT device provisioning.
2. TLS enabled by default with certificate verification. No "insecure" mode in production firmware.
3. Outbound-only connections. The device opens a connection to the broker; it does not listen for inbound MQTT.
4. No public brokers for real data. Public test brokers are useful in development, but production firmware must connect to a private, authenticated broker.
5. Minimal topics. Do not publish diagnostic dumps, credentials or unneeded personal data.
6. Safe command handling. Validate every command against an allow list before acting.

Here is what that looks like in ESP32 firmware using WiFiClientSecure and PubSubClient:

#include <WiFi.h>
#include <WiFiClientSecure.h>
#include <PubSubClient.h>

// ISRG Root X1 (Let's Encrypt root) in PEM format, used to verify the broker
static const char ROOT_CA[] PROGMEM = R"EOF(
-----BEGIN CERTIFICATE-----
...paste ISRG Root X1 here...
-----END CERTIFICATE-----
)EOF";

// Unique per device, loaded from protected storage in production
extern const char* DEVICE_CLIENT_ID;  // YOUR_CLIENT_ID
extern const char* DEVICE_USERNAME;   // YOUR_USERNAME
extern const char* DEVICE_PASSWORD;   // YOUR_PASSWORD

WiFiClientSecure net;
PubSubClient mqtt(net);
unsigned long nextAttempt = 0;
unsigned long backoffMs = 1000;

void connectMqtt() {
  if (mqtt.connected() || millis() < nextAttempt) return;
  if (mqtt.connect(DEVICE_CLIENT_ID, DEVICE_USERNAME, DEVICE_PASSWORD)) {
    backoffMs = 1000;
  } else {
    nextAttempt = millis() + backoffMs + random(0, 1000);  // backoff with jitter
    backoffMs = min(backoffMs * 2, 300000UL);
  }
}

void setup() {
  WiFi.begin("YOUR_WIFI_SSID", "YOUR_WIFI_PASSWORD");
  while (WiFi.status() != WL_CONNECTED) delay(500);
  net.setCACert(ROOT_CA);               // verify server; never call setInsecure()
  mqtt.setServer("YOUR_BROKER_HOST", 8883);
}

void loop() {
  connectMqtt();
  mqtt.loop();
}

The details that matter for secure defaults are visible: certificate verification on, credentials not hard-coded in the sketch body, and a reconnect strategy that does not hammer the broker. The ESP32 MQTT tutorial shows the full publish loop.

Updates and Vulnerability Handling

The CRA puts significant weight on what happens after a product ships. For MQTT devices, the connectivity layer is part of that story:

• Know your components. Maintain a software bill of materials (SBOM) listing your MQTT client library, TLS library and their versions. When an advisory appears, you need to know within hours which products use the affected code.
• Have an update channel. Many teams use MQTT to signal that an update is available and HTTPS to download a signed image. Whatever the mechanism, it must be authenticated and integrity-protected.
• Separate security updates. Where possible, ship security fixes independently of feature releases.
• Publish a disclosure policy. Give researchers a clear way to report issues.
• Prepare for reporting. Decide who triages vulnerabilities and incidents and how reports reach the authorities within the required deadlines.

The overview of common MQTT vulnerabilities is a useful starting point for what to track in client libraries.

Where the Broker Fits

The CRA places obligations on the manufacturer of the product. Choosing a particular broker does not make a product compliant, and no broker provider can transfer that responsibility. What the backend can do is make secure designs easier to implement and document.

ConnectMQ provides capabilities you can reference in your technical documentation as part of your own risk assessment:

• MQTT over TLS on 8883 and secure WebSockets on 8084 with a Let's Encrypt certificate, so devices can verify the server with a standard root.
• Authenticated private brokers with generated credentials, and client IDs bound to those credentials.
• Multi-tenant isolation, or an isolated cluster on Dedicated plans, or deployment into your own cloud account with BYOC.
• Per-plan quotas signalled with MQTT 5 reason code 0x97, flood protection and IP blocking after repeated failed logins, which support availability under abuse.
• Connection state through $SYS/broker/connection/{clientId}/state and portal threshold alerts to help detect abnormal behaviour.

Do not describe ConnectMQ, or any broker, as a CRA compliance solution. Document it as a component in your architecture, list its security properties, and keep responsibility for device-side controls. The managed MQTT broker guide explains the shared-responsibility split.

A Practical CRA Readiness Checklist for MQTT Devices

1. Confirm whether your product is in scope and which category applies.
2. Perform and document a cybersecurity risk assessment covering the MQTT data flows.
3. Remove default and shared credentials; provision unique identities per device.
4. Enforce TLS with server certificate verification in production firmware.
5. Ensure devices make outbound connections only and expose no unnecessary interfaces.
6. Validate all received commands and limit what they can change.
7. Implement reconnect backoff and offline buffering for resilience.
8. Maintain an SBOM including MQTT and TLS libraries.
9. Build and test a signed, authenticated update mechanism.
10. Publish a vulnerability disclosure policy and define the reporting process.
11. Define and communicate the support period.
12. Prepare user documentation on secure setup and decommissioning.

For broader context, MQTT security best practices and zero trust for IoT messaging cover many of the same controls from an engineering perspective. Official guidance and the regulation text are published by the European Commission.

Build Secure Connectivity on ConnectMQ

Start with the connectivity layer while you work through the rest of the checklist. Create a private broker on the free Serverless plan at app.connectmq.com (no credit card), point a development device at it over TLS with unique credentials, and use the public MQTT test broker only for throwaway experiments. When you need isolation, the cloud MQTT broker guide compares deployment models.

Frequently Asked Questions

Does the Cyber Resilience Act apply to my IoT device?

If it is a product with digital elements that connects to a device or network and is placed on the EU market, it very likely does, unless sector-specific rules exclude it. Confirm the scope and category for your product with legal counsel.

When do CRA obligations start to apply?

Reporting obligations for actively exploited vulnerabilities and severe incidents apply from September 2026, and most other obligations from December 2027.

Does using a secure MQTT broker make my product CRA compliant?

No. Compliance is the manufacturer's responsibility for the whole product. A secure broker supports your design, but device firmware, updates, vulnerability handling and documentation remain your work.

Is MQTT over TLS enough to meet the CRA's confidentiality requirement?

TLS protects data in transit, which is an important part. You still need to protect stored credentials and data on the device and assess whether additional measures are needed for your risk profile.