Conformité CRA : les enseignements du schéma EUDI Wallet d'ENISA [2026]

Le 3 avril 2026, ENISA a publié le projet v0.4.614 du schéma de certification pour le portefeuille d'identité numérique européen : 110 pages, une consultation publique ouverte jusqu'au 30 avril, et un webinaire le 8 avril. C'est le premier schéma de certification en cybersécurité pour les services TIC jamais rédigé dans le cadre du règlement européen sur la cybersécurité (Cybersecurity Act). L'EUCC couvre déjà les produits TIC ; ce schéma ouvre de nouvelles perspectives en appliquant le même cadre aux services. Il cible les portefeuilles d'identité numérique, pas les produits en général. Mais les normes d'évaluation, les obligations relatives à la chaîne d'approvisionnement et l'infrastructure de conformité qu'il établit vont façonner l'ensemble de la certification de cybersécurité dans l'UE, y compris les schémas qui régiront à terme les produits soumis au CRA. Voici ce que le schéma exige, les références explicites au CRA qu'il contient, et ce que les fabricants de produits doivent suivre de près.

Pourquoi un schéma pour le portefeuille importe aux fabricants de produits

Le schéma EUDI Wallet et le CRA opèrent sur des objets juridiques différents. Le CRA régit les produits comportant des éléments numériques mis sur le marché de l'UE. Le schéma pour le portefeuille régit un type spécifique de service : la solution EUDI Wallet. Il ne s'agit pas du même règlement.

Mais ils partagent la même plomberie juridique.

Les articles 24 et 27 du CRA font tous deux référence aux schémas de certification de cybersécurité européens dans le cadre du Cybersecurity Act comme voie de conformité alternative. Un produit couvert par un schéma CSA applicable peut utiliser la certification sous ce schéma pour démontrer sa conformité avec les exigences essentielles correspondantes du CRA. Aucun schéma de ce type couvrant les produits CRA n'existe encore. Le schéma EUDI Wallet est le premier à être rédigé, et les choix qu'ENISA opère ici, sur les formats de preuves, les exigences relatives à la chaîne d'approvisionnement et la méthodologie d'évaluation, seront repris à l'avenir.

Le schéma trace une frontière juridictionnelle claire à la page 9. Le texte est direct : le CRA « ne s'applique pas directement aux portefeuilles EUDI tels qu'ils sont certifiés dans le cadre du présent schéma, car ils sont certifiés en tant que services TIC, et non en tant que produits TIC ». Pour la plupart des participants à l'EUDIW, le CRA n'est pas une obligation parallèle. Le schéma s'est inspiré sélectivement de la méthodologie du CRA, mais cet emprunt n'étend pas le champ d'application du règlement.

L'exception concerne le mobile. Lorsque l'instance du portefeuille est une application mobile mise sur le marché par une entité commerciale, le CRA s'applique à cette application en tant que produit comportant des éléments numériques. Pour les entreprises qui distribuent commercialement une application mobile de portefeuille, deux régimes s'appliquent simultanément. Le CRA couvre les obligations de conformité pré-commercialisation et de gestion des vulnérabilités post-commercialisation sur le produit. Le schéma pour le portefeuille couvre la certification continue du service. Ils se cumulent, mais uniquement dans ce scénario spécifique. Une organisation fournissant une solution de portefeuille purement en tant que service TIC n'a aucune obligation CRA au titre de ce schéma.

Le cadre commun inclut le CSA et le cadre européen d'évaluation fondé sur les Critères Communs (ECCF), CEN TS 18072 pour les exigences de service du portefeuille, et EUCC (le schéma européen de certification en cybersécurité fondé sur les Critères Communs) comme base compositionnelle pour les composants matériels et les plateformes. Rien de cette infrastructure n'a été conçu uniquement pour les portefeuilles. C'est le squelette que les futurs schémas adjacents au CRA utiliseront.

Une limite supplémentaire : le schéma indique que les certificats EUDIW « ne seront pas adaptés à la présomption de conformité » dans le cadre du CRA (p.9). Même pour les applications mobiles de portefeuille auxquelles le CRA s'applique, le certificat EUDIW ne satisfait pas la conformité CRA. Les deux parcours de mise en conformité sont distincts et doivent chacun être complétés de manière indépendante.

Distributeurs d'applications mobiles de portefeuille : deux parcours de conformité indépendants. Si vous êtes une entité commerciale mettant sur le marché de l'UE une application mobile de portefeuille, le CRA s'applique à cette application en tant que produit comportant des éléments numériques. Vous avez besoin d'une évaluation de la conformité CRA pour le produit et d'une certification EUDIW pour le service de portefeuille. L'une ne satisfait pas l'autre. Toutes deux doivent être complétées de manière indépendante et maintenues sous des cycles de surveillance distincts. Si vous fournissez le portefeuille purement en tant que service TIC sans application mobile distribuée séparément, le CRA ne s'applique pas à vous au titre de ce schéma.

Si vos produits seront à terme soumis à un schéma de certification CSA dans le cadre de la voie de l'article 27 du CRA, le schéma pour le portefeuille est votre aperçu le plus clair de ce à quoi ressemblera cette évaluation. Les méthodologies validées ici sont celles auxquelles vous serez confronté.

Consultez le guide de décision sur l'évaluation de la conformité pour les options actuelles de modules CRA pendant que les schémas CSA sont encore en attente.

L'infrastructure de certification aujourd'hui

Le paysage de conformité CRA comporte actuellement quatre niveaux. Les produits par défaut (la majorité) peuvent utiliser l'auto-évaluation du module A. Les produits importants de classe I peuvent utiliser le module A s'ils appliquent des normes harmonisées, ou faire appel à un organisme notifié. Les produits importants de classe II et les produits critiques nécessitent une évaluation par un tiers, les produits critiques devant également se soumettre à un schéma CSA applicable lorsqu'il en existe un.

La lacune : aucun schéma CSA ne couvre actuellement les exigences essentielles du CRA. Cela signifie que la voie de l'article 27, par laquelle la certification CSA déclenche la présomption de conformité avec le CRA, n'est pas encore praticable pour aucun produit. Elle existe dans le règlement, mais pas dans la pratique.

Le schéma EUDI Wallet ne comble pas cette lacune. Mais il établit le modèle.

Le schéma impose exclusivement le niveau d'assurance « élevé », sans autoriser de niveaux inférieurs. La justification dans le document est directe : « toutes les fonctions fournies par les portefeuilles EUDI sont des fonctions de sécurité, certaines d'une sensibilité critique » (p.17). Le schéma juge qu'aucune fonction du portefeuille n'est suffisamment peu risquée pour permettre l'auto-évaluation.

L'auto-évaluation n'est pas seulement découragée. Elle est bloquée : « Une auto-évaluation de conformité... ne doit pas être autorisée » (p.18).

La logique est parallèle à l'approche du CRA pour les produits importants et critiques. Des enjeux plus élevés justifient des voies de conformité plus strictes. Le seuil spécifique diffère entre les régimes, mais le principe est identique. Lorsqu'ENISA rédigera de futurs schémas CSA pour les catégories de produits CRA, attendez le même raisonnement appliqué aux produits des annexes III et IV.

Important : La correspondance entre les niveaux d'assurance et les catégories de produits CRA dans les futurs schémas CSA est notre inférence analytique, pas une déclaration explicite du schéma EUDIW. Le schéma ne couvre que les portefeuilles.

Pour les règles actuelles de classification des produits selon le CRA, consultez le guide de classification des produits.

Ce que le schéma exige des entreprises privées

Le schéma définit un cycle de vie en quatre étapes pour les demandeurs.

La préparation couvre la constitution du dossier documentaire, l'évaluation des risques et la collecte des preuves d'assurance pour les composants. C'est ici que les preuves relatives à votre chaîne d'approvisionnement deviennent un prérequis bloquant, et non un simple ajout facultatif.

La première évaluation porte sur la revue de conception et l'analyse des dépendances. Un établissement d'évaluation de la sécurité informatique (ITSEF) examine votre architecture, votre modèle de confiance et le statut de conformité de chaque composant dont dépend votre portefeuille.

La deuxième évaluation comprend des tests fonctionnels, des tests de pénétration et une évaluation des vulnérabilités par rapport aux fonctions de sécurité déclarées du portefeuille. Il ne s'agit pas d'une revue documentaire. Les testeurs sondent activement le système.

La maintenance se poursuit après la délivrance du certificat. Une surveillance annuelle est requise, incluant des tests de pénétration à chaque anniversaire. Ce n'est pas une case à cocher. C'est un coût d'évaluation récurrent intégré au cycle de vie du certificat.

Le certificat est valable 5 ans. Le plafond est strict. Le schéma précise qu'aucune dérogation n'est possible (p.26). À l'expiration du certificat, le portefeuille doit être désactivé. Il n'existe pas de délai de grâce à négocier.

L'obligation d'intégrité de l'information est plus exigeante que dans la plupart des cadres de conformité. Fournir des informations incorrectes ou incomplètes à l'organisme de certification est qualifié de non-conformité (au sens de défaut de respect des règles), et non de non-conformité technique (p.23-24). La distinction compte : la non-conformité technique déclenche un processus de remédiation. Le défaut de respect des règles peut entraîner une suspension ou un retrait sur des bases différentes.

Après notification d'une non-conformité, vous disposez de 30 jours pour évaluer si le constat est significatif (p.38). Ce délai ne commence pas lorsque vous découvrez le problème. Il commence lorsque l'organisme de certification vous notifie. Les organisations qui n'ont pas de processus de réception des notifications de conformité brûleront ce délai avant que quiconque ne lise l'e-mail.

La suspension est publique. Le schéma impose une divulgation publique obligatoire lorsqu'un certificat est suspendu (p.40). La durée maximale de suspension est de 42 jours, extensible à 1 an par l'autorité nationale de certification en cybersécurité (NCCA). Ce n'est pas une affaire interne. Vos clients et parties utilisatrices le verront.

La conservation des documents s'étend 5 ans au-delà de l'expiration du certificat, y compris les spécimens physiques de produits le cas échéant (p.49). Pour les produits logiciels sur un certificat de 5 ans, cela représente une chaîne de preuves d'au moins 10 ans.

Le modèle CRA exige une évaluation de la conformité avant la mise sur le marché et une gestion des vulnérabilités après la mise sur le marché. Le schéma pour le portefeuille exige une conformité continue avec des tests de pénétration annuels et une surveillance tout au long du cycle de vie du certificat. Pour les entreprises soumises aux deux, les obligations post-certification du schéma pour le portefeuille sont plus exigeantes que celles du CRA en termes de portée et de fréquence.

Votre chaîne d'approvisionnement est désormais dans la chaîne de certification

Le schéma pour le portefeuille utilise un modèle d'évaluation compositionnel à trois couches distinctes.

La WSCA (Wallet Secure Cryptographic Application) et sa plateforme matérielle sous-jacente sont évaluées sous EUCC, le schéma européen de Critères Communs. Cela couvre les modules de sécurité matériels, les éléments sécurisés et les environnements d'exécution de confiance dont dépend le portefeuille.

L'instance du portefeuille (le logiciel fonctionnant sur l'appareil de l'utilisateur) est évaluée sous FiTCEM, la méthode fonctionnelle d'évaluation commune en informatique, qui gère l'évaluation des logiciels là où la séparation matérielle n'est pas réalisable.

Les services du portefeuille (composants côté serveur, émission d'identité, interfaces avec les parties utilisatrices) sont évalués par rapport aux exigences CEN TS 18072.

Chaque couche possède son propre parcours d'évaluation. Votre certificat dépend des certificats qui le sous-tendent.

Le schéma est explicite sur la charge que cela impose aux demandeurs : vous devez « rassembler la documentation d'assurance pour ses composants, ce qui peut impliquer de les faire certifier » (p.14). « Peut impliquer » est en deçà de la réalité. Si un composant ne dispose pas de la documentation d'assurance requise, votre évaluation ne peut pas aboutir.

La divulgation des sous-traitants est exhaustive. Chaque sous-traitant doit être répertorié, ainsi que l'étendue de l'évaluation de conformité appliquée à leur contribution (p.78). Il n'existe pas de catégorie générique « nous utilisons des fournisseurs réputés ». Chaque tiers dispose soit de preuves de conformité documentées, soit non, et cette lacune est votre problème lors de l'évaluation.

Les notifications de vulnérabilités en amont sont obligatoires dans les deux sens. Lorsqu'une vulnérabilité affecte un produit TIC sous-jacent à un service TIC composite, le titulaire du certificat EUCC doit en informer les titulaires de certificats EUDIW dépendants (p.43). Il s'agit d'une obligation spécifique liée aux divulgations de vulnérabilités, et non d'une notification générale pour chaque modification de certificat. Si votre fournisseur de composants identifie une vulnérabilité et ne vous en informe pas, il est en infraction. S'il vous en informe, vous disposez d'un délai de 30 jours pour évaluer le caractère significatif de la situation.

La surveillance continue ne s'arrête pas à la frontière de votre organisation. Lorsqu'un certificat de composant de base est mis à jour ou remplacé, le CAB doit effectuer une analyse différentielle des dépendances sur les modifications apportées (p.84). Une mise à jour significative d'une dépendance déclenche une évaluation formelle du CAB pour déterminer si la portée de votre certification est affectée.

Les fournisseurs de cloud ne sont pas exemptés. Le schéma classe l'infrastructure « fournie par le prestataire » (p.61) comme un composant dans le périmètre de l'évaluation de la chaîne d'approvisionnement. Si votre service de portefeuille fonctionne sur une plateforme cloud, le statut de conformité de cette plateforme fait partie de votre dossier de preuves.

La règle de propagation est significative : si une correction de non-conformité est en attente dans le rapport de certification d'un composant de base, le CAB doit évaluer son impact sur le service TIC composite (p.84). Si cet impact est significatif, l'évaluation composite ne peut pas aboutir avant que la non-conformité soit résolue. Ce n'est pas automatique : cela dépend du fait que la non-conformité soit considérée comme significative pour votre service. Mais une non-conformité ouverte et sérieuse dans le rapport de certification de votre fournisseur de WSCA peut bloquer l'achèvement de votre évaluation.

Ce n'est pas un modèle hypothétique pour le CRA. L'obligation SBOM du CRA (annexe I, partie II) et les exigences de surveillance des vulnérabilités (articles 13 et 14) fonctionnent selon le même principe. Le schéma pour le portefeuille montre comment ces obligations opèrent en pratique dans un cadre de certification formel : documentées, bilatérales et bloquantes.

Important : Les règles de notification et de propagation dans la chaîne d'approvisionnement décrites ici s'appliquent au schéma de certification EUDIW. Les obligations parallèles du CRA se trouvent aux articles 13 et 14. La manière dont elles interagissent en pratique pour les produits soumis aux deux régimes n'est pas encore établie dans les orientations.

Pour la manière dont les obligations CRA relatives à la chaîne d'approvisionnement interagiront avec les futurs schémas de certification CSA, consultez Cybersecurity Act 2. Pour la mécanique pratique de la génération et de la maintenance des SBOM, consultez le guide de génération de SBOM.

Ce que valent réellement vos certifications existantes

La plupart des fabricants supposent que leurs certifications existantes ont du poids dans les nouveaux schémas. Pour EUDIW, la réponse dépend entièrement de la certification que vous détenez et de la rigueur avec laquelle votre auditeur a mis en correspondance son périmètre avec les critères du schéma.

Le schéma aborde cette question directement à la section 5.3. Il autorise les organismes d'évaluation de la conformité (CAB) à s'appuyer sur des travaux antérieurs, mais les conditions sont strictes. Une lettre de passerelle est requise lorsqu'il existe un écart entre la période de rapport de l'audit antérieur et l'évaluation en cours (p.85). La confiance partielle est courante ; la confiance totale est rare.

La conclusion sur ISO 27001 mérite une attention particulière. Le schéma indique clairement : « il ne fournit pas, à lui seul, une assurance suffisante que les contrôles individuels sélectionnés dans la déclaration d'applicabilité sont conçus et opèrent au niveau de rigueur exigé par ce schéma » (p.88).

Cette logique s'applique au-delà de l'EUDIW. La certification ISMS confirme la maturité des processus et l'existence d'un système de management. Elle ne confirme pas que les contrôles individuels fonctionnent au niveau d'assurance qu'un schéma spécifique exige. Le même raisonnement s'appliquera sous le CRA lorsque les normes harmonisées seront finalisées.

Si votre audit SOC 2 Type II a été délimité sans tenir compte des critères européens de cybersécurité, il ne sera pas admissible à une confiance conditionnelle. Vous aurez besoin d'une mise en correspondance vérifiée par votre auditeur. Prévoyez cette discussion maintenant, avant d'être dans un calendrier de certification.

Pour une comparaison plus approfondie de ce que couvre réellement ISO 27001 par rapport aux exigences du CRA, consultez notre guide de comparaison ISO 27001.

Important : Le schéma EUDIW est spécifique au contexte de l'infrastructure du portefeuille. Les normes harmonisées CRA pourront fixer des seuils différents pour ce que les certifications antérieures permettent de satisfaire. Considérez cette analyse comme indicative, non définitive.

La gestion des vulnérabilités va au-delà du CRA

Les exigences de gestion des vulnérabilités du schéma EUDIW s'appuient explicitement sur le CRA. Le schéma précise : « Cette section... s'inspire principalement d'autres réglementations, telles que l'article 55 du CSA... ainsi que du CRA » (p.43). Cette filiation importe car les exigences partagent une structure mais divergent sur les mécanismes.

Sur le SBOM : le schéma exige un format lisible par machine (p.43), aligné avec l'annexe I, partie II du CRA. Ce n'est pas un concept nouveau si vous suivez déjà les obligations du CRA, mais cela confirme que le SBOM comme artefact technique devient une attente de référence dans les schémas européens, pas seulement dans le cadre du CRA.

Les mises à jour de sécurité doivent être délivrées séparément des mises à jour fonctionnelles (p.43). Cela a une portée opérationnelle significative. Une version combinée qui corrige des vulnérabilités et ajoute des fonctionnalités crée une ambiguïté sur ce que les utilisateurs acceptent. Le schéma les traite comme des obligations distinctes.

Votre politique CVD doit être publique et alignée sur EN ISO/IEC 29147 (p.47). Il ne s'agit pas d'un document de politique enfoui dans un dossier de conformité. Elle doit être accessible, à jour et structurée selon la norme.

Sur l'analyse d'impact : les scores CVSS seuls sont insuffisants. Le schéma exige une analyse spécifique au contexte (p.44). Un CVSS 9,8 dans un contexte de déploiement peut correspondre à un CVSS 4,0 dans le vôtre, mais vous devez documenter ce raisonnement, pas seulement l'affirmer.

L'exigence la plus significative d'un point de vue opérationnel : une vulnérabilité significative sans voie de remédiation entraîne le retrait du certificat (p.45). Cela crée un lien direct entre votre rythme de correction et votre statut de certification. Le délai ne s'arrête pas à l'évaluation.

La comparaison avec le CRA est pertinente ici. Le CRA exige la notification à ENISA dans les 24 heures suivant la découverte d'une vulnérabilité activement exploitée. EUDIW utilise « sans retard injustifié » via la chaîne CAB. Horloge différente, acheminement différent, intention similaire. Si vous construisez des processus pour l'un, concevez-les pour satisfaire les deux.

Pour une analyse détaillée de l'obligation de notification dans les 24 heures, consultez notre article sur le signalement de vulnérabilités à ENISA. Pour un point de départ sur votre politique CVD, consultez le modèle de politique CVD.

Ce qui est confirmé et notre analyse

Cinq points à surveiller

Le schéma n'est pas définitif. La date limite de consultation du 30 avril signifie que des modifications sont encore possibles. Ce sont les domaines où le résultat affecte concrètement votre planification.

1. Exigences relatives au format des preuves : Le schéma fait référence aux SBOM lisibles par machine et à la structure des dossiers techniques, mais ne standardise pas entièrement ce qu'un format « suffisant » signifie en pratique. Les CAB interpréteront cela. En attendant, construisez vers le format le plus structuré que vous pouvez justifier.

2. Capacité des CAB : L'autorisation requiert à la fois une accréditation et l'accord de la NCCA, ainsi que la réalisation d'une évaluation pilote (p.30). Le problème d'amorçage est réel. Si les CAB qualifiés sont rares lorsque le schéma entre en vigueur, les délais glissent indépendamment de votre niveau de préparation. Cela n'est pas en votre pouvoir, mais cela affecte vos hypothèses de planification.

3. Reconnaissance mutuelle : Le schéma n'adopte pas les dispositions de reconnaissance mutuelle de l'EUCC pour les schémas de pays tiers (p.52). La reconnaissance mutuelle avec les pays tiers est explicitement laissée ouverte pour une phase ultérieure : « ces conditions pourront être ajoutées dans une phase ultérieure ». C'est une question non résolue, et non tranchée. Ne comptez pas sur le fait que vos certifications américaines seront reconnues, mais il s'agit d'une question ouverte et active plutôt que d'un rejet définitif.

4. Expiration des schémas nationaux : Les schémas nationaux existants disposent d'une fenêtre de 12 mois après l'entrée en vigueur pour rester valides (p.56). Si votre certification actuelle est délivrée sous un schéma national, comprenez quand cette fenêtre se ferme.

5. Questions ouvertes : La responsabilité des tests de pénétration, les seuils de niveau de potentiel d'attaque et les qualificatifs de profondeur pour l'analyse des vulnérabilités restent non résolus dans le texte actuel (p.97-98). Ce ne sont pas des lacunes rédactionnelles. Elles affectent la façon dont vous délimitez et budgétisez les évaluations.

Ce que nous savons avec certitude

• Le CRA est explicitement cité comme source pour les exigences du schéma.
• Le SBOM en format lisible par machine est obligatoire.
• ISO 27001 seul ne satisfait pas les exigences de contrôle organisationnel.
• L'auto-évaluation n'est disponible à aucun niveau d'assurance pour les composants EUDIW.
• La validité de la certification est plafonnée à 5 ans.

Notre analyse (non confirmée)

• Les schémas d'évaluation de la conformité CRA suivront vraisemblablement des modèles similaires sur les exigences SBOM, la politique CVD et l'insuffisance d'ISO 27001 pris isolément. Le schéma EUDIW donne un aperçu de la façon dont ENISA pense ces obligations.
• La pression de certification de la chaîne d'approvisionnement va augmenter. Les exigences au niveau des composants de l'EUDIW suggèrent que les fabricants en aval commenceront à exiger que les fournisseurs en amont détiennent des certifications indépendantes, et non de simples auto-déclarations.
• La mise en correspondance SOC 2 est une vraie opportunité. Si vous engagez votre auditeur maintenant pour structurer une mise en correspondance des critères avec les exigences européennes de cybersécurité, vous pourrez positionner votre prochain SOC 2 Type II pour une confiance conditionnelle plutôt que de repartir de zéro.

Ce que personne ne sait encore

• Quand un schéma de certification spécifique au CRA sera publié et à quoi ressemblera son calendrier de consultation.
• Quelles normes harmonisées seront désignées dans le cadre du CRA et quels seuils d'assurance elles fixeront.
• Comment la capacité nationale des CAB se développera par rapport à la demande lorsque plusieurs schémas seront actifs simultanément.

Ce que les fabricants devraient faire maintenant

La fenêtre de consultation et la publication finale du schéma vous donnent un délai défini pour vous préparer. Voici des étapes concrètes, pas des conseils généraux.

• Comprenez votre voie d'évaluation de la conformité. Les niveaux d'assurance du schéma correspondent à différentes catégories de produits. Ce qui s'applique à vous n'est pas toujours évident. Utilisez un processus de décision structuré avant de supposer que vous connaissez votre voie. Commencez par notre guide de décision sur l'évaluation de la conformité.

• Constituez vos preuves maintenant. Les SBOM, les évaluations des risques, les politiques de divulgation des vulnérabilités et les dossiers techniques prennent du temps à produire correctement. Commencer pendant la période de consultation signifie que vous pouvez itérer avant qu'un CAB ne les demande.

• Ne supposez pas qu'ISO 27001 vous couvre. Le schéma est explicite. Si votre posture de conformité repose sur ISO 27001 comme substitut à l'assurance de cybersécurité, vous avez une lacune. Identifiez les contrôles qui nécessitent une vérification indépendante.

• Structurez votre prochain SOC 2 en tenant compte de la mise en correspondance des critères européens. Si vous êtes en cours de renouvellement SOC 2, parlez à votre auditeur avant que le périmètre ne soit défini. Une mise en correspondance documentée des critères avec les exigences EUDIW (et à terme CRA) est ce qui fait passer un Type II d'une confiance partielle à une confiance conditionnelle.

• Suivez le processus de consultation. Le webinaire du 8 avril et la date limite de soumission écrite du 30 avril sont les derniers points d'entrée formels avant que le schéma n'avance vers sa finalisation. Si le schéma affecte vos produits, soumettez des commentaires ou surveillez au minimum les évolutions.

• Cartographiez votre chaîne d'approvisionnement. Identifiez quels composants en amont entrent dans le périmètre du schéma. Si un fournisseur ne peut pas démontrer la certification pour un composant que vous intégrez, cette lacune devient votre problème au moment de l'évaluation.

Comment CRA Evidence vous aide

CRA Evidence prend en charge l'infrastructure documentaire et processuelle que les évaluations EUDIW et CRA requièrent :

• Gestion des SBOM : Générez, stockez et exportez des SBOM dans des formats lisibles par machine alignés avec les exigences de l'annexe I, partie II du CRA.
• VDP avec flux de travail CVD : Publiez et gérez votre politique de divulgation des vulnérabilités avec un flux d'entrée et de réponse structuré aligné sur EN ISO/IEC 29147.
• Suivi des notifications ENISA : Suivez les fenêtres de notification de 24 heures, 72 heures et 14 jours avec des enregistrements prêts pour l'audit pour chaque notification.
• Portail fournisseurs : Gérez les notifications en amont et en aval au sein de votre chaîne d'approvisionnement, avec des preuves documentées de communication pour les dossiers techniques.

Découvrez ce que CRA Evidence couvre sur craevidence.com.

Cet article est fourni à titre informatif uniquement et ne constitue pas un conseil juridique. Pour des orientations spécifiques en matière de conformité, consultez un conseiller juridique qualifié.