CONFORMITÉ ET DROIT · TRAITÉ
Les vulnérabilités dans les logiciels et les dispositifs en réseau ne sont pas depuis longtemps une simple question de service à la clientèle. La loi sur la cyberrésilience, règlement (UE) 2024/2847, réglemente les exigences en matière de cybersécurité pour certains produits comportant des éléments numériques. Les fabricants devraient envisager ensemble la mise au point de produits, la gestion de la vulnérabilité et la conception de contrats. Nous clarifions la portée juridique et l'appui dans l'attribution des tâches.
Quels sont les produits et les entreprises couverts?
Le point de départ est les produits à éléments numériques dont l'utilisation prévue ou raisonnablement prévisible comprend une connexion directe ou indirecte logique ou physique de données. En plus du matériel, les logiciels peuvent être affectés. Une solution de traitement à distance requise pour fonctionner peut faire partie du produit. D'autre part, un service cloud indépendant ne relève pas de l'ARC parce qu'il utilise des logiciels.
Les fabricants, les importateurs et les distributeurs ainsi que les rôles particuliers des logiciels libres et des logiciels libres sont examinés. Pour certains produits, il existe des exceptions sectorielles. La délimitation de l'exploitation d'une source ouverte non commerciale d'une disposition entrant dans le champ d'une activité commerciale nécessite également un examen concret. Le seul terme « Source ouverte » ne répond pas à la question.
Que considérer depuis septembre 2026
La plupart des exigences en matière de matériaux s'appliquent à partir du 11 décembre 2027C'est vrai. Toutefois, les exigences en matière de déclaration pour les fabricants visés à l'article 14 sont déjà applicables depuis la 11 septembre 2026C'est vrai. Cela concerne les vulnérabilités exploitées activement et les incidents graves de sécurité qui affectent la sûreté d'un produit capturé. Toutes les vulnérabilités trouvées ne déclenchent pas la même obligation de déclaration.
Pour ces notifications, des délais progressifs s'appliquent: en principe, un avertissement précoce dans les 24 heures et une nouvelle notification dans les 72 heures suivant l'obtention des connaissances. Les exigences relatives au rapport final sont différentes. Dans le cas d'une vulnérabilité exploitée activement, les rapports doivent être signalés au plus tard 14 jours après qu'une mesure corrective est disponible; dans le cas d'un incident grave, en principe, dans un délai d'un mois à compter de la notification de 72 heures. Les faits pertinents doivent donc être établis à un stade précoce.
La notification est effectuée par l'intermédiaire de la plate-forme européenne prévue à cet effet. D'autres obligations peuvent également exister, par exemple en vertu de la loi sur la protection des données ou du BSIG. Un plan d'alerte interne devrait distinguer et coordonner ces procédures. Les obligations particulières des responsables du logiciel libre ont leur propre date d'application; elles ne doivent pas être assimilées aux obligations du fabricant.
Préparation de nouvelles obligations en matière de produits
Un répertoire de produits est requis pour la mise en œuvre: famille de produits, fonctions, fourniture, utilisateurs visés, dépendances techniques et personnes responsables. L'évaluation des risques de cybersécurité, les exigences en matière de développement, la documentation technique et la procédure appropriée d'évaluation de la conformité s'y fondent. La classification des produits importants ou critiques influence le processus.
La période d ' appui et la mise à jour de la sécurité doivent être planifiées de manière durable sur les plans juridique et technique. Cela vaut également pour les composants achetés et la question de savoir comment les points faibles deviennent connus dans les dépendances. Une liste de pièces logicielles peut aider à cela, mais ne remplace pas le contrôle du rôle légal ou le traitement de messages de sécurité concrets.
Ce qui appartient aux traités
Les contrats avec les promoteurs et les fournisseurs devraient réglementer les exigences en matière de sécurité, l'information sur les composants, la mise à jour des obligations et la coopération en cas d'incidents. Il est nécessaire de déterminer qui prépare la notification et quelles informations doivent être fournies dans le délai interne. Les obligations des producteurs de droit public ne sont en aucune façon transférées au fournisseur de services par une clause contractuelle.
Les contrats avec les clients exigent également une comparaison avec la description du produit, les engagements de soutien et le concept de mise à jour. Les exclusions de responsabilité à taux forfaitaire ne résolvent pas une contradiction entre la vie utile promise et la sécurité réelle.
Surveillance juridique d'un projet de l'ARC
Nous pouvons prendre en charge la classification des différents produits, la répartition des droits dans une chaîne d'approvisionnement ou la révision des contrats de développement et de distribution. Un essai technique de sécurité ou une évaluation de conformité nécessaire est effectué par des organismes spécialisés compétents. La documentation relative aux produits, le modèle de vente, les éléments essentiels et les arrangements existants en matière d'appui devraient être compilés aux fins d'entrée. Contact avec l'entreprise.
Base juridique et décisions: Loi sur la cyberrésilience – règlement (UE) 2024/2847; Commission européenne: exigences de déclaration de l'ARC; Commission européenne: Calendrier de mise en œuvre.
Situation au 2 novembre 2026.
Pour en savoir plus: Sécurité des produits, marquage CE et rappels · Entreprises de logiciels · Protection des données et sécurité informatique
Quatre exemples pratiques
Les cas fictifs suivants illustrent des questions d'examen typiques. La solution concrète dépend des circonstances de l'affaire.
01 · Vulnérabilité active
Un fabricant apprend les attaques contre son produit. la portée, le moment des connaissances et l'obligation de rapport doivent être examinés sans délai; Les voies de recours et de communication continuent de fonctionner de manière coordonnée.
02 · Logiciels avec composants open source
Une application commerciale contient des bibliothèques étrangères. Les rôles, l'aperçu des composants et le processus de vulnérabilité sont vérifiés; l'étiquette open source ne libère pas l'ensemble du produit à un taux forfaitaire.
03 · Période de soutien non-suffisante
Les ventes et le développement appellent différentes périodes de maintenance. Les engagements, les exigences juridiques et la capacité technique de livraison seront coordonnés avant la conclusion du contrat.
04 · Produit ou service pur?
Un fournisseur offre une application avec le traitement à distance nécessaire. La délimitation du produit est vérifiée en utilisant les fonctions au lieu d'exclure automatiquement tout composant cloud.
Votre prochaine étape
Voulez-vous transférer les exigences à votre entreprise ou faire vérifier un processus spécifique? Une brève description et une référence aux délais existants sont suffisantes pour le premier contact. Nous voterons sur la portée de l'examen et de l'indemnisation avant la mise en service.
