Cyber Resilience Act et IoT : impact pour MQTT

Le Cyber Resilience Act (CRA) de l'UE change la façon dont les produits connectés sont conçus, commercialisés et maintenus dans l'Union européenne. Cet article résume ce que le Cyber Resilience Act implique pour les fabricants IoT dont les appareils communiquent via MQTT (sécurité par défaut, mises à jour, gestion des vulnérabilités et documentation) et montre quelles décisions d'ingénierie dans votre couche de messagerie soutiennent ce travail. Il s'agit d'une présentation technique, pas d'un avis juridique ; confirmez vos obligations auprès d'un conseil qualifié et du texte officiel.

Qu'est-ce que le Cyber Resilience Act ?

Le CRA est un règlement européen qui fixe des exigences de cybersécurité horizontales pour les « produits comportant des éléments numériques », c'est-à-dire les produits matériels et logiciels dont l'usage prévu inclut une connexion de données à un appareil ou à un réseau. Il est entré en vigueur en décembre 2024 et ses obligations s'appliquent par étapes : les obligations de signalement des vulnérabilités activement exploitées et des incidents graves s'appliquent à partir de septembre 2026, et la plupart des autres obligations à partir de décembre 2027.

Pour les équipes IoT, le point important est le champ d'application. Un capteur, une passerelle, un appareil intelligent ou un contrôleur industriel qui se connecte à un réseau et est mis sur le marché de l'UE est très probablement concerné, de même que son firmware et les composants logiciels qu'il intègre. Certains secteurs dotés de leurs propres règles, comme certains produits médicaux et automobiles, sont traités différemment.

Les produits sont répartis en catégories. La plupart relèvent d'une catégorie par défaut, dans laquelle les fabricants peuvent évaluer eux-mêmes la conformité. Les produits classés « importants » ou « critiques » suivent des procédures d'évaluation plus strictes. La catégorie de votre appareil détermine le degré d'intervention d'un tiers nécessaire.

Les obligations essentielles des fabricants

Les exigences essentielles du règlement se répartissent en deux groupes : les propriétés du produit et les processus de gestion des vulnérabilités. Version simplifiée pour l'IoT :

Domaine	Ce qu'attend le CRA (simplifié)	Ce que cela signifie pour un appareil MQTT
Sécurité par défaut	Les produits sont livrés avec une configuration sécurisée, sans vulnérabilité exploitable connue	Pas de mots de passe par défaut, TLS activé par défaut, aucun topic de débogage actif
Contrôle d'accès	Protection contre les accès non autorisés grâce à une authentification et une gestion des identités appropriées	Identifiants uniques par appareil, aucune connexion anonyme au broker
Confidentialité	Protéger les données stockées et transmises, par exemple par chiffrement	MQTT sur TLS, stockage protégé des identifiants
Intégrité	Protéger données, commandes et firmware contre toute modification non autorisée	Firmware signé, commandes validées
Minimisation des données	Ne traiter que les données nécessaires à la finalité prévue	Publier ce dont le cas d'usage a besoin, rien de plus
Disponibilité et résilience	Maintenir les fonctions essentielles, y compris en cas de déni de service	Backoff, mise en tampon, bon comportement face aux limites du broker
Limiter la surface d'attaque	Réduire au minimum les interfaces exposées	Aucun port entrant ; MQTT sortant uniquement
Mises à jour de sécurité	Fournir des mises à jour pendant la période de support, idéalement automatiques et séparées des évolutions fonctionnelles	Un chemin OTA sécurisé qui fonctionne sur votre connectivité
Gestion des vulnérabilités	Identifier, documenter et corriger les vulnérabilités ; politique de divulgation coordonnée	SBOM couvrant les bibliothèques MQTT, un contact de divulgation, un processus de correctifs
Signalement	Signaler les vulnérabilités activement exploitées et les incidents graves dans les délais fixés	Un processus interne pour détecter, trier et signaler
Documentation	Documentation technique, informations utilisateur, période de support	Documenter comment l'appareil se connecte et comment l'utilisateur le sécurise

La sécurité par défaut dans la couche MQTT

Beaucoup de problèmes historiques de l'IoT venaient de réglages par défaut non sécurisés. En termes MQTT, l'orientation du CRA se traduit par des décisions de conception concrètes :

Aucun identifiant partagé ou par défaut. Chaque appareil reçoit des identifiants uniques lors de la fabrication ou de la mise en service. Voir le provisionnement sécurisé des appareils IoT.
TLS activé par défaut avec vérification des certificats. Aucun mode « non sécurisé » dans le firmware de production.
Connexions sortantes uniquement. L'appareil ouvre une connexion vers le broker ; il n'écoute pas de connexions MQTT entrantes.
Pas de brokers publics pour les vraies données. Les brokers de test publics sont utiles en développement, mais le firmware de production doit se connecter à un broker privé et authentifié.
Topics minimaux. Ne publiez ni dumps de diagnostic, ni identifiants, ni données personnelles inutiles.
Traitement sûr des commandes. Validez chaque commande par rapport à une liste autorisée avant d'agir.

Voici à quoi cela ressemble dans un firmware ESP32 utilisant WiFiClientSecure et PubSubClient :

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

// ISRG Root X1 (racine Let's Encrypt) au format PEM, utilisée pour vérifier le broker
static const char ROOT_CA[] PROGMEM = R"EOF(
-----BEGIN CERTIFICATE-----
...paste ISRG Root X1 here...
-----END CERTIFICATE-----
)EOF";

// Uniques par appareil, chargés depuis un stockage protégé en 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 avec gigue
    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);               // vérifier le serveur ; ne jamais appeler setInsecure()
  mqtt.setServer("YOUR_BROKER_HOST", 8883);
}

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

Les détails qui comptent pour la sécurité par défaut sont visibles : vérification des certificats activée, identifiants non codés en dur dans le corps du sketch, et stratégie de reconnexion qui ne martèle pas le broker. Le tutoriel MQTT pour ESP32 présente la boucle de publication complète.

Mises à jour et gestion des vulnérabilités

Le CRA accorde une grande importance à ce qui se passe après la mise sur le marché d'un produit. Pour les appareils MQTT, la couche de connectivité fait partie de cette histoire :

Connaître vos composants. Tenez à jour une nomenclature logicielle (SBOM) listant votre bibliothèque cliente MQTT, votre bibliothèque TLS et leurs versions. Quand un avis de sécurité paraît, vous devez savoir en quelques heures quels produits utilisent le code concerné.
Disposer d'un canal de mise à jour. Beaucoup d'équipes utilisent MQTT pour signaler qu'une mise à jour est disponible et HTTPS pour télécharger une image signée. Quel que soit le mécanisme, il doit être authentifié et protégé en intégrité.
Séparer les mises à jour de sécurité. Dans la mesure du possible, livrez les correctifs de sécurité indépendamment des versions fonctionnelles.
Publier une politique de divulgation. Donnez aux chercheurs un moyen clair de signaler des problèmes.
Préparer le signalement. Décidez qui trie les vulnérabilités et les incidents et comment les signalements parviennent aux autorités dans les délais requis.

Le panorama des vulnérabilités MQTT courantes est un bon point de départ pour savoir quoi surveiller dans les bibliothèques clientes.

La place du broker

Le CRA impose des obligations au fabricant du produit. Choisir un broker particulier ne rend pas un produit conforme, et aucun fournisseur de broker ne peut transférer cette responsabilité. Ce que le backend peut faire, c'est faciliter la mise en œuvre et la documentation de conceptions sécurisées.

ConnectMQ fournit des capacités que vous pouvez citer dans votre documentation technique dans le cadre de votre propre analyse de risques :

MQTT sur TLS sur le port 8883 et WebSockets sécurisés sur le port 8084 avec un certificat Let's Encrypt, pour que les appareils puissent vérifier le serveur avec une racine standard.
Des brokers privés authentifiés avec des identifiants générés, et des client IDs liés à ces identifiants.
Une isolation multi-tenant, ou un cluster isolé avec les offres Dedicated, ou un déploiement dans votre propre compte cloud avec BYOC.
Des quotas par offre signalés avec le code de raison MQTT 5 0x97, une protection contre l'inondation et un blocage d'IP après des échecs de connexion répétés, qui soutiennent la disponibilité en cas d'abus.
L'état de connexion via $SYS/broker/connection/{clientId}/state et des alertes à seuil dans le portail pour aider à détecter les comportements anormaux.

Ne présentez pas ConnectMQ, ni aucun broker, comme une solution de conformité au CRA. Documentez-le comme un composant de votre architecture, listez ses propriétés de sécurité et gardez la responsabilité des contrôles côté appareil. Le guide du broker MQTT managé explique le partage des responsabilités.

Une checklist pratique de préparation au CRA pour les appareils MQTT

Confirmez si votre produit entre dans le champ d'application et quelle catégorie s'applique.
Réalisez et documentez une analyse des risques de cybersécurité couvrant les flux de données MQTT.
Supprimez les identifiants par défaut et partagés ; provisionnez des identités uniques par appareil.
Imposez TLS avec vérification du certificat serveur dans le firmware de production.
Assurez-vous que les appareils n'établissent que des connexions sortantes et n'exposent aucune interface inutile.
Validez toutes les commandes reçues et limitez ce qu'elles peuvent modifier.
Mettez en place un backoff de reconnexion et une mise en tampon hors ligne pour la résilience.
Tenez à jour une SBOM incluant les bibliothèques MQTT et TLS.
Construisez et testez un mécanisme de mise à jour signé et authentifié.
Publiez une politique de divulgation des vulnérabilités et définissez le processus de signalement.
Définissez et communiquez la période de support.
Préparez une documentation utilisateur sur la configuration sécurisée et la mise hors service.

Pour un contexte plus large, les bonnes pratiques de sécurité MQTT et le zero trust pour la messagerie IoT couvrent bon nombre des mêmes contrôles d'un point de vue ingénierie. Les orientations officielles et le texte du règlement sont publiés par la Commission européenne.

Bâtir une connectivité sécurisée sur ConnectMQ

Commencez par la couche de connectivité pendant que vous avancez sur le reste de la checklist. Créez un broker privé avec l'offre gratuite Serverless sur app.connectmq.com (sans carte bancaire), connectez-y un appareil de développement via TLS avec des identifiants uniques, et n'utilisez le serveur MQTT public gratuit que pour des expériences jetables. Lorsque vous avez besoin d'isolation, le guide du broker MQTT cloud compare les modèles de déploiement.

Questions fréquentes

Le Cyber Resilience Act s'applique-t-il à mon appareil IoT ?

S'il s'agit d'un produit comportant des éléments numériques qui se connecte à un appareil ou à un réseau et qui est mis sur le marché de l'UE, c'est très probablement le cas, sauf si des règles sectorielles l'excluent. Confirmez le champ d'application et la catégorie de votre produit avec un conseil juridique.

Quand les obligations du CRA commencent-elles à s'appliquer ?

Les obligations de signalement des vulnérabilités activement exploitées et des incidents graves s'appliquent à partir de septembre 2026, et la plupart des autres obligations à partir de décembre 2027.

Utiliser un broker MQTT sécurisé rend-il mon produit conforme au CRA ?

Non. La conformité relève de la responsabilité du fabricant pour l'ensemble du produit. Un broker sécurisé soutient votre conception, mais le firmware, les mises à jour, la gestion des vulnérabilités et la documentation restent votre travail.

MQTT sur TLS suffit-il à satisfaire l'exigence de confidentialité du CRA ?

TLS protège les données en transit, ce qui en constitue une part importante. Vous devez encore protéger les identifiants et les données stockés sur l'appareil, et évaluer si des mesures supplémentaires sont nécessaires selon votre profil de risque.

Cyber Resilience Act de l'UE et IoT : ce que cela change pour les appareils MQTT