Les objets connectes sont la cible primaire du Cyber Resilience Act (reglement (UE) 2024/2847). Et pour cause : l’IoT concentre a lui seul les trois failles structurelles que le CRA entend corriger – des produits livres avec des configurations non securisees, une absence de mises a jour post-commercialisation, et des cycles de vie qui excedent largement la capacite de suivi des fabricants. Avec plus de 15 milliards d’objets connectes en circulation dans le monde en 2025, et une projection a plus de 30 milliards d’ici 2030, le sujet n’a rien de marginal.

Pour les fabricants d’objets connectes, le CRA transforme radicalement les regles du jeu. Voyons concretement ce que cela implique.

I. Pourquoi l’IoT est la cible principale du CRA

Un heritage de negligence securitaire

L’IoT traine un lourd passif en matiere de securite. L’episode Mirai en 2016 reste l’illustration la plus frappante : un botnet constitue de cameras IP, de routeurs et d’enregistreurs video numeriques, tous compromis grace a des identifiants par defaut (admin/admin, root/root), a genere des attaques DDoS d’une puissance inedite, paralysant des services comme Dyn, Twitter ou Netflix. Pres de dix ans plus tard, les variantes de Mirai continuent d’exploiter des appareils dont les fabricants ont disparu ou refuse de publier des correctifs.

Le probleme est systemique. Une etude de l’ENISA estimait en 2023 que plus de 60 % des objets connectes grand public etaient livres avec au moins une vulnerabilite critique. Les raisons sont connues : mots de passe par defaut non modifiables, ports de communication ouverts sans justification, firmware jamais mis a jour, chiffrement absent ou obsolete, collecte de donnees excessive et non documentee.

Des cycles de vie incompatibles avec la securite logicielle

Un thermostat connecte ou un capteur industriel peut rester en service pendant 10, 15, voire 20 ans. Or, la duree de support logiciel de la plupart des appareils IoT excede rarement 2 a 3 ans. Le resultat est previsible : des millions d’appareils restent connectes a des reseaux, sans correctifs, avec des vulnerabilites publiquement connues. Ces appareils deviennent des points d’entree privilegies pour les attaquants.

Le CRA adresse ce probleme frontalement en imposant au fabricant une obligation de gestion des vulnerabilites pendant toute la duree de vie attendue du produit, et en tout etat de cause pendant une duree minimale de cinq ans (article 13, paragraphe 8). Pour un fabricant d’objets connectes industriels dont la duree de vie attendue est de 15 ans, cette obligation change fondamentalement le modele economique.

II. Les obligations specifiques aux produits IoT

Les exigences essentielles de cybersecurite figurent a l’annexe I du CRA. Appliquees aux objets connectes, elles se traduisent par des obligations concretes.

Securite par defaut (secure by default)

Le produit doit etre livre dans une configuration securisee par defaut. Concretement, pour un objet connecte, cela signifie :

• Pas de mots de passe par defaut universels. Chaque appareil doit disposer d’un mot de passe unique genere en usine, ou imposer a l’utilisateur la creation d’un mot de passe robuste lors de la premiere utilisation.
• Interfaces d’administration desactivees par defaut lorsqu’elles ne sont pas indispensables au fonctionnement initial.
• Ports reseau fermes par defaut, sauf ceux strictement necessaires au fonctionnement du produit.
• Fonctionnalites de debogage desactivees avant la mise sur le marche.

Absence de vulnerabilites connues a la livraison

L’article 13, paragraphe 1, impose que les produits soient mis sur le marche sans vulnerabilites exploitables connues. Pour un fabricant IoT, cela presuppose un processus de test de securite (analyse statique du code, tests de penetration, revue des dependances) integre au cycle de developpement, et pas seulement un audit ponctuel avant la commercialisation.

Minimisation des donnees et protection de la vie privee

Le CRA exige que le produit ne collecte que les donnees strictement necessaires a son fonctionnement (principe de minimisation). Ce point resonne directement avec les exigences du RGPD, et en particulier le principe de privacy by design, et impose aux fabricants d’objets connectes de justifier chaque flux de donnees. Un bracelet connecte qui transmet l’integralite des donnees biometriques de l’utilisateur vers un serveur distant sans justification technique precise contrevient a cette exigence.

Communications chiffrees

Toutes les communications du produit – tant celles avec d’autres appareils que celles avec des services distants – doivent etre protegees par des mecanismes de chiffrement adaptes a l’etat de l’art, conformement aux exigences de securite des donnees lorsque des donnees personnelles sont en jeu. Pour les objets connectes, cela implique la mise en oeuvre de protocoles tels que TLS 1.3 ou DTLS pour les communications, et le stockage securise des cles cryptographiques sur l’appareil.

Mecanisme de mise a jour

Le fabricant doit integrer un mecanisme de mise a jour securise. Les mises a jour de securite doivent etre mises a disposition sans frais pour l’utilisateur. Le mecanisme doit garantir l’authenticite et l’integrite des mises a jour (signature cryptographique), permettre la notification de l’utilisateur, et etre suffisamment robuste pour fonctionner meme dans des conditions degradees.

Pour les appareils qui ne disposent pas d’une interface utilisateur (cas frequent dans l’IoT industriel), des mecanismes alternatifs doivent etre prevus – mises a jour par le reseau (OTA), via une application compagnon, ou par l’intermediaire d’une passerelle.

III. Classification des produits IoT

La classification des produits determines les procedures d’evaluation de conformite applicables. Pour les objets connectes, la repartition est la suivante.

Produits par defaut

La majorite des objets connectes grand public sans fonction critique releve de la categorie par defaut : enceintes connectees, ampoules intelligentes, aspirateurs robots. L’evaluation de conformite peut etre realisee par le fabricant lui-meme (auto-evaluation), a condition de respecter les normes harmonisees lorsqu’elles sont disponibles.

Produits importants – Classe I

Les systemes domotiques, les jouets connectes, les routeurs domestiques et les wearables (bracelets, montres connectees) relevent de la classe I. Le fabricant peut encore s’auto-evaluer s’il applique les normes harmonisees, mais a defaut, il doit recourir a une evaluation par un organisme tiers.

Exemple : un fabricant de montres connectees de suivi de sante qui applique l’ensemble des normes harmonisees relatives au CRA peut proceder a l’auto-evaluation. Dans le cas contraire, il devra faire certifier son produit par un organisme notifie.

Produits importants – Classe II

Les capteurs industriels integres a des systemes de controle, les passerelles IoT industrielles, et les routeurs destines a un usage professionnel relevent de la classe II. L’evaluation par un organisme tiers est obligatoire, quelle que soit la conformite aux normes harmonisees.

Produits critiques

Certains objets connectes utilises dans des infrastructures sensibles (passerelles de compteurs intelligents, dispositifs de securite pour les reseaux industriels) relevent de la categorie des produits critiques et necessitent une certification europeenne de cybersecurite.

IV. Les defis specifiques de l’IoT

Appareils aux ressources limitees (constrained devices)

Un capteur de temperature fonctionnant sur batterie avec 32 Ko de memoire RAM ne peut pas executer une pile TLS complete ni un mecanisme de mise a jour sophistique. Le CRA n’ignore pas cette realite mais n’accorde pas d’exemption pour autant. Les fabricants doivent trouver des solutions techniques adaptees : protocoles legers (CoAP avec DTLS, OSCORE), mecanismes de mise a jour differee via passerelle, chiffrement symetrique adapte aux contraintes materielles.

Infrastructures a longue duree de vie

Dans le secteur industriel, les capteurs et actionneurs IoT sont deployes pour des durees pouvant atteindre 15 a 20 ans. L’obligation de support de securite pendant toute la duree de vie du produit pose un defi economique et organisationnel considerable. Les fabricants doivent anticiper des couts de maintenance logicielle sur des periodes que l’industrie logicielle classique ne pratique pas.

IoT grand public vs IoT industriel

Les problematiques different sensiblement. L’IoT grand public (smart home, wearables) pose essentiellement des problemes de vie privee et de surface d’attaque residentielle. L’IoT industriel (OT/ICS) presente des enjeux de surete de fonctionnement : un capteur compromis dans une chaine de production peut avoir des consequences physiques. Le CRA traite ces deux mondes sous le meme cadre reglementaire, mais la classification en categories tient compte de ces differences de risque.

Dispositifs medicaux IoT

Les dispositifs medicaux connectes (moniteurs de glycemie, pacemakers connectes, pompes a insuline) font l’objet d’un traitement specifique. Le CRA ne s’applique pas aux produits deja couverts par les reglements (UE) 2017/745 et 2017/746 sur les dispositifs medicaux, qui contiennent leurs propres exigences de cybersecurite. Toutefois, les accessoires connectes non qualifies de dispositifs medicaux (applications compagnons, passerelles de donnees) peuvent relever du CRA.

V. Feuille de route de mise en conformite pour les fabricants IoT

Les dates cles du CRA imposent un calendrier precis. Le signalement des vulnerabilites activement exploitees est obligatoire depuis septembre 2026. L’ensemble des obligations, y compris la conformite des produits, entre en application le 11 decembre 2027. Voici les etapes a prioriser.

1. Inventaire et classification (T0 a T+3 mois)

Recenser l’ensemble des produits IoT mis sur le marche europeen. Pour chaque produit, determiner la categorie applicable (defaut, classe I, classe II, critique). Identifier les produits qui necessitent une evaluation tierce. Consulter la liste des acteurs concernes par le CRA pour verifier le role de chaque entite dans la chaine de valeur.

2. Analyse d’ecart (T+3 a T+6 mois)

Pour chaque produit, evaluer l’ecart entre l’etat actuel et les exigences de l’annexe I du CRA : securite par defaut, chiffrement, mecanisme de mise a jour, gestion des vulnerabilites. Etablir un SBOM (Software Bill of Materials) pour chaque produit afin d’identifier les dependances et les composants tiers vulnerables.

3. Remediation technique (T+6 a T+18 mois)

Mettre en oeuvre les modifications techniques necessaires : remplacement des mecanismes d’authentification par defaut, integration de mecanismes de mise a jour OTA, implementation du chiffrement des communications, suppression des interfaces de debogage, reduction de la collecte de donnees. Integrer des tests de securite au pipeline de developpement (SAST, DAST, tests de penetration).

4. Mise en place des processus (T+12 a T+18 mois)

Structurer le processus de gestion des vulnerabilites : point de contact pour le signalement, procedure de triage, delais de correction, mecanisme de diffusion des correctifs. Preparer la documentation technique requise, y compris la declaration de conformite et les informations destinees aux utilisateurs.

5. Evaluation de conformite (T+18 a T+24 mois)

Selon la categorie du produit, proceder a l’auto-evaluation ou solliciter un organisme notifie. Apposer le marquage CE attestant de la conformite au CRA.

Conclusion

Le CRA place les objets connectes au coeur de ses exigences, et ce n’est pas un hasard. L’IoT concentre les vulnerabilites les plus critiques et les plus massives du paysage numerique actuel. Pour les fabricants, la mise en conformite ne se limite pas a un exercice documentaire : elle impose une transformation profonde des pratiques de conception, de test et de suivi post-commercialisation. Le delai restant avant l’application pleine du texte en decembre 2027 est serre, compte tenu de l’ampleur des chantiers techniques. Il est urgent d’engager les travaux des maintenant.