Article dans mt|medizintechnik 4.2026 : pourquoi la maintenance des dispositifs médicaux connectés inclut la cybersécurité
19 octobre 2026
Paru dans mt|medizintechnik, Numéro 4.2026
Paru dans mt|medizintechnik, numéro 4.2026
Dans la revue mt|medizintechnik, Valeri Milke explique pourquoi la maintenance des dispositifs médicaux connectés englobe aujourd’hui la cybersécurité. Son article en allemand « Instandhaltung vernetzter Medizinprodukte », sous-titré « Schwachstellen- und Patchmanagement sind Safety-relevant » (la gestion des vulnérabilités et des correctifs touche à la sécurité des patients), figure dans le numéro 4.2026, paru en août 2026 et consacré à la maintenance. La revue est éditée par TÜV Media GmbH à Cologne. Auteur : Valeri Milke, CEO de VamiSec GmbH, Lead Auditor ISO/IEC 27001 et ISO/IEC 42001. En cinq illustrations et un tableau, il montre comment fabricants et exploitants organisent l’exploitation des appareils connectés en un processus continu – de l’inventaire des composants logiciels à l’évaluation et à la correction des vulnérabilités, jusqu’aux obligations de notification après un incident de sécurité. Cette actualité reformule ses messages clés et les situe dans le cadre réglementaire d’octobre 2026.
La thèse centrale : fonctionnel ne veut pas dire sécurisé
La maintenance classique suit des intervalles d’entretien et vérifie qu’un appareil remplit sa fonction. Pour les dispositifs médicaux connectés, ce regard ne suffit plus : une pompe à perfusion ou un système d’imagerie peut réussir tous les contrôles fonctionnels et présenter pourtant un risque inacceptable – parce qu’une faille publiée de longue date n’a jamais été évaluée ou qu’un intrus agit sans être vu sur le réseau. L’article s’appuie sur un principe du guide européen MDCG 2019-16 (révision 1 de juillet 2020) : en milieu clinique, un risque pour la sécurité de l’information (security) peut devenir directement un risque pour la sécurité des patients (safety). Exemples typiques : paramètres thérapeutiques modifiés, alarmes supprimées, résultats faussés. Gestion des vulnérabilités et des correctifs, détection d’intrusion en exploitation, surveillance après commercialisation (Post-Market Surveillance, PMS) et vigilance relèvent donc d’un même processus de pilotage – avec des rôles clairement répartis entre fabricants, intégrateurs et établissements de santé.
La transparence d’abord : connaître les composants, évaluer la situation
Sans savoir quelles bibliothèques, quels systèmes d’exploitation et quels firmwares contient un appareil, impossible de dire s’il est touché par une nouvelle vulnérabilité. Le point de départ est donc une nomenclature logicielle lisible par machine (Software Bill of Materials, SBOM) au format SPDX (ISO/IEC 5962) ou CycloneDX (ECMA-424), tenue à jour à chaque version. Les déclarations d’exploitabilité du fabricant (Vulnerability Exploitability eXchange, VEX) et les avis de sécurité au format Common Security Advisory Framework (CSAF) en font un état des lieux exploitable. La priorisation croise plusieurs angles : gravité technique selon le Common Vulnerability Scoring System (CVSS), probabilité d’exploitation à 30 jours selon l’Exploit Prediction Scoring System (EPSS), exploitation avérée d’après le catalogue KEV (Known Exploited Vulnerabilities) de l’agence américaine CISA – et contexte clinique. Une faille moyenne sur une plateforme thérapeutique peut être plus urgente qu’une faille critique sur un appareil isolé. Log4Shell et XZ Utils montrent à quelle vitesse les risques de la chaîne d’approvisionnement gagnent le produit.
Le correctif comme modification maîtrisée – et que faire tant qu’il n’existe pas
Une mise à jour de sécurité réduit les risques, mais peut modifier des états validés et des interfaces. L’article traite donc la gestion des correctifs comme un processus de modification encadré : identifier les composants concernés via l’inventaire et la SBOM, évaluer les effets sur la security et la safety dans la gestion des risques selon ISO 14971, tester dans un environnement représentatif, valider, déployer, vérifier l’efficacité et documenter. Les exploitants ne devraient installer une mise à jour que sur instruction expresse du fabricant, comme le prévoit aussi le MDCG 2019-16. Sans correctif – face à une vulnérabilité zero-day, par exemple –, des mesures compensatoires préparées prennent le relais : segmentation réseau, désactivation des services vulnérables, surveillance renforcée et modes dégradés convenus avec les équipes cliniques. Elles aussi doivent être justifiées et tracées. Les mises à jour à distance (Over-the-Air, OTA) exigent en plus des paquets signés, un démarrage sécurisé (Secure Boot), une image de repli, une protection contre le retour à des versions obsolètes et un déploiement progressif.
Accueillir les signalements externes : CVD et PSIRT
Bien des failles ne sont pas découvertes par les fabricants, mais par des chercheurs en sécurité, des pentesteurs, des intégrateurs ou des utilisateurs. Pour que ces signalements ne se perdent pas et ne deviennent pas publics dans le désordre, l’article plaide pour une procédure encadrée de divulgation coordonnée des vulnérabilités (Coordinated Vulnerability Disclosure, CVD). Repères : ISO/IEC 29147 pour la réception et la publication, ISO/IEC 30111 pour le traitement interne. Concrètement, il faut un fichier security.txt conforme à la RFC 9116, une adresse de signalement joignable de façon chiffrée, des délais de réponse annoncés, une CVE Numbering Authority (CNA) propre ou l’appui d’une CNA existante, ainsi que des avis lisibles par machine au format CSAF. Une équipe de réponse aux incidents de sécurité produit (Product Security Incident Response Team, PSIRT) porte la procédure. Pour les établissements de santé, sa maturité est un critère de choix concret lors des achats : sans historique d’avis traçable, nul ne sait à quelle vitesse les alertes critiques parviennent à l’exploitant.
Un incident, trois circuits de notification : MDR, loi BSI et RGPD
Quand un événement cyber doit-il être notifié ? Les fabricants sont soumis aux obligations de vigilance du règlement sur les dispositifs médicaux (MDR) : un incident grave se notifie sans délai, au plus tard 2 jours après en avoir eu connaissance en cas de menace grave pour la santé publique, 10 jours en cas de décès ou de détérioration grave et inattendue de l’état de santé, 15 jours sinon. Les hôpitaux qui relèvent, comme entité essentielle ou importante, de la nouvelle loi BSI – qui transpose depuis le 6 décembre 2025 la directive NIS2 en droit allemand – notifient tout incident important en trois temps : alerte précoce sous 24 heures, notification avec une première évaluation sous 72 heures, rapport final au plus tard un mois après celle-ci. Si des données personnelles sont touchées, le RGPD impose en règle générale une notification à l’autorité de protection des données, si possible sous 72 heures. Une seule attaque peut activer les trois circuits à la fois, chez le fabricant comme à l’hôpital. D’où la recommandation de l’article : délais consignés, responsabilités clarifiées, modèles de notification prêts.
Pourquoi le sujet presse – et ce que vous pouvez faire
En décembre 2025, la Commission européenne a proposé d’ajouter au MDR et à l’IVDR une notification propre des vulnérabilités activement exploitées et des incidents de sécurité graves – via Eudamed aux CSIRT et à l’ENISA, au plus tard 30 jours après en avoir eu connaissance. Le délai des autres incidents graves passerait de 15 à 30 jours ; rien n’est encore adopté. Depuis le 11 septembre 2026 s’appliquent en outre les obligations de notification du Cyber Resilience Act. S’il exclut les dispositifs médicaux, il peut s’appliquer directement aux composants de fournisseurs mis sur le marché de manière autonome en tant que produits comportant des éléments numériques. Cinq étapes sont recommandées : dresser un inventaire des appareils avec versions logicielles et SBOM ; exiger par contrat SBOM, VEX et avis CSAF des fournisseurs ; instaurer un triage qui évalue explicitement les conséquences cliniques ; exercer les scénarios zero-day avec la DSI hospitalière, l’ingénierie biomédicale et les affaires réglementaires ; enfin, réunir les circuits de notification du MDR, de la loi BSI et du RGPD en un processus coordonné.
Nouveau sur vamisec.com : la page de connaissances sur le sujet
Nouveau sur vamisec.com : la page de connaissances « Maintenance des dispositifs médicaux connectés ». Elle reprend les thèses de l’article, les actualise à octobre 2026 et les approfondit sur tout le processus de maintenance sur le terrain – de l’inventaire et de la SBOM à l’état des lieux, au triage, aux processus de correctifs et OTA, à la préparation aux zero-day et à la CVD, jusqu’à la surveillance, aux circuits de notification parallèles et à un modèle opérationnel cible, avec une FAQ et des sources vérifiées. Vous trouverez la page sur https://vamisec.com/fr/wissen/secure-software-development/instandhaltung-vernetzter-medizinprodukte. Notre accompagnement sur les projets MDR et la cybersécurité des dispositifs médicaux est présenté sur https://vamisec.com/fr/mdr et https://vamisec.com/fr/medical-device-cybersecurity – les exigences MDR transversales sont résumées sur https://vamisec.com/fr/wissen/grc/mdr-cybersecurity.
Tous les liens
Numéro 4.2026 de mt|medizintechnik : https://mt-medizintechnik.de/fokus-auf-instandhaltung/ · Page de connaissances Maintenance des dispositifs médicaux connectés : https://vamisec.com/fr/wissen/secure-software-development/instandhaltung-vernetzter-medizinprodukte · Catégorie Développement sécurisé de logiciels & produits, section Dispositifs médicaux : https://vamisec.com/fr/wissen/secure-software-development#medizinprodukte · Cybersécurité MDR en bref : https://vamisec.com/fr/wissen/grc/mdr-cybersecurity · Gestion des SBOM : https://vamisec.com/fr/wissen/secure-software-development/sbom-management · Gestion des vulnérabilités : https://vamisec.com/fr/wissen/it-security/schwachstellenmanagement · Conseil MDR : https://vamisec.com/fr/mdr · Cybersécurité des dispositifs médicaux : https://vamisec.com/fr/medical-device-cybersecurity
Vous avez des questions sur la sécurité IT de votre organisation ?
Première consultation gratuite →