Cybersécurité IRVE : les bornes de recharge sont-elles vulnérables ?

Pourquoi les bornes de recharge sont des cibles

En mars 2026, la France compte plus de 180 000 points de recharge ouverts au public. Chacun de ces points est un ordinateur connecté à Internet, relié au réseau électrique, capable de traiter des paiements par carte bancaire et de communiquer avec un serveur central. Cette convergence de fonctions fait des bornes de recharge des cibles particulièrement attractives pour les cyberattaquants. Pourtant, la cybersécurité des infrastructures de recharge pour véhicules électriques (IRVE) reste un angle mort dans de nombreux déploiements.

Les bornes IRVE ne sont pas de simples prises électriques. Elles embarquent un contrôleur logique, un module de communication (4G, Ethernet, Wi-Fi), un lecteur de badge RFID, un terminal de paiement, et parfois un écran tactile avec un système d'exploitation complet. Chacun de ces composants constitue une surface d'attaque potentielle.

Le risque est amplifié par trois facteurs. Premièrement, les bornes sont physiquement accessibles : elles sont installées sur des parkings, en voirie, dans des centres commerciaux. Un attaquant peut s'en approcher sans éveiller de soupçons. Deuxièmement, elles sont souvent déployées par des acteurs dont le métier initial n'est pas la cybersécurité : énergéticiens, gestionnaires de parking, collectivités. Troisièmement, le rythme de déploiement est tel que la sécurité passe parfois au second plan, derrière les impératifs de volume et de délais.

Les conséquences d'une attaque réussie vont bien au-delà du simple désagrément. Vol de données bancaires des utilisateurs, interruption de service sur un réseau entier, manipulation des compteurs d'énergie, accès au réseau informatique de l'exploitant, voire déstabilisation du réseau électrique local par injection de charges non contrôlées. L'enjeu est à la fois économique, réputationnel et sécuritaire.

Les vecteurs d'attaque sur les bornes de recharge

Les surfaces d'attaque d'une borne IRVE sont multiples. Elles se répartissent en quatre grandes catégories : le protocole de communication, le firmware, les systèmes de paiement et les interfaces physiques.

Interception et manipulation du protocole OCPP

Le protocole OCPP (Open Charge Point Protocol) est le standard de communication entre les bornes et le système de gestion central (CSMS). En version 1.6, encore majoritairement déployée, la connexion WebSocket peut fonctionner sans chiffrement TLS. Les messages circulent alors en clair entre la borne et le serveur.

Un attaquant positionné sur le réseau (attaque « man-in-the-middle ») peut intercepter les échanges, lire les identifiants RFID des utilisateurs, modifier les commandes envoyées à la borne, ou injecter de faux messages. Il peut par exemple envoyer une commande RemoteStartTransaction pour démarrer une session de recharge gratuite, ou un ChangeConfiguration pour modifier le comportement de la borne.

En OCPP 1.6, l'authentification de la borne auprès du CSMS repose sur un simple identifiant (ChargeBoxIdentity), sans mécanisme cryptographique. Une borne compromise ou un simulateur peut se connecter au CSMS en usurpant l'identité d'une borne légitime. Le CSMS n'a aucun moyen de vérifier que l'interlocuteur est bien la borne physique qu'il prétend être.

Attaques sur le firmware

Le firmware est le logiciel embarqué dans le contrôleur de la borne. Il gère l'ensemble des opérations : authentification des utilisateurs, gestion de la puissance, communication OCPP, affichage écran. Une modification malveillante du firmware permet à l'attaquant de prendre le contrôle total de la borne.

Les vecteurs d'attaque sur le firmware sont multiples. Le port USB de maintenance, souvent accessible en ouvrant le capot de la borne, permet de flasher un firmware modifié. La mise à jour à distance (OTA - Over The Air), si elle ne vérifie pas la signature cryptographique du fichier, peut être détournée. Un serveur de mise à jour compromis peut distribuer un firmware vérolé à l'ensemble d'un parc.

Certaines bornes utilisent des systèmes d'exploitation Linux embarqués avec des composants logiciels non mis à jour (OpenSSL, noyau Linux), exposant des vulnérabilités connues et documentées (CVE). L'absence de mécanisme de « secure boot » (vérification de l'intégrité du firmware au démarrage) permet à un firmware modifié de persister après un redémarrage.

Systèmes de paiement

Les bornes équipées de terminaux de paiement par carte bancaire (conformité PCI DSS requise) présentent des risques spécifiques. L'installation d'un « skimmer » physique (dispositif de lecture frauduleuse) sur le terminal de paiement permet de capturer les données de carte. Ce risque est accentué par l'implantation des bornes dans des zones peu surveillées et accessibles 24h/24.

Au-delà du skimming physique, les attaques logiques sur les terminaux de paiement intégrés sont documentées. Injection de code dans le processus de transaction, interception des données de carte avant chiffrement, manipulation du montant de la transaction. Les bornes dont le terminal de paiement partage le même réseau que le contrôleur OCPP sont particulièrement exposées : une compromission du contrôleur donne accès au flux de paiement.

Clonage RFID et usurpation d'identité

La majorité des bornes utilisent des badges RFID pour l'authentification des utilisateurs. Les cartes MIFARE Classic, encore largement répandues dans le secteur IRVE, utilisent un chiffrement (Crypto-1) cassé depuis 2008. Un attaquant équipé d'un lecteur NFC à moins de 50 euros peut lire et cloner un badge en quelques secondes, à l'insu de son propriétaire.

Le badge cloné permet de démarrer des sessions de recharge facturées au compte de la victime. Il permet aussi de se connecter au portail utilisateur de l'opérateur si le même identifiant RFID sert de clé d'authentification. Les cartes MIFARE DESFire EV2/EV3, avec un chiffrement AES-128, offrent une meilleure résistance mais ne sont pas encore généralisées.

Attaques réseau et pivot

Une borne connectée au réseau local d'un site (entreprise, centre commercial, copropriété) constitue un point d'entrée potentiel vers l'infrastructure informatique du site. Si la borne est sur le même VLAN que les serveurs de l'entreprise, sa compromission permet un « pivot » : l'attaquant utilise la borne comme passerelle pour explorer et attaquer le réseau interne.

Ce scénario est particulièrement préoccupant pour les déploiements en entreprise, où les bornes sont parfois connectées au réseau bureautique par commodité. La sécurisation des installations physiques ne suffit pas : la segmentation réseau est indispensable.

Cas concrets d'incidents de cybersécurité IRVE

Les incidents de cybersécurité sur les bornes de recharge ne sont plus théoriques. Plusieurs cas documentés illustrent la réalité de la menace.

Bornes piratées en Ukraine et au Royaume-Uni (2022)

En février 2022, des bornes de recharge rapide le long d'autoroutes ukrainiennes ont affiché des messages de propagande anti-russe après compromission de leur système d'affichage. L'attaque exploitait une faille dans le système de gestion des écrans, connecté au CSMS sans authentification TLS. La même année, des bornes au Royaume-Uni (réseau GeniePoint) ont été rendues indisponibles pendant plusieurs jours après une attaque ciblant le backend de supervision.

Vulnérabilités Schneider Electric et ABB (2023-2024)

En 2023, des chercheurs en sécurité de Pentest Partners ont révélé des vulnérabilités critiques dans les bornes EVLink de Schneider Electric : accès root via le port série sans mot de passe, clé API codée en dur dans le firmware, et absence de vérification de l'intégrité des mises à jour. Schneider a publié des correctifs, mais les bornes non mises à jour restent exposées.

ABB a fait l'objet de divulgations similaires sur sa gamme Terra : interface web de configuration accessible sans authentification depuis le réseau local, stockage de mots de passe en clair dans la mémoire flash. Ces vulnérabilités sont représentatives d'un problème systémique : les fabricants de bornes sont des électriciens et des industriels, pas des éditeurs de logiciels. La culture de la sécurité logicielle y est encore en construction.

Fraude massive par clonage RFID en Allemagne (2024)

En 2024, la police fédérale allemande a démantelé un réseau de fraude qui avait cloné plus de 2 000 badges de recharge sur des réseaux publics. Les fraudeurs opéraient dans des parkings de centres commerciaux, clonaient les badges des utilisateurs pendant qu'ils faisaient leurs courses, puis revendaient les données d'accès en ligne. Le préjudice total dépassait 800 000 euros.

Ransomware sur un CPO européen (2025)

Début 2025, un opérateur de points de charge (CPO) européen gérant 15 000 bornes dans quatre pays a subi une attaque par ransomware. Le vecteur initial : une borne dont le firmware contenait un agent de reverse shell, installé lors d'une mise à jour non signée. L'attaquant a pivoté de la borne vers le CSMS, puis vers les systèmes de facturation. Le réseau entier a été hors service pendant 72 heures. La rançon demandée était de 2,3 millions d'euros.

Les normes et référentiels applicables

Plusieurs normes et standards encadrent la cybersécurité des infrastructures de recharge. Leur adoption est inégale, mais la pression réglementaire s'intensifie.

ISO 15118 : sécurité de la communication véhicule-borne

La norme ISO 15118 définit le protocole de communication entre le véhicule électrique et la borne de recharge. Sa partie sécurité (ISO 15118-2 et ISO 15118-20) impose l'utilisation de TLS 1.2 minimum pour le canal de communication, l'authentification mutuelle par certificats X.509, et le chiffrement de bout en bout des données échangées.

Le « Plug & Charge » (PnC), prévu par ISO 15118, remplace le badge RFID par un certificat numérique stocké dans le véhicule. L'utilisateur branche son câble, le véhicule s'identifie automatiquement via un échange de certificats, et la session démarre sans intervention manuelle. Ce mécanisme élimine le risque de clonage RFID, mais nécessite une infrastructure PKI (Public Key Infrastructure) robuste pour la gestion des certificats.

ISO 15118-20 (publiée en 2022) étend le protocole à la recharge bidirectionnelle (V2G) et impose des exigences de sécurité renforcées : rotation automatique des certificats, révocation en temps réel, et isolation cryptographique des sessions.

OCPP 2.0.1 : les profils de sécurité

OCPP 2.0.1 définit trois profils de sécurité hiérarchiques pour la communication borne-CSMS :

• Profil 1 (Security Profile 1) : authentification par mot de passe HTTP Basic. Le mot de passe est transmis dans l'en-tête de la connexion WebSocket. Niveau de sécurité minimal, comparable à OCPP 1.6
• Profil 2 (Security Profile 2) : TLS avec certificat serveur. La borne vérifie l'identité du CSMS via un certificat X.509. Le canal est chiffré. La borne s'authentifie par mot de passe dans le tunnel TLS
• Profil 3 (Security Profile 3) : TLS mutuel (mTLS). La borne et le CSMS s'authentifient mutuellement par certificats X.509. C'est le niveau requis pour le Plug & Charge et le seul profil qui garantit l'identité de la borne

OCPP 2.0.1 intègre aussi la gestion du cycle de vie des certificats (installation, renouvellement, révocation), la vérification de signature des firmwares avant installation, et le chiffrement des données sensibles stockées localement (clés, mots de passe).

IEC 62351 : sécurité des communications pour les systèmes électriques

La norme IEC 62351, initialement conçue pour les réseaux électriques intelligents (smart grids), s'applique de plus en plus aux bornes IRVE dans le contexte du V2G. Elle définit des exigences de sécurité pour les protocoles de communication utilisés dans les systèmes de gestion de l'énergie : authentification, chiffrement, intégrité des messages, gestion des accès, journalisation des événements de sécurité.

Pour les bornes intégrées dans des micro-grids ou participant à des programmes d'effacement (demand response), IEC 62351 devient un référentiel incontournable. Elle impose notamment l'utilisation de TLS 1.3, la rotation périodique des clés, et la détection d'anomalies dans les flux de données énergétiques.

Directive NIS2 et réglement AFIR

La directive européenne NIS2 (Network and Information Security), entrée en application en octobre 2024, élargit le périmètre des entités soumises à des obligations de cybersécurité. Les opérateurs d'infrastructures de recharge de grande taille (plus de 1 000 points de charge ou chiffre d'affaires supérieur à 10 millions d'euros) sont désormais considérés comme des « entités importantes » au sens de NIS2.

Les obligations incluent : analyse de risques documentée, mesures de sécurité proportionnées, notification des incidents significatifs à l'ANSSI dans les 24 heures, et responsabilité de la direction en cas de manquement. Le règlement AFIR (Alternative Fuels Infrastructure Regulation) complète ce cadre en imposant des exigences d'interopérabilité et de disponibilité qui impliquent indirectement des mesures de cybersécurité.

Bonnes pratiques de sécurisation

Sécuriser un réseau de bornes IRVE ne demande pas des investissements disproportionnés. Les mesures les plus efficaces relèvent des fondamentaux de la sécurité informatique, appliqués au contexte spécifique de la recharge électrique.

Segmentation réseau

C'est la mesure la plus importante et la plus souvent négligée. Chaque borne doit être isolée dans un VLAN dédié, séparé du réseau bureautique, du réseau de vidéosurveillance et du réseau de gestion du bâtiment. Le trafic entre le VLAN des bornes et le reste de l'infrastructure doit passer par un pare-feu avec des règles restrictives (whitelist).

En pratique, la borne ne doit pouvoir communiquer qu'avec son CSMS (un seul endpoint, un seul port). Toute communication vers d'autres destinations doit être bloquée. Si la borne dispose d'un terminal de paiement, celui-ci doit avoir son propre réseau isolé, distinct du réseau OCPP. La segmentation empêche le pivot réseau : même si la borne est compromise, l'attaquant reste confiné.

Chiffrement TLS systématique

Toute communication entre la borne et le CSMS doit être chiffrée en TLS 1.2 minimum (TLS 1.3 recommandé). Le profil de sécurité 2 d'OCPP 2.0.1 est le minimum acceptable pour un déploiement en 2026. Le profil 3 (TLS mutuel) est recommandé pour les réseaux publics et obligatoire pour le Plug & Charge.

Les certificats TLS doivent être émis par une autorité de certification de confiance, avec une durée de validité limitée (1 an maximum) et un mécanisme de renouvellement automatique. Les suites cryptographiques faibles (RC4, DES, SHA-1) doivent être désactivées côté serveur et côté borne. OCPP 2.0.1 intègre les messages nécessaires à la gestion du cycle de vie des certificats directement dans le protocole.

Signature et vérification du firmware

Chaque mise à jour firmware doit être signée numériquement par le fabricant. La borne doit vérifier la signature avant d'appliquer la mise à jour. OCPP 2.0.1 prend en charge nativement ce mécanisme via le message UpdateFirmware, qui inclut un champ pour la signature et le certificat de vérification.

Le « secure boot » garantit que seul un firmware authentique peut démarrer sur la borne. Si le firmware a été altéré (modification physique via le port USB, par exemple), la borne refuse de démarrer et signale l'anomalie. Cette fonctionnalité doit être un critère de sélection lors de l'achat de nouvelles bornes.

Les mises à jour de sécurité doivent être déployées dans un délai raisonnable après publication par le fabricant. Un processus de gestion des mises à jour (patch management) doit être formalisé, avec un calendrier de déploiement, des tests sur un lot pilote, et une procédure de rollback en cas de régression.

Surveillance et détection d'anomalies

Un réseau de bornes doit être surveillé en continu, pas seulement pour les pannes matérielles, mais aussi pour les événements de sécurité. Les logs de connexion OCPP, les tentatives d'authentification échouées, les changements de configuration non autorisés, les communications vers des adresses IP inconnues : tous ces signaux doivent être collectés et analysés.

La supervision à distance ne se limite pas au monitoring de disponibilité. Elle doit inclure une couche de détection d'intrusion (IDS) adaptée au contexte IRVE : alertes sur les connexions OCPP depuis des adresses IP non autorisées, détection des scans de ports, surveillance des volumes de données anormaux, identification des bornes qui cessent de communiquer sans raison apparente.

Les événements de sécurité doivent être centralisés dans un SIEM (Security Information and Event Management) et corrélés avec les données d'exploitation. Une borne qui redémarre anormalement et change de version firmware sans commande du CSMS est un signal d'alerte majeur.

Durcissement des bornes

Le durcissement (hardening) consiste à réduire la surface d'attaque de chaque borne en désactivant les fonctionnalités inutiles et en renforçant les configurations par défaut :

• Changer les mots de passe par défaut de toutes les interfaces d'administration (web, SSH, OCPP). Utiliser des mots de passe uniques par borne, stockés dans un gestionnaire centralisé
• Désactiver les ports et services inutiles : SSH si non nécessaire, interface web d'administration locale, serveur FTP embarqué, protocoles de découverte réseau (mDNS, UPnP)
• Protéger les accès physiques : verrouillage du capot avec serrure renforcée, détecteur d'ouverture connecté au CSMS, désactivation ou protection du port USB de maintenance
• Configurer le pare-feu embarqué (quand disponible) pour n'autoriser que les flux sortants vers le CSMS et le serveur NTP
• Activer la journalisation locale avec rotation des logs et remontée vers le CSMS pour analyse centralisée

Gestion des accès et des identités

L'accès aux systèmes de gestion (CSMS, portail opérateur, outils de maintenance) doit être contrôlé par une authentification forte (MFA - Multi-Factor Authentication). Les comptes techniques doivent avoir des droits limités au strict nécessaire (principe du moindre privilège). Les sessions d'administration doivent être tracées et les accès révoqués immédiatement quand un collaborateur quitte l'organisation.

Pour les techniciens de terrain, l'accès à l'interface locale de la borne (panneau de configuration, port de maintenance) doit nécessiter une authentification distincte de celle du CSMS. Un technicien qui intervient sur une borne ne doit pas disposer des droits d'administration du CSMS. La gestion des habilitations doit être revue trimestriellement.

Le rôle du CPO et du mainteneur dans la cybersécurité

La cybersécurité d'un réseau IRVE n'est pas la responsabilité exclusive du fabricant de bornes. Elle se répartit entre trois acteurs : le fabricant, le CPO (Charge Point Operator) et le mainteneur.

Le fabricant : sécurité du produit

Le fabricant est responsable de la sécurité du firmware, du matériel et des mises à jour. Il doit intégrer la sécurité dès la conception (security by design) : secure boot, chiffrement du stockage local, ports de maintenance protégés, support des profils de sécurité OCPP 2.0.1. Il doit aussi maintenir un processus de réponse aux vulnérabilités : publication de correctifs dans des délais raisonnables, notification proactive des CPO, documentation des CVE.

Le choix du fabricant est un acte de cybersécurité. Les critères à évaluer : fréquence des mises à jour de sécurité, durée de support du firmware (minimum 5 ans), existence d'un programme de « bug bounty » ou d'audits de sécurité indépendants, certifications obtenues (IEC 62443, EN 303 645).

Le CPO : sécurité opérationnelle

Le CPO est responsable de l'environnement dans lequel les bornes opèrent. La segmentation réseau, le déploiement des mises à jour, la configuration des profils de sécurité OCPP, la surveillance des événements, la gestion des accès au CSMS : tout cela relève du CPO. Il doit disposer d'une politique de sécurité documentée et la faire appliquer par ses prestataires.

Le CPO doit aussi anticiper les incidents : plan de réponse aux incidents documenté, contacts d'urgence identifiés, procédure de communication vers les utilisateurs en cas de compromission de données personnelles (obligation RGPD et NIS2), capacité à isoler une borne ou un groupe de bornes compromises sans affecter le reste du réseau.

Le mainteneur : sécurité en intervention

Le mainteneur intervient physiquement sur les bornes. Il doit être formé aux risques de cybersécurité : ne pas brancher de clé USB non vérifiée sur le port de maintenance, vérifier l'intégrité physique du terminal de paiement à chaque intervention, signaler toute anomalie (capot déjà ouvert, câble inconnu branché, autocollant suspect sur le lecteur RFID).

Chez JCSM, nos équipes de maintenance intègrent un protocole de vérification de sécurité à chaque intervention terrain. Chaque technicien dispose d'identifiants individuels, tracés et révocables. Les interventions sont documentées dans un rapport d'intervention horodaté et géolocalisé, accessible au CPO via le centre d'appel.

Checklist sécurité pour un réseau de bornes

Cette checklist couvre les mesures essentielles à vérifier lors du déploiement et de l'exploitation d'un réseau IRVE. Elle est organisée par priorité d'implémentation.

Priorité 1 : mesures immédiates

• Tous les mots de passe par défaut des bornes sont changés (interface web, SSH, OCPP)
• Les connexions OCPP utilisent TLS 1.2+ (profil de sécurité 2 minimum)
• Les bornes sont dans un VLAN dédié, isolé du réseau bureautique
• Le CSMS exige une authentification avant d'accepter une connexion de borne
• Les accès au CSMS sont protégés par MFA
• Les terminaux de paiement sont conformes PCI DSS et sur un réseau isolé
• Un inventaire à jour de toutes les bornes existe (modèle, firmware, version OCPP)

Priorité 2 : mesures à planifier (3 mois)

• Un processus de déploiement des mises à jour firmware est formalisé (test, validation, déploiement, rollback)
• Les bornes vérifient la signature des firmwares avant installation
• Les logs OCPP et les événements de sécurité sont centralisés et analysés
• Un pare-feu filtre le trafic des bornes (whitelist : CSMS + NTP uniquement)
• Les badges RFID utilisent un chiffrement AES (MIFARE DESFire EV2/EV3 minimum)
• Les accès physiques aux bornes sont sécurisés (serrure, détecteur d'ouverture)
• La matrice de responsabilités cybersécurité (fabricant / CPO / mainteneur) est contractualisée

Priorité 3 : mesures d'excellence (6-12 mois)

• Migration vers OCPP 2.0.1 profil de sécurité 3 (TLS mutuel) pour les bornes compatibles
• Déploiement du Plug & Charge (ISO 15118) avec infrastructure PKI
• Test d'intrusion annuel sur le réseau de bornes et le CSMS
• Plan de réponse aux incidents documenté et testé (exercice de simulation)
• Conformité NIS2 auditée (si applicable)
• Surveillance continue avec SIEM et alertes automatisées sur les indicateurs de compromission
• Revue trimestrielle des habilitations et des accès
• Secure boot activé sur toutes les bornes neuves

Conclusion : la cybersécurité, un prérequis pour la mobilité électrique

La transition vers la mobilité électrique repose sur la confiance des utilisateurs dans l'infrastructure de recharge. Cette confiance est fragile. Un incident de cybersécurité majeur, avec fuite de données bancaires ou interruption prolongée de service, peut porter un coup durable à l'adoption des véhicules électriques.

Les outils existent : OCPP 2.0.1, ISO 15118, TLS mutuel, signature firmware, segmentation réseau. Le cadre réglementaire se renforce avec NIS2 et AFIR. Ce qui manque le plus, c'est l'exécution sur le terrain : des bornes correctement configurées, des réseaux correctement segmentés, des mises à jour correctement déployées, des incidents correctement détectés.

La cybersécurité IRVE n'est pas un projet ponctuel. C'est un processus continu, qui doit être intégré dans l'exploitation quotidienne du réseau au même titre que la maintenance préventive ou la gestion des pannes. Les opérateurs qui l'intégreront en amont de leurs déploiements disposeront d'un avantage compétitif décisif face à ceux qui devront réagir après un incident.