La plupart des fabricants de dispositifs médicaux pensent que la conformité CRA ne s'applique pas à eux. Ils ont en partie raison. Et c'est là que réside le danger.
Exemption relative aux instruments médicaux de l'ARC : l'exposition qu'elle crée
Les dispositifs médicaux réglementés par le RDM et le RDIV sont explicitement exclus du CRA. Votre logiciel embarqué – la partie qui est considérée comme un dispositif médical – reste soumis à la norme CEI 62304, à l'annexe I du RDM et aux exigences connexes en matière de cybersécurité.
Mais votre appareil ne fonctionne pas seul.
Il se connecte à une application compagnon. Il communique avec un tableau de bord cloud. Il reçoit les mises à jour du micrologiciel via un serveur de mise à jour. Il transmet les données via WiFi ou Bluetooth.
Chacun de ces composants peut être soumis à une réglementation différente. Et la plupart d'entre eux ne sont pas exemptés.
CRA, MDR et RED : trois réglementations pour un seul dispositif médical
Le règlement MDR / IVDR réglemente le dispositif médical lui-même.
La directive sur les équipements radioélectriques (RED) réglemente les équipements radioélectriques connectés à Internet. Les exigences en matière de cybersécurité prévues aux articles 3.3(d), (e) et (f) sont devenues obligatoires le 1er août 2025.
La loi sur la cyber-résilience (CRA) réglemente les produits comportant des éléments numériques, notamment les applications compagnons, les services cloud et les infrastructures de mise à jour qui ne sont pas classés comme des dispositifs médicaux.
Votre appareil peut être exempté. Votre écosystème ne l'est pas.
Exception importante : même dans le cadre de l'exemption actuelle de la CRA , les dispositifs médicaux portables (dispositifs portés sur le corps) doivent satisfaire aux exigences de la CRA. L'exemption est plus restrictive que ne le supposent de nombreux fabricants.
11 septembre 2026 : la date butoir à laquelle personne ne se prépare
La mise en application complète de la CRA débutera le 11 décembre 2027. Cependant , les obligations de signalement des vulnérabilités prévues à l'article 14 entreront en vigueur le 11 septembre 2026.
À compter de cette date, les fabricants des produits concernés doivent :
- Soumettre une alerte précoce à l'ENISA et aux CSIRTnationaux dans les 24 heures suivant la découverte d'une vulnérabilité activement exploitée.
- Fournir une notification détaillée de la vulnérabilité dans les 72 heures.
- Soumettre un rapport final au plus tard 14 jours après la mise en place d'une mesure corrective.
Il ne s'agit pas d'un exercice de documentation. C'est une capacité opérationnelle que vous possédez ou non.
Remarque pour les PME : la CRA prévoit que les microentreprises et les petites entreprises ne peuvent être sanctionnées pour ne pas avoir respecté le délai de déclaration de 24 heures. Toutefois, l'obligation de déclaration reste applicable et l'infrastructure opérationnelle nécessaire pour détecter et évaluer les vulnérabilités doit toujours être en place.
Un scénario qui peut se produire
Une vulnérabilité critique d'OpenSSL est activement exploitée dans la nature.
Votre tableau de bord cloud utilise OpenSSL 1.1.1. Votre application compagnon utilise une bibliothèque partagée qui en dépend. Votre serveur de mise à jour OTA n'a pas été audité depuis 18 mois.
Pouvez-vous répondre à ces questions dès maintenant ?
- Quels sont les produits déployés concernés ?
- Cette vulnérabilité est-elle exploitable dans votre configuration spécifique ?
- Pouvez-vous prévenir les autorités dans les 24 heures ?
- Pouvez-vous déployer un correctif sécurisé sur l'ensemble de votre base installée ?
Sinon, vous n'êtes pas prêt pour septembre 2026.
L'exemption pourrait ne pas durer
En décembre 2025, la Commission européenne a publié une proposition visant à modifier le RDM et le RDIV afin de supprimer complètement l'exemption CRA pour les dispositifs médicaux. Selon cette proposition, la cybersécurité serait explicitement ajoutée aux exigences générales de sécurité et de performance (GSPR) figurant à l'annexe I du RDM et du RDIV, et les dispositifs médicaux ne seraient plus exclus du CRA.
La proposition introduit également de nouvelles obligations pour les fabricants de dispositifs médicaux, qui devront signaler les vulnérabilités activement exploitées et les incidents cybernétiques graves aux CSIRT nationaux et à l'ENISA, conformément aux exigences de l'article 14 de la CRA.
Il s'agit d'une proposition de la Commission qui n'a pas encore été adoptée. Elle doit être approuvée par le Parlement européen et le Conseil, ce qui prend généralement entre 12 et 24 mois. Mais la direction est claire : les obligations en matière de cybersécurité pour les fabricants de dispositifs médicaux sont en train de s'étendre, et non de se réduire.
Que l'exemption soit maintenue ou supprimée, les infrastructures techniques dont vous avez besoin restent les mêmes : SBOM, surveillance CVE, mises à jour OTA et capacité de réponse aux incidents.
Ce que la conformité CRA signifie pour votre équipe d'ingénieurs
Dans les domaines MDR, RED et CRA, les régulateurs s'accordent sur un principe : les fabricants doivent connaître le contenu de leurs logiciels, les surveiller en permanence et les corriger rapidement.
Ce problème ne peut être résolu en engageant un consultant en réglementation pendant deux semaines. Il nécessite la mise en place d'une infrastructure technique :
- Une nomenclature logicielle (SBOM) dérivée de la compilation – pas un simple tableur, mais un artefact actif issu de votre pipeline de compilation réel.
- Surveillance continue des CVE par rapport à vos binaires déployés
- Capacité de mise à jour sécurisée par liaison radio (OTA)
- Documentation prête pour l'audit qui relie votre SBOM à votre analyse des risques
- Fournisseurs qualifiés selon la norme ISO 13485 pour les composants logiciels critiques
La conformité en matière de cybersécurité relève désormais d'une décision architecturale et non plus d'une simple considération réglementaire après coup.
La vraie question
La question n'est pas de savoir si la CRA s'applique aujourd'hui à votre dispositif médical.
La question est de savoir si l'ensemble de votre écosystème de produits ( système d'exploitation des appareils, application compagnon, backend cloud, infrastructure de mise à jour ) pourra résister à l'examen réglementaire après septembre 2026. Et si vous serez prêt lorsque l'exemption sera encore restreinte ou disparaîtra complètement.
La date limite pour signaler les vulnérabilités à l'ARC est le 11 septembre 2026. Comptez à rebours à partir de cette date : voilà le temps dont vous disposez.
Cadre réglementaire décrit en février 2026.
Êtes-vous prêt pour l'ARC ? Découvrez-le en 5 minutes.
Nous avons publié un livre blanc détaillé comprenant une liste de contrôle d'auto-évaluation couvrant les trois réglementations (MDR, RED, CRA), un guide de classification des composants, les montants des sanctions et un plan d'action de 90 jours pour être opérationnel avant septembre 2026.
Vous ne pouvez pas attendre 90 jours ?
Nous fournissons la couche OS dont dépend votre conformité CRA.
SBOM · Surveillance CVE · Mises à jour OTA · Documents IEC 62304 — en 30 jours.
PRENDRE RENDEZ-VOUS POUR UN ENTRETIEN PRÉLIMINAIRE →Certifié ISO 13485 (développement logiciel et cybersécurité) · l4b-software.com
**Cet article est fourni à titre informatif uniquement et ne constitue en aucun cas un avis juridique ou réglementaire.
Vous devez être connecté pour poster un commentaire.