La liste des exclusions est réelle, et elle est presque toujours lue de travers
L'article 2 du règlement (UE) 2024/2847 retire plusieurs catégories de produits du règlement sur la cyberrésilience, au motif que d'autres règles de l'Union traitent déjà les mêmes risques à un niveau égal ou supérieur. Les dispositifs médicaux et les diagnostics in vitro régis par les règlements (UE) 2017/745 et 2017/746 sont exclus. Les véhicules à moteur couverts par le régime de réception par type au titre du règlement (UE) 2019/2144 sont exclus. Les produits de l'aviation civile certifiés au titre du règlement (UE) 2018/1139 sont exclus. Les équipements marins entrant dans le champ de la directive 2014/90/UE sont exclus. L'article 2 porte aussi une exemption étroite pour les pièces de rechange et un mécanisme d'acte délégué permettant à la Commission de limiter ou d'exclure l'application du RCR lorsque des règles sectorielles atteignent le même niveau de protection ou un niveau supérieur.
Lisez cette liste dans une réunion de cadrage et la conclusion s'écrit toute seule : nous sommes une entreprise medtech, les dispositifs médicaux sont exclus, nous avons fini. Cette conclusion a été fausse dans chaque exercice de cadrage que j'attendrais dans une entreprise réglementée, et la raison est structurelle plutôt qu'un chipotage juridique.
Les exclusions s'attachent aux produits, pas aux entreprises. Il n'existe pas de fabricant exclu au titre du RCR. Il existe des produits exclus, définis par leur destination, qui siègent dans des portefeuilles contenant d'autres choses. Pour savoir qui porte l'obligation au départ, voir à qui s'applique le règlement sur la cyberrésilience.
Cette seule distinction est l'article entier. Ce qui suit est ce que cela coûte à chaque secteur qui se trompe.
| Frontière | Exclu ou hors périmètre | Dans le champ | Test décisif |
|---|---|---|---|
| Medtech | Dispositif médical ou diagnostic in vitro régi par le MDR ou l'IVDR | Logiciel de bien-être, de fitness ou d'administration hospitalière vendu comme produit distinct | La destination du produit |
| Véhicules à moteur | Système livré dans un véhicule réceptionné par type | Le même système vendu séparément comme produit après-vente | Sa couverture par le régime de réception par type des véhicules |
| Drones | Drone de la catégorie certifiée | Drone de la catégorie ouverte ou spécifique s'il répond à la définition du produit | L'exigence d'une certification au titre du règlement de base sur l'aviation |
| Pièces de rechange | Remplacement identique fabriqué selon les mêmes spécifications | Remplacement qui modifie la fonction ou la conception | Son identité réelle avec le produit d'origine |
| Cloud et SaaS | SaaS autonome et indépendant d'un produit physique | Service cloud requis pour une fonction essentielle du produit lorsque le test de traitement distant est rempli | La dépendance fonctionnelle du produit à un traitement contrôlé par le fabricant |
| Open source | Logiciel open source réellement non commercial | Code open source intégré dans un produit commercial | L'activité commerciale, le statut de gestionnaire et l'intégration en aval |
Medtech : l'exclusion couvre le dispositif et s'arrête là
L'exclusion MDR et IVDR est réelle. Elle a aussi un bord dur, et ce bord est la destination.
Un logiciel qui analyse des données pour un diagnostic médical spécifique est un dispositif médical et est exclu. Un logiciel commercialisé pour le fitness général, le suivi du bien-être ou l'administration hospitalière n'est pas un dispositif médical, n'hérite pas de l'exclusion, et siège pleinement dans le RCR. Une entreprise qui vend un dispositif de classe II au titre du MDR et une application compagnon de bien-être fait tourner deux régimes réglementaires à la fois, et le second a une obligation de déclaration à partir du 11 septembre 2026.
Trois autres endroits où l'exclusion s'arrête :
Composants vendus séparément. Les systèmes d'exploitation, microcontrôleurs, modules de communication et bibliothèques logicielles qui vivent à l'intérieur d'un dispositif réglementé sont exclus en tant que partie de ce dispositif. Vendus seuls comme produits comportant des éléments numériques, ils entrent dans le champ selon leurs propres termes.
Tout ce qui n'est pas le dispositif. L'exclusion concerne les produits mis sur le marché. Elle ne dit rien du patrimoine informatique de l'organisation, là où vivent vos obligations NIS2 si vous êtes une entité essentielle ou importante du secteur de la santé.
Le sens de la marche. La Commission a proposé en décembre 2025 des amendements au MDR et à l'IVDR qui écriraient explicitement la cybersécurité dans les exigences générales de sécurité et de performance et introduiraient la déclaration des vulnérabilités activement exploitées et des incidents graves aux CSIRT nationaux et à l'ENISA. S'ils sont adoptés sous cette forme, l'effet pratique est que le medtech reçoit des obligations de déclaration en forme de RCR via le droit des dispositifs médicaux plutôt que via le RCR. L'exclusion survit, le travail arrive quand même. Construire maintenant la capacité de détection et d'escalade est le chemin le moins cher dans les deux cas.
Automobile, aviation, marine : le retrait suit le régime, pas la pièce
L'exclusion véhicule couvre les systèmes livrés à l'intérieur d'un véhicule réceptionné par type. Le même système vendu séparément, hors de ce régime, reste dans le champ. Un fournisseur qui expédie une unité télématique aftermarket ne peut pas pointer vers le retrait de réception par type.
L'aviation est l'illustration la plus nette. Les produits certifiés au titre du règlement de base sur l'aviation sont exclus. Les drones ne sont exclus que lorsqu'ils tombent dans la catégorie certifiée. Les aéronefs sans équipage dans les catégories ouverte ou spécifique n'exigent pas cette certification, et ils restent dans le champ du RCR.
L'exemption des pièces de rechange suit la même logique : elle couvre les remplacements identiques fabriqués selon les mêmes spécifications. Un remplacement qui diffère en fonction ou en conception est un nouveau produit comportant des éléments numériques.
Open source : l'exemption concerne l'activité commerciale, pas la licence
Les logiciels open source non commerciaux développés en dehors d'une activité commerciale se situent largement hors périmètre. Deux choses resserrent cela en pratique.
Le RCR crée une catégorie juridique distincte, le gestionnaire de logiciels open source, pour les entités qui apportent un soutien soutenu à des produits open source destinés à une activité commerciale. Les gestionnaires portent un régime allégé et adapté : une politique de cybersécurité, une coopération avec les autorités de surveillance du marché, et la déclaration des vulnérabilités activement exploitées. Ils sont explicitement hors des amendes administratives de l'article 64, ce qui est un soulagement significatif et non une exemption des obligations elles-mêmes.
Et l'exemption ne voyage pas en aval. Le code open source embarqué dans un produit commercial est à l'intérieur du périmètre de ce produit, et l'intégrateur commercial le porte. « C'est en amont et c'est sous licence MIT » n'est pas un argument de périmètre.
SaaS : hors, jusqu'à ce que le produit en dépende
Le logiciel en tant que service autonome qui fonctionne indépendamment d'un produit physique est hors du périmètre RCR. C'est l'exclusion que vos acheteurs entendront le plus souvent de la part des éditeurs, et elle est généralement correcte.
Le test qui compte est la frontière de la solution de traitement de données à distance. Un composant cloud est à l'intérieur du périmètre du produit lorsque le produit physique dépend fonctionnellement de ce traitement distant pour exécuter une fonction essentielle, et que le logiciel distant est développé par le fabricant ou sous sa responsabilité. Les fonctionnalités cloud accessoires sont hors. Celles qui portent la charge sont dedans.
La raison pour laquelle cela compte commercialement est que la réponse bascule à mesure que les produits évoluent. Un appareil qui rappelait le cloud pour de l'analytique optionnelle en 2023 et qui ne peut plus démarrer sans contrôle de licence a traversé la ligne sans que personne ne dépose de changement de périmètre.
Ce qu'aucune exclusion ne touche
Quel que soit ce qui s'applique ci-dessus, trois choses restent inchangées.
Vos obligations NIS2. Si vous êtes une entité essentielle ou importante, vous portez des obligations de gestion des risques et de sécurité de la chaîne d'approvisionnement que vos produits soient ou non dans le RCR. La liste d'exclusions du RCR n'est pas une liste d'exclusions NIS2.
Votre position d'acheteur. Chaque organisation sur cette page achète des produits comportant des éléments numériques à des fabricants qui sont dans le champ. La posture RCR de vos fournisseurs est une question d'achat vivante à partir du 11 septembre 2026, lorsque leur obligation de déclaration commence. Voir quoi demander aux fournisseurs de produits comportant des éléments numériques.
Vos obligations DORA, si vous êtes une entité financière. Instrument différent, horloge différente, même incident sous-jacent.
Comment mener la décision de cadrage pour qu'elle survive à la revue
L'échec n'est en général pas de se tromper sur le droit. C'est de faire l'analyse une fois, au niveau entreprise, et de ne jamais y revenir.
Faites-la par produit, et enregistrez quatre choses pour chacun : la destination telle que commercialisée, l'exclusion invoquée avec l'article cité, qui a validé, et la date. Puis fixez un déclencheur de revue plutôt qu'une date de revue, parce que ce qui change le périmètre est un changement de produit : une nouvelle application compagnon, un composant vendu séparément, une dépendance cloud qui devient porteuse, une variante qui n'est pas une pièce de rechange identique.
C'est un registre avec des propriétaires et des déclencheurs de revue, c'est-à-dire la chose que votre système de management fait déjà pour chaque autre question d'applicabilité. Le faire comme une diapositive ponctuelle dans un atelier de cadrage est ce qui produit la réponse qui s'effondre dix-huit mois plus tard.
Le RCR l'anticipe, et c'est la partie que la plupart des exercices de cadrage manquent. Lorsqu'une exigence essentielle n'est pas applicable à un produit, le fabricant doit inclure une justification claire à cet effet dans la documentation technique plutôt que de simplement laisser le champ vide (art. 13, paragraphe 4). Une décision de périmètre que vous ne pouvez pas expliquer n'est pas une décision de périmètre. C'est une déclaration d'applicabilité en tout sauf le nom, et c'est la même discipline que votre système de management applique déjà partout ailleurs.
Dans Acuna, l'applicabilité est marquée par exigence au sein d'un cadre cadré, et la justification est enregistrée contre l'exigence plutôt que tenue dans la tête de quelqu'un ou sur une diapositive d'atelier. Lorsque le RCR siège sur le même ensemble de contrôles que NIS2 et DORA, une décision de cadrage et son raisonnement ont un endroit où vivre et quelque chose contre quoi les revoir. Voir comment un programme RCR tourne aux côtés de NIS2 et DORA.
Références réglementaires