Votre produit contient un logiciel et il est vendu dans l'UE ? Il relève alors vraisemblablement du Cyber Resilience Act (CRA), le règlement (UE) 2024/2847. Celui-ci exige des fabricants que les produits comportant des éléments numériques soient sûrs pendant tout leur cycle de vie. Et que cela puisse être prouvé. Nous examinons votre produit d'un point de vue technique, vous montrons où il en est et mettons en œuvre avec vous les mesures nécessaires.
Demander l'offre Réserver dans la boutique
Les échéances
- Depuis le 11 septembre 2026 : obligations de signalement des vulnérabilités activement exploitées et des incidents de sécurité graves. Elles s'appliquent aussi aux produits déjà sur le marché.
- À partir du 11 décembre 2027 : le règlement s'applique intégralement, y compris les exigences essentielles de cybersécurité, l'évaluation de la conformité et le marquage CE.
Les produits mis sur le marché avant le 11 décembre 2027 ne doivent satisfaire aux autres exigences que s'ils font ensuite l'objet d'une modification substantielle.
Votre produit est-il concerné par le CRA ?
Le CRA s'applique aux produits comportant des éléments numériques qui peuvent avoir une connexion de données avec un appareil ou un réseau. Il s'agit d'appareils dotés de leur propre logiciel, mais aussi de logiciels seuls que vous vendez. Donc également des programmes de bureau, des applications et des add-ins pour systèmes de CAO.
- Sont concernés par exemple les machines et appareils dotés d'un logiciel de commande, la technique de mesure et de laboratoire, les logiciels de bureau, les add-ins CAO, les firmwares et les applications.
- Sont exclus les produits soumis à des règles spécifiques, comme les dispositifs médicaux et les dispositifs de diagnostic in vitro, les véhicules à moteur et l'aéronautique. Les services purement cloud relèvent généralement de NIS2 plutôt que du CRA, tant qu'ils ne font pas partie d'un produit.
Dans quelle classe se situe votre produit ?
La plupart des produits sont des produits standard. Pour eux, vous évaluez vous-même la conformité. Des règles plus strictes s'appliquent aux produits importants des classes I et II, comme les systèmes d'exploitation, les gestionnaires de mots de passe, les routeurs ou les pare-feu, ainsi qu'aux produits critiques comme les cartes à puce. Selon la classe, il faut alors des normes harmonisées ou un organisme notifié.
Ce que le CRA exige des fabricants
- La sécurité dès le départ : aucune vulnérabilité exploitable connue à la livraison, une configuration par défaut sécurisée et une protection contre les accès non autorisés.
- Une évaluation des risques de cybersécurité, que vous tenez à jour.
- Une nomenclature logicielle (SBOM) comprenant au moins les dépendances directes.
- Une gestion organisée des vulnérabilités, y compris une adresse de contact pour les signalements.
- Des mises à jour de sécurité pendant la période d'assistance, en règle générale au moins cinq ans. Chaque mise à jour reste disponible au moins dix ans.
- Une documentation technique, la déclaration UE de conformité et le marquage CE.
- Des signalements via la plateforme de l'ENISA dans les 24 et 72 heures.
En cas de non-respect des exigences essentielles, les amendes peuvent atteindre 15 millions d'euros ou 2,5 % du chiffre d'affaires annuel mondial, le montant le plus élevé étant retenu.
Source : Règlement (UE) 2024/2847, art. 2, 7, 13, 14, 64, 69 et 71
Ce que nous examinons et mettons en œuvre pour vous
1. État des lieux
Quels produits et quelles versions sont concernés, quel logiciel contiennent-ils, quelles interfaces et connexions de données existent ? Nous déterminons sur le plan technique si votre produit entre dans le champ d'application et quelle classification est la plus probable. C'est de cela que dépend la possibilité d'évaluer vous-même la conformité ou la nécessité de faire appel à un organisme notifié.
2. Nomenclature logicielle (SBOM)
Le CRA exige que vous connaissiez et documentiez les composants de votre produit, au minimum les dépendances directes, dans un format courant lisible par machine. Nous recensons les bibliothèques, les composants open source et les modules achetés avec leurs versions, et configurons la SBOM au format CycloneDX ou SPDX de sorte qu'elle soit générée automatiquement à chaque build.
3. Gestion des vulnérabilités
Nous comparons vos composants avec les bases de données publiques de vulnérabilités, évaluons les résultats pour votre produit et proposons des corrections. Cela comprend une procédure pour traiter à l'avenir les vulnérabilités : une adresse de contact pour les signalements externes, une politique de divulgation coordonnée et des vérifications régulières.
4. Processus de mise à jour
Les mises à jour de sécurité doivent parvenir à vos clients rapidement, de manière sûre et, si possible, séparément des mises à jour fonctionnelles. Nous examinons comment les mises à jour sont aujourd'hui créées, signées et distribuées, et comment vous couvrez la période d'assistance. S'il manque une voie de mise à jour sûre, nous la mettons en place.
5. Sécurité du produit
Nous vérifions les exigences essentielles applicables au produit lui-même : configuration par défaut sécurisée, protection contre les accès non autorisés, chiffrement, surface d'attaque aussi réduite que possible et journalisation des événements pertinents pour la sécurité. Sur le plan méthodologique, nous nous appuyons pour cela sur notre contrôle qualité avec revue de code et contrôle de sécurité.
6. Documentation technique
Pour la déclaration de conformité, vous avez besoin d'une documentation technique : description du produit, architecture, évaluation des risques de cybersécurité, procédures de traitement des vulnérabilités et informations destinées aux utilisateurs. Nous examinons ce qui existe et rédigeons les parties techniques manquantes.
7. Obligations de signalement
Si une vulnérabilité de votre produit est activement exploitée, une alerte précoce doit être transmise dans les 24 heures et une notification plus détaillée dans les 72 heures, via la plateforme unique de signalement de l'ENISA. Nous définissons avec vous qui détecte, évalue et signale les indices, et préparons les informations techniques afin qu'aucun temps ne soit perdu en cas d'incident.
Logiciels anciens et CRA
Le CRA devient difficile surtout pour les logiciels développés au fil des années. Qui livre une mise à jour de sécurité pour une bibliothèque dont l'éditeur n'existe plus ? Comment créer une SBOM lorsque des composants ont été copiés à la main dans le projet ? Et comment une mise à jour signée parvient-elle au client lorsqu'il n'existe aucune voie de mise à jour ?
C'est là qu'intervient la modernisation de logiciels. Nous remplaçons les composants obsolètes, mettons en place une chaîne de build automatisée avec SBOM et construisons un mécanisme de mise à jour sûr. Pour Delphi, VB6, VBA ou MFC, nous combinons cela avec le portage. Important : une modification substantielle après le 11 décembre 2027 place votre produit entièrement sous le CRA. Planifiez donc modernisation et CRA ensemble.
Pour commencer : le Diagnostic CRA
Dans le Diagnostic CRA, nous classons un produit, créons une première nomenclature logicielle et comparons les composants avec les vulnérabilités connues. Vous savez ensuite où en est votre produit et ce qu'il reste à faire d'ici décembre 2027.
- Classification : votre produit relève-t-il du CRA, et quelle classe est la plus probable ?
- Première nomenclature logicielle (SBOM) au format CycloneDX ou SPDX
- Comparaison des composants avec les vulnérabilités connues
- Liste des écarts par exigence, avec plan d'action et estimation de l'effort
Vous recevez un rapport d'audit indiquant l'état de votre produit pour chaque exigence du CRA, la nomenclature logicielle et un plan d'action avec une offre à prix fixe. Le Diagnostic CRA coûte 2 990 € HT à prix fixe pour un produit. Si vous nous confiez ensuite la mise en œuvre, nous déduisons 50 % du prix de l'offre.
Demander l'offre Réserver dans la boutique
Ce que vous recevez
- Un rapport sur l'état de votre produit pour chaque domaine d'exigences, compréhensible également pour la direction et la gestion de produit
- Une liste des mesures, classées par ordre d'urgence et assorties d'une estimation de l'effort
- Sur demande, la mise en œuvre : SBOM dans le build, correction des vulnérabilités, mécanisme de mise à jour, documentation
- Si nécessaire, un accompagnement dans la durée, par exemple dans le cadre du support et de la maintenance
À qui s'adresse cette offre
Notre offre s'adresse aux fabricants de machines et d'appareils dotés de leur propre logiciel de commande, aux fournisseurs de technique de laboratoire et de mesure, ainsi qu'aux entreprises qui commercialisent des logiciels de bureau ou des add-ins CAO pour AutoCAD, BricsCAD ou Revit. Nous examinons aussi bien les logiciels que nous avons développés nous-mêmes que ceux d'autres éditeurs et le code existant développé au fil des années en C#/.NET ou en C++.
Remarque : nous nous chargeons de l'examen et de la mise en œuvre techniques, et non du conseil juridique. Nous coordonnons les questions juridiques, comme la classification contraignante de votre produit, avec votre service juridique ou vos avocats.
Plus d'expertise
- Cyber Resilience Act : ce que les éditeurs de logiciels doivent avoir fait d'ici fin 2027
- Créer une SBOM : la nomenclature logicielle pour le Cyber Resilience Act
- Moderniser un logiciel ancien : de Delphi, VB6 et MFC vers .NET, étape par étape
Questions fréquentes sur le Cyber Resilience Act
Le CRA s'applique-t-il aussi si nous ne vendons qu'en Allemagne ?
Oui. Le CRA s'applique à tous les produits mis à disposition sur le marché de l'UE, même si vous ne vendez que dans un seul pays.
Le CRA s'applique-t-il aussi aux logiciels que nous utilisons uniquement en interne ?
Un logiciel que vous utilisez uniquement en interne et que vous ne proposez pas n'est pas mis à disposition sur le marché. Il ne relève donc en règle générale pas du CRA.
Qu'en est-il des versions que nos clients possèdent déjà ?
Depuis le 11 septembre 2026, les obligations de signalement s'appliquent aussi aux produits déjà sur le marché. Les autres exigences s'appliquent aux produits que vous mettez sur le marché à partir du 11 décembre 2027 ou que vous modifiez substantiellement par la suite.
Avons-nous besoin d'un organisme notifié ?
Pas pour les produits standard. Vous évaluez vous-même la conformité. Pour les produits importants et critiques, un organisme notifié peut être nécessaire. Nous le clarifions lors de l'état des lieux.
Rédigez-vous aussi la déclaration de conformité ?
Nous rédigeons les parties techniques de la documentation. En tant que fabricant, c'est vous qui signez la déclaration UE de conformité.
Votre prochaine étape
Lors du premier entretien, nous déterminons quels produits pourraient être concernés et par quoi il est préférable de commencer. Vous trouverez plus d'informations sur nos prestations aux pages Modernisation de logiciels et Qualité et sécurité.
kununu