20 questions sur le Cyber Resilience Act — réponses claires

Votre produit est concerné s'il comporte des éléments numériques — du code logiciel, embarqué ou téléchargeable — et s'il peut se connecter directement ou indirectement à un autre appareil ou à un réseau.

Concrètement : routeurs, caméras connectées, logiciels industriels, applications embarquées, équipements médicaux connectés, passerelles IoT, systèmes de contrôle industriel. La liste est large et intentionnellement large.

Le CRA classe les produits en trois catégories selon leur niveau de risque :

• Classe par défaut — la grande majorité des produits. Autocertification possible par le fabricant.
• Classe I — produits à risque élevé : navigateurs, gestionnaires de mots de passe, VPN, produits industriels de supervision. Audit par un organisme notifié requis.
• Classe II — produits critiques : hyperviseurs, pare-feux industriels, PKI, microprocesseurs. Exigences et contrôles renforcés.

Le CRA cible les produits mis sur le marché. Les services cloud purs (SaaS sans composant installé chez le client) ne sont pas directement couverts par le CRA, mais par NIS 2.

En revanche, si votre SaaS inclut un composant logiciel installé sur un appareil client (agent, connecteur, SDK intégré), ce composant entre dans le champ du CRA.

Oui. Le CRA impose des obligations spécifiques aux importateurs et distributeurs, différentes de celles des fabricants mais réelles.

• Importateurs : vérifier que le fabricant a effectué les procédures d'évaluation de conformité, que la documentation est disponible et que le marquage CE est apposé.
• Distributeurs : vérifier le marquage CE et la présence de la documentation de conformité avant mise sur le marché.

Si vous modifiez substantiellement un produit, vous êtes considéré comme fabricant et assumez toutes les obligations correspondantes.

Oui. Le CRA (article 13) impose aux fabricants de maintenir un inventaire de leurs composants logiciels. En pratique, cela correspond à ce qu'on appelle un SBOM (Software Bill of Materials).

Le CRA ne prescrit pas de format spécifique, mais les formats CycloneDX (recommandé par la Commission européenne) et SPDX (ISO 5962:2021) sont les standards de facto.

Le CRA impose une durée de support proportionnelle à la durée d'utilisation attendue du produit. Il n'y a pas de durée minimale fixe dans le texte — c'est une appréciation au cas par cas selon le secteur et le cycle de vie.

L'obligation principale : communiquer cette durée à l'acheteur avant la vente, et à l'échéance, informer les utilisateurs en avance suffisante pour qu'ils puissent migrer.

Vous devez informer vos utilisateurs des vulnérabilités qui les concernent et des correctifs disponibles. Le standard VEX (Vulnerability Exploitability eXchange) permet de communiquer si une CVE est exploitable dans votre produit — sans divulguer votre architecture interne.

Le VEX peut indiquer quatre statuts : non affecté, affecté, corrigé, en cours d'investigation. C'est le moyen standard de répondre aux questions de vos clients sur l'impact d'une CVE publiée.

Le CRA impose de constituer et maintenir une documentation technique complète pour chaque produit :

• Analyse de risque de cybersécurité
• SBOM à jour
• Description de l'architecture et de la conception sécurisée
• Résultats des tests de sécurité
• Déclaration de conformité UE
• Politique de gestion des vulnérabilités

Cette documentation doit être conservée pendant 10 ans après la mise sur le marché et mise à disposition des autorités sur demande.

Oui. Le CRA tient le fabricant responsable de la sécurité de son produit dans son intégralité — y compris les composants tiers et open source qu'il intègre. C'est le principe de la responsabilité sur la chaîne d'approvisionnement logicielle.

Vous devez auditer vos dépendances, surveiller les CVE qui les affectent, et corriger ou compenser les vulnérabilités identifiées — même si la faille provient d'une bibliothèque externe que vous n'avez pas développée.

• Décembre 2024 — Entrée en vigueur du CRA. Le compte à rebours commence.
• Septembre 2026 — Première échéance concrète : obligations de notification d'incidents à l'ENISA applicables.
• Décembre 2027 — Application complète. Tous les produits mis sur le marché doivent être conformes.

Les produits déjà sur le marché avant décembre 2027 bénéficient d'une période de transition — à condition qu'ils ne subissent pas de modification substantielle avant cette date.

Mais dès septembre 2026, les obligations de notification d'incidents s'appliquent à tous les produits, y compris ceux déjà sur le marché. La période de transition ne couvre pas les obligations de notification.

Entre 12 et 24 mois selon la maturité de départ, le nombre de produits concernés et la taille des équipes disponibles. Les organisations partant de zéro avec plusieurs produits complexes ont besoin du délai maximal.

Les étapes les plus longues : produire un SBOM complet (surtout pour les produits legacy), mettre en place un processus PSIRT opérationnel, et former les équipes R&D au Security by Design.

Il existe deux approches : manuelle (inventaire à la main, long et sujet aux erreurs) et automatisée (génération depuis le pipeline CI/CD, recommandée).

Les outils open source comme Syft, CycloneDX CLI ou SPDX tools permettent de générer automatiquement un SBOM à partir du code source ou d'une image conteneur.

La surveillance manuelle est insuffisante pour respecter les délais de 24h imposés par le CRA. Il faut une corrélation automatisée entre votre SBOM et les bases de vulnérabilités.

Le flux standard : SBOM → corrélation CVE (NVD, OSV, VulnDB) → alerte si composant affecté → évaluation CVSS → décision correctif ou VEX.

VAST automatise cette corrélation — alerte dès qu'une nouvelle CVE affecte un de vos composants, avec génération automatique de VEX et traçabilité complète.

Un PSIRT n'est pas forcément une équipe dédiée — pour les PME, c'est souvent un processus documenté avec des rôles assignés à des personnes existantes. L'essentiel : une adresse de signalement publique, un processus d'évaluation de criticité, des délais de traitement définis, et une procédure de notification.

• Désigner un responsable de réception des signalements
• Définir des SLA internes : 24h pour l'évaluation initiale, X jours pour le correctif selon criticité
• Documenter le processus et le tester au moins une fois par an

Non. ISO 27001 et SOC 2 couvrent la sécurité de votre organisation et de vos systèmes d'information — pas la sécurité de vos produits mis sur le marché. Ce sont des référentiels complémentaires, pas substituables.

Le CRA porte spécifiquement sur les produits que vous vendez. Une organisation certifiée ISO 27001 doit quand même mettre en place un SBOM, un processus de gestion des CVE produit et une déclaration de conformité.

Le CRA prévoit trois niveaux d'amendes selon la gravité :

• 15 M€ ou 2,5 % du CA mondial — violations des exigences essentielles de sécurité
• 10 M€ ou 2 % du CA mondial — autres violations des obligations du fabricant
• 5 M€ ou 1 % du CA mondial — fourniture d'informations incorrectes aux autorités

En plus des amendes : retrait du produit du marché européen ou interdiction de commercialisation jusqu'à mise en conformité.

Chaque État membre désigne une ou plusieurs autorités de surveillance de marché. En France, l'ANSSI est pressentie comme autorité principale, en coordination avec d'autres organismes selon les secteurs.

Au niveau européen, l'ENISA coordonne la coopération entre autorités nationales et reçoit les notifications d'incidents.

Le CRA prévoit quelques mesures de soutien pour les PME — accès facilité aux ressources d'accompagnement et aux bacs à sable réglementaires — mais pas d'exemption sur les obligations fondamentales.

Une PME qui fabrique un produit connecté a les mêmes obligations qu'une grande entreprise sur les exigences essentielles : SBOM, gestion des CVE, notification d'incidents. Les délais et le niveau d'exigence de documentation peuvent être proportionnés à la taille, mais les obligations de base s'appliquent.