Les exigences réglementaires autour des équipements de santé connectés

MDR 2017/745, NIS2 et PGSSI-S imposent des obligations précises sur la cybersécurité des dispositifs médicaux connectés. La conformité exige une collaboration active constructeurs-biomédical-RSSI et un processus continu de qualification.

M
Mehdi SARIAK
24 mai 2026 7 min de lecture 11 lectures

Points clés

  • Le règlement MDR 2017/745 impose des exigences de cybersécurité explicites pour les dispositifs médicaux mis sur le marché européen, incluant la gestion des mises à jour et la protection contre les accès non autorisés.
  • La directive NIS2 classe les établissements de santé comme entités essentielles, imposant des obligations de gestion des risques, de notification d'incidents et de sécurisation de la chaîne d'approvisionnement incluant les dispositifs médicaux.
  • PGSSI-S (Politique Générale de Sécurité des Systèmes d'Information de Santé) définit les règles applicables en France, avec des recommandations spécifiques aux dispositifs médicaux connectés.
  • La conformité réglementaire exige une collaboration active entre constructeurs, services biomédicaux et équipes cybersécurité, souvent absente des organisations actuelles.
Cas US FDA Cybersecurity Guidance (2023) — La FDA a renforcé ses exigences prémarket : les fabricants doivent désormais soumettre un plan de cybersécurité, un SBOM (Software Bill of Materials), et démontrer leur capacité à déployer des correctifs. Les établissements utilisant des équipements non conformes à ces nouvelles exigences doivent documenter les risques résiduels et les mesures compensatoires.

MDR 2017/745 : les obligations des fabricants et leurs implications pour les établissements

Le règlement européen sur les dispositifs médicaux MDR 2017/745, pleinement applicable depuis mai 2021, introduit des exigences de sécurité informatique dans les critères essentiels de performance et de sécurité. Les fabricants doivent documenter les mesures de protection contre les accès non autorisés, garantir la mise à jour sécurisée du logiciel embarqué, et maintenir un plan de gestion du cycle de vie incluant la sécurité. Pour les établissements, ces obligations se traduisent par des exigences contractuelles : un fabricant ne communiquant pas ses CVE, ne fournissant pas de correctifs, ou cessant le support sans préavis peut engager sa responsabilité. Les acheteurs doivent intégrer ces critères dans les cahiers des charges et les processus de qualification à l'acquisition.

NIS2 : les établissements de santé comme entités essentielles

La directive NIS2, transposée en droit français, place les hôpitaux et établissements de santé significatifs dans la catégorie des entités essentielles. À ce titre, ils sont soumis à des obligations renforcées : mise en place d'une gouvernance cybersécurité documentée, gestion des risques incluant la chaîne d'approvisionnement, plan de continuité et de reprise d'activité, notification obligatoire des incidents significatifs à l'ANSSI dans des délais stricts. Les dispositifs médicaux connectés entrent dans le périmètre de la gestion des risques supply chain : un équipement dont le constructeur a été compromis (attaque SolarWinds-style) ou dont le support logiciel n'est plus assuré constitue un risque NIS2 documentable.

PGSSI-S et le cadre national de sécurité en santé

La PGSSI-S, portée par l'ANS (Agence du Numérique en Santé), structure les exigences de sécurité applicables aux SI de santé français. Ses référentiels couvrent spécifiquement les dispositifs médicaux connectés, les modalités d'authentification, la gestion des habilitations, la traçabilité des accès, et les exigences de chiffrement. Le cadre HDS (Hébergement de Données de Santé) s'applique également lorsque les équipements IoMT traitent ou transmettent des données de santé vers des plateformes cloud ou des serveurs distants. La conformité PGSSI-S est vérifiée dans le cadre des certifications HAS et des audits de la CNIL pour les données personnelles de santé.

Cas EU British Airways (2018) — La CNIL britannique (ICO) a infligé une amende de 20 M£ pour violation du RGPD après une compromission de données clients. Bien que non hospitalier, ce cas illustre que les autorités de régulation examinent précisément si les mesures techniques étaient conformes aux exigences applicables — une logique identique s'applique aux établissements de santé sous NIS2 et RGPD art. 9.

La conformité comme processus continu, pas comme certification ponctuelle

L'erreur la plus répandue est de traiter la conformité réglementaire IoMT comme un exercice ponctuel de mise en conformité. Les textes évoluent — MDR, NIS2, PGSSI-S font l'objet de guides d'application successifs — les équipements vieillissent, de nouvelles vulnérabilités émergent. Un programme de conformité IoMT efficace intègre une veille réglementaire structurée, des revues périodiques de la conformité du parc, des processus de qualification sécuritaire à chaque acquisition, et des clauses contractuelles avec les constructeurs exigeant la communication proactive des CVE, les délais de correction, et les conditions de fin de support.

Articuler conformité et opérationnel : le rôle du RSSI de santé

Le RSSI de santé occupe une position charnière entre les exigences réglementaires et les contraintes opérationnelles. Son rôle inclut la traduction des obligations légales en exigences techniques compréhensibles pour les équipes biomédicales, la négociation avec les constructeurs sur les clauses de sécurité, et le reporting à la direction sur l'état de conformité du parc IoMT. Des référentiels sectoriels — IEC 80001-1 pour la gestion des risques des réseaux IT intégrant des dispositifs médicaux, IEC 62443 pour la cybersécurité industrielle — complètent le cadre réglementaire institutionnel et fournissent des méthodes opérationnelles adaptées.

Cas Asie Cathay Pacific (2018) — La compagnie a subi une amende de 500 000 £ de l'ICO pour violation de la Data Protection Act suite à une compromission de données de 9,4 millions de passagers. L'enquête a établi que les mesures techniques n'étaient pas conformes aux standards applicables. En santé, une défaillance similaire sur des données de classe RGPD art. 9 aurait des conséquences réglementaires proportionnellement plus sévères.
WhatsApp