En bref
Pour un logiciel ou un dispositif médical connecté sous MDR, la cybersécurité doit être intégrée au cycle de vie produit, pas ajoutée en fin de développement. Le MDR fixe les exigences ; IEC 81001-5-1 aide à les traduire en activités de développement et de maintenance, sans conférer aujourd’hui de présomption de conformité. L’enjeu n’est pas un « dossier cyber » parallèle, mais un SDLC où les décisions de sécurité produisent exigences, tests, preuves et actions post-marché traçables.
La cybersécurité ne se traite pas à la fin du développement
Un logiciel médical peut être fonctionnel, validé et cliniquement pertinent… tout en restant fragile face à une vulnérabilité découverte après sa mise sur le marché.
C’est précisément ce qui rend la cybersécurité différente d’un simple contrôle final : les menaces évoluent, les composants tiers changent et de nouvelles vulnérabilités apparaissent pendant toute la durée de vie du dispositif.
Ce que le MDR exige réellement en matière de cybersécurité
Le MDR ne contient pas une procédure intitulée « cybersécurité ». Il impose plusieurs exigences qui, combinées, obligent le fabricant à maîtriser les risques liés à la sécurité informatique.
Son annexe I demande notamment que les dispositifs intégrant des systèmes électroniques programmables ou les logiciels qui sont eux-mêmes des dispositifs soient développés et fabriqués conformément à l’état de l’art, en 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.
Le fabricant doit également définir les exigences minimales concernant le matériel, les caractéristiques des réseaux informatiques et les mesures de sécurité nécessaires pour faire fonctionner le logiciel comme prévu, notamment la protection contre les accès non autorisés.
Et la cybersécurité ne s’arrête pas au marquage CE.
Le MDCG 2019-16 Rev.1 prévoit que les vulnérabilités, incidents de sécurité et évolutions du paysage de menace soient pris en compte pendant la vie du dispositif. Ils peuvent conduire à réévaluer les risques, déployer des correctifs, réaliser de nouvelles vérifications ou mettre à jour la documentation technique.
Démontrer la conformité ne consiste donc pas à montrer qu’un pentest a été réalisé une fois. Il faut démontrer que la cybersécurité est maîtrisée comme un processus de cycle de vie.
IEC 81001-5-1 : à quoi sert réellement la norme ?
IEC 81001-5-1:2021 définit des exigences de cycle de vie pour le développement et la maintenance sécurisés des logiciels de santé. Elle vise notamment à soutenir la conformité aux principes d’IEC 62443-4-1 en tenant compte des spécificités du secteur de la santé.
Elle complète ainsi particulièrement bien un cycle de vie logiciel déjà structuré autour d’IEC 62304.
Là où IEC 62304 structure le développement et la maintenance du logiciel médical, IEC 81001-5-1 apporte un cadre centré sur la sécurité : organisation des activités cyber, exigences de sécurité, conception et implémentation sécurisées, vérification, traitement des vulnérabilités ou encore maintenance.
Mais un point réglementaire doit être parfaitement clair.
Lors de la rédaction de l’article, IEC 81001-5-1 n’est pas une norme harmonisée sous le MDR.
La Commission européenne l’a incluse dans sa demande de normalisation M/575 parmi les nouvelles normes harmonisées à élaborer, avec une échéance d’adoption actuellement fixée au 27 mai 2028. Sa référence n’est cependant pas publiée au Journal officiel de l’Union européenne et elle ne confère donc pas aujourd’hui de présomption de conformité au MDR.
Cela ne diminue pas son intérêt.
Elle constitue un cadre technique particulièrement pertinent pour structurer un cycle de développement sécurisé. Mais il faut éviter deux raccourcis : appliquer IEC 81001-5-1 n’est pas aujourd’hui une obligation réglementaire MDR ; et l’appliquer ne démontre pas automatiquement la conformité au MDR.
Le vrai enjeu : intégrer la cyber au SDLC, pas ajouter une couche documentaire
Le piège classique consiste à traiter la cybersécurité comme un chantier parallèle.
L’équipe développe le produit. Puis, peu avant une soumission, un audit ou une release, une analyse de menaces, quelques scans et un pentest sont ajoutés au dossier.
Le problème n’est pas uniquement documentaire. Si une menace identifiée tardivement impose de modifier l’architecture, l’authentification, le chiffrement, la journalisation ou la gestion des mises à jour, le coût du changement peut devenir considérable.
La cybersécurité doit donc entrer dans les mêmes boucles de conception que les autres exigences produit.
Comprendre le produit avant de choisir les contrôles
Architecture, données traitées, interfaces, utilisateurs, environnement d’utilisation, dépendances et composants tiers doivent être connus.
À partir de ce contexte, l’analyse de menaces et l’analyse des risques de sécurité permettent de dériver des exigences testables : authentification, autorisation, chiffrement, intégrité, disponibilité, journalisation, mise à jour sécurisée ou protection des interfaces.
Le contrôle technique vient après la compréhension du risque, pas avant.
Relier les risques cyber aux risques de sécurité patient
Tous les risques de cybersécurité ne deviennent pas automatiquement des risques pour la sécurité du patient.
Le MDCG distingue explicitement les risques de sécurité ayant un impact sur la safety de ceux qui n’en ont pas.
Les deux dimensions doivent donc être gérées et reliées lorsqu’une compromission de la confidentialité, de l’intégrité ou de la disponibilité peut modifier les performances du dispositif ou contribuer à un dommage.
La gestion des risques cyber ne doit ainsi ni être absorbée entièrement dans l’ISO 14971, ni fonctionner dans un silo sans connexion avec le fichier de gestion des risques produit.
Vérifier la sécurité comme une exigence produit
Une exigence de cybersécurité qui n’est pas vérifiée reste une intention.
Les contrôles mis en œuvre doivent être associés à des méthodes de vérification proportionnées : tests fonctionnels de sécurité, fuzz testing, scans de vulnérabilités, analyses de code ou encore penetration testing lorsque pertinent. Ce sont notamment les approches identifiées par le MDCG pour la vérification et la validation de la sécurité.
L’objectif n’est pas d’accumuler les rapports. Il est de pouvoir relier : menace → risque → exigence → contrôle → test → décision de release.
La cybersécurité commence avant la release, mais une grande partie de sa maîtrise se joue ensuite : détecter de nouvelles vulnérabilités, évaluer leur impact et décider si une correction est nécessaire, avec quelle priorité, quelles vérifications et quelle communication. Un inventaire maîtrisé des composants logiciels, souvent matérialisé par une Software Bill of Materials (SBOM), facilite cette surveillance. Mais une SBOM n’est pas une stratégie de cybersécurité. Sans veille, analyse et processus de remédiation, elle reste un inventaire.
Quelles preuves intégrer au dossier technique ?
Le dossier technique doit permettre de démontrer comment les exigences générales de sécurité et de performances applicables sont satisfaites et fournir la justification, la vérification et la validation des solutions retenues. Le MDCG rattache explicitement ces attentes à la cybersécurité.
Il n’existe donc pas un unique document cybersécurité qui suffirait à répondre au MDR.
Selon le produit, son architecture et ses risques, les preuves pourront notamment comprendre :
- une stratégie ou un plan de gestion de la cybersécurité ;
- la description de l’architecture et du contexte de sécurité ;
- l’analyse de menaces et les analyses de risques ;
- les exigences et contrôles de sécurité ;
- la traçabilité entre risques, exigences et vérifications ;
- les résultats des tests et autres activités de vérification ;
- l’inventaire des composants logiciels et la maîtrise des composants tiers ;
- le processus de gestion des vulnérabilités ;
- les modalités de mise à jour et de patch ;
- les informations de sécurité communiquées aux utilisateurs ;
- les preuves issues de la surveillance post-marché.
Le MDCG cite d’ailleurs explicitement la SBOM parmi les informations de sécurité pouvant être communiquées pour certains produits, aux côtés des contrôles implémentés, des rôles utilisateurs, du logging ou de la sécurisation des mises à jour.
La force du dossier vient cependant moins du nombre de documents que de leur cohérence. Une vulnérabilité identifiée doit pouvoir conduire à une analyse, une décision, une modification si nécessaire, une vérification puis une preuve conservée dans le système.
La cybersécurité est aussi un sujet de SMQ
IEC 81001-5-1 ne concerne donc pas seulement l’équipe technique.
La gestion des vulnérabilités touche le change control. Les composants tiers touchent la gestion des fournisseurs. Un incident cyber peut alimenter le PMS ou la vigilance. Un correctif touche la conception, la validation et la gestion des releases.
La cybersécurité traverse le système qualité.
Pour une MedTech numérique, le véritable objectif est donc de maintenir les liens entre exigences, risques, tests, anomalies, composants, versions et preuves à mesure que le produit évolue.
C’est aussi l’intérêt d’un eQMS intégré aux outils des équipes : éviter que le dossier cyber soit maintenu manuellement dans un espace séparé du développement.
Le Programme PULSE permet de construire cette architecture de conformité entre SMQ, développement logiciel et dossier technique, tandis que Qapsule vise à renforcer l’orchestration et la traçabilité des preuves entre les différents outils.
Plan d’action
Vous développez déjà un logiciel médical et la cybersécurité n’est pas encore pleinement intégrée à votre cycle de vie ?
- Cartographiez l’architecture et l’environnement d’utilisation : interfaces, flux, données, utilisateurs, systèmes externes et composants tiers.
- Réalisez une analyse d’écarts entre vos pratiques, les exigences MDR applicables, le MDCG 2019-16 Rev.1 et IEC 81001-5-1.
- Formalisez votre analyse de menaces et de risques de sécurité, puis identifiez les liens avec les risques pour la sécurité du patient.
- Transformez les mesures de sécurité en exigences testables intégrées au système de gestion des exigences ou au backlog produit.
- Construisez la traçabilité entre menaces, risques, exigences, contrôles, tests et releases.
- Maîtrisez les composants tiers et maintenez un inventaire exploitable pour la surveillance des vulnérabilités.
- Définissez avant la mise sur le marché comment une nouvelle vulnérabilité sera reçue, évaluée, corrigée, vérifiée et communiquée.
- Connectez la cybersécurité au SMQ : change control, fournisseurs, CAPA, PMS, vigilance et gestion documentaire.
- Testez le système sur une release réelle, par exemple lors d’un audit interne, plutôt que de vérifier uniquement l’existence des procédures.
Le test le plus révélateur est simple : prenez une vulnérabilité potentielle et essayez de suivre son parcours complet, de sa détection jusqu’à la preuve de sa maîtrise.
Conclusion
La question utile n’est pas seulement « Quels documents cyber devons-nous produire ? », mais : « Notre cycle de développement est-il capable de détecter une menace, d’en mesurer le risque, d’en dériver une exigence, de vérifier le contrôle et de maintenir cette maîtrise après la release ? » Lorsque ce système fonctionne, la documentation devient la preuve naturelle de ce que les équipes font réellement, et non une reconstruction à la veille de l’audit.
FAQ
IEC 81001-5-1 est-elle obligatoire sous le MDR ?
Non. Le MDR impose au fabricant de démontrer la conformité aux exigences générales de sécurité et de performances applicables. L’utilisation des normes reste volontaire.
IEC 81001-5-1 peut constituer un excellent moyen de structurer le cycle de vie de cybersécurité, mais son application n’est pas en elle-même une obligation réglementaire.
IEC 81001-5-1 est-elle harmonisée sous le MDR ?
Non, pas au moment de rédaction de l’article.
La norme figure dans la demande de normalisation M/575 de la Commission européenne, avec une échéance actuellement prévue au 27 mai 2028 pour l’adoption de la norme harmonisée demandée. Sa référence n’est pas encore publiée au Journal officiel de l’Union européenne.
Il ne faut donc pas revendiquer aujourd’hui de présomption de conformité MDR sur cette base.
Quelle différence entre IEC 62304 et IEC 81001-5-1 ?
Les deux normes sont complémentaires.
IEC 62304 structure les processus du cycle de vie du logiciel médical.
IEC 81001-5-1 se concentre sur les activités nécessaires pour sécuriser le développement et la maintenance des logiciels de santé et s’appuie notamment sur les principes d’IEC 62443-4-1.
L’objectif n’est donc pas de choisir l’une ou l’autre, mais d’intégrer leurs activités pertinentes dans un même cycle de développement.
Le MDR impose-t-il une SBOM ?
Le MDR n’impose pas explicitement, dans son annexe I, un livrable portant le nom de « SBOM ».
Le MDCG 2019-16 Rev.1 cite néanmoins la Software Bill of Materials parmi les informations de sécurité pouvant être fournies selon le produit.
Dans les logiciels reposant sur de nombreux composants tiers ou open source, disposer d’un inventaire exploitable devient surtout essentiel pour identifier rapidement si une nouvelle vulnérabilité concerne le produit.
Un test de pénétration suffit-il pour démontrer la cybersécurité d’un dispositif médical ?
Non. Le pentest constitue une technique de vérification possible, mais il ne remplace ni l’analyse des risques, ni les exigences de sécurité, ni les activités de conception sécurisée, ni la gestion des vulnérabilités après commercialisation.
Le MDCG cite d’ailleurs plusieurs techniques de vérification possibles, parmi lesquelles les tests des fonctions de sécurité, le fuzz testing, le vulnerability scanning ou le penetration testing.
Comment relier cybersécurité et ISO 14971 ?
Il faut distinguer le risque de sécurité informatique du risque pour la sécurité du patient, puis créer les liens lorsque l’un peut conduire à l’autre.
Une vulnérabilité permettant d’accéder à une information sans impact sur les performances du dispositif n’aura pas nécessairement les mêmes conséquences qu’une attaque susceptible de modifier un résultat clinique ou de rendre une fonction indisponible.
Le MDCG distingue explicitement les risques de sécurité avec et sans impact sur la safety.
Que faut-il surveiller après la mise sur le marché ?
La surveillance doit notamment permettre de détecter les nouveaux incidents de sécurité, les vulnérabilités affectant le produit ou ses composants tiers et les évolutions du paysage de menace.
Ces informations doivent être évaluées afin de déterminer si des mesures sont nécessaires : communication, modification de configuration, patch logiciel, mise à jour d’un composant ou nouvelle vérification.
Par où commencer si le logiciel est déjà en développement ?
Ne commencez pas par produire tous les documents manquants.
Commencez par une analyse d’écarts : exigences MDR → pratiques actuelles → IEC 81001-5-1 → preuves disponibles.
Identifiez ensuite les écarts susceptibles d’affecter l’architecture ou une prochaine release. Ceux-ci doivent être traités avant les écarts purement documentaires.
Cet article propose une lecture pédagogique et opérationnelle des exigences de cybersécurité applicables aux dispositifs médicaux et de l’utilisation d’IEC 81001-5-1 dans un contexte MDR. Les informations réglementaires et le statut de normalisation présentés ont été vérifiés au moment de la rédaction de l’article, notamment à partir du règlement (UE) 2017/745, du MDCG 2019-16 Rev.1, des publications de la Commission européenne et de l’IEC.
Il ne constitue pas un avis réglementaire, juridique ou de cybersécurité applicable à un dispositif particulier. Les mesures nécessaires dépendent notamment de l’architecture, de l’usage prévu, de l’environnement d’utilisation, des interfaces, des composants tiers et des risques propres au produit. Avant toute décision de conformité, il convient de vérifier les textes, guidances, normes et références publiées au Journal officiel de l’Union européenne dans leur version en vigueur.