Architecture de sécurité des dispositifs médicaux

Sytance · Mis à jour 6 octobre 2026

Une architecture de sécurité montre comment le dispositif médical et ses systèmes connectés sont protégés. Elle identifie les interfaces qu’un attaquant pourrait atteindre et explique où les contrôles limitent l’accès, protègent les données ou vérifient les mises à jour logicielles.

L’architecture comme preuve

La FDA recommande des vues d’architecture qui aident les examinateurs à comprendre l’exposition du dispositif aux attaques et les protections intégrées au système. Dans un dossier technique européen, les mêmes informations de conception étayent les exigences applicables du MDR ou de l’IVDR. L’explication réglementaire peut différer, mais l’architecture sous-jacente doit décrire le dispositif réel et son environnement prévu.

Par exemple, une connexion d’assistance à distance peut relier le réseau d’un prestataire de services à un hôpital. L’architecture doit montrer quel point d’accès authentifie le technicien et quelle partie du dispositif limite les actions de maintenance.

Limite du système

Identifiez le dispositif et les systèmes externes dont il dépend. Indiquez les parties contrôlées par le fabricant et celles qui dépendent de l’organisme de santé ou d’un autre prestataire.

Limite de confiance

Signalez les changements de confiance ou d’autorité. Par exemple, une commande provenant d’une application mobile doit être vérifiée avant que le dispositif ne l’autorise à modifier un réglage clinique.

Vues d’architecture FDA

Les recommandations définitives de la FDA de février 2026 préconisent des vues d’architecture adaptées à la complexité du dispositif et aux risques de cybersécurité. Chaque vue explique un aspect différent des attaques possibles et des protections du système.

Vue globale du système (Global System View)

Vue des dommages possibles pour plusieurs patients (Multi-Patient Harm View)

Vue de mise à jour et d’application des correctifs (Updateability and Patchability View)

Vues de cas d’utilisation de sécurité (Security Use Case Views)

Vues pour le dossier technique de l’UE

Le MDR et l’IVDR ne prescrivent pas les noms de vues FDA. Les informations d’architecture étayent l’évaluation de la sécurité logicielle et de l’interaction du dispositif avec l’environnement informatique prévu. Elles doivent expliquer les hypothèses de conception à l’origine de l’évaluation des risques et les conditions que l’utilisateur doit maintenir.

Une vue des flux de données montre où les données cliniques peuvent être lues ou modifiées et quels contrôles les protègent tout au long de ce parcours.
Une vue des interfaces identifie les connexions autorisées et les contrôles qui en limitent l’utilisation. Ces détails étayent les exigences générales de sécurité et de performances (GSPR) applicables.
Une vue de l’environnement d’exploitation explique la protection attendue de l’organisme de santé, par exemple la restriction du segment réseau pouvant accéder à un service de maintenance.
Une vue du chemin de mise à jour décrit comment un correctif testé parvient aux dispositifs concernés et comment récupérer après un échec d’installation.

Le MDCG 2019-16 Rev.1 explique comment les fabricants et les organismes de santé partagent la responsabilité d’une exploitation sécurisée. Ces recommandations aident à relier les hypothèses de conception aux exigences informatiques minimales et aux informations de sécurité fournies avec le dispositif.

Dépendances du système

Le niveau de détail de l’architecture doit correspondre au système réel du dispositif. Un dispositif local simple peut nécessiter moins de vues qu’un système connecté au cloud, mobile, en réseau ou géré en parc. Les dépendances ayant une incidence sur la sécurité du dispositif doivent être incluses même si le client exploite le système connecté.

Cloud et services distants

Incluez un service distant lorsque le dispositif en dépend pour fonctionner en toute sécurité. Par exemple, la perte d’un service d’identité peut affecter les personnes autorisées à accéder au dispositif et la restauration de l’accès local.

Chemins de mise à jour

L’architecture des mises à jour doit décrire le chemin complet, de l’approbation de la version au dispositif en service, notamment l’authenticité, l’intégrité, l’échec de déploiement et la récupération.

Utilisation mobile et à domicile

Le téléphone du patient et son réseau domestique introduisent des contrôles que le fabricant ne gère pas forcément. Expliquez les protections fournies par le dispositif lui-même et les paramètres que l’utilisateur doit maintenir.

Infrastructure clinique partagée

Un système central de surveillance ou d’information hospitalier peut relier de nombreux dispositifs. Montrez comment l’accès à travers ce système partagé pourrait affecter d’autres dispositifs ou patients.

Relier l’architecture aux mesures de maîtrise des risques

Pour chaque interface importante, l’architecture doit aider l’examinateur à trouver la menace concernée et l’essai qui vérifie la protection. Si la conception s’appuie sur une restriction du réseau hospitalier, les informations destinées aux utilisateurs doivent décrire cette restriction afin qu’elle soit maintenue pendant l’utilisation.