Mettre à jour le firmware des bornes de recharge sans risque

Le firmware fait tourner la borne : communication OCPP, gestion de la puissance, lecteur de badge, affichage. Le mettre à jour corrige des défauts et des failles, mais chaque mise à jour est aussi une intervention à risque, potentiellement sur tout un parc à la fois. Ce guide décrit les messages OCPP en jeu, la signature du firmware, la planification et ce que le protocole permet, ou non, en cas d'échec. Pour le panorama des menaces, voir notre article sur la cybersécurité des bornes.

La mise à jour en OCPP 1.6 : UpdateFirmware

Dans la spécification OCPP 1.6, le système central envoie UpdateFirmware avec l'emplacement du fichier (location), la date à partir de laquelle la borne peut le télécharger (retrieveDate) et, en option, un nombre de tentatives (retries) et un intervalle entre tentatives (retryInterval). La borne rend compte de chaque étape par FirmwareStatusNotification :

Si la recharge ne peut pas continuer pendant l'installation, la spécification recommande d'attendre la fin des sessions et de passer en Unavailable les connecteurs libres. Elle qualifie aussi de bonne pratique le fait de redémarrer d'abord, pour vérifier que le nouveau firmware démarre et se reconnecte, avant d'annoncer Installed. Ce n'est pas une obligation : un statut Installed ne prouve donc pas toujours que la borne s'est reconnectée.

Limite d'OCPP 1.6 de base : rien ne garantit l'origine du fichier installé. C'est l'objet de l'extension de sécurité.

Le firmware signé : extension de sécurité 1.6 et OCPP 2.0.1

Le livre blanc de sécurité OCPP 1.6 (4e édition, février 2026) ajoute les messages SignedUpdateFirmware et SignedFirmwareStatusNotification. OCPP 2.0.1 intègre le même mécanisme dans UpdateFirmware (cas d'usage L01, la mise à jour non sécurisée étant le cas L02). Le principe :

• Le CSMS joint à la demande le certificat de signature du firmware. La borne le vérifie contre le certificat racine du fabricant. S'il est invalide, elle refuse (InvalidCertificate) et émet l'événement de sécurité InvalidFirmwareSigningCertificate.
• Après téléchargement, la borne vérifie la signature calculée sur l'ensemble du fichier : RSA-PSS ou ECSchnorr, avec SHA256 pour l'empreinte, selon l'extension 1.6. Signature absente ou fausse : statut InvalidSignature et événement InvalidFirmwareSignature.
• Les statuts s'enrichissent : DownloadScheduled, DownloadPaused, SignatureVerified, InstallScheduled pour une installation à date fixée, InstallRebooting, et en 2.0.1 InstallVerificationFailed.
• Chaque notification reprend le requestId de la demande : le suivi se fait par campagne.
• Il est recommandé de chiffrer le transfert (HTTPS, SFTP ou FTPS) ou le fichier lui-même.

Le Security Operations Guide de l'OCA (version 2.0, septembre 2026) va plus loin : la borne ne doit installer aucun firmware sans en vérifier l'origine et l'intégrité, y compris lors d'une installation locale par un technicien, et le démarrage sécurisé (secure boot) est recommandé quand le matériel le permet.

Planifier un déploiement sur un parc

• Inventaire des versions : la borne déclare sa version dans le BootNotification (champ firmwareVersion). Croisez modèle, version de firmware et version OCPP avant de choisir les cibles.
• Notes de version du fabricant : correctifs de sécurité, clés de configuration modifiées, version intermédiaire éventuellement requise.
• Pilote : quelques bornes par couple modèle et version, suivies en usage réel avant d'élargir.
• Déploiement progressif : l'OCA recommande que les mises à jour ne perturbent pas l'exploitation, par exemple grâce à un déploiement graduel, par phases. Une campagne ratée sur un lot reste un incident local.
• Créneaux : retrieveDate et, avec le firmware signé, installDateTime permettent de télécharger en avance et d'installer aux heures creuses. En 2.0.1, la variable AllowNewSessionsPendingFirmwareUpdate indique si de nouvelles sessions restent possibles pendant que la borne attend de pouvoir installer.
• Droits : seuls des utilisateurs autorisés doivent pouvoir lancer une mise à jour depuis le CSMS, selon l'OCA.
• Contrôle après installation : reconnexion, BootNotification avec la nouvelle version, statuts cohérents, session de test, et vérification que les réglages critiques (adresse du serveur, profil de sécurité, intervalle de Heartbeat) sont intacts.

Pendant la campagne, les connecteurs passent en Unavailable : marquez ces périodes comme arrêts planifiés pour ne pas fausser vos indicateurs de maintenance.

Retour arrière : ce que le protocole permet

OCPP ne définit pas de commande de retour à la version précédente. Revenir en arrière revient à envoyer un nouvel UpdateFirmware avec l'ancien fichier, ce qui n'est pas toujours possible : l'OCA exige que la borne refuse d'installer une version plus ancienne que celle en place (Security Operations Guide v2.0, exigence SEC-0078), pour empêcher un attaquant de réinstaller un firmware dont la faille a été corrigée.

Le plan de repli se prépare donc en amont :

• Une version corrective du fabricant, avec un engagement inscrit au contrat d'achat ou de support.
• Un mécanisme de restauration : l'OCA demande aux fabricants de permettre de rétablir une borne après un incident de sécurité, à partir d'une configuration connue et saine.
• La configuration réseau relevée avant la campagne, pour reconfigurer une borne qui aurait perdu ses paramètres.
• Une capacité d'intervention sur site pour les bornes qui ne se reconnectent plus. C'est le scénario le plus coûteux, et le pilote sert à le faire apparaître avant le déploiement.

Firmware et cybersécurité : le Cyber Resilience Act

Le règlement (UE) 2024/2847 sur la cyberrésilience, publié au Journal officiel le 20 novembre 2024, s'applique aux produits comportant des éléments numériques dont l'utilisation prévue comprend une connexion à un dispositif ou à un réseau (article 2). Ses obligations visent les opérateurs économiques, fabricants en tête, ainsi que mandataires, importateurs et distributeurs, et non l'exploitant qui utilise les bornes. Le calendrier fixé par son article 71 :

• 11 juin 2026 : application du chapitre IV, consacré aux organismes notifiés.
• 11 septembre 2026 : application de l'article 14, qui oblige le fabricant à notifier les vulnérabilités activement exploitées et les incidents graves.
• 11 décembre 2027 : application générale du règlement.

Pour les mises à jour, l'annexe I demande notamment que les vulnérabilités puissent être corrigées par des mises à jour de sécurité, distribuées de façon sécurisée, diffusées sans retard et gratuitement (sauf accord contraire pour un produit sur mesure), et si possible séparément des mises à jour de fonctionnalités. L'article 13 fixe une période d'assistance d'au moins cinq ans, sauf si la durée d'utilisation prévue du produit est plus courte.

Deux limites. Les produits mis sur le marché avant le 11 décembre 2027 ne sont soumis aux exigences que s'ils font l'objet d'une modification substantielle après cette date (article 69), l'obligation de notification de l'article 14 mise à part. Et c'est l'OCA, dans son Security Operations Guide, qui estime que le CRA s'appliquerait aux bornes et au CSMS vendu comme produit, en notant que certaines frontières restent à préciser. Pour l'exploitant, le CRA est surtout un critère d'achat : demandez la période d'assistance, la politique de divulgation des vulnérabilités et le mode de distribution des correctifs.

Ce que JCSM prend en charge

JCSM assure la supervision à distance OCPP et la maintenance de parcs multi-marques, suivi des versions de firmware compris. Nous préparons les campagnes avec vous (inventaire, pilote, lots, contrôle après installation) et intervenons sur site quand une borne ne se reconnecte pas. Voir la supervision et la sécurisation sur notre page exploitation.

Questions fréquentes