Un règlement pour les fabricants, un effet pour tout le monde
Lu pour lui-même, le règlement sur la cyberrésilience ressemble au problème de quelqu'un d'autre. Le règlement (UE) 2024/2847 impose des obligations aux fabricants, importateurs et distributeurs de produits comportant des éléments numériques. Si votre organisation achète des pare-feu, déploie des appareils connectés, exécute des micrologiciels fournisseurs et intègre des logiciels tiers, vous n'êtes aucune de ces catégories. Aucune obligation RCR ne vous vise en tant qu'utilisateur.
Cette lecture est correcte, et elle n'est pas non plus le tableau complet, pour trois raisons.
La première : à partir du 11 décembre 2027, la conformité RCR devient une condition préalable stricte pour mettre un produit comportant des éléments numériques sur le marché de l'UE, via l'évaluation de la conformité et le marquage CE. Les produits qui ne peuvent pas la démontrer ne peuvent pas vous être vendus légalement. La viabilité du fournisseur est désormais une question de sécurité assortie d'une échéance juridique.
La deuxième : si vous êtes une entité essentielle ou importante au sens de NIS2, vous portez déjà des obligations de sécurité de la chaîne d'approvisionnement couvrant les aspects liés à la sécurité de vos relations avec les fournisseurs et prestataires de services directs (art. 21, paragraphe 2, point d)). La directive va plus loin qu'une exigence de politique : pour décider quelles mesures sont appropriées, vous devez tenir compte des vulnérabilités propres à chaque fournisseur direct et de la qualité globale de leurs produits et de leurs pratiques de cybersécurité, y compris leurs procédures de développement sécurisé (art. 21, paragraphe 3). Cette dernière clause est celle qui compte ici, parce que la posture RCR d'un fournisseur compte parmi les preuves les plus nettes de exactement ce qu'elle demande.
La troisième est la plus inconfortable. Beaucoup d'organisations qui se voient comme acheteuses sont fabricants au titre du RCR sans l'avoir remarqué. Voir à qui s'applique le règlement sur la cyberrésilience.
Trois façons dont l'exposition RCR atteint une organisation qui ne se voit pas comme fabricant
Vous mettez votre nom dessus. Le RCR place les obligations du fabricant sur l'entité qui met le produit sur le marché de l'UE sous son propre nom ou sa propre marque. Si vous achetez du matériel en marque blanche ou un composant OEM et que vous vendez ou fournissez le produit fini sous votre marque, vous êtes le fabricant aux fins du RCR, quel que soit celui qui a construit la technologie sous-jacente. La charge réglementaire suit la marque sur la boîte.
Vous intégrez les composants de quelqu'un d'autre. Les fabricants qui intègrent des composants provenant de tiers sont tenus d'exercer une diligence raisonnable pour que ces composants ne compromettent pas la cybersécurité du produit, et cette obligation s'étend explicitement aux composants libres et open source qui n'ont jamais été mis sur le marché à titre commercial (art. 13, paragraphe 5). Si vous construisez un produit comportant des éléments numériques, votre chaîne d'approvisionnement est à l'intérieur de votre propre obligation, pas à côté.
Vous achetez et déployez. Ici vous n'avez aucune obligation RCR. Vous avez une obligation NIS2, une obligation DORA si vous êtes une entité financière, et un intérêt commercial à ne pas acheter un produit qui devient invendable et non supporté en 2027. Cela suffit.
Une exception à connaître si vous êtes un organisme public. L'article 5, paragraphe 2, impose aux États membres de veiller à ce que, lorsque des produits entrant dans le champ d'application sont acquis, le respect des exigences essentielles de l'annexe I et la capacité du fabricant à gérer efficacement les vulnérabilités soient pris en considération dans le processus de passation. C'est une obligation pour les États membres plutôt que pour vous directement, mais si vous achetez sous les règles de la commande publique, elle atteindra vos critères d'appel d'offres. L'article 5, paragraphe 1, préserve aussi la liberté des États membres d'imposer des exigences de cybersécurité supplémentaires pour des finalités d'acquisition ou d'utilisation spécifiques, y compris la sécurité nationale et la défense.
Déterminez laquelle des trois décrit chaque ligne de produit avant d'écrire une seule question fournisseur, parce que la réponse change selon que vous exercez une obligation légale ou une préférence d'achat. Les deux sont légitimes. Ce n'est pas la même conversation.
Ce que vous pouvez légitimement demander aujourd'hui, et ce que vous ne pouvez pas
C'est là que la plupart des démarches RCR auprès des fournisseurs se trompent, et se trompent d'une façon qui endommage votre crédibilité auprès des éditeurs.
Vous ne pouvez pas demander aujourd'hui à un fournisseur une déclaration de conformité RCR ou un marquage CE au titre du RCR. Ces obligations s'appliquent à partir du 11 décembre 2027. Un fournisseur qui en produit une maintenant est soit confus, soit en train de vous dire quelque chose qui n'est pas vrai, et un questionnaire qui en exige une signale que vous n'avez pas lu le règlement.
Vous pouvez demander les deux choses qui sont déjà réelles. Les obligations de déclaration qui s'appliquent à partir du 11 septembre 2026, ce qui signifie que la capacité d'un fabricant à détecter et déclarer une vulnérabilité activement exploitée est une capacité au présent, pas un engagement futur. Et vous pouvez demander la préparation aux obligations de 2027, question légitime sur la trajectoire d'un fournisseur plutôt que sur son statut juridique actuel.
La distinction compte commercialement. Un jeu de questions qui sépare « ce qui est vrai aujourd'hui » de « quel est votre plan pour 2027 » obtient des réponses de fond. Un qui traite chaque obligation RCR comme déjà en vigueur obtient du texte défensif.
Le jeu de questions fournisseurs
Dix questions. Bornées à ce qui est répondable en août 2026, ordonnées pour que les premières réponses indiquent si les suivantes valent la peine d'être posées.
| # | Question | À quoi ressemble une réponse utile |
|---|---|---|
| 1 | Considérez-vous ce produit comme un produit comportant des éléments numériques entrant dans le champ du RCR, et sur quelle base ? | Un oui ou non motivé citant l'usage prévu et la connexion de données, pas une réponse d'un mot. Un fournisseur qui ne peut pas répondre n'a pas commencé. |
| 2 | Qui est le fabricant aux fins du RCR, et mettez-vous ce produit sur le marché de l'UE sous votre propre nom ou marque ? | La clarté sur le fait que votre contrepartie porte l'obligation ou la renvoie en amont. |
| 3 | Si vous êtes établi hors de l'UE, qui est votre mandataire ou opérateur économique responsable dans l'Union ? | Une entité juridique nommée avec un mandat écrit. |
| 4 | Quel est votre processus pour satisfaire aux obligations de déclaration de l'article 14 applicables à partir du 11 septembre 2026 ? | Un propriétaire nommé, un chemin d'escalade avec couverture hors horaires, et une décision de routage sur quel CSIRT national coordonne. |
| 5 | Nous notifierez-vous directement lorsque vous déclarez une vulnérabilité activement exploitée affectant un produit que nous exploitons, et selon quel délai ? | Le RCR route les déclarations vers les autorités, pas vers vous. La notification client est contractuelle et il faut la demander. |
| 6 | Maintenez-vous une liste des composants logiciels pour ce produit, dans quel format, et la partagerez-vous ? | Un format lisible par machine, tenu à jour à chaque version. « Sur demande, en PDF » est un non soft. |
| 7 | Quelle est la période de support déclarée pour ce produit, et que couvre-t-elle ? | Une durée énoncée avec un périmètre défini de mises à jour de sécurité gratuites. Au titre du RCR, la période de support reflète la durée d'utilisation attendue du produit, et est en général attendue d'être d'au moins cinq ans sauf si l'usage attendu est plus court (art. 13, paragraphe 8). |
| 8 | Quelle est votre classification de produit au titre du RCR, et quelle voie de conformité en découle ? | Par défaut, important classe I, important classe II ou critique, avec le raisonnement. Cela indique combien de travail le fournisseur a devant lui avant 2027. |
| 9 | Quel est votre plan et votre calendrier d'évaluation de la conformité avant le 11 décembre 2027 ? | Un plan daté. « Nous suivons les évolutions » en août 2026 est un signal de risque pour un produit que vous comptez encore faire tourner en 2028. |
| 10 | Quel est votre processus de divulgation coordonnée des vulnérabilités, et où envoyer un constat ? | Un contact publié et un engagement de réponse énoncé. |
Les questions 1 à 5 sont celles qui ont des réponses au présent. Si un fournisseur trébuche dessus, les questions 6 à 10 ne le sauveront pas.
Les clauses qu'il vaut la peine d'avoir maintenant
Le langage contractuel est le seul mécanisme qui convertit la posture réglementaire d'un fournisseur en quelque chose sur lequel vous pouvez vous appuyer. Le RCR ne vous donne pas de droits contre votre éditeur. Votre contrat le fait.
Notification client directe. L'article 14 route les déclarations vers l'ENISA et le CSIRT national coordinateur. Rien dans ce mécanisme ne vous dit, à vous opérateur du produit affecté, que cela s'est produit. Si vous voulez le savoir dans la même fenêtre de 24 à 72 heures à laquelle travaille votre fournisseur, écrivez-le dans le contrat avec un délai énoncé.
Livraison et actualité de la SBOM. Livraison à chaque version, dans un format lisible par machine, pas sur demande.
Engagement de période de support et préavis de fin de support. Une période de support déclarée avec un préavis minimum avant sa fin, pour qu'un produit qui cesse d'être supporté devienne un remplacement planifié plutôt qu'une découverte.
Engagement de mise à jour de sécurité. Mises à jour de sécurité gratuites pendant la durée de la période de support, avec une cible de remédiation énoncée pour les problèmes critiques.
Jalon de conformité. Pour les produits que vous comptez encore exploiter après le 11 décembre 2027, un engagement d'évaluation de la conformité avec une date, et un remède si elle est manquée.
Droit d'audit ou de preuve, proportionné. Le droit de voir la documentation technique ou un résumé, borné pour qu'il soit réellement négociable.
Trois de ces points méritent leur propre ligne dans un renouvellement même si vous laissez tomber tout le reste : notification directe, livraison de SBOM, et préavis de fin de support.
Lire les réponses
Les réponses sont plus informatives que les scores. Quelques schémas à reconnaître.
Un fournisseur qui répond à la question 1 par un non confiant et une base motivée est souvent en meilleure posture qu'un qui répond par un oui vague. L'analyse de périmètre est du travail, et ceux qui l'ont faite peuvent l'expliquer.
Un fournisseur qui nomme une personne pour la question 4 vous dit quelque chose de réel. Un fournisseur qui décrit un processus sans nommer personne a un document, pas une capacité, et l'horloge de 24 heures ne lit pas les documents.
Un fournisseur qui refuse de partager une SBOM pour des motifs de confidentialité avance un argument commercial défendable et un argument de sécurité faible. C'est une position de négociation, pas une impasse.
Un fournisseur dont le plan 2027 est une déclaration de suivi doit être présumé en queue de file pour la capacité des organismes notifiés si ses produits tombent dans les classes importantes ou critiques. C'est un risque d'approvisionnement, pas seulement de conformité.
Quand le fournisseur est hors périmètre
Beaucoup de vos éditeurs sont réellement hors du RCR et le diront correctement.
Le logiciel en tant que service autonome qui fonctionne indépendamment d'un produit physique est hors périmètre. Un service cloud n'est capturé que lorsqu'il qualifie de solution de traitement de données à distance, c'est-à-dire que 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é. Si le produit appelle un service cloud pour une fonctionnalité accessoire, le composant cloud n'est pas dans le périmètre. Si le produit ne peut pas fonctionner sans lui, il l'est.
Les produits déjà régis par des règles sectorielles, y compris les dispositifs médicaux, les véhicules à moteur et l'aviation civile, sont exclus. Les logiciels open source non commerciaux développés en dehors d'une activité commerciale se situent largement hors périmètre, bien que le RCR crée une catégorie distincte de gestionnaire de logiciels open source avec ses propres obligations allégées, et que les intégrateurs commerciaux qui embarquent ce code dans un produit restent pleinement responsables.
Une réponse hors périmètre n'est pas la fin de la conversation, elle ramène simplement la conversation à votre cadre existant. Votre obligation NIS2 de chaîne d'approvisionnement n'a pas d'exception RCR. Un éditeur SaaS hors du RCR est toujours à l'intérieur de votre programme de risque tiers.
Exécutez cela une fois, pas une fois par cadre
Le mode de défaillance est prévisible. Les questions fournisseurs RCR partent comme un nouveau questionnaire, d'un nouveau propriétaire, vers une liste de fournisseurs qui a déjà reçu un questionnaire de chaîne d'approvisionnement NIS2 il y a six mois et une demande de registre DORA avant cela. L'éditeur répond au troisième moins bien qu'au premier. Vos preuves vivent dans trois tableurs avec trois dates de rafraîchissement et aucune vue partagée de quel fournisseur échoue à quelle obligation.
Les questions RCR ci-dessus ne sont pas une évaluation séparée. Ce sont des dimensions supplémentaires sur un enregistrement fournisseur que vous tenez déjà. La question 7 est un champ de période de support. La question 6 est un document que vous détenez ou non. La question 4 est une attestation de capacité avec une date de revue.
Dans Acuna, c'est un exercice de risque tiers plutôt qu'un projet de conformité. Les questions s'exécutent comme une campagne d'évaluation contre les enregistrements fournisseurs que vous maintenez déjà, et les réponses s'attachent au fournisseur plutôt qu'à un tableur, au même endroit que les campagnes et la piste d'audit que vous menez déjà pour NIS2, DORA et ISO 27001. L'enregistrement fournisseur reste un enregistrement, quel que soit le régime qui a motivé la question.
C'est l'argument pour traiter le RCR comme un autre ensemble d'exigences sur un seul ensemble de contrôles. L'ennemi ici est le silo, pas le fournisseur.
Références réglementaires