Résumé express — CRA en 4 minutes
Le CRA impose des exigences de cybersécurité aux produits numériques mis sur le marché de l’UE. Il structure des obligations “security by design”, une gestion des vulnérabilités, des évaluations de conformité (auto-évaluation ou tiers) et un dispositif de surveillance de marché.
- Portée : produits matériels/logiciels et solutions de traitement de données à distance, y compris composants vendus séparément.
- Catégories : par défaut, produits importants (classe I et II), produits critiques.
- Conformité : modules A, B+C, H selon la classe de produit et les références harmonisées.
- Calendrier : montée en puissance entre 2026 et 2027.
- CryptPeer : positionnement orienté “sécurité dès la conception”, mais classification et module de conformité restent à qualifier au cas d’usage.
Introduction au Cyber Resilience Act (CRA)
Le règlement (UE) 2024/2847 vise à renforcer la cybersécurité des produits comportant des éléments numériques dans l’Union européenne, via un cadre uniforme couvrant la conception, la mise sur le marché et le cycle de vie.
Objectifs structurants
- Responsabilisation des fabricants, importateurs et distributeurs (obligations, preuves, suivi).
- Réduction du risque via des exigences essentielles et la gestion des vulnérabilités.
- Harmonisation pour éviter une fragmentation réglementaire.
- Confiance : marquage CE et mécanismes de contrôle de marché.
Marquage CE et signal de conformité
Le CRA rattache la conformité à un marquage CE, ce qui suppose une capacité à démontrer le respect des exigences essentielles et des procédures d’évaluation applicables.
Le marquage CE au titre du CRA ne pourra être apposé qu’après l’entrée en application complète du règlement et l’achèvement formel de la procédure de conformité applicable.
Périmètre d’application
Le CRA vise les produits comportant des éléments numériques : produits logiciels ou matériels et solutions de traitement de données à distance, y compris composants vendus séparément.
Annexes officielles du Cyber Resilience Act
La classification des produits au titre du Cyber Resilience Act (CRA) repose exclusivement sur les annexes du règlement (UE) 2024/2847, qui listent de manière exhaustive les catégories de produits considérés comme importants ou critiques.
- Annexe III — Liste des produits importants de classe I et II (texte officiel UE)
- Annexe IV — Liste des produits critiques (texte officiel UE)
Tout produit ne correspondant explicitement à aucune typologie listée dans ces annexes relève, par défaut, de la catégorie standard, sous réserve de l'analyse de sa fonctionnalité principale.
Catégories de produits
Catégorie « Par défaut »
Produits numériques hors listes “importants” et “critiques”. Exemples : smartphones, ordinateurs, objets connectés non critiques.
Produits importants — Classe I
Types de produits listés (ex. OS, routeurs, navigateurs, gestionnaires de mots de passe, SIEM, etc.).
Produits importants — Classe II
Exemples : hyperviseurs, firewalls/IDS/IPS, microprocesseurs et microcontrôleurs “tamper resistant”.
Produits critiques
Exemples : HSM, cartes à puce/similaires, passerelles pour compteurs intelligents.
Point d’attention : la fonctionnalité principale du produit pilote la catégorisation. Certains secteurs sont exclus (ex. dispositifs médicaux, automobile, aviation civile, etc.).
Modalités d’évaluation de la conformité
Le CRA structure des procédures d’évaluation organisées en modules, avec des exigences accrues selon la criticité.
Module A : Auto-évaluation
Le fabricant réalise l’auto-évaluation et la déclaration de conformité. Aucun tiers n’est impliqué.
Modules B + C : Évaluation par un organisme notifié
Un organisme notifié examine conception/développement avec tests périodiques, puis le fabricant déclare la conformité.
Module H : Système qualité
Un organisme notifié examine la performance du système de contrôle qualité, avec vérifications périodiques, puis le fabricant déclare la conformité.
Diagramme d’évaluation (repère visuel)
Le visuel en tête de page synthétise les chemins d’évaluation par type de produit.
Calendrier d’application
L’entrée en application est progressive entre juin 2026 et décembre 2027, avec une montée en puissance des dispositifs d’évaluation, notification et contrôle.
Échéances clés (repères opérationnels)
- Juin 2026 – Décembre 2026 : accréditation et début de notification des organismes d’évaluation.
- Septembre 2026 : notification des vulnérabilités activement exploitées et incidents graves via ENISA vers le CSIRT coordonnateur.
- Décembre 2027 : produits mis sur le marché conformes ; contrôles de surveillance de marché.
Rôle de l’ANSSI et chaîne nationale
En France, l’ANSSI intervient comme autorité nationale de cybersécurité, autorité de certification (CSA) et acteur structurant de la mise en œuvre CRA.
Autorité notifiante
Évalue, contrôle et notifie les organismes d’évaluation de la conformité (sur base d’accréditation COFRAC).
Soutien technique à l’ANFR
Appui à la stratégie de surveillance de marché et aux contrôles (via laboratoires accrédités mobilisés par l’ANFR).
CSIRT coordonnateur (CERT-FR)
Centralise les signalements de vulnérabilités activement exploitées et incidents graves, coordonne la remédiation avec les fabricants.
Surveillance de marché et sanctions
Le CRA prévoit un dispositif de surveillance de marché. En France, l’ANFR est citée comme autorité de surveillance de marché.
Risque de non-conformité
Le dispositif inclut des mesures correctives (jusqu’au retrait du marché) et des sanctions financières pouvant atteindre 10 M€ ou 2% du chiffre d’affaires annuel mondial selon les cas.
Résumé avancé — Lecture structurée
Le CRA ne se limite pas à un “niveau minimal de sécurité”. Il impose une logique de preuve et de maintien : documentation, gestion de vulnérabilités, traçabilité, capacité d’intervention, et procédures d’évaluation adaptées au niveau de criticité. Ce cadre modifie la relation entre produit, fournisseur et marché : une non-conformité devient un risque commercial et opérationnel, pas seulement technique.
Positionnement de CryptPeer face au CRA
CryptPeer (messagerie et appels P2P auto-hébergés avec chiffrement de bout en bout) se positionne sur une approche “sécurité par conception” et “contrôle opérationnel” via des déploiements maîtrisés. Pour le CRA, deux questions structurent la trajectoire : la catégorisation et la voie d’évaluation.
Catégorisation : prudence et méthode
La classification CRA dépend de la fonctionnalité principale et des cas d’usage. Une solution de communication sécurisée peut, selon contexte, relever d’une catégorie “par défaut” ou être considérée “importante” (classe I) si elle correspond à une typologie listée. CryptPeer ne doit pas auto-déclarer une classe sans analyse de correspondance au texte et à ses annexes.
Positionnement “responsable”
Le positionnement CRA de CryptPeer s’appuie sur des principes (E2EE, réduction des surfaces, contrôle des déploiements, procédures de correctifs), mais la qualification réglementaire finale doit suivre une lecture formelle des annexes et des usages ciblés (B2B, organisations sensibles, environnements isolés, etc.).
Exemple d'analyse de classification CRA : le cas CryptPeer
Afin d'illustrer la méthode de classification prévue par le Cyber Resilience Act, prenons l'exemple de CryptPeer®, une solution de communication chiffrée pair-à-pair auto-hébergée.
1. Fonctionnalité principale
La fonctionnalité principale de CryptPeer est la communication sécurisée (messagerie et appels chiffrés de bout en bout), reposant sur une architecture auto-hébergée et fédérée.
CryptPeer n'est pas conçu comme un composant de sécurité réseau (pare-feu, IDS/IPS), ni comme une infrastructure de gestion d'identités, ni comme un dispositif matériel de sécurité.
2. Vérification au regard des annexes CRA
- Annexe III (produits importants) : CryptPeer ne correspond pas explicitement aux typologies listées (systèmes d'exploitation, navigateurs, routeurs, gestionnaires d'identités, pare-feu, hyperviseurs, microcontrôleurs, etc.).
- Annexe IV (produits critiques) : CryptPeer n'est ni un HSM, ni une carte à puce, ni une passerelle de comptage intelligent ou un dispositif matériel certifié.
3. Hypothèse de classification prudente
Sur la base des annexes actuellement publiées, et sous réserve d'une évaluation formelle par les autorités compétentes, CryptPeer relèverait a priori de la catégorie standard, dès lors qu'aucun rattachement explicite à une catégorie de produit important ou critique n'est établi.
Cette qualification reste conditionnée :
- à l'évolution du périmètre fonctionnel du produit,
- à son positionnement déclaratif sur le marché,
- et à l'interprétation retenue par les autorités de surveillance.
4. Conséquence en matière d'évaluation de conformité
Dans cette hypothèse, et sous réserve de la confirmation de la classification par les autorités compétentes et de l’existence de références harmonisées ou spécifications communes applicables, CryptPeer pourrait relever du module A (auto-évaluation et déclaration UE de conformité), impliquant :
- la mise en œuvre d'exigences de cybersécurité dès la conception,
- une gestion documentée des vulnérabilités,
- et une surveillance continue sur l'ensemble du cycle de vie du produit.
En cas d'évolution de classification vers un produit listé en annexe, une évaluation impliquant un organisme notifié deviendrait alors obligatoire.
5. Table comparative : Catégorie standard vs importante
Facteurs pouvant déclencher une reclassification
Plusieurs facteurs peuvent conduire à une reclassification d'un produit de la catégorie standard vers une catégorie importante ou critique :
- Évolution fonctionnelle : ajout de fonctionnalités correspondant à une typologie listée (ex. intégration d'un composant de gestion d'identités)
- Positionnement marché : déclaration marketing ou commerciale présentant le produit comme un composant critique d'infrastructure
- Usage cible : déploiement dans des environnements critiques (secteur public sensible, infrastructures critiques, etc.)
- Interprétation autorités : décision d'une autorité de surveillance (ANFR, ANSSI) basée sur l'analyse de la fonctionnalité principale
- Évolution réglementaire : modification des annexes CRA incluant de nouvelles typologies
Phrase type pour CGU / Documentation commerciale
"CryptPeer est développé dans une démarche d’alignement avec les exigences du règlement (UE) 2024/2847 (Cyber Resilience Act), en préparation de sa conformité au CRA. Sur la base de l'analyse de sa fonctionnalité principale et des annexes du CRA, CryptPeer relève a priori de la catégorie standard, ce qui pourrait permettre une auto-évaluation et une déclaration UE de conformité (Module A), sous réserve de la confirmation de la classification par les autorités compétentes et de l’existence de références harmonisées ou spécifications communes applicables. Cette classification reste conditionnée à l'évolution du périmètre fonctionnel du produit, à son positionnement sur le marché, et à l'interprétation retenue par les autorités de surveillance compétentes."
Alignement technique : ce que CryptPeer peut démontrer
Sécurité par conception
Chiffrement de bout en bout, réduction des données exposées côté serveur, et options de déploiement auto-hébergé pour limiter la centralisation.
Gestion des vulnérabilités
Processus de correction et cycles de mise à jour. La conformité CRA implique aussi des obligations de notification et de coordination selon les cas.
Maintien sur le cycle de vie
Maintenabilité, documentation technique, capacité à publier des correctifs et à instruire des mesures de mitigation sur les environnements déployés.
Voie de conformité : scénarios plausibles
Selon la catégorisation finale et l’existence de standards harmonisés ou références communes applicables, CryptPeer pourrait relever :
- Module A si les conditions et références harmonisées pertinentes sont remplies.
- Module B+C ou Module H si un tiers est requis, notamment si la classification le rend obligatoire.
- Approche par schémas/certifications (si applicables) pour renforcer la démontrabilité et la confiance de marché.
Chronicle — Ce que le CRA change concrètement (lecture approfondie)
Le CRA introduit un renversement : la cybersécurité n’est plus un attribut “best effort”, mais une propriété évaluée, documentée et vérifiée dans le temps. Trois axes dominent : (1) exigences essentielles applicables aux produits, (2) obligations de gestion des vulnérabilités, (3) mécanismes de conformité et surveillance.
La logique de preuve
Concrètement, un produit doit pouvoir produire des artefacts : spécifications, architecture, sécurité des mises à jour, procédures de correction, et informations de support. Le marquage CE devient un signal de maîtrise organisationnelle, pas seulement une étiquette.
La gestion des vulnérabilités comme processus
Le CRA impose une gestion structurée : réception des signalements, analyse, correction, publication contrôlée, et—selon les cas—notification. Pour une solution comme CryptPeer, cela implique une capacité à orchestrer des correctifs sans détériorer le modèle de sécurité (E2EE, auto-hébergement, etc.).
La surveillance de marché comme contrainte durable
Les contrôles et la capacité des autorités à imposer des mesures correctives transforment la conformité en exigence continue. Cela rend la “dette de sécurité” coûteuse, surtout pour des produits diffusés à large échelle.
Perspective : trajectoire de conformité et stratégie produit
Le CRA favorise les solutions capables de prouver une sécurité maintenue, pas seulement annoncée. Pour CryptPeer, l’avantage compétitif se joue sur la démontrabilité (processus, documentation, cycles de mises à jour), la réduction des expositions serveur et la capacité à fonctionner en environnements contraints.
Checklist CRA — Prête pour audit
Cette checklist synthétise les éléments documentaires et procéduraux utiles pour préparer et démontrer la conformité au CRA, quelle que soit la catégorie de produit concernée.
Exigences essentielles de cybersécurité
- ☐ Spécifications de sécurité : documentation des propriétés de sécurité (confidentialité, intégrité, authentification, disponibilité)
- ☐ Architecture sécurisée : schémas, diagrammes, justification des choix techniques
- ☐ Chiffrement : algorithmes utilisés, gestion des clés, conformité aux standards (ex. recommandations ANSSI, NIST)
- ☐ Réduction des surfaces d'attaque : minimisation des données exposées, principe du moindre privilège
- ☐ Authentification et contrôle d'accès : mécanismes d'identification, gestion des identités
Gestion des vulnérabilités
- ☐ Processus de réception : procédure documentée pour recevoir et traiter les signalements de vulnérabilités
- ☐ Analyse et priorisation : critères d'évaluation de la criticité (CVSS, impact métier)
- ☐ Correction : cycle de développement de correctifs, tests de non-régression
- ☐ Publication contrôlée : politique de divulgation coordonnée (coordinated vulnerability disclosure)
- ☐ Notification : procédure de notification des vulnérabilités activement exploitées et incidents graves (via ENISA vers CSIRT coordonnateur)
- ☐ Traçabilité : registre des vulnérabilités traitées, dates de découverte/correction/publication
Cycle de vie sécurisé
- ☐ Support continu : engagement de maintenance, durée de support annoncée
- ☐ Mises à jour de sécurité : fréquence, canaux de distribution, procédure de déploiement
- ☐ Documentation technique : guides d'installation, configuration sécurisée, bonnes pratiques
- ☐ Fin de vie : politique de fin de support, procédure de migration/archivage
- ☐ Formation utilisateurs : documentation, webinaires, support technique
Évaluation de conformité et déclaration
- ☐ Classification produit : analyse de la fonctionnalité principale, vérification au regard des annexes CRA
- ☐ Module d'évaluation : détermination du module applicable (A, B+C, H) selon catégorie et références harmonisées
- ☐ Auto-évaluation (Module A) : documentation interne, tests, déclaration UE de conformité
- ☐ Évaluation par organisme notifié (B+C, H) : certification, rapports d'évaluation, certificats de conformité
- ☐ Marquage CE : apposition du marquage, documentation technique (dossier technique)
- ☐ Déclaration UE de conformité : document signé, informations produits, références normatives
Documentation et traçabilité
- ☐ Dossier technique : spécifications, architecture, tests, évaluations
- ☐ Registre des modifications : historique des versions, changelog, notes de version
- ☐ Preuves de conformité : certificats, rapports d'essai, déclarations de conformité
- ☐ Gestion des risques : analyse de risques, mesures de mitigation, plan de continuité
- ☐ Conformité aux standards : références aux standards harmonisés, spécifications communes, schémas CSA
Note sur l'utilisation de cette checklist
Cette checklist est indicative et doit être adaptée selon la catégorie de produit, le module d'évaluation applicable, et les références harmonisées pertinentes. Une évaluation formelle par un organisme notifié ou un expert juridique peut être nécessaire pour valider la conformité complète au CRA.