Mises à jour du firmware OTA et Cyber Resilience Act : le patch en tant qu’obligation de service
Les mises à jour OTA ne sont plus seulement une commodité : elles sont une obligation légale
Lorsqu’un fabricant chinois de robots expédie un bras manipulateur ou un robot mobile autonome dans l’Union européenne, le firmware de cet appareil est désormais soumis au Cyber Resilience Act (CRA). Le règlement, publié au Journal officiel de l’UE sous le numéro (UE) 2024/2847, transforme les mises à jour over-the-air (OTA) d’une fonctionnalité qui ravit les clients en une obligation de conformité qui peut déterminer l’accès au marché. Pour un réseau de service en cours de mise en place en Europe, la conséquence pratique est claire : le patch n’est pas une correction occasionnelle mais un service continu qui doit être planifié, documenté et exécuté en gardant à l’esprit la sécurité.
Le CRA n’exige pas seulement que les vulnérabilités soient corrigées ; il exige que le mécanisme de mise à jour lui-même soit sécurisé. L’annexe I, partie I, point 2(d) du règlement impose que les éléments numériques soient conçus pour « limiter les surfaces d’attaque » et pour « minimiser l’impact d’un incident ». Plus précisément, le point 2(f) exige que les mises à jour de sécurité soient fournies en temps utile et que le mécanisme de mise à jour soit sécurisé. Cela signifie qu’un système OTA qui permet un firmware non signé ou qui peut être interrompu par une attaque de l’homme du milieu n’est pas conforme, même si le contenu de la mise à jour est correct.
Ce que le CRA exige des mécanismes de mise à jour
Le règlement énonce plusieurs exigences de sécurité concrètes pour les mises à jour OTA. En vertu de l’annexe I, partie I, point 2(f), les fabricants doivent s’assurer que les mises à jour sont « prises en charge par des mécanismes sécurisés » qui empêchent l’installation de firmware non autorisé. Cela implique la signature cryptographique des packages de mise à jour, la vérification de la source de la mise à jour et des contrôles d’intégrité avant l’installation. De plus, le processus de mise à jour ne doit pas introduire de nouvelles vulnérabilités, par exemple, il ne doit pas permettre un retour à une version présentant des vulnérabilités critiques connues, sauf autorisation explicite et journalisation.
L’article 13(8) du CRA ajoute une autre couche : les fabricants doivent s’assurer que les vulnérabilités exploitables sont « efficacement atténuées » par des mises à jour de sécurité fournies gratuitement. Le règlement ne spécifie pas de fenêtre de temps fixe, mais il exige que les mises à jour soient fournies « sans délai indu » après la découverte d’une vulnérabilité. Pour un réseau de service, cela crée un défi logistique : comment pousser un correctif critique vers des centaines de robots dans plusieurs États membres de l’UE, chacun avec des connectivités et des calendriers de maintenance différents ?
De plus, l’article 13(9) exige que les fabricants documentent et informent les utilisateurs des mises à jour, y compris de leur impact sur la sécurité. Cela signifie que chaque mise à jour OTA doit être accompagnée de notes de version expliquant ce qui a été corrigé et pourquoi. Pour un fournisseur de services tiers, cette documentation fait partie du dossier de service, qui peut être audité par les autorités nationales de surveillance du marché.
Expédition de firmware vulnérable : qui est responsable ?
Le CRA déplace considérablement la responsabilité. En vertu de l’article 13(1), les fabricants doivent s’assurer que les produits sont mis sur le marché sans vulnérabilités exploitables connues. Il s’agit d’une obligation stricte : si un robot est expédié avec une version de firmware présentant une vulnérabilité critique connue, le fabricant est en infraction, même si la vulnérabilité a été divulguée après la conception du produit. La seule défense est que la vulnérabilité était inconnue au moment de la mise sur le marché, mais la charge de la preuve incombe au fabricant.
Pour un réseau de service, cette responsabilité a un effet d’entraînement. Si un fabricant s’appuie sur un partenaire local pour effectuer les mises à jour, le fabricant reste responsable de la sécurité du produit. Cependant, le fournisseur de services peut être tenu responsable en vertu du droit général des contrats s’il ne parvient pas à effectuer correctement une mise à jour, ou s’il installe une mise à jour qui introduit une nouvelle vulnérabilité. Le CRA ne réglemente pas directement les fournisseurs de services, mais il exige que les fabricants s’assurent que « le produit est accompagné des informations et instructions » nécessaires à une installation et une utilisation sécurisées (annexe I, partie I, point 2(i)). Cela signifie qu’un réseau de service doit avoir accès à une documentation technique détaillée et doit suivre les procédures de mise à jour du fabricant à la lettre.
En pratique, cela signifie qu’un contrat de service doit clairement définir qui est responsable du suivi des divulgations de vulnérabilités, qui décide quand pousser une mise à jour, et qui supporte le coût d’une mise à jour échouée. Le CRA n’impose pas une répartition spécifique du travail, mais il exige que le fabricant dispose d’un processus de « divulgation coordonnée » des vulnérabilités (article 13(5)). Un réseau de service peut agir comme les yeux et les oreilles du fabricant sur le terrain, signalant les incidents et vérifiant que les correctifs sont appliqués correctement.
OTA versus mise à jour physique : une comparaison
Bien que les mises à jour OTA soient souvent le moyen le plus efficace de patcher le firmware, elles ne sont pas toujours possibles. Certains robots fonctionnent dans des réseaux isolés, certains ont des fonctions critiques pour la sécurité qui nécessitent une intervention physique, et certains ont du matériel qui ne prend pas en charge l’OTA sécurisé. Le tableau suivant compare les deux approches du point de vue du service et de la conformité.
| Aspect | Mise à jour OTA | Mise à jour physique |
|---|---|---|
| Vitesse de déploiement | Peut être poussée vers de nombreux appareils simultanément, souvent en quelques heures | Nécessite la planification d’une visite de technicien ; peut prendre des jours ou des semaines pour de grandes flottes |
| Sécurité du mécanisme de mise à jour | Doit implémenter une signature cryptographique, des canaux sécurisés et des contrôles d’intégrité (CRA Annexe I Partie I 2(f)) | L’accès physique réduit le risque d’interception à distance, mais nécessite une manipulation sécurisée des supports de mise à jour et la vérification de l’identité du technicien |
| Documentation et piste d’audit | Journalisation automatique des tentatives de mise à jour, des succès/échecs et de l’état de l’appareil ; plus facile de fournir des preuves de conformité | Nécessite une journalisation manuelle ; risque d’erreur humaine ou de dossiers incomplets |
| Coût par mise à jour | Coût marginal faible après l’investissement initial dans l’infrastructure | Élevé : temps de déplacement, main-d’œuvre et temps d’arrêt potentiel |
| Adaptation aux systèmes critiques pour la sécurité | Peut nécessiter une validation supplémentaire ; certaines fonctions de sécurité peuvent nécessiter une présence physique pour vérification | Préféré lorsqu’un technicien doit inspecter visuellement le robot ou lorsqu’une sécurité intégrée est nécessaire |
| Conformité à l’exigence de mise à jour gratuite du CRA | Plus facile de fournir des mises à jour gratuites, car pas de frais de déplacement | Peut être gratuit, mais le coût de la main-d’œuvre doit être absorbé par le fabricant ou le contrat de service |
Le choix entre les mises à jour OTA et physiques n’est pas binaire. De nombreux fabricants utilisent une approche hybride : OTA pour le firmware non critique, et visites physiques pour les mises à niveau majeures ou les correctifs liés à la sécurité. Pour un réseau de service, cela signifie développer des capacités dans les deux domaines, mais avec une compréhension claire que l’OTA est la solution par défaut pour la conformité car elle est plus rapide et plus auditable.
Implications pratiques pour un réseau de service
Pour un réseau de service local en cours de mise en place en Europe, le CRA crée une nouvelle source de revenus : le patch en tant que service. Les fabricants peuvent externaliser la surveillance des bases de données de vulnérabilités, la préparation des packages de mise à jour et la vérification de l’installation réussie. Cependant, cela nécessite un niveau d’expertise technique et de sensibilisation juridique qui va au-delà de la réparation traditionnelle.
Premièrement, le réseau doit avoir accès au processus de divulgation des vulnérabilités du fabricant. Le CRA exige que les fabricants maintiennent un « point de contact unique » pour le signalement des vulnérabilités (article 13(5)), mais il ne les oblige pas à le partager avec des tiers. Un contrat de service doit donc inclure des dispositions pour que le fabricant notifie au fournisseur de services les vulnérabilités pertinentes et fournisse les correctifs nécessaires.
Deuxièmement, le réseau doit être en mesure de vérifier qu’une mise à jour est authentique et n’a pas été altérée. Cela signifie que les techniciens doivent comprendre les signatures cryptographiques et être capables de les vérifier avant l’installation. En pratique, cela peut impliquer l’utilisation d’un chargeur de démarrage sécurisé qui n’accepte que le firmware signé, mais le technicien doit toujours confirmer que le package de mise à jour correspond aux notes de version du fabricant.
Troisièmement, le réseau doit tenir des registres méticuleux. En vertu de l’article 13(9), les fabricants doivent informer les utilisateurs des mises à jour, mais un fournisseur de services peut avoir besoin de documenter qu’une mise à jour a été appliquée à un appareil spécifique, à quelle heure et avec quel résultat. Cela n’est pas seulement pour la conformité mais aussi pour la protection contre la responsabilité : si un robot tombe en panne après une mise à jour, le fournisseur de services doit être en mesure de prouver que la mise à jour a été effectuée correctement.
Enfin, le réseau doit être préparé à la possibilité qu’un fabricant fasse faillite ou cesse de prendre en charge un produit. Le CRA exige que les fabricants fournissent des mises à jour de sécurité pendant la « durée de vie attendue » du produit (article 13(8)), mais si le fabricant disparaît, la responsabilité peut incomber aux importateurs ou aux distributeurs. Un réseau de service peut intervenir pour fournir des mises à jour, mais il doit en avoir le droit légal, ce qui souligne à nouveau la nécessité de contrats clairs.
Sources
- EUR-Lex — Règlement (UE) 2024/2847 — https://eur-lex.europa.eu/eli/reg/2024/2847/oj (consulté le 2026-03-14)
- Commission européenne — Cyber Resilience Act — https://digital-strategy.ec.europa.eu/ (consulté le 2026-03-14)