AVCA Legal

Fiche de classification produit

Auto-diagnostic Cyber Resilience Act — règl. (UE) 2024/2847, art. 2, 3, 7, 8 ; annexes I, III, IV

Confidentialité absolue. Aucune donnée saisie ici n'est envoyée ni conservée par AVCA Legal. Les informations sensibles sur votre produit — architecture, catégorie, vulnérabilités — restent dans votre navigateur. Pour conserver et poursuivre le diagnostic, vous exportez un fichier chiffré que vous rangez vous-même dans votre dossier produit, sous votre seul contrôle. Rien ne permet de savoir quelle entreprise utilise l'outil, ni pour quel produit.

Comment ça marche — et comment reprendre le diagnostic plus tard

1. Je renseigne le produit

Décrivez le produit et répondez aux questions de qualification et de classification, directement à l'écran. Aucun compte, aucune installation.

2. J'exporte et je classe

Un clic sur « Exporter » crée un fichier chiffré, protégé par une phrase de passe. Enregistrez-le dans le dossier du produit, comme une pièce.

3. Je ré-importe pour continuer

Plus tard, cliquez sur « Importer », rouvrez ce fichier avec votre phrase de passe : la fiche se recharge, vous complétez le diagnostic, puis vous ré-exportez.

Ce fichier chiffré est votre seule copie, sous votre seul contrôle : rien n'est enregistré sur nos serveurs. Sans votre phrase de passe, personne ne peut l'ouvrir — pas même AVCA Legal. Conservez-les ensemble, en lieu sûr.

1Identité du dossier

2Produit comportant des éléments numériques

Décrivez le produit examiné — art. 3 CRA

3Qualification — le produit relève-t-il du CRA ?

Champ d'application et exclusions — art. 2, 3, 24 CRA

Résultat de la qualificationDANS LE CHAMP
  • — Produit comportant des éléments numériques mis à disposition dans le cadre d'une activité commerciale, sans exclusion sectorielle : DANS LE CHAMP du CRA.

4Classification — quelle catégorie ?

Selon la fonctionnalité PRINCIPALE — art. 7, 8 CRA ; annexes III et IV. Sélectionnez la catégorie correspondante dans chaque annexe (ou « aucune »).

Niveau retenuDÉFAUT

Produit par défaut

Motivation

  • — Aucun rattachement à l'annexe III ou IV : le produit relève de la catégorie « par défaut ».

Voie d'évaluation de la conformité (art. 32)

Autoévaluation par contrôle interne (module A, annexe VIII) : le fabricant assume lui-même la conformité aux exigences essentielles (art. 32).

5Exigences essentielles — annexe I

État d'avancement, exigence par exigence. « À évaluer » n'est pas un défaut : c'est un simple point restant à examiner.

Avancement0/19 évaluées · 0% conformes

Partie I — propriétés du produit

Mise sur le marché sans vulnérabilité exploitable connue, avec une configuration par défaut sécurisée et la possibilité de réinitialisation.

Protection contre les accès non autorisés par des mécanismes appropriés d'authentification, de gestion des identités et de contrôle d'accès.

Protection de la confidentialité des données (au repos et en transit) par le chiffrement, selon l'état de l'art.

Protection de l'intégrité des données, commandes, programmes et configuration contre toute manipulation ou modification non autorisée.

Minimisation des données : traitement limité aux données adéquates, pertinentes et nécessaires à la finalité du produit.

Protection de la disponibilité des fonctions essentielles, y compris la résilience et l'atténuation des attaques par déni de service.

Minimisation de l'incidence négative du produit sur la disponibilité des services fournis par d'autres dispositifs ou réseaux.

Conception limitant les surfaces d'attaque, y compris les interfaces externes.

Réduction de l'incidence des incidents par des mécanismes et techniques appropriés d'atténuation de l'exploitation.

Fourniture d'informations relatives à la sécurité par l'enregistrement et la surveillance des activités internes pertinentes (accès, modifications).

Possibilité de corriger les vulnérabilités par des mises à jour de sécurité, y compris, le cas échéant, automatiques et avec notification à l'utilisateur.

Partie II — gestion des vulnérabilités

Recenser et documenter les vulnérabilités et composants du produit, notamment en établissant une nomenclature des logiciels (SBOM) dans un format lisible par machine couvrant au moins les dépendances de premier niveau.

Remédier sans délai aux vulnérabilités, notamment par des mises à jour de sécurité, pendant la période de support.

Appliquer des tests et examens de la sécurité du produit de manière régulière.

Après mise à disposition d'une mise à jour, publier des informations sur les vulnérabilités corrigées (description, impact, correctifs).

Mettre en place et faire respecter une politique de divulgation coordonnée des vulnérabilités.

Prendre des mesures pour faciliter le signalement des vulnérabilités, y compris un point de contact.

Fournir des mécanismes de diffusion sécurisée des mises à jour pour distribuer sans délai les correctifs.

Diffuser sans délai et à titre gratuit les correctifs ou mises à jour de sécurité, accompagnés d'avis de sécurité.

6Approfondissement — mécanismes de mise à jour sécurisée (avis ENISA)

État de l'art attendu selon l'avis technique de l'ENISA sur les mécanismes de mise à jour sécurisée, EN APPUI de l'annexe I (mises à jour de sécurité, partie I ; gestion des vulnérabilités, partie II). Ce n'est PAS une obligation légale distincte du règlement, mais une aide à l'auto-évaluation, étape par étape du cycle de vie de la mise à jour. « À évaluer » n'est pas un défaut : c'est un simple point restant à examiner.

Avancement0/27 évalués · 0% conformes

Préparation & publication

Signature cryptographique des métadonnées et liaison cryptographique des artefacts de mise à jour à ces métadonnées.

Protection et gestion des clés de signature (stockage sécurisé/HSM, authentification forte, accès restreint, séparation des rôles, rotation/révocation).

Intégrité et cohérence des métadonnées (version, applicabilité, empreintes, tailles).

Validation avant publication (contrôles d'intégrité, vérification de signature, tests de déploiement).

Environnement de build de confiance et isolé (seuls code, dépendances et configurations autorisés).

Traçabilité/provenance entre code source, entrées, outils, approbations et artefacts (provenance signée SLSA / attestations in-toto pour les niveaux d'assurance élevés).

Contrôle des composants tiers et dépendances pour identifier et traiter les vulnérabilités connues avant publication.

Processus de publication formalisé, avec points d'approbation et séparation des tâches.

Protection des services de publication, dépôts et API (authentification forte, moindre privilège, journalisation, surveillance).

Séparer la livraison des mises à jour de sécurité des changements fonctionnels ; installation automatique des mises à jour de sécurité par défaut lorsque c'est possible.

Publier chaque correctif de sécurité avec une information claire (vulnérabilité, impact, sévérité, remédiation).

Tester l'application sûre des mises à jour (compatibilité, fonctionnement des mécanismes de rollback/récupération en cas d'échec).

Découverte & récupération

Sources de mise à jour authentifiées et autorisées uniquement.

Canaux chiffrés et authentifiés (TLS), sans repli vers un protocole non sécurisé.

Redirections non suivies sauf validation explicite (hôtes/domaines approuvés uniquement).

Traiter CDN, miroirs et intermédiaires comme non fiables : leur compromission ne doit pas suffire à faire accepter une mise à jour altérée.

Contrôle d'intégrité initial de l'artefact récupéré (empreintes), sans s'y fier avant authentification des métadonnées.

Validation de la fraîcheur des métadonnées (expiration, horodatage, numéro de version/séquence) pour rejeter les métadonnées périmées ou rejouées (anti-replay / anti-freeze).

Découverte et récupération automatiques prises en charge, mises à jour de sécurité activées par défaut ; utilisateur informé, avec des contrôles d'opt-out/report n'empêchant pas l'application des correctifs critiques.

Vérification & installation

Vérification de l'authenticité des métadonnées et liaison cryptographique des artefacts (empreintes signées).

Validation de l'applicabilité (produit, version, configuration) avant installation.

Contrôle d'intégrité des artefacts avant installation ; rejet de tout contenu corrompu ou modifié.

Contrôle de version et anti-rollback (compteurs ou numéros de séquence monotones) pour empêcher l'installation de versions anciennes, même valablement signées.

Seuls des composants de confiance et autorisés peuvent initier et exécuter l'installation (restrictions de privilèges).

Installation atomique et contrôlée, évitant les états partiels ou interrompus, avec capacité de récupération.

Observabilité & récupération

Journalisation et compte rendu de l'issue de la mise à jour (succès/échec) au niveau du point de terminaison.

Mécanismes de récupération/rollback fiables en cas d'échec, sans laisser le produit dans un état vulnérable.

7Période de support & marquage

Période de support d'au moins 5 ans — art. 13 CRA. Marquage CE et déclaration UE de conformité applicables à compter du 11 décembre 2027.

8Registre des vulnérabilités & signalements

Traçabilité des vulnérabilités activement exploitées et incidents graves — art. 13, 14 CRA. Délais : alerte ≤ 24 h, notification ≤ 72 h, rapport final ≤ 14 j (vuln.) / ≤ 1 mois (incident). Obligations applicables depuis le 11 septembre 2026.

Aucune entrée. Ajoutez une ligne à chaque vulnérabilité activement exploitée ou incident grave affectant la sécurité du produit.

9Notes libres

Cet auto-diagnostic aide à structurer la qualification et la classification d'un produit au regard du règlement (UE) 2024/2847 ; il ne se substitue pas à une analyse individualisée. Le classement repose sur la fonctionnalité principale du produit (art. 7, 8). Les données restent dans votre navigateur : le fichier chiffré que vous exportez et archivez dans votre dossier produit en est la seule copie.

Fiche de classification produit — Cyber Resilience Act
Produit
Entreprise · Rôle : Fabricant · Référence : — · Évalué le 07/07/2026 · Édité le 07/07/2026
1. Produit
—
2. Qualification : DANS LE CHAMP
— Produit comportant des éléments numériques mis à disposition dans le cadre d'une activité commerciale, sans exclusion sectorielle : DANS LE CHAMP du CRA.
3. Classification : Produit par défaut
— Aucun rattachement à l'annexe III ou IV : le produit relève de la catégorie « par défaut ».
Évaluation de la conformité (art. 32) : Autoévaluation par contrôle interne (module A, annexe VIII) : le fabricant assume lui-même la conformité aux exigences essentielles (art. 32).
4. Exigences essentielles (annexe I)
Avancement : 0/19 exigences évaluées · 0% des exigences applicables jugées conformes.
Partie I — propriétés du produit
— Mise sur le marché sans vulnérabilité exploitable connue, avec une configuration par défaut sécurisée et la possibilité de réinitialisation. [À évaluer]
— Protection contre les accès non autorisés par des mécanismes appropriés d'authentification, de gestion des identités et de contrôle d'accès. [À évaluer]
— Protection de la confidentialité des données (au repos et en transit) par le chiffrement, selon l'état de l'art. [À évaluer]
— Protection de l'intégrité des données, commandes, programmes et configuration contre toute manipulation ou modification non autorisée. [À évaluer]
— Minimisation des données : traitement limité aux données adéquates, pertinentes et nécessaires à la finalité du produit. [À évaluer]
— Protection de la disponibilité des fonctions essentielles, y compris la résilience et l'atténuation des attaques par déni de service. [À évaluer]
— Minimisation de l'incidence négative du produit sur la disponibilité des services fournis par d'autres dispositifs ou réseaux. [À évaluer]
— Conception limitant les surfaces d'attaque, y compris les interfaces externes. [À évaluer]
— Réduction de l'incidence des incidents par des mécanismes et techniques appropriés d'atténuation de l'exploitation. [À évaluer]
— Fourniture d'informations relatives à la sécurité par l'enregistrement et la surveillance des activités internes pertinentes (accès, modifications). [À évaluer]
— Possibilité de corriger les vulnérabilités par des mises à jour de sécurité, y compris, le cas échéant, automatiques et avec notification à l'utilisateur. [À évaluer]
Partie II — gestion des vulnérabilités
— Recenser et documenter les vulnérabilités et composants du produit, notamment en établissant une nomenclature des logiciels (SBOM) dans un format lisible par machine couvrant au moins les dépendances de premier niveau. [À évaluer]
— Remédier sans délai aux vulnérabilités, notamment par des mises à jour de sécurité, pendant la période de support. [À évaluer]
— Appliquer des tests et examens de la sécurité du produit de manière régulière. [À évaluer]
— Après mise à disposition d'une mise à jour, publier des informations sur les vulnérabilités corrigées (description, impact, correctifs). [À évaluer]
— Mettre en place et faire respecter une politique de divulgation coordonnée des vulnérabilités. [À évaluer]
— Prendre des mesures pour faciliter le signalement des vulnérabilités, y compris un point de contact. [À évaluer]
— Fournir des mécanismes de diffusion sécurisée des mises à jour pour distribuer sans délai les correctifs. [À évaluer]
— Diffuser sans délai et à titre gratuit les correctifs ou mises à jour de sécurité, accompagnés d'avis de sécurité. [À évaluer]
5. Mécanismes de mise à jour sécurisée (avis ENISA, en appui de l'annexe I)
État de l'art attendu selon l'avis technique de l'ENISA, en appui de l'annexe I (mises à jour de sécurité, gestion des vulnérabilités). Aide à l'auto-évaluation, non constitutive d'une obligation légale distincte.
Avancement : 0/27 critères évalués · 0% des critères applicables jugés conformes.
Préparation & publication
— Signature cryptographique des métadonnées et liaison cryptographique des artefacts de mise à jour à ces métadonnées. [À évaluer]
— Protection et gestion des clés de signature (stockage sécurisé/HSM, authentification forte, accès restreint, séparation des rôles, rotation/révocation). [À évaluer]
— Intégrité et cohérence des métadonnées (version, applicabilité, empreintes, tailles). [À évaluer]
— Validation avant publication (contrôles d'intégrité, vérification de signature, tests de déploiement). [À évaluer]
— Environnement de build de confiance et isolé (seuls code, dépendances et configurations autorisés). [À évaluer]
— Traçabilité/provenance entre code source, entrées, outils, approbations et artefacts (provenance signée SLSA / attestations in-toto pour les niveaux d'assurance élevés). [À évaluer]
— Contrôle des composants tiers et dépendances pour identifier et traiter les vulnérabilités connues avant publication. [À évaluer]
— Processus de publication formalisé, avec points d'approbation et séparation des tâches. [À évaluer]
— Protection des services de publication, dépôts et API (authentification forte, moindre privilège, journalisation, surveillance). [À évaluer]
— Séparer la livraison des mises à jour de sécurité des changements fonctionnels ; installation automatique des mises à jour de sécurité par défaut lorsque c'est possible. [À évaluer]
— Publier chaque correctif de sécurité avec une information claire (vulnérabilité, impact, sévérité, remédiation). [À évaluer]
— Tester l'application sûre des mises à jour (compatibilité, fonctionnement des mécanismes de rollback/récupération en cas d'échec). [À évaluer]
Découverte & récupération
— Sources de mise à jour authentifiées et autorisées uniquement. [À évaluer]
— Canaux chiffrés et authentifiés (TLS), sans repli vers un protocole non sécurisé. [À évaluer]
— Redirections non suivies sauf validation explicite (hôtes/domaines approuvés uniquement). [À évaluer]
— Traiter CDN, miroirs et intermédiaires comme non fiables : leur compromission ne doit pas suffire à faire accepter une mise à jour altérée. [À évaluer]
— Contrôle d'intégrité initial de l'artefact récupéré (empreintes), sans s'y fier avant authentification des métadonnées. [À évaluer]
— Validation de la fraîcheur des métadonnées (expiration, horodatage, numéro de version/séquence) pour rejeter les métadonnées périmées ou rejouées (anti-replay / anti-freeze). [À évaluer]
— Découverte et récupération automatiques prises en charge, mises à jour de sécurité activées par défaut ; utilisateur informé, avec des contrôles d'opt-out/report n'empêchant pas l'application des correctifs critiques. [À évaluer]
Vérification & installation
— Vérification de l'authenticité des métadonnées et liaison cryptographique des artefacts (empreintes signées). [À évaluer]
— Validation de l'applicabilité (produit, version, configuration) avant installation. [À évaluer]
— Contrôle d'intégrité des artefacts avant installation ; rejet de tout contenu corrompu ou modifié. [À évaluer]
— Contrôle de version et anti-rollback (compteurs ou numéros de séquence monotones) pour empêcher l'installation de versions anciennes, même valablement signées. [À évaluer]
— Seuls des composants de confiance et autorisés peuvent initier et exécuter l'installation (restrictions de privilèges). [À évaluer]
— Installation atomique et contrôlée, évitant les états partiels ou interrompus, avec capacité de récupération. [À évaluer]
Observabilité & récupération
— Journalisation et compte rendu de l'issue de la mise à jour (succès/échec) au niveau du point de terminaison. [À évaluer]
— Mécanismes de récupération/rollback fiables en cas d'échec, sans laisser le produit dans un état vulnérable. [À évaluer]
6. Période de support & marquage
Période de support : 5 an(s)
Marquage CE : non apposé · Déclaration UE de conformité : non établie
7. Registre des vulnérabilités & signalements
Aucune entrée.
Fiche établie au titre du règlement (UE) 2024/2847 (Cyber Resilience Act). La classification repose sur la fonctionnalité principale du produit (art. 7, 8) ; les obligations de signalement (art. 14) s'appliquent depuis le 11 septembre 2026 et l'application pleine du règlement interviendra le 11 décembre 2027. Auto-diagnostic établi avec l'outil offert par AVCA Legal — aucune donnée n'a été transmise à AVCA Legal.