ETSI EN 303 645: les 13 exigences de sécurité de l’IoT grand public, expliquées
Si vous ne deviez lire qu’un seul référentiel avant de concevoir un objet connecté, ce serait celui-ci. ETSI EN 303 645 tient en une quarantaine de pages, se lit sans formation juridique, et décrit le socle de sécurité que tout produit grand public devrait respecter.
Nous la citons régulièrement dans nos articles. Voici enfin ce qu’elle contient, exigence par exigence, avec ce que chacune signifie sur un produit réel.
Une norme volontaire, mais partout
ETSI EN 303 645 est une norme européenne publiée par l’ETSI en 2020, dont la version en vigueur est la V3.1.3 de septembre 2024. Elle vise les objets connectés grand public: caméras, enceintes, serrures, jouets, montres, électroménager, passerelles domestiques.
Elle est volontaire. Aucun texte européen n’impose de la respecter. Elle sert pourtant de référence à de nombreux dispositifs dans le monde: la loi britannique sur la sécurité des produits connectés en reprend les trois premières exigences, et plusieurs labels nationaux de cybersécurité s’appuient sur elle.
Deux documents l’accompagnent:
- ETSI TS 103 701, qui décrit comment évaluer la conformité d’un produit
- ETSI TR 103 621, un guide de mise en œuvre avec des exemples
Les 13 exigences
1. Pas de mot de passe par défaut universel
Chaque équipement doit avoir un mot de passe unique, ou imposer à l’utilisateur d’en définir un. C’est la première exigence parce que c’est la première cause de compromission de masse. Voir notre training sur le mot de passe par défaut.
2. Un moyen de recevoir les signalements de vulnérabilités
Le fabricant publie une politique de divulgation: un point de contact, et un engagement sur les délais de réponse. Un chercheur qui trouve une faille doit savoir à qui l’écrire.
3. Des logiciels maintenus à jour
Le produit peut recevoir des mises à jour de sécurité, de façon simple pour l’utilisateur. Le fabricant annonce pendant combien de temps il les fournira.
4. Un stockage sécurisé des paramètres sensibles
Clés, identifiants et certificats sont protégés dans l’équipement. Aucun secret commun à tous les produits n’est inscrit en dur dans le code. C’est exactement le sujet de Secrets dans le firmware: trois failles, une même cause.
5. Des communications sécurisées
Les échanges sont chiffrés et authentifiés avec des mécanismes à l’état de l’art, qu’ils passent par Internet ou par une liaison locale. Nos articles sur le Bluetooth Low Energy et sur MQTT montrent ce qui se passe quand ce n’est pas le cas.
6. Une surface d’attaque réduite
Les interfaces et services inutiles sont désactivés. Cela inclut les interfaces physiques: la norme mentionne explicitement les ports de debug. Voir JTAG et SWD: les interfaces de debug côté attaque.
7. L’intégrité du logiciel
Le produit vérifie son logiciel au démarrage et réagit en cas de modification non autorisée. Voir Secure boot et signature de firmware.
8. La protection des données personnelles
Les données personnelles sont chiffrées en transit, en particulier les plus sensibles. Les capteurs de l’appareil (micro, caméra) sont documentés de façon claire pour l’utilisateur.
9. La résilience aux coupures
Le produit continue d’assurer ses fonctions locales en cas de perte de réseau ou de courant, et reprend proprement ensuite. Une serrure connectée doit rester une serrure quand le cloud ne répond plus.
10. L’examen des données de télémétrie
Si le produit remonte des données d’usage ou de mesure, elles sont examinées pour détecter des anomalies de sécurité.
11. La suppression facile des données par l’utilisateur
L’utilisateur peut effacer ses données de l’appareil et des services associés, simplement, avec une confirmation claire. La question se pose à chaque revente ou retour produit.
12. Une installation et une maintenance simples
La configuration sécurisée demande le moins de décisions possible à l’utilisateur, et le produit le guide. Un réglage de sécurité que personne ne trouve est un réglage que personne n’active.
13. La validation des données entrantes
Toute donnée reçue par une interface, réseau ou autre, est contrôlée avant d’être utilisée. C’est la règle de base du développement sécurisé, appliquée aussi aux API et aux bus internes.
La norme se termine par un chapitre consacré à la protection des données personnelles: information de l’utilisateur, consentement, minimisation de la télémétrie.
Lire la norme côté attaquant
Présentée ainsi, la liste paraît évidente. Elle ne l’est pas, pour une raison simple: chaque exigence est facile à cocher sur le papier et difficile à tenir sur le produit.
| Ce que dit la fiche produit | Ce que trouve l’auditeur |
|---|---|
| « Mot de passe unique par appareil » | Un mot de passe dérivé de l’adresse MAC, donc calculable |
| « Communications chiffrées » | Du TLS vers le cloud, et une liaison Bluetooth locale en clair |
| « Mises à jour sécurisées » | Un téléchargement en HTTPS d’un firmware qui n’est pas signé |
| « Interfaces de debug désactivées » | Un connecteur retiré, des signaux toujours actifs sur les pastilles |
| « Secrets protégés » | Une clé d’API identique dans tous les firmwares |
La norme distingue d’ailleurs les exigences obligatoires des recommandations, et précise pour chacune dans quelles conditions elle s’applique. L’évaluation selon TS 103 701 demande au fabricant de justifier chaque point, pas seulement de l’affirmer.
Quel rapport avec le CRA et la directive RED?
Les trois textes se recoupent largement sur le fond, pas sur le statut.
| ETSI EN 303 645 | Directive RED (EN 18031) | Cyber Resilience Act | |
|---|---|---|---|
| Nature | Norme volontaire | Obligation légale | Obligation légale |
| Périmètre | IoT grand public | Équipements radio connectés | Tous les produits numériques |
| En application | Depuis 2020 | Depuis le 1er août 2025, jusqu’au 10 décembre 2027 | Signalement depuis septembre 2026, complet en décembre 2027 |
| Cycle de vie | Partiel | Peu couvert | Couvert en détail |
ETSI EN 303 645 ne donne pas de présomption de conformité à la RED ni au CRA. En revanche, un produit conçu en la respectant couvre déjà une grande partie des exigences techniques des deux. C’est un bon point de départ, lisible par une équipe produit, avant de passer aux textes obligatoires.
Pour le détail, voir Directive RED et EN 18031 et Cyber Resilience Act: ce qui s’applique depuis le 11 septembre 2026.
Comment l’utiliser
- En début de projet, comme liste de contrôle d’architecture. Treize questions à se poser avant de figer le matériel.
- Dans un appel d’offres, comme exigence envers un fournisseur. Demander la déclaration de conformité exigence par exigence est plus efficace qu’une clause générale. Voir aussi nos 5 questions à poser avant d’acheter un objet connecté.
- Avant la mise sur le marché, comme trame d’audit. Chaque exigence se vérifie par un test.
- En formation, comme fil conducteur. Chaque exigence correspond à une attaque que l’on peut reproduire.
Le lien avec nos formations
Nos trainings suivent cette logique: pour chaque exigence, montrer sur du vrai matériel ce qui arrive quand elle n’est pas respectée, puis comment la tenir. Le parcours Sécurité IoT couvre la majorité des treize points, du mot de passe par défaut à la signature de firmware. Le programme est détaillé dans nos programmes de formation.
Aller plus loin
En savoir plus: https://dvid.eu/fr
Nous contacter: https://dvid.eu/fr#contact
Suivre notre actualité: https://www.linkedin.com/company/dvid/
Sources
- ETSI EN 303 645 V3.1.3 (2024-09), Cyber Security for Consumer Internet of Things: Baseline Requirements
- ETSI, page de référence sur la sécurité de l’IoT grand public: https://www.etsi.org/technologies/consumer-iot-security