Introduction

Dans un monde où les dispositifs médicaux intègrent de plus en plus de fonctionnalités logicielles et électroniques, la cybersécurité n'est plus une option : c'est une exigence réglementaire majeure et un impératif de sécurité des patients.

Qu'il s'agisse d'une pompe à perfusion, d'un système d'imagerie médicale, d'un logiciel de diagnostic ou d'un dispositif implantable, dès qu'un composant logiciel est présent, des vulnérabilités peuvent exister. Les conséquences d'une faille de sécurité peuvent être dramatiques : vol de données de santé, altération du fonctionnement d'un dispositif, interruption de services critiques, voire mise en danger directe des patients.

Face à ces risques, les autorités réglementaires ont durci leurs exigences. Le Règlement européen MDR et la FDA américaine imposent désormais aux fabricants de démontrer que leurs dispositifs intègrent des mesures de cybersécurité robustes tout au long de leur cycle de vie – qu'ils soient connectés ou non.

Dans cet article, nous décryptons les exigences essentielles et proposons une démarche pratique pour les fabricants de dispositifs médicaux.

Le cadre réglementaire en bref

Les exigences européennes (MDR)

Le Règlement (UE) 2017/745 impose des exigences de cybersécurité dans son Annexe I, section 17, qui couvre les dispositifs comportant des logiciels.

Les points essentiels :

• Point 17.2 : les logiciels doivent être développés conformément à l'état de l'art, incluant la gestion des risques et la sécurité de l'information
• Point 17.4 : les fabricants doivent définir les mesures de sécurité informatique nécessaires, y compris la protection contre l'accès non autorisé

Le guide MDCG 2019-16 détaille ces exigences en quatre axes :

• Incorporer des solutions technologiques appropriées pour garantir la cybersécurité
• Fournir des informations sur les mesures de cybersécurité prises
• Maintenir la cybersécurité tout au long du cycle de vie
• Mettre en place une surveillance post-commercialisation pour détecter les vulnérabilités

Pour mettre en œuvre ces exigences : La norme IEC 81001-5-1 fournit le cadre opérationnel avec des processus concrets pour chaque phase du cycle de développement : comment réaliser la gestion des risques de sécurité, comment concevoir une architecture sécurisée, quels tests de sécurité effectuer, et comment gérer les vulnérabilités après la commercialisation.

Les exigences américaines (FDA)

La Section 524B du Food, Drug and Cosmetic Act (guidance FDA juin 2025) impose des exigences pour les dispositifs contenant des logiciels et pouvant se connecter (USB, Bluetooth, Wi-Fi...).

Documentation obligatoire en prémarket :

• Modèle de menaces et analyse de risques de sécurité
• Architecture de sécurité détaillée
• SBOM obligatoire (format CycloneDX ou SPDX) avec dates de fin de support
• Rapports de tests de sécurité :
  • Analyse du code source pour détecter les vulnérabilités
  • Tests d'intrusion simulant des attaques réelles
• Plan de surveillance et de gestion des vulnérabilités post-commercialisation
• Démonstration qu'il n'y a aucune vulnérabilité critique non maîtrisée

Conséquence : La FDA peut refuser d'accepter les soumissions incomplètes. La cybersécurité fait désormais partie intégrante de la démonstration de sécurité du dispositif.

Mise en œuvre : Adopter un cadre de développement sécurisé reconnu par la FDA : AAMI SW96, IEC 81001-5-1, ou ANSI/ISA 62443-4-1.

Les normes et guides techniques clés

Normes communes EU et US :

Spécifique Union Européenne :

Spécifique États-Unis :

Maintenant que le cadre réglementaire est posé, voyons concrètement comment structurer votre démarche cybersécurité

Comment structurer votre démarche cybersécurité

L'analyse de risques et le modèle de menaces

Objectif : Identifier les menaces spécifiques à votre dispositif et définir les mesures de protection. La guidance FDA (juin 2025) exige la soumission des résultats complets du threat modeling dans le dossier prémarket.

Méthodologie STRIDE (la plus utilisée)

La méthode STRIDE structure l'identification des menaces en 6 catégories :

• Spoofing : usurpation d'identité
• Tampering : altération de données ou de code
• Repudiation : impossibilité de tracer qui a fait quoi
• Information Disclosure : accès non autorisé aux données
• Denial of Service : rendre le dispositif indisponible
• Elevation of Privilege : obtenir des droits d'accès supérieurs

Démarche : Identifier les actifs à protéger (données patient, fonctions critiques), cartographier les surfaces d'attaque (interfaces physiques, réseau, logicielles), appliquer STRIDE sur chaque interface, puis décrire les scénarios d'exploitation et leur impact.

Exemple - Pompe à perfusion :

Menace : Modification du débit via l'interface réseau
Conséquence : Surdosage → risque grave patient
Protection : Authentification renforcée + chiffrement + signature numérique

Outils recommandés : Microsoft Threat Modeling Tool ou OWASP Threat Dragon.

Documentation attendue : Diagrammes de flux, registre des menaces avec identifiants uniques, traçabilité menaces → risques → contrôles → tests.

L'architecture de sécurité

Principe de défense en profondeur : Votre dispositif doit intégrer plusieurs couches de protection complémentaires. Si une couche est compromise, les autres limitent l'impact de l'attaque.

Les six couches essentielles :

• Authentification : vérifier l'identité des utilisateurs (authentification renforcée pour les fonctions critiques)
• Chiffrement : protéger les données stockées et transmises (standards actuels : AES-256, TLS 1.3)
• Contrôle d'accès : chaque utilisateur n'accède qu'aux fonctions nécessaires à son rôle
• Intégrité : garantir que les données critiques n'ont pas été modifiées (signatures numériques)
• Détection : enregistrer les événements de sécurité pour identifier les anomalies
• Isolation : séparer les fonctions critiques des fonctions non critiques

Point clé : Chaque couche de sécurité doit être justifiée par votre analyse de risques et traçable aux menaces identifiées dans votre modèle. Les autorités vérifient cette cohérence.

Le SBOM (Software Bill of Materials)

Le SBOM est une liste exhaustive de tous les composants logiciels de votre dispositif.

Contenu obligatoire :

• Nom et version exacte de chaque composant (ex: "OpenSSL 3.0.7", pas "OpenSSL 3.x")
• Fournisseur/éditeur
• Licence logicielle
• Dépendances (y compris transitives)
• Hash cryptographique (SHA-256) pour vérification d'intégrité

Formats acceptés par la FDA :

• CycloneDX (format JSON ou XML)
• SPDX (Software Package Data Exchange)

Importance critique : Un SBOM incomplet ou au mauvais format est la première cause de refus FDA. Les SBOM au format PDF ou Excel sont automatiquement rejetés.

Outil recommandé : OWASP DependencyTrack pour la génération automatique et la surveillance continue des vulnérabilités.

Les tests de sécurité

Objectif : Démontrer que vos mesures de protection sont efficaces.

Deux types de tests obligatoires :

• Tests automatisés : analyse du code source et détection des vulnérabilités connues (CVE) à chaque modification
• Tests d'intrusion : simulation d'attaques réalistes par une équipe externe spécialisée MedTech (obligatoire avant soumission FDA, puis à intervalles réguliers proportionnels au risque - typiquement annuel post-commercialisation)

Documentation requise : protocoles détaillés, rapports de résultats, preuves de correction et retests

Point clé : Les tests doivent être traçables aux menaces identifiées dans votre modèle STRIDE et aux contrôles de sécurité définis.

Le patch management

Exigence critique : Vous devez démontrer que vous disposez d'un processus opérationnel pour corriger rapidement les vulnérabilités découvertes après commercialisation.

Éléments obligatoires :

• Délais de réponse définis
• Établir des délais de correction selon la criticité des vulnérabilités
  Exemple : vulnérabilité critique = action immédiate, vulnérabilité élevée = correction planifiée
• Référence au catalogue CISA Known Exploited Vulnerabilities
• Mécanisme de déploiement sécurisé
• Mises à jour signées numériquement
• Mécanisme de rollback en cas d'échec
• Tests de régression avant déploiement

Communication :

• Processus de divulgation coordonnée des vulnérabilités
• Notification aux utilisateurs (Field Safety Notice si impact patient)
• Information aux autorités réglementaires selon criticité

Exigence réglementaire : Le MDR et la FDA imposent la traçabilité complète de vos actions correctives. Conservez les preuves de déploiement pour chaque patch appliqué.

La documentation réglementaire

Le Cybersecurity Management Plan (CSMP) pour la FDA

Pour les soumissions FDA, vous devez fournir un plan de gestion cybersécurité complet couvrant l'ensemble du cycle de vie du dispositif. Ce document structure votre démarche de sécurité en plusieurs sections clés : gestion des risques, architecture de sécurité, SBOM, threat modeling, contrôles et tests, patch management, réponse aux incidents, formation, sécurité tierce et supply chain.

L'annexe cybersécurité pour l'EU (MDR)

Pour le marquage CE, intégrez la cybersécurité dans votre dossier technique : analyse de risques ISO 14971, conformité aux exigences générales de sécurité et de performances (§17 Annexe I MDR), références au guide MDCG 2019-16, et plan de surveillance post-commercialisation.

Point de vigilance : L'organisme notifié vérifiera la cohérence entre votre analyse de risques, votre architecture de sécurité et vos rapports de tests.

Post-commercialisation : surveillance continue

Surveillance des vulnérabilités

Obligation réglementaire : Surveillez en continu l'émergence de nouvelles vulnérabilités affectant vos composants logiciels.

Processus recommandé :

• Maintenir un SBOM à jour à chaque modification
• Utiliser des outils automatisés (DependencyTrack, Trivy) pour détecter les CVE
• S'abonner aux alertes ICS-CERT, CISA, ANSSI
• Définir des délais de correction selon criticité (référence : catalogue CISA Known Exploited Vulnerabilities)

Gestion des incidents

Délais de notification réglementaires :

• EU (MDR) : "Sans délai" aux autorités nationales si incident grave affectant la sécurité
• US (FDA) : Suivre les procédures de notification d'incidents sous 21 CFR Part 803 et 806
• Coordination CISA : 72h pour les infrastructures critiques si exploit actif ou données compromises

Erreurs fréquentes à éviter

❌ SBOM incomplet ou au mauvais format → Utilisez des outils automatisés et le format CycloneDX ou SPDX
❌ Threat modeling superficiel → Réalisez un workshop STRIDE réel avec l'équipe technique
❌ Tests de sécurité insuffisants → Pentest externe + tests automatisés + documentation complète
❌ Patch management jamais testé → Simulez un déploiement d'urgence avant commercialisation
❌ Documentation générique → Rédigez spécifiquement pour votre dispositif

Conclusion

La cybersécurité des dispositifs médicaux est devenue un impératif réglementaire incontournable. Les fabricants doivent démontrer une approche rigoureuse et documentée, de la conception à la surveillance post-commercialisation.

Les clés du succès :

• Intégrer la cybersécurité dès la conception
• Automatiser les tests et la surveillance
• Documenter en continu
• Tester le patch management avant commercialisation
• Former vos équipes

Tendances futures : Les exigences continueront à se durcir : SBOM de plus en plus détaillés, délais de correction raccourcis, threat intelligence obligatoire. Au-delà de la conformité réglementaire, la cybersécurité devient un différenciateur commercial : hôpitaux et investisseurs scrutent désormais la maturité cybersécurité lors de leurs décisions.

Prêt à sécuriser votre dispositif médical et garantir sa conformité réglementaire ?

Chez Certeafiles, nous vous accompagnons :

• Structurer votre démarche cybersécurité (threat modeling, SBOM, tests)
• Rédiger votre documentation FDA et MDR
• Préparer vos audits et certifications

👉 Contactez-nous pour un premier échange gratuit et découvrez comment Certeafiles peut accélérer votre mise sur le marché.