HSA publie GL-10 : cybersécurité des DM

L'Health Sciences Authority de Singapour (HSA) a publié le guide GL-10-R1, Best Practices Guide for Medical Device Cybersecurity. L'historique des révisions l'enregistre comme une première publication prenant effet le 17 août 2026. La liste des lignes directrices relatives aux dispositifs médicaux de l'HSA intitule le fichier « GL-10-R1 … (2026 Aug) PUB ». Un avis de réponse à la consultation du 14 août 2026 indique que l'HSA a intégré les commentaires du public et a publié le guide finalisé sur cette liste.

Le statut juridique du GL-10 constitue le premier élément essentiel. La section 2 précise : « Ce document ne constitue pas une ligne directrice réglementaire et n'établit pas d'exigences ou d'attentes réglementaires pour la soumission pré-commercialisation ou l'enregistrement. » Il s'agit de conseils pratiques pour gérer la cybersécurité tout au long du cycle de vie global du produit (TPLC) des dispositifs connectés. Il ne s'agit pas d'un nouveau texte législatif sur la cybersécurité, ni d'une liste de contrôle pour l'enregistrement, ni d'un remplacement des lignes directrices réglementaires distinctes de l'HSA relatives aux logiciels.

Qui et quoi relèvent du champ d'application

Le guide s'applique à tous les dispositifs médicaux généraux et DMDIV connectés mis sur le marché singapourien, qu'ils soient exclusivement réservés à un usage professionnel (PUO) ou non-PUO. Il couvre les dispositifs nouvellement fournis à Singapour et les dispositifs déjà installés et en cours d'utilisation.

Le lectorat visé comprend les fabricants, les titulaires de l'enregistrement du produit, les importateurs, les mandataires locaux et les prestataires de soins de santé. Les recommandations destinées aux fabricants débutent dès la phase de développement. Les responsabilités des prestataires de soins de santé décrites dans le guide commencent à la phase de support et se poursuivent durant le support limité et la fin de support.

Le GL-10 ne crée pas de nouvelle classe de dispositifs connectés ni ne modifie les catégories d'enregistrement du SMDR. Cet article traite uniquement de ce que le GL-10 énonce lui-même.

Le modèle TPLC dans le GL-10

Le GL-10 structure les activités de cybersécurité en quatre étapes : Développement, Support, Support limité et Fin de support. Le Support limité se situe entre la fin de vie (EOL) et la fin de support (EOS). Selon les définitions de l'HSA, l'EOL signifie que le fabricant ne vend plus le produit au-delà de sa durée de vie utile définie et que le support peut être réduit ; l'EOS signifie que le fabricant a mis fin à ses activités de support technique.

Le transfert opérationnel lors de l'EOS est strictement encadré. Pour les dispositifs ayant été préalablement mis sur le marché singapourien avec un cycle de vie de cybersécurité adéquat pris en charge par le fabricant, la responsabilité opérationnelle de la gestion des risques liés à une utilisation continue après l'EOS est transférée au prestataire de soins de santé. Ce transfert :

• ne décharge pas le fabricant, le titulaire de l'enregistrement du produit, l'importateur ou le mandataire local de leurs obligations continues, notamment la communication des risques connus pour la sécurité, l'appui aux actions de sécurité appropriées et la notification réglementaire applicable ; et
• ne doit pas être interprété comme un motif permettant de transférer les responsabilités du fabricant relatives au cycle de vie vers les prestataires de soins de santé avant l'EOS.

Le GL-10 recommande d'amorcer la transition du Support vers le Support limité environ deux à trois ans avant l'EOS, avec la réserve que ce calendrier peut varier selon la complexité et la criticité du dispositif. Ce calendrier constitue une recommandation du guide et non un délai de préavis légal.

Ce que le GL-10 recommande durant la phase de développement

Durant la phase de développement, les recommandations de l'HSA s'articulent autour de la conception de la sécurité, de la gestion des risques, des essais, des informations destinées aux utilisateurs, d'un plan post-commercialisation et d'une nomenclature logicielle (SBOM).

Sécurité dès la conception (Secure by Design) et sécurité par défaut (Secure by Default). La sécurité dès la conception implique d'intégrer la sécurité dans l'architecture dès le départ. La sécurité par défaut signifie que le dispositif est configuré pour être aussi sécurisé que possible sans que l'utilisateur n'ait à modifier les paramètres.

Gestion des risques. Le guide considère que la cybersécurité relève de la gestion des risques tout au long du cycle de vie, de la conception jusqu'à l'EOL. Lorsque la probabilité d'une cyberattaque intentionnelle est difficile à estimer, il recommande d'évaluer l'exploitabilité des vulnérabilités connues, notamment par les méthodes du Common Vulnerability Scoring System (CVSS). L'ordre de priorité de la maîtrise des risques suit l'ISO 14971 : sécurité intrinsèque par la conception, puis mesures de protection, et enfin informations pour la sécurité.

Informations destinées aux utilisateurs. Les recommandations relatives aux informations destinées aux utilisateurs au stade du développement comprennent des informations sur la fin de support (EOS) en matière de cybersécurité et un SBOM.

Plan post-commercialisation. Le plan recommandé couvre la vigilance post-commercialisation, la divulgation des vulnérabilités, l'application des correctifs et des mises à jour, la récupération et le partage d'informations.

SBOM. Le GL-10 décrit un SBOM comme une liste détaillée des composants logiciels, incluant les outils open source, les logiciels tiers et les bibliothèques. Les éléments clés énumérés sont le nom de l'auteur, l'horodatage, le fournisseur du composant logiciel, le nom, la version, l'identifiant unique et la relation de dépendance. Deux cas d'usage illustratifs montrent un fabricant utilisant un SBOM pour la chaîne d'approvisionnement et la gestion des correctifs, et un prestataire de soins de santé utilisant les SBOM des fournisseurs lors de la réponse aux incidents. Il s'agit d'exemples et non de modèles de dossiers obligatoires.

Dispositifs intégrant de l'IA. La section 6.7 constitue une considération supplémentaire et non une nouvelle voie d'enregistrement pour l'IA. Elle indique que l'IA générative introduit des menaces telles que l'injection d'instructions (prompt injection), les hallucinations, la désinformation et les fuites accidentelles de données, qui doivent être traitées parallèlement aux menaces traditionnelles de cybersécurité. Les axes prioritaires recommandés sont la conception du modèle, la protection de la chaîne d'approvisionnement de l'IA, le déploiement sécurisé ainsi que la sécurité pendant l'exploitation et les mises à jour.

Étant donné que le GL-10 ne constitue pas une ligne directrice réglementaire, aucun des éléments ci-dessus ne devient une attente de soumission pré-commercialisation de l'HSA du simple fait de figurer dans ce document. Les fabricants doivent toujours se conformer à toutes les obligations en matière de cybersécurité, de logiciels et de post-commercialisation applicables en vertu d'autres textes de l'HSA. Le GL-10 est une cartographie des pratiques que l'HSA considère comme utiles tout au long de ce cycle de vie.

Ce qui change lors des phases de Support, de Support limité et d'EOS

Durant la phase de Support, les fabricants doivent fournir un support complet en matière de cybersécurité, y compris les correctifs et les mises à jour. Les titulaires de l'enregistrement du produit, les importateurs et les mandataires locaux doivent contribuer à transmettre ce support et ces informations aux utilisateurs à Singapour. Les prestataires de soins de santé ne sont pas censés assumer l'intégralité de la charge de cybersécurité tant que le support du fabricant demeure disponible.

Durant la phase de Support limité, le support du fabricant diminue. Le guide recommande aux fabricants d'informer les utilisateurs de cette réduction, du calendrier restant avant l'EOS, des composants non pris en charge, des mises à jour logicielles disponibles et des contrôles compensatoires. Les prestataires de soins de santé sont invités à réévaluer la poursuite de l'utilisation au regard du risque de sécurité, de la convivialité résiduelle, des ressources de support et de l'impact sur les patients.

À l'EOS, le prestataire de soins de santé assume la responsabilité opérationnelle principale des risques de cybersécurité liés à une utilisation continue sans support actif du fabricant, toujours uniquement pour les dispositifs ayant bénéficié d'un cycle de vie de cybersécurité adéquat pris en charge par le fabricant. Les fabricants doivent toujours transmettre les informations relatives à la sécurité du produit, communiquer sur la transition vers l'EOS et poursuivre la communication sur la sécurité des patients liée à la cybersécurité connue ainsi que les notifications réglementaires applicables.

Le GL-10 indique également que les prestataires de soins de santé doivent se conformer aux Cyber & Data Security Guidelines for Healthcare Providers du ministère de la Santé en vertu de l'Health Information Act 2026. Il s'agit d'une obligation pour les prestataires de soins de santé mentionnée par le GL-10, et non d'une nouvelle exigence d'enregistrement de dispositifs médicaux établie dans le GL-10 lui-même.

Articulation avec les lignes directrices logicielles de l'HSA

Le GL-10 est un nouveau document de première édition. Il ne révise pas le GL-04-R4, qui constitue les lignes directrices réglementaires de l'HSA relatives aux dispositifs médicaux logiciels, y compris les dispositifs intégrant l'apprentissage automatique. Conservez ces deux documents dans des dossiers distincts : le GL-04 traite de l'enregistrement des logiciels et de la maîtrise des modifications ; le GL-10 traite des pratiques de cybersécurité des dispositifs connectés et ne définit pas d'attentes en matière de soumission.

Ce que les fabricants doivent faire d'un guide non contraignant

L'utilisation recommandée du GL-10 par Pure Global consiste à vérifier si le portefeuille connecté de l'entreprise à Singapour peut effectivement être exploité selon la cartographie du TPLC de l'HSA — et non à traiter ce PDF comme un nouveau dossier d'enregistrement :

1. Répertorier chaque dispositif médical général et DMDIV connecté sur le marché singapourien, y compris la base installée, et lui attribuer l'étape actuelle du TPLC (Développement, Support, Support limité ou EOS).
2. Établir ou confirmer les dates d'EOL et d'EOS ainsi que le plan de communication de deux à trois ans recommandé par le GL-10 avant l'EOS. Les titulaires de l'enregistrement du produit, les importateurs et les mandataires locaux doivent être en mesure de fournir ces informations à Singapour.
3. Vérifier le dossier de développement par rapport aux rubriques du GL-10 : Secure by Design/Default, gestion des risques tout au long du cycle de vie, essais, informations destinées aux utilisateurs (y compris les informations EOS et le SBOM) et le plan post-commercialisation en cinq volets.
4. Confirmer que le SBOM peut soutenir la réponse aux incidents, en utilisant au moins les sept éléments clés répertoriés par l'HSA. Le GL-10 n'impose aucun format de fichier.
5. Maintenir l'analyse des menaces liées à l'IA au sein de la gestion des risques de cybersécurité lorsque l'IA générative est présente dans le dispositif, sans traiter la section 6.7 comme une règle de soumission d'IA autonome de l'HSA.
6. Ne pas transférer prématurément les obligations du fabricant. Le transfert opérationnel à l'EOS est encadré et n'annule pas la communication sur les risques connus ni les notifications réglementaires applicables.

Consultez le guide GL-10-R1 complet et l'avis de réponse à la consultation de l'HSA. Pour le contexte du marché singapourien, voir l'entrée de glossaire HSA, l'aperçu du marché de Singapour et la réglementation des dispositifs médicaux de l'HSA. Le service de cybersécurité des dispositifs médicaux de Pure Global couvre les travaux de sécurité du TPLC qui s'articulent avec l'enregistrement auprès de l'HSA, sans s'y substituer.