Donneespersonnelles.fr

Plateforme de veille en conformite numerique

Mardi 29 septembre 2026
Cyber Resilience Act

Produits CRA : classe I, classe II ou critiques ?

Classez votre produit CRA avec les annexes et les descriptions techniques : fonctionnalité de base, composants intégrés et procédure applicable.

Un système d’exploitation figure en classe I du CRA ; un hyperviseur figure en classe II. Un logiciel métier ne devient pas automatiquement un produit important parce qu’il embarque un navigateur. La classification dépend de la fonctionnalité de base du produit et des descriptions légales, pas d’une appréciation libre du caractère « sensible » de son client.

Les textes à utiliser ensemble

Les Art. 7 et 8 et annexes III et IV du règlement (UE) 2024/2847 définissent les catégories. Le règlement d’exécution (UE) 2025/2392, adopté le 28 novembre 2025, précise leurs descriptions techniques.

Vérifiez d’abord le champ d’application du CRA. Un classement dans une annexe ne dispense pas d’analyser la commercialisation, le rôle de l’entreprise ou une éventuelle exclusion sectorielle.

Délimiter l’objet du classement avant de choisir une classe

Une fiche de classement utile décrit une offre précise. Relevez le nom, la version, les fonctions commercialisées et les éléments fournis avec elle. Si plusieurs éditions existent, expliquez leurs différences. Une conclusion valable pour une édition limitée ne couvre pas automatiquement celle qui ajoute des fonctions de sécurité ou de virtualisation.

L’Art. 7(1) rattache le classement à la fonctionnalité de base. Pour l’examiner, confrontez la description commerciale, l’architecture et les opérations que le produit permet effectivement. Une présentation qui insiste sur la sécurité ne suffit pas à établir une catégorie ; inversement, un intitulé commercial neutre ne permet pas d’écarter une fonction répondant à sa description légale.

La distinction entre le produit et ses composants doit rester explicite. Identifiez ce qui est proposé sur le marché comme produit et ce qui est intégré pour le faire fonctionner. Conservez les caractéristiques utiles des composants sans recopier leurs catégories dans la colonne du produit final. Si un composant est lui-même commercialisé séparément, son propre classement mérite une analyse distincte.

Dans un dossier complexe, formulez la question technique avant de demander un avis : quelles opérations sont possibles, à quelles conditions, et quelle fonction explique l’utilisation du produit ? Une réponse documentée sur ces points aide davantage qu’une demande générale de confirmer que le logiciel « n’est pas critique ».

Classe I : des fonctions structurantes pour la sécurité

L’annexe III, classe I, comprend notamment les gestionnaires d’identités et d’accès privilégiés, navigateurs, gestionnaires de mots de passe, antivirus, VPN, SIEM, systèmes d’exploitation, routeurs, modems destinés à la connexion internet et commutateurs.

Elle vise aussi certaines catégories matérielles et certains produits domestiques ou portables. Par exemple, les jouets connectés visés présentent des caractéristiques sociales interactives ou des fonctions de localisation : tous les jouets ne sont pas classés sur le seul mot « connecté ».

Pour l’évaluation, l’Art. 32(2) permet une voie de contrôle interne sous conditions de couverture des exigences par les références prévues au texte. À défaut, une intervention tierce est requise pour les exigences concernées. Le guide d’évaluation CRA détaille les modules et leurs conditions.

Classe II : quatre catégories dans l’annexe III

La classe II comprend :

  • les hyperviseurs et systèmes d’exécution de conteneurs prenant en charge l’exécution virtualisée de systèmes d’exploitation et d’environnements similaires ;
  • les pare-feu, systèmes de détection et de prévention des intrusions ;
  • les microprocesseurs résistants aux manipulations ;
  • les microcontrôleurs résistants aux manipulations.

Il serait erroné d’y déplacer tous les systèmes d’exploitation pour serveurs ou tous les routeurs industriels. Il faut lire la description technique et déterminer la fonctionnalité de base du produit réellement commercialisé.

L’Art. 32(3) prévoit les modules B+C, H ou, lorsqu’elle est disponible et applicable, la voie de certification européenne encadrée par le texte. L’Art. 32(5) comporte une exception pour certains logiciels libres et ouverts avec documentation technique publique. « Classe II » ne signifie donc pas « aucune exception possible ».

Produits critiques : l’annexe IV

Trois familles y figurent : dispositifs matériels avec boîtier de sécurité ; passerelles pour compteurs intelligents et autres dispositifs de sécurité avancée visés ; cartes à puce et dispositifs similaires, dont les éléments sécurisés.

Le règlement 2025/2392 précise les propriétés attendues. Ses exemples comprennent notamment certains modules matériels de sécurité et terminaux de paiement répondant à la description. Le nom commercial du matériel ne suffit pas à classer toute une gamme.

L’Art. 8(1) permet d’imposer une certification européenne par acte délégué sous conditions. En l’absence d’un tel acte applicable, il renvoie aux procédures de l’Art. 32(3). La seule existence du schéma EUCC ne permet pas d’affirmer que tout produit critique doit déjà détenir un certificat EUCC.

Un composant important ne classe pas automatiquement le produit entier

Le règlement 2025/2392, considérants 3 à 5, distingue la fonctionnalité de base des fonctions intégrées. Une application d’actualités embarquant un navigateur ne devient pas, pour ce seul motif, un navigateur au sens de la catégorie. De même, un routeur intégrant une fonction de pare-feu peut conserver sa fonctionnalité de base de routeur.

Cette règle ne supprime pas l’obligation d’évaluer la sécurité du composant dans le produit. Reliez la qualification à l’architecture et au SBOM, plutôt qu’à une liste de mots-clés.

Comparer les catégories avec une note de qualification

La démarche suivante est une proposition de travail fondée sur les Art. 7 et 8. Elle sert à rendre le raisonnement vérifiable ; elle ne remplace pas les descriptions techniques du règlement d’exécution.

Pour chaque catégorie plausible, conservez la référence exacte, les caractéristiques requises et les pièces permettant de les constater. Inscrivez également les éléments contraires à l’hypothèse. Lorsque la description exige une propriété particulière, le seul nom d’une famille de produits ne prouve pas que cette propriété existe.

Voici un dossier entièrement fictif. L’entreprise Varech commercialise deux éditions sous une même marque. La première présente une fonction principale de gestion documentaire. La seconde est annoncée avec une nouvelle fonction d’administration, dont la portée technique n’est pas encore décrite. L’équipe possède une brochure commune et deux nomenclatures de composants, mais aucun descriptif complet de la nouvelle fonction.

Il serait prématuré de classer les deux éditions à partir de la seule marque ou de leur composant commun. La note indique deux périmètres, les catégories à examiner et la pièce attendue pour la seconde édition. Elle évite aussi de conclure à une absence de classement faute de description : l’information manquante demeure une réserve à résoudre.

Lorsque l’analyse est terminée, rédigez une conclusion courte expliquant les faits décisifs et leur rapprochement avec le texte. Mentionnez la version examinée et la date de l’analyse. Une capture d’écran d’un tableau de catégories ne permet pas, seule, de comprendre pourquoi la conclusion correspond à votre produit.

La fiche de classement à conserver

Rubrique Décision à documenter
Produit et version Délimiter ce qui est commercialisé séparément
Fonctionnalité de base Expliquer la fonction principale et les fonctions accessoires
Catégorie candidate Citer l’annexe et la description technique pertinente
Éléments de preuve Architecture, fonctions, documentation commerciale et technique
Conclusion Classe retenue, procédure envisagée, points à confirmer
Réexamen Prévoir les changements déclenchant une nouvelle analyse

Insérez cette fiche dans la documentation technique CRA. Une évolution de fonctionnalités peut justifier un réexamen ; elle ne doit pas être ignorée parce que le nom du produit reste identique.

Les signalements de l’article 14 s’appliquent depuis le 11 septembre 2026 indépendamment du classement. L’application générale intervient le 11 décembre 2027 : voir le calendrier CRA.

Relier la classe à une procédure démontrable

Après le classement, établissez un second dossier consacré à l’évaluation. Pour un produit de classe I, une mention générale « normes appliquées » ne suffit pas. Au regard de l’Art. 32(2), il faut savoir quelles références sont utilisées, quelles exigences elles couvrent et lesquelles restent à traiter par la procédure appropriée.

Préparez une correspondance entre les exigences essentielles, les références retenues et les éléments de démonstration. Si la couverture n’est que partielle, rendez cette limite visible avant de commander une prestation. Le devis d’un évaluateur et le dossier technique doivent porter sur le même produit, la même version et les mêmes processus du fabricant.

Pour l’exception de l’Art. 32(5), vérifiez séparément la qualification de logiciel libre et ouvert, l’appartenance aux catégories de l’annexe III et la mise à disposition publique de la documentation technique au moment de la mise sur le marché. La simple publication de quelques fichiers sources ne démontre pas que toutes ces conditions sont réunies. Cette disposition n’est pas formulée comme une exception générale pour l’annexe IV.

Dans le cas des produits critiques, identifiez l’acte éventuellement applicable au titre de l’Art. 8(1), son champ et ses conditions. Un certificat disponible dans l’écosystème ne règle pas automatiquement la procédure imposée au produit étudié. Distinguez donc la classe, le choix de procédure et les preuves qui permettront de démontrer la conformité.

Prévoir les événements qui rouvrent l’analyse

Intégrez une question de classement aux revues de changement : nouvelle édition, fonction ajoutée, composant désormais vendu séparément ou évolution du périmètre documenté. Ces événements justifient un examen ; ils ne signifient pas tous, par eux-mêmes, un changement de classe.

La veille doit aussi suivre les catégories et leurs descriptions. Les Art. 7(3) et 8(2) prévoient des possibilités de modification des annexes. Conservez la référence et la date des textes utilisés, puis expliquez les conséquences d’une évolution sur les produits concernés. La date d’une veille et la date d’application d’une nouvelle règle doivent rester distinctes dans le dossier.

Ce qu’il faut retenir

  • Les produits importants sont répartis entre classes I et II ; les critiques figurent dans une annexe distincte.
  • La fonctionnalité de base et le règlement 2025/2392 guident les cas limites.
  • L’intégration d’un composant ne transfère pas automatiquement sa classe au produit entier.
  • Les procédures comportent des conditions, notamment pour l’open source et la certification européenne.

FAQ

Un routeur industriel relève-t-il nécessairement de la classe II ?

Non. Les routeurs figurent en classe I. Il faut toutefois examiner la fonctionnalité de base réelle et la description du produit, notamment lorsque plusieurs fonctions sont réunies.

Un produit hors annexes est-il dispensé de cybersécurité ?

Non. S’il entre dans le champ du CRA, les exigences essentielles restent applicables. Le contrôle interne est une procédure de démonstration, pas une exemption de fond.

Tout logiciel utilisant un navigateur devient-il important ?

Non. Le règlement d’exécution distingue le composant intégré de la fonctionnalité de base du produit dans son ensemble. La sécurité du composant reste à prendre en compte.

Recevez nos analyses conformité dans la newsletter.

Thiébaut Devergranne, docteur en droit et fondateur de donneespersonnelles.fr, travaille depuis plus de vingt ans sur le droit des technologies et la conformité numérique.

Thiébaut Devergranne
Docteur en droit des nouvelles technologies (Paris II)

Docteur en droit, Thiébaut Devergranne travaille en droit des nouvelles technologies et en protection des données personnelles depuis plus de 20 ans. Il a accompagné des centaines d'organisations dans leur mise en conformité RGPD et est le fondateur de Legiscope, logiciel de conformité RGPD.

En savoir plus sur l'auteur →