Points clés
- La 524B est une exigence légale, pas un guide — la FDA peut refuser d’accepter une soumission non conforme.
- Un cyber device a un logiciel, une capacité internet/réseau, et une vulnérabilité pouvant poser un risque.
- Vous devez soumettre une SBOM listant chaque composant logiciel, y compris tiers et open source.
- La conception sécurisée est attendue : firmware signé, démarrage sécurisé, communications chiffrées, accès au moindre privilège.
- Le post-commercialisation compte le plus : un vrai plan de correctifs par OTA gouvernées et de divulgation coordonnée.
Ce qui a changé en 2023
L’article 524B du FD&C Act a fait de la cybersécurité une condition légale de soumission de précommercialisation pour les dispositifs connectés. Auparavant, la cybersécurité relevait d’un guide non contraignant ; désormais la FDA peut rendre une décision de refus d’acceptation si le dossier manque. Effet pratique : l’ingénierie de cybersécurité passe à l’avant du programme, aux côtés de votre cycle de vie IEC 62304, et non après l’autorisation.
Êtes-vous un « cyber device » ?
La loi définit un cyber device comme un dispositif qui (1) inclut un logiciel, (2) peut se connecter à internet ou à un réseau, et (3) contient une caractéristique technologique pouvant être vulnérable aux menaces de cybersécurité. La plupart des produits IoT médicaux connectés remplissent les trois. Si vous livrez un firmware qui parle à une passerelle, un téléphone ou un nuage, présumez que vous êtes visé.
Ce que contient le dossier 524B
| Élément | Ce que la FDA attend |
|---|---|
| Plan de cybersécurité | Comment vous identifiez, surveillez et traitez les vulnérabilités et exploits tout au long du cycle de vie du dispositif |
| SBOM | Une liste lisible par machine de tous les composants logiciels, incluant commerciaux, open source et sur étagère |
| Preuves de conception sécurisée | Modèle de menaces, architecture et contrôles : firmware signé, démarrage sécurisé, chiffrement, authentification, moindre privilège |
| Processus post-commercialisation | Un processus documenté pour publier mises à jour et correctifs à une cadence raisonnablement justifiée et hors cycle pour les problèmes critiques |
| Divulgation coordonnée | Une politique de divulgation des vulnérabilités pour que les chercheurs signalent les problèmes de façon responsable |
Les quatre contrôles d’ingénierie que les évaluateurs cherchent
Firmware signé et démarrage sécurisé
Les dispositifs ne doivent accepter qu’un firmware dont la signature se valide contre une clé de confiance, et vérifier l’intégrité au démarrage. C’est la défense la plus importante contre les mises à jour malveillantes — et un prérequis pour des OTA dignes de confiance.
Une SBOM réellement maintenable
Une SBOM n’est utile que si elle reste à jour. Générez-la depuis votre build (un avantage d’un outillage de build discipliné) pour que, lorsqu’un CVE de composant survient, vous puissiez répondre « sommes-nous touchés ? » en minutes, pas en semaines.
Communications chiffrées et authentifiées
Les données en transit entre dispositif, passerelle et nuage doivent être chiffrées et mutuellement authentifiées. L’accès au moindre privilège empêche un identifiant compromis de s’emparer de la flotte.
OTA gouvernées pour les correctifs
L’attente post-commercialisation de la 524B est irréalisable sans un chemin de mise à jour fiable et auditable. Vous devez pousser un correctif signé vers une population définie, vérifier qu’il est appliqué et enregistrer qui-a-changé-quoi. Des mises à jour ad hoc ne satisfont pas un évaluateur.
Le post-commercialisation, là où la plupart des plans sont minces
Les équipes surinvestissent dans l’artefact de précommercialisation et sous-investissent dans la réalité opérationnelle : surveiller les nouvelles vulnérabilités dans les composants de votre SBOM, les trier face aux versions de firmware déployées, et livrer un correctif sous contrôle des changements. C’est un programme continu, pas un document. Reliez-le au reste de votre dossier via le carrefour IoT médical conforme, et alignez-le à vos preuves firmware du 510(k) pour que le récit de cybersécurité soit cohérent dans toute la soumission.
Alignement nord-américain et mondial
La 524B est un instrument américain, mais ses attentes font écho aux exigences de sécurité du MDR de l’UE et au guide de Santé Canada. Construisez les contrôles une fois — firmware signé, SBOM, correctifs gouvernés — et vous satisfaites le fond sur les marchés nord-américains et mondiaux, seule l’enveloppe documentaire changeant selon la juridiction.
Où Fundamentum entre en jeu
L’exigence la plus difficile de la 524B est opérationnelle : firmware signé et une façon gouvernée et auditable de corriger une flotte pendant des années. Fundamentum, notre plateforme IoT canadienne, livre exactement cela — prise en charge du démarrage sécurisé, OTA signées et gouvernées, accès par rôle et piste d’audit dans un périmètre SOC 2 Type II — transformant l’attente post-commercialisation en capacité opérationnelle. Elle peut s’interfacer à AWS, Azure ou Google Cloud si votre architecture l’exige. Voir les OTA gouvernées →
Foire aux questions
Qu’est-ce que la FDA 524B ?
L’article 524B du FD&C Act, ajouté par l’Omnibus de 2023, fait de la cybersécurité une exigence légale de précommercialisation pour les dispositifs médicaux connectés. La FDA peut rendre une décision de refus d’acceptation si la soumission d’un cyber device manque du dossier de cybersécurité exigé.
Qu’est-ce qu’un cyber device ?
Un dispositif qui (1) contient un logiciel, (2) peut se connecter à internet ou à un réseau, et (3) a une caractéristique technologique pouvant être vulnérable aux menaces de cybersécurité. La plupart des produits IoT médicaux connectés remplissent les trois ; si votre firmware parle à une passerelle, un téléphone ou un nuage, présumez que vous êtes visé.
Qu’est-ce qu’une SBOM et pourquoi la 524B l’exige-t-elle ?
Une nomenclature logicielle est une liste lisible par machine de chaque composant logiciel, incluant open source et sur étagère. La 524B l’exige pour que, lorsqu’une vulnérabilité de composant est divulguée, vous puissiez déterminer rapidement si votre firmware livré est touché. Générez-la depuis votre build pour qu’elle reste à jour.
La 524B exige-t-elle des mises à jour à distance ?
Elle exige un processus post-commercialisation crédible pour publier des correctifs à une cadence justifiée et hors cycle pour les problèmes critiques. En pratique cela suppose un chemin de mise à jour fiable et auditable : pousser un correctif signé vers une population définie, vérifier son application et enregistrer le changement. Des mises à jour ad hoc ne satisfont pas un évaluateur.
La 524B s’applique-t-elle hors des États-Unis ?
La 524B est un instrument américain, mais ses attentes font écho aux exigences de sécurité du MDR de l’UE et au guide de Santé Canada. Construisez les contrôles une fois — firmware signé, SBOM, correctifs gouvernés — et vous satisfaites le fond sur les marchés nord-américains et mondiaux, seule l’enveloppe documentaire changeant selon la juridiction.
À lire aussi
Parlez à un ingénieur IoT — gratuitement
Réservez un appel-conseil GRATUIT de 30 minutes avec notre équipe. Pas de diapositives, aucune obligation — une vraie séance de travail sur vos questions de connectivité, de plateforme ou de conformité.
