Le Cyber Resilience Act (CRA, Règlement (UE) 2024/2847) est entré en vigueur le 10 décembre 2024 et deviendra pleinement applicable le 11 décembre 2027. Il impose aux fabricants de produits à éléments numériques (PEN) — matériels ET logiciels — des obligations cybersécurité renforcées assorties de sanctions pouvant atteindre 15 M€ ou 2,5 % du CA mondial. Pour toute organisation qui achète, intègre ou revend ces produits, cela signifie : vos contrats fournisseurs doivent être renégociés pour transférer et documenter ces nouvelles obligations.
Cet article détaille les 8 clauses à intégrer systématiquement dès 2026, avec exemples de rédaction et mise en perspective vis-à-vis de NIS2 et DORA.
Périmètre : quels produits et quels fournisseurs sont concernés ?
Le CRA s'applique aux produits à éléments numériques (PEN) mis sur le marché européen. Cela couvre :
- Matériel : capteurs IoT, routeurs, caméras de surveillance, appareils médicaux connectés, équipements industriels intelligents
- Logiciels : applications SaaS commerciales, bibliothèques open-source distribuées à titre commercial, firmwares, systèmes d'exploitation, composants embarqués
- Produits hybrides : systèmes mêlant hardware + logiciel (véhicules connectés, appareils domotiques, ascenseurs connectés)
Le CRA distingue trois catégories :
| Catégorie | Exemples | Voie d'évaluation |
|---|---|---|
| Non critique (90 %) | Applications grand public, jouets connectés | Auto-évaluation par le fabricant |
| Important (classe I) | VPN, gestionnaires de mots de passe, navigateurs | Auto-évaluation + normes harmonisées |
| Important (classe II) | Systèmes d'exploitation, firewalls, hyperviseurs | Organisme notifié obligatoire |
| Critique | HSM, smart meters sécurisés, routeurs industriels | Certification européenne obligatoire (schéma EUCC) |
Pour approfondir les frameworks cyber applicables, consultez nos guides NIS2 entités essentielles vs importantes et DORA 2026.
Les 8 clauses contractuelles obligatoires
Clause 1 — Périmètre PEN et catégorie de classification
Objectif : le fournisseur déclare explicitement si son produit entre dans le périmètre CRA et à quelle catégorie il appartient.
Rédaction type :
« Le Fournisseur reconnaît que le Produit livré est un « produit à éléments numériques » au sens du Règlement (UE) 2024/2847 et le classifie comme [non critique / important classe I / important classe II / critique]. Toute reclassification ultérieure par la Commission européenne sera notifiée au Client sous 30 jours et donnera lieu à renégociation des présentes clauses. »
Pourquoi c'est critique : la catégorie détermine la voie d'évaluation de conformité et les niveaux de responsabilité. Sans déclaration explicite, le Client ne sait pas quelles preuves demander en cas d'audit.
Clause 2 — Obligations « secure-by-design » et « secure-by-default »
Objectif : engager le fournisseur à respecter les exigences essentielles cybersécurité de l'Annexe I du CRA dès la conception.
Rédaction type :
« Le Fournisseur garantit que le Produit est conçu, développé et produit conformément aux exigences essentielles de cybersécurité de l'Annexe I du Règlement (UE) 2024/2847, incluant notamment : protection contre les accès non autorisés, protection de la confidentialité et de l'intégrité des données traitées, disponibilité des fonctions essentielles, minimisation des surfaces d'attaque, absence de vulnérabilités exploitables connues à la livraison. »
Mise en relation NIS2 : cette exigence alimente la mesure NIS2 « sécurité dans l'acquisition et la maintenance des systèmes d'information » (Art. 21.2.e).
Clause 3 — Marquage CE et Déclaration de Conformité
Objectif : obtenir la documentation de conformité formelle pour pouvoir démontrer la conformité en cascade.
Rédaction type :
« Le Fournisseur fournit, au plus tard à la livraison du Produit : (i) une Déclaration UE de Conformité conforme à l'Annexe V du Règlement ; (ii) la documentation technique de l'Annexe VII sur demande ; (iii) la preuve du marquage CE visible sur le Produit ou son emballage. » Toute modification substantielle du Produit rendant la Déclaration obsolète déclenche une nouvelle évaluation de conformité à la charge du Fournisseur. »
Valeur auditable : en cas de contrôle par une autorité de surveillance du marché, la fourniture rapide de ces documents par vos fournisseurs détermine votre capacité à prouver votre propre diligence.
Clause 4 — Gestion des vulnérabilités et SBOM
Objectif : accès permanent au Software Bill of Materials (SBOM) et processus de divulgation coordonnée.
Rédaction type :
« Le Fournisseur maintient et fournit au Client : (i) un SBOM (Software Bill of Materials) au format CycloneDX ou SPDX, mis à jour à chaque version du Produit, couvrant l'ensemble des composants logiciels y compris open-source ; (ii) une politique de divulgation coordonnée des vulnérabilités (CVD) publiée et incluant un point de contact sécurité (security.txt) ; (iii) un engagement de publication de correctifs pour toute vulnérabilité critique (CVSS ≥ 7.0) sous 30 jours après découverte ; (iv) un système de notification proactif des nouvelles vulnérabilités affectant les composants du SBOM. »
Outillage ResiPlan : notre module d'analyse de contrat IA détecte automatiquement si ces clauses SBOM sont présentes dans le contrat soumis.
Clause 5 — Période de support sécurité
Objectif : imposer la durée minimale de support sécurité, plancher critique du CRA.
Rédaction type :
« Le Fournisseur s'engage à fournir des mises à jour de sécurité gratuites et des correctifs de vulnérabilités pendant au minimum la plus longue des périodes suivantes : (i) cinq (5) ans à compter de la mise sur le marché du Produit ; (ii) la durée de vie attendue du Produit telle que publiée dans la documentation ; (iii) quinze (15) ans si le Produit est classifié « important classe II » ou « critique ». Toute interruption anticipée du support engage la responsabilité du Fournisseur au titre du manquement aux exigences essentielles CRA. »
Piège classique : les fournisseurs SaaS ont tendance à lier la durée de support à la période d'abonnement actif. Le CRA exige un support pour les vulnérabilités exploitables même après expiration contractuelle, dans la limite de la période légale.
Clause 6 — Notification des incidents et vulnérabilités exploitées à l'ENISA
Objectif : cascade de l'obligation de notification ENISA vers le fournisseur.
Rédaction type :
« Le Fournisseur notifie au Client, simultanément à la notification à l'ENISA, tout incident significatif ou toute vulnérabilité activement exploitée affectant le Produit, dans les délais suivants : (i) alerte précoce sous 24 heures après prise de connaissance ; (ii) notification de l'incident sous 72 heures ; (iii) rapport final sous 14 jours après la fin de l'incident. Chaque notification inclut : description technique, CVE/CVSS applicables, vecteurs d'exploitation observés, mesures de remédiation disponibles. »
Alignement NIS2 : ces délais CRA sont calqués sur les délais NIS2 (voir notre guide notification d'incident NIS2). Intégrer la même rédaction dans les deux régimes facilite l'opérationnel.
Clause 7 — Droit d'audit et de preuve de conformité
Objectif : pouvoir vérifier et auditer la conformité CRA du fournisseur.
Rédaction type :
« Le Client, directement ou via un auditeur tiers mandaté, dispose du droit : (i) d'auditer annuellement le respect des obligations CRA du Fournisseur avec un préavis de 30 jours ; (ii) de demander la documentation technique CRA (Annexe VII) dans un délai de 15 jours ouvrés ; (iii) d'exiger les rapports d'évaluation d'organisme notifié le cas échéant ; (iv) de faire auditer les sous-traitants critiques du Fournisseur, dans les mêmes conditions. Les coûts d'audit restent à la charge du Client sauf découverte d'une non-conformité substantielle, auquel cas ils sont refacturés au Fournisseur. »
Clause 8 — Responsabilité et indemnisation CRA
Objectif : transférer au fournisseur les sanctions encourues du fait de sa non-conformité.
Rédaction type :
« Le Fournisseur indemnise intégralement le Client de tout dommage, amende administrative, coût de remédiation ou perte d'exploitation résultant : (i) d'une non-conformité du Produit aux exigences du Règlement (UE) 2024/2847 ; (ii) d'une absence, d'un retard ou d'une insuffisance de mise à jour de sécurité ; (iii) d'une notification tardive ou incomplète d'incident ou de vulnérabilité. Cette indemnisation n'est pas plafonnée par les clauses générales de limitation de responsabilité du présent contrat. »
Pourquoi cette clause importe : les amendes CRA (jusqu'à 15 M€ ou 2,5 % CA mondial) sont supérieures aux plafonds de responsabilité contractuelle standard. Sans clause spécifique, le risque reste sur le client-intégrateur.
Articulation avec NIS2 et DORA : éviter les clauses redondantes
Beaucoup de ces clauses se recoupent avec NIS2 (supply chain, Art. 21.2.d) et DORA (tiers TIC, Art. 28-30). Notre recommandation :
| Type de contrat | Clauses prioritaires |
|---|---|
| Fournisseur hardware IoT | CRA 1-8 + ISO 22301 RTO/RPO |
| Fournisseur SaaS critique (entité NIS2) | NIS2 complet + CRA 4-6 (SBOM, support, notification) |
| Fournisseur TIC critique (entité financière) | DORA Art. 28 complet + CRA 2-5 |
| Fabricant dispositif médical connecté | CRA 1-8 + MDR + GDPR |
Comment ResiPlan détecte automatiquement ces 8 clauses
Notre module d'analyse IA de contrats parcourt chaque contrat fournisseur et :
- Identifie les 8 clauses CRA attendues selon le type de produit
- Extrait les passages du contrat correspondant à chaque clause
- Classe chaque clause : conforme / partielle / non conforme / absente
- Calcule un score de conformité CRA (0-100) spécifique
- Fournit une liste priorisée des clauses manquantes à renégocier
Couplé aux modules DORA, NIS2, ISO 22301 et GDPR, vous obtenez un rapport multi-framework en moins de 2 minutes par contrat.