FDA §524B : le plan cybersécurité sans lequel votre dossier sera refusé

Si vous visez le marché américain avec un logiciel médical connecté, la cybersécurité n’est plus un chapitre de votre dossier : c’est une condition légale de recevabilité. Depuis 2023, la FDA peut refuser (« Refuse to Accept ») une soumission qui n’inclut pas les éléments exigés par la section 524B du FD&C Act. Voici ce que dit la loi, ce que la FDA attend concrètement, et comment vous y préparer quand vous venez du référentiel européen.

Qu’est-ce que la section 524B ?

Définition : la section 524B du FD&C Act, introduite en 2023 par le Consolidated Appropriations Act, impose aux fabricants de « cyber devices » de démontrer, dès la soumission premarket, qu’ils assurent la cybersécurité du dispositif sur tout son cycle de vie. Contrairement aux guidances de la FDA, qui expriment des recommandations, la 524B est une exigence légale : son absence justifie un refus du dossier avant même l’examen scientifique.

Votre produit est-il un « cyber device » ?

La loi pose trois critères cumulatifs. Est un cyber device tout dispositif qui :

1. inclut du logiciel validé, installé ou autorisé par le fabricant en tant que dispositif ou dans un dispositif ;
2. a la capacité de se connecter à Internet ;
3. contient des caractéristiques technologiques qui pourraient être vulnérables à des menaces de cybersécurité.

En pratique, tout SaMD moderne coche les trois cases : une app mobile avec backend, un dispositif avec télémaintenance, un algorithme servi par API. La question n’est pas « suis-je concerné ? » mais « qu’est-ce que je dois produire ? ».

Quelles sont les 4 exigences légales ?

La 524B impose quatre obligations, à documenter dans la soumission :

1. Un plan de surveillance et de correction des vulnérabilités : comment vous surveillez, identifiez et traitez les vulnérabilités et exploits après commercialisation, y compris la divulgation coordonnée des vulnérabilités (CVD) et les procédures associées.
2. Des processus donnant une assurance raisonnable que le dispositif et ses systèmes sont sécurisés, avec mises à jour et correctifs après commercialisation : en cycle régulier pour les vulnérabilités connues, et hors cycle, dès que possible, pour les vulnérabilités critiques activement exploitées.
3. Une SBOM (Software Bill of Materials) couvrant les composants commerciaux, open source et prêts à l’emploi — le format CycloneDX est un choix courant et outillé.
4. Le respect de toute autre exigence que la FDA impose par règlement pour démontrer une assurance raisonnable de cybersécurité.

La 524B ne demande pas un produit invulnérable. Elle demande la preuve que vous saurez réagir quand une vulnérabilité apparaîtra — car elle apparaîtra.

Que demande la guidance premarket de la FDA ?

La guidance « Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions », publiée en septembre 2023 puis mise à jour en 2025, détaille le contenu attendu dans le dossier. Les blocs structurants :

• Un Secure Product Development Framework (SPDF) : la sécurité intégrée à la conception, au développement et à la maintenance — l’esprit est très proche de l’IEC 81001-5-1.
• Un threat model documenté couvrant le dispositif et son système (app, backend, mises à jour, interfaces).
• Une analyse de risques cybersécurité distincte de l’analyse de risques sécurité patient, avec le lien entre les deux.
• Des tests de sécurité : analyse statique et dynamique, tests de robustesse/fuzzing, test d’intrusion, avec rapports.
• La SBOM accompagnée du niveau de support de chaque composant et de sa fin de vie.
• Des vues d’architecture sécurité : schémas des flux de données, interfaces, mécanismes d’authentification et de chiffrement.
• Un plan de gestion des vulnérabilités post-market aligné avec les quatre obligations légales.

Quelles différences avec l’approche européenne ?

Si vous êtes déjà conforme MDR + IEC 81001-5-1, vous avez une base solide, mais pas une équivalence :

Le point structurant : un même socle technique — threat model, SBOM, gestion des vulnérabilités, tests de sécurité — alimente les deux dossiers. Ce qui diverge, c’est l’emballage documentaire et le niveau de détail exigé sur le post-market. Construisez le socle une fois, déclinez-le par marché.

Checklist de préparation en 8 points

1. Statuez formellement sur la qualification « cyber device » de votre produit, par écrit, critère par critère.
2. Générez une SBOM automatisée (CycloneDX) à chaque build, incluant dépendances transitives et composants d’infrastructure embarqués.
3. Documentez un threat model couvrant le dispositif complet : app, API, cloud, mécanisme de mise à jour.
4. Formalisez votre processus de gestion des vulnérabilités : veille, triage avec délais, critères de criticité, décision de patch en cycle ou hors cycle.
5. Publiez une politique de divulgation coordonnée des vulnérabilités (point de contact, engagement de traitement).
6. Constituez vos preuves de tests de sécurité : SAST, SCA, fuzzing des interfaces, pentest par un tiers, et le traitement des findings.
7. Décrivez l’architecture sécurité : schémas de flux, segmentation, authentification, chiffrement au repos et en transit.
8. Alignez le post-market : intégrez la surveillance cybersécurité à vos procédures existantes de surveillance après commercialisation, avec des rôles nommés.

Si vous partez de zéro, comptez un trimestre pour constituer un dossier 524B crédible sur un produit existant — moins si votre rattrapage IEC 81001-5-1 est déjà fait, car l’essentiel des artefacts est commun. Le pire scénario reste de découvrir la 524B dans la lettre de refus de la FDA : à ce stade, c’est votre calendrier de mise sur le marché américain qui devient la principale vulnérabilité.