01Annexe I du MDR : les exigences générales de cybersécurité
Le MDR n’emploie pas littéralement le terme « cybersécurité », mais son annexe I pose des exigences claires : la section 17.1 exige, pour les dispositifs comportant des systèmes électroniques programmables, la répétabilité, la fiabilité et des performances conformes à la destination ; la section 17.2 impose un développement logiciel conforme à l’état de l’art, tenant compte du cycle de vie, de la gestion des risques – y compris la sécurité de l’information – ainsi que de la vérification et de la validation. En vertu de la section 17.4, les fabricants doivent définir des exigences minimales concernant le matériel, les caractéristiques des réseaux informatiques et les mesures de sécurité informatique, y compris la protection contre l’accès non autorisé ; la section 18.8 et la section 23.4, point ab), ajoutent la protection contre l’accès non autorisé et l’obligation de communiquer ces exigences minimales dans la notice d’utilisation. Le Cyber Resilience Act (règlement (UE) 2024/2847) exclut expressément les dispositifs médicaux de son champ d’application à l’art. 2, car le MDR impose déjà des exigences de sécurité informatique couvrant tout le cycle de vie.
02MDCG 2019-16 : le guide central de cybersécurité
Le guide MDCG 2019-16 Rev. 1 (juillet 2020) du Medical Device Coordination Group précise comment mettre en œuvre les exigences de l’annexe I sur l’ensemble du cycle de vie : secure by design, une gestion des risques de sécurité dédiée, articulée avec la gestion des risques de sûreté (safety), ainsi qu’un catalogue de security capabilities telles que l’authentification, l’autorisation, le chiffrement et la journalisation d’audit. Il établit le principe de responsabilité partagée (« joint responsibility ») : outre le fabricant, les intégrateurs, exploitants et utilisateurs assument des obligations définies pour une exploitation sécurisée – par exemple la configuration sécurisée et le respect des exigences informatiques minimales du fabricant. Un tableau de correspondance met en relation les sections pertinentes des annexes I du MDR et de l’IVDR, et une annexe d’études de cas distingue les incidents de cybersécurité des incidents graves soumis à déclaration.
03IEC 81001-5-1 : le cycle de vie sécurisé du health software
La norme IEC 81001-5-1:2021 (« Health software and health IT systems safety, effectiveness and security – Part 5-1: Security – Activities in the product life cycle ») définit les exigences de processus pour le développement et la maintenance sécurisés des logiciels de santé : gestion des risques de sécurité avec modélisation des menaces, tests de sécurité, gestion de configuration, ainsi que des processus de surveillance des vulnérabilités et de résolution des problèmes. Elle étend la structure de cycle de vie de l’IEC 62304 par des activités de sécurité et s’inspire de l’IEC 62443-4-1. La version européenne EN IEC 81001-5-1:2022 est certes prévue pour l’harmonisation au titre du MDR et de l’IVDR, mais même après la mise à jour des listes de normes en juin 2026 (décision d’exécution (UE) 2026/1231), elle n’est toujours pas citée au Journal officiel de l’UE – il n’existe donc pas de présomption de conformité. Dans la pratique, les organismes notifiés traitent néanmoins la norme comme l’état de l’art pour démontrer le respect des exigences des sections 17.2 et 17.4 de l’annexe I.
04Dispositifs médicaux à base d’IA : articulation entre le MDR et le règlement sur l’IA
Le règlement sur l’IA (règlement (UE) 2024/1689, en vigueur depuis le 1er août 2024) complète le MDR sans le remplacer : selon l’art. 6(1), un système d’IA est considéré comme IA à haut risque s’il constitue un composant de sécurité d’un dispositif médical, ou est lui-même un tel dispositif, et que son évaluation de la conformité requiert un organisme notifié – ce qui, sous le MDR, est régulièrement le cas à partir de la classe IIa. La FAQ MDCG 2025-6 (juin 2025), élaborée conjointement avec l’AI Board, répond à 36 questions pratiques sur l’articulation des deux réglementations, par exemple sur la correspondance des rôles (le fabricant au sens du MDR correspond au fournisseur au sens du règlement sur l’IA) et sur la combinaison des évaluations de la conformité. Côté échéances, 2026 a apporté un changement majeur : le « Digital Omnibus » convenu en mai 2026 par le Parlement et le Conseil reporte l’application des obligations relatives au haut risque pour les systèmes d’IA intégrés dans des produits réglementés du 2 août 2027 au 2 août 2028 ; ce report prendra effet avec la publication au Journal officiel de l’UE. Une proposition plus ambitieuse visant à exempter largement les dispositifs médicaux du règlement sur l’IA n’a pas été retenue.
05Surveillance après commercialisation et gestion des vulnérabilités
Parce que le paysage des menaces et les vulnérabilités évoluent en permanence après la mise sur le marché, le MDR exige un système actif de surveillance après commercialisation (art. 83) avec un plan de SAC (art. 84) et – selon la classe – un rapport de SAC ou un rapport périodique actualisé de sécurité (PSUR, art. 86) ; selon MDCG 2019-16, la cybersécurité fait expressément partie de ce système. Si une vulnérabilité exploitée ou exploitable entraîne un incident grave, les obligations de vigilance de l’art. 87 s’appliquent : déclaration au plus tard 15 jours après la prise de connaissance, 10 jours en cas de décès ou de détérioration grave et inattendue de l’état de santé, 2 jours en cas de menace grave pour la santé publique ; s’y ajoute le trend reporting de l’art. 88. Des codes IMDRF sont disponibles pour déclarer les causes liées à la sécurité, par exemple « Computer System Security Problem » et « Software Security Vulnerability ». Sur le plan réglementaire, les correctifs de sécurité sont des mesures correctives et peuvent être soumis à déclaration en tant que mesures correctives de sécurité (FSCA) – un processus structuré de gestion des vulnérabilités selon l’IEC 81001-5-1 relie les deux mondes. À suivre : la proposition de la Commission de décembre 2025 pour la révision du MDR (COM(2025) 1023) prévoit en complément des notifications de type CRA des vulnérabilités activement exploitées aux CSIRT et à l’ENISA – pas encore adoptée à ce jour.
06Organismes notifiés : attentes en matière de preuves de cybersécurité
Les organismes notifiés examinent la cybersécurité dans le cadre de la documentation technique selon les annexes II et III du MDR – de l’analyse des risques de sécurité et de la définition des security capabilities jusqu’aux preuves issues des tests de sécurité et aux processus de gestion des vulnérabilités et de SAC. Le position paper de Team-NB « Cyber Security » (octobre 2022) décrit les attentes communes des organismes notifiés européens vis-à-vis de ces preuves ; dans un courrier de février 2026, Team-NB appelle en outre à une harmonisation rapide de normes telles que l’IEC 81001-5-1. Tant que des normes de cybersécurité harmonisées font défaut, il n’existe pas de présomption de conformité – les fabricants doivent justifier eux-mêmes l’état de l’art et devraient construire leur argumentation autour de MDCG 2019-16 et de l’IEC 81001-5-1.
