Cyber Resilience Act, ce qui change vraiment

Décryptage opérationnel du CRA: obligations, calendrier, impact sur les achats et la relation fournisseurs. La réglementation n’est pas une contrainte de plus. C’est un levier.

Trois épisodes en arrière, nous mettions les mains dans le concret. La supply chain logicielle (008), les usages non maîtrisés de l’IA (009), l’OT et l’IoT (010): autant de zones où la fragilité numérique prend racine, souvent en silence. À chaque fois, un constat revenait: l’absence de transparence du fournisseur, le manque de visibilité sur les composants, l’illusion d’une sécurité fondée sur la confiance plutôt que sur la preuve.

Ce n’est pas un hasard si l’Europe a légiféré. Le Règlement (UE) 2024/2847, plus connu sous le nom de Cyber Resilience Act (CRA), est entré en vigueur le 10 décembre 2024. Il transforme en obligations légales ce que les praticiens réclamaient depuis des années: sécurité dès la conception, support dans la durée, transparence sur les composants.

Dans l’épisode 005, nous posions le principe: « Le CRA et NIS2 sont vos alliés. Utilisez ces textes pour exiger légitimement de vos fournisseurs la transparence et la maintenabilité. » Cette semaine, on passe de l’intention à l’opérationnel.

La vraie question n’est pas « faut-il se conformer ». C’est: comment utiliser cette réglementation pour renforcer structurellement la résilience de son écosystème numérique?

1. Ce que le CRA impose — en clair

Le CRA s’applique à tout « produit comportant des éléments numériques » mis sur le marché européen. Matériel connecté, logiciel embarqué, application, composant: le périmètre est volontairement large. Les obligations portent sur trois axes.

• Sécurité dès la conception (security by design): le fabricant doit prouver que son produit a été conçu, développé et produit conformément aux exigences essentielles de cybersécurité définies à l’Annexe I du règlement.

• Gestion des vulnérabilités dans la durée: le fabricant doit définir une période de support (en principe au moins cinq ans), fournir les correctifs de sécurité gratuitement, et séparer les mises à jour de sécurité des mises à jour fonctionnelles.

• Transparence et documentation: un SBOM (Software Bill of Materials), une documentation technique complète, une déclaration de conformité CE et des informations claires pour l’utilisateur sont exigés.

Les obligations ne visent pas seulement les fabricants. Importateurs et distributeurs doivent vérifier que le fabricant a bien rempli ses obligations avant de rendre un produit disponible sur le marché européen.

Le CRA ne crée pas une norme technique de plus. Il transforme la sécurité des produits numériques en condition d’accès au marché.

2. Le calendrier que beaucoup sous-estiment

L’application complète du CRA est fixée au 11 décembre 2027. Mais deux jalons antérieurs changent la donne.

• 11 juin 2026: le cadre de notification des organismes d’évaluation de conformité (CAB) s’applique. Les États membres doivent avoir désigné leurs autorités notifiantes.

• 11 septembre 2026: les obligations de signalement des vulnérabilités activement exploitées et des incidents graves entrent en vigueur. C’est la première échéance opérationnelle réelle.

• 11 décembre 2027: application complète. Tout produit nouvellement mis sur le marché doit être conforme.

Le point que beaucoup d’organisations n’ont pas saisi: les obligations de signalement de septembre 2026 s’appliquent aussi aux produits déjà sur le marché, y compris les produits legacy. Ce n’est pas une disposition prospective. C’est une obligation rétroactive sur le parc existant.

Conséquence immédiate: pour signaler une vulnérabilité dans les 24 heures, il faut d’abord savoir quels composants sont présents dans ses produits. Sans SBOM et sans surveillance automatisée des vulnérabilités, cette obligation est matériellement intenable. Le SBOM devient donc une nécessité opérationnelle dès septembre 2026, bien avant son exigence formelle de décembre 2027.

Septembre 2026, c’est dans six mois. Ceux qui pensent avoir jusqu’en 2027 se préparent une mauvaise surprise.

3. Le SBOM: ingrédient obligatoire, pas option

Le SBOM est à un produit numérique ce que la liste d’ingrédients est à un produit alimentaire. Il décrit en détail les bibliothèques, frameworks, dépendances et composants tiers utilisés, avec leurs versions exactes.

L’Annexe I du CRA l’exige explicitement: le fabricant doit « identifier et documenter les vulnérabilités et les composants contenus dans les produits, notamment en établissant un SBOM dans un format lisible par machine couramment utilisé ».

En pratique, le SBOM ne doit pas être publié. Mais il doit exister, être maintenu à jour, et permettre une réaction rapide en cas de découverte d’une vulnérabilité dans un composant tiers. C’est exactement le scénario Log4Shell évoqué dans l’épisode 008: des milliers d’organisations incapables de déterminer en quelques heures si elles étaient concernées, faute d’inventaire.

Pour les acheteurs, la conséquence est directe. Exiger un SBOM de ses fournisseurs n’est plus une posture de perfectionniste. C’est une exigence réglementaire que le fabricant doit satisfaire pour vendre en Europe.

Si votre fournisseur ne peut pas produire un SBOM aujourd’hui, il ne sera pas en mesure de se conformer au CRA demain. C’est un signal d’alerte, pas un détail.

4. Ce que le CRA change dans la relation fournisseur

C’est peut-être l’impact le plus structurant du CRA: il redéfinit les règles du jeu entre acheteurs et fournisseurs de produits numériques. Jusqu’ici, la sécurité d’un produit reposait largement sur la bonne foi du fabricant et sur la vigilance — souvent insuffisante — de l’acheteur.

Désormais, la donne change sur plusieurs plans.

• Le fournisseur doit documenter et démontrer. La conformité CE atteste que le produit respecte les exigences du CRA. L’acheteur est en droit d’exiger la documentation technique associée.

• L’importateur et le distributeur deviennent co-responsables. Ils doivent vérifier que la conformité est en place avant de mettre le produit à disposition sur le marché européen. Ce n’est plus seulement l’affaire du fabricant.

• La durée de support devient un critère d’achat. Le fabricant doit déclarer publiquement la période pendant laquelle il fournira des correctifs. C’est un engagement vérifiable et opposable.

• Les correctifs de sécurité deviennent un droit. Gratuits, séparés des mises à jour fonctionnelles, délivrés sans délai injustifié.

Ce cadre offre aux acheteurs un levier de négociation légitime. Ce que l’épisode 005 formulait en termes de bonnes pratiques (« C’est à l’achat que se joue la sécurité de demain ») devient une réalité juridique.

Le CRA transforme le rapport de force. Le fournisseur qui refuse la transparence ne refuse pas une faveur: il refuse de se conformer au droit européen.

5. Classification des produits: comprendre les niveaux d’exigence

Le CRA n’impose pas le même niveau de contrôle à tous les produits. Il distingue trois catégories, avec des procédures de conformité progressives.

Catégorie Exemples Conformité —————- — ——————————————— Par défaut Enceintes connectées, jouets, applis grand public Auto-évaluation par le fabricant Important Pare-feux, routeurs, OS, gestionnaires de mots de passe Standard harmonisé ou audit tiers Critique Contrôleurs industriels, HSM, compteurs intelligents Audit obligatoire par organisme tiers (CAB)

Pour environ 90% des produits concernés, une auto-évaluation du fabricant suffit. Mais pour les produits « importants » et « critiques » — pare-feux, routeurs, systèmes d’exploitation, composants industriels — un audit par un organisme tiers est obligatoire.

La Commission européenne a publié en novembre 2025 un acte d’exécution précisant les descriptions techniques de chaque catégorie. C’est ce document qui permet aux fabricants de déterminer dans quelle classe tombe leur produit.

Ne pas connaître la classification de ses produits, c’est ne pas savoir quel niveau de conformité appliquer. C’est le premier risque.

6. Sanctions: le prix de l’inaction

Le CRA n’est pas un texte de recommandation. Il prévoit un régime de sanctions significatif, encadré par des plafonds européens.

• Jusqu’à 15 millions d’euros ou 2,5% du chiffre d’affaires mondial pour le non-respect des exigences essentielles de cybersécurité.

• Jusqu’à 10 millions d’euros ou 2% du CA pour les manquements de documentation, de représentation ou de marquage CE.

• Jusqu’à 5 millions d’euros ou 1% du CA pour la fourniture d’informations incorrectes ou trompeuses aux régulateurs.

Au-delà des amendes, les autorités de surveillance du marché peuvent ordonner le retrait ou le rappel de produits non conformes. Un scénario qui n’a rien de théorique pour un fabricant dont la réputation repose sur sa présence sur le marché européen.

Point notable: les micro-entreprises et petites entreprises bénéficient d’une tolérance sur le délai de signalement de 24 heures. Mais cette tolérance ne les exempte pas des obligations de fond.

Les montants sont comparables à ceux du RGPD. Le message est clair: la cybersécurité des produits n’est plus optionnelle.

7. Grille d’évaluation fournisseurs: intégrer le CRA dans vos achats

La théorie est posée. Reste la question pratique: comment intégrer ces exigences dans le processus d’achat et de gestion des fournisseurs? La grille ci-dessous propose une lecture directement actionnable.

Critère Question à poser au fournisseur Référence CRA ——————————– — ———————– SBOM Pouvez-vous fournir un SBOM lisible par machine pour ce produit? Annexe I, Partie II Durée de support Quelle est la durée de support déclarée? Est-elle ≥ 5 ans? Art. 13(8) Correctifs de sécurité Les patchs de sécurité sont-ils gratuits et séparés des mises à jour fonctionnelles? Annexe I, Partie I Signalement vulnérabilités Avez-vous un processus de signalement conforme (24h/72h)? Art. 14 Conformité CE Le produit dispose-t-il d’une déclaration de conformité CRA? Art. 28 Documentation technique La documentation technique est-elle disponible et à jour? Annexe VII

Cette grille n’est pas un questionnaire de conformité générique. C’est un outil de dialogue avec le fournisseur. Un fournisseur qui répond positivement à ces critères démontre une maturité compatible avec les exigences du CRA. Celui qui ne le peut pas expose son client à un risque réglementaire et opérationnel qu’il faut assumer en conscience, comme nous le posions dès l’épisode 005 avec les mesures compensatoires.

Intégrer le CRA dans les achats, ce n’est pas ajouter une ligne au cahier des charges. C’est changer la manière d’évaluer ce qu’on achète.

8. CRA, NIS2, DORA: articuler les textes sans se noyer

Le CRA ne vit pas seul. Il s’inscrit dans un écosystème réglementaire européen de plus en plus dense. Pour les organisations concernées, la question n’est plus de connaître chaque texte isolément. C’est de comprendre comment ils s’articulent.

• NIS2 impose aux entités essentielles et importantes une gestion des risques documentée, testée, auditée. Elle couvre la gouvernance, la notification d’incidents et la responsabilité de la direction.

• DORA cible spécifiquement la résilience numérique du secteur financier, y compris la gestion des prestataires IT critiques.

• Le CRA complète le dispositif en amont: il agit au niveau du produit, avant même son déploiement dans l’organisation.

La logique est cohérente: NIS2 et DORA cadrent la résilience de l’organisation. Le CRA cadre la résilience de ce que l’organisation achète. Les trois textes se renforcent mutuellement.

En pratique, cela signifie qu’une organisation soumise à NIS2 qui sélectionne des produits conformes au CRA répond d’emblée à une partie de ses obligations de gestion des risques liés aux fournisseurs. C’est un cercle vertueux, à condition de le piloter consciemment.

Les textes s’empilent. Mais pour qui les lit avec méthode, ils convergent. La conformité au CRA n’est pas un silo de plus: c’est une brique de la conformité globale.

L’Essentiel pour Agir

1. Anticipez septembre 2026, pas décembre 2027:

Identifiez dès maintenant les produits en périmètre CRA dans votre parc. Mettez en place la capacité de signalement (processus, contacts CSIRT, workflows internes). Exigez de vos fournisseurs qu’ils démontrent leur préparation au signalement de vulnérabilités.

2. Intégrez les exigences CRA dans vos processus d’achat:

Ajoutez les critères de la grille (SBOM, durée de support, séparation des correctifs, conformité CE) à vos cahiers des charges et à vos grilles d’évaluation fournisseurs. Ce n’est plus de la rigueur excessive. C’est de la conformité.

3. Utilisez le CRA comme levier de dialogue, pas comme outil coercitif:

La réglementation est un terrain commun de discussion avec les fournisseurs. Elle légitime des exigences qui étaient perçues comme excessives. Posez les questions de la grille dans vos comités de pilotage, pas seulement dans les appels d’offres.

Conclusion

Le Cyber Resilience Act ne révolutionne pas la cybersécurité. Il met en droit ce que les praticiens savent depuis longtemps: un produit numérique qui n’est ni maintenu, ni documenté, ni transparent est une dette de sécurité. Le CRA transforme cette dette en risque juridique et financier.

Pour les organisations qui avaient déjà intégré la logique du « Shift Left » et du « Compliance as Code » posée dans l’épisode 005, le CRA est un accélérateur. Pour les autres, c’est un signal d’alarme. Septembre 2026 n’est pas une date lointaine.

Mais la réglementation, aussi bien conçue soit-elle, ne produit ses effets que si les équipes qui la déploient la comprennent, l’approprient, et la traduisent en pratiques concrètes. La prochaine chronique s’intéressera précisément à cet angle souvent négligé: ce que le facteur humain change dans l’équation de la résilience.

La résilience ne consiste pas à subir la réglementation. Elle consiste à s’en servir pour bâtir ce qu’on aurait dû construire depuis le début.

Bibliographie

« Règlement (UE) 2024/2847 — Cyber Resilience Act — Texte officiel »

https://eur-lex.europa.eu/eli/reg/2024/2847/oj

Le texte intégral du règlement européen, publié au Journal officiel le 20 novembre 2024. Source primaire incontournable pour vérifier les obligations, les définitions et le calendrier d’application.

« European Commission — Cyber Resilience Act: Implementation »

https://digital-strategy.ec.europa.eu/en/factpages/cyber-resilience-act-implementation

Page officielle de la Commission européenne regroupant le calendrier de mise en œuvre, les actes délégués et d’exécution, et les guides d’accompagnement pour les entreprises.

« ENISA — Single Reporting Platform (SRP) »

https://www.enisa.europa.eu/topics/product-security-and-certification/single-reporting-platform-srp

FAQ et informations opérationnelles sur la plateforme unique de signalement des vulnérabilités et incidents, opérationnelle dès le 11 septembre 2026. Essentiel pour comprendre les obligations de l’Article 14.

« European Commission — CRA Reporting Obligations »

https://digital-strategy.ec.europa.eu/en/policies/cra-reporting

Page dédiée de la Commission détaillant les obligations de signalement: délais (24h, 72h, 14 jours), processus, rôle des CSIRT et interaction avec la plateforme ENISA.

« ANSSI — La Directive NIS 2 »

https://cyber.gouv.fr/la-directive-nis-2

Le portail de référence de l’ANSSI sur NIS2, indispensable pour comprendre l’articulation entre les obligations de gouvernance NIS2 et les exigences produit du CRA.