Attaque Stryker : aucun dispositif médical touché, et c'est précisément le problème

Le 11 mars 2026, les salariés de l’un des plus gros fabricants de dispositifs médicaux au monde ont allumé leurs ordinateurs et trouvé des écrans vides. Un attaquant s’était procuré un compte administrateur, avait atteint la console de gestion de flotte de l’entreprise, et avait déclenché un effacement à distance. Pas de rançongiciel, pas de logiciel malveillant déposé : une commande légitime, exécutée par un outil légitime, avec les droits qu’il fallait.

Et pourtant, le détail qui compte pour nous est ailleurs : aucun dispositif médical n’a été affecté. L’entreprise l’a confirmé. Les produits ont continué de fonctionner. Ce qui est tombé, ce sont les postes de travail, les téléphones des salariés, et — plus longtemps — les systèmes d’approvisionnement, de commande et d’expédition.

C’est exactement pour cette raison que l’épisode mérite votre attention. Il désigne l’angle mort que vos référentiels de cybersécurité ne couvrent pas spontanément.

Ce qui est confirmé, et ce qui ne l’est pas

Un mot de méthode avant d’aller plus loin, parce qu’il conditionne tout le reste : dans les jours qui ont suivi, des chiffres spectaculaires ont circulé — des centaines de milliers d’appareils, des pétaoctets de données détruites, des dizaines de téraoctets exfiltrés. Ces chiffres proviennent des revendications du groupe attaquant, pas du fabricant.

Ce que l’entreprise a confirmé est plus sobre : une perturbation globale de son réseau, des dizaines de milliers de terminaux de salariés effacés, aucun logiciel malveillant déployé, et des systèmes logistiques hors service. Les données volées revendiquées par l’attaquant n’ont pas été étayées.

Cette distinction n’est pas de la pinaillerie. Si vous rédigez une analyse d’impact ou une note de veille en reprenant les chiffres d’un communiqué d’attaquant, vous inscrivez de la propagande dans votre système qualité. Un groupe qui vient de mener une opération a tout intérêt à en gonfler l’ampleur : la source d’une donnée fait partie de la donnée.

Le plan de contrôle, angle mort des référentiels

Ouvrez la section 524B, l’IEC 81001-5-1, ou les exigences 17.2 et 17.4 de l’annexe I du MDR. Toutes désignent la même chose : le dispositif. Son logiciel, ses interfaces, son canal de mise à jour, ses composants tiers. C’est légitime — c’est lui qui touche le patient.

Mais ce qui a été compromis chez Stryker n’est pas un dispositif. C’est le plan de contrôle : l’ensemble identité + gestion de flotte qui administre le parc informatique de l’entreprise. Un compte à privilèges, une console capable d’agir sur des dizaines de milliers de terminaux d’un seul geste, et aucune friction entre l’intention et l’exécution.

Or ce plan de contrôle, chez un fabricant de dispositifs médicaux, n’est pas une commodité de DSI. C’est lui qui signe et pousse vos mises à jour. Il héberge vos dossiers de conception, vos enregistrements qualité, vos clés. Il administre les postes depuis lesquels vos développeurs committent du code embarqué.

Un attaquant qui contrôle la chaîne qui pousse vos correctifs n’a pas besoin d’attaquer vos dispositifs. Il attend la prochaine mise à jour.

C’est le chemin qui relie un incident purement informatique à un risque patient. Il ne passe par aucune interface de votre produit.

La FDA demande déjà ce threat model

Voici le point que la plupart des équipes ratent, et il est écrit noir sur blanc dans la guidance premarket de 2023. Le threat model attendu ne doit pas se limiter à l’architecture du produit : il doit capturer les risques introduits par la chaîne d’approvisionnement, la fabrication, le déploiement, l’interopérabilité avec d’autres dispositifs, les activités de maintenance et de mise à jour, et la mise hors service.

La guidance précise même pourquoi : ce sont précisément les risques qu’une analyse de sécurité patient traditionnelle laisse échapper.

Autrement dit, un scénario « un administrateur compromis déclenche une action de masse depuis la console qui gère nos environnements de développement et de déploiement » entre déjà dans le périmètre exigé. Ce n’est pas une extension zélée du référentiel, c’est le référentiel. Dans les dossiers que je relis, ce volet est pourtant presque toujours absent : le threat model s’arrête à la frontière du produit, et la matrice de risques ne comporte aucune ligne sur les processus qui le fabriquent et le maintiennent.

L’IEC 81001-5-1 va dans le même sens en encadrant l’environnement de développement, et l’ISO 13485 vous demande de maîtriser les logiciels utilisés dans le système qualité. Les trois textes convergent sur un point que l’épisode Stryker rend concret : votre chaîne de fabrication logicielle est un actif réglementé.

La contre-mesure recommandée est une mesure d’organisation

Après l’incident, la CISA a formulé une recommandation d’une simplicité désarmante : exiger l’approbation d’un second administrateur avant toute opération sensible ou à fort impact — un effacement de masse, typiquement — dans les outils de gestion de flotte.

Ce qui mérite d’être noté, c’est la nature de cette mesure. Ce n’est pas un correctif logiciel, ce n’est pas une couche de chiffrement, et ça ne vit nulle part dans votre dispositif. C’est un contrôle à quatre yeux sur une opération irréversible : de la gouvernance, pas de la technique. Le même raisonnement que celui qui vous fait exiger deux signatures sur une libération de lot.

L’authentification forte par clé matérielle complète le dispositif en amont, sur les comptes à privilèges — elle résiste à l’hameçonnage là où une notification à valider d’un doigt ne résiste pas. Mais c’est bien la double validation des opérations destructrices qui aurait limité l’ampleur de ce qui s’est passé.

Ce que ça donne dans votre threat model

Les lignes à ajouter, sur le modèle « une menace × un groupe d’actifs » :

Aucune de ces lignes ne parle du logiciel embarqué dans votre produit. Toutes relèvent pourtant du threat model que la FDA attend dans votre soumission.

Le vrai enseignement

Il ne s’agit pas de dire qu’un grand fabricant a mal travaillé — l’entreprise a d’ailleurs contenu l’incident sans que ses produits soient touchés, ce qui n’est pas rien. Il s’agit de constater où la brèche s’est ouverte : au point exact où l’informatique d’entreprise croise la chaîne qui produit et maintient des dispositifs médicaux.

C’est le point que les référentiels décrivent le moins bien, que les organismes notifiés interrogent le moins, et que les équipes documentent en dernier. Le rattrapage n’est pas énorme : quelques lignes de matrice, un contrôle à quatre yeux sur les opérations irréversibles, et de l’authentification forte sur les comptes qui comptent. Encore faut-il avoir posé la question — et la poser tôt coûte infiniment moins cher que de la découvrir dans une lettre de non-conformité.

FAQ

Nos dispositifs ne sont pas connectés : sommes-nous concernés ?

Oui, et c’est précisément la leçon. L’incident n’a transité par aucune interface de dispositif. Il a visé l’infrastructure d’administration du fabricant — laquelle existe que vos produits soient connectés ou non, dès lors que vous développez du logiciel, gérez des postes et poussez des mises à jour, même par clé USB ou par intervention d’un technicien.

Faut-il documenter l’informatique interne dans le dossier réglementaire ?

Pas l’informatique interne dans son ensemble, non. Ce qui entre dans le périmètre, c’est ce qui touche au cycle de vie du dispositif : environnements de développement et de build, canal de mise à jour, outils du système qualité au sens de l’ISO 13485. La guidance FDA nomme explicitement la chaîne d’approvisionnement, la fabrication, le déploiement, la maintenance et la mise hors service parmi les périmètres à modéliser.

Par où commencer si notre threat model s’arrête au produit ?

Par une seule question posée à votre équipe : quelles opérations, chez nous, sont irréversibles et exécutables par une seule personne ? Effacement de flotte, publication d’une mise à jour, suppression d’un dépôt, rotation de clés. Chacune donne une ligne de matrice, et la plupart se traitent par une double validation plutôt que par un projet technique. C’est le meilleur rapport effort/risque du sujet.