Le CRA en pratique.
La sécurité après la livraison.

Le CRA, Règlement (UE) 2024/2847, fixe des exigences de cybersécurité pour les produits comportant des éléments numériques entrant dans son champ d’application. Il s’agit d’un règlement établi, et non d’une proposition de loi. Les obligations précises dépendent notamment du produit, de sa fonction, de sa mise sur le marché et de votre rôle dans la chaîne.

Tous les produits numériques ne sont pas soumis aux mêmes règles ; il existe des exceptions et d’autres régimes de produits. Évaluez donc séparément un routeur, un contrôleur embedded, un progiciel ou une application connectée. La Commission européenne fournit l’aperçu général.

11 septembre 2026

Les obligations de notification pour les fabricants s’appliquent aux vulnérabilités activement exploitées et aux incidents graves affectant la sécurité des produits. Tout problème logiciel détecté ne relève pas automatiquement de la même procédure de notification.

11 décembre 2027

Les principales obligations relatives aux produits deviennent applicables. Se limiter à cette date est insuffisant : les obligations de notification commencent plus tôt.

En cas d’incident, utilisez l’actuelle explication officielle sur les notifications CRA. Le rôle d’un fabricant est ici différent de celui d’une organisation sous NIS2.

Pour les produits concernés, il s’agit d’un processus cohérent : évaluer les risques, concevoir une sécurité appropriée, traiter les vulnérabilités et constituer la documentation. L’évaluation de la conformité et le marquage CE ne concernent pas exclusivement un petit groupe de produits à risque ; le parcours et l’éventuelle implication d’un tiers diffèrent selon la catégorie.

Pour une application industrielle, un dossier produit pratique commence par exemple par la fonction prévue, les interfaces, les dépendances et les conditions de support. Définissez quelles fonctions de sécurité sont intégrées au produit et quelles mesures sont attendues de l’intégrateur ou de l’utilisateur. Voir l’explication pour les fabricants.

Le CRA exige une période de support justifiée. Celle-ci est en principe de cinq ans minimum, à moins que la durée d’utilisation prévue ne soit plus courte. Une durée d’utilisation prévue plus longue peut nécessiter une période plus étendue. Cinq ans n’est donc pas un maximum général, ni une promesse pour chaque produit Remote. Les conditions concrètes du produit doivent être fixées.

Demandez également comment signaler les vulnérabilités, comment les mises à jour sont annoncées et comment identifier la version actuelle. Pour le gestionnaire de machines, les possibilités de test, les fenêtres de maintenance et la récupération après une mise à jour échouée sont des accords pratiques importants. Consultez le règlement pour les dispositions complètes.

• Quel produit et quelle version logicielle sont livrés, et qui agit en tant que fabricant ?
• Quelles fonctions, interfaces et composants logiciels externes font partie de la livraison ?
• Quelle documentation justifie les revendications de sécurité et l’éventuelle conformité ?
• Quels support, mises à jour et procédures de contact pour les vulnérabilités ont été convenus ?
• Qui teste une modification avant qu’elle ne soit utilisée dans un environnement de production ?

Ces questions de projet ne remplacent pas l’évaluation de conformité légale.

Remote combine des routeurs/contrôleurs, un portail web, une plateforme IIoT et une application. Pour les applications sur mesure, les couplages de protocoles et les logiciels embedded, nous mettons également la gestion et la maintenance sur la table. Discutez tôt de qui est responsable de quels composants du produit, de la documentation et des mises à jour.

L’IEC 62443 peut aider à traiter les exigences de sécurité de manière structurée. Une référence à cette norme ou un certificat ISO ne constitue pas en soi une déclaration de conformité au CRA.