Guide de la FDA sur la cybersécurité avant la mise sur le marché pour les systèmes d'exploitation des dispositifs médicaux : recommandations de la FDA pour les demandes d'autorisation

La plupart des fabricants d'équipements d'origine (OEM) entendent parler de « cybersécurité FDA » et pensent immédiatement à la SBOM. Il s'agit là d'un élément parmi d'autres, mais ce n'est pas tout.
Le cadre plus large est constitué par les lignes directrices de la FDA sur la cybersécurité avant la mise sur le marché – « Cybersécurité des dispositifs médicaux : considérations relatives au système de gestion de la qualité et contenu des dossiers de demande d'autorisation de mise sur le marché » – qui décrivent la position actuelle de la FDA concernant la conception de la cybersécurité des dispositifs, l'étiquetage et la documentation relative à la cybersécurité des dispositifs médicaux que la FDA recommande d'inclure dans les dossiers de demande d'autorisation de mise sur le marché. Il couvre les dispositifs présentant un risque de cybersécurité, et pas seulement les dispositifs connectés au réseau.
La section 524B du FD&C Act est la loi contraignante qui confère à la FDA le pouvoir d’exiger des informations de cybersécurité pour les « cyber-dispositifs ». Mais la section 524B constitue le minimum légal, et non le modèle complet de documentation de cybersécurité. Le guide décrit l'ensemble plus large de preuves que les fabricants doivent préparer – et il va bien au-delà d'une SBOM.
Cela est important pour le choix du système d'exploitation, car celui-ci représente une part significative de la surface d'attaque logicielle. Mais le système d'exploitation ne constitue pas l'ensemble du dispositif. Le rôle du fournisseur de système d'exploitation est de fournir des preuves techniques structurées au niveau de la couche de la plateforme. L'OEM est responsable de la soumission au niveau du dispositif, de la gestion des risques, de la validation et des obligations post-commercialisation.

Recommandations de la FDA concernant les demandes d'autorisation de mise sur le marché

La FDA a publié la version finale actuelle de ces lignes directrices le 3 février 2026, remplaçant ainsi celle du 27 juin 2025. Elle harmonise la terminologie avec le règlement sur les systèmes de gestion de la qualité (QMSR), entré en vigueur le 2 février 2026, et intègre la norme ISO 13485:2016 par référence dans le titre 21 du CFR, partie 820.
La FDA recommande aux fabricants d'intégrer la cybersécurité dans la gestion de la sécurité et de la qualité des dispositifs. Les lignes directrices identifient un cadre de développement sécurisé des produits (SPDF) comme une approche recommandée pour gérer les risques de cybersécurité tout au long du cycle de vie du produit. Les approches courantes de modélisation des menaces comprennent STRIDE, les arbres d'attaque et les méthodologies inspirées de MITRE.
Pour une demande de mise sur le marché, la FDA recommande généralement :

Élément de soumission	Recommandations de la FDA
SPDF	Preuve que la cybersécurité est prise en compte dans le système de gestion de la qualité. La FDA considère le SPDF comme l'une des approches recommandées
Modèle de menaces	Modèle de menaces spécifique à l'appareil, comprenant la justification méthodologique, les risques identifiés, les mesures d'atténuation et l'analyse des risques résiduels
Architecture de sécurité	Schémas d'architecture, diagrammes de flux de données, limites de confiance et inventaire des interfaces
SBOM	Inventaire de tous les composants logiciels, avec indication de leur version. L'article 524B l'impose pour les appareils connectés
Tests de sécurité	Tests de cybersécurité, pouvant inclure des tests d'intrusion, des analyses statiques et dynamiques, des tests de fuzz et l'analyse de la surface d'attaque
Procédé CVD	Procédure documentée pour la réception, l'évaluation et la communication des signalements de vulnérabilités
Plan de suivi post-commercialisation	Procédure de surveillance des vulnérabilités, de déploiement des correctifs et de communication avec la FDA
Étiquetage en matière de cybersécurité	Mesures et procédures de sécurité documentées à l'intention des utilisateurs finaux et des établissements de santé

Aucun outil ni aucun fournisseur ne couvre l'ensemble de ces aspects. Les différents éléments sont gérés par différentes entités au sein de l'organisation.

524B par rapport aux directives complètes

L'article 524B s'applique aux « appareils connectés » – c'est-à-dire, en général, tout appareil équipé d'un logiciel validé par un promoteur, connecté à Internet et présentant des caractéristiques techniques exposées aux menaces de cybersécurité. En cas de doute quant à la classification, les fabricants doivent solliciter l'avis des autorités réglementaires.

	Article 524B	Guide de la FDA sur la cybersécurité avant la mise sur le marché
De quoi s'agit-il ?	Loi ayant force obligatoire	Recommandations de la FDA (reflet de la position actuelle, généralement non contraignantes en soi)
Champ d'application	Appareils connectés uniquement	Appareils présentant un risque pour la cybersécurité, y compris certains appareils logiciels non connectés
Couverture	Gestion des vulnérabilités, mises à jour/correctifs, SBOM, divulgation coordonnée	SPDF, modèle de menace, architecture de sécurité, tests, SBOM, CVD, plan post-commercialisation, étiquetage
Application	La FDA peut refuser de prendre en compte certaines demandes ne contenant pas les informations requises en matière de cybersécurité	La FDA recommande ce cadre pour garantir une évaluation cohérente, adaptée au niveau de risque

Ce guide présente des recommandations en matière de cybersécurité pour les dispositifs présentant un risque de cybersécurité, et pas uniquement pour les dispositifs connectés à Internet. Si votre dispositif contient des logiciels et présente un risque de cybersécurité, la FDA recommande d'aborder la question de la cybersécurité dans votre dossier de demande, qu'il soit connecté ou non. La SBOM à elle seule ne suffit pas. (Pour les dispositifs destinés au marché de l'UE, voir également « Conformité des dispositifs médicaux au règlement CRA : qu'est-ce qui est réellement exempté ? »)

Ce qui a changé en février 2026 : pourquoi les preuves au niveau du système d'exploitation revêtent une importance accrue

La mise à jour des lignes directrices de la FDA de février 2026 a harmonisé la terminologie avec celle du QMSR. Pour les équipementiers (OEM), l'aspect pratique n'est pas que le fournisseur de système d'exploitation devienne responsable du système qualité. L'équipementier reste responsable des demandes d'autorisation réglementaires, de la mise en œuvre du système de gestion de la qualité, de la gestion des risques liés à la cybersécurité, de la validation et des obligations post-commercialisation.
Le rôle du fournisseur de système d'exploitation est plus restreint mais important : il consiste à fournir des preuves techniques structurées que l'OEM peut intégrer à sa propre documentation. Les lignes directrices de la FDA stipulent que les vulnérabilités connues doivent être évaluées comme des risques raisonnablement prévisibles dans le cadre de la gestion des risques de cybersécurité. Le programme d'inspection mis à jour de la FDA utilise une approche fondée sur les risques. La documentation relative à la cybersécurité avant la mise sur le marché fait l'objet d'une attention particulière. Les directives de la FDA indiquent que des informations insuffisantes en matière de cybersécurité peuvent affecter l'examen, et la section 524B établit des exigences contraignantes en matière de soumission pour les dispositifs cybernétiques. Pour les fabricants d'équipements d'origine (OEM), le point pratique est simple : les éléments de la couche du système d'exploitation doivent être structurés, traçables et utilisables dans le dossier de preuves au niveau du dispositif.
Pour un système d'exploitation de dispositif médical, les preuves structurées de la couche du système d'exploitation comprennent :

• Artifacts SBOM pour les composants de la plate-forme du système d'exploitation
• Registres de surveillance et de triage des vulnérabilités
• Disponibilité des correctifs et historique des mises à jour
• Documentation sur le démarrage sécurisé
• Documentation sur le mécanisme de mise à jour sécurisée
• Éléments constitutifs de l'architecture de sécurité au niveau du système d'exploitation

C'est là qu'une plateforme d'exploitation de qualité médicale doit se distinguer d'une version de base de Linux à usage général : non pas en revendiquant à elle seule la conformité réglementaire, mais en produisant des éléments traçables et prêts à être examinés au niveau de la couche du système d'exploitation, que le fabricant d'équipement d'origine (OEM) peut intégrer dans ses processus de gestion des risques, de vérification, de validation et de suivi post-commercialisation au niveau des appareils.

Ce que couvre MediTUX OS au niveau de la couche plateforme

Génération de SBOM. MediTUX OS est conçu pour générer des artefacts SBOM au moment de la compilation pour les composants de la plateforme OS inclus dans la compilation : noyau, espace utilisateur, bibliothèques et composants de micrologiciel pris en charge, le cas échéant. Pour une distribution Linux embarquée, cela peut représenter des centaines de composants liés au noyau, à l'espace utilisateur, aux bibliothèques, au runtime et au micrologiciel, en fonction du profil d'image et de la plateforme matérielle sélectionnés. Les équipementiers restent responsables des composants de la couche applicative, spécifiques à l'appareil et liés au cloud dans la SBOM complète de l'appareil.
Surveillance des vulnérabilités. L4B exploite MOON (MediTUX OS Operations Network), conçu pour prendre en charge la surveillance des vulnérabilités au niveau du système d'exploitation, le triage, le suivi de la disponibilité des correctifs et la prise en charge des mises à jour pour les composants du système d'exploitation MediTUX. Conformément aux directives de cybersécurité du QMSR et de la FDA, ces résultats de surveillance peuvent soutenir les processus du système qualité de l'OEM, car les vulnérabilités connues doivent être évaluées comme des risques raisonnablement prévisibles. Les OEM restent responsables de l'évaluation au niveau de l'appareil, de l'évaluation de l'impact sur la sécurité et des décisions de déploiement. Une correspondance CVE ne constitue pas automatiquement un problème de sécurité de l'appareil. L'OEM doit encore procéder à une analyse de l'exploitabilité dans le contexte de l'appareil : déterminer si le composant vulnérable est inclus, si le chemin de code affecté est accessible, s'il existe des contrôles compensatoires et si l'exploitation pourrait affecter la sécurité, l'efficacité ou l'intégrité des données.
Démarrage sécurisé. MediTUX OS est conçu pour prendre en charge les workflows de démarrage sécurisé pour les plateformes matérielles prises en charge, y compris les contrôles d'intégrité cryptographique lors des étapes de démarrage, sous réserve du matériel cible et de l'architecture du système.
Mises à jour sécurisées. MediTUX OS inclut la technologie sFOTA (secure Firmware Over The Air), conçue pour prendre en charge les workflows de mise à jour logicielle sécurisée, y compris les contrôles d'intégrité cryptographique et les stratégies de mise à jour orientées vers la restauration, sous réserve du matériel cible, de l'architecture système et de la mise en œuvre par le client.

Ce que le fabricant d'équipement d'origine doit gérer séparément

Le système d'exploitation gère la couche de plate-forme. Le reste nécessite une expertise au niveau des périphériques.

Élément	Qui s'en charge ?
SBOM au niveau du système d'exploitation, surveillance des CVE, démarrage sécurisé, mise à jour OTA	Fournisseur de systèmes d'exploitation (MediTUX OS, MOON, sFOTA)
Modèle de menace au niveau des appareils	Fabricant d'équipement d'origine (OEM) ou cabinet de conseil en cybersécurité
Tests d'intrusion	Fabricant d'équipement d'origine (OEM) ou organisme de contrôle indépendant
Procédé CVD	OEM (obligation du fabricant)
Architecture de sécurité complète	Fabricant d'équipement d'origine (OEM), avec intégration de la plateforme du système d'exploitation
Étiquetage en matière de cybersécurité	Fabricant d'équipement d'origine
Intégration de SPDF dans le système de gestion de la qualité (QMS)	Fabricant d'équipement d'origine (OEM), avec prise en charge de la plate-forme du système d'exploitation pour les processus au niveau de la couche du système d'exploitation
Plan de surveillance post-commercialisation	OEM, avec prise en charge de la plate-forme du système d'exploitation pour la surveillance au niveau du système d'exploitation

Cette distinction est importante. Un éditeur de système d'exploitation digne de ce nom devrait faciliter la documentation de la couche plateforme, et non prétendre détenir l'intégralité du code.

Pourquoi Linux, en tant que système d'exploitation polyvalent, complique les choses

Les équipementiers qui utilisent des distributions basées sur Ubuntu, Debian ou Yocto doivent effectuer les mêmes tâches au niveau des appareils – modélisation des menaces, tests d'intrusion, CVD – mais ils doivent également assumer l'intégralité de la charge liée à la couche du système d'exploitation. (Pour mieux comprendre pourquoi, consultez l'article « Pourquoi un système Linux à usage général ne suffit pas pour les dispositifs médicaux ».)

• La génération d'une liste des composants logiciels (SBOM) nécessite des outils sur mesure
• La surveillance des vulnérabilités (CVE) sur des centaines de paquets est un engagement permanent
• Le démarrage sécurisé doit être configuré et validé
• Il est nécessaire de développer et d'entretenir l'infrastructure OTA
• La documentation relative à l'architecture de sécurité au niveau du système d'exploitation part de zéro
• La maintenance à long terme du noyau et des paquets (plus de 10 ans) incombe au fabricant d'équipement d'origine
• Conformément au QMSR, les processus de cybersécurité pertinents au niveau de la couche OS doivent être intégrés dans la documentation vérifiable du système qualité lorsqu'ils ont une incidence sur la sécurité des dispositifs, les contrôles de conception, la gestion des risques ou la surveillance post-commercialisation

C'est là tout l'intérêt d'une plateforme d'exploitation de qualité médicale : alléger la charge liée à la couche du système d'exploitation afin que l'équipe du fabricant puisse se concentrer sur les risques spécifiques à l'appareil, qu'elle est la seule à pouvoir évaluer.

Foire aux questions

La FDA impose-t-elle une norme spécifique de cybersécurité pour les systèmes d'exploitation ? Non. La FDA n'impose pas de norme spécifique de cybersécurité pour le système d'exploitation lui-même. Le guide fait référence à la norme CEI 81001-5-1 en tant que norme consensuelle reconnue, mais le dossier de demande doit tout de même démontrer comment les risques liés à la cybersécurité sont gérés pour le dispositif concerné.
La section 524B constitue-t-elle la principale exigence en matière de cybersécurité ? Il s'agit de la disposition légale contraignante pour les dispositifs connectés. Mais elle ne reflète pas l'ensemble du contexte. Le cadre plus large recommandé par la FDA est le guide sur la cybersécurité avant la mise sur le marché (Premarket Cybersecurity Guidance), qui couvre les dispositifs présentant un risque de cybersécurité – y compris ceux qui ne sont pas connectés au réseau.
Le système d'exploitation MediTUX répond-il à toutes les exigences de cybersécurité de la FDA ? Non, et aucune plateforme de système d'exploitation ne le peut. Le système d'exploitation MediTUX prend en charge la couche de la plateforme du système d'exploitation : génération de la liste des composants logiciels (SBOM), surveillance des vulnérabilités via MOON, démarrage sécurisé pour le matériel pris en charge et mises à jour sécurisées via sFOTA. La modélisation des menaces, les tests d'intrusion, l'évaluation des risques de cybersécurité (CVD), l'architecture de sécurité et l'étiquetage nécessitent une expertise au niveau du dispositif que le fabricant fournit directement ou par l'intermédiaire d'un partenaire spécialisé. (Voir également : Garantir la sécurité des dispositifs médicaux avec MediTUX OS.)
Qu'est-ce que le SPDF ? Secure Product Development Framework (cadre de développement de produits sécurisés). La FDA l'identifie comme l'une des méthodes recommandées pour gérer les risques de cybersécurité tout au long du cycle de vie du produit. L'idée est que la cybersécurité soit intégrée au processus de développement dès le début, et non ajoutée après coup avant la soumission.
En quoi la QMSR affecte-t-elle la cybersécurité ? La QMSR signifie que les activités liées à la cybersécurité qui affectent la sécurité des dispositifs doivent faire partie du système de gestion de la qualité, et non être traitées comme un exercice distinct. Les directives de la FDA stipulent que les vulnérabilités connues doivent être évaluées comme des risques raisonnablement prévisibles. Pour les équipementiers, cela signifie que les artefacts de la couche OS, tels que les SBOM, les registres de vulnérabilités et les journaux de mise à jour, doivent être organisés de manière à s'intégrer dans le système de gestion de la qualité, et non laissés dans un référentiel d'ingénierie déconnecté des processus du système qualité.
MediTUX OS génère-t-il des artefacts SBOM pour les demandes d'autorisation de mise sur le marché auprès de la FDA ? Oui, au niveau de la plate-forme du système d'exploitation. MediTUX OS est conçu pour générer des artefacts SBOM au moment de la compilation pour les composants du système d'exploitation inclus dans la version. La SBOM complète du dispositif – y compris les composants au niveau de l'application, du cloud et autres composants non liés au système d'exploitation – reste sous la responsabilité de l'OEM.

---

---

Avertissement : Ce contenu est fourni à titre d'information générale et à des fins de marketing uniquement ; il ne constitue en aucun cas un conseil juridique, réglementaire, en matière de cybersécurité, clinique ou relatif au système qualité. Les recommandations de la FDA reflètent généralement la position actuelle de l'agence et ne sont pas contraignantes, sauf si elles sont liées à des exigences légales ou réglementaires. Les fabricants de dispositifs médicaux restent responsables de l'identification des exigences applicables, de la mise en œuvre de leur système de gestion de la qualité (SGQ), de la gestion des risques de cybersécurité au niveau des dispositifs, de la préparation des dossiers de demande d'autorisation et du respect des obligations post-commercialisation. MediTUX OS, MOON et sFOTA prennent en charge les activités de cybersécurité au niveau du système d'exploitation, mais ne remplacent pas les responsabilités du fabricant au niveau des dispositifs.