De l’analyse d’écart CRA à l’évaluation de conformité — votre partenaire pour des produits sécurisés et conformes au marquage CE.
Nous accompagnons les fabricants, importateurs et distributeurs dans leur mise en conformité CRA tout au long du cycle de vie dès produits : Security by Design, Security by Default, gestion dès vulnérabilités, processus de signalement dès incidents et gestion robuste dès preuves.
Note : Le CRA exige des mesures de sécurité sur tout le cycle de vie du produit — pas uniquement à la mise sur le marché initiale.
Avec notre outil d'analyse des écarts CRA, évaluez en quelques minutes la maturité de vos produits face au Cyber Resilience Act – avec backlog de mesures priorisé, export JSON et rapport de direction. Directement dans le navigateur, sans inscription.
Statut : Enregistrement (déjà diffusé) · durée ~1:28h
Cette session parcourt le chemin entre exigences de sécurité, threat modeling et contrôles DevSecOps actionnables dans la pipeline.
Avec exemples concrets sur SAST, SCA, SBOM, quality gates, vérifications IaC et gestion continue des vulnérabilités.
Voir le webinaire sur YouTubeLe CRA regroupe les obligations produit, la gestion des vulnérabilités, la transparence de la chaîne d’approvisionnement et les obligations d’information vis-à-vis des utilisateurs en quatre piliers centraux.
Exigences produit
Gestion des vulnérabilités
Composants tiers & chaîne d’approvisionnement
Information minimale du fabricant
Les entreprises qui démarrent tôt bénéficient d’une meilleure transparence des risques, de processus de développement plus stables et d’un accès marché plus rapide. Une mise en œuvre tardive crée une forte pression projet et de preuve.
Sécuriser l’accès au marché
Piloter le risque de gouvernance
Efficacité par l’intégration
Les produits non-conformes risquent des restrictions de distribution. Une preuve robuste protège votre roadmap produit.
Des processus clairs pour reporting, mises à jour et remédiation réduisent significativement les risques réglementaires et opérationnels.
Lier ISMS, CSMS et processus de développement crée des synergies au lieu de bureaucratie supplémentaire.
Briques concrètes pour opérationnaliser cet avantage :
Recensement systématique des produits numériques, composants et dépendances — avec un SBOM lisible par machine.
Identification, évaluation et remédiation continues — les vulnérabilités activement exploitées doivent être notifiées sous 24 heures.
Capture structurée des mesures, évaluations de risques et preuves — la documentation technique doit être conservée au moins dix ans.
Les équipes développement et sécurité maîtrisent les 22 principes Secure-by-Design du playbook de l’ENISA ; la culture sécurité est ancrée.
Ces jalons définissent quand les entreprises doivent satisfaire pleinement et de façon démontrable leurs obligations techniques, organisationnelles et réglementaires pour des produits conformes au CRA.
Cliquez sur un jalon pour les détails.
Le reporting CRA n’est pas une simple extension de la gestion d’incidents interne — c’est une architecture réglementaire de délais. Les fabricants portent la charge de preuve et d’évaluation pour le déclencheur de notification.
Message clé :Les fabricants portent la charge de preuve et d’évaluation pour savoir quand un déclencheur de notification survient et quand le délai démarre — à partir du moment de la connaissance suffisante (certitude raisonnable de l’incident).
Des éléments fiables montrent qu’un acteur malveillant a exploité la vulnérabilité dans un système sans l’autorisation de son propriétaire.
Incident qui compromet la capacité du produit à protéger la disponibilité, l’authenticité, l’intégrité ou la confidentialité de données ou fonctions sensibles — ou qui introduit du code malveillant dans le produit ou les systèmes des utilisateurs.
Sans retard injustifié, au plus tard 24 heures après la prise de connaissance — en indiquant les États membres où le produit est mis à disposition.
Au plus tard 72 heures après la prise de connaissance : produit concerné, nature de l’exploitation ou de l’incident, mesures correctives et d’atténuation prises et recommandées.
14 jours après la mise à disposition d’une mesure corrective ou d’atténuation (vulnérabilité) ou un mois après la notification (incident).
Vulnérabilités activement exploitées et incidents graves. Les autres vulnérabilités, cybermenaces et quasi-incidents peuvent être notifiés volontairement.
Sans retard injustifié : alerte précoce sous 24 heures après la prise de connaissance, notification sous 72 heures, puis rapport final.
Via la plateforme unique de signalement de l’ENISA au CSIRT coordinateur de l’État membre de l’établissement principal — en Allemagne le CERT-Bund du BSI — et simultanément à l’ENISA.
Produits et versions concernés, nature et gravité, mesures prises et recommandées. Les utilisateurs concernés doivent en outre être informés.
Depuis le 11 septembre 2026, toutes les notifications CRA passent par la plateforme unique de signalement (SRP) de l’ENISA. Notre approfondissement montre comment tenir le délai de 24 heures de façon fiable — de l’accès au dossier de notification répété.
Les exigences essentielles s’appliquent à tous les produits — mises en œuvre selon une approche fondée sur les risques. Ce qui augmente avec la catégorie, c’est la profondeur de l’évaluation de la conformité. Classer correctement vos produits est donc la première étape décisive.
| Catégorie | Exemples produits | Ce qui compte | Voie d’évaluation |
|---|---|---|---|
| ● Standard | Disques durs, jeux, logiciels de retouche photo et de traitement de texte, robots aspirateurs, électroménager connecté | Satisfaire les exigences essentielles selon le risque ; documentation technique ; mises à jour pendant toute la période d’assistance | Auto-évaluation par le fabricant (contrôle interne, module A) |
| ● Important I | IAM/PAM, navigateurs, gestionnaires de mots de passe, VPN, routeurs, systèmes d’exploitation, produits domotiques dotés de fonctions de sécurité | Les mêmes exigences ; justifier la classification par la fonctionnalité principale, suivre l’état des normes | Auto-évaluation uniquement si des normes harmonisées ou une certification UE sont appliquées intégralement — sinon organisme notifié (module B+C ou H) |
| ● Important II | Pare-feu, IDS/IPS, hyperviseurs, runtimes de conteneurs, microprocesseurs et microcontrôleurs inviolables | Les mêmes exigences ; les preuves doivent résister à un examen externe | Toujours par un tiers : organisme notifié (module B+C ou H) ou certificat de cybersécurité de l’UE |
| ● Critique | Dispositifs matériels avec boîtiers de sécurité, passerelles smart-meter, cartes à puce et éléments sécurisés | Les mêmes exigences ; profondeur d’évaluation maximale et preuves complètes | Certificat européen de cybersécurité dès que la Commission l’impose — d’ici là, organisme notifié comme pour la classe II |
Recensement systématique dès produits numériques, composants et dependances. Base de toutes les mesures CRA ulterieures.
Identification, évaluation et correction continues dès vulnérabilités avec dès delais de réponse clairs conformément aux exigences CRA.
Saisie structuree dès mesures, évaluations dès risques et preuves de conformité – pret pour l'audit et conforme au marquage CE.
Le signalement CRA est une architecture de delais réglementaires. Les fabricants portent la charge de la preuve et de l'évaluation lorsqu'un declencheur de signalement survient et que le delai commence.
Efficacite par l'intégration : la liaison entre SMSI, CSMS et processus de développement créé dès synergies au lieu de bureaucratie supplementaire.
Les équipes de développement et de sécurité comprennent le Secure-by-Design. La culture de la sécurité est ancree – pour les développeurs, chefs de produit et dirigeants.
En collaboration avec JUN Légal, nous avons développé le CRA Navigator — un outil pour une première orientation fondee sur les exigences du EU Cyber Résilience Act.
Un chemin systématique de la première analyse à l’assurance permanente de conformité.
Recensement systématique dès produits numériques, composants et dependances.
Identification, évaluation et correction continues avec dès delais de réponse clairs.
Saisie structuree dès mesures, évaluations dès risques et preuves de conformité.
Les équipes de développement et de sécurité comprennent le Secure-by-Design ; la culture de la sécurité est ancree.
Création de la documentation technique, execution de l'évaluation de conformité et marquage CE par categorie de produit.
Choisissez votre rôle pour voir les exigences spécifiques et les priorités recommandées.
Démarrez par l’inventaire produit, le rating de risque et la base SBOM. Ensuite durcissement SSDLC, voies de remontée d’incidents et processus de release formalisés.
Demander conseilVotre stratégie de conformité dépend directement de votre catégorie de produit et de la voie d’évaluation requise.
De l’analyse d’écart à l’accompagnement à la certification — nous vous accompagnons dans chaque phase.
Inventaire, évaluation des écarts et roadmap priorisée pour une mise en œuvre CRA prête à l’audit.
Identification, priorisation et remédiation continues des failles de sécurité sur tout le cycle de vie produit.
Intégration du CSMS dans les structures de gouvernance existantes pour conformité durable et moins de surcharge administrative.
Security by Design en architecture, développement, test et opérations avec des security gates clairs. Une boucle avec maintenance et amélioration continues.
Préparation des dossiers de preuves pour CRA, IEC 62443 et ISO/SAE 21434 — incluant simulation d’audit interne et revue management.
Un Software Bill of Materials (SBOM) liste les composants et dépendances comme une liste d’ingrédients. Pour le CRA, c’est une brique de transparence centrale : SPDX et CycloneDX couvrent les exigences usuelles.
Software Package Data Exchange — exhaustif, format flexible et établi à l’échelle de l’industrie.
Format SBOM orienté sécurité avec forte intégration CI/CD pour pipelines de vulnérabilités.
Détecter, évaluer et prioriser les risques dans paquets, dépendances et licences — incluant le mapping vers les CVE connues.
Conformité fluide dans la pipeline : intégration avec GitHub, GitLab, Jenkins et autres, pour que les SBOMs voyagent avec les builds.
Refléter des arbres produit complexes (p.ex. dispositif → sous-systèmes → firmware/composants) pour une visibilité scalable.
Comment ENISA structure les principes de sécurité contraignants du Cyber Resilience Act en deux piliers clairs. Quatre catégories, 22 exigences concrètes.
Chacun des 22 playbooks contient : objectif · checklist · preuves minimales · release gate — structuré pour petites équipes sans spécialistes sécurité dédiés. TLP-CLEAR, librement accessible sur
enisa.europa.euLes mécanismes de protection sont intégrés pendant le développement — pas ajoutés après. Deux catégories :
Les produits sont livrés avec la configuration la plus sécurisée possible — les utilisateurs n’ont pas besoin d’expertise technique pour la sécurité de base. Deux catégories :
Pour chaque phase du cycle de vie, le playbook définit des mesures concrètes et une preuve minimale — pour que la sécurité reste démontrable même dans de petites équipes.
| Phase | Actions clés | Preuve |
|---|---|---|
| Exigences | Définir contexte produit (utilisateurs, environnements, données), defaults sécurité non-négociables, top risques et scénarios d’abus | Security Context & Assumptions (1 page) + checklist exigences sécurité |
| Conception | Diagramme d’architecture avec frontières de confiance, threat model léger pour les top 5–10 cas d’abus, contrôles de design critiques | Architecture + diagramme frontières de confiance + top menaces & contre-mesures |
| Développement | Defaults sécurisés en code/config, hygiène des dépendances, protection des secrets, SAST/SCA automatisés en CI/CD, revues PR pour changements critiques | Preuve pipeline CI (logs) + checklist secure-coding/PR |
| Test | SAST/DAST automatisés, valider la configuration par défaut, test de pénétration ciblé sur changements substantiels | Checklist sécurité release (pass/fail + exceptions) |
| Déploiement | Provisioning sécurisé, configuration runtime à moindre privilège, monitoring santé sécurité, mises à jour comme change management contrôlé | Checklist durcissement déploiement + plan de rollback |
| Maintenance | SLA de patching, monitoring des vulnérabilités, gestion d’incidents, plan EOL, suppression sécurisée des données et révocation des credentials | Processus vulnérabilités et patchs (1 page) + note EOL + risk register à jour |
Le playbook ENISA décrit ce qu’il faut implémenter — VamiSec vous accompagne sur le comment : structuré, efficace, avec des artefacts démontrables pour audits, conformité CE et autorités.
La standardisation européenne est décisive pour la mise en œuvre du CRA et la gestion des preuves.
Standards inter-sectoriels et exigences de base pour produits et services dans le marché unique numérique.
Exigences techniques de sécurité pour composants électroniques, équipements et environnements industriels.
Standards réseau et communication pour infrastructure numérique, interfaces et protocoles de sécurité.
Les obligations produit du CRA (Annexe I, chaîne d’approvisionnement, voies de notification) se mappent directement sur les structures IEC 62443 / ISO/SAE 21434 — idéal pour audits intégrés avec moins de duplication.
Le CSMS pilote le cycle de vie produit et imbrique le CRA avec ISMS, protection des données et autres réglementations. Une mise en place selon IEC 62443-2-1 et ISO/SAE 21434 chap. 5 prépare les preuves de conformité.
Les Security Champions ne sont pas un service sécurité de remplacement — ils sont des advocates et le premier point de contact dans l’équipe, avec des liens clairs vers NIS2, le CRA et (pour dispositifs médicaux) le MDR.
Dans l’équipe : Sécurité dans les sprints, revues code et design, formation et sensibilisation.
Dans l’organisation : Traduire les exigences, feedback et reporting, remonter les risques, animer la communauté des champions.
Les entreprises qui ne traitent pas le CRA, NIS2 et l’AI Act de façon isolée mais les transposent dans un système de management intégré gagnent en efficacité, en auditabilité et en résilience.
Formations compactes et adaptables sur exigences CRA, rôles, Secure-by-Design, SBOM, threat modeling, chaîne d’approvisionnement et responsabilité — avec des templates pratiques utilisables directement.
Planifier une sessionUne approche harmonisée de la conception produit aux opérations réduit les efforts redondants, améliore l’efficacité d’audit et crée des preuves cohérentes à travers plusieurs réglementations.
Programme journalier : SSDLC, Conformité et Threat Modeling pour fabricants, importateurs et distributeurs.
Templates prêts à l’emploi — à vous à la fin de la journée.
Classification claire de vos produits sous le CRA.
Ordonnancement basé sur les risques pour le portefeuille.
Plan concret pour développement & product management.
Optionnel pour les équipes avec contexte MDR/SaMD : analyse de menaces structurée avec cadrage réglementaire (MDR Annexe I / GSPR, ISO 14971, IEC 62304, IEC 81001-5-1). Les dispositifs médicaux relevant du MDR/IVDR sont exclus du CRA — ses principes Secure-by-Design restent une référence utile.
Le Threat Modeling relie Safety, Security et Compliance : architecture traçable, frontières de confiance et preuves pour audits et organismes notifiés.
Architecture, interfaces (cloud, app, IT clinique), flux de données, actifs importants.
Confidentialité, intégrité, disponibilité ; mapping vers la sécurité patient.
Notamment STRIDE, scénarios d’abus, chaîne d’approvisionnement.
Probabilité d’occurrence et impact ; lien avec ISO 14971.
Secure boot, authentification, chiffrement, logging, mises à jour sécurisées.
Traçabilité, dossier de risque, documentation technique, preuves d’audit.
64 contrôles, 8 catégories, 3 niveaux de maturité — automatiquement mappés sur l'annexe I du CRA, NIS2, ISO/IEC 18974, SSDF et SLSA. Un framework, un langage, une posture vérifiable.
L'OpenSSF OSPS Baseline est un ensemble d'exigences de sécurité concrètes qu'un projet open source devrait remplir pour démontrer une posture de sécurité solide. Au lieu de bonnes pratiques vagues : 64 énoncés MUST vérifiables — organisés par catégorie et niveau de maturité, mappés sur les frameworks externes pertinents.
Chaque contrôle est formulé comme un MUST, avec exigence, recommandation et attribution concrète à un niveau de maturité. De la MFA obligatoire sur les actions sensibles du repo à l'obligation de manifeste de release signé — tout est vérifiable, ancré dans la revue de code, le CI/CD ou la documentation.
CRA, NIS2 et SSDF parlent de software supply chain — mais pas dans le langage des mainteneurs. L'OSPS Baseline traduit : que signifie « signed releases » concrètement dans le repo ? Qu'est-ce qu'une « CVD policy with timeframe » ? Quel niveau de maturité est approprié pour mon projet ?
La Baseline organise ses contrôles en huit domaines couvrant le cycle de vie d'un projet open source. Chaque domaine adresse une classe concrète de menaces — et chacun s'applique sur les trois niveaux de maturité.
MFA, moindre privilège, branch protection.
Pipelines, signatures, secrets, SBOM.
Guides utilisateur, vérification, support.
Rôles, contributions, vetting des reviewers.
Licences OSI, DCO/CLA, clarté IP.
Status checks, tests, sous-projets.
Documentation de design, threat modeling, API.
CVD, VEX, SCA, politiques SAST.
La Baseline définit trois niveaux de maturité. Chaque niveau s'ajoute au précédent et reflète la responsabilité qu'un projet porte envers ses consommateurs. Qui atteint L3 atteint automatiquement L1 et L2.
« Le niveau de maturité n'est pas une note — c'est la réponse à la question : combien de responsabilité un projet porte-t-il envers ses consommateurs ? »
OSPS Baseline · Maintainer Guidance
L'OpenSSF Baseline est explicitement mappée sur les frameworks globaux — vous documentez une fois, livrez plusieurs fois.
Astuce d'initié : Si votre fournisseur atteint L2, vous avez déjà l'essentiel de la preuve fournisseur CRA en poche.
La Baseline est une mesure, pas un outil. VamiGRC la rend mesurable : chaque contrôle est stocké comme profil OSCAL, des ancres de preuve sont posées, les gap findings sont suivis dans le risk register — et la couverture cross-framework est calculée automatiquement.
VamiAudit vérifie le dépôt, la configuration CI/CD, la documentation et la pipeline de release par rapport à la baseline. Les findings atterrissent dans le risk register avec owner et SLA — pas d'Excel.
Chaque exigence baseline résolue satisfait simultanément les clauses CRA, NIS2, SSDF et ISO. La matrice de couverture le montre prêt pour l'audit — implement once, satisfy many.
Branch protection, releases signées, SBOM, statut SAST — tout est extrait en continu du repo et de la pipeline, classifié et rendu visible sur la page trust center.
Ein Ansprechpartner. Zwei Expertisen. Von der technischen Produktprüfung bis zum Cyber Security Management System — alles aus einer Hand.
Begleitet Sie persönlich durch Ihre CRA-Compliance — technisch wie organisatorisch.
Technische Prüfung Ihrer Produkte entlang des gesamten Entwicklungszyklus — vom Design bis zur Konformitätsbewertung nach CRA.
Aufbau tragfähiger Security-Strukturen im Unternehmen — vom Managementsystem bis zu den Meldepflichten gemäß CRA.
De l'analyse dès ecarts CRA a l'évaluation de conformité – votre partenaire pour dès produits sécurisés et conformes au marquage CE. Reservez dès experts CRA maintenant.
Prendre rendez-vous
