Maintenance des dispositifs médicaux connectés

Les services d’ingénierie biomédicale planifient traditionnellement la maintenance en fonction des échéances de contrôle, des consignes du fabricant et du coût des pannes. Pour les appareils connectés, cela ne suffit plus : un échographe, un moniteur patient ou une pompe à perfusion relié au réseau contient un système d’exploitation, des bibliothèques et des interfaces dont la situation de sécurité évolue chaque jour – même lorsque rien ne change sur l’appareil lui-même. Un appareil qui réussit tous les contrôles de sécurité électrique peut donc constituer en même temps une porte d’entrée grande ouverte.

L’étude ManiMed du BSI a montré à quel point le problème est réel : l’Office fédéral allemand de la sécurité des technologies de l’information a examiné dix dispositifs médicaux connectables de cinq catégories de produits et signalé aux fabricants plus de 150 vulnérabilités au cours du projet. Le rapport final a été publié en décembre 2020.

Ce que signifie la cyber-résilience en exploitation

La cyber-résilience désigne la capacité à continuer d’exploiter un appareil en toute sécurité malgré de nouvelles vulnérabilités et attaques, ou à en restreindre l’usage de manière justifiée. Il en découle des tâches qui s’ajoutent au plan d’entretien :

• un inventaire à jour de tous les appareils, versions logicielles et composants tiers ;
• une veille continue sur les nouvelles vulnérabilités et les attaques actives ;
• une évaluation qui relie gravité technique et conséquences cliniques ;
• des mises à jour et des mesures compensatoires traitées comme des modifications documentées et validées ;
• un canal de réception des signalements de vulnérabilités externes ;
• la surveillance, le traitement des incidents et des notifications dans les délais.

Cette page résume l’article « Instandhaltung vernetzter Medizinprodukte » (Maintenance des dispositifs médicaux connectés), paru en allemand dans mt|medizintechnik, numéro 4.2026, le restructure et le complète par les évolutions intervenues jusqu’en octobre 2026.

Outre la confidentialité, l’intégrité et la disponibilité, une quatrième question se pose pour les dispositifs médicaux : une attaque peut-elle compromettre les performances prévues ou nuire à des personnes ? Le guide MDCG 2019-16 souligne que, pour les dispositifs médicaux, les risques de sécurité de l’information (security) ne doivent pas être considérés indépendamment des risques pour la sécurité des patients (safety).

Comment une faille informatique devient un risque clinique

• Intégrité : des mesures, images ou résultats manipulés conduisent à des diagnostics erronés.
• Disponibilité : un système chiffré par un attaquant ou tombé en panne retarde examens et interventions.
• Pilotage : quiconque peut modifier des paramètres thérapeutiques ou d’alarme intervient directement dans le traitement.
• Confidentialité : des données de santé exfiltrées touchent à la protection des données et à la confiance des patients.

Il en découle une règle centrale pour l’évaluation sur le terrain : la gravité technique ne détermine pas à elle seule l’urgence – ce qui compte, c’est ce qu’un attaquant pourrait provoquer sur l’appareil concerné et dans le parcours de soins concerné.

Deux dossiers de risques, un seul résultat

Les fabricants mènent leur gestion des risques selon ISO 14971, harmonisée au titre du MDR sous la forme EN ISO 14971. Les risques de sécurité de l’information font souvent l’objet d’une analyse distincte. L’essentiel est le lien entre les deux : chaque scénario de sécurité susceptible d’affecter patients ou utilisateurs doit figurer dans le dossier de gestion des risques (safety), et chaque mesure de sécurité reposant sur du logiciel exige un examen sous l’angle de la cybersécurité. Sur le terrain, cet examen se répète à chaque nouvelle vulnérabilité et à chaque incident – y compris la question de savoir si le rapport bénéfice/risque doit être réévalué.

MDR : les obligations du fabricant

Le MDR s’applique depuis le 26 mai 2021. Il exige des logiciels conformes à l’état de l’art, avec une gestion des risques incluant la sécurité de l’information, une protection contre l’accès non autorisé et, dans la notice d’utilisation, des exigences minimales concernant les réseaux informatiques. Après la mise sur le marché, les fabricants exploitent un système de surveillance après commercialisation (SAC ; en anglais Post-Market Surveillance, PMS). À partir de la classe IIa, il comprend un rapport périodique actualisé de sécurité (Periodic Safety Update Report, PSUR) – au moins une fois par an pour les classes IIb et III, au moins tous les deux ans pour la classe IIa.

MDCG 2019-16 : la responsabilité partagée

Le guide MDCG 2019-16, dans sa révision de juillet 2020, transpose ces exigences à l’ensemble du cycle de vie. Il précise que la cybersécurité fait partie du système de SAC et englobe aussi les composants tiers. Il décrit en même temps une responsabilité partagée : juridiquement, c’est le fabricant qui est tenu ; en pratique, fournisseurs, intégrateurs, établissements de santé et autorités portent aussi leur part. Les modifications de l’appareil, correctifs et logiciels tiers compris, ne sont prévues que sur la base de consignes explicites et publiées du fabricant.

Les normes comme état de l’art

Ordonnance allemande sur les exploitants : les mises à jour font partie de la maintenance

Pour les exploitants en Allemagne, l’ordonnance sur l’exploitation des dispositifs médicaux (Medizinprodukte-Betreiberverordnung, MPBetreibV), en vigueur dans sa nouvelle version depuis le 20 février 2025, précise le contenu de la maintenance : outre l’entretien, l’inspection et la remise en état, elle inclut expressément, pour les logiciels, l’installation des mises à jour pertinentes pour la sécurité – dans le respect des indications du fabricant. Si une mise à jour modifie sensiblement la manipulation, le personnel doit être formé à nouveau. Pour les logiciels classés comme dispositifs médicaux de classe IIb ou III, l’ordonnance impose en outre aux établissements de santé, depuis le 1er août 2025, des contrôles de sécurité informatique selon les règles de l’art reconnues, au moins tous les deux ans et avec procès-verbal.

Loi BSI : les obligations de l’hôpital

Depuis le 6 décembre 2025, la nouvelle loi BSI transpose la directive NIS2 en Allemagne. Les hôpitaux relèvent du secteur de la santé. Sont en règle générale concernés les établissements d’au moins 50 salariés ou dont le chiffre d’affaires et le total du bilan dépassent 10 millions d’euros. À partir de 250 salariés, ou au-delà de 50 millions d’euros de chiffre d’affaires et de 43 millions d’euros de total du bilan, ils sont considérés comme entités essentielles – de même que, quelle que soit leur taille, les hôpitaux exploitant une installation critique, jusqu’ici à partir de 30 000 cas d’hospitalisation complète par an. Les obligations comprennent expressément la sécurité lors de l’acquisition, du développement et de la maintenance, y compris la gestion et la divulgation des vulnérabilités, ainsi que la sécurité de la chaîne d’approvisionnement.

Cyber Resilience Act et FDA en périphérie

Le Cyber Resilience Act ne s’applique pas aux produits relevant du MDR ou de l’IVDR. Il produit néanmoins des effets dans la technologie médicale : les fournisseurs qui commercialisent séparément des composants comportant des éléments numériques sont soumis à ses obligations de notification depuis le 11 septembre 2026, et à ses obligations principales à partir du 11 décembre 2027. À l’international, l’autorité américaine du médicament, la FDA, donne le ton : pour les « cyber devices », elle exige depuis le 29 mars 2023 dans les dossiers de soumission, entre autres, une SBOM, un plan de gestion des vulnérabilités incluant la divulgation coordonnée et des mises à jour selon un cycle justifié.

Le jour où Log4Shell a été rendue publique, le 10 décembre 2021, la même question s’est posée dans de nombreuses organisations : dans quels produits se trouve la bibliothèque concernée ? Pour les dispositifs médicaux, cette incertitude est particulièrement délicate, car les hôpitaux n’ont en général le droit ni de scanner eux-mêmes les appareils ni de les modifier sans que le fabricant l’ait prévu.

Ce qu’apporte une SBOM

La nomenclature logicielle (Software Bill of Materials, SBOM) recense de façon lisible par machine les composants logiciels d’un produit – avec désignation, version, fournisseur, somme de contrôle et dépendances. Deux formats se sont imposés : CycloneDX, normalisé depuis juin 2024 sous la référence ECMA-424, et SPDX, dont la version 2.2.1 est normalisée sous ISO/IEC 5962:2021. En Allemagne, la directive technique TR-03183-2 du BSI décrit le contenu minimal d’une SBOM.

Obligation ou attente ?

Aux États-Unis, la SBOM fait partie du dossier de soumission des « cyber devices ». Le droit européen des dispositifs médicaux ne prévoit pas d’obligation explicite ; le MDCG 2019-16 cite la nomenclature comme exemple d’information de sécurité à fournir aux exploitants. L’attente découle ici de l’état de l’art selon l’IEC 81001-5-1. Pour les composants de fournisseurs relevant du Cyber Resilience Act, la SBOM deviendra obligatoire au sein de la documentation technique à partir du 11 décembre 2027.

De la liste à la veille

Une SBOM ne devient efficace que si le fabricant la régénère à chaque build et la confronte en continu aux données de vulnérabilités. Comme une bibliothèque vulnérable ne signifie pas automatiquement un appareil vulnérable, le fabricant y ajoute des déclarations sur l’exploitabilité réelle (Vulnerability Exploitability eXchange, VEX). Ces informations s’échangent de façon lisible par machine au format Common Security Advisory Framework (CSAF), standard OASIS en version 2.0 depuis novembre 2022.

Ce que les hôpitaux devraient fixer lors des achats

• la livraison d’une SBOM lisible par machine avec l’appareil et sa mise à jour à chaque version logicielle ;
• des avis de sécurité et des déclarations VEX transmis par un canal fixe, si possible au format CSAF ;
• des indications sur la durée de support des mises à jour de sécurité et sur leurs modalités de mise à disposition ;
• le formulaire MDS2 rempli et les exigences minimales concernant l’environnement réseau ;
• un interlocuteur désigné pour les questions de sécurité et les incidents.

Des risques au-delà de son propre code

Les attaques de la chaîne d’approvisionnement, comme celle visant SolarWinds Orion fin 2020 ou la porte dérobée découverte dans XZ Utils en mars 2024, montrent comment du code malveillant s’introduit par des sources de confiance. Les parades : builds vérifiables, artefacts signés, preuves de provenance et dépendances choisies avec parcimonie ; Supply-chain Levels for Software Artifacts (SLSA), actuellement en version 1.2, offre un cadre progressif.

Les sources de la veille

• les avis de sécurité des fabricants d’appareils et des fournisseurs de composants, idéalement lisibles par machine au format CSAF ;
• le service d’alerte et d’information de CERT-Bund, rattaché au BSI ;
• le catalogue Known Exploited Vulnerabilities (KEV) de l’agence américaine CISA ;
• les échanges au sein du Health-ISAC, le réseau international de partage d’informations du secteur de la santé ;
• les constats propres issus de la surveillance réseau, des journaux et des incidents.

Trois signaux techniques

Le classement technique s’appuie sur trois signaux : le CVSS, en version 4.0 depuis novembre 2023, pour la gravité ; l’EPSS pour la prévision, actualisée chaque jour, d’une exploitation dans les 30 prochains jours ; le catalogue KEV, tenu depuis novembre 2021, pour les attaques avérées.

Les questions cliniques

• Exposition : l’appareil est-il joignable depuis le réseau de l’hôpital, via des accès de télémaintenance, voire depuis Internet ?
• Usage clinique : pilote-t-il ou surveille-t-il une thérapie, fournit-il des résultats, se trouve-t-il au chevet du patient ?
• Conséquences d’une manipulation : quel effet aurait une perte d’intégrité ou de disponibilité sur le diagnostic et le traitement ?
• Mesures de protection : la segmentation, les restrictions d’accès ou la surveillance sont-elles déjà efficaces de façon démontrable ?
• Déclaration du fabricant : une indication VEX confirme-t-elle l’exposition, ou le composant est-il inatteignable ?

Des classes de priorité comme langage commun

Fabricants et hôpitaux gagnent à disposer de quelques classes de priorité clairement décrites. Le classement ci-dessous est une proposition ; chaque organisation fixe les délais de réaction concrets produit par produit.

Deux extrêmes sont risqués : installer par réflexe chaque mise à jour disponible, ou ne jamais rien changer aux équipements médicaux. Le MDCG 2019-16 attend des exploitants qu’ils disposent de processus de gestion des correctifs permettant de déployer rapidement les mises à jour de sécurité, et que l’environnement d’exploitation admette les mises à jour sans perte de compatibilité. Le guide prévoit expressément que des mises à jour soient fournies même en dehors d’une mesure corrective de sécurité.

De l’alerte à la mise à jour documentée

1. 1
   Établir l’exposition

   Croiser l’alerte avec la SBOM, l’inventaire des équipements et les indications VEX : quels appareils, versions logicielles et sites sont réellement concernés ?

2. 2
   Évaluer et classer

   Rassembler signaux techniques, usage clinique et mesures de protection existantes, fixer la classe de priorité et documenter le lien avec la sécurité des patients.

3. 3
   Choisir la mesure

   Mise à jour, modification de configuration ou mesure compensatoire – segmentation, durcissement, surveillance renforcée ou restriction d’usage –, en accord avec les consignes du fabricant.

4. 4
   Tester et valider

   Le fabricant vérifie et valide la mise à jour ; l’hôpital la teste dans un environnement représentatif avec ses propres interfaces et l’approuve selon des critères définis.

5. 5
   Déployer progressivement

   D’abord des appareils pilotes, puis le parc, dans des fenêtres de maintenance convenues et avec un retour arrière préparé en cas de dysfonctionnement.

6. 6
   Vérifier et documenter

   Contrôler l’état d’installation, confirmer le fonctionnement, consigner le risque résiduel et mettre à jour l’inventaire, la SBOM et le dossier de gestion des risques.

Les mesures compensatoires sont évaluées, approuvées, limitées dans le temps et réexaminées comme un correctif. Du point de vue du MDR, ce qui compte, c’est la preuve qu’une décision a été justifiée, testée et documentée avec son risque résiduel – pas la seule installation.

Les mises à jour à distance (OTA)

Les mises à jour Over-the-Air apportent plus vite des corrections à de nombreux appareils, mais créent un risque de concentration : dans le pire des cas, un paquet défectueux ou manipulé atteint tout le parc. L’architecture de mise à jour de firmware de l’IETF, décrite dans la RFC 9019 d’avril 2021, en énonce les principes porteurs :

• un manifeste signé décrivant l’origine, la compatibilité et les sommes de contrôle du paquet ;
• la vérification de l’authenticité et de l’intégrité avant l’installation, puis à nouveau au démarrage par un chargeur d’amorçage doté d’une ancre de confiance (Secure Boot) ;
• une image de repli dans une zone mémoire distincte (principe A/B), afin qu’une mise à jour ratée ne paralyse pas l’appareil ;
• une protection contre le retour à une version antérieure (anti-downgrade) au moyen de numéros de séquence, afin qu’un attaquant ne puisse pas installer une version plus ancienne, vulnérable mais valablement signée ;
• la robustesse face aux coupures de courant ou de connexion.

Image de repli et protection anti-downgrade résolvent des problèmes différents : l’une garantit la disponibilité, l’autre empêche une attaque. S’y ajoutent une transmission chiffrée, des vagues de déploiement échelonnées et une télémétrie du taux de réussite ; en milieu clinique, il faut en outre des fenêtres de maintenance concertées et une information claire des utilisateurs. Si une mise à jour modifie sensiblement des caractéristiques de sécurité ou de performance, une nouvelle évaluation impliquant l’organisme notifié peut être nécessaire selon la classification.

Se préparer au zero-day

On parle de zero-day pour une vulnérabilité pour laquelle aucun correctif n’est disponible au moment où elle est connue. Pour les dispositifs médicaux, la situation est particulièrement délicate : l’appareil doit continuer à servir les soins, aucune mise à jour validée n’existe et l’hôpital n’a pas le droit d’intervenir de sa propre initiative. Quatre dispositions ont fait leurs preuves :

• un circuit d’escalade documenté qui fixe qui décide dans les premières heures – responsable produit, sécurité, DSI hospitalière, ingénierie biomédicale et affaires réglementaires ;
• des mesures immédiates convenues à l’avance, comme l’isolement réseau, la désactivation des services inutiles et une surveillance ciblée des traces d’attaque ;
• pour les classes d’appareils critiques pour la sécurité, des configurations de repli préparées et validées sur le plan clinique ;
• des modèles d’avis de sécurité destinés aux utilisateurs (Field Safety Notice, FSN), techniquement exacts et compréhensibles pour les équipes cliniques.

Selon le MDR, une mesure corrective de sécurité (Field Safety Corrective Action, FSCA) doit en principe être notifiée à l’autorité avant sa mise en œuvre ; ce n’est qu’en cas d’urgence que la notification peut suivre. Si une faille est déjà activement exploitée, la situation se tend encore – sur le plan technique comme sur le plan réglementaire.

Coordinated Vulnerability Disclosure

Beaucoup de vulnérabilités sont découvertes par des chercheurs, des pentesteurs, des intégrateurs ou des utilisateurs. Sans circuit de signalement visible, ces informations restent lettre morte ou deviennent publiques dans le désordre. La divulgation coordonnée des vulnérabilités (Coordinated Vulnerability Disclosure, CVD) organise le déroulement : le signalement est reçu, examiné, corrigé, puis publié de manière concertée. Le cadre est fixé par ISO/IEC 29147:2018 pour la réception et la publication, et par ISO/IEC 30111:2019 pour le traitement interne.

Ce que les hôpitaux devraient vérifier

Sans processus CVD opérationnel, il est difficile d’estimer la capacité de réaction d’un fabricant. Sont révélateurs une politique publiée, un PSIRT joignable et un historique traçable d’avis de sécurité.

Une surveillance qui va au-delà de la disponibilité

Une surveillance qui vérifie seulement si un appareil est joignable ne détecte aucune attaque. Sont révélateurs les connexions inhabituelles, les échecs d’authentification répétés, les modifications de configuration inattendues et les contrôles d’intégrité en échec. Comme aucun logiciel supplémentaire ne peut être installé sur de nombreux dispositifs médicaux, une surveillance réseau passive dans des zones d’appareils segmentées constitue une option adaptée.

Une réponse aux incidents qui dépasse les frontières de l’organisation

Les anomalies doivent déboucher sur un processus opérationnel – avec des rôles, des critères d’escalade et des interfaces avec l’ingénierie biomédicale, la direction de l’hôpital, la protection des données et le fabricant. Le MDCG 2019-16 attend expressément des exploitants qu’ils informent sans délai le fabricant de tout incident de sécurité présumé. Chez le fabricant, le PSIRT centralise analyse, priorisation et correction, et accompagne la communication avec les CERT, les réseaux de partage d’informations et les autorités.

Quatre circuits de notification comparés

Pour la vigilance MDR, peu importe qu’un événement résulte d’une attaque, d’une faille ou d’une erreur logicielle. Ce qui compte, c’est de savoir si la sécurité ou les performances du produit ont été, ou auraient pu être, compromises. Le MDCG 2019-16 contient des exemples pour distinguer incident et incident grave ; pour le codage, l’International Medical Device Regulators Forum (IMDRF) propose des codes de problème comme « Software Security Vulnerability ». En cas de doute sur l’obligation de notification, il faut notifier dans les délais ; une notification d’abord incomplète est admise.

Ce que changerait la proposition de révision

Le 16 décembre 2025, la Commission a proposé de réviser le MDR et l’IVDR. Les fabricants devraient alors notifier les vulnérabilités activement exploitées et les incidents de sécurité graves dans un délai de 30 jours, via la base de données européenne Eudamed, aux CSIRT compétents et à l’ENISA ; le délai général de vigilance applicable aux autres incidents graves passerait en outre de 15 à 30 jours. La proposition n’est pas encore adoptée. D’ici là, les délais actuels s’appliquent.

Surveillance après commercialisation, gestion des vulnérabilités et traitement des incidents dépendent les uns des autres : les nouveaux risques ne deviennent visibles que si la veille de sécurité alimente la SAC ; les priorités ne sont justes que si l’évaluation safety les accompagne ; les délais ne sont tenus que si les affaires réglementaires sont impliquées tôt. Le modèle cible relie ces fils en un cycle aux responsabilités clairement attribuées.

Plan de démarrage pour les premiers mois

• Inventaire et responsables : recenser tous les dispositifs médicaux connectés avec version logicielle, raccordement réseau, contact chez le fabricant et fin de support.
• Combler les lacunes d’information côté fabricants : demander SBOM, MDS2, avis de sécurité et consignes de correctifs, et les ancrer dans les contrats.
• Définir des classes de priorité et des délais de réaction internes qui combinent critères techniques et cliniques.
• Mettre en place un processus de modification pour les mises à jour et les mesures compensatoires, avec étapes de test, de validation et de documentation, et l’articuler avec les obligations de maintenance et de contrôle de l’ordonnance sur les exploitants.
• Établir et exercer une matrice de notification couvrant vigilance MDR, signalement des utilisateurs, loi BSI et protection des données, avec modèles, responsabilités et suppléances.
• Introduire des indicateurs, par exemple la part des appareils dotés d’une SBOM à jour, le délai de traitement par classe de priorité et le nombre de mesures compensatoires temporaires.

Qui relie tôt ces briques réagit plus vite, peut justifier ses décisions et renforce la confiance dans la technologie médicale numérique. Un appareil développé de manière sécurisée ne reste sûr que s’il est maintenu avec le même soin sur le terrain.

Les informations de cette page ne remplacent pas un conseil juridique. Les obligations applicables dans un cas donné dépendent de la classification, du rôle et de la taille de l’organisation.