La loi européenne sur la cyber-résilience (CRA) change tout, et votre approche actuelle ne sera probablement pas suffisante.
Vous vous souvenez quand « admin/admin » était un mot de passe par défaut acceptable ?
Cette époque est officiellement révolue.
La loi européenne sur la cyber-résilience (CRA) est entrée en vigueur en décembre 2024. Si vous expédiez IoT vers l'Europe, ce n'est pas facultatif, c'est la loi.
Et voici ce qui manque à la plupart des équipes : vos jetons OAuth2, JWT et clés API ne seront probablement pas conformes.
Le problème dont personne ne parle
La CRA n'interdit pas seulement les mots de passe faibles. Elle interdit également tout identifiant partagé ou codé en dur sur l'ensemble de votre parc d'appareils.
Ce secret client intégré dans votre micrologiciel ? Non conforme.
Cette clé API fournie à chaque appareil ? Non conforme.
Cette clé de signature JWT partagée entre tous les produits de votre gamme ? Non conforme.
La réglementation exige que chaque appareil dispose d'une identité unique et sécurisée par cryptographie. Les propriétaires doivent également être en mesure de révoquer les identifiants si un appareil est compromis.
Les infractions sont passibles d'amendes pouvant atteindre 15 millions d'euros ou 2,5 % du chiffre d'affaires mondial.
Le problème des identifiants Bootstrap
Voici ce que les partisans d'OAuth2 et de JWT oublient souvent : vous avez besoin d'un identifiant codé en dur pour obtenir le jeton en premier lieu.
Réfléchissez-y :
Flux d'informations d'identification du client OAuth2 nécessite que votre appareil stocke un client_id et client_secret pour demander un jeton d'accès. Il s'agit de valeurs statiques intégrées dans le micrologiciel, ce qui est précisément ce que la CRA interdit.
L'authentification JWT nécessite que l'appareil dispose d'une clé de signature privée pour générer des jetons. Cette clé doit être fournie d'une manière ou d'une autre. Si la même clé est utilisée pour l'ensemble de votre parc, vous enfreignez les exigences relatives à l'unicité des appareils. Si vous fournissez des clés uniques pour chaque appareil, félicitations : vous êtes en train de mettre en place PKI .
Les clés API et les PAT sont, par définition, des chaînes statiques intégrées dans l'appareil.
La vérité dérangeante ? Ces méthodes ne font que remplacer un secret codé en dur (un mot de passe) par un autre secret codé en dur (un secret client, une clé de signature ou un jeton). Vous n'avez pas résolu le problème de conformité CRA, vous l'avez simplement reformulé.
Pourquoi mTLS est fondamentalement différent
TLS mutuel TLS certificats X.509 résout entièrement le problème du démarrage.
Voici l'idée clé : la clé privée peut être générée sur l'appareil lui-même et n'a jamais besoin d'exister ailleurs.
Au cours de la fabrication, l'appareil génère sa propre paire de clés en interne, idéalement dans un module hardware où la clé privée ne peut littéralement pas être extraite. L'appareil envoie uniquement une demande de signature de certificat (contenant la clé publique) à votre autorité de certification. Le certificat signé vous est renvoyé. C'est terminé.
Pas de secrets partagés. Pas d'informations d'identification à coder en dur. Aucune donnée sensible transmise pendant l'approvisionnement.
Comparez cela à OAuth2, où votre secret client doit être créé côté serveur, puis transféré de manière sécurisée vers chaque appareil de votre flotte.
Ce qu'offre mTLS :
✅ Chaque appareil reçoit un certificat unique avec sa propre paire de clés.
✅ Les clés privées ne quittent jamais l'appareil, jamais.
✅ Aucun secret codé en dur dans le micrologiciel
✅ Révocation individuelle des appareils via des listes de révocation de certificats
✅ Authentification mutuelle : l'appareil vérifie le serveur, le serveur vérifie l'appareil.
AWS IoT , Azure IoT et Google Cloud IoT recommandent IoT l'authentification par certificat X.509 précisément pour ces raisons.
Ce que cela signifie pour votre feuille de route
D'ici décembre 2027, vos appareils devront être conformes. Cela semble lointain, mais réfléchissez-y :
-
Les cycles Hardware durent entre 18 et 24 mois.
-
La conception PKI prend du temps.
-
La fabrication nécessite l'intégration de la fourniture de certificats
-
Votre backend doit prendre en charge mTLS.
Les équipes qui se lancent dès maintenant bénéficieront d'un avantage concurrentiel. Celles qui attendront devront se démener pour intégrer des mesures de sécurité dans des produits qui n'ont jamais été conçus dans ce but.
Le bilan
La CRA ne vous demande pas de choisir un meilleur identifiant codé en dur. Elle vous demande d'éliminer complètement les identifiants codés en dur.
OAuth2 et JWT n'ont pas été conçus pour ce monde. Ils résolvent brillamment les problèmes d'authentification des utilisateurs. Mais pour l'identité des appareils soumise aux exigences de la CRA, ils ne font que déplacer la violation de conformité d'un endroit à un autre.
Le mTLS avec certificats X.509 est différent sur le plan architectural. C'est la seule approche qui évite d'avoir à partager, transmettre ou coder en dur les informations d'identification sensibles.
Les entreprises qui comprennent cette distinction dès maintenant fabriqueront des produits conformes. Celles qui ne la comprennent pas devront se mettre à niveau ou quitter le marché européen.
Peu importe où vous en êtes dans votre parcours en matière de sécurité, nos experts sont là pour vous aider. Réservez une démonstration pour nous en dire plus sur votre organisation et de vos objectifs.
