# Référence CRA > Le référentiel public sur le règlement (UE) 2024/2847 : périmètre et obligations, nomenclatures logicielles (SBOM), licences open source, traitement des vulnérabilités et sécurité de la chaîne d'approvisionnement. Un cadre commun, deux parcours — Juridique et Cybersécurité. This file gathers every page of the site, grouped by language and ordered by URL. Shorter index: https://cra-reference.eu/llms.txt --- # Français (fr) ## À propos de ce site URL: https://cra-reference.eu/fr/a-propos/ Description: Objet, périmètre, gouvernance éditoriale, avertissement juridique, principes techniques et mentions légales. Audience: transverse Published 2026-08-19, updated 2026-08-20 ### Objet **Référence CRA** est un référentiel public sur le règlement (UE) 2024/2847 sur la cyberrésilience, les nomenclatures logicielles (SBOM), les licences open source et la sécurité de la chaîne d'approvisionnement. Il s'adresse à deux publics dont les obligations sont distinctes mais indissociables : le **Juridique / Conformité** et la **Cybersécurité / DevSecOps**, ainsi qu'à la **Direction** pour les arbitrages. ### Avertissement > Ce site est un **contenu d'information**. Il **ne constitue pas un avis juridique**. > > Seul le texte du **règlement (UE) 2024/2847 publié au *Journal officiel de l'Union > européenne*** fait foi. Les numéros d'articles et d'annexes cités ici doivent être vérifiés > contre le texte consolidé avant tout usage opposable, et les pages de la section > réglementaire doivent être relues par le conseil juridique avant d'être opposées à un tiers. > > Trois sujets restent ouverts et peuvent rendre certaines pages obsolètes : les **normes > harmonisées**, les **actes délégués et d'exécution** de la Commission, et la **désignation > des autorités nationales**. Voir [Veille réglementaire](/fr/actualites/). > > Les noms d'outils et de solutions cités le sont à titre d'illustration de catégories > techniques. Aucune recommandation commerciale n'est faite, et aucune information de marché > n'est garantie à jour. ### Périmètre **Ce que le site couvre :** le cadre réglementaire du CRA, le SBOM comme objet technique et juridique, la traduction en obligations pour chaque équipe, et votre organisation cible. **Ce qu'il ne couvre pas :** la sécurité opérationnelle de vos systèmes d'information (qui relève de NIS 2 et du système de management de la sécurité), la protection des données personnelles, et la conformité sectorielle des produits exclus du champ du CRA. ### Gouvernance éditoriale | Section | Propriétaire | | --- | --- | | [Le cadre CRA](/fr/cra/) | Direction juridique | | [Parcours Juridique](/fr/legal/) | Direction juridique | | [Le SBOM](/fr/sbom/) | RSSI | | [Parcours Cyber](/fr/cyber/) | RSSI | | [Outils](/fr/outils/) | RSSI | | [Organisation](/fr/organisation/) | Sponsor exécutif | | [Direction](/fr/direction/) | Sponsor exécutif | | Sections transverses | Comité CRA | **Rythme de revue :** - **Trimestriel** pour l'ensemble des pages de la section réglementaire ; - **Immédiat** à chaque publication d'un acte délégué, d'un acte d'exécution ou d'une norme harmonisée citée au *Journal officiel* ; - **Annuel** pour les autres pages. Chaque page affiche sa **date de dernière revue** et sa **fonction propriétaire**. Une page dont la date de revue est trop ancienne doit être signalée : c'est un défaut, pas un détail. ### Règle éditoriale Une notion réglementaire n'est définie **qu'une seule fois**, dans la section [Le cadre CRA](/fr/cra/) ou [Le SBOM](/fr/sbom/). Les parcours métier n'en font que des lectures orientées, avec un lien vers la page canonique. C'est ce qui empêche les deux parcours de diverger, et c'est la règle la plus facile à enfreindre. ### Principes techniques Ce site est construit selon quelques partis pris explicites : - **entièrement statique**, sans serveur applicatif ni base de données ; - **aucune dépendance JavaScript côté client**, hormis le script de partage en amélioration progressive ; - **une seule requête vers un domaine tiers** dans les pages, celle de la mesure d'audience décrite dans les mentions légales ; toute autre fait échouer le build ; - **bilingue français / anglais**, avec appariement strict des pages ; - **imprimable** : les listes de contrôle et les fiches réflexes sortent proprement en A4, car elles seront utilisées hors ligne, y compris en cellule de crise ; - **accessible** : contraste, navigation au clavier, structure de titres, lien d'évitement. Un index destiné aux agents et moteurs d'intelligence artificielle est publié à [`/llms.txt`](/llms.txt), et l'intégralité du contenu à [`/llms-full.txt`](/llms-full.txt). ### Signaler une erreur Une erreur factuelle, un lien mort, une page obsolète : voir [Contact](/fr/contact/). Les corrections sur les pages réglementaires sont prioritaires. ### Mentions légales **Éditeur.** Ressource documentaire indépendante, éditée à titre non professionnel et sans finalité commerciale. En application de l'article 6 de la loi pour la confiance dans l'économie numérique, les éléments d'identification de l'éditeur sont détenus par l'hébergeur et communicables à l'autorité judiciaire sur réquisition. **Contact éditorial.** `contact@cra-reference.eu` **Hébergement.** Cloudflare, Inc., 101 Townsend Street, San Francisco, CA 94107, États-Unis. **Données personnelles.** Ce site ne demande aucune inscription, ne dépose aucun cookie et n'utilise aucun stockage dans le navigateur. La fréquentation est mesurée par Cloudflare Web Analytics : chaque page charge un script depuis `static.cloudflareinsights.com`, qui remonte l'URL consultée, la page de provenance, le type de navigateur et des temps de chargement. Cette requête expose l'adresse IP du visiteur à Cloudflare — ce que fait déjà l'hébergement du site : la mesure n'ajoute aucun destinataire. Elle ne pose ni cookie ni identifiant individuel et ne permet aucun suivi d'un site à l'autre. Aucune bannière de consentement n'est affichée, la mesure se limitant à des statistiques d'usage agrégées. **Accessibilité.** Ce site vise la conformité au RGAA et à la norme EN 301 549. Toute difficulté d'accès peut être signalée via la page [Contact](/fr/contact/). **Propriété intellectuelle.** Les contenus sont mis à disposition à des fins d'information. Les extraits du règlement (UE) 2024/2847 relèvent du régime de réutilisation des documents de l'Union européenne. Les noms d'outils et de produits cités appartiennent à leurs titulaires respectifs. ## Veille réglementaire URL: https://cra-reference.eu/fr/actualites/ Description: Ce qui bouge encore : normes harmonisées, actes délégués et d'exécution, désignation des autorités nationales. Le mécanisme qui empêche ce site de devenir faux. Audience: transverse Published 2026-08-19, updated 2026-08-19 Un référentiel réglementaire non entretenu devient faux sans prévenir. Cette page décrit **ce qui est susceptible de changer**, **où le vérifier**, et **ce qu'il faut faire quand cela change**. ### Les trois sujets ouverts #### 1. Les normes harmonisées **Enjeu :** elles conditionnent la **présomption de conformité** et, pour les produits de classe I, la possibilité même de s'auto-évaluer. **Où suivre :** travaux du comité technique mixte **CEN/CENELEC JTC 13, groupe de travail 9**, en réponse à la demande de normalisation **M/606** ; et surtout la **citation des références au *Journal officiel de l'Union européenne***, qui seule produit l'effet juridique. **Ce qui change quand une norme est citée :** la voie du module A s'ouvre pour les produits de classe I couverts, sous réserve d'une application **intégrale**. Les pages [Classes de criticité](/fr/cra/classes-de-criticite/), [Classe I](/fr/cra/classes-de-criticite/important-classe-1/) et [Évaluation de la conformité](/fr/cra/evaluation-de-conformite/) doivent être revues, et le scénario d'évaluation de chaque produit concerné réexaminé. #### 2. Les actes délégués et d'exécution de la Commission **Enjeu :** ils peuvent modifier le périmètre et les modalités. | Acte attendu | Effet | | --- | --- | | **Actualisation des annexes III et IV** | Un produit peut changer de classe, ou entrer dans une classe | | **Spécification du format et des éléments du SBOM** | Votre format et votre niveau de détail deviennent contraints | | **Obligation de certification** pour des catégories de produits critiques | Passage à une évaluation de type EUCC | | **Spécifications communes** | Voie alternative de présomption en l'absence de norme | | **Formulaire simplifié** de dossier technique pour les petites entreprises | Allègement documentaire | **Ce qu'il faut faire :** à chaque publication, évaluer l'impact sur le **registre de classification** et sur les pages concernées, puis produire une note d'impact au comité. #### 3. La mise en œuvre nationale **Enjeu :** savoir à qui s'adresser, dans quelle langue, par quel canal. **Points à suivre :** désignation des **autorités de surveillance du marché** et des **CSIRT coordinateurs** par les États membres ; **régimes de sanctions** nationaux ; modalités pratiques de la **plateforme de signalement unique** de l'ENISA ; **accréditation des organismes notifiés** et portée exacte de leur notification dans la base NANDO. **Ce qu'il faut faire :** tenir à jour, par État membre où vos produits sont mis à disposition, l'autorité compétente et le canal de signalement. ### Les sources à suivre | Source | Ce qu'on y trouve | Fréquence de consultation | | --- | --- | --- | | **[EUR-Lex — le règlement](https://eur-lex.europa.eu/eli/reg/2024/2847/oj)** | Texte consolidé, actes délégués et d'exécution | Mensuelle | | ***[Journal officiel de l'Union européenne](https://eur-lex.europa.eu/oj/direct-access.html)*** | **Citation des normes harmonisées** | Mensuelle | | **[Commission européenne, page CRA](https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act)** | Orientations, FAQ, calendrier | Mensuelle | | **[ENISA](https://www.enisa.europa.eu/)** · **[EUVD](https://euvd.enisa.europa.eu/)** | Plateforme de signalement, base de vulnérabilités, documents techniques | Mensuelle | | **[CEN / CENELEC](https://www.cencenelec.eu/)** JTC 13 | Avancement des normes | Trimestrielle | | **[Organismes notifiés](https://single-market-economy.ec.europa.eu/single-market/goods/building-blocks/notified-bodies_en)** (base NANDO) | Organismes désignés et portée de leur notification | Trimestrielle | | **[ANSSI](https://cyber.gouv.fr/)** · **[CERT-FR](https://www.cert.ssi.gouv.fr/)** | Mise en œuvre nationale, alertes | Mensuelle | > **Ce qui n'est pas une source.** Billets de blog d'éditeurs, livres blancs commerciaux, > synthèses non vérifiées. Ils contiennent des erreurs récurrentes, notamment sur les classes > de criticité et sur le statut de l'open source. Toute affirmation reprise en interne doit > pouvoir être rattachée à un article, une annexe ou un acte publié. ### Le processus de veille 1. **Consultation mensuelle** des sources par la direction juridique. 2. **Note d'impact** lorsqu'un élément change : que dit le nouvel élément, quelles pages sont concernées, quelle action est requise, dans quel délai. 3. **Mise à jour des pages** concernées, avec actualisation de leur date de revue. 4. **Point en comité CRA** trimestriel : ce qui a changé, ce que vous avez fait. 5. **Réexamen des registres** de classification et de support si le changement les affecte. ### Étiquetage des entrées Chaque entrée du fil de veille porte une ou plusieurs étiquettes : - **impact Legal** — modifie une obligation documentaire ou contractuelle - **impact Cyber** — modifie une exigence technique ou un outillage - **impact calendrier** — modifie une échéance ou un chemin critique - **action requise** — appelle une décision, par opposition à une simple information ### Journal des révisions du site | Date | Objet | Pages touchées | | --- | --- | --- | | 19 août 2026 | Publication initiale du référentiel | Toutes | Ce tableau est tenu à jour à chaque révision significative. Il permet de savoir **ce que l'organisation savait, et depuis quand** — information utile en cas de contrôle. ## Cas pratiques URL: https://cra-reference.eu/fr/cas-pratiques/ Description: Dix scénarios déroulés de bout en bout : la question côté Juridique, la question côté Cyber, la décision, la preuve produite et l'enseignement. Audience: transverse Published 2026-08-19, updated 2026-08-19 Chaque cas suit la même trame : la situation, la question de chaque équipe, la décision, la preuve produite, l'enseignement. ### Cas 1 — Une vulnérabilité critique touche douze de vos produits **Situation.** Une vulnérabilité est publiée sur une bibliothèque très répandue. Votre plateforme identifie en dix minutes douze produits affectés, dont quatre en version encore supportée chez des clients. **Juridique :** y a-t-il exploitation active ? Si oui, le délai de 24 heures court. **Cyber :** quelles versions exactement, quels clients, le code vulnérable est-il atteignable ? **Décision.** Pas de preuve d'exploitation active à ce stade → **pas d'obligation de signalement**, mais traitement en urgence selon les SLA, VEX pour les produits où le code n'est pas atteignable, et surveillance renforcée des indices d'exploitation. **Preuve.** Entrée au registre motivant l'absence de signalement, journal de traitement, VEX, avis de sécurité à la publication du correctif. **Enseignement.** Sans SBOM centralisé, l'étape « quels produits sont affectés » aurait pris plusieurs semaines — et le délai de 24 heures aurait été manqué si l'exploitation avait été constatée entre-temps. --- ### Cas 2 — Un chercheur vous signale une faille un vendredi soir **Situation.** Un courriel arrive sur l'adresse PSIRT à 19 h le vendredi, décrivant une vulnérabilité exploitable à distance, avec une preuve de concept. **Juridique :** est-ce une exploitation active ? Une preuve de concept fournie par un chercheur **n'est pas** une exploitation dans la nature. **Cyber :** la faille est-elle réelle, quelles versions, quel contournement immédiat ? **Décision.** Accusé de réception dans les délais de la politique CVD, qualification sous sept jours, **pas de signalement CRA** en l'absence d'exploitation active, coordination de la date de publication avec le chercheur. **Preuve.** Registre CVD, accusé de réception, échanges avec le chercheur, avis publié, remerciement. **Enseignement.** La politique CVD absorbe ce cas sans mobiliser l'astreinte. Sans elle, le courriel serait resté sans réponse jusqu'au lundi, et le chercheur aurait pu publier. --- ### Cas 3 — Un client exige votre SBOM dans un appel d'offres **Situation.** Un grand compte demande, en pièce obligatoire, un SBOM au format SPDX pour la version qui lui sera livrée. **Juridique :** que révèle ce document, sous quelles conditions le communiquer ? **Cyber :** votre format pivot est CycloneDX ; la conversion perd-elle des informations ? **Décision.** Fourniture sous accord de confidentialité, via le portail authentifié, accompagnée des VEX. Conversion documentée, avec mention des pertes connues. **Preuve.** Décision de diffusion, clause contractuelle, trace de la remise. **Enseignement.** La question de la diffusion doit être tranchée **avant** l'appel d'offres — voir [Diffusion et confidentialité](/fr/sbom/diffusion-et-confidentialite/). La traiter dans l'urgence conduit à sur-promettre. --- ### Cas 4 — Un composant open source critique est abandonné **Situation.** Le mainteneur unique d'une bibliothèque présente dans trois de vos produits annonce qu'il cesse la maintenance. **Juridique :** vos périodes de support courent encore trois ans sur ces produits. **Cyber :** remplacer, forker, ou internaliser ? **Décision.** Fork et maintenance interne pour la durée résiduelle du support, avec provision budgétaire ; remplacement planifié sur la prochaine version majeure. **Preuve.** Décision documentée au registre des risques, mise à jour du registre des périodes de support, plan de remplacement. **Enseignement.** Le critère « durée de support amont » doit figurer dans la grille de diligence **à l'intégration**, pas être découvert trois ans plus tard. --- ### Cas 5 — Vous voulez intégrer une bibliothèque AGPL dans une offre en ligne **Situation.** Une équipe propose une bibliothèque sous AGPL pour accélérer un développement. **Juridique :** la mise à disposition via un réseau déclenche l'obligation de fournir le source de l'œuvre dérivée aux utilisateurs du service. **Cyber :** existe-t-il une alternative sous licence permissive ? **Décision.** Refus, avec proposition d'une alternative. Si aucune n'existe : isolation stricte dans un service séparé, ou négociation d'une licence commerciale avec l'auteur. **Preuve.** Blocage en CI, ticket, décision au registre des exceptions. **Enseignement.** La politique de licences doit être **appliquée par la chaîne de construction**, pas seulement publiée. Un blocage automatique évite un débat trois mois plus tard, quand le code est écrit. --- ### Cas 6 — Vous lancez un nouveau produit : quelle classe ? **Situation.** Un nouveau produit intègre une fonction de gestion des accès et un moteur de rendu web embarqué. **Juridique :** deux catégories de l'annexe III, partie I, sont en cause. **Cyber :** le moteur de rendu est-il exposé à du contenu distant non maîtrisé ? **Décision.** **Classe I**. Deux scénarios d'évaluation instruits en parallèle : auto-évaluation si les normes harmonisées sont publiées et citées à temps, recours à un organisme notifié sinon — ce dernier retenu comme scénario de référence. **Preuve.** Fiche de classification co-signée, versée au dossier. **Enseignement.** La classification se fait **au lancement du développement**, pas avant la mise sur le marché : elle détermine le budget et le planning. --- ### Cas 7 — Une autorité demande le dossier d'un produit vendu il y a quatre ans **Situation.** Une autorité de surveillance du marché d'un autre État membre demande le dossier technique de la version 3.1.4, mise sur le marché quatre ans plus tôt. **Juridique :** délai imparti, interlocuteur unique, gel des preuves. **Cyber :** retrouver le SBOM signé, vérifier sa signature, produire les VEX et les journaux de l'époque. **Décision.** Application de la [fiche réflexe](/fr/cra/surveillance-du-marche/), réponse dans le délai, sans reconstitution de documents. **Preuve.** Le dossier tel qu'il existait, plus le registre des échanges. **Enseignement.** Ce cas ne se prépare pas au moment où il arrive. Il se prépare par l'**exercice annuel de restitution** — voir [Conservation des preuves](/fr/legal/conservation-des-preuves/). --- ### Cas 8 — Un fournisseur refuse de fournir un SBOM **Situation.** Un fournisseur de composant commercial refuse, invoquant le secret des affaires. **Juridique :** votre obligation d'inventaire ne disparaît pas ; le contrat doit être renégocié. **Cyber :** pouvez-vous produire l'inventaire par analyse de l'artefact livré ? **Décision.** Trois options, dans cet ordre : négocier une fourniture sous accord de confidentialité ; à défaut, produire un **Analyzed SBOM** par vos propres moyens et documenter la limite ; à défaut, planifier le remplacement du composant. **Preuve.** Trace de la demande et du refus, SBOM produit par analyse avec déclaration de complétude partielle, décision au registre des risques. **Enseignement.** La déclaration de complétude du SBOM sert précisément à cela : dire honnêtement ce que l'inventaire couvre. Un inventaire partiel déclaré comme tel vaut mieux qu'un inventaire partiel présenté comme complet. --- ### Cas 9 — Quelle période de support pour un produit embarqué à longue durée de vie ? **Situation.** Un équipement industriel dont la durée de vie physique attendue est de quinze ans. **Juridique :** la période de support doit refléter la durée pendant laquelle le produit est censé être utilisé — soit potentiellement quinze ans. **Cyber :** pouvez-vous garantir des correctifs pendant quinze ans, sur une plateforme matérielle dont le fournisseur de puce arrêtera le support avant ? **Décision.** Analyse des composants limitants, négociation d'un support étendu auprès du fournisseur de plateforme, et détermination d'une période de support **justifiée et documentée** — inférieure à la durée de vie physique si les composants ne suivent pas, avec information explicite de l'acheteur. **Preuve.** Justification au dossier technique, mention à l'acheteur, registre. **Enseignement.** La période de support n'est pas une décision commerciale libre : elle doit être **justifiée**. Et sa justification révèle souvent que vos fournisseurs ne suivent pas. --- ### Cas 10 — Une exploitation constatée chez un seul client **Situation.** Un client signale des indicateurs de compromission concordants exploitant une vulnérabilité de votre produit. Aucun autre client n'est affecté à votre connaissance. **Juridique :** une exploitation constatée chez **un seul** client suffit à caractériser l'exploitation active. **Cyber :** vérifier les indicateurs, établir le périmètre, préparer un contournement. **Décision.** **Signalement.** Alerte précoce sous 24 heures, information de l'ensemble des utilisateurs de la version affectée, contournement publié, correctif selon le SLA d'urgence. **Preuve.** Registre, accusés de la plateforme, communication aux utilisateurs, avis publié. **Enseignement.** Il n'existe pas de seuil de nombre de victimes. Un client suffit. C'est le cas qui doit être présent à l'esprit de l'astreinte, car l'intuition pousse à attendre « d'en savoir plus ». ## Contact URL: https://cra-reference.eu/fr/contact/ Description: Une seule adresse : signaler une erreur, proposer un contenu, poser une question — et ce que ce site ne fait pas. Audience: transverse Published 2026-08-19, updated 2026-08-20 **`contact@cra-reference.eu`** Une seule adresse, pour tout. Précisez l'objet en début de message, cela suffit à router. ### Signaler une erreur — le message le plus utile Une référence d'article inexacte, une date fausse, un lien mort, une page dont la date de dernière revue est trop ancienne. C'est la sollicitation que nous traitons en **priorité**, et de loin. Une erreur juridique dans un référentiel public se propage : elle est recopiée dans des notes internes, citées en réunion, reprises dans des appels d'offres. La corriger vite vaut mieux que tout le reste. Précisez, si possible : l'adresse de la page, le passage concerné, ce qui vous paraît inexact, et votre source. Les corrections portant sur [Le cadre CRA](/fr/cra/) passent devant. ### Proposer un contenu Un cas pratique vécu, une question fréquente qui manque, un scénario de distribution que la matrice de licences ne couvre pas, un incident à documenter. Les [cas pratiques](/fr/cas-pratiques/), la [FAQ](/fr/faq/) et les [incidents de référence](/fr/cyber/incidents/) sont alimentés par des situations réellement rencontrées. C'est ce qui les rend utiles. ### Poser une question Avant d'écrire, deux réflexes qui répondent à la plupart des questions : la [FAQ](/fr/faq/), qui en couvre une quarantaine, et le [glossaire](/fr/glossaire/). Si votre question porte sur un point que le site traite mal ou pas du tout, elle nous intéresse — elle finira probablement dans la FAQ. ### Signaler une vulnérabilité sur ce site **N'utilisez pas cette page pour cela.** Suivez la procédure décrite dans [Divulgation des vulnérabilités](/fr/securite/), qui indique le périmètre, nos engagements de délai et l'engagement de non-poursuite. ### Ce que ce site ne fait pas Il faut le dire clairement, pour ne pas faire perdre de temps. **Nous ne donnons pas d'avis juridique.** Ce site est une ressource documentaire ; il ne se substitue pas à un conseil. Pour une question portant sur un produit précis, sur une qualification ou sur un risque contentieux, adressez-vous à un avocat ou à votre direction juridique. **Nous n'accompagnons pas de démarche de conformité.** Nous ne réalisons ni audit, ni classification, ni dossier technique pour le compte d'un tiers. **Nous ne répondons pas au nom d'une autorité.** Pour une question relevant de la surveillance du marché, de la désignation d'un organisme notifié ou du signalement d'une vulnérabilité activement exploitée, l'interlocuteur est votre **autorité nationale**, pas ce site. Les points d'entrée officiels sont listés dans [Veille réglementaire](/fr/actualites/). **Nous ne recommandons aucun produit.** Les outils cités le sont pour illustrer des catégories techniques, sans lien commercial d'aucune sorte. Voir [Outils](/fr/outils/). ## Le cadre CRA URL: https://cra-reference.eu/fr/cra/ Description: Le règlement (UE) 2024/2847 : identité du texte, périmètre, exclusions, classes de criticité, exigences essentielles, période de support, logiciel libre, signalement, calendrier et sanctions. Audience: transverse Legal basis: Règlement (UE) 2024/2847 Published 2026-08-19, updated 2026-08-19 Cette section est la **source de vérité unique** du site sur le règlement sur la cyberrésilience. Tout le reste — parcours Juridique, parcours Cyber, organisation — y renvoie plutôt que de reformuler. ### Identité du texte **Règlement (UE) 2024/2847 du Parlement européen et du Conseil du 23 octobre 2024 relatif à des exigences horizontales de cybersécurité pour les produits comportant des éléments numériques et modifiant les règlements (UE) n° 168/2013 et (UE) 2019/1020 et la directive (UE) 2020/1828 (règlement sur la cyberrésilience).** | Repère | Date | | --- | --- | | Adoption | 23 octobre 2024 | | Publication au *Journal officiel de l'Union européenne* | 20 novembre 2024 | | Entrée en vigueur | 10 décembre 2024 | | Application des dispositions sur les organismes notifiés | 11 juin 2026 | | Application des obligations de signalement (art. 14) | 11 septembre 2026 | | Application pleine et entière | 11 décembre 2027 | ### Nature juridique C'est un **règlement**, donc d'application directe dans les vingt-sept États membres, sans transposition — à la différence de la directive NIS 2. C'est aussi une **législation d'harmonisation de l'Union** relevant du « nouveau cadre législatif » : il emprunte la même grammaire que le marquage CE des machines ou des jouets, et l'applique à la cybersécurité. Conséquence pratique : les notions de *mise sur le marché*, d'*exigences essentielles*, de *présomption de conformité par les normes harmonisées*, de *modules d'évaluation*, de *dossier technique* et de *déclaration UE de conformité* ne sont pas inventées par le CRA. Elles sont déjà connues des équipes qui traitent d'autres marquages CE, et le vocabulaire doit rester le leur. ### Ce que le règlement poursuit Les cinq objectifs affichés par le législateur, utiles à citer en interne pour asseoir un argumentaire : 1. réduire le nombre de produits vulnérables mis sur le marché ; 2. faire assumer aux fabricants la sécurité **sur tout le cycle de vie**, et non au seul moment de la vente ; 3. améliorer la **transparence** sur les propriétés de sécurité des produits ; 4. permettre aux utilisateurs, professionnels comme grand public, de choisir et d'utiliser des produits sûrs ; 5. combler les interstices entre les législations sectorielles existantes. ### Structure du règlement | Partie | Contenu | | --- | --- | | Chapitre I | Objet, champ d'application, définitions | | Chapitre II | Obligations des opérateurs économiques, dispositions relatives au logiciel libre | | Chapitre III | Présomption de conformité, normes harmonisées, évaluation de la conformité | | Chapitre IV | Notification des organismes d'évaluation de la conformité | | Chapitre V | Surveillance du marché et contrôle | | Chapitre VI | Actes délégués et actes d'exécution | | Chapitre VII | Confidentialité et sanctions | | Chapitre VIII | Dispositions transitoires et finales | | **Annexe I** | Exigences essentielles — **Partie I** : sécurité du produit ; **Partie II** : traitement des vulnérabilités | | **Annexe II** | Informations et instructions à l'utilisateur | | **Annexe III** | Produits importants — partie I (classe I) et partie II (classe II) | | **Annexe IV** | Produits critiques | | **Annexe V** | Contenu de la déclaration UE de conformité | | **Annexe VI** | Déclaration UE de conformité simplifiée | | **Annexe VII** | Contenu du dossier technique | | **Annexe VIII** | Procédures d'évaluation de la conformité | ### Sources officielles - Le **texte du règlement** sur EUR-Lex : [règlement (UE) 2024/2847](https://eur-lex.europa.eu/eli/reg/2024/2847/oj) — seule version faisant foi. Les vingt-quatre versions linguistiques ont la même valeur juridique. - La page **Cyber Resilience Act** de la Commission européenne : [digital-strategy.ec.europa.eu](https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act) — orientations, questions fréquentes, actes délégués et d'exécution à mesure de leur adoption. - L'**ENISA** : [enisa.europa.eu](https://www.enisa.europa.eu/) pour les publications, et la **base européenne de vulnérabilités** sur [euvd.enisa.europa.eu](https://euvd.enisa.europa.eu/). - Le **CEN et le CENELEC** : [cencenelec.eu](https://www.cencenelec.eu/), pour l'avancement des normes harmonisées qui conditionnent la présomption de conformité. - L'**ANSSI** : [cyber.gouv.fr](https://cyber.gouv.fr/), et le [CERT-FR](https://www.cert.ssi.gouv.fr/) pour les alertes. > **Avertissement.** Les pages de cette section sont une lecture de travail. Les numéros > d'articles et d'annexes cités doivent être vérifiés contre le texte consolidé avant tout > usage opposable, et les pages doivent être relues par le conseil juridique. ## Articulation avec les autres réglementations URL: https://cra-reference.eu/fr/cra/articulation-autres-textes/ Description: NIS 2, Cybersecurity Act, règlement IA, RED, Machines, GPSR, DORA, RGPD, responsabilité du fait des produits : où le CRA s'arrête, où il recoupe, et comment mutualiser les preuves. Audience: legal Legal basis: Art. 2 — champ d'application · Art. 12 — relation avec le règlement (UE) 2024/1689 Published 2026-08-19, updated 2026-08-19 Le CRA ne vit pas seul. Cette page sert deux objectifs : éviter le double travail en mutualisant les preuves, et éviter les angles morts entre deux régimes. ### Tableau d'articulation | Texte | Ce qu'il régit | Rapport au CRA | | --- | --- | --- | | **[Directive (UE) 2022/2555 (NIS 2)](https://eur-lex.europa.eu/eli/dir/2022/2555/oj)** | Les **entités** : gouvernance du risque, sécurité de la chaîne d'approvisionnement, notification d'incidents | Complémentaire. Le CRA régit les **produits**, NIS 2 les **organisations**. Un même groupe peut relever des deux. Point de convergence : la base européenne de vulnérabilités (EUVD), créée sous NIS 2, est alimentée par les signalements CRA. | | **[Règlement (UE) 2019/881 (Cybersecurity Act)](https://eur-lex.europa.eu/eli/reg/2019/881/oj)** | Les schémas européens de certification de cybersécurité, dont l'**EUCC** | Instrument mobilisé par le CRA : un certificat au niveau d'assurance au moins « substantiel » vaut voie d'évaluation de la conformité. | | **[Règlement (UE) 2024/1689 (règlement sur l'IA)](https://eur-lex.europa.eu/eli/reg/2024/1689/oj)** | Les systèmes d'IA, dont les systèmes à haut risque | Articulation explicite : pour un système d'IA à haut risque qui est aussi un PDE, la conformité aux exigences essentielles du CRA vaut **présomption de conformité** aux exigences de cybersécurité de l'article 15 du règlement IA, dans la mesure où elles sont couvertes. | | **[Directive 2014/53/UE (RED)](https://eur-lex.europa.eu/eli/dir/2014/53/oj)** et [règlement délégué (UE) 2022/30](https://eur-lex.europa.eu/eli/reg_del/2022/30/oj) | Cybersécurité des équipements radio, normes **EN 18031-1/-2/-3** | Régime intermédiaire, appelé à être **supplanté par le CRA** pour les produits couverts par les deux. Les travaux menés sur EN 18031 restent réutilisables comme preuve. | | **[Règlement (UE) 2023/1230 (Machines)](https://eur-lex.europa.eu/eli/reg/2023/1230/oj)** | Sécurité des machines, y compris protection contre la corruption des logiciels de sécurité | Recouvrement partiel sur les fonctions de sécurité ; les deux marquages coexistent. | | **[Règlement (UE) 2023/988 (GPSR)](https://eur-lex.europa.eu/eli/reg/2023/988/oj)** | Sécurité générale des produits de consommation | Filet de sécurité résiduel, applicable en l'absence de législation sectorielle. | | **[Règlement (UE) 2022/2554 (DORA)](https://eur-lex.europa.eu/eli/reg/2022/2554/oj)** | Résilience opérationnelle numérique du secteur financier et de ses prestataires TIC critiques | Si vous fournissez des entités financières, leurs exigences contractuelles anticipent souvent celles du CRA. | | **[Règlement (UE) 2016/679 (RGPD)](https://eur-lex.europa.eu/eli/reg/2016/679/oj)** | Protection des données à caractère personnel | Recouvrement sur la sécurité par conception (art. 25) et la sécurité du traitement (art. 32). **Les notifications ne se confondent pas** : voir ci-dessous. | | **[Directive (UE) 2024/2853](https://eur-lex.europa.eu/eli/dir/2024/2853/oj)** | Responsabilité du fait des produits défectueux | Inclut désormais explicitement le logiciel, et prend en compte l'**absence de mises à jour de sécurité** dans l'appréciation du défaut. Un manquement au CRA devient un élément à charge en action civile. | | **[Règlement (UE) 2019/1020](https://eur-lex.europa.eu/eli/reg/2019/1020/oj)** | Surveillance du marché | Modifié par le CRA ; fonde les pouvoirs des autorités nationales. | ### Le piège des notifications concurrentes Un même événement — une compromission exploitant une faille de votre produit, avec fuite de données clients — peut déclencher **trois notifications distinctes**, vers trois destinataires, dans trois délais, avec trois contenus. | | **CRA (art. 14)** | **NIS 2** | **RGPD (art. 33)** | | --- | --- | --- | --- | | Objet | Vulnérabilité **activement exploitée** dans votre produit, ou incident grave affectant sa sécurité | Incident important affectant la fourniture de vos services | Violation de données à caractère personnel | | Qui notifie | Le **fabricant** du produit | L'**entité** essentielle ou importante | Le **responsable du traitement** | | Destinataire | **CSIRT coordinateur + ENISA**, via la plateforme de signalement unique | CSIRT ou autorité compétente nationale | Autorité de protection des données | | Alerte précoce | **24 h** | 24 h | — | | Notification | **72 h** | 72 h | **72 h** | | Rapport final | **14 jours** après disponibilité d'une mesure corrective (vulnérabilité) ou **1 mois** (incident) | 1 mois | — | | Information des personnes / utilisateurs | Utilisateurs impactés, sans délai injustifié | Destinataires des services, le cas échéant | Personnes concernées, si risque élevé | > **Conséquence organisationnelle.** Une cellule de crise unique doit statuer sur les trois > régimes en même temps, avec trois gabarits distincts prêts à l'emploi. Traiter les régimes > en série fait mécaniquement rater le délai le plus court. ### Mutualiser les preuves Beaucoup d'artefacts servent plusieurs textes à la fois. Les produire une fois, les classer une fois : | Artefact | CRA | NIS 2 | RGPD | Clients | | --- | --- | --- | --- | --- | | SBOM | Annexe I et VII | Chaîne d'approvisionnement | — | Appels d'offres | | Analyse de risques de cybersécurité | Art. 13, annexe VII | Gestion des risques | Art. 32 | Questionnaires | | Politique de divulgation coordonnée | Annexe I, partie II | Bonne pratique attendue | — | Attendu du marché | | Journal de traitement des vulnérabilités | Annexe I, partie II | Gestion des incidents | Registre des violations | Audits | | Procédure de notification | Art. 14 | Notification d'incidents | Art. 33 | — | | Chiffrement et contrôle d'accès | Annexe I, partie I | Mesures techniques | Art. 32 | Certifications | C'est cette colonne « une preuve, plusieurs textes » qui rend le projet finançable : le CRA n'ajoute pas un silo, il structure des preuves déjà partiellement dues. ## Le calendrier URL: https://cra-reference.eu/fr/cra/calendrier/ Description: Les trois dates d'application, le régime transitoire, la dérogation qui soumet le parc historique au signalement, et le rétroplanning interne qui en découle. Audience: direction Legal basis: Art. 71 — entrée en vigueur et application · Art. 69 — dispositions transitoires Published 2026-08-19, updated 2026-08-19 ### Les dates | Date | Ce qui s'applique | Ce que cela implique pour vous | | --- | --- | --- | | **23 octobre 2024** | Adoption | — | | **20 novembre 2024** | Publication au *JOUE* | Point de départ des délais | | **10 décembre 2024** | **Entrée en vigueur** | Le texte est définitif ; il n'y aura pas de renégociation | | **11 juin 2026** | Chapitre sur la **notification des organismes d'évaluation de la conformité** | Les organismes notifiés peuvent être désignés → **réserver un créneau** pour les produits de classe II et Critiques | | **11 septembre 2026** | **Obligations de signalement** (art. 14), **y compris pour les produits déjà sur le marché** | Procédure 24 h / 72 h / 14 j opérationnelle, astreinte, canal testé, gabarits prêts, décision d'escalade documentée | | **11 décembre 2027** | **Application pleine et entière** | Marquage CE, dossier technique, exigences essentielles, SBOM, période de support, information de l'utilisateur | ### Le régime transitoire Deux règles, dont la seconde est une dérogation à la première. **Règle générale.** Les produits mis sur le marché **avant le 11 décembre 2027** ne sont soumis au règlement que s'ils font ensuite l'objet d'une **modification substantielle**. **Dérogation.** Les **obligations de signalement de l'article 14** s'appliquent à **tous** les produits dans le champ du règlement, **y compris ceux mis sur le marché avant cette date**. Autrement dit : | | Parc historique (avant 11/12/2027) | Produits neufs (à partir du 11/12/2027) | | --- | --- | --- | | Marquage CE au titre du CRA | Non, sauf modification substantielle | **Oui** | | Dossier technique | Non, sauf modification substantielle | **Oui** | | SBOM au dossier | Non, sauf modification substantielle | **Oui** | | Période de support | Non, sauf modification substantielle | **Oui** | | **Signalement 24 h / 72 h / 14 j** | **Oui, depuis le 11/09/2026** | **Oui** | Une mise à jour de sécurité corrigeant une vulnérabilité, sans autre changement, n'est pas une modification substantielle et ne fait donc pas basculer un produit historique dans le régime complet. ### Le rétroplanning interne Dérivé des dates légales, à valider en comité et à revoir trimestriellement. #### Immédiatement — le retard le plus coûteux - **Contractualiser les organismes notifiés** pour tous les produits de classe II et Critiques. C'est le seul poste dont le délai ne dépend pas de vous. - **Armer la procédure de signalement**, si ce n'est pas fait : l'échéance est passée. - **Classer le portefeuille** : sans classification, on ne sait pas quels produits relèvent du point précédent. #### 24 mois avant l'application pleine Classification complète du portefeuille, choix des voies d'évaluation, gouvernance et RACI validés, politique de licences arrêtée. #### 18 mois avant SBOM généré automatiquement sur 100 % des chaînes de construction ; plateforme de centralisation en production ; surveillance continue active. #### 12 mois avant Politique CVD publiée, `security.txt` en ligne, premier cycle de divulgation traité, avis de sécurité publiés au format lisible par machine. #### 9 mois avant Dossiers techniques complets sur deux produits pilotes représentatifs — un produit par défaut, un produit important — pour éprouver le processus avant de l'industrialiser. #### 6 mois avant Audit à blanc, revue par un tiers, correction des écarts, exercice de signalement chronométré. #### 3 mois avant Déclarations UE de conformité signées, marquage CE apposé, notices annexe II livrées, archivage dix ans configuré et testé par une restitution réelle. ### Ce qui peut encore bouger Trois sujets restent ouverts et doivent être suivis : 1. la **publication et la citation au *JOUE* des normes harmonisées** issues de la demande M/606, qui conditionne l'auto-évaluation des produits de classe I ; 2. les **actes délégués et d'exécution** de la Commission — actualisation des annexes III et IV, format du SBOM, obligation de certification des produits critiques ; 3. la **désignation des autorités nationales** et les modalités pratiques de la plateforme de signalement unique. Aucun de ces trois sujets ne peut décaler les dates du règlement. Ils peuvent en revanche changer le **chemin** pour y arriver, notamment pour la classe I. ## Les classes de criticité URL: https://cra-reference.eu/fr/cra/classes-de-criticite/ Description: Par défaut, Important classe I, Important classe II, Critique : la classification détermine si un organisme notifié est obligatoire, donc le coût, le délai et le chemin critique du projet. Audience: transverse Legal basis: Art. 7 — produits importants · Art. 8 — produits critiques · Annexe III — produits importants, parties I et II · Annexe IV — produits critiques · Annexe VIII — procédures d'évaluation Published 2026-08-19, updated 2026-08-19 C'est la page la plus structurante du référentiel. La classe d'un produit ne change pas *ce* qu'il doit respecter — les exigences essentielles de l'annexe I sont identiques pour tous. Elle change **la manière de le prouver**, et donc le coût, le délai et le chemin critique du projet. ### La pyramide à quatre niveaux | Niveau | Référence | Exemples | Auto-évaluation | Tiers obligatoire | | --- | --- | --- | --- | --- | | **[Par défaut](/fr/cra/classes-de-criticite/par-defaut/)** | Aucune annexe : tout ce qui n'est pas listé | Traitements de texte, jeux, applications métier, la grande majorité des produits | **Oui** (module A) | Non | | **[Important — classe I](/fr/cra/classes-de-criticite/important-classe-1/)** | Annexe III, partie I | Navigateurs, gestionnaires de mots de passe, VPN, antivirus, SIEM, routeurs, gestion d'identités | **Oui, mais seulement si les normes harmonisées sont appliquées intégralement** | Sinon oui | | **[Important — classe II](/fr/cra/classes-de-criticite/important-classe-2/)** | Annexe III, partie II | Systèmes d'exploitation, hyperviseurs et exécution de conteneurs, pare-feu, IDS/IPS, microprocesseurs résistants à l'altération | **Non** | **Oui** | | **[Critique](/fr/cra/classes-de-criticite/critique/)** | Annexe IV | Boîtiers de sécurité matériels, passerelles de compteurs intelligents, cartes à puce et éléments sécurisés | Non | **Oui**, avec possible certification **EUCC** de niveau au moins « substantiel » | ### Trois règles de méthode **1. On classe par fonctionnalité effective, pas par nom commercial.** Un produit appelé « console d'administration » qui remplit une fonction de gestion de réseau relève de la classe I. Le libellé marketing n'est pas opposable. **2. Un produit multifonction relève de la classe la plus élevée applicable.** Une suite qui embarque à la fois un gestionnaire de mots de passe (classe I) et un pare-feu (classe II) est traitée en classe II. **3. Les listes bougent.** La Commission peut préciser par actes délégués la description technique des catégories et **actualiser les annexes III et IV**. Cette page porte une date de revue ; la [veille](/fr/actualites/) sert à la tenir. ### Pourquoi c'est le chemin critique Le raisonnement à tenir devant un comité, en trois pas : 1. Une classe II ou Critique **ne peut pas s'auto-évaluer** : il faut un organisme notifié. 2. Les organismes notifiés ne peuvent être désignés que depuis le **11 juin 2026**, et leur nombre sera limité au départ. 3. Une évaluation par un tiers demande de **figer une version**, de constituer un dossier et de compter en mois, pas en semaines. Conclusion : pour tout produit de classe II ou Critique, **contractualiser un créneau d'évaluation est une action à mener maintenant**, avant même que le dossier technique soit complet. C'est le seul poste du projet dont le délai ne dépend pas de vous. ### L'incertitude à assumer Pour la classe I, la voie de l'auto-évaluation n'est ouverte **que** si le fabricant applique intégralement des normes harmonisées, des spécifications communes ou un schéma de certification européen couvrant l'ensemble des exigences essentielles pertinentes. Tant que les normes harmonisées issues de la demande de normalisation **M/606** ne sont pas publiées et citées au *Journal officiel*, cette voie est **fermée en pratique**. Il faut donc planifier deux scénarios pour la classe I : auto-évaluation si les normes arrivent à temps, recours à un organisme notifié sinon. Traiter le second comme le scénario de référence est la position prudente. ### Ce qu'il faut produire Une **fiche de classification** par produit, versée au dossier technique : fonctionnalités effectives, catégories de l'annexe III ou IV examinées, catégorie retenue ou motif d'écartement, classe résultante, voie d'évaluation choisie, date et signataire. La [méthode](/fr/cra/classes-de-criticite/methode/) décrit le questionnement à suivre. ## Produits critiques URL: https://cra-reference.eu/fr/cra/classes-de-criticite/critique/ Description: Annexe IV : boîtiers de sécurité matériels, passerelles de compteurs intelligents, cartes à puce et éléments sécurisés. Régime renforcé et possible obligation de certification EUCC. Audience: transverse Legal basis: Art. 8 — produits critiques · Annexe IV · Règlement (UE) 2019/881 — schémas de certification Published 2026-08-19, updated 2026-08-19 ### La liste (annexe IV) - **Dispositifs matériels dotés de boîtiers de sécurité** (*security boxes*) — modules matériels de sécurité, coffres cryptographiques. - **Passerelles de compteurs intelligents** au sein des systèmes de comptage intelligents au sens de la [directive (UE) 2019/944](https://eur-lex.europa.eu/eli/dir/2019/944/oj), et **autres dispositifs destinés à des fins de sécurité avancées**, y compris pour le **cryptotraitement sécurisé**. - **Cartes à puce ou dispositifs similaires**, y compris les **éléments sécurisés** (*secure elements*). La liste est courte et volontairement restrictive : elle vise des composants dont la compromission dégrade la sécurité de tout ce qui repose sur eux. ### Le régime renforcé Les produits critiques suivent d'abord le régime des produits importants de classe II — **organisme notifié obligatoire**, modules B+C ou H. S'y ajoute une habilitation spécifique : la Commission est habilitée à imposer, par **acte délégué**, l'obtention d'un **certificat européen de cybersécurité** délivré au titre d'un schéma adopté sous le règlement (UE) 2019/881 — typiquement le schéma **EUCC** — à un **niveau d'assurance au moins « substantiel »**. Le déclenchement de cette obligation se fait catégorie par catégorie, en fonction du niveau de risque et de la disponibilité d'un schéma adapté. Suivre les actes délégués est donc indispensable pour tout fabricant concerné : c'est un point permanent de la [veille](/fr/actualites/). ### Ce que cela change concrètement | | Classe II | **Critique avec exigence EUCC** | | --- | --- | --- | | Évaluateur | Organisme notifié | **Laboratoire d'évaluation (ITSEF)** accrédité au titre du schéma | | Livrable d'entrée | Dossier technique | **Cible de sécurité**, description des mécanismes, preuves de conception | | Méthode | Examen de type ou audit qualité | Évaluation selon la méthodologie du schéma, proche des **Critères communs** | | Durée typique | Quelques mois | **Souvent plus d'un an** pour un premier passage | | Coût | Significatif | **Sensiblement supérieur** | | Maintien | Extension de certificat | **Maintenance du certificat**, réévaluation à chaque évolution | ### Conséquences pour la feuille de route Pour un produit critique, la conformité au CRA n'est pas un chantier documentaire : c'est un **programme d'ingénierie de sécurité** qui doit être lancé très en amont de la date d'application, avec : - la désignation d'un responsable de la certification, distinct du chef de produit ; - la rédaction anticipée de la **cible de sécurité** et l'identification des hypothèses d'environnement ; - le choix et la contractualisation du laboratoire d'évaluation ; - l'alignement de la feuille de route produit sur les fenêtres d'évaluation, y compris le gel des évolutions pendant les phases critiques ; - la budgétisation du **maintien** du certificat, et non seulement de son obtention. > **À poser au comité.** Pour un produit critique, la question n'est pas « comment vous > mettre en conformité ? » mais « ce produit reste-t-il dans votre portefeuille au regard du > coût de certification récurrent ? ». C'est une décision de portefeuille, pas une décision > de conformité, et elle doit être prise explicitement. ## Important — classe I URL: https://cra-reference.eu/fr/cra/classes-de-criticite/important-classe-1/ Description: Annexe III, partie I : navigateurs, gestionnaires de mots de passe, VPN, antivirus, SIEM, routeurs, gestion d'identités. Trois voies d'évaluation, dont une conditionnée aux normes harmonisées. Audience: transverse Legal basis: Art. 7 — produits importants · Annexe III, partie I · Art. 32, paragraphe 2 — voies d'évaluation Published 2026-08-19, updated 2026-08-19 ### La liste (annexe III, partie I) Les catégories, telles qu'énumérées par le règlement. Le classement se fait par **fonctionnalité effective**. - **Systèmes de gestion des identités** et logiciels ou matériels de **gestion des accès à privilèges**. - **Navigateurs autonomes et embarqués.** - **Gestionnaires de mots de passe.** - Logiciels de **recherche, suppression ou mise en quarantaine de logiciels malveillants** — antivirus, protection des postes de travail. - **Produits de réseau privé virtuel (VPN).** - **Systèmes de gestion de réseau.** - **Systèmes de gestion des informations et des événements de sécurité (SIEM).** - **Gestionnaires d'amorçage** (*boot managers*). - Logiciels d'**émission de certificats numériques** et infrastructures à clés publiques. - **Interfaces réseau physiques et virtuelles.** - **Routeurs, modems destinés à la connexion internet, et commutateurs.** - **Microprocesseurs, microcontrôleurs, circuits intégrés à application spécifique (ASIC) et réseaux de portes programmables (FPGA)** dotés de fonctionnalités liées à la sécurité. - **Assistants virtuels domestiques à usage général.** - **Produits domotiques dotés de fonctions de sécurité** : serrures connectées, caméras de sécurité, systèmes d'alarme, dispositifs de surveillance de bébé. - **Jouets connectés** dotés de fonctions d'interaction sociale ou de suivi de localisation. - **Produits portables personnels** destinés au suivi de la santé ou portés sur le corps. ### Les trois voies d'évaluation | Voie | Contenu | Tiers | | --- | --- | --- | | **Module A** — contrôle interne | Auto-évaluation complète | Aucun — **mais sous condition, voir ci-dessous** | | **Modules B + C** | Examen UE de type par un organisme notifié, puis conformité au type sur la base du contrôle interne | **Organisme notifié** | | **Module H** | Assurance qualité complète du système de conception, développement et production, auditée | **Organisme notifié** | Une quatrième possibilité existe : la détention d'un **certificat européen de cybersécurité** délivré au titre d'un schéma adopté sous le Cybersecurity Act, à un niveau d'assurance au moins « substantiel », qui couvre les exigences essentielles pertinentes. ### La condition qui change tout Le module A n'est ouvert aux produits de classe I **que si le fabricant applique intégralement** des normes harmonisées, des spécifications communes ou un schéma de certification européen **couvrant l'ensemble des exigences essentielles pertinentes**. « Intégralement » et « l'ensemble » sont les deux mots à retenir. Une application partielle, avec des écarts justifiés, ne suffit pas : elle referme la voie de l'auto-évaluation. > **Conséquence de planning.** Tant que les normes harmonisées issues de la demande de > normalisation **M/606** — travaux du comité technique mixte **CEN/CENELEC JTC 13, > groupe de travail 9** — ne sont pas publiées et **citées au *Journal officiel de l'Union > européenne***, la voie du module A est **fermée en pratique** pour la classe I. Une norme > adoptée mais non citée au JOUE ne confère aucune présomption de conformité. ### Ce qu'il faut décider maintenant Deux scénarios à instruire en parallèle, et un choix par défaut : 1. **Scénario normes** — les normes harmonisées sont publiées et citées à temps ; vous démontrez leur application intégrale et restez en module A. Coût faible, délai maîtrisé, **probabilité incertaine**. 2. **Scénario organisme notifié** — vous engagez un organisme sur les modules B+C ou H. Coût significatif, délai de plusieurs mois, **maîtrisé par vous seuls à condition de réserver tôt**. La position prudente consiste à **traiter le scénario 2 comme le scénario de référence** et le scénario 1 comme une économie éventuelle. L'inverse expose à découvrir en 2027 qu'aucun créneau d'évaluation n'est disponible. ### Points de vigilance sur la qualification - Un **navigateur embarqué** dans un autre produit fait basculer ce produit en classe I. Un composant de rendu web intégré dans une application de bureau doit être examiné à ce titre. - Un **microcontrôleur doté de fonctionnalités liées à la sécurité** relève de la classe I ; s'il est en outre **résistant à l'altération**, il relève de la classe II. La frontière est technique et doit être tranchée par l'ingénierie, pas par le juridique. - Un **produit domotique** n'est en classe I que s'il est **doté de fonctions de sécurité**. Une ampoule connectée n'en relève pas ; une caméra de sécurité, si. - Les **jouets connectés** ne relèvent de la classe I qu'en présence d'interaction sociale ou de suivi de localisation — mais restent par ailleurs soumis à la réglementation des jouets. ## Important — classe II URL: https://cra-reference.eu/fr/cra/classes-de-criticite/important-classe-2/ Description: Annexe III, partie II : systèmes d'exploitation, hyperviseurs, pare-feu, IDS/IPS, microprocesseurs résistants à l'altération. L'auto-évaluation est exclue, l'organisme notifié est obligatoire. Audience: transverse Legal basis: Art. 7 — produits importants · Annexe III, partie II · Art. 32, paragraphe 3 Published 2026-08-19, updated 2026-08-19 ### La liste (annexe III, partie II) - **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. - **Pare-feu, systèmes de détection et de prévention d'intrusion** (IDS / IPS). - **Microprocesseurs résistants à l'altération** (*tamper-resistant*). - **Microcontrôleurs résistants à l'altération.** - **Systèmes d'exploitation.** ### Le régime **L'auto-évaluation est exclue.** Seuls deux modules sont ouverts, et tous deux impliquent un **organisme notifié** : | Module | Contenu | Ce qui est certifié | | --- | --- | --- | | **B + C** | Examen UE de type, puis conformité au type sur la base du contrôle interne de la production | **Le produit**, dans une version donnée | | **H** | Assurance qualité complète : le système de conception, de développement et de production est audité et approuvé | **Le processus** | La détention d'un certificat européen de cybersécurité au niveau d'assurance au moins « substantiel » couvrant les exigences essentielles pertinentes constitue également une voie recevable. ### Choisir entre B+C et H | Critère | B + C | H | | --- | --- | --- | | Cadence de publication | Convient à un produit à cycle long, versions rares | Convient à une **livraison continue** | | Nouvelle version | Peut exiger une extension ou une réévaluation du certificat | Couverte par le système qualité approuvé | | Effort initial | Concentré sur un dossier produit | Porte sur l'**organisation** : procédures, traçabilité, audits | | Effort récurrent | À chaque version significative | Audits de surveillance périodiques | | Adapté à | Micrologiciel, produit matériel, système d'exploitation embarqué | Éditeur logiciel publiant fréquemment | Pour un éditeur qui publie plusieurs fois par mois, le module B+C devient rapidement ingérable : chaque modification substantielle rouvre la question du certificat. Le module H coûte plus cher au démarrage mais absorbe la cadence. ### Implications de projet - **Coût** d'évaluation, à budgéter par produit et par cycle. - **Délai** de plusieurs mois, dépendant de la charge de l'organisme, non compressible. - **Gel d'une version** pendant l'examen, pour le module B. - **Gestion des modifications substantielles** après certification : toute évolution affectant la conformité rouvre une procédure. - **Contractualisation anticipée** : c'est le seul poste du projet dont vous ne maîtrisez pas le délai. > **Alerte planning.** Le chapitre du règlement relatif à la notification des organismes > d'évaluation de la conformité s'applique depuis le **11 juin 2026**. Le nombre > d'organismes accrédités et leur capacité seront limités au démarrage, alors que > l'ensemble du marché doit passer par eux avant le 11 décembre 2027. **Réserver un créneau > est une action à mener maintenant, pas quand le dossier sera prêt.** ### Points de vigilance sur la qualification - « **Système d'exploitation** » se lit largement : un système d'exploitation embarqué ou temps réel que vous distribuez relève de la catégorie. - Un **moteur d'exécution de conteneurs** est visé ; un simple **orchestrateur** ne l'est pas au même titre, mais l'ensemble doit être examiné composant par composant. - Un microcontrôleur **résistant à l'altération** relève de la classe II ; le même microcontrôleur sans cette propriété relève de la classe I s'il porte des fonctionnalités liées à la sécurité. La qualification doit être tranchée par l'ingénierie, sur la base des contre-mesures physiques réellement implémentées, et documentée. - Un produit qui **intègre** un système d'exploitation sans le mettre sur le marché séparément n'est pas de ce seul fait en classe II : c'est la fonction offerte au marché qui compte. En revanche, la diligence sur ce composant tiers reste due. ## Méthode de classification URL: https://cra-reference.eu/fr/cra/classes-de-criticite/methode/ Description: Le questionnement à suivre pour classer un produit, la fiche de classification à produire, et le registre consolidé du portefeuille. Audience: transverse Legal basis: Annexes III et IV Published 2026-08-19, updated 2026-08-19 La classification est une décision juridique fondée sur des faits techniques. Elle doit donc être **co-signée** : l'ingénierie établit les fonctionnalités réelles, le juridique tranche la qualification. ### Le questionnement, dans l'ordre #### Étape 1 — Le produit est-il un PDE ? Voir [Le périmètre](/fr/cra/perimetre-pde/). Si non, la classification s'arrête ; une fiche de qualification négative est tout de même produite. #### Étape 2 — Est-il exclu ? Voir [Les exclusions](/fr/cra/exclusions/). Si oui, produire une fiche d'exclusion motivée citant le texte sectoriel applicable. #### Étape 3 — Quelles fonctionnalités le produit offre-t-il réellement ? Lister les fonctions **effectivement offertes à l'utilisateur**, indépendamment du nom commercial et de la documentation marketing. Une fonction désactivée par défaut mais activable reste une fonction offerte. #### Étape 4 — Figure-t-il à l'annexe IV ? Boîtier de sécurité matériel, passerelle de compteur intelligent, dispositif de cryptotraitement sécurisé, carte à puce ou élément sécurisé. Si oui → **[Critique](/fr/cra/classes-de-criticite/critique/)**, on s'arrête. #### Étape 5 — Figure-t-il à l'annexe III, partie II ? Système d'exploitation, hyperviseur, moteur d'exécution de conteneurs, pare-feu, IDS/IPS, microprocesseur ou microcontrôleur **résistant à l'altération**. Si oui → **[Important classe II](/fr/cra/classes-de-criticite/important-classe-2/)**, on s'arrête. #### Étape 6 — Figure-t-il à l'annexe III, partie I ? Les dix-sept catégories listées dans [Important classe I](/fr/cra/classes-de-criticite/important-classe-1/). Si oui → **classe I**. #### Étape 7 — Sinon **[Catégorie par défaut](/fr/cra/classes-de-criticite/par-defaut/)**. La fiche doit démontrer l'examen des annexes III et IV et l'écartement de chaque catégorie pertinente. ### Les quatre questions qui tranchent les cas limites 1. **Résistance à l'altération.** Le composant met-il en œuvre des contre-mesures physiques contre l'extraction ou la modification de secrets — bouclier, détection d'intrusion, mémoire chiffrée, protection contre les canaux auxiliaires ? Cette réponse, purement technique, fait basculer un microcontrôleur de la classe I à la classe II. 2. **Fonctionnalité liée à la sécurité.** Le composant remplit-il une fonction de sécurité pour le système qui l'intègre — génération de clés, stockage de secrets, contrôle d'accès, démarrage vérifié ? 3. **Navigateur embarqué.** Le produit intègre-t-il un moteur de rendu web exposé à du contenu distant non maîtrisé ? 4. **Multifonction.** Le produit couvre-t-il plusieurs catégories ? Alors la **classe la plus élevée** s'applique à l'ensemble. ### La fiche de classification Un document d'une page, versé au dossier technique. Elle doit contenir : | Champ | Contenu | | --- | --- | | Produit et versions couvertes | Identification traçable | | Fonctionnalités effectives | Liste, avec la source (spécification, code, documentation) | | Annexe IV | Catégories examinées, retenues ou écartées, motif | | Annexe III partie II | Idem | | Annexe III partie I | Idem | | **Classe retenue** | Par défaut, I, II ou Critique | | **Voie d'évaluation** | Module A, B+C, H, ou certification | | Organisme notifié | Le cas échéant, identité et état de la contractualisation | | Hypothèses et réserves | Points appelant une réévaluation | | Date, signataires | Ingénierie **et** juridique | ### Le registre consolidé Un tableau unique du portefeuille, tenu par la direction juridique et revu à chaque comité : produit, statut PDE, exclusion éventuelle, classe, voie d'évaluation, organisme notifié, date de la dernière classification, prochaine revue. Ce registre est le premier document que demandera une autorité de surveillance du marché, et le premier que demandera un acquéreur lors d'une opération. Sa tenue n'est pas optionnelle. ### Quand reclasser - Ajout ou activation d'une **fonction de sécurité**. - **Modification substantielle** au sens de l'article 3. - **Actualisation des annexes III ou IV** par acte délégué de la Commission. - Publication d'orientations de la Commission précisant la description technique d'une catégorie. - Au minimum, **revue annuelle** de l'ensemble du registre. ## Catégorie par défaut URL: https://cra-reference.eu/fr/cra/classes-de-criticite/par-defaut/ Description: Ce que signifie l'auto-évaluation : le module A, ce qu'il dispense et surtout ce qu'il ne dispense pas, et le risque réel d'un dossier auto-déclaré mais vide. Audience: legal Legal basis: Art. 32, paragraphe 1 · Annexe VIII, partie I — module A Published 2026-08-19, updated 2026-08-19 ### Ce que la catégorie recouvre Tout produit comportant des éléments numériques qui **ne figure ni à l'annexe III ni à l'annexe IV**. C'est le cas de la très grande majorité des produits du marché : logiciels métier, applications mobiles, jeux, outils bureautiques, objets connectés sans fonction de sécurité, bibliothèques génériques. La catégorie n'est donc pas définie par une liste, mais **par soustraction**. La fiche de classification doit en conséquence démontrer que le produit a été confronté aux listes des annexes III et IV, et écarté de chacune — pas simplement affirmer qu'il est « standard ». ### La voie de conformité : le module A Le **module A — contrôle interne de la production** (annexe VIII, partie I) est ouvert sans condition. Le fabricant : 1. réalise lui-même l'**évaluation des risques de cybersécurité** et la documente ; 2. conçoit, développe et produit le produit conformément aux **exigences essentielles de l'annexe I** ; 3. constitue le **dossier technique** de l'annexe VII ; 4. prend les mesures nécessaires pour que le processus de fabrication garantisse la conformité en série ; 5. établit la **déclaration UE de conformité** (annexe V) ; 6. appose le **marquage CE**. Aucun organisme notifié n'intervient, aucun numéro d'organisme n'est apposé à côté du marquage. ### Ce que « auto-évaluation » ne veut pas dire C'est le contresens le plus répandu du sujet, et il coûte cher. | Ce que le module A dispense | Ce que le module A **ne dispense pas** | | --- | --- | | De faire vérifier le dossier par un tiers accrédité | De **constituer** le dossier technique | | De payer un organisme notifié | De réaliser et documenter l'analyse de risques | | D'attendre un créneau d'évaluation | De produire un **SBOM** lisible par machine | | De figer une version pour l'examen de type | De mettre en place une **politique de divulgation coordonnée** | | — | De déterminer et de publier une **période de support** | | — | De **signaler sous 24 heures** les vulnérabilités activement exploitées | | — | De **conserver** dossier et déclaration pendant dix ans | Le fond des obligations est **strictement identique** à celui d'un produit de classe II. Seule la vérification externe disparaît. ### Le risque réel Il ne réside pas dans la classification, il réside dans le contrôle. Une **autorité de surveillance du marché** peut, à tout moment et sans motif préalable, exiger le dossier technique d'un produit qu'elle a acheté dans le commerce. Trois situations se présentent alors : - **Dossier complet** : la démonstration se fait en quelques jours, l'incident s'arrête là. - **Dossier incomplet** : injonction de mise en conformité dans un délai imparti, avec risque de restriction de mise à disposition pendant la remise à niveau. - **Dossier inexistant alors que le marquage CE est apposé** : c'est une non-conformité formelle doublée d'une déclaration inexacte. Le plafond de sanction pour la fourniture d'informations incorrectes ou trompeuses aux autorités s'y ajoute. > **À retenir.** L'auto-évaluation transfère la charge de la preuve, elle ne la supprime > pas. Un dossier auto-déclaré mais vide est une situation plus grave qu'une absence de > marquage, parce qu'elle est une affirmation fausse et non une omission. ### Liste de contrôle du module A - [ ] Fiche de qualification PDE signée - [ ] Fiche de classification démontrant l'écartement des annexes III et IV - [ ] Analyse de risques de cybersécurité documentée et datée - [ ] Couverture des exigences de l'annexe I, partie I, avec justification des exigences écartées - [ ] Processus de traitement des vulnérabilités de l'annexe I, partie II, opérationnel - [ ] SBOM généré, validé, signé, archivé - [ ] Politique de divulgation coordonnée publiée, point de contact actif - [ ] Période de support déterminée, justifiée, communiquée à l'acheteur - [ ] Informations et instructions à l'utilisateur (annexe II) livrées - [ ] Dossier technique (annexe VII) complet - [ ] Déclaration UE de conformité (annexe V) signée - [ ] Marquage CE apposé selon les règles - [ ] Archivage dix ans configuré ## Le dossier technique (annexe VII) URL: https://cra-reference.eu/fr/cra/dossier-technique/ Description: Le plan type du dossier, où s'y place le SBOM, la durée de conservation de dix ans, et la liste de complétude à cocher avant la revue de mise sur le marché. Audience: legal Legal basis: Art. 31 — documentation technique · Annexe VII — contenu du dossier technique · Annexe I — exigences essentielles Published 2026-08-19, updated 2026-08-19 Le dossier technique est **le** livrable du CRA. C'est lui que demande une autorité de surveillance du marché, lui que vérifie un organisme notifié, lui qui fonde la déclaration UE de conformité. C'est aussi le document qui matérialise l'interface entre le Juridique et la Cyber : le premier le structure et le conserve, la seconde en produit l'essentiel du contenu. ### Le plan type #### 1. Description générale du produit Destination, versions couvertes, photographies ou illustrations montrant les caractéristiques externes, marquage et configuration interne, description des logiciels et matériels, informations et instructions à l'utilisateur (annexe II), instructions d'installation. #### 2. Conception, développement, production et traitement des vulnérabilités C'est la partie substantielle. Elle comprend : - les informations sur la **conception et le développement**, y compris les schémas d'architecture et la description des composants ; - les **spécifications complètes des processus de traitement des vulnérabilités** mis en place, comprenant explicitement : - la **nomenclature logicielle (SBOM)**, - la **politique de divulgation coordonnée des vulnérabilités**, - la preuve de la mise à disposition d'une **adresse de contact** pour le signalement, - les **processus de distribution des mises à jour de sécurité** ; - la description des **processus de production et de contrôle**. #### 3. Évaluation des risques de cybersécurité L'analyse conduite au titre de l'article 13, prise en compte dès la conception et pendant tout le cycle de vie, avec la justification des exigences de l'annexe I retenues et écartées. #### 4. Détermination de la période de support La durée retenue et sa justification : attentes des utilisateurs, nature du produit, pratiques du marché, durée de support des composants intégrés. Voir [Période de support](/fr/cra/support-et-cycle-de-vie/). #### 5. Normes appliquées La liste des **normes harmonisées** appliquées en tout ou partie, dont les références sont publiées au *Journal officiel*, et — pour les parties non couvertes — la description des solutions retenues pour satisfaire les exigences essentielles. #### 6. Rapports d'essais Les rapports de tests attestant la conformité du produit et des processus de traitement des vulnérabilités. #### 7. Déclaration UE de conformité Une copie de la déclaration établie au titre de l'annexe V. #### 8. Le cas échéant, les documents de l'organisme notifié Attestations, décisions et rapports délivrés par l'organisme notifié intervenu. ### Où se place le SBOM Au **point 2**, dans les spécifications des processus de traitement des vulnérabilités. > **La phrase à faire passer côté Juridique.** Le SBOM n'est pas un livrable technique > annexe : c'est une **pièce constitutive du dossier permettant d'obtenir le marquage CE**. > Pas de SBOM exploitable → dossier technique incomplet → déclaration UE de conformité mal > fondée → marquage CE juridiquement fragile → commercialisation exposée. Le règlement n'impose pas de **publier** le SBOM. Il impose qu'il figure au dossier, tenu à disposition des autorités. Sa communication aux clients relève d'une décision commerciale et contractuelle : voir [Diffusion du SBOM](/fr/sbom/diffusion-et-confidentialite/). ### Conservation Le dossier technique **et** la déclaration UE de conformité sont tenus à la disposition des autorités de surveillance du marché pendant **au moins dix ans après la mise sur le marché du produit, ou pendant la période de support si celle-ci est plus longue**. Cela suppose un dispositif d'archivage capable de restituer, dix ans plus tard, la version exacte du dossier correspondant à une version donnée du produit — y compris son SBOM. Voir [Conservation des preuves](/fr/legal/conservation-des-preuves/). ### Liste de complétude - [ ] Description générale, versions couvertes identifiées sans ambiguïté - [ ] Schémas d'architecture à jour - [ ] **SBOM** de la version concernée, lisible par machine, signé - [ ] **Politique CVD** publiée, avec la preuve de sa publication - [ ] Preuve de l'existence et du fonctionnement de l'**adresse de contact** - [ ] Description du **processus de distribution des mises à jour** - [ ] **Analyse de risques** datée et signée, avec justification des exigences écartées - [ ] **Période de support** déterminée et justifiée - [ ] Liste des **normes harmonisées** appliquées, écarts documentés - [ ] **Rapports de tests** couvrant les exigences applicables - [ ] Copie de la **déclaration UE de conformité** signée - [ ] Le cas échéant, **attestations de l'organisme notifié** - [ ] Politique d'**archivage dix ans** configurée et testée Une version simplifiée de ce dossier est prévue par la Commission pour les micro et petites entreprises. ## L'évaluation de la conformité URL: https://cra-reference.eu/fr/cra/evaluation-de-conformite/ Description: Présomption de conformité, normes harmonisées et demande M/606, modules A, B+C et H, organismes notifiés, certification EUCC, et mesures de soutien aux PME. Audience: legal Legal basis: Art. 27 — présomption de conformité · Art. 32 — procédures d'évaluation · Chapitre IV — organismes notifiés · Annexe VIII — modules Published 2026-08-19, updated 2026-08-19 ### La présomption de conformité Un produit conforme, en tout ou partie, à des **normes harmonisées** dont les références ont été publiées au *Journal officiel de l'Union européenne* est **présumé conforme** aux exigences essentielles couvertes par ces normes. Trois voies ouvrent cette présomption : 1. les **normes harmonisées** citées au JOUE ; 2. les **spécifications communes** adoptées par la Commission par acte d'exécution, en l'absence de norme harmonisée satisfaisante ; 3. les **schémas européens de certification de cybersécurité** adoptés sous le règlement (UE) 2019/881, à un niveau d'assurance au moins « substantiel ». La présomption est un **renversement de la charge de la preuve**, pas une dispense : elle n'exonère ni du dossier technique, ni de la déclaration, ni du marquage. ### L'état de la normalisation La Commission a adressé au [CEN et au CENELEC](https://www.cencenelec.eu/) la demande de normalisation **M/606**. Les travaux sont conduits par le comité technique mixte **JTC 13**, groupe de travail 9, et comportent : - des **normes horizontales** — principes de cyberrésilience, exigences génériques de sécurité, traitement des vulnérabilités — applicables à tous les produits ; - des **normes verticales**, par catégorie de produit de l'annexe III. > **C'est le principal facteur d'incertitude du calendrier.** Une norme adoptée mais non > encore **citée au JOUE** ne confère aucune présomption. Cette page doit être relue à > chaque publication ; voir la [veille](/fr/actualites/). ### Les modules d'évaluation | Module | Nom | Qui évalue | Ouvert à | | --- | --- | --- | --- | | **A** | Contrôle interne de la production | Le fabricant | Par défaut ; classe I **sous condition** d'application intégrale des normes | | **B** | Examen UE de type | Organisme notifié | Classes I et II, Critique — suivi du module C | | **C** | Conformité au type sur la base du contrôle interne | Le fabricant, après le module B | Idem | | **H** | Conformité sur la base de l'assurance complète de la qualité | Organisme notifié (audit du système) | Classes I et II, Critique | Le choix entre B+C et H est développé dans [Important classe II](/fr/cra/classes-de-criticite/important-classe-2/). ### Les organismes notifiés Un organisme notifié est un organisme d'évaluation de la conformité **accrédité**, désigné par une **autorité notifiante** nationale, **notifié à la Commission** et inscrit dans la base **[NANDO](https://single-market-economy.ec.europa.eu/single-market/goods/building-blocks/notified-bodies_en)**, où il reçoit un numéro d'identification. Le règlement leur impose indépendance, compétence technique, impartialité, confidentialité et souscription d'une assurance de responsabilité. Ils sont soumis à des obligations d'information vers l'autorité notifiante et vers les autres organismes. Le chapitre correspondant s'applique depuis le **11 juin 2026**. Deux points à anticiper : - **la capacité** — l'ensemble du marché européen doit passer par ces organismes avant le 11 décembre 2027, avec un nombre d'organismes limité au démarrage ; - **la compétence sectorielle** — tous les organismes ne couvriront pas toutes les catégories de l'annexe III ; vérifier la portée exacte de la notification dans NANDO avant de contractualiser. ### La voie de la certification La détention d'un **certificat européen de cybersécurité**, délivré au titre d'un schéma adopté sous le Cybersecurity Act à un niveau d'assurance au moins « substantiel », et couvrant les exigences essentielles pertinentes, vaut évaluation de la conformité. Pour les **produits critiques** de l'annexe IV, la Commission peut **rendre cette voie obligatoire** par acte délégué — voir [Produits critiques](/fr/cra/classes-de-criticite/critique/). ### Coûts et délais : ce qu'il faut budgéter Le règlement ne fixe évidemment aucun tarif. Les postes à provisionner, eux, sont connus : - frais d'évaluation de l'organisme notifié, par produit et par cycle ; - coût interne de préparation du dossier, généralement supérieur au coût externe ; - coût du **gel de version** pendant l'examen, en jours de retard de mise sur le marché ; - coût de **maintien** : extensions de certificat, audits de surveillance, réévaluations après modification substantielle ; - pour les produits critiques soumis à certification, coût du laboratoire d'évaluation et de la maintenance du certificat. ### Micro, petites et moyennes entreprises Le règlement prévoit des **mesures de soutien** : mise à disposition par la Commission d'un **formulaire simplifié de dossier technique** adapté aux micro et petites entreprises, actions de sensibilisation et de formation par les États membres, et prise en compte de la taille de l'entreprise dans la fixation des sanctions. Ces mesures allègent la charge documentaire ; elles ne réduisent **aucune** exigence de fond. ## Les exclusions du champ d'application URL: https://cra-reference.eu/fr/cra/exclusions/ Description: Dispositifs médicaux, véhicules, aviation, équipements marins, défense, pièces détachées, logiciel libre non commercial : ce que le règlement laisse hors de son champ, et les faux amis. Audience: legal Legal basis: Art. 2, paragraphes 2 à 7 Published 2026-08-19, updated 2026-08-19 Le sur-périmètre coûte aussi cher que le sous-périmètre. Beaucoup d'organisations appliquent le CRA à des produits expressément exclus, tout en oubliant des composants qui, eux, sont dedans. ### Exclusions sectorielles — la règle *lex specialis* Le législateur a écarté les secteurs déjà dotés d'un régime de cybersécurité équivalent ou plus exigeant. L'exclusion est fondée sur le **texte qui couvre le produit**, pas sur le secteur d'activité de l'entreprise. | Produits exclus | Texte qui prévaut | Régime de cybersécurité applicable | | --- | --- | --- | | **Dispositifs médicaux** | [Règlement (UE) 2017/745](https://eur-lex.europa.eu/eli/reg/2017/745/oj) (MDR) | Exigences de l'annexe I MDR, orientations MDCG 2019-16 | | **Dispositifs médicaux de diagnostic in vitro** | [Règlement (UE) 2017/746](https://eur-lex.europa.eu/eli/reg/2017/746/oj) (IVDR) | Idem, volet IVD | | **Véhicules à moteur** | [Règlement (UE) 2019/2144](https://eur-lex.europa.eu/eli/reg/2019/2144/oj) | Règlements ONU R155 (système de management de la cybersécurité) et R156 (mise à jour logicielle) | | **Aviation civile** | [Règlement (UE) 2018/1139](https://eur-lex.europa.eu/eli/reg/2018/1139/oj) | Règlement délégué « Part-IS » sur la sécurité de l'information | | **Équipements marins** | [Directive 2014/90/UE](https://eur-lex.europa.eu/eli/dir/2014/90/oj) | Régime propre aux équipements marins | ### Exclusions liées à la sécurité nationale et à la défense - Produits **développés ou modifiés exclusivement à des fins de sécurité nationale ou de défense**. - Produits **spécifiquement conçus pour traiter des informations classifiées**. L'adverbe « exclusivement » est déterminant : un produit à double usage, commercialisé aussi sur le marché civil, n'est pas exclu pour sa version civile. ### Autres exclusions - **Pièces détachées** mises sur le marché pour remplacer des composants identiques dans des produits existants, et fabriquées selon les mêmes spécifications. - **Logiciel libre et open source non fourni dans le cadre d'une activité commerciale** — le régime complet est détaillé dans [Le logiciel libre](/fr/cra/open-source/). - **Produits exclusivement destinés à la recherche** et prototypes non mis sur le marché. - **Produits inachevés** mis à disposition à des fins de test ou de démonstration, non destinés à un usage final. ### Les faux amis Quatre pièges reviennent systématiquement. **1. Le composant d'un produit exclu n'est pas exclu.** Un dispositif médical relève du MDR, mais la bibliothèque de communication que vous lui vendez, mise sur le marché séparément, est un PDE à part entière — avec son marquage CE au titre du CRA. **2. L'exclusion sectorielle ne dispense pas de NIS 2.** Une entité essentielle ou importante reste soumise à ses obligations de gestion des risques, y compris sur la sécurité de sa chaîne d'approvisionnement, quels que soient les produits qu'elle fabrique. **3. « Vous vendez du service, pas du produit » n'est pas une exclusion.** Voir la qualification des solutions de traitement de données à distance dans [Le périmètre](/fr/cra/perimetre-pde/). **4. « C'est de l'open source » n'est pas une exclusion en soi.** Ce qui est exclu, c'est la mise à disposition **hors activité commerciale**. Le logiciel libre que vous intégrez dans un produit vendu engage votre responsabilité pleine et entière : voir [Intégrer de l'open source](/fr/cra/open-source/integrer-de-l-oss/). ### Ce qu'il faut produire Pour chaque produit écarté du périmètre, une **fiche d'exclusion** motivée : texte sectoriel invoqué, référence exacte, justification de son applicabilité, date et signataire. Une exclusion non documentée est indéfendable devant une autorité de surveillance du marché, et le coût de la démonstration a posteriori est sans commune mesure avec celui d'une fiche d'une page rédigée au bon moment. ## Les exigences essentielles URL: https://cra-reference.eu/fr/cra/exigences-essentielles/ Description: L'annexe I : treize exigences de sécurité du produit en partie I, huit obligations de traitement des vulnérabilités en partie II. Le fond du règlement, identique pour toutes les classes. Audience: cyber Legal basis: Art. 13 — obligations des fabricants · Annexe I, parties I et II Published 2026-08-19, updated 2026-08-19 L'annexe I est le cœur du règlement. Elle s'applique **à l'identique quelle que soit la classe de criticité** ; ce sont les modalités de preuve qui varient. Elle se lit en deux parties, de nature très différente. | | **Partie I — Sécurité du produit** | **Partie II — Traitement des vulnérabilités** | | --- | --- | --- | | Nature | Propriétés du produit à la mise sur le marché | **Processus** à tenir pendant toute la période de support | | Horizon | Instantané | Continu, cinq à dix ans | | Preuve | Conception, tests, configuration | Journaux, SBOM, avis publiés, délais mesurés | | Détail | [Sécurité du produit](/fr/cra/exigences-essentielles/securite-des-produits/) | [Traitement des vulnérabilités](/fr/cra/exigences-essentielles/traitement-des-vulnerabilites/) | ### Le principe de proportionnalité Les exigences de la partie I s'appliquent « dans la mesure applicable au produit ». Cette formule n'est pas une échappatoire : elle impose de **conduire et documenter une analyse des risques de cybersécurité** qui justifie, exigence par exigence, celles qui sont retenues et celles qui sont écartées. Une exigence écartée sans justification documentée est une non-conformité. Une exigence écartée avec une analyse de risques argumentée est une décision de conception défendable. La différence entre les deux tient à un document. L'analyse de risques est d'ailleurs une pièce explicitement attendue au [dossier technique](/fr/cra/dossier-technique/). ### Ce qu'il faut produire Une **matrice de traçabilité**, tenue par produit, avec une ligne par exigence : | Colonne | Contenu | | --- | --- | | Exigence | Référence dans l'annexe I | | Applicable ? | Oui / Non, avec renvoi à l'analyse de risques | | Contrôle | La mesure technique ou organisationnelle qui la couvre | | Preuve | L'artefact qui l'atteste — test, configuration, journal, document | | Outil | Ce qui produit la preuve | | Responsable | Nommément | | Dernière vérification | Date | Cette matrice est le document de travail le plus utile du projet : elle sert à l'ingénierie pour savoir quoi construire, au juridique pour constituer le dossier, et à l'auditeur pour vérifier. ### Le lien avec la présomption de conformité Le règlement n'impose aucune solution technique. Il impose des résultats. La **présomption de conformité** permet d'y répondre par l'application de normes harmonisées, de spécifications communes ou de schémas de certification — voir [Évaluation de la conformité](/fr/cra/evaluation-de-conformite/). En l'absence de norme harmonisée publiée, il reste possible de démontrer la conformité par d'autres moyens : c'est simplement plus long à documenter, et cela ferme la voie du module A pour les produits de classe I. ## Sécurité du produit (annexe I, partie I) URL: https://cra-reference.eu/fr/cra/exigences-essentielles/securite-des-produits/ Description: Les treize exigences de conception : configuration sécurisée par défaut, absence de vulnérabilité exploitable connue, chiffrement, intégrité, minimisation des données, journalisation, effacement sécurisé. Audience: cyber Legal basis: Annexe I, partie I · Art. 13, paragraphes 1 à 3 — analyse de risques Published 2026-08-19, updated 2026-08-19 ### L'exigence chapeau Les produits comportant des éléments numériques sont **conçus, développés et fabriqués de manière à garantir un niveau de cybersécurité approprié au regard des risques**. Tout le reste en découle. « Approprié au regard des risques » signifie que la référence n'est pas un catalogue universel de mesures, mais **votre analyse de risques documentée**. ### Les exigences, une par une #### Absence de vulnérabilité exploitable connue Le produit est mis à disposition **sans vulnérabilité exploitable connue**. Cela suppose un contrôle bloquant en fin de chaîne de construction, alimenté par le [SBOM](/fr/sbom/) et par les sources de vulnérabilités — voir [Intégration CI/CD](/fr/cyber/integration-cicd/). #### Configuration sécurisée par défaut Le produit est livré dans une **configuration sécurisée par défaut**, avec la possibilité de le **réinitialiser à son état d'origine**. Concrètement : pas de mot de passe par défaut partagé, pas de service exposé sans nécessité, pas de compte de maintenance actif. #### Correction par des mises à jour de sécurité Les vulnérabilités peuvent être corrigées par des **mises à jour de sécurité**, y compris, lorsque c'est approprié, par des **mises à jour automatiques activées par défaut**, assorties d'un mécanisme de refus clair, d'une information sur les mises à jour disponibles et de la possibilité de les différer. #### Protection contre les accès non autorisés Protection par des **mécanismes de contrôle appropriés** — authentification, gestion des identités et des accès — et **signalement des accès non autorisés**. #### Confidentialité Protection de la **confidentialité** des données stockées, transmises ou traitées, par **chiffrement au repos et en transit** au moyen de mécanismes de l'état de l'art. #### Intégrité Protection de l'**intégrité** des données, commandes, programmes et configurations contre toute manipulation ou modification non autorisée, et **signalement des corruptions**. #### Minimisation des données Ne traiter que les données **adéquates, pertinentes et limitées à ce qui est nécessaire** au regard de la destination du produit. Exigence miroir du RGPD, mais ici indépendante du caractère personnel des données. #### Disponibilité des fonctions essentielles Protection de la **disponibilité des fonctions essentielles et de base**, y compris la résilience et l'atténuation des attaques par déni de service. #### Non-nuisance aux autres systèmes **Minimisation de l'impact négatif** du produit sur la disponibilité des services fournis par d'autres dispositifs ou réseaux — un produit ne doit pas devenir un relais d'attaque. #### Limitation des surfaces d'attaque **Limitation des surfaces d'attaque**, interfaces externes comprises : services désactivés, ports fermés, fonctions de débogage retirées des versions de production. #### Réduction de l'impact des incidents Utilisation de **techniques et mécanismes appropriés d'atténuation de l'exploitation** : cloisonnement, moindre privilège, durcissement du binaire, protections mémoire. #### Journalisation et surveillance Fourniture d'informations liées à la sécurité par l'**enregistrement et la surveillance des activités internes pertinentes**, y compris les accès aux données, services et fonctions et leurs modifications, avec **possibilité de désactivation par l'utilisateur**. #### Effacement et portabilité sécurisés Possibilité pour les utilisateurs de **supprimer de façon sûre et permanente** toutes les données et tous les paramètres, et, lorsque ces données peuvent être transférées vers d'autres produits ou systèmes, de le faire de manière sécurisée. ### Ce qui rend ces exigences vérifiables Aucune de ces exigences n'est vérifiable telle quelle. Chacune doit être traduite en **critère de test** : | Exigence | Critère de test typique | | --- | --- | | Pas de vulnérabilité exploitable connue | Analyse de composition logicielle bloquante, seuil défini, VEX pour les exceptions | | Configuration sécurisée par défaut | Référentiel de durcissement, test d'installation depuis l'état d'usine | | Chiffrement | Inventaire des flux et des stockages, vérification des suites cryptographiques | | Intégrité | Vérification de signature au démarrage et à la mise à jour, test de retour arrière | | Surface d'attaque | Cartographie des ports et interfaces, écart avec la spécification | | Journalisation | Vérification de la présence des événements attendus, test de désactivation | | Effacement | Test de réinitialisation, vérification de non-récupérabilité | Cette table est le point d'entrée de la matrice de traçabilité décrite dans [Exigences essentielles](/fr/cra/exigences-essentielles/). ### Référentiels mobilisables En attendant les normes harmonisées, plusieurs référentiels couvrent une large part de ces exigences et fournissent des preuves réutilisables : **IEC 62443-4-1** (processus de développement sécurisé) et **62443-4-2** (exigences techniques des composants), **[NIST SP 800-218](https://csrc.nist.gov/pubs/sp/800/218/final)** (*Secure Software Development Framework*), **[ETSI EN 303 645](https://www.etsi.org/deliver/etsi_en/303600_303699/303645/)** (objets connectés grand public), **EN 18031-1/-2/-3** (équipements radio), **ISO/IEC 27001**. Attention : appliquer ces référentiels ne confère **aucune présomption de conformité** au sens du règlement tant qu'ils ne sont pas des normes harmonisées citées au *Journal officiel*. Ils facilitent la démonstration, ils ne la remplacent pas. ## Traitement des vulnérabilités (annexe I, partie II) URL: https://cra-reference.eu/fr/cra/exigences-essentielles/traitement-des-vulnerabilites/ Description: Les huit obligations de processus : SBOM, correction sans délai, tests réguliers, publication des avis, politique CVD, partage d'informations, diffusion sécurisée et gratuite des correctifs. Audience: cyber Legal basis: Annexe I, partie II, points 1 à 8 · Art. 13, paragraphes 5 et 6 — diligence sur les composants tiers Published 2026-08-19, updated 2026-08-19 C'est ici que le SBOM devient une **obligation légale**, et c'est la partie de l'annexe I qui engage sur la durée : elle décrit un processus à tenir pendant toute la [période de support](/fr/cra/support-et-cycle-de-vie/). ### Les huit obligations #### 1. Recenser et documenter — le SBOM > Recenser et documenter les vulnérabilités et les composants contenus dans le produit, > **notamment en établissant une nomenclature logicielle dans un format couramment utilisé > et lisible par machine, couvrant au minimum les dépendances de premier niveau**. Le détail est traité dans [Ce que le CRA exige du SBOM](/fr/sbom/exigence-cra/). Retenir que « premier niveau » est un **plancher légal**, et que la Commission peut préciser par acte d'exécution le format et les éléments attendus. #### 2. Traiter et corriger sans délai Traiter et corriger les vulnérabilités **sans délai**, notamment par la fourniture de mises à jour de sécurité. Lorsque c'est **techniquement possible**, les mises à jour de sécurité sont fournies **séparément** des mises à jour fonctionnelles. Cette séparation a une conséquence d'ingénierie lourde : elle suppose des **branches de maintenance** et une capacité de rétroportage, donc une stratégie de versionnement décidée dès la conception. Voir [Mises à jour sécurisées](/fr/cyber/mises-a-jour-securisees/). #### 3. Tester et revoir régulièrement Appliquer des **tests et des revues de sécurité efficaces et réguliers**. « Régulier » implique une cadence définie et tenue, pas un test à la sortie d'une version majeure. #### 4. Publier l'information sur les vulnérabilités corrigées Une fois une mise à jour de sécurité disponible, **publier des informations sur les vulnérabilités corrigées** : description, identification des produits concernés, impacts, gravité, et informations aidant les utilisateurs à remédier. En pratique : des **avis de sécurité** publiés, idéalement au format **[CSAF 2.0](https://www.csaf.io/)**, lisibles par machine pour que vos clients puissent les traiter automatiquement. #### 5. Mettre en place et faire appliquer une politique CVD Mettre en place **et faire appliquer** une politique de **divulgation coordonnée des vulnérabilités**. Les deux verbes comptent : une politique publiée mais sans traitement des signalements reçus ne satisfait pas l'exigence. Voir [Politique CVD](/fr/cyber/politique-cvd/). #### 6. Faciliter le partage d'informations Prendre des mesures pour **faciliter le partage d'informations** sur les vulnérabilités potentielles du produit et des composants tiers qu'il contient, notamment en fournissant une **adresse de contact**. #### 7. Diffuser les mises à jour de manière sécurisée Prévoir des **mécanismes de diffusion sécurisée** des mises à jour, garantissant que les vulnérabilités sont corrigées ou atténuées en temps utile et, lorsque c'est applicable pour les correctifs de sécurité, **de manière automatique**. #### 8. Diffuser sans délai et gratuitement Veiller à ce que les correctifs et mises à jour disponibles soient diffusés **sans délai** et, sauf accord contraire pour des produits sur mesure entre professionnels, **gratuitement**, accompagnés de **messages consultatifs** indiquant aux utilisateurs les actions à entreprendre. > **Point souvent manqué.** La gratuité des correctifs de sécurité est une règle, pas une > option commerciale. Facturer un contrat de maintenance pour accéder aux correctifs de > sécurité pendant la période de support est incompatible avec cette exigence. ### La diligence sur les composants tiers Deux obligations complémentaires, à l'article 13, encadrent l'usage de composants que vous n'écrivez pas — y compris libres : - **Diligence raisonnable à l'intégration** : évaluer la qualité et la maintenance du composant, vérifier l'absence de vulnérabilités exploitables connues, examiner l'historique de sécurité, la fréquence des publications et la licence. Cette diligence doit être **documentée**. - **Remontée à l'amont** : lorsqu'une vulnérabilité est identifiée dans un composant, y compris libre, la **signaler à la personne ou à l'entité qui fabrique ou maintient ce composant**, la corriger et — lorsque c'est pertinent — **partager le correctif avec le projet amont**. Voir [Intégrer de l'open source](/fr/cra/open-source/integrer-de-l-oss/). ### La preuve à constituer | Obligation | Artefact de preuve | | --- | --- | | 1 | SBOM par version, signé et archivé | | 2 | Journal de traitement horodaté, délais mesurés par criticité, branches de correctifs | | 3 | Rapports de tests datés, plan de test, couverture | | 4 | Avis de sécurité publiés, historique consultable | | 5 | Politique CVD publiée, registre des signalements reçus et de leur traitement | | 6 | Adresse de contact active, `security.txt`, accusés de réception | | 7 | Description du mécanisme, clés de signature, tests de mise à jour | | 8 | Historique des publications, messages consultatifs, preuve de gratuité | ## Le marquage CE URL: https://cra-reference.eu/fr/cra/marquage-ce/ Description: Ce que le marquage signifie juridiquement, les sept conditions cumulatives préalables à son apposition, les règles de pose pour un logiciel, et le point de blocage commercial. Audience: legal Legal basis: Art. 29 — principes généraux du marquage CE · Art. 30 — règles et conditions d'apposition · Art. 28 — déclaration UE de conformité Published 2026-08-19, updated 2026-08-19 ### Ce que le marquage CE est — et n'est pas Le marquage CE est la **déclaration du fabricant, sous sa seule responsabilité**, que le produit satisfait à toutes les exigences applicables des législations d'harmonisation de l'Union qui en prévoient l'apposition. Il n'est **pas** un label de qualité, **pas** une certification, **pas** une garantie d'absence de vulnérabilité, et **pas** délivré par une autorité. C'est une affirmation unilatérale, opposable, et sanctionnable si elle est fausse. ### Les sept conditions cumulatives Avant toute apposition, dans cet ordre : 1. les **exigences essentielles** de l'annexe I applicables sont satisfaites ; 2. une **analyse des risques de cybersécurité** a été réalisée et documentée ; 3. le **dossier technique** de l'annexe VII est constitué, **SBOM inclus** ; 4. la **procédure d'évaluation de la conformité** applicable à la classe du produit a été suivie jusqu'à son terme ; 5. la **déclaration UE de conformité** de l'annexe V est établie et signée ; 6. les **informations et instructions à l'utilisateur** de l'annexe II sont fournies avec le produit ; 7. l'**identification du fabricant** et le **point de contact** pour le signalement de vulnérabilités figurent sur le produit, son emballage ou sa documentation. Une seule condition manquante suffit à rendre l'apposition irrégulière. ### Les règles d'apposition - **Visible, lisible et indélébile.** Si la nature du produit ne le permet pas, sur l'emballage et sur les documents d'accompagnement. - **Pour un produit logiciel** : sur la **déclaration UE de conformité** et, le cas échéant, sur le **site web** accompagnant le produit, à un emplacement facilement accessible depuis la page de téléchargement ou d'achat. - **Avant** la mise sur le marché. - Lorsqu'un **organisme notifié** est intervenu dans la phase de contrôle de la production, son **numéro d'identification** est apposé **à la suite** du marquage CE — par l'organisme lui-même ou par le fabricant sur ses instructions. - Aucun marquage, signe ou inscription susceptible d'induire en erreur des tiers sur la signification ou la forme du marquage CE ne doit être apposé à ses côtés. ### Le point de blocage commercial **Pas de marquage CE = pas de mise sur le marché de l'Union.** C'est la phrase qui rend le sujet compréhensible en comité de direction. La conséquence organisationnelle est directe : la fonction juridique est **propriétaire du processus de marquage** et doit disposer d'un **droit de veto formel** sur la mise sur le marché. Ce veto se matérialise par un **procès-verbal de revue de conformité**, signé avant apposition, qui reprend les quinze points de la [liste de contrôle](/fr/legal/checklist-mise-sur-le-marche/) et nomme les responsables de chaque pièce. ### Erreurs fréquentes | Erreur | Conséquence | | --- | --- | | Apposer le marquage « par anticipation », en attendant que le dossier soit complet | Non-conformité formelle **et** déclaration inexacte | | Réutiliser la déclaration d'une version antérieure sans la mettre à jour | La déclaration ne couvre pas le produit réellement mis sur le marché | | Omettre le numéro de l'organisme notifié alors qu'il est intervenu | Non-conformité formelle | | Apposer le marquage sur un produit hors périmètre du CRA | Marquage trompeur | | Considérer le marquage acquis une fois pour toutes | Toute **modification substantielle** rouvre la procédure | ## Le logiciel libre et open source URL: https://cra-reference.eu/fr/cra/open-source/ Description: Le critère n'est pas la licence mais la nature commerciale de la mise à disposition. Quatre statuts, du contributeur individuel hors périmètre au fabricant pleinement responsable. Audience: transverse Legal basis: Art. 2 — champ d'application · Art. 3, point 14 — définition du sponsor de logiciel libre · Art. 24 — obligations des sponsors de logiciel libre · Art. 25 — attestations de conformité volontaires Published 2026-08-19, updated 2026-08-19 Le traitement du logiciel libre est la partie du règlement la plus commentée et la plus mal comprise. Une seule idée en commande la lecture : > **Le critère discriminant n'est pas la licence, c'est la nature commerciale de la mise à > disposition.** Une licence libre ne fait pas sortir du champ ; une activité non > commerciale, oui. ### Les quatre statuts | Statut | Qui | Régime | | --- | --- | --- | | **[Développeur ou contributeur individuel](/fr/cra/open-source/developpeur-individuel/)** | Personne physique ou entité développant du libre **hors activité commerciale** | **Hors périmètre.** Aucune obligation. | | **[Sponsor de logiciel libre](/fr/cra/open-source/sponsor-oss/)** (*open-source software steward*) | Personne morale, autre qu'un fabricant, soutenant de façon **systématique et durable** le développement de produits libres destinés à des activités commerciales, et assurant leur viabilité | **Régime allégé** : politique de cybersécurité, coopération, signalement. Ni marquage CE, ni dossier technique, ni amendes. | | **[Fabricant intégrant de l'open source](/fr/cra/open-source/integrer-de-l-oss/)** | Vous, dans la très grande majorité des cas | **Régime complet**, avec obligation de **diligence** sur les composants tiers et de **remontée à l'amont**. | | **Fabricant distribuant un produit libre commercialement** | Éditeur monétisant un logiciel libre | **Régime complet**, comme tout fabricant. | ### Pourquoi le législateur a procédé ainsi Le raisonnement, utile à connaître pour argumenter en interne : soumettre l'écosystème libre aux obligations des fabricants aurait rendu impossible la contribution bénévole, tout en laissant intacte la responsabilité de ceux qui en tirent une valeur commerciale. Le règlement fait donc porter la charge **sur celui qui met le produit sur le marché**, pas sur celui qui écrit le code en amont. Corollaire : **vous ne pouvez pas reporter votre responsabilité sur l'amont**. Le mainteneur d'une bibliothèque que vous intégrez ne répond de rien à votre place. ### Les points d'attention pour votre organisation **Vos salariés contribuent-ils à l'amont sur leur temps de travail ?** Si oui, dans quel cadre, et cela vous qualifie-t-il de sponsor pour certains projets ? Une politique interne de contribution doit trancher la question et être documentée. **Publiez-vous vous-mêmes des projets libres ?** S'ils sont mis à disposition hors activité commerciale, ils sont hors périmètre. S'ils accompagnent une offre commerciale, la qualification doit être examinée produit par produit. **Portez-vous ou financez-vous une fondation ?** Le statut de sponsor de logiciel libre peut alors être en cause, avec ses obligations propres — allégées mais réelles. ### Les attestations de conformité volontaires Le règlement prévoit un mécanisme d'**attestation de conformité volontaire** : un développeur ou un utilisateur de logiciel libre peut établir, à titre volontaire, une attestation relative aux propriétés de sécurité du composant. Ces attestations n'engagent pas leur auteur comme une déclaration de conformité, mais elles constituent un élément utile à la **diligence** des intégrateurs en aval. Pour vous, elles ont deux usages : les **consommer** — une attestation amont enrichit votre dossier de diligence — et éventuellement en **produire** pour les composants que vous publiez, ce qui facilite l'adoption de vos briques par d'autres fabricants soumis au CRA. ## Développeur et contributeur individuels URL: https://cra-reference.eu/fr/cra/open-source/developpeur-individuel/ Description: Ce qui fait, ou ne fait pas, basculer une activité libre dans le champ commercial : dons, forge, support facturé, financement d'entreprise, et la question de vos propres contributions. Audience: legal Legal basis: Art. 2 — champ d'application Published 2026-08-19, updated 2026-08-19 ### La règle Le logiciel libre et open source **non fourni dans le cadre d'une activité commerciale** est hors du champ du règlement. Aucune obligation ne pèse sur le développeur, personne physique ou morale, qui met son travail à disposition dans ce cadre. Toute la difficulté tient à la frontière du « commercial ». ### Ce qui ne suffit pas à qualifier une activité commerciale Les considérants du règlement écartent explicitement plusieurs situations : - **contribuer** à un projet libre, même de façon régulière et importante ; - **héberger** le code sur une forge ou un dépôt public, y compris avec des services payants pour le mainteneur ; - **accepter des dons** destinés à couvrir les frais de développement ou d'infrastructure ; - facturer de simples **services accessoires** — support technique, conseil, formation — distincts de la fourniture du logiciel lui-même ; - **collaborer** avec des entreprises qui utilisent le logiciel, y compris en intégrant leurs contributions. ### Ce qui bascule L'activité devient commerciale lorsque le logiciel lui-même est fourni dans une relation d'affaires. Les indices convergents : - le logiciel est **facturé**, sous quelque forme que ce soit — licence, abonnement, accès ; - le développement est réalisé **contre rémunération** dans le cadre d'une relation commerciale identifiée ; - le logiciel libre sert de **produit d'appel** à une offre payante liée, du type édition entreprise ou fonctionnalités réservées ; - l'entité **intègre** le logiciel dans un produit qu'elle met sur le marché — mais alors elle est **fabricant**, ce qui est un autre statut. ### Le cas de vos propres contributions Trois situations doivent être tranchées par une politique interne écrite. **1. Un salarié contribue à un projet amont, sur son temps de travail, pour corriger un défaut qui vous affecte.** C'est le cas le plus fréquent et le plus sain. Il ne vous qualifie ni de fabricant du projet amont, ni de sponsor : vous restez un utilisateur qui contribue. Le règlement encourage d'ailleurs explicitement le partage à l'amont des correctifs de sécurité — voir [Intégrer de l'open source](/fr/cra/open-source/integrer-de-l-oss/). **2. Vous publiez un projet libre issu de vos travaux, sans offre commerciale associée.** Hors périmètre tant que la mise à disposition reste non commerciale. À réexaminer si une offre payante vient s'y adosser. **3. Vous financez durablement le développement d'un projet libre dont vous ne êtes pas le fabricant, et vous en assurez la viabilité.** C'est la définition du **sponsor de logiciel libre** : voir la [page dédiée](/fr/cra/open-source/sponsor-oss/). ### Ce qu'il faut écrire Une **politique interne de contribution open source**, courte, qui répond à : - Dans quels cas un salarié peut-il contribuer à un projet amont sur son temps de travail ? - Sous quelle identité — personnelle ou de l'entreprise ? - Qui autorise la publication d'un nouveau projet libre par l'entreprise ? - Qui vérifie, avant publication, que le projet ne bascule pas dans une qualification commerciale non voulue ? - Comment sont documentées vos remontées de correctifs de sécurité à l'amont, qui sont attendues par le règlement et constituent une preuve de diligence ? Cette politique relève du juridique, mais elle est appliquée par l'ingénierie : elle doit tenir en une page. ## Intégrer de l'open source URL: https://cra-reference.eu/fr/cra/open-source/integrer-de-l-oss/ Description: Votre situation la plus fréquente : la responsabilité réglementaire intégrale, l'obligation de diligence documentée, la remontée des correctifs à l'amont et le traitement des composants abandonnés. Audience: cyber Legal basis: Art. 13, paragraphe 5 — diligence sur les composants tiers · Art. 13, paragraphe 6 — signalement à l'amont et partage du correctif · Annexe I, partie II Published 2026-08-19, updated 2026-08-19 ### La règle centrale Lorsque vous intégrez un composant libre dans un produit que vous mettez sur le marché, **vous en portez la responsabilité réglementaire intégrale**. L'amont n'est pas responsable à votre place, et ce quelle que soit la licence. C'est la conséquence directe de l'architecture du règlement : la responsabilité suit la **mise sur le marché**, pas l'écriture du code. ### L'obligation de diligence Le fabricant doit faire preuve de **diligence raisonnable lorsqu'il intègre des composants provenant de tiers**, y compris des composants libres, afin que ces composants ne compromettent pas la cybersécurité du produit. Cette diligence doit être **documentée**, composant par composant, pour être opposable. #### Grille de diligence | Critère | Ce qu'on vérifie | Source | | --- | --- | --- | | **Vulnérabilités connues** | Absence de vulnérabilité exploitable connue non corrigée | EUVD, OSV, NVD, avis amont | | **Activité du projet** | Fréquence des publications, date du dernier commit, nombre de mainteneurs actifs | Dépôt | | **Gouvernance** | Projet porté par une fondation ou un [sponsor](/fr/cra/open-source/sponsor-oss/) ? Mainteneur unique ? | Documentation du projet | | **Politique de sécurité amont** | Existence d'un `SECURITY.md`, d'un canal de signalement, d'un historique d'avis | Dépôt | | **Réactivité historique** | Délai moyen entre signalement et correctif sur les vulnérabilités passées | Historique des avis | | **Licence** | Identifiant SPDX, famille, compatibilité avec votre politique | [Familles de licences](/fr/licences/familles/) | | **SBOM amont** | Le projet publie-t-il lui-même un SBOM ? | Publications du projet | | **Signature des artefacts** | Les publications sont-elles signées et vérifiables ? | Publications | | **Profondeur** | Nombre et nature des dépendances transitives introduites | Analyse | Un score composite permet de trancher entre adopter, adopter sous surveillance, ou refuser. La grille remplie est versée au dossier de diligence du produit. > **Cette grille est inapplicable à la main au-delà de quelques dizaines de composants**, et un > graphe de dépendances réel en compte des milliers. Six de ces neuf critères se calculent > automatiquement : voir > **[Évaluer un composant open source](/fr/cyber/evaluer-un-composant/)**, qui décrit > l'outillage, ce qu'il couvre, ce qu'il ne dit pas, et la politique de seuils à écrire. ### L'obligation de remontée à l'amont Lorsque vous identifiez une vulnérabilité dans un composant intégré, y compris libre, vous devez : 1. la **signaler à la personne ou à l'entité qui fabrique ou maintient** ce composant ; 2. **traiter et corriger** la vulnérabilité dans votre produit ; 3. lorsque c'est pertinent, **partager avec le projet amont le correctif** que vous avez développé. C'est une obligation, pas une bonne pratique. Elle suppose un processus outillé : - un **canal identifié** vers chaque projet amont critique — adresse de sécurité, procédure de signalement privé ; - un **journal des remontées** : date, projet, vulnérabilité, contenu du signalement, réponse obtenue, correctif partagé ; - une **politique de contribution** qui autorise vos ingénieurs à publier un correctif sous la licence du projet amont, sans passer par une validation juridique de plusieurs semaines qui rendrait l'obligation intenable. > **Point de friction fréquent.** Une politique de propriété intellectuelle interdisant > toute publication de code par les salariés rend impossible le respect de cette obligation. > Les deux politiques doivent être réconciliées explicitement, par écrit. ### Les composants abandonnés Un composant non maintenu dans un produit couvert par une période de support de cinq ans est une **dette réglementaire** : il n'y aura personne, en amont, pour corriger la prochaine vulnérabilité. Quatre stratégies, à décider produit par produit et à documenter : | Stratégie | Quand | Coût | | --- | --- | --- | | **Remplacer** | Une alternative maintenue existe | Coût de migration, ponctuel | | **Forker et maintenir** | Pas d'alternative, composant central | Coût récurrent, sur toute la période de support | | **Internaliser** | Le composant est petit et son périmètre stable | Coût de reprise, puis maintenance | | **Contribuer à sa relance** | Le projet est viable mais sous-doté | Coût récurrent, résultat non garanti | La stratégie « ne rien faire et espérer » n'est pas défendable devant une autorité, puisque la fin de maintenance amont est un fait public et donc connu de vous. ### Le point de vigilance de la reprise malveillante Un composant abandonné dont le contrôle est repris par un tiers est un vecteur documenté d'attaque de chaîne d'approvisionnement. La surveillance du **changement de mainteneur** sur les dépendances critiques fait partie de la diligence continue — voir [Risques de chaîne d'approvisionnement](/fr/cyber/risques-supply-chain/). ## Le sponsor de logiciel libre URL: https://cra-reference.eu/fr/cra/open-source/sponsor-oss/ Description: L'open-source software steward : définition, obligations effectivement dues, ce à quoi il n'est pas soumis — y compris les amendes — et la grille d'auto-qualification. Audience: legal Legal basis: Art. 3, point 14 — définition · Art. 24 — obligations des sponsors de logiciel libre · Art. 14, paragraphes 1 et 3 — signalement · Art. 64 — sanctions (exclusion des sponsors) Published 2026-08-19, updated 2026-08-19 C'est la véritable nouveauté du CRA en matière d'open source : la création d'un statut intermédiaire entre le contributeur bénévole, hors périmètre, et le fabricant, pleinement responsable. ### La définition Un **sponsor de logiciel libre** (*open-source software steward*) est une **personne morale, autre qu'un fabricant**, dont l'objet ou la finalité est de fournir un **soutien de manière systématique et durable** au développement de **produits comportant des éléments numériques spécifiques, qualifiés de logiciels libres et open source et destinés à des activités commerciales**, et qui **assure la viabilité** de ces produits. Quatre éléments cumulatifs, chacun discriminant : | Élément | Ce qu'il écarte | | --- | --- | | **Personne morale, autre qu'un fabricant** | Les personnes physiques ; celui qui met le produit sur le marché est fabricant, pas sponsor | | **Soutien systématique et durable** | Le financement ponctuel, le mécénat occasionnel, la contribution épisodique | | **Produits destinés à des activités commerciales** | Les projets purement académiques ou de loisir | | **Assure la viabilité** | Le simple hébergement ou la mise en relation | Les entités visées sont principalement les **fondations logicielles** — Apache, Eclipse, Linux Foundation et leurs équivalents — et certaines structures de financement pérenne du code. ### Les obligations effectivement dues La liste est **limitative**. Un sponsor doit : 1. **mettre en place et documenter, de manière vérifiable, une politique de cybersécurité** visant à favoriser le développement d'un produit sûr et le traitement efficace des vulnérabilités, **adaptée à la nature de l'entité et à ses moyens** ; 2. **coopérer avec les autorités de surveillance du marché**, à leur demande, pour atténuer les risques de cybersécurité des produits concernés ; 3. respecter les **obligations de signalement** relatives aux **vulnérabilités activement exploitées** et aux **incidents graves** ayant une incidence sur la sécurité du produit, **dans la mesure où il participe au développement** de ce produit ; 4. fournir, à la demande des autorités, les **informations nécessaires** dans une langue aisément compréhensible. Le membre de phrase « adaptée à la nature de l'entité et à ses moyens » est essentiel : une fondation de trois salariés n'est pas tenue au même dispositif qu'une structure de deux cents personnes. ### Ce à quoi le sponsor n'est PAS soumis | Obligation du fabricant | Sponsor | | --- | --- | | Marquage CE | **Non** | | Déclaration UE de conformité | **Non** | | Dossier technique de l'annexe VII | **Non** | | Procédure d'évaluation de la conformité | **Non** | | Exigences essentielles de l'annexe I comme telles | **Non** — remplacées par la politique de cybersécurité | | Période de support de cinq ans | **Non** | | Informations à l'utilisateur de l'annexe II | **Non** | | **Amendes administratives** | **Non** — le régime de sanctions pécuniaires ne s'applique pas aux sponsors | L'exclusion des amendes administratives est le point le plus commenté. Elle ne signifie pas l'absence de conséquence : les autorités de surveillance du marché conservent leurs pouvoirs d'injonction et de coopération, et la réputation d'une fondation est son actif principal. ### La grille d'auto-qualification Répondre par oui ou non, pour chaque structure que vous portez ou financez : - [ ] La structure est-elle une **personne morale** distincte ? - [ ] Est-elle **autre qu'un fabricant** du produit concerné — c'est-à-dire ne le met-elle pas elle-même sur le marché ? - [ ] Son objet ou sa finalité inclut-il le **soutien au développement** de logiciels libres identifiés ? - [ ] Ce soutien est-il **systématique et durable**, et non ponctuel ? - [ ] Les logiciels concernés sont-ils **destinés à des activités commerciales**, c'est-à-dire utilisés dans des produits mis sur le marché par des tiers ? - [ ] La structure **assure-t-elle la viabilité** de ces logiciels — gouvernance, financement, maintien dans le temps ? Six réponses positives : le statut de sponsor est probablement caractérisé, et les quatre obligations ci-dessus s'appliquent. Une seule négative : le statut ne l'est pas, mais la qualification doit être réexaminée si la situation évolue. ### Ce que cela change pour vous en tant qu'intégrateur Un composant maintenu par un sponsor identifié offre une garantie supérieure à un composant maintenu par une personne isolée : il existe une politique de cybersécurité documentée, un canal de signalement et une obligation de coopération. C'est un **critère de sélection** à intégrer dans la grille de diligence — voir [Intégrer de l'open source](/fr/cra/open-source/integrer-de-l-oss/). ## Le périmètre : les produits comportant des éléments numériques URL: https://cra-reference.eu/fr/cra/perimetre-pde/ Description: Définition du PDE, décomposition matériel / logiciel / traitement de données à distance, critères déclencheurs, notions de mise sur le marché et de modification substantielle. Audience: legal Legal basis: Art. 2 — champ d'application · Art. 3, points 1 et 2 — définitions · Art. 69 — dispositions transitoires Published 2026-08-19, updated 2026-08-19 C'est la première question, et elle conditionne tout le reste : **êtes-vous concernés, et pour quels produits ?** ### La définition Un **produit comportant des éléments numériques** (PDE, en anglais *product with digital elements*) est *un produit logiciel ou matériel et ses solutions de traitement de données à distance, y compris les composants logiciels ou matériels destinés à être mis sur le marché séparément* (art. 3, point 1). Trois éléments, à examiner séparément. #### Le matériel Ordinateurs, serveurs, objets connectés, équipements réseau, capteurs, cartes, puces, automates industriels, terminaux de paiement, équipements médicaux non couverts par le règlement sectoriel, jouets connectés. #### Le logiciel Systèmes d'exploitation, applications, micrologiciels (*firmware*), bibliothèques, intergiciels, pilotes — **y compris les composants mis sur le marché séparément**. Ce dernier point est structurant : une bibliothèque que vous commercialisez seule est elle-même un PDE, avec son propre dossier technique et son propre marquage CE. #### Les solutions de traitement de données à distance *Traitement de données à distance conçu et développé par le fabricant, ou sous la responsabilité de celui-ci, dont l'absence empêcherait le produit comportant des éléments numériques d'exécuter l'une de ses fonctions* (art. 3, point 2). C'est la porte d'entrée du cloud dans le CRA. Le critère est la **dépendance fonctionnelle** : si l'objet connecté cesse d'exécuter une de ses fonctions quand le back-end tombe, ce back-end est dans le périmètre du produit. ### Le SaaS : oui ou non ? C'est la question la plus posée, et la réponse est en deux temps. | Cas | Régime | | --- | --- | | Application SaaS autonome, vendue comme service, sans produit associé | **Hors périmètre CRA.** Relève, le cas échéant, de la directive NIS 2 en tant que service de l'entité. | | Back-end indissociable d'un produit connecté que vous vendez | **Dans le périmètre**, en tant que solution de traitement de données à distance du produit. | | Logiciel téléchargeable installé chez le client, même vendu par abonnement | **Dans le périmètre** : c'est un produit logiciel, le modèle de facturation est indifférent. | | Portail d'administration facultatif, dont l'absence ne prive le produit d'aucune fonction | À qualifier au cas par cas ; l'absence de dépendance fonctionnelle plaide pour l'exclusion. | Le modèle économique n'est jamais le critère. Le critère est la **nature de ce qui est mis à disposition** et sa **dépendance fonctionnelle** au produit. ### Les critères déclencheurs, cumulatifs Un produit relève du règlement lorsque les trois conditions suivantes sont réunies : 1. il est **mis à disposition sur le marché de l'Union**, quel que soit le lieu d'établissement du fabricant ; 2. dans le cadre d'une **activité commerciale** ; 3. il présente une **connexion logique ou physique, directe ou indirecte**, à un dispositif ou à un réseau. La connexion « indirecte » est large : un produit qui ne se connecte lui-même à rien, mais qui échange des données avec un autre produit lui-même connecté, satisfait le critère. ### Trois notions de vocabulaire à ne pas confondre - **Mise sur le marché** — la **première** mise à disposition d'un produit sur le marché de l'Union. C'est l'instant où s'apprécie la conformité. - **Mise à disposition sur le marché** — toute fourniture ultérieure, dans le cadre d'une activité commerciale, à titre onéreux ou gratuit. - **Mise en service** — la première utilisation conforme à sa destination. Le point de bascule est le suivant : la conformité aux exigences essentielles s'apprécie **au moment de la mise sur le marché**, mais le traitement des vulnérabilités et la fourniture de mises à jour courent **pendant toute la période de support**. ### La modification substantielle Une modification est **substantielle** lorsqu'elle change la destination du produit ou qu'elle affecte sa conformité aux exigences essentielles. Elle **remet le produit dans le périmètre** et déclenche une nouvelle évaluation de la conformité, un dossier technique actualisé et, le cas échéant, une nouvelle intervention de l'organisme notifié. Cette notion porte tout le régime transitoire : > Les produits mis sur le marché **avant le 11 décembre 2027** ne sont soumis au règlement > que s'ils font ensuite l'objet d'une modification substantielle — **à l'exception des > obligations de signalement de l'article 14, qui s'appliquent à tous les produits dans le > champ du règlement, y compris ceux déjà sur le marché.** Autrement dit : votre parc historique échappe au marquage CE, mais **pas** au signalement à 24 heures depuis le 11 septembre 2026. C'est le point le plus souvent manqué. Une mise à jour de sécurité destinée à corriger une vulnérabilité, sans autre changement, n'est pas une modification substantielle. ### Ce qu'il faut produire Une **fiche de qualification** par produit, versée au dossier technique et signée, qui tranche explicitement : nature du produit, existence d'une connexion, existence d'une solution de traitement de données à distance, caractère commercial, statut PDE, date et signataire. Un tableau consolidé du portefeuille en découle. Les produits qualifiés PDE passent ensuite par [Les exclusions](/fr/cra/exclusions/), puis par [Les classes de criticité](/fr/cra/classes-de-criticite/). ## Le règlement (UE) 2024/2847 URL: https://cra-reference.eu/fr/cra/reglement-2024-2847/ Description: Identité, nature juridique, objectifs et structure du règlement sur la cyberrésilience, avec les repères de publication et les sources officielles à citer. Audience: legal Legal basis: Règlement (UE) 2024/2847 · Art. 1 — objet · Art. 71 — entrée en vigueur et application Published 2026-08-19, updated 2026-08-19 ### Comment citer le texte En référence complète, une seule fois par document : > Règlement (UE) 2024/2847 du Parlement européen et du Conseil du 23 octobre 2024 relatif à > des exigences horizontales de cybersécurité pour les produits comportant des éléments > numériques et modifiant les règlements (UE) n° 168/2013 et (UE) 2019/1020 et la directive > (UE) 2020/1828 (règlement sur la cyberrésilience). Ensuite : « le règlement (UE) 2024/2847 » ou « le CRA ». Éviter « la directive CRA » et « la loi CRA », qui sont faux et discréditent le document où ils apparaissent. ### Ce que « règlement » implique concrètement | | Directive (ex. NIS 2) | **Règlement (ex. CRA)** | | --- | --- | --- | | Effet | Doit être transposée en droit national | **Directement applicable** | | Délai national | Un délai de transposition, souvent dépassé | Aucun | | Variations entre États | Possibles, parfois importantes | Marginales | | Texte à lire | La loi nationale de transposition | **Le texte européen lui-même** | Il n'y aura donc pas de « loi française CRA » qui viendrait décaler, atténuer ou préciser l'échéance. Les États membres n'interviennent que sur trois points : la désignation des autorités (surveillance du marché, autorité notifiante, CSIRT coordinateur), la fixation du régime de sanctions dans les plafonds fixés par le règlement, et les mesures de soutien aux petites entreprises. ### La filiation : le « nouveau cadre législatif » Le CRA est une **législation d'harmonisation de l'Union**. Il reprend l'architecture éprouvée des directives et règlements « produits » : 1. des **exigences essentielles** exprimées en objectifs, non en solutions techniques (annexe I) ; 2. une **présomption de conformité** pour qui applique des normes harmonisées ; 3. des **modules d'évaluation de la conformité** gradués selon le risque ; 4. un **dossier technique** et une **déclaration UE de conformité** ; 5. le **marquage CE** comme signal de conformité ; 6. une **surveillance du marché** a posteriori, avec pouvoir de retrait. Deux conséquences pratiques. D'abord, les équipes qui traitent déjà d'autres marquages CE — machines, équipements radio, jouets — connaissent ce vocabulaire : il faut réutiliser leurs processus plutôt que d'en inventer de nouveaux. Ensuite, le règlement ne dit presque jamais *comment* faire : il dit *quel résultat* atteindre, et laisse la preuve au fabricant. ### Les cinq objectifs du législateur Utiles à citer dans une note interne pour justifier l'effort : 1. réduire le nombre de produits vulnérables mis sur le marché de l'Union ; 2. faire assumer aux fabricants la responsabilité de la sécurité **sur tout le cycle de vie**, et pas seulement au moment de la vente ; 3. améliorer la transparence sur les propriétés de sécurité des produits ; 4. permettre aux utilisateurs — entreprises comme consommateurs — de choisir et d'utiliser des produits sûrs ; 5. combler les interstices entre les législations sectorielles existantes. ### Les repères de date | Date | Événement | | --- | --- | | 23 octobre 2024 | Adoption par le Parlement européen et le Conseil | | 20 novembre 2024 | Publication au *Journal officiel de l'Union européenne* | | 10 décembre 2024 | Entrée en vigueur — le texte est définitif, les délais courent | | 11 juin 2026 | Application du chapitre relatif à la notification des organismes d'évaluation de la conformité | | 11 septembre 2026 | Application des obligations de signalement de l'article 14 | | 11 décembre 2027 | Application pleine et entière | Le détail des conséquences opérationnelles de chaque date figure dans [Le calendrier](/fr/cra/calendrier/). ### Les sources à privilégier - **[EUR-Lex — règlement (UE) 2024/2847](https://eur-lex.europa.eu/eli/reg/2024/2847/oj)** — le texte consolidé, seule version faisant foi. Les versions linguistiques ont toutes la même valeur juridique ; en cas de doute sur une formulation française, comparer avec l'anglais. - **[Commission européenne](https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act)** — page dédiée au *Cyber Resilience Act* : orientations, FAQ, actes délégués et d'exécution au fur et à mesure de leur adoption. - **[ENISA](https://www.enisa.europa.eu/)** — plateforme de signalement unique, [base européenne de vulnérabilités](https://euvd.enisa.europa.eu/), documents techniques. - **[CEN et CENELEC](https://www.cencenelec.eu/)** — état d'avancement des normes harmonisées (comité technique mixte JTC 13, groupe de travail 9), qui conditionne la présomption de conformité. - **[ANSSI](https://cyber.gouv.fr/)** — publications nationales sur la mise en œuvre, et **[CERT-FR](https://www.cert.ssi.gouv.fr/)** pour les alertes. > **Ce qui n'est pas une source.** Les billets de blog d'éditeurs de solutions, les > livres blancs commerciaux et les résumés d'intelligence artificielle non vérifiés > circulent beaucoup et contiennent des erreurs récurrentes, notamment sur les classes de > criticité et sur le statut de l'open source. Toute affirmation reprise en interne doit > pouvoir être rattachée à un article ou à une annexe. ## Les acteurs et leurs responsabilités URL: https://cra-reference.eu/fr/cra/roles-et-responsabilites/ Description: Fabricant, mandataire, importateur, distributeur, et la bascule de responsabilité en marque blanche. Les autorités : Commission, ENISA, CSIRT coordinateurs, surveillance du marché, organismes notifiés. Audience: legal Legal basis: Art. 13 — fabricants · Art. 18 — mandataires · Art. 19 — importateurs · Art. 20 — distributeurs · Art. 22 — cas où les obligations du fabricant s'appliquent Published 2026-08-19, updated 2026-08-19 ### Les opérateurs économiques #### Le fabricant Il porte l'essentiel des obligations : concevoir conformément aux exigences essentielles, conduire l'analyse de risques, suivre la procédure d'évaluation, constituer le dossier technique, établir la déclaration UE de conformité, apposer le marquage CE, déterminer et respecter la période de support, traiter les vulnérabilités, signaler, informer les utilisateurs, coopérer avec les autorités, conserver les preuves. Est fabricant toute personne physique ou morale qui **développe ou fabrique** un produit, ou qui le fait concevoir, développer ou fabriquer, et qui le **commercialise sous son propre nom ou sa propre marque**, à titre onéreux ou gratuit. #### Le mandataire Toute personne physique ou morale établie dans l'Union ayant reçu un **mandat écrit** du fabricant pour agir en son nom. Le mandat doit au moins lui permettre de tenir le dossier technique et la déclaration UE de conformité à disposition des autorités, de leur fournir les informations demandées et de coopérer. Un fabricant établi hors de l'Union doit désigner un mandataire. #### L'importateur Il ne met sur le marché que des produits **conformes**. Avant de le faire, il vérifie que la procédure d'évaluation a été suivie, que le fabricant a constitué le dossier technique, que le marquage CE est apposé, que les informations à l'utilisateur sont fournies, et que le point de contact figure sur le produit. Il indique ses propres coordonnées. S'il a des raisons de croire à une non-conformité ou à un risque significatif, il en informe le fabricant et les autorités. #### Le distributeur Il agit avec la **diligence requise** : vérification de la présence du marquage CE, des informations à l'utilisateur et des coordonnées des opérateurs en amont. Il s'abstient de mettre à disposition un produit dont il sait ou devrait savoir qu'il n'est pas conforme. ### La bascule de responsabilité C'est le point le plus exposé pour une organisation qui revend ou personnalise. > Un **importateur ou un distributeur est réputé fabricant** — et assume donc **toutes** les > obligations du fabricant — lorsqu'il met un produit sur le marché **sous son propre nom ou > sa propre marque**, ou lorsqu'il apporte une **modification substantielle** à un produit > déjà mis sur le marché. Conséquences directes pour vos activités : | Situation | Statut | Ce que cela implique | | --- | --- | --- | | Vous revendez un produit tiers **sous sa marque** | Distributeur | Vérifications documentaires | | Vous revendez un produit tiers **sous votre marque** (marque blanche, OEM) | **Fabricant** | Dossier technique, SBOM, marquage CE, période de support, signalement — tout | | Vous intégrez un produit tiers dans votre solution | **Fabricant** de la solution | Idem, plus diligence sur le composant | | Vous modifiez substantiellement un produit tiers | **Fabricant** | Idem, et nouvelle évaluation | | Vous distribuez sans modification, sous la marque d'origine | Distributeur | Vérifications documentaires | Cette table doit être confrontée au catalogue commercial **avant** toute autre action : elle révèle souvent des produits dont personne ne pensait que vous étiez le fabricant. ### Les autorités | Acteur | Rôle | | --- | --- | | **Commission européenne** | Actes délégués (mise à jour des annexes III et IV, obligation de certification des produits critiques) et actes d'exécution (spécifications communes, format du SBOM), orientations | | **[ENISA](https://www.enisa.europa.eu/)** | Opère la **plateforme de signalement unique**, contribue à la **base européenne de vulnérabilités**, produit des rapports techniques et un rapport bisannuel sur les tendances | | **CSIRT désignés coordinateurs** | Destinataires des signalements dans chaque État membre, coordination de la divulgation, possibilité de différer la diffusion d'une notification pour un motif justifié | | **Autorités de surveillance du marché** | Contrôles, demandes de dossier technique, essais, injonctions, restrictions, retraits, rappels | | **ADCO** | Groupe de coopération administrative des autorités de surveillance : coordination, opérations conjointes, contrôles coordonnés | | **Autorités notifiantes** | Désignent, notifient et surveillent les organismes d'évaluation de la conformité | | **Organismes notifiés** | Réalisent les évaluations des modules B, C et H pour les produits qui ne peuvent pas s'auto-évaluer | ### En France Le règlement laisse aux États membres la désignation des autorités. Sont en cause : l'**[ANSSI](https://cyber.gouv.fr/)**, dont le positionnement en tant qu'autorité de surveillance du marché et le **[CERT-FR](https://www.cert.ssi.gouv.fr/)** en tant que CSIRT coordinateur sont les hypothèses les plus documentées, et le cas échéant les administrations compétentes en matière de surveillance du marché des produits. > **Page à tenir à jour.** Les désignations nationales et leurs modalités pratiques — > guichet, format des échanges, langue — sont un point permanent de la > [veille](/fr/actualites/). Ne pas figer ici une organisation qui n'est pas encore > officielle. ## Les sanctions URL: https://cra-reference.eu/fr/cra/sanctions/ Description: Le barème à trois niveaux, les critères de modulation, les sanctions non pécuniaires — souvent plus lourdes que l'amende — et l'articulation avec la responsabilité du fait des produits. Audience: direction Legal basis: Art. 64 — sanctions · Art. 55 à 58 — mesures des autorités de surveillance · Directive (UE) 2024/2853 — responsabilité du fait des produits Published 2026-08-19, updated 2026-08-19 ### Le barème | Manquement | Plafond | | --- | --- | | Non-respect des **exigences essentielles de l'annexe I** et des obligations des **articles 13 et 14** (obligations du fabricant, signalement) | **15 000 000 € ou 2,5 % du chiffre d'affaires annuel mondial total** de l'exercice précédent — le montant le plus élevé étant retenu | | Non-respect de **toute autre obligation** du règlement | **10 000 000 € ou 2 %** | | **Fourniture d'informations incorrectes, incomplètes ou trompeuses** aux organismes notifiés et aux autorités de surveillance du marché | **5 000 000 € ou 1 %** | Deux précisions structurantes : - les **sponsors de logiciel libre ne sont pas passibles d'amendes administratives** — voir [Le sponsor de logiciel libre](/fr/cra/open-source/sponsor-oss/) ; - la situation des **micro, petites et moyennes entreprises**, y compris des jeunes pousses, est prise en compte dans la détermination du montant. Les États membres fixent le régime national de sanctions dans ces plafonds et le notifient à la Commission. ### Les critères de modulation Le montant n'est pas mécanique. Sont pris en compte, notamment : - la **nature, la gravité et la durée** de l'infraction, ainsi que ses conséquences ; - le caractère **intentionnel ou négligent** du manquement ; - les **mesures prises pour atténuer** le préjudice subi par les utilisateurs ; - les **infractions antérieures** du même opérateur ; - le **degré de coopération** avec les autorités ; - les **avantages financiers** tirés du manquement, ou les pertes évitées ; - la **taille** de l'entreprise, notamment s'il s'agit d'une PME. > **Ce que cela dit de votre posture.** Un dossier documenté, des décisions tracées et une > coopération immédiate déplacent le curseur bien plus que la perfection technique. Le > registre des décisions — signaler ou ne pas signaler, corriger ou documenter en VEX — est > la pièce défensive centrale. ### Les sanctions non pécuniaires Elles sont souvent plus lourdes que l'amende, et elles interviennent plus vite. | Mesure | Effet | | --- | --- | | **Injonction de mise en conformité** dans un délai imparti | Mobilisation d'urgence, arbitrages de feuille de route | | **Restriction ou interdiction de mise à disposition** sur le marché de l'Union | Arrêt des ventes | | **Retrait du marché** | Retrait des stocks et des canaux de distribution | | **Rappel** du produit | Coût logistique, coût de remplacement, exposition médiatique | | **Publication de la décision** | Effet réputationnel durable | | **Mesures d'urgence à l'échelle de l'Union** | En cas de risque significatif, via la procédure de sauvegarde | Une interdiction de mise à disposition sur le marché de l'Union pendant quelques mois coûte, pour la plupart des acteurs, plusieurs fois le montant maximal de l'amende. ### Chiffrer votre exposition Le calcul à porter en comité tient en trois lignes : 1. **Exposition administrative** : 2,5 % du chiffre d'affaires consolidé du dernier exercice, comparé à 15 M€ — retenir le plus élevé. 2. **Exposition commerciale** : part du chiffre d'affaires réalisée dans l'Union, multipliée par la durée plausible d'une interdiction de mise à disposition. 3. **Exposition contractuelle** : pénalités et résiliations prévues par vos contrats clients en cas de non-conformité réglementaire. Le détail méthodologique figure dans [Exposition et risques](/fr/legal/sanctions-et-exposition/). ### Responsabilité civile Le CRA se combine avec la **directive (UE) 2024/2853 sur la responsabilité du fait des produits défectueux**, qui inclut désormais explicitement le **logiciel** et prend en compte l'**absence de mises à jour de sécurité** dans l'appréciation du défaut. Conséquence : un manquement au CRA — période de support non tenue, correctif non diffusé, vulnérabilité connue non traitée — devient un **élément à charge** dans une action en responsabilité, indépendamment de toute sanction administrative. ### Assurance Deux points à instruire avec le courtier : - les **clauses d'exclusion** des polices cyber en cas de non-respect d'une obligation réglementaire connue ; - la couverture des **frais de rappel** et de mise en conformité forcée, qui relèvent rarement des polices cyber standard. ## Le signalement à l'ENISA et aux CSIRT URL: https://cra-reference.eu/fr/cra/signalement-enisa/ Description: L'obligation la plus proche : 24 heures, 72 heures, 14 jours ou un mois. Déclencheurs, définition de l'exploitation active, plateforme de signalement unique, confidentialité et champ temporel élargi. Audience: transverse Legal basis: Art. 14 — obligations de signalement · Art. 15 — signalement volontaire · Art. 16 — plateforme de signalement unique · Art. 17 — autres dispositions relatives au signalement · Art. 69 — application aux produits déjà sur le marché Published 2026-08-19, updated 2026-08-19 C'est l'obligation qui est arrivée **en premier**, le 11 septembre 2026, et celle dont le non-respect est le plus visible : les délais sont courts, publics et vérifiables. ### Les deux déclencheurs | Déclencheur | Définition | | --- | --- | | **Vulnérabilité activement exploitée** contenue dans le produit | Vulnérabilité pour laquelle il existe une **preuve fiable** qu'un acteur malveillant l'a exploitée dans un système, sans l'autorisation du propriétaire de ce système | | **Incident grave ayant une incidence sur la sécurité** du produit | Incident affectant négativement, ou susceptible d'affecter, la capacité du produit à protéger la disponibilité, l'authenticité, l'intégrité ou la confidentialité des données ou fonctions | #### Ce que « activement exploitée » veut dire - L'existence d'un **exploit de démonstration public** ne suffit pas, à elle seule, à caractériser une exploitation active. - À l'inverse, une exploitation **constatée chez un seul client** suffit. - Un score de gravité élevé n'est pas un critère : une vulnérabilité critique jamais exploitée ne déclenche pas l'obligation, une vulnérabilité de gravité moyenne exploitée la déclenche. Le point délicat est la **preuve fiable** : indicateurs de compromission concordants, journaux, analyse forensique, signalement crédible d'un client ou d'un CERT. La décision doit être **documentée**, y compris lorsqu'elle conclut à l'absence d'exploitation active. ### Le canal Les signalements sont adressés via la **plateforme de signalement unique** (*single reporting platform*, SRP) mise en place et opérée par l'**[ENISA](https://www.enisa.europa.eu/)**. Ils sont routés vers le **CSIRT désigné comme coordinateur** de l'État membre concerné et vers l'ENISA. Le fabricant doit donc, en amont : s'enregistrer sur la plateforme, disposer de comptes nominatifs actifs pour les personnes d'astreinte, et avoir **testé** l'envoi. ### Les trois temps — vulnérabilité activement exploitée | Délai | Livrable | Contenu | | --- | --- | --- | | **≤ 24 heures** après avoir eu connaissance | **Alerte précoce** | Indication des États membres où le produit a été mis à disposition ; le cas échéant, caractère malveillant présumé | | **≤ 72 heures** | **Notification de vulnérabilité** | Informations générales sur le produit, nature de la vulnérabilité, mesures correctives ou d'atténuation prises et celles que les utilisateurs peuvent appliquer | | **≤ 14 jours** après la mise à disposition d'une mesure corrective | **Rapport final** | Description de la vulnérabilité, gravité et impact, informations sur l'acteur malveillant si disponibles, détails du correctif | ### Les trois temps — incident grave | Délai | Livrable | Contenu | | --- | --- | --- | | **≤ 24 heures** | **Alerte précoce** | Indication du caractère malveillant présumé de l'incident | | **≤ 72 heures** | **Notification d'incident** | Évaluation de l'incident, gravité, impact, indicateurs de compromission lorsqu'ils sont disponibles | | **≤ 1 mois** | **Rapport final** | Description détaillée, gravité et impact, type de menace ou cause profonde probable, mesures d'atténuation appliquées et en cours | ### L'information des utilisateurs Indépendamment du signalement aux autorités, le fabricant informe **sans délai injustifié** les utilisateurs impactés — et, le cas échéant, l'ensemble des utilisateurs — de la vulnérabilité ou de l'incident, ainsi que des **mesures correctives ou d'atténuation** qu'ils peuvent appliquer. Cette information n'attend pas le rapport final. Elle est distincte de la publication de l'avis de sécurité au titre de l'annexe I, partie II, point 4, qui intervient une fois le correctif disponible. ### Le signalement volontaire Le règlement prévoit la possibilité de signaler **volontairement** des vulnérabilités, des incidents, des quasi-incidents ou des cybermenaces, même en dehors de toute obligation. Un signalement volontaire n'entraîne **aucune obligation supplémentaire** pour son auteur. > **Conséquence pratique sur votre règle de décision.** En cas de doute sérieux sur la > qualification, **signaler** est la position par défaut : le coût d'un signalement > volontaire est nul en droit, celui d'un signalement manqué ne l'est pas. ### Confidentialité et diffusion différée Les informations signalées sont protégées : les autorités et l'ENISA les traitent en préservant les secrets d'affaires et les droits de propriété intellectuelle, et ne les utilisent qu'aux fins prévues. Un CSIRT coordinateur peut par ailleurs **différer la diffusion** d'une notification à d'autres autorités, pour une durée limitée et sur la base de motifs de risque cyber justifiés — typiquement lorsque la diffusion élargirait le risque avant qu'un correctif ne soit disponible. ### Le champ temporel élargi C'est le point le plus souvent manqué : > Les obligations de signalement de l'article 14 s'appliquent **également aux produits mis > sur le marché avant le 11 décembre 2027**, par dérogation au régime transitoire général. Votre **parc historique** est donc concerné depuis le 11 septembre 2026, alors même qu'il n'a ni marquage CE au titre du CRA, ni dossier technique. Cela suppose de savoir, pour chaque produit encore déployé chez des clients : quelles versions circulent, quels composants elles contiennent, et comment joindre les utilisateurs. ### Ne pas confondre Le tableau comparatif CRA / NIS 2 / RGPD figure dans [Articulation avec les autres réglementations](/fr/cra/articulation-autres-textes/). Un même événement peut déclencher les trois notifications, vers trois destinataires distincts. Le déroulé opérationnel — cellule, rôles, gabarits, astreinte, exercices — est décrit dans [Procédure 24 h / 72 h / 14 j](/fr/cyber/procedure-24h/) ; la décision juridique de signaler est traitée dans [Obligations de signalement](/fr/legal/obligations-de-signalement/). ## Période de support et cycle de vie URL: https://cra-reference.eu/fr/cra/support-et-cycle-de-vie/ Description: Cinq ans minimum ou la durée de vie attendue, dix ans de disponibilité des correctifs, obligation d'information de l'acheteur, fin de support et cessation d'activité : l'engagement de long terme du CRA. Audience: legal Legal basis: Art. 13, paragraphe 8 — période de support · Annexe II, point 8 — information de l'utilisateur · Art. 13 — cessation d'activité Published 2026-08-19, updated 2026-08-19 C'est l'impact financier le plus sous-estimé du règlement. Le CRA ne demande pas seulement de mettre sur le marché un produit sûr : il demande de **le maintenir sûr pendant des années**, y compris après l'arrêt de sa commercialisation. ### La règle Le fabricant détermine la **période de support** de manière à refléter la **durée pendant laquelle le produit est censé être utilisé**. Cette période est **d'au moins cinq ans**. Exception unique : si le **cycle de vie attendu du produit est inférieur à cinq ans**, la période de support correspond à ce cycle de vie. C'est une exception étroite et à motiver ; elle ne s'applique pas parce qu'on souhaite raccourcir l'engagement, mais parce que le produit lui-même n'est pas destiné à durer. ### Les critères à documenter La durée retenue doit être justifiée dans le [dossier technique](/fr/cra/dossier-technique/), au regard de : - les **attentes raisonnables** des utilisateurs ; - la **nature du produit** et son usage ; - les **périodes de support de produits comparables** sur le marché ; - la **législation applicable** au produit ; - la **disponibilité de l'environnement d'exploitation** — un produit dépendant d'un système d'exploitation dont le support s'arrête ; - les **périodes de support des composants intégrés**, y compris libres. Ce dernier critère est le piège classique : vous ne pouvez pas garantir cinq ans sur un produit reposant sur un composant amont maintenu deux ans. Soit vous internalisez la maintenance de ce composant, soit vous le remplacez, soit vous réduisez — et justifiez — votre période de support. Il n'y a pas de quatrième option. ### La règle des dix ans sur les correctifs Distincte de la période de support, et souvent confondue avec elle : après leur émission, les **mises à jour de sécurité restent disponibles** pendant **au moins dix ans à compter de la mise sur le marché du produit, ou pendant le reste de la période de support si celle-ci est plus longue**. | | Période de support | Disponibilité des correctifs | | --- | --- | --- | | Ce qui est dû | **Produire** des correctifs | **Mettre à disposition** les correctifs déjà produits | | Durée | ≥ 5 ans, ou la durée de vie attendue | ≥ 10 ans après la mise sur le marché, ou la période de support si plus longue | | Conséquence | Équipe de maintenance, chaîne de compilation vivante | Hébergement, archivage, disponibilité du canal de distribution | ### L'obligation d'information La **date de fin de la période de support** doit être communiquée à l'utilisateur de manière claire et compréhensible **au moment de l'achat**, exprimée au moins par le **mois et l'année** (annexe II). Elle figure donc dans la documentation produit, et devrait figurer sur la fiche commerciale. ### Fin de support et cessation d'activité **À l'approche de la fin de support** : informer les utilisateurs, indiquer le risque résiduel, proposer un chemin de migration, préciser la date à partir de laquelle plus aucun correctif ne sera produit. **En cas de cessation d'activité** ou d'arrêt des opérations : le fabricant informe les autorités de surveillance du marché compétentes et, **par tout moyen disponible**, les utilisateurs des produits concernés. Le règlement encourage par ailleurs, dans cette situation, le transfert du code source ou sa publication en logiciel libre, afin que la communauté puisse en assurer la maintenance. ### La traduction financière — à porter en comité C'est le message pour la Direction : - maintenir des **chaînes de compilation reproductibles** et des environnements de construction pendant cinq à dix ans, avec les outils et les dépendances de l'époque ; - **rétroporter** des correctifs sur des branches anciennes, ce qui suppose des compétences disponibles et une stratégie de versionnement adaptée ; - **conserver** artefacts, SBOM et dossiers techniques, avec leur coût de stockage et d'indexation ; - **renoncer à arrêter le support** d'un produit encore utilisé sans conséquence réglementaire — la fin de vie commerciale n'emporte plus la fin des obligations. ### Le registre à tenir | Colonne | Contenu | | --- | --- | | Produit et version | Identification traçable | | Date de mise sur le marché | Point de départ des dix ans | | Période de support déclarée | Durée et date de fin, au mois près | | Justification | Renvoi à la section du dossier technique | | Correctifs disponibles jusqu'au | Date calculée | | Composants limitants | Composants dont le support amont s'arrête plus tôt | | Coût annuel estimé | Maintenance, hébergement, archivage | | Responsable | Nommément | Ce registre est tenu par la direction juridique et alimenté par l'ingénierie. Il est revu à chaque comité, car c'est lui qui révèle les engagements devenus intenables. ## La surveillance du marché URL: https://cra-reference.eu/fr/cra/surveillance-du-marche/ Description: Pouvoirs des autorités, procédure applicable aux produits présentant un risque significatif, non-conformité formelle, opérations coordonnées, et la fiche réflexe en cas de demande. Audience: legal Legal basis: Chapitre V — surveillance du marché et contrôle · Règlement (UE) 2019/1020, tel que modifié Published 2026-08-19, updated 2026-08-19 ### Les pouvoirs des autorités Les autorités de surveillance du marché exercent les pouvoirs prévus par le règlement (UE) 2019/1020, tel que modifié par le CRA. Elles peuvent notamment : - **exiger le dossier technique** et la déclaration UE de conformité ; - demander toute **information nécessaire** pour établir la conformité ; - **acheter des produits** dans le commerce, y compris sous une identité d'emprunt, pour les soumettre à des **essais** ; - réaliser des **inspections** ; - dans des cas justifiés, demander l'accès à des éléments du **code source** afin d'évaluer la conformité aux exigences essentielles, dans le respect de la confidentialité ; - ordonner des **mesures correctives**, restreindre ou interdire la mise à disposition, ordonner le retrait ou le rappel. ### La procédure « risque significatif » Lorsqu'une autorité a des raisons suffisantes de considérer qu'un produit présente un **risque significatif de cybersécurité**, elle procède à une évaluation. Si la non-conformité est établie, elle **enjoint** à l'opérateur de prendre des mesures correctives adaptées dans un délai raisonnable. Si l'opérateur n'agit pas, l'autorité **restreint ou interdit** la mise à disposition, ordonne le retrait ou le rappel, et **informe la Commission et les autres États membres**. S'ouvre alors une phase où les autres États peuvent objecter ; à défaut, la mesure est réputée justifiée et étendue. Une **procédure de sauvegarde de l'Union** permet à la Commission d'intervenir en cas de désaccord entre États membres ou de risque à l'échelle de l'Union. ### La non-conformité formelle Distincte du risque : elle porte sur les manquements documentaires. Sont visés notamment : - le **marquage CE manquant** ou apposé en violation des règles ; - l'absence du **numéro d'identification de l'organisme notifié** lorsqu'il est requis ; - la **déclaration UE de conformité** absente ou non conforme à l'annexe V ; - la **documentation technique** indisponible, incomplète ou non conservée ; - l'absence des **coordonnées du fabricant** ou du **point de contact** pour le signalement ; - l'absence des **informations à l'utilisateur** de l'annexe II. Elle donne lieu à injonction de régularisation et, si elle persiste, aux mêmes mesures que la non-conformité de fond. ### Les opérations coordonnées La Commission et le **groupe de coopération administrative (ADCO)** peuvent organiser des opérations de **contrôle coordonné** (*sweeps*), portant sur une catégorie de produits ou une exigence particulière, simultanément dans plusieurs États membres. Ces campagnes sont annoncées et leurs résultats publiés. Elles constituent le mode de contrôle le plus probable pour les produits de grande diffusion. ### Fiche réflexe : vous recevez une demande d'une autorité À imprimer et à conserver avec les procédures de crise. 1. **Accuser réception immédiatement**, en confirmant l'interlocuteur unique côté entreprise — nommé à l'avance, avec un suppléant. 2. **Qualifier la demande** : quelle autorité, quel État membre, quel produit, quelle version, quel fondement juridique, quel délai de réponse. 3. **Geler les preuves** : figer les versions du dossier technique, du SBOM et des journaux correspondant à la version visée. Ne rien modifier rétroactivement. 4. **Constituer la réponse** : le dossier technique tel qu'il existait au moment de la mise sur le marché, la déclaration, et les pièces demandées — sans y ajouter de documents antidatés, ce qui relèverait de la fourniture d'informations trompeuses. 5. **Faire valider** par la direction juridique avant tout envoi. 6. **Répondre dans le délai imparti**, en demandant formellement une prorogation si le délai est intenable — une demande motivée vaut mieux qu'un silence. 7. **Consigner** l'intégralité des échanges dans le registre, avec horodatage. 8. **Informer** le comité et, si l'événement peut avoir un effet matériel, la direction générale. ### Ce que révèle une demande Une demande d'autorité est un test de votre **archivage**, pas de votre sécurité. La question n'est pas « votre produit est-il sûr ? » mais « pouvez-vous produire, en quelques jours, le dossier exact d'une version livrée il y a quatre ans ? ». La réponse se prépare des années à l'avance : voir [Conservation des preuves](/fr/legal/conservation-des-preuves/). ## Parcours Cyber URL: https://cra-reference.eu/fr/cyber/ Description: Les obligations du CRA vues par l'équipe Cybersécurité et DevSecOps : génération de SBOM, CI/CD, sécurité par conception, gestion des vulnérabilités, divulgation coordonnée, signalement, surveillance continue. Audience: cyber Legal basis: Annexe I, parties I et II · Art. 13, 14 Published 2026-08-19, updated 2026-08-19 Cette section traduit l'**annexe I** du règlement en capacités techniques à construire, en outils à déployer et en preuves à produire. Le texte lui-même est expliqué dans [Exigences essentielles](/fr/cra/exigences-essentielles/). ### Les huit capacités à construire L'annexe I, partie II, énonce huit obligations de traitement des vulnérabilités. Chacune correspond à une capacité technique, à un outil et à un artefact vérifiable : | Exigence (annexe I, partie II) | Capacité | Preuve produite | | --- | --- | --- | | 1. Recenser composants et vulnérabilités, **SBOM** lisible par machine | Génération automatisée en CI | SBOM CycloneDX signé, par build | | 2. Traiter et corriger **sans délai**, correctifs séparés des évolutions | Gestion des vulnérabilités, branches de correctifs | Journal de traitement, délais mesurés | | 3. **Tests et revues** de sécurité réguliers | SAST, DAST, SCA, fuzzing, tests d'intrusion | Rapports de tests datés | | 4. **Publier** les informations sur les vulnérabilités corrigées | Avis de sécurité au format CSAF | Avis publiés | | 5. Politique de **divulgation coordonnée** | Canal CVD, `security.txt` | Politique publiée, accusés de réception | | 6. Faciliter le **partage d'informations**, adresse de contact | Boîte PSIRT, clé publique | Adresse active et testée | | 7. **Diffusion sécurisée** des mises à jour | Signature, canal authentifié, anti-retour arrière | Description du mécanisme | | 8. Diffusion **sans délai et gratuite**, avec message consultatif | Processus de publication | Historique des publications | ### Ce que la Cyber doit obtenir du Juridique La classification réglementaire de chaque produit (elle détermine le niveau de preuve attendu), la politique de licences, la période de support engagée, l'arbitrage sur la diffusion du SBOM, et la décision de signaler lors d'un événement. ### Ce que la Cyber doit fournir au Juridique Le SBOM signé, l'analyse de risques, le journal de traitement des vulnérabilités, les VEX, les rapports de tests, la description du mécanisme de mise à jour, et — dans les deux heures suivant la détection — la qualification d'une exploitation active. ### L'obligation la plus proche Ce n'est pas le SBOM, c'est le **signalement**. Depuis le 11 septembre 2026, une vulnérabilité activement exploitée déclenche une alerte précoce sous **24 heures**, y compris pour les produits mis sur le marché avant cette date. Cela suppose une astreinte, un canal testé et une décision d'escalade documentée : voir [Procédure 24 h / 72 h / 14 j](/fr/cyber/procedure-24h/). > **Le lien à automatiser.** Le passage du triage technique (« cette vulnérabilité est > exploitée dans la nature ») à l'obligation juridique (« vous devez signaler dans les > 24 heures ») ne doit pas dépendre de l'appréciation d'un analyste de garde. Il doit être > un déclencheur outillé, avec une escalade par défaut. ## Sécuriser la chaîne de construction URL: https://cra-reference.eu/fr/cyber/chaine-ci-securisee/ Description: La chaîne qui produit et signe le SBOM est elle-même une surface d'attaque : les six façons d'exécuter du code dans un pipeline, l'attaque par proposition de modification, et les contre-mesures. Audience: cyber Legal basis: Annexe I, partie I — limitation des surfaces d'attaque, protection de l'intégrité · Annexe I, partie II, point 7 — diffusion sécurisée Published 2026-08-20, updated 2026-08-20 [Intégration dans la CI/CD](/fr/cyber/integration-cicd/) explique comment **produire** un SBOM dans la chaîne de construction. Cette page traite du problème inverse : **la chaîne elle-même**. ### Pourquoi c'est un sujet de conformité La chaîne de construction produit l'artefact, génère le SBOM, appose la signature et émet l'attestation de provenance. **Si elle est compromise, tout l'aval perd sa valeur** : le SBOM décrit ce que l'attaquant veut bien montrer, et la signature authentifie un binaire vérolé. [SolarWinds et Codecov](/fr/cyber/incidents/) sont exactement cela. Le règlement ne consacre pas d'article à la chaîne de construction, mais trois de ses exigences y conduisent : la **limitation des surfaces d'attaque** et la **protection de l'intégrité** (annexe I, partie I), la **diffusion sécurisée des mises à jour** (annexe I, partie II, point 7), et la **diligence sur les composants tiers** (art. 13, paragraphe 5) — laquelle porte aussi sur les composants que la chaîne consomme, actions et images comprises. ### Les six façons d'exécuter du code dans un pipeline Le point contre-intuitif : la plupart n'exploitent **aucune vulnérabilité**. Ce sont des fonctionnalités documentées, utilisées comme prévu. | Mécanisme | Comment ça marche | Exemple typique | | --- | --- | --- | | **Exécution directe** | L'outil a pour rôle d'exécuter des commandes décrites dans un fichier du dépôt | Un fichier de construction lance un script shell | | **Configuration exécutable** | Le fichier de configuration n'est pas lu, il est **évalué** | Une configuration d'outil écrite en JavaScript ou en Python | | **Scripts de cycle de vie** | Le gestionnaire de paquets déclenche des scripts à l'installation | Les crochets d'installation d'un paquet | | **Redirection de registre** | Un fichier du dépôt réoriente la résolution vers un dépôt contrôlé par l'attaquant | Un fichier de configuration de registre commité | | **Empoisonnement d'environnement** | Une variable modifie silencieusement le comportement d'un outil | Une variable interprétée par l'interpréteur de commandes ou par un utilitaire d'archive | | **Fichier d'entrée piégé** | Une archive ou un fichier malformé exploite l'analyseur qui le traite | Une archive à chemins absolus, un fichier de projet forgé | **La conséquence pratique** : interdire les scripts d'installation ne suffit pas. Un dépôt qui peut modifier n'importe quel fichier de configuration peut, dans la plupart des écosystèmes, obtenir l'exécution de code. ### L'attaque par proposition de modification C'est le scénario dominant, et il ne demande **aucun accès** au dépôt. 1. Un contributeur externe ouvre une proposition de modification. 2. Elle touche un fichier que la chaîne **exécute** : configuration de tâche, fichier de construction, manifeste de dépendances. 3. La chaîne se déclenche automatiquement sur la proposition. 4. Si elle s'exécute **avec les secrets du dépôt**, ceux-ci sont exfiltrés — souvent discrètement, par une requête sortante ou en les écrivant dans les journaux. L'erreur de conception qui rend l'attaque possible est unique : **exécuter du code non validé dans un contexte qui détient des secrets**. ### Les contre-mesures, par ordre d'efficacité #### 1. Séparer les contextes d'exécution La mesure structurante, et la seule qui traite la cause. | Contexte | Déclencheur | Secrets | Ce qu'il fait | | --- | --- | --- | --- | | **Non fiable** | Proposition de modification externe | **Aucun** | Compilation, tests, analyse statique | | **Fiable** | Après fusion, ou sur validation explicite | Oui | Publication, signature, déploiement | Tout ce qui a besoin d'un secret appartient au second. Aucun code non fusionné ne s'y exécute. #### 2. Épingler par empreinte, jamais par étiquette Une étiquette est **mutable** : elle peut être repointée vers un autre commit sans que rien ne change de votre côté. C'est ce qui s'est produit sur une action de CI très répandue en mars 2025. Les actions, images de base et scripts distants se référencent par **empreinte**. Voir [Verrouiller et mettre à jour les dépendances](/fr/cyber/verrouillage-dependances/). #### 3. Protéger les fichiers qui s'exécutent Les fichiers de définition de chaîne, les manifestes de dépendances et les configurations évaluées méritent un régime de revue distinct : propriétaires désignés, approbation obligatoire, et alerte sur modification. #### 4. Moindre privilège sur les jetons Par défaut, un jeton de chaîne ne devrait avoir que la lecture. Les droits d'écriture, de publication et d'émission d'identité sont accordés **tâche par tâche**, et seulement là où ils servent. Un jeton éphémère vaut mieux qu'un secret de longue durée. #### 5. Désactiver ce qui n'est pas nécessaire Installation sans exécution des scripts de cycle de vie, chemins de configuration imposés en ligne de commande plutôt que lus depuis le dépôt, registres forcés par argument. #### 6. Isoler les exécuteurs Exécuteurs éphémères, détruits après chaque tâche, sans accès réseau sortant non maîtrisé. Le filtrage sortant transforme une exfiltration silencieuse en échec visible. #### 7. Analyser la chaîne comme du code Trois familles d'outils ouverts examinent les définitions de chaîne et détectent ces défauts : | Outil | Ce qu'il regarde | | --- | --- | | [actionlint](https://github.com/rhysd/actionlint) | Syntaxe des définitions de tâches et sûreté des scripts intégrés | | [zizmor](https://github.com/zizmorcore/zizmor) | Défauts de sécurité propres aux chaînes hébergées | | [poutine](https://github.com/boostsecurityio/poutine) | Analyse de chaîne d'approvisionnement des chaînes de construction | Ils s'exécutent dans la chaîne, sur la chaîne, et leur échec doit être bloquant au même titre qu'un test. ### Ce que ça produit comme preuve | Artefact | À quoi il sert | | --- | --- | | Configuration de chaîne **versionnée** | Montre l'état exact à une date, pour une version livrée | | **Rapports d'analyse** de chaîne, datés | Preuve du contrôle régulier exigé par l'annexe I, partie II, point 3 | | **Attestation de provenance** signée par le service de construction | Relie l'artefact à la révision et aux paramètres réels | | **Journal des dérogations**, avec expiration | Montre que les blocages sont maîtrisés, pas contournés | | **Politique de jetons** documentée | Preuve du moindre privilège | ### Le rapport avec le niveau de provenance visé Séparer les contextes, isoler les exécuteurs et empêcher les étapes définies par l'utilisateur d'atteindre le matériel de signature sont exactement les conditions des niveaux supérieurs du cadre **SLSA** — voir [Signature et intégrité](/fr/sbom/signature-et-integrite/). Sécuriser la chaîne n'est donc pas un chantier séparé : c'est ce qui rend l'attestation crédible. ## Liste de contrôle technique URL: https://cra-reference.eu/fr/cyber/checklist-technique/ Description: Quinze points à vérifier par produit avant la revue de conformité, imprimable, à joindre au dossier de la revue de mise sur le marché. Audience: cyber Published 2026-08-19, updated 2026-08-19 Le pendant technique de la [liste de contrôle juridique](/fr/legal/checklist-mise-sur-le-marche/). À remplir avant la revue de conformité, à joindre au dossier. **Produit :** ______________________ **Version exacte :** ______________________ **Date :** ____________ **Responsable :** ______________________ --- ### Nomenclature - [ ] **1.** Le **SBOM** est généré automatiquement par la chaîne de construction, sans intervention manuelle. → [Générer un SBOM](/fr/cyber/generer-un-sbom/) - [ ] **2.** Le **format et la version** sont conformes à la décision d'entreprise, et identiques à ceux des autres produits. → [Formats](/fr/sbom/formats/) - [ ] **3.** La **profondeur transitive** est couverte, et la complétude est déclarée honnêtement dans le document. - [ ] **4.** Le **score de qualité** est au-dessus du seuil, et l'écart entre Build SBOM et Analyzed SBOM est dans les limites. → [Qualité](/fr/sbom/qualite-et-completude/) - [ ] **5.** Le SBOM est **signé** et accompagné d'une attestation de provenance. → [Signature](/fr/sbom/signature-et-integrite/) - [ ] **6.** Le SBOM est **publié** vers la plateforme de pilotage et **archivé** avec indexation par empreinte. ### Chaîne de construction - [ ] **7.** Les **politiques de blocage** sont actives en CI : vulnérabilités critiques, licences interdites, absence de SBOM. → [Intégration CI/CD](/fr/cyber/integration-cicd/) - [ ] **8.** Les **dérogations** en cours sont documentées et portent toutes une date d'expiration. ### Vulnérabilités - [ ] **9.** La **surveillance continue** est active sur ce produit, toutes versions livrées confondues. → [Surveillance continue](/fr/cyber/surveillance-continue/) - [ ] **10.** Les alertes non corrigées font l'objet d'un **VEX** avec justification normalisée. → [VEX](/fr/sbom/vex/) - [ ] **11.** Les **avis de sécurité** sont publiés pour les vulnérabilités corrigées, dans un format lisible par machine. ### Sécurité du produit - [ ] **12.** L'**analyse de risques** est à jour pour cette version, et la matrice de traçabilité de l'annexe I est complète. → [Sécurité par conception](/fr/cyber/secure-by-design/) - [ ] **13.** Les **tests de sécurité** prévus au plan ont été exécutés et leurs rapports sont archivés. - [ ] **14.** Le **mécanisme de mise à jour** est décrit, testé — y compris en échec et en retour arrière — et les correctifs de sécurité sont séparables des évolutions. → [Mises à jour sécurisées](/fr/cyber/mises-a-jour-securisees/) ### Réaction - [ ] **15.** Le **canal CVD** est actif pour ce produit, le `security.txt` est valide et non expiré, et la procédure de signalement a été **testée** dans les douze derniers mois. → [Politique CVD](/fr/cyber/politique-cvd/) · [Procédure 24 h](/fr/cyber/procedure-24h/) --- **Réserves** (points ouverts, avec responsable et échéance) : _______________________________________________________________________ **Avis du RSSI :** favorable ☐ favorable sous réserve ☐ défavorable ☐ Nom, signature, date : ______________________ ## Évaluer un composant open source URL: https://cra-reference.eu/fr/cyber/evaluer-un-composant/ Description: Rendre calculable la diligence exigée par l'article 13, paragraphe 5 : les dix-huit contrôles d'OpenSSF Scorecard, ce qu'ils couvrent de la grille, ce qu'ils ne disent pas, et le cadre S2C2F pour l'ingestion. Audience: cyber Legal basis: Art. 13, paragraphe 5 — diligence raisonnable sur les composants tiers · Annexe I, partie II, point 1 — recensement des composants Published 2026-08-20, updated 2026-08-20 ### Le problème L'article 13, paragraphe 5, impose une **diligence raisonnable** lors de l'intégration de composants tiers, et cette diligence doit être **documentée** pour être opposable. La [grille](/fr/cra/open-source/integrer-de-l-oss/) qui en découle comporte neuf critères : vulnérabilités connues, activité, gouvernance, politique de sécurité amont, réactivité historique, licence, SBOM amont, signature des artefacts, profondeur. Appliquée à la main, elle est irréprochable sur dix composants et **inapplicable sur trois mille**. Or c'est l'ordre de grandeur d'un graphe de dépendances réel. Une diligence qui ne s'exécute pas n'est pas une diligence. Il faut donc rendre la grille **calculable**. ### OpenSSF Scorecard [Scorecard](https://scorecard.dev/) est un outil ouvert de la [Fondation OpenSSF](https://openssf.org/) qui exécute une série de contrôles automatisés sur un dépôt et produit, pour chacun, une **note sur 10** assortie d'un **niveau de risque** qui la pondère dans une note agrégée. Son apport n'est pas de remplacer le jugement : c'est de rendre **objectif et reproductible** ce qui était jusque-là une impression. #### Les dix-huit contrôles | Famille | Contrôles | | --- | --- | | **Pratiques de sécurité** | Vulnerabilities · Dependency-Update-Tool · Maintained · Security-Policy · License · CII-Best-Practices · CI-Tests · Fuzzing · SAST | | **Risque côté source** | Binary-Artifacts · Branch-Protection · Dangerous-Workflow · Code-Review · Contributors | | **Risque côté construction** | Pinned-Dependencies · Token-Permissions · Packaging · Signed-Releases | #### Ce que chaque critère de la grille devient | Votre critère | Contrôle Scorecard correspondant | Automatisable | | --- | --- | --- | | Vulnérabilités connues | `Vulnerabilities` (via OSV) | **Oui** | | Activité du projet | `Maintained` | **Oui** | | Gouvernance, mainteneur unique | `Contributors` | **Partiellement** — il compte les organisations, pas la fragilité | | Politique de sécurité amont | `Security-Policy` | **Oui** | | Réactivité historique | — | **Non** | | Licence | `License` (présence seulement) | **Partiellement** | | SBOM amont | — | **Non** | | Signature des artefacts | `Signed-Releases` | **Oui** | | Profondeur des dépendances | — | **Non**, relève du SBOM | Six critères sur neuf deviennent mesurables, et Scorecard en ajoute neuf que la grille n'avait pas — protection de branche, revue de code, permissions des jetons, épinglage des dépendances, motifs de chaîne dangereux, analyse statique, tests, fuzzing, artefacts binaires non auditables. #### Ce que Scorecard ne dit pas Point essentiel, à écrire dans la politique pour éviter le faux sentiment de sécurité : - **rien sur la compatibilité de licence** avec votre contexte d'usage — voir [Licences open source](/fr/licences/) ; - **rien sur l'atteignabilité** : un composant bien noté peut porter une vulnérabilité exploitable chez vous, et un composant mal noté peut être inoffensif ; - **rien sur la durée de support amont**, qui conditionne pourtant votre [période de support](/fr/cra/support-et-cycle-de-vie/) ; - **rien sur la qualité du code** ni sur l'adéquation fonctionnelle ; - une note élevée **n'aurait écarté aucun** des incidents documentés dans [Incidents de référence](/fr/cyber/incidents/) — les projets concernés étaient actifs, revus et largement adoptés. Scorecard mesure des **signaux d'hygiène**, pas l'absence de malveillance. C'est utile, borné, et il faut le dire. ### S2C2F : le cadre d'ingestion Là où Scorecard note un composant, le **Secure Supply Chain Consumption Framework** ([S2C2F](https://github.com/ossf/s2c2f)), également porté par l'OpenSSF, décrit **comment consommer** de l'open source : un ensemble de pratiques indépendantes des outils, assorti d'un modèle de maturité et d'une cartographie vers d'autres référentiels de chaîne d'approvisionnement. Son principe directeur est celui que vous appliquez déjà sans le nommer : **ne pas consommer directement depuis un registre public**, mais passer par une ingestion contrôlée, inventoriée et vérifiée — voir [Verrouiller et mettre à jour les dépendances](/fr/cyber/verrouillage-dependances/). Son intérêt pour vous est double : il donne un **vocabulaire commun** avec vos fournisseurs et vos clients, et il fournit une **échelle de maturité** utilisable dans le [diagnostic](/fr/diagnostic/). ### La politique de seuils Un score sans seuil n'est pas une politique. Ce qui doit être écrit : | Situation | Règle proposée | | --- | --- | | Nouveau composant, note ≥ 7 | Adoption sans instruction supplémentaire | | Nouveau composant, note 5 à 7 | Adoption possible, **instruction documentée** des contrôles en échec | | Nouveau composant, note < 5 | **Refus par défaut**, ou dérogation motivée et datée | | Contrôle `Signed-Releases` en échec sur un composant critique | Vérification par empreinte obligatoire | | Contrôle `Maintained` en échec | Traiter comme un [composant abandonné](/fr/cra/open-source/integrer-de-l-oss/) | | Composant déjà intégré dont la note **baisse** | Alerte, réexamen, pas de retrait automatique | La dernière ligne est celle qu'on oublie : la diligence n'est pas un contrôle d'entrée, c'est une **surveillance**. Un projet peut perdre son mainteneur trois ans après son adoption. ### Où ça s'exécute | Moment | Ce qui est fait | | --- | --- | | **Demande d'adoption** d'un composant | Score calculé, joint au ticket, seuil appliqué | | **Construction** | Contrôle des seuils sur les dépendances directes, avertissement au-dessous | | **Périodiquement** | Recalcul sur les composants critiques, alerte sur baisse | | **Revue annuelle** | Réexamen de l'ensemble, avec les composants dont la note s'est dégradée | Le calcul en continu sur l'intégralité du graphe transitif est coûteux et peu utile : limiter la surveillance périodique aux composants **directs** et aux **transitives critiques** — celles dont le remplacement prendrait des mois — donne l'essentiel du bénéfice. ### La preuve à conserver | Artefact | Pourquoi | | --- | --- | | **Score horodaté** par composant et par version | Montre l'état des connaissances **au moment de la décision** | | **Grille de diligence** complétée, avec les critères non automatisables | Couvre ce que l'outil ne mesure pas | | **Politique de seuils** versionnée | Montre que la décision suit une règle, pas une préférence | | **Registre des dérogations**, avec expiration | Montre que les exceptions sont maîtrisées | | **Journal des réexamens** | Montre que la diligence est continue | C'est cet ensemble, et non le score seul, qui constitue la diligence documentée attendue par l'article 13, paragraphe 5. > **Le piège à éviter.** Un score archivé sans la décision qu'il a fondée ne démontre rien. > Ce qu'une autorité examine, ce n'est pas la note : c'est le fait qu'une règle écrite ait été > appliquée, et que les écarts aient été motivés. ## Maîtriser les faux positifs URL: https://cra-reference.eu/fr/cyber/faux-positifs/ Description: Le risque de conformité par excès de bruit : causes racines, remèdes, politique de suppression datée et motivée, et l'indicateur à suivre. Audience: cyber Published 2026-08-19, updated 2026-08-19 ### Le problème, posé clairement Un scan brut sur une image applicative typique remonte des **centaines d'alertes**. Une très large majorité n'est pas exploitable dans votre contexte. Sans traitement, deux issues, toutes deux mauvaises : 1. l'équipe tente de tout traiter, s'épuise, et les **vraies** vulnérabilités se noient ; 2. l'équipe désactive les contrôles, et le dispositif n'existe plus que sur le papier. > **C'est un risque de conformité, pas seulement un problème de confort.** Un dispositif qui > produit tellement de bruit qu'il n'est plus consulté ne démontre pas le traitement « sans > délai » exigé par l'annexe I. La qualité du signal est une exigence, pas un raffinement. ### Les causes racines | Cause | Mécanisme | Fréquence | | --- | --- | --- | | **Appariement imprécis** | Corrélation par CPE : homonymie, orthographes, CPE manquants | Très élevée | | **Code vulnérable non atteignable** | Le composant est présent, la fonction vulnérable n'est jamais appelée | Élevée | | **Rétroportage de distribution** | Le correctif est appliqué sans changement du numéro de version amont | Élevée sur les images de conteneur | | **Dépendances de test comptées** | Des dépendances jamais livrées apparaissent dans le SBOM du produit | Élevée | | **Couches d'image de base inutilisées** | Des paquets présents dans l'image mais jamais exécutés | Élevée | | **Vulnérabilité contestée ou de faible qualité** | Identifiant publié puis contesté par l'éditeur | Modérée | | **Composant présent en double** | Deux versions d'une même bibliothèque, une seule chargée | Modérée | ### Les remèdes, par ordre d'efficacité **1. Privilégier les identifiants par écosystème.** Corréler par `purl` contre une base par écosystème plutôt que par CPE contre une base généraliste réduit massivement le bruit. C'est le levier le plus rentable — voir [Identifiants](/fr/sbom/identifiants/). **2. Renseigner la distribution.** Pour les paquets système, indiquer la distribution et sa version permet à l'outil d'appliquer la bonne base de correctifs et d'ignorer les vulnérabilités déjà rétroportées. **3. Exclure les dépendances de test du SBOM du produit livré.** Elles n'y ont pas leur place — voir [Qualité et complétude](/fr/sbom/qualite-et-completude/). **4. Analyse d'atteignabilité.** Déterminer si la fonction vulnérable est appelée depuis vos points d'entrée. Coûteux à mettre en place, très efficace ensuite. **5. VEX systématique.** Chaque alerte écartée est documentée par un [VEX](/fr/sbom/vex/) avec une justification normalisée. L'alerte disparaît des tableaux de bord **sans disparaître des traces**. **6. Réduire la surface.** Images de base minimales, suppression des paquets inutiles, compilation statique maîtrisée. Moins de composants, moins d'alertes — et moins de risque réel. **7. Prioriser plutôt que filtrer.** Utiliser la probabilité d'exploitation et les catalogues d'exploitation avérée pour ordonner, sans supprimer. ### Politique de suppression Une alerte peut être écartée. Elle ne peut pas être **effacée**. | Autorisé | Interdit | | --- | --- | | VEX `not_affected` avec justification normalisée | Suppression silencieuse | | Mise en sourdine **datée**, motivée, avec responsable | Mise en sourdine permanente | | Exclusion d'un chemin de fichier, documentée | Désactivation globale d'un contrôle | | Réduction de la sévérité contextualisée, tracée | Modification manuelle de la base de vulnérabilités | Toute mise en sourdine porte une **date d'expiration**. À l'échéance, l'alerte réapparaît et la décision est réexaminée. C'est ce qui distingue une décision d'ingénierie d'un contournement. ### L'encadré pour le Juridique > Décider de ne pas corriger n'est **pas** un manquement, à condition que la décision soit > **motivée, documentée et tracée**. L'annexe I exige de traiter les vulnérabilités sans > délai ; elle n'exige pas de corriger l'intégralité des identifiants remontés par un > scanner. > > Le VEX est la **forme juridique** de cette décision. Sans lui, une vulnérabilité écartée est > indiscernable d'une vulnérabilité ignorée — et c'est précisément la distinction qu'une > autorité de surveillance cherchera à établir. ### L'indicateur **Ratio d'alertes actionnables sur alertes brutes**, mesuré par produit et suivi dans le temps. ``` ratio = alertes ayant donné lieu à une action (correctif, contournement, VEX motivé) ÷ alertes brutes remontées par les outils ``` Un ratio de quelques pour cent signale un problème d'outillage, pas un excès de rigueur. Un ratio en amélioration continue signale que le dispositif mûrit. C'est l'un des rares indicateurs qui mesure la **qualité** du dispositif et non son volume. Il figure dans le tableau de bord décrit dans [Indicateurs](/fr/organisation/indicateurs/). ## Générer un SBOM URL: https://cra-reference.eu/fr/cyber/generer-un-sbom/ Description: Les cinq méthodes de génération selon le contexte, les familles d'outils, la matrice de choix par langage, et pourquoi il faut figer l'outillage par famille de produits. Audience: cyber Legal basis: Annexe I, partie II, point 1 Published 2026-08-19, updated 2026-08-19 ### Le principe Le SBOM se produit **au plus près de l'artefact**, dans le pipeline qui le fabrique, jamais à la main a posteriori. Un SBOM rédigé par un humain est faux le jour où il est écrit et obsolète le lendemain. ### Les cinq méthodes | Méthode | Ce qu'elle voit | Angle mort | | --- | --- | --- | | **Depuis les manifestes de dépendances** | Les dépendances déclarées et résolues | Ce qui n'est pas déclaré : code vendorisé, liaison statique | | **Depuis l'image de conteneur** | Les paquets système de l'image de base **et** l'application | Ce qui est compilé dans un binaire | | **Depuis le binaire compilé** | Les bibliothèques liées statiquement | Précision variable, dépend des métadonnées laissées par le compilateur | | **Depuis le système de fichiers ou le micrologiciel** | Le contenu réel d'une image embarquée | Coûteux, outillage spécialisé | | **Depuis l'exécution** | Ce qui est réellement chargé en mémoire | Ne voit que les chemins exercés | Ces méthodes ne s'excluent pas : elles se **combinent**. Un pipeline mature produit un [Build SBOM](/fr/sbom/typologies/) depuis les manifestes et un Analyzed SBOM depuis l'artefact, puis compare les deux. ### Les familles d'outils Les fiches détaillées figurent dans [Générateurs](/fr/outils/generation/). En synthèse : | Famille | Rôle | Représentants | | --- | --- | --- | | **Générateurs génériques** | Produire l'inventaire, multi-écosystèmes | Syft, cdxgen | | **Scanners tout-en-un** | Générer et détecter les vulnérabilités en une passe | Trivy | | **Moteurs de détection** | Consommer un SBOM et le corréler | Grype, osv-scanner | | **Outils orientés licences** | Détecter les licences par analyse de fichiers | ScanCode, OSS Review Toolkit | | **Plugins natifs de chaîne de build** | Produire l'inventaire depuis le graphe de résolution réel | CycloneDX Maven/Gradle, `npm sbom`, équivalents .NET, Rust, Go | ### Matrice de choix par contexte | Contexte | Recommandation | Pourquoi | | --- | --- | --- | | Application Java, .NET, Node, Python, Ruby | **Plugin natif de la chaîne de build**, complété par un générateur générique sur l'artefact | Le plugin voit le graphe de résolution réel, avec les arbitrages de versions | | Application Go ou Rust | Générateur générique sur le **binaire** | Les métadonnées de build y sont présentes | | Application C / C++ | Générateur sur le binaire **et** sur le système de construction | La liaison statique rend les manifestes insuffisants | | Image de conteneur | Générateur sur l'**image** complète | Capte l'image de base | | Micrologiciel embarqué | Outillage spécialisé, **et** exigence de SBOM auprès du fournisseur de plateforme | Peu d'outils généralistes couvrent ce cas | | Monorepo multi-artefacts | Un SBOM **par artefact publiable**, pas un pour le dépôt | Le SBOM décrit un artefact livré | ### Le piège de l'outillage flottant Deux outils différents produisent deux SBOM différents pour le même artefact : périmètre de détection, granularité, normalisation des identifiants et gestion des dépendances de test varient. C'est normal, et ce n'est un problème que si l'outillage change sans qu'on le sache. > **Règle.** Figer l'outillage **par famille de produits**, documenter le choix, versionner > la configuration, et traiter tout changement d'outil ou de version majeure comme un > événement : recalcul d'une référence, comparaison, note d'explication. Sans cette discipline, la comparabilité dans le temps est perdue et les écarts entre deux versions deviennent ininterprétables — ce qui vide le dispositif de sa valeur pour le dossier technique. ### Ce qui doit sortir du pipeline Pour chaque artefact publiable : 1. un **Build SBOM** au format pivot, version fixée ; 2. un **Analyzed SBOM** de contrôle croisé ; 3. un **score de qualité**, avec échec de la construction sous le seuil ; 4. une **signature** et une attestation de provenance ; 5. une **publication** vers la plateforme de pilotage ; 6. un **archivage** avec indexation par empreinte. Le détail figure dans [Intégration CI/CD](/fr/cyber/integration-cicd/). ### Ce qu'il faut documenter Une fiche par famille de produits : outils utilisés et versions, commandes exactes, format et version de sortie, périmètre couvert, exclusions volontaires et leur motif, seuils de qualité, responsable. Cette fiche est une pièce du dossier technique, parce qu'elle explique **comment** le SBOM a été produit — information que l'annexe VII attend au titre des processus. ## Gestion des vulnérabilités URL: https://cra-reference.eu/fr/cyber/gestion-des-vulnerabilites/ Description: Le cycle complet de la détection à la clôture, les sources à agréger, la priorisation par score composite, les SLA de remédiation et le déclencheur automatisé du signalement. Audience: cyber Legal basis: Annexe I, partie II, points 2 et 4 · Art. 14 — signalement Published 2026-08-19, updated 2026-08-19 ### Le cycle ``` détection → corrélation SBOM → triage → qualification d'exploitabilité (VEX) → priorisation → remédiation → vérification → publication d'un avis → clôture → archivage ``` Chaque transition est horodatée. C'est cette chronologie qui démontre, en cas de contrôle, le traitement « sans délai » exigé par l'annexe I. ### Les sources à agréger | Source | Nature | Rôle | | --- | --- | --- | | **[EUVD](https://euvd.enisa.europa.eu/)** | Base européenne de vulnérabilités, opérée par l'ENISA | Source européenne de référence, alimentée par les signalements CRA | | **[NVD](https://nvd.nist.gov/)** | Base américaine, corrélation par CPE | Couverture large, latence et imprécision d'appariement | | **[OSV](https://osv.dev/)** | Base par écosystème, corrélation par PURL | **Précision élevée** sur les paquets | | **Catalogues d'exploitation avérée** | Vulnérabilités effectivement exploitées | Déclencheur prioritaire | | **Avis des éditeurs et distributions** | Correctifs et rétroportages | Évite les faux positifs de version | | **Avis des projets amont** | Souvent en avance sur les bases | Détection précoce | | **CERT nationaux** | Alertes et contexte de menace | Contexte régional | L'agrégation est le rôle de la [plateforme de pilotage](/fr/outils/plateformes/), pas d'un tableur. ### Le triage Trois questions, dans cet ordre : 1. **Le composant est-il réellement présent ?** Vérification par `purl` et empreinte. Beaucoup d'alertes s'arrêtent ici — voir [Identifiants](/fr/sbom/identifiants/). 2. **Le code vulnérable est-il atteignable ?** Analyse d'atteignabilité, examen du chemin d'exécution. C'est ici que se décide le statut [VEX](/fr/sbom/vex/). 3. **Quelle est l'urgence réelle ?** Priorisation, ci-dessous. ### La priorisation Aucun indicateur pris isolément ne suffit. | Indicateur | Ce qu'il dit | Ce qu'il ne dit pas | | --- | --- | --- | | **Gravité (CVSS de base)** | La sévérité intrinsèque | Ni l'exploitation réelle, ni votre contexte | | **Score environnemental** | La sévérité chez vous | Suppose un travail de contextualisation | | **Probabilité d'exploitation** | La vraisemblance d'une exploitation à court terme | Ni la présence chez vous, ni l'impact | | **Exploitation avérée** | Qu'elle est exploitée dans la nature | Ni chez vous, ni sur ce chemin | | **Atteignabilité** | Que le code est appelé | Ni l'exploitabilité, ni l'impact | | **Exposition réseau** | Que le composant est accessible | — | | **Criticité métier du produit** | L'impact d'un incident | — | **Score composite recommandé**, à pondérer une fois et à documenter : ``` priorité = gravité contextualisée × facteur d'exploitation (avérée > probable > théorique) × atteignabilité (appelé > présent non appelé) × exposition (réseau > local) × criticité métier du produit ``` L'important n'est pas la formule mais le fait qu'elle soit **écrite, stable et appliquée uniformément** : c'est ce qui rend les décisions comparables et défendables. ### Les SLA de remédiation À définir, à publier en interne, et à **mesurer** : | Niveau | Déclencheur | Délai de correction cible | | --- | --- | --- | | **Urgence absolue** | Exploitation active constatée sur votre produit | Contournement immédiat, correctif sous 72 h | | **Critique** | Exploitable à distance sans authentification, atteignable | 7 jours | | **Élevé** | Exploitable, atteignable, conditions particulières | 30 jours | | **Moyen** | Exploitable dans un scénario restreint | 90 jours | | **Faible ou non exploitable** | Documenté en VEX | Traité à la prochaine version | Ces délais sont **internes** ; le règlement exige un traitement « sans délai », sans le chiffrer. Des SLA écrits et tenus sont la meilleure démonstration de ce que vous entendez par « sans délai ». ### Le déclencheur du signalement C'est le point d'articulation entre la technique et le droit. > Dès qu'une vulnérabilité de votre produit est qualifiée **activement exploitée**, le délai > de **24 heures** de l'article 14 court. Le passage du triage à l'obligation juridique ne > doit **pas** dépendre de l'initiative d'un analyste de garde. Mise en œuvre : un statut dédié dans l'outil de suivi, dont l'activation déclenche automatiquement une alerte vers l'astreinte juridique et l'ouverture d'une entrée au registre des décisions. Voir [Procédure 24 h](/fr/cyber/procedure-24h/) et [Obligations de signalement](/fr/legal/obligations-de-signalement/). ### La séparation des correctifs L'annexe I demande, lorsque c'est techniquement possible, que les correctifs de sécurité soient fournis **séparément** des évolutions fonctionnelles. Cela suppose : - une **stratégie de branches** de maintenance par ligne de version supportée ; - une capacité de **rétroportage** vers les branches anciennes ; - une **numérotation** qui distingue clairement un correctif de sécurité ; - des **tests de non-régression** exécutables sur des branches anciennes, donc un environnement de construction conservé. C'est une contrainte d'ingénierie lourde, à décider **à la conception** et non lors du premier incident. ### Les indicateurs Délai médian de triage, délai médian de remédiation par niveau, âge moyen des vulnérabilités ouvertes, part des alertes traitées en VEX, part des SLA respectés, nombre de vulnérabilités héritées de composants abandonnés. Voir [Indicateurs](/fr/organisation/indicateurs/). ## Incidents de référence URL: https://cra-reference.eu/fr/cyber/incidents/ Description: Quatorze compromissions documentées et datées, du canal de mise à jour d'un éditeur au détournement d'une action de CI : ce qui s'est passé, ce qui aurait limité l'impact, et l'exigence du règlement que chacune éclaire. Audience: transverse Legal basis: Annexe I, partie I — limitation des surfaces d'attaque, intégrité · Art. 13, paragraphe 5 — diligence sur les composants tiers Published 2026-08-20, updated 2026-08-20 La page [Risques de chaîne d'approvisionnement](/fr/cyber/risques-supply-chain/) classe les mécanismes. Celle-ci documente **ce qui s'est réellement produit**. La distinction n'est pas cosmétique. Une typologie se conteste ; une compromission datée, avec son éditeur, son numéro de vulnérabilité et son périmètre, ne se conteste pas. C'est l'argument qui débloque un budget et qui fait accepter une contrainte d'ingénierie. > **Une précaution de lecture.** Chaque entrée renvoie à une contre-mesure. Il ne faut pas en > conclure qu'elle aurait empêché l'attaque : dans plusieurs cas, **rien de ce qui est recommandé ici n'aurait suffi**. La colonne indique ce qui aurait **réduit le délai de > détection ou l'ampleur**, ce qui est déjà l'essentiel. ### La série | Date | Incident | Mécanisme | Ce qui aurait limité | | --- | --- | --- | --- | | Juin 2017 | **M.E.Doc / NotPetya** | Canal de mise à jour d'un éditeur compromis, propagation par une mise à jour légitime | Segmentation, moindre privilège du compte de mise à jour | | Sept. 2017 | **CCleaner** | Environnement de construction de l'éditeur compromis ; le binaire malveillant portait une **signature légitime** | Attestations de provenance, isolation du service de construction | | Nov. 2018 | **event-stream** (npm) | Le mainteneur cède le projet à un inconnu, qui ajoute une dépendance malveillante ciblant un portefeuille de cryptomonnaie | Surveillance du **changement de mainteneur**, revue des nouvelles dépendances | | Déc. 2020 | **SolarWinds Orion** (SUNBURST) | Système de construction compromis, porte dérobée insérée entre le code source vérifié et l'artefact distribué | Builds reproductibles, provenance signée par le service de construction | | Févr. 2021 | **Confusion de dépendances** | Travaux de recherche montrant qu'un paquet public prend le pas sur un paquet interne homonyme, chez plusieurs grands éditeurs | Espaces de noms réservés, priorité de résolution explicite, registre interne | | Avr. 2021 | **Codecov** | Le script d'envoi de couverture est modifié pendant des mois et **exfiltre les variables d'environnement** des chaînes de CI qui l'exécutent | Vérification d'empreinte du script, moindre privilège des jetons, filtrage sortant | | Juil. 2021 | **Kaseya VSA** | Un logiciel d'administration à distance sert de vecteur de distribution d'un rançongiciel vers les clients finaux | Segmentation, contrôle des canaux d'administration | | Oct. 2021 | **ua-parser-js** (npm) | Compte de mainteneur détourné, versions malveillantes publiées sur un paquet très largement utilisé | Authentification forte sur les comptes de publication, quarantaine des nouvelles versions | | Déc. 2021 | **Log4Shell** (CVE-2021-44228) | Non pas une attaque de la chaîne, mais une **vulnérabilité critique dans un composant ubiquitaire** : la question devient « où est-il chez vous ? » | **SBOM centralisé** : réponse en minutes plutôt qu'en semaines | | Mars 2022 | **node-ipc** | Code destructeur introduit **délibérément par le mainteneur lui-même**, pour des motifs politiques | Verrouillage de versions, revue avant montée de version | | Mars 2023 | **3CX** | Installeur compromis — et compromission **en cascade** : l'éditeur avait lui-même été atteint par un logiciel tiers trojanisé | Diligence sur les fournisseurs des fournisseurs, vérification de signature | | Mars 2024 | **xz / liblzma** (CVE-2024-3094) | **Ingénierie sociale sur plus de deux ans** pour obtenir la maintenance du projet, puis porte dérobée visant le service SSH. CVSS 10 | Peu de choses — voir ci-dessous | | Juin 2024 | **polyfill.io** | Le domaine servant un script à des centaines de milliers de sites est **racheté**, puis sert du code malveillant | Auto-hébergement des ressources, contrôle d'intégrité des sous-ressources | | Mars 2025 | **tj-actions/changed-files** (CVE-2025-30066) | Les **étiquettes de version** d'une action de CI sont repointées vers un commit malveillant qui écrit les secrets dans les journaux | **Épinglage par empreinte** plutôt que par étiquette, journaux non publics | ### Cinq incidents qui enseignent quelque chose de précis #### SolarWinds — la signature ne dit rien du contenu La porte dérobée a été insérée **dans le système de construction**, entre un code source intègre et un artefact distribué. Le binaire livré était authentiquement signé par l'éditeur : toute vérification de signature côté client passait. **Ce que ça change pour vous.** Signer un artefact prouve **qui** l'a publié, pas **ce qu'il contient ni comment il a été produit**. C'est exactement l'écart que comblent les [attestations de provenance](/fr/sbom/signature-et-integrite/) : elles décrivent le dépôt, la révision, la chaîne et les paramètres de construction. Un service de construction isolé, dont les étapes définies par l'utilisateur ne peuvent pas atteindre le matériel de signature, est la réponse structurelle. #### Codecov — la CI est une cible, pas un outil neutre Un script téléchargé et exécuté par des milliers de chaînes d'intégration a été modifié discrètement, et a exfiltré pendant des mois le contenu des variables d'environnement — donc les jetons, clés et identifiants qui s'y trouvaient. **Ce que ça change pour vous.** Tout ce que la chaîne de construction exécute fait partie du produit. Voir [Sécuriser la chaîne de construction](/fr/cyber/chaine-ci-securisee/). #### xz — l'incident qui résiste à vos contre-mesures Deux ans de contributions légitimes pour obtenir la confiance du mainteneur, puis une porte dérobée dissimulée dans les archives de publication — absente du dépôt de code — visant l'authentification SSH. Découverte par accident, par un ingénieur intrigué par une consommation processeur anormale. **Ce que ça change pour vous.** Aucune grille de diligence n'aurait écarté ce projet : il était actif, maintenu, largement audité, et présent dans toutes les distributions. Deux leçons seulement, et elles sont modestes : - **la divergence entre le dépôt et l'archive publiée** était le signal ; le construire soi-même depuis les sources, ou vérifier que l'archive correspond au dépôt, l'aurait révélée ; - **un mainteneur unique sous pression** est un critère de risque, et il figure dans votre [grille d'évaluation](/fr/cyber/evaluer-un-composant/). Il faut savoir dire qu'un dispositif a des limites. Prétendre l'inverse décrédibilise le reste. #### polyfill.io — la dépendance qu'on ne compte pas Un script chargé depuis un domaine tiers n'apparaît dans aucun manifeste, dans aucun SBOM produit depuis un gestionnaire de paquets. Le rachat du domaine a suffi à transformer une dépendance invisible en vecteur. **Ce que ça change pour vous.** Les ressources chargées à l'exécution depuis un tiers sont une dépendance à part entière, qui doit être inventoriée et justifiée comme les autres. Ce site en charge exactement une — la mesure d'audience servie par son propre hébergeur — et un contrôle de build échoue si une seconde apparaît : la discipline utile n'est pas de promettre zéro, mais de savoir énumérer. C'est l'un des angles morts du [frontend web](/fr/licences/scenarios/frontend-web/). #### tj-actions — une étiquette n'est pas une empreinte L'attaquant n'a pas eu besoin de publier une version : il a **repointé les étiquettes existantes** vers un commit malveillant. Toutes les chaînes qui référençaient l'action par son étiquette ont exécuté le nouveau code au build suivant, et ont écrit leurs secrets dans des journaux souvent publics. **Ce que ça change pour vous.** L'épinglage par empreinte n'est pas un raffinement : c'est la seule référence immuable. Voir [Verrouiller et mettre à jour les dépendances](/fr/cyber/verrouillage-dependances/). ### Ce que la série montre **Le point de compromission remonte la chaîne.** Les cas anciens visaient le canal de distribution ; les récents visent le **système de construction**, les **comptes de publication** et l'**outillage de CI**. Plus on remonte, plus la signature du produit final devient sans valeur, puisqu'elle est apposée après la compromission. **Le délai de détection compte plus que la prévention.** Aucune des quatorze n'a été empêchée par un contrôle automatisé. Plusieurs ont été trouvées par hasard. Ce qui distingue les organisations, c'est le temps qu'il leur a fallu pour répondre à « **êtes-vous concernés ?** » — de quelques minutes à plusieurs semaines, selon qu'elles disposaient ou non d'un inventaire centralisé. **Le lien avec le règlement est direct.** L'article 13, paragraphe 5, impose une **diligence documentée** sur les composants tiers ; l'annexe I, partie I, impose la **limitation des surfaces d'attaque** et la **protection de l'intégrité**. Ces quatorze cas décrivent précisément les surfaces qu'il faut réduire. > **Cette liste est une sélection, pas un inventaire.** Elle retient des incidents documentés > publiquement et bien établis, choisis pour couvrir chaque mécanisme de la typologie. Les > campagnes les plus récentes ont industrialisé certains de ces motifs — notamment les > **vers auto-répliquants** sur les registres de paquets, qui abusent des jetons de publication > dérobés pour se propager de paquet en paquet sans intervention humaine. Tenir cette page à > jour relève du processus de [veille](/fr/actualites/). ## Intégration dans la CI/CD URL: https://cra-reference.eu/fr/cyber/integration-cicd/ Description: Les huit étapes du pipeline cible, les règles de blocage, la gestion des dérogations, les monorepos et le coût en temps de construction. Audience: cyber Legal basis: Annexe I, partie II, points 1 et 3 Published 2026-08-19, updated 2026-08-19 ### Le pipeline cible ``` 1. build → produit l'artefact 2. sbom-generate → Build SBOM + Analyzed SBOM 3. sbom-validate → schéma, score de qualité, écart build/analyzed ↳ ÉCHEC si sous le seuil 4. sbom-sign → signature + attestation de provenance 5. sbom-publish → envoi à la plateforme de pilotage 6. policy-gate → vulnérabilités, licences, VEX ↳ ÉCHEC ou AVERTISSEMENT selon la politique 7. attach → SBOM et signature attachés à l'artefact dans le registre 8. archive → versement au coffre de preuves, indexé par empreinte ``` Les étapes 3 et 6 sont **bloquantes**. Les autres sont des étapes de production : leur échec doit également faire échouer la construction, faute de quoi des artefacts sans SBOM atteindront la production. ### Exemple — GitHub Actions ```yaml jobs: build-and-attest: runs-on: ubuntu-latest permissions: contents: read id-token: write # signature sans clé longue durée packages: write steps: - uses: actions/checkout@v4 - name: Construire l'artefact run: make build - name: Générer le SBOM (build) run: syft dir:. -o cyclonedx-json=sbom-build.cdx.json - name: Générer le SBOM (analyzed) run: syft "$IMAGE" -o cyclonedx-json=sbom-analyzed.cdx.json - name: Valider qualité et écart run: ./ci/validate-sbom.sh sbom-build.cdx.json sbom-analyzed.cdx.json - name: Signer run: cosign attest --predicate sbom-build.cdx.json --type cyclonedx "$IMAGE" - name: Publier vers la plateforme run: ./ci/publish-sbom.sh sbom-build.cdx.json - name: Politiques (vulnérabilités et licences) run: ./ci/policy-gate.sh sbom-build.cdx.json ``` Le principe est le même sur GitLab CI, Jenkins ou Azure DevOps : les étapes sont identiques, seule la syntaxe change. Les scripts `validate-sbom.sh`, `publish-sbom.sh` et `policy-gate.sh` sont **communs à toutes les chaînes** et versionnés dans un dépôt central — c'est ce qui garantit l'uniformité des seuils. ### Les règles de blocage | Condition | Effet | Justification | | --- | --- | --- | | SBOM non généré ou schéma invalide | **Échec** | Sans SBOM, pas de conformité possible | | Score de qualité sous le seuil | **Échec** | Un SBOM incomplet donne une assurance fausse | | Écart build / analyzed au-delà du seuil | **Échec** | Révèle du code non déclaré | | Vulnérabilité critique exploitable, sans VEX | **Échec** | Annexe I : pas de vulnérabilité exploitable connue à la mise sur le marché | | Vulnérabilité élevée, sans VEX | Avertissement + ticket | Traitement dans le SLA | | Licence en liste noire pour ce contexte | **Échec** | Politique de licences | | Licence en liste grise | Avertissement + ticket | Validation juridique | | Signature ou attestation absente | **Échec** | Sans signature, le SBOM n'est pas une preuve | ### Les dérogations Un blocage sans échappatoire est contourné, généralement en désactivant le contrôle. Il faut donc une **dérogation encadrée** : 1. demandée dans un ticket, avec justification ; 2. accordée par une personne identifiée — RSSI pour les vulnérabilités, juridique pour les licences ; 3. **limitée dans le temps**, avec une date d'expiration obligatoire ; 4. inscrite dans un fichier versionné à côté du code, lisible par le pipeline ; 5. **expirée automatiquement** : à la date, le blocage reprend. Une dérogation permanente est une modification de la politique, et doit être traitée comme telle — pas comme une exception. ### Les cas particuliers **Monorepos.** Un SBOM par **artefact publiable**, pas un pour le dépôt. La difficulté est d'attribuer correctement les dépendances partagées ; les plugins natifs de la chaîne de build s'en sortent mieux que les générateurs génériques. **Constructions matricielles.** Un artefact par combinaison système ou architecture, donc un SBOM par combinaison. Le SBOM d'une variante ne vaut pas pour les autres. **Constructions incrémentales et cache.** Le cache peut masquer un changement de dépendance. Le SBOM doit être régénéré à chaque construction publiable, sans réutilisation de cache. **Artefacts tiers reconditionnés.** Si vous republiez un artefact que vous n'avez pas construit, vous devez l'analyser — le SBOM du fournisseur, s'il existe, est un point de départ à vérifier, pas une pièce à reprendre telle quelle. ### Le coût La génération ajoute de quelques secondes à quelques minutes par construction, selon la taille de l'artefact et la méthode. Les leviers usuels : - ne produire l'**Analyzed SBOM** que sur les constructions publiables, pas sur chaque proposition de modification ; - **mettre en cache** les bases de vulnérabilités des outils, pas les résultats ; - **paralléliser** génération et tests ; - réserver le **contrôle croisé complet** aux branches de publication. Ces optimisations ne doivent jamais réduire ce qui est produit pour un artefact **livré** : c'est le seul cas où la conformité se joue. ## Mises à jour sécurisées URL: https://cra-reference.eu/fr/cyber/mises-a-jour-securisees/ Description: Canal authentifié, signature, protection contre le retour arrière, mises à jour automatiques avec refus possible, séparation des correctifs, gratuité et cas de l'embarqué. Audience: cyber Legal basis: Annexe I, partie I — mises à jour automatiques, intégrité · Annexe I, partie II, points 2, 7 et 8 · Annexe II, point 9 — information sur les mises à jour automatiques Published 2026-08-19, updated 2026-08-19 ### Ce que le règlement exige Quatre exigences, réparties entre les deux parties de l'annexe I : 1. les vulnérabilités peuvent être corrigées par des **mises à jour de sécurité**, y compris, lorsque c'est approprié, **automatiques et activées par défaut**, avec un **mécanisme de refus clair** et une information sur les mises à jour disponibles ; 2. les correctifs de sécurité sont fournis **séparément** des évolutions fonctionnelles lorsque c'est techniquement possible ; 3. des **mécanismes de diffusion sécurisée** garantissent que les correctifs parviennent aux utilisateurs sans altération ; 4. les correctifs sont diffusés **sans délai** et **gratuitement**, accompagnés de **messages consultatifs** indiquant les actions à entreprendre. ### Le mécanisme technique | Propriété | Mise en œuvre | | --- | --- | | **Authenticité** | Signature du paquet de mise à jour, vérifiée par le produit avant application | | **Intégrité** | Empreinte vérifiée ; échec propre en cas d'altération | | **Confidentialité du canal** | Transport chiffré et authentification du serveur | | **Protection contre le retour arrière** | Refus d'installer une version antérieure, sauf procédure explicite de restauration | | **Résilience** | Reprise après coupure ; le produit reste fonctionnel si la mise à jour échoue | | **Vérifiabilité** | L'utilisateur peut vérifier la version installée et l'historique | | **Racine de confiance** | Clé de vérification protégée, procédure de rotation prévue et testée | La **rotation de clé** est le point le plus souvent oublié. Sur un produit supporté dix ans, la clé de signature devra changer. Si le mécanisme ne le prévoit pas dès la conception, le produit deviendra non maintenable. ### Les mises à jour automatiques Activées par défaut **lorsque c'est approprié**. Ce qualificatif appelle une décision documentée, appuyée sur l'analyse de risques : un équipement industriel dont un redémarrage inopiné arrêterait une ligne de production relève d'un autre régime qu'une application grand public. Dans tous les cas : - **information de l'utilisateur** sur l'existence du mécanisme et sur ses effets ; - **possibilité de désactivation** claire, avec information sur les conséquences ; - **possibilité de différer** une mise à jour ; - **notification** des mises à jour disponibles lorsqu'elles ne sont pas automatiques. Ces éléments doivent figurer dans la notice utilisateur — voir [Documentation utilisateur](/fr/legal/documentation-utilisateur/). ### La séparation des correctifs C'est l'exigence qui a le plus de conséquences sur l'ingénierie. Fournir un correctif de sécurité **sans** évolution fonctionnelle suppose : - des **branches de maintenance** par ligne de version supportée ; - une capacité de **rétroportage** du correctif vers ces branches ; - une **numérotation** qui distingue clairement un correctif de sécurité ; - des **environnements de construction conservés** pour les branches anciennes — sur dix ans, cela signifie archiver les outils, pas seulement le code ; - des **tests de non-régression** exécutables sur ces branches. Un modèle de publication en flux continu, sans branches de maintenance, ne permet pas de satisfaire cette exigence : le client doit alors accepter les évolutions fonctionnelles pour obtenir le correctif. La décision d'architecture doit être prise **avant** le premier incident. ### La gratuité Les correctifs de sécurité sont **gratuits** pendant la période de support, sauf accord contraire pour des produits sur mesure entre professionnels. Conséquence commerciale à instruire : un contrat de maintenance ne peut pas conditionner l'accès aux correctifs de sécurité. Voir [Traduire la période de support en engagements](/fr/legal/support-contractuel/). ### Les messages consultatifs Chaque diffusion s'accompagne d'un message indiquant à l'utilisateur **ce qu'il doit faire**. Contenu minimal : les vulnérabilités corrigées, les produits et versions concernés, la gravité, l'urgence d'application, et les éventuelles actions manuelles requises. Publier ces messages dans un format **lisible par machine** — CSAF 2.0 — permet à vos clients de les traiter automatiquement. Ce n'est pas exigé explicitement, mais c'est ce que les grands comptes demanderont, et cela réduit vos propres sollicitations. ### Le cas de l'embarqué et de la connectivité contrainte Contraintes spécifiques, à traiter dès la conception : - **taille** du paquet de mise à jour et bande passante disponible ; - **alimentation** : une mise à jour interrompue par une coupure ne doit pas rendre l'appareil inutilisable — d'où les schémas à double partition ; - **absence d'interface utilisateur** : comment informer et recueillir un refus ? - **parc déployé non joignable** : comment atteindre un équipement derrière un réseau d'entreprise fermé ? - **durée de vie matérielle** longue : la capacité de stockage doit absorber dix ans de correctifs. Ces contraintes ne dispensent d'aucune exigence. Elles doivent être **traitées dans l'analyse de risques** et refléter dans les hypothèses d'environnement de sécurité communiquées à l'utilisateur. ### Les preuves à produire Description du mécanisme au dossier technique, procédure de gestion des clés, rapports de tests de mise à jour — y compris les tests d'échec et de retour arrière —, historique des publications et des messages consultatifs. ## La politique de divulgation coordonnée URL: https://cra-reference.eu/fr/cyber/politique-cvd/ Description: Contenu d'une politique CVD, security.txt et RFC 9116, engagement de non-poursuite, normes ISO/IEC 29147 et 30111, article L. 2321-4, et la question de devenir CNA. Audience: cyber Legal basis: Annexe I, partie II, point 5 — politique CVD · Annexe I, partie II, point 6 — adresse de contact · Annexe II, point 2 — point de contact unique Published 2026-08-19, updated 2026-08-19 ### L'obligation L'annexe I, partie II, point 5, impose de **mettre en place et de faire appliquer** une politique de divulgation coordonnée des vulnérabilités. Les deux verbes comptent : une politique publiée mais dont les signalements restent sans réponse ne satisfait pas l'exigence. Le point 6 y ajoute la mise à disposition d'une **adresse de contact**, et l'annexe II impose de faire figurer un **point de contact unique** dans les informations à l'utilisateur, **avec l'indication de l'endroit où il se situe**. ### Le contenu d'une politique CVD | Section | Contenu | | --- | --- | | **Périmètre** | Produits, versions et domaines couverts — **et ce qui ne l'est pas** | | **Hors périmètre** | Systèmes tiers, environnements de test clients, types de défauts non traités | | **Canal de signalement** | Adresse dédiée, formulaire, clé publique de chiffrement | | **Accusé de réception** | Délai d'engagement — 3 jours ouvrés est une pratique courante | | **Délai de réponse** | Délai d'une première évaluation qualifiée | | **Délai de divulgation** | Fenêtre convenue avant publication — 90 jours est la pratique de référence, ajustable | | **Engagement de non-poursuite** | Pour les recherches de bonne foi restant dans le périmètre | | **Reconnaissance** | Crédit dans l'avis, page de remerciements | | **Récompense** | Le cas échéant, barème et conditions | | **Processus interne** | Ce qui se passe après réception, et le point d'escalade | | **Langues acceptées** | Au minimum français et anglais | ### L'engagement de non-poursuite C'est la clause la plus sensible, et celle qui détermine si des chercheurs vous signaleront quoi que ce soit. Elle engage l'entreprise à ne pas engager d'action civile ni de plainte pénale contre une personne qui, de bonne foi : - reste dans le **périmètre annoncé** ; - **n'exfiltre pas** de données au-delà de ce qui est strictement nécessaire à la démonstration ; - **ne dégrade pas** la disponibilité du service ; - **ne divulgue pas** avant la fenêtre convenue ; - **signale** par le canal indiqué. Elle doit être **validée par la direction juridique** avant publication, et rédigée en termes précis : une clause vague est inutile pour le chercheur et dangereuse pour l'entreprise. ### Le fichier `security.txt` Norme **[RFC 9116](https://www.rfc-editor.org/rfc/rfc9116.html)**, publié à `/.well-known/security.txt` : ``` Contact: mailto:psirt@example.org Expires: 2027-08-19T00:00:00Z Encryption: https://example.org/pgp-key.txt Preferred-Languages: fr, en Policy: https://example.org/fr/securite/ Acknowledgments: https://example.org/fr/securite/#remerciements Canonical: https://example.org/.well-known/security.txt ``` > **Le piège.** Le champ `Expires` doit rester **dans le futur**. Un `security.txt` expiré > est un signal de négligence visible de tous, et il est régulièrement relevé par les outils > d'évaluation externe. Sa mise à jour doit être **automatisée**, pas confiée à un rappel de > calendrier. ### Les normes de référence - **ISO/IEC 29147** — divulgation des vulnérabilités : comment recevoir et publier. - **ISO/IEC 30111** — traitement des vulnérabilités : comment enquêter et corriger. S'y référer explicitement dans la politique renforce sa crédibilité et facilite les réponses aux questionnaires clients. ### Le cadre français L'**article L. 2321-4 du code de la défense** permet à une personne de bonne foi de transmettre à l'ANSSI une information sur une vulnérabilité affectant un système, l'ANSSI préservant la confidentialité de son identité. C'est une voie ouverte au chercheur indépendamment de votre politique. Conséquence pratique : **un chercheur peut passer par l'ANSSI plutôt que par vous**. Mieux vaut que votre canal soit le plus simple et le plus fiable des deux. ### Le processus interne | Étape | Délai cible | Responsable | | --- | --- | --- | | Accusé de réception | 3 jours ouvrés | PSIRT | | Qualification initiale | 7 jours | PSIRT + ingénierie | | Retour qualifié au chercheur | 10 jours | PSIRT | | Correctif ou position motivée | Selon les [SLA](/fr/cyber/gestion-des-vulnerabilites/) | Ingénierie | | Coordination de la date de publication | Avant publication | PSIRT + chercheur | | Publication de l'avis | À la disponibilité du correctif | PSIRT | | Remerciement | À la publication | PSIRT | Chaque signalement reçu est inscrit à un **registre**, qu'il soit retenu ou non. Ce registre est la preuve que la politique est « appliquée » et non seulement « mise en place ». ### Faut-il devenir autorité de numérotation CVE ? | Pour | Contre | | --- | --- | | Maîtrise du calendrier de publication | Engagement de qualité et de réactivité | | Cohérence des identifiants sur vos produits | Charge de processus permanente | | Crédibilité auprès des chercheurs et des clients | Exposition : vos publications deviennent comptées | | Facilite la corrélation chez vos clients | Nécessite un PSIRT réellement armé | La question ne se pose utilement qu'une fois le processus CVD rodé et le volume de signalements significatif. La poser trop tôt détourne l'attention du sujet réel, qui est de répondre aux signalements dans les délais annoncés. ### La page publique Votre politique est publiée sur [Divulgation des vulnérabilités](/fr/securite/). Elle doit être accessible **sans authentification**, à une URL stable, et référencée depuis `security.txt` et depuis la documentation de chaque produit. ## Procédure 24 h / 72 h / 14 jours URL: https://cra-reference.eu/fr/cyber/procedure-24h/ Description: Le runbook complet du signalement : détection, qualification, cellule, envois, information des utilisateurs, astreinte, exercices et fiche réflexe imprimable. Audience: cyber Legal basis: Art. 14 — obligations de signalement · Art. 16 — plateforme de signalement unique Published 2026-08-19, updated 2026-08-19 Le cadre légal figure dans [Le signalement à l'ENISA](/fr/cra/signalement-enisa/), la décision juridique dans [Obligations de signalement](/fr/legal/obligations-de-signalement/). Cette page est le **runbook**. ### Prérequis, à vérifier avant tout incident - [ ] Comptes nominatifs actifs sur la **plateforme de signalement unique**, pour chaque personne d'astreinte, testés dans les six derniers mois - [ ] **Gabarits** pré-remplis : alerte précoce, notification, rapport final - [ ] **Liste des États membres** où chaque produit est mis à disposition — donnée à maintenir, souvent absente - [ ] **Canal d'information des utilisateurs** opérationnel, avec coordonnées à jour - [ ] **Tour d'astreinte** technique **et** juridique, avec suppléants - [ ] **Délégation écrite** de la décision de signaler - [ ] **Registre** des décisions en place ### Le déroulé #### H+0 — Détection et horodatage Un élément d'exploitation active parvient à une fonction de sécurité : alerte de surveillance, signalement client, avis d'un CERT, publication amont. **Premier geste : horodater la réception**, et l'inscrire au registre. C'est ce point de départ qui sera examiné en cas de contrôle. #### H+0 à H+2 — Qualification Le PSIRT établit les faits : - la vulnérabilité affecte-t-elle **vos** produits, et lesquels, dans quelles versions ? - existe-t-il une **preuve fiable d'exploitation** — indicateurs concordants, journaux, analyse, signalement circonstancié ? - quelle est la **base installée** concernée, et dans quels États membres ? Livrable : une **fiche de qualification** transmise au décideur juridique. Délai cible : **deux heures**. #### H+2 à H+4 — Décision Le décideur juridique tranche : signaler, ne pas signaler, ou signaler volontairement. En cas de doute sérieux, la règle par défaut est de **signaler**. La décision et sa motivation sont inscrites au registre, **quelle qu'elle soit**. #### H+4 à H+20 — Rédaction Le PSIRT rédige l'alerte précoce à partir du gabarit. Contenu minimal : identification du produit, États membres où il est mis à disposition, nature de l'événement, caractère malveillant présumé le cas échéant. Relecture juridique avant envoi. #### Avant H+24 — Envoi de l'alerte précoce Transmission via la plateforme de signalement unique. **Conserver l'accusé de réception** : c'est la preuve du respect du délai. Ne pas viser H+23 : viser H+16, pour absorber un incident technique sur la plateforme. #### En parallèle — Information des utilisateurs Sans délai injustifié, informer les utilisateurs impactés de la vulnérabilité ou de l'incident et des mesures qu'ils peuvent appliquer. Cette information **n'attend pas** le rapport final. #### Avant H+72 — Notification circonstanciée Informations générales sur le produit, nature de la vulnérabilité, mesures correctives et d'atténuation prises et applicables par les utilisateurs. Pour un incident : évaluation, gravité, impact, indicateurs de compromission disponibles. #### Ensuite — Remédiation Correctif ou contournement, tests, publication de la mise à jour, publication de l'**avis de sécurité** au titre de l'annexe I, partie II, point 4. #### J+14 après disponibilité du correctif — Rapport final Pour une vulnérabilité : description, gravité et impact, informations sur l'acteur malveillant si disponibles, détails du correctif. Pour un incident grave, le délai est d'**un mois** : description détaillée, cause profonde probable, mesures appliquées et en cours. #### Après — Retour d'expérience Chronologie réelle contre chronologie cible, points de friction, mise à jour du référentiel et des gabarits. ### Les rôles pendant la cellule | Rôle | Responsabilité | | --- | --- | | **Coordinateur d'incident** | Tient la chronologie, arbitre les priorités, protège l'équipe des sollicitations | | **Analyste** | Établit les faits techniques, produit la fiche de qualification | | **Référent juridique** | Décide du signalement, valide les textes, suit les régimes parallèles | | **Communication** | Prépare l'information aux utilisateurs et aux clients, en lien avec le juridique | | **Ingénierie produit** | Développe le correctif ou le contournement | | **Direction** | Informée, arbitre les décisions à impact commercial | ### L'astreinte Un délai de 24 heures couvre nuits, week-ends et jours fériés. Concrètement : - une **rotation** technique et une rotation juridique, avec suppléants ; - un **numéro d'astreinte** unique, connu du support et des équipes ; - un **délai maximal d'escalade** avant bascule sur le suppléant ; - une **liste de rappel** tenue à jour, testée. ### Les exercices **Deux par an au minimum.** Un exercice sur table pour la décision, un exercice technique complet allant jusqu'à l'envoi sur l'environnement de test de la plateforme. Ce qui est mesuré : délai de qualification, délai de décision, délai d'envoi, qualité du contenu produit, complétude du registre. Le compte rendu est versé au dossier de gouvernance ; l'écart entre le délai obtenu et 24 heures est un [indicateur](/fr/organisation/indicateurs/) suivi en comité. ### Fiche réflexe À imprimer et à afficher. ``` VULNÉRABILITÉ ACTIVEMENT EXPLOITÉE — FICHE RÉFLEXE 1. HORODATER la réception. Ouvrir l'entrée au registre. 2. APPELER l'astreinte PSIRT : [numéro] 3. QUALIFIER en 2 h : vos produits ? quelles versions ? preuve d'exploitation ? quels États membres ? 4. TRANSMETTRE la fiche au décideur juridique : [numéro] 5. DÉCIDER. En cas de doute → SIGNALER. 6. RÉDIGER l'alerte précoce (gabarit : [emplacement]) 7. ENVOYER avant H+16. Conserver l'accusé. 8. INFORMER les utilisateurs impactés, sans attendre. 9. H+72 : notification circonstanciée. 10. J+14 après correctif : rapport final. Ne pas oublier : NIS 2 et RGPD peuvent s'appliquer au même événement. ``` ## Risques de chaîne d'approvisionnement URL: https://cra-reference.eu/fr/cyber/risques-supply-chain/ Description: Typologie des attaques, ce que le SBOM permet et ne permet pas, les contre-mesures de durcissement de la chaîne de construction, et la cartographie de votre exposition. Audience: cyber Legal basis: Art. 13, paragraphe 5 — diligence sur les composants tiers · Annexe I, partie I — intégrité Published 2026-08-19, updated 2026-08-19 ### Pourquoi le CRA s'y intéresse L'essentiel du code d'un produit moderne n'a pas été écrit par son fabricant. Le règlement en tire la conséquence : il impose un inventaire, une diligence à l'intégration, et une remontée des vulnérabilités à l'amont. La chaîne d'approvisionnement est le sujet, le SBOM n'en est que l'instrument. ### Typologie des attaques | Type | Mécanisme | Cas documenté | Ce qui aurait aidé | | --- | --- | --- | --- | | **Compromission d'un dépôt ou d'un mainteneur** | Vol d'identifiants, prise de contrôle d'un compte de publication | ua-parser-js, oct. 2021 | Vérification de signature, épinglage d'empreintes | | **Compromission de la chaîne de construction** | Injection dans l'environnement de build du fournisseur | SolarWinds, déc. 2020 · CCleaner, sept. 2017 | Attestations de provenance, builds reproductibles | | **Typosquattage** | Paquet au nom proche d'un paquet légitime | Campagnes récurrentes sur les registres publics | Registre proxy interne, liste d'autorisation | | **Confusion de dépendances** | Un paquet public prend le pas sur un paquet interne homonyme | Travaux de recherche, févr. 2021 | Espaces de noms réservés, priorité de résolution explicite | | **Paquet malveillant publié** | Code hostile dès la première version | event-stream, nov. 2018 | Revue humaine des nouvelles dépendances, période de quarantaine | | **Vulnérabilité massive dans une bibliothèque ubiquitaire** | Un défaut dans un composant présent partout | Log4Shell, déc. 2021 | **SBOM centralisé** : réponse en minutes au lieu de semaines | | **Porte dérobée par ingénierie sociale de long terme** | Un contributeur gagne la confiance du projet, puis introduit un défaut subtil | xz / liblzma, mars 2024 | Diversité des mainteneurs, revue, builds reproductibles | | **Compromission d'un fournisseur commercial** | Le produit tiers légitime devient un vecteur | 3CX, mars 2023 · Kaseya, juil. 2021 | Segmentation, moindre privilège, surveillance comportementale | | **Reprise d'un composant abandonné** | Un tiers prend le contrôle d'un projet délaissé | polyfill.io, juin 2024 | Surveillance du changement de mainteneur | | **Détournement d'une étape de la chaîne de construction** | Une action de CI réutilisée est repointée vers du code malveillant | tj-actions, mars 2025 | **Épinglage par empreinte**, moindre privilège des jetons | Chaque cas est documenté, daté et sourcé dans **[Incidents de référence](/fr/cyber/incidents/)** : ce qui s'est produit, ce qui aurait limité l'impact, et l'exigence du règlement que l'incident éclaire. ### Ce que le SBOM permet — et ne permet pas **Permet :** savoir instantanément quels produits et quelles versions livrées contiennent un composant donné. C'est la **capacité de réponse**, et elle transforme une crise de plusieurs semaines en une journée de travail. **Ne permet pas :** détecter du code malveillant. Un paquet hostile correctement inventorié apparaît comme n'importe quel autre. Le SBOM répond à « qu'y a-t-il dedans », pas à « est-ce sain ». Il faut donc le compléter par la **vérification de provenance**, la **signature**, la **revue** des nouvelles dépendances et le **durcissement** de la chaîne de construction. ### Les contre-mesures #### Sur les dépendances - **Registre proxy interne** : toutes les dépendances transitent par un miroir contrôlé, jamais directement depuis un dépôt public. - **Épinglage de versions et verrouillage d'empreintes** : le fichier de verrouillage est commité, et la construction échoue si une empreinte diffère. - **Espaces de noms réservés** pour vos paquets internes, dans le registre public le cas échéant, afin de prévenir la confusion de dépendances. - **Quarantaine** : une nouvelle dépendance n'est disponible qu'après un délai et une revue. - **Revue humaine** des ajouts et des mises à jour majeures de dépendances sensibles. #### Sur la chaîne de construction Le sujet est traité en détail dans [Sécuriser la chaîne de construction](/fr/cyber/chaine-ci-securisee/) ; en résumé : - **Runners isolés**, éphémères, sans accès réseau sortant non maîtrisé. - **Moindre privilège** sur les jetons de publication ; jetons éphémères plutôt que secrets de longue durée. - **Séparation** entre la construction et la publication. - **Attestations de provenance** signées par le service de construction, pas par l'auteur du commit. - **Builds reproductibles**, à terme, pour permettre la vérification indépendante. #### Sur la détection - **Surveillance du changement de mainteneur** et de licence sur les dépendances critiques. - **Analyse comportementale** des scripts d'installation, qui sont un vecteur courant. - **Détection des écarts** entre Build SBOM et Analyzed SBOM, qui révèle les introductions non déclarées. ### Cartographier votre exposition Un exercice à conduire une fois, puis à tenir à jour depuis la plateforme : | Question | Ce qu'elle révèle | | --- | --- | | Quels composants sont présents dans **plus de la moitié** de vos produits ? | Les points de défaillance unique | | Lesquels sont maintenus par **une seule personne** ? | Le risque de reprise ou d'abandon | | Lesquels n'ont pas eu de publication depuis **plus de deux ans** ? | Les candidats à l'abandon | | Lesquels sont **profonds** dans le graphe, hors de votre vue directe ? | Les angles morts de la diligence | | Lesquels exécutent du code à l'**installation** ? | La surface d'attaque de la chaîne de build | | Lesquels sont sous une **licence à risque** ou dont la licence a changé ? | Le risque juridique | Cette cartographie n'a pas besoin d'être exhaustive pour être utile : les dix à vingt composants les plus critiques concentrent l'essentiel du risque, et leur traitement est finançable. ### Le message pour la direction Une attaque de chaîne d'approvisionnement ne se prévient pas entièrement. Ce qui se décide, c'est le **temps de réaction**. Sans inventaire centralisé, ce temps se compte en semaines et la réponse est incomplète ; avec, il se compte en heures et la réponse est exhaustive. C'est la valeur du dispositif, indépendamment de toute obligation réglementaire. ## Sécurité par conception URL: https://cra-reference.eu/fr/cyber/secure-by-design/ Description: Traduire l'annexe I partie I en exigences vérifiables : modélisation des menaces, analyse de risques, plan de tests, et les référentiels mobilisables en attendant les normes harmonisées. Audience: cyber Legal basis: Annexe I, partie I · Art. 13, paragraphes 2 et 3 — analyse de risques Published 2026-08-19, updated 2026-08-19 Le contenu de l'annexe I, partie I, est détaillé dans [Sécurité du produit](/fr/cra/exigences-essentielles/securite-des-produits/). Cette page décrit **comment le produire**. ### L'analyse de risques : le document pivot Elle est exigée à deux titres : elle conditionne l'application des exigences essentielles « dans la mesure applicable au produit », et elle est une pièce du [dossier technique](/fr/cra/dossier-technique/). **Ce qu'elle doit contenir :** | Section | Contenu | | --- | --- | | Périmètre | Produit, versions, composants, interfaces | | Environnement de sécurité prévu | Hypothèses sur le déploiement — reprises telles quelles dans la notice utilisateur | | Biens à protéger | Données, fonctions, secrets, disponibilité | | Sources de menace et scénarios | Qui, avec quelles capacités, par quel chemin | | Évaluation | Vraisemblance et impact, sur une échelle définie et écrite | | Traitement | Mesure retenue pour chaque risque, ou acceptation motivée | | **Couverture de l'annexe I** | Exigence par exigence : applicable ou non, et pourquoi | | Risques résiduels | Assumés, par qui, avec quelle information à l'utilisateur | La dernière ligne est celle qui alimente le point 5 de l'annexe II — les circonstances connues pouvant entraîner un risque. **Quand la réviser :** à chaque évolution majeure de l'architecture, à chaque ajout de fonctionnalité exposée, à chaque changement de l'environnement de déploiement supposé, et au minimum annuellement. ### La modélisation des menaces L'analyse de risques est un document ; la modélisation des menaces est l'**atelier** qui la produit. À conduire au moment de la conception, pas après. Déroulé pratique, en deux à quatre heures par périmètre : 1. dessiner le **flux de données** et poser les frontières de confiance ; 2. pour chaque frontière, énumérer les menaces selon une grille stable — usurpation, altération, répudiation, divulgation, déni de service, élévation de privilèges ; 3. retenir les scénarios crédibles, écarter les autres **avec le motif** ; 4. associer une contre-mesure ou une acceptation à chaque scénario retenu ; 5. en déduire des **critères de test**. Le livrable est un schéma et une liste. Il est versé au dossier technique et rejoint la matrice de traçabilité. ### Le plan de tests L'annexe I, partie II, point 3, exige des **tests et revues de sécurité efficaces et réguliers**. « Régulier » suppose une cadence écrite et tenue. | Type de test | Ce qu'il couvre | Cadence type | | --- | --- | --- | | **Analyse de composition** (SCA) | Vulnérabilités des composants tiers | À chaque construction | | **Analyse statique** (SAST) | Défauts du code que vous écrivez | À chaque construction | | **Analyse de secrets** | Clés et identifiants dans le code | À chaque construction | | **Analyse de configuration** | Durcissement, infrastructure déclarative | À chaque construction | | **Analyse dynamique** (DAST) | Comportement de l'application exposée | Par version | | **Fuzzing** | Robustesse des analyseurs d'entrée | Continu sur les composants exposés | | **Revue de code sécurité** | Fonctions sensibles : authentification, cryptographie, analyse d'entrée | Par changement sensible | | **Test d'intrusion** | Vision d'ensemble, chaînage de défauts | Annuel, et avant les versions majeures | Chaque test doit produire un **rapport daté et conservé** : c'est la preuve de l'exigence. Un test réalisé sans rapport archivé n'existe pas pour l'auditeur. ### Le durcissement par défaut L'exigence de configuration sécurisée par défaut se traduit par un **référentiel de durcissement** écrit et testé automatiquement : - aucun identifiant par défaut partagé entre exemplaires ; - aucun service ou port ouvert sans nécessité fonctionnelle ; - interfaces de débogage absentes des versions de production ; - chiffrement activé par défaut sur les flux et les stockages ; - journalisation activée, avec la possibilité documentée de la désactiver ; - procédure de **réinitialisation à l'état d'origine** testée. Le test d'installation depuis l'état d'usine, exécuté automatiquement, est le contrôle le plus efficace : il vérifie ce que reçoit réellement le client, et non ce que la documentation affirme. ### Les référentiels mobilisables En attendant que les normes harmonisées soient citées au *Journal officiel* : | Référentiel | Ce qu'il couvre | | --- | --- | | **IEC 62443-4-1** | Processus de développement sécurisé | | **IEC 62443-4-2** | Exigences techniques des composants | | **[NIST SP 800-218](https://csrc.nist.gov/pubs/sp/800/218/final)** (SSDF) | Pratiques de développement sécurisé | | **[ETSI EN 303 645](https://www.etsi.org/deliver/etsi_en/303600_303699/303645/)** | Objets connectés grand public | | **EN 18031-1/-2/-3** | Équipements radio — travaux réutilisables | | **ISO/IEC 27001** | Système de management de la sécurité de l'information | | **ISO/IEC 29147** et **30111** | Divulgation et traitement des vulnérabilités | | **ISO/IEC 18974** | OpenChain — assurance sécurité du logiciel libre | > **Précision importante.** Appliquer ces référentiels ne confère **aucune présomption de > conformité** au sens du règlement tant qu'ils ne sont pas des normes harmonisées citées au > JOUE. Ils facilitent la démonstration et fournissent des preuves réutilisables ; ils ne > remplacent pas la démonstration. ## Surveillance continue URL: https://cra-reference.eu/fr/cyber/surveillance-continue/ Description: Rejouer le SBOM chaque jour contre des sources qui bougent : architecture, EUVD et plateforme de signalement de l'ENISA, surveillance de l'amont, indicateurs. Audience: cyber Legal basis: Annexe I, partie II, points 1 et 2 Published 2026-08-19, updated 2026-08-19 ### Le principe Un SBOM n'a de valeur que **rejoué en continu**. Un composant sain aujourd'hui est vulnérable demain, **sans qu'aucune nouvelle construction n'ait eu lieu**. C'est la différence entre un contrôle en CI et un dispositif de conformité. C'est aussi la raison pour laquelle la centralisation est obligatoire : on ne réévalue pas chaque jour des milliers de fichiers dispersés dans des registres d'artefacts. ### L'architecture ``` SBOM archivés (toutes versions livrées) │ ▼ Plateforme de pilotage ──── réévaluation quotidienne ────┐ ▲ │ │ ▼ Sources de vulnérabilités Alertes ciblées EUVD · OSV · NVD · avis éditeurs │ catalogues d'exploitation avérée ▼ avis des projets amont Équipe propriétaire du produit │ ▼ Triage → VEX → correctif ``` Le point essentiel est le mot **ciblées** : la plateforme n'envoie une alerte qu'aux équipes dont les produits contiennent réellement le composant, dans une version affectée. Une diffusion large produit du bruit et éteint l'attention. ### Les sources et leur usage | Source | Fréquence | Usage | | --- | --- | --- | | **[EUVD](https://euvd.enisa.europa.eu/)** — base européenne de vulnérabilités, opérée par l'ENISA | Quotidienne | Source européenne de référence, à privilégier dans vos rapports | | **[OSV](https://osv.dev/)** | Quotidienne | Corrélation par `purl`, précision élevée sur les paquets | | **[NVD](https://nvd.nist.gov/)** | Quotidienne | Couverture large, à filtrer pour éviter les faux positifs de CPE | | **Catalogues d'exploitation avérée** | Quotidienne | Déclencheur de priorisation, indice fort pour la qualification | | **Avis des éditeurs et distributions** | Quotidienne | Évite les faux positifs liés aux rétroportages | | **Avis des projets amont** | Suivi par abonnement | Souvent en avance sur les bases publiques | ### L'EUVD et la plateforme de signalement Deux dispositifs européens distincts, souvent confondus : | | **EUVD** | **Plateforme de signalement unique (SRP)** | | --- | --- | --- | | Nature | **Base de vulnérabilités** | **Canal de signalement** | | Origine | Créée sous NIS 2, opérée par l'ENISA | Créée par le CRA, opérée par l'ENISA | | Sens du flux | Vous la **consommez** | Vous y **émettez** | | Usage | Surveillance continue | Alerte 24 h, notification 72 h, rapport final | Le lien entre les deux : vos signalements alimentent, après traitement par le CSIRT coordinateur et l'ENISA, l'écosystème européen de connaissance des vulnérabilités — dont l'EUVD est la vitrine. C'est ce que signifie « alimenter l'EUVD via la plateforme de signalement ». ### La surveillance de l'amont Distincte de la surveillance des vulnérabilités, et tout aussi nécessaire : - **abonnement aux avis de sécurité** des projets dont vous dépendez de façon critique ; - **suivi de l'activité** : date du dernier commit, fréquence des publications, nombre de mainteneurs actifs ; - **détection des projets abandonnés**, et déclenchement de la stratégie décidée dans [Intégrer de l'open source](/fr/cra/open-source/integrer-de-l-oss/) ; - **alerte sur changement de mainteneur** ou de licence — les deux sont des signaux de risque, l'un de sécurité, l'autre juridique. Cette surveillance porte sur un nombre restreint de composants : ceux qui sont critiques pour vos produits. Tenter de surveiller l'intégralité du graphe transitif produit un bruit inexploitable. ### Ce qui doit être automatique | Automatique | Manuel | | --- | --- | | Réévaluation quotidienne du parc | Analyse d'exploitabilité | | Corrélation SBOM / sources | Rédaction du VEX | | Routage de l'alerte vers l'équipe propriétaire | Arbitrage de priorité en cas de conflit | | Ouverture d'un ticket avec le contexte | Décision de signalement | | Rappel à échéance de SLA | Communication client | | Détection d'un composant en fin de maintenance | Choix de la stratégie de remplacement | Le principe : **la machine trouve et route, l'humain décide**. Tout ce qui est laissé à l'initiative humaine dans la colonne de gauche finit par ne pas être fait. ### Les indicateurs - **Délai de détection** : temps entre la publication d'une vulnérabilité et son alerte chez vous. - **Délai de triage** : temps entre l'alerte et la décision de traitement. - **Délai de remédiation** par niveau de criticité. - **Couverture** : part des produits livrés dont le SBOM est effectivement surveillé. - **Âge moyen** des vulnérabilités ouvertes. - **Ratio d'alertes actionnables** sur alertes brutes — voir [Faux positifs](/fr/cyber/faux-positifs/). La **couverture** est le premier à regarder : surveiller parfaitement 40 % du portefeuille n'est pas un dispositif de conformité, c'est un pilote. ## Verrouiller et mettre à jour les dépendances URL: https://cra-reference.eu/fr/cyber/verrouillage-dependances/ Description: La tension centrale du sujet : figer pour reconstruire à l'identique pendant dix ans, et mettre à jour pour n'avoir aucune vulnérabilité exploitable connue. Fichiers de verrouillage, épinglage par empreinte, mise à jour automatisée et quarantaine. Audience: cyber Legal basis: Annexe I, partie I — absence de vulnérabilité exploitable connue · Annexe I, partie II, point 2 — corriger sans délai · Art. 13, paragraphe 8 — période de support Published 2026-08-20, updated 2026-08-20 ### Deux obligations qui tirent en sens contraire | Exigence | Ce qu'elle impose | Ce qu'elle pousse à faire | | --- | --- | --- | | **Annexe I, partie I** — pas de vulnérabilité exploitable connue à la mise sur le marché | Les composants doivent être **à jour** | Mettre à jour souvent | | **Annexe I, partie II, point 2** — corriger sans délai | Idem, en continu | Mettre à jour vite | | **Art. 13, paragraphe 8** — période de support de cinq à dix ans | Pouvoir **reconstruire à l'identique** une version livrée il y a huit ans | Tout figer | Le règlement exige donc simultanément la fraîcheur et la reproductibilité. La réponse n'est pas un compromis mou : c'est **figer précisément, et mettre à jour délibérément**. ### Figer : le fichier de verrouillage Un manifeste déclare des **intervalles** (« version 5 ou supérieure ») ; un fichier de verrouillage enregistre la **résolution exacte**, transitives comprises, avec les empreintes. Sans lui, deux constructions du même code à deux dates différentes produisent deux artefacts différents. Les conséquences sont directement réglementaires : - le **SBOM** ne décrit plus de façon fiable ce qui a été livré ; - la **reconstruction** d'une version ancienne devient impossible, donc la période de support aussi ; - une **substitution silencieuse** de dépendance ne se voit pas. **La règle** : le fichier de verrouillage est **commité**, il fait partie du code source, et la construction publiable échoue si la résolution s'en écarte. C'est ce que garantissent les modes d'installation stricts des différents écosystèmes, qui refusent de mettre à jour le fichier de verrouillage à la volée. ### Figer aussi ce qui n'est pas une dépendance applicative C'est l'angle mort le plus fréquent : on verrouille les bibliothèques, et on laisse mutable tout le reste de la chaîne. | Élément | Référence mutable — à éviter | Référence immuable | | --- | --- | --- | | Action ou étape de CI réutilisée | Étiquette de version | **Empreinte de commit complète** | | Image de base de conteneur | `:latest`, ou une étiquette de version | **Empreinte de contenu** | | Script distant exécuté par la chaîne | URL vers la branche principale | URL figée **+ vérification d'empreinte** | | Outil installé à la volée | « dernière version » | Version exacte, empreinte vérifiée | > **Pourquoi c'est décisif.** Une étiquette peut être **repointée** vers un autre commit sans > qu'aucune de vos références ne change. C'est exactement l'attaque qui a exposé les secrets de > milliers de chaînes en mars 2025 — voir [Incidents de référence](/fr/cyber/incidents/). Une > empreinte, elle, ne se repointe pas. ### Mettre à jour : délibérément, pas automatiquement Figer sans mettre à jour produit l'inverse du résultat cherché : un produit reproductible et vulnérable. Les robots de mise à jour — Dependabot, Renovate — sont l'outillage standard. Ils ouvrent des propositions de modification lorsqu'une version est publiée, avec les notes de version et, selon la configuration, la vulnérabilité corrigée. **Mais un robot de mise à jour est lui-même un vecteur.** Une montée de version automatique fusionnée sans revue introduit du code tiers directement en production. Trois garde-fous : | Garde-fou | Effet | | --- | --- | | **Délai de quarantaine** | Aucune version publiée depuis moins de N jours n'est proposée. Les paquets malveillants sont généralement retirés en quelques heures ou quelques jours | | **Fusion automatique restreinte** | Réservée aux correctifs de sécurité sur des composants en liste blanche, et jamais pour un changement de version majeure | | **Revue humaine des dépendances sensibles** | Liste explicite des composants dont toute montée de version passe par une personne | ### L'ingestion contrôlée : cache ou point de décision ? Faire transiter les dépendances par un miroir interne est une bonne pratique répandue, mais il faut distinguer deux dispositifs que l'on confond souvent : | | **Cache ou miroir** | **Point de décision à l'entrée** | | --- | --- | --- | | Fonction | Sert plus vite, résiste à l'indisponibilité amont | **Autorise, refuse, met en quarantaine** | | Moment | Après téléchargement | **Avant l'entrée dans l'organisation** | | Face à un paquet malveillant | Il le **propage**, et le conserve | Il le **bloque** | Un cache accélère ; il ne gouverne pas. Si l'objectif est d'empêcher un paquet typosquatté ou fraîchement publié d'entrer, il faut une décision appliquée **avant** l'ingestion, et une politique qui vive à côté du code plutôt que dans une console. Point souvent négligé : la configuration seule ne suffit pas. Tant qu'un poste peut joindre directement le registre public, le contournement est trivial. Le **filtrage sortant** est ce qui rend la règle effective. ### La reproductibilité, exigence de long terme Sur un produit couvert par une période de support de dix ans, il faut pouvoir reconstruire dans huit ans. Cela suppose de conserver, en plus du code : - le **fichier de verrouillage** de la version livrée ; - les **empreintes** des images de base et des outils de construction ; - une **copie des artefacts amont** — un registre public n'est pas un service d'archivage, et des paquets disparaissent ; - la **définition de la chaîne** telle qu'elle était. La démarche des **[builds reproductibles](https://reproducible-builds.org/)** pousse la logique à son terme : deux constructions du même code produisent des artefacts identiques bit à bit. C'est exigeant, et c'est la seule preuve réellement vérifiable par un tiers. Le recoupement mérite d'être dit : ce que le règlement impose de conserver pour la période de support, et ce que la **GPL** impose de fournir comme « code source correspondant », sont le même ensemble d'artefacts. Voir [Application bureau ou ligne de commande](/fr/licences/scenarios/application-bureau/). ### Liste de contrôle - [ ] Fichier de verrouillage **commité** pour chaque écosystème - [ ] Construction publiable **en mode strict**, qui échoue si la résolution s'écarte - [ ] Actions et étapes de CI épinglées par **empreinte de commit** - [ ] Images de base épinglées par **empreinte de contenu** - [ ] Robot de mise à jour actif, avec **délai de quarantaine** - [ ] Fusion automatique limitée aux correctifs de sécurité, composants en liste blanche - [ ] Liste des dépendances à **revue humaine obligatoire** - [ ] Dépendances servies par un **miroir interne**, avec filtrage sortant - [ ] Artefacts amont **archivés** pour la durée de la période de support - [ ] Test annuel : **reconstruire** une version livrée il y a plus de deux ans ## Démarrer URL: https://cra-reference.eu/fr/demarrer/ Description: Comment ce site est organisé, quel parcours suivre selon votre équipe, et les quinze termes à connaître avant d'ouvrir le règlement. Audience: transverse Published 2026-08-19, updated 2026-08-19 Ce site est un référentiel public sur les nomenclatures logicielles (SBOM) et le règlement (UE) 2024/2847, dit **Cyber Resilience Act**. Il s'adresse à deux équipes dont les obligations sont distinctes mais indissociables : le **Juridique / Conformité** et la **Cybersécurité / DevSecOps**. ### Le principe d'organisation Trois erreurs guettent ce type de référentiel : dupliquer le contenu réglementaire dans une section Legal et une section Cyber — elles divergent en six mois ; suivre l'ordre des articles du règlement, que personne ne lit ; mélanger la doctrine (ce que dit la loi) et la pratique interne (ce que vous faites). Le site sépare donc quatre couches : | Couche | Rôle | Sections | | --- | --- | --- | | **Référentiel réglementaire** | Source de vérité unique sur le règlement. Neutre, sourcée, datée. | Le cadre CRA | | **Référentiel technique** | Source de vérité unique sur le SBOM : formats, qualité, VEX, licences. | Le SBOM | | **Parcours métier** | Traduction en obligations, risques et actions pour un rôle donné. Ne redéfinit rien. | Juridique, Cyber, Direction | | **Opérationnel** | Votre organisation, l'outillage, vos modèles, la feuille de route. | Organisation, Outils, Ressources | > **Règle éditoriale.** Une notion réglementaire n'est définie **qu'une seule fois**, dans > la section « Le cadre CRA ». Les parcours Juridique et Cyber n'en font que des lectures > orientées, avec un lien vers la page canonique. Si vous constatez une définition > dupliquée, c'est un défaut à signaler. ### Comment lire une page Chaque page porte les mêmes repères, affichés au même endroit : - un **badge de cible principale** — Legal, Cyber, Direction ou Transverse ; - une **échéance** lorsqu'une des trois dates du règlement s'y attache ; - un encadré **« Repères »** en colonne latérale : base légale (articles et annexes), **artefact de preuve** attendu pour l'audit, fonction propriétaire du contenu et **date de dernière revue**. La date de revue n'est pas décorative. Un contenu réglementaire non daté est un contenu dont on ne sait pas s'il est encore vrai ; trois sujets bougent encore (normes harmonisées, actes délégués, désignation des autorités nationales), et la section [veille](/fr/actualites/) existe pour cela. ### Choisir son parcours - **[Parcours Juridique](/fr/demarrer/parcours-legal/)** — de la qualification du produit à l'apposition du marquage CE, en dix étapes d'une trentaine de minutes. - **[Parcours Cyber](/fr/demarrer/parcours-cyber/)** — de la génération du SBOM à la procédure de signalement à 24 heures, en dix étapes. - **[Vue Direction](/fr/direction/)** — l'exposition, le coût, les arbitrages. Si vous ne savez pas encore si vous êtes concerné, commencez par [le périmètre](/fr/cra/perimetre-pde/) puis [les exclusions](/fr/cra/exclusions/) : ces deux pages répondent en dix minutes à la seule question qui compte au départ. ### Ce qu'il faut retenir avant tout le reste 1. Le CRA est un **règlement** : d'application directe, sans transposition nationale. Il n'y aura pas de loi française qui viendra décaler l'échéance. 2. La première échéance n'est pas le marquage CE, c'est le **signalement**. Depuis le 11 septembre 2026, une vulnérabilité activement exploitée doit être signalée sous **24 heures** — y compris pour les produits mis sur le marché avant cette date. 3. Le **SBOM est une pièce du dossier technique**. Sans dossier technique complet, pas de déclaration UE de conformité ; sans déclaration, pas de marquage CE ; sans marquage CE, pas de commercialisation dans l'Union. 4. Générer un SBOM dans la chaîne de construction et piloter le portefeuille depuis une plateforme centrale sont **deux métiers différents** — voir [Générer et piloter](/fr/organisation/deux-niveaux/). ## Parcours Cyber en 10 étapes URL: https://cra-reference.eu/fr/demarrer/parcours-cyber/ Description: Un chemin de lecture linéaire d'une trentaine de minutes, de la génération d'un SBOM à la procédure de signalement à 24 heures, pour un ingénieur qui découvre le Cyber Resilience Act. Audience: cyber Published 2026-08-19, updated 2026-08-19 Trente minutes, dix étapes, dans l'ordre. Chaque étape se termine par la question à laquelle vous devez savoir répondre avant de passer à la suivante. ### 1. Lire ce que le règlement exige techniquement — 5 min Lire [Exigences essentielles](/fr/cra/exigences-essentielles/), puis les deux pages qui en découlent : [Sécurité du produit](/fr/cra/exigences-essentielles/securite-des-produits/) (annexe I, partie I) et [Traitement des vulnérabilités](/fr/cra/exigences-essentielles/traitement-des-vulnerabilites/) (annexe I, partie II). > **À savoir répondre :** parmi les treize exigences de la partie I, lesquelles ne sont pas > applicables à votre produit, et sur quelle base documentée ? ### 2. Savoir ce qu'est un SBOM conforme — 3 min Lire [Définition](/fr/sbom/definition/) et [Ce que le CRA exige](/fr/sbom/exigence-cra/). Format couramment utilisé, lisible par machine, au minimum les dépendances de premier niveau — un plancher légal, pas une cible. > **À savoir répondre :** pourquoi un tableur ou un PDF ne satisfont-ils pas l'exigence ? ### 3. Choisir un format et s'y tenir — 3 min Lire [Formats](/fr/sbom/formats/), puis [CycloneDX](/fr/sbom/formats/cyclonedx/) et [SPDX](/fr/sbom/formats/spdx/). > **À savoir répondre :** quel est votre format pivot, et dans quel cas exportez-vous dans > l'autre ? ### 4. Générer — 4 min Lire [Générer un SBOM](/fr/cyber/generer-un-sbom/) et [Générateurs](/fr/outils/generation/). Le SBOM se produit **au plus près de l'artefact**, dans le pipeline qui le fabrique, jamais à la main a posteriori. > **À savoir répondre :** deux outils produisent deux SBOM différents pour le même > artefact — comment garantissez-vous la comparabilité dans le temps ? ### 5. Intégrer dans la CI/CD — 3 min Lire [Intégration CI/CD](/fr/cyber/integration-cicd/). Huit étapes : construire, générer, valider, signer, publier, appliquer les politiques, attacher, archiver. > **À savoir répondre :** quelles conditions font échouer un build, et comment obtient-on > une dérogation qui expire ? ### 6. Comprendre la distinction générer / piloter — 4 min Lire [Générer et piloter](/fr/organisation/deux-niveaux/) puis [Plateformes](/fr/outils/plateformes/). C'est le malentendu le plus coûteux du sujet. « On a mis un scanner dans la CI, on est conformes » est faux : sans centralisation, on ne peut ni répondre à une autorité, ni savoir quelles versions livrées sont affectées. > **À savoir répondre :** en combien de temps pouvez-vous lister les produits contenant un > composant donné, toutes versions livrées confondues ? ### 7. Traiter les vulnérabilités sans se noyer — 4 min Lire [Gestion des vulnérabilités](/fr/cyber/gestion-des-vulnerabilites/), [VEX](/fr/sbom/vex/) et [Faux positifs](/fr/cyber/faux-positifs/). Le VEX est la forme documentaire d'une décision motivée de ne pas corriger. C'est ce qui distingue « traité » d'« ignoré ». > **À savoir répondre :** quel est votre ratio d'alertes actionnables sur alertes brutes ? ### 8. Ouvrir un canal de signalement — 2 min Lire [Politique CVD](/fr/cyber/politique-cvd/) et la page publique [Divulgation des vulnérabilités](/fr/securite/). L'adresse de contact et la politique publiée sont des **obligations de fond**, pas des pages de courtoisie. > **À savoir répondre :** votre `security.txt` est-il en ligne, et son champ `Expires` > est-il encore dans le futur ? ### 9. Armer la procédure à 24 heures — 3 min Lire [Procédure 24 h / 72 h / 14 j](/fr/cyber/procedure-24h/) et [Le signalement à l'ENISA](/fr/cra/signalement-enisa/). Une astreinte, un canal testé, des gabarits pré-remplis, deux exercices par an. > **À savoir répondre :** quel est votre délai réel mesuré lors du dernier exercice ? ### 10. Surveiller en continu — 2 min Lire [Surveillance continue](/fr/cyber/surveillance-continue/) et [Risques de chaîne d'approvisionnement](/fr/cyber/risques-supply-chain/). Un composant sain aujourd'hui est vulnérable demain, sans nouveau build. Le SBOM ne sert que s'il est rejoué chaque jour contre des sources qui bougent. --- ### Et ensuite [Sécurité par conception](/fr/cyber/secure-by-design/), [Mises à jour sécurisées](/fr/cyber/mises-a-jour-securisees/) et la [liste de contrôle technique](/fr/cyber/checklist-technique/) complètent le parcours. Quatre pages traitent de la chaîne d'approvisionnement elle-même, et se lisent dans cet ordre : 1. **[Incidents de référence](/fr/cyber/incidents/)** — quatorze compromissions datées, pour savoir de quoi on parle ; 2. **[Sécuriser la chaîne de construction](/fr/cyber/chaine-ci-securisee/)** — la CI comme surface d'attaque, et non comme simple outil ; 3. **[Verrouiller et mettre à jour les dépendances](/fr/cyber/verrouillage-dependances/)** — figer pour reconstruire, mettre à jour pour ne pas être vulnérable ; 4. **[Évaluer un composant open source](/fr/cyber/evaluer-un-composant/)** — rendre calculable la diligence de l'article 13, paragraphe 5. ## Parcours Juridique en 10 étapes URL: https://cra-reference.eu/fr/demarrer/parcours-legal/ Description: Un chemin de lecture linéaire d'une trentaine de minutes, de la qualification du produit à l'apposition du marquage CE, pour un juriste qui découvre le Cyber Resilience Act. Audience: legal Published 2026-08-19, updated 2026-08-19 Trente minutes, dix étapes, dans l'ordre. Chaque étape se termine par la question à laquelle vous devez savoir répondre avant de passer à la suivante. ### 1. Comprendre la nature du texte — 3 min Lire [Le cadre CRA](/fr/cra/) et [Le règlement (UE) 2024/2847](/fr/cra/reglement-2024-2847/). Un règlement, pas une directive : application directe, pas de transposition. Une législation d'harmonisation du « nouveau cadre législatif » : la grammaire du marquage CE, appliquée à la cybersécurité. > **À savoir répondre :** pourquoi n'y aura-t-il pas de loi nationale de transposition > susceptible de décaler l'échéance ? ### 2. Déterminer si vos produits sont concernés — 5 min Lire [Le périmètre](/fr/cra/perimetre-pde/) puis [Les exclusions](/fr/cra/exclusions/). Attention à trois points : les **composants mis sur le marché séparément** sont eux-mêmes des produits ; les **solutions de traitement de données à distance** indissociables du produit entrent dans le périmètre ; le SaaS « pur », lui, relève de NIS 2. > **À savoir répondre :** votre offre cloud est-elle une solution de traitement de données > à distance au sens du règlement, ou un service hors périmètre ? ### 3. Classer chaque produit — 4 min Lire [Les classes de criticité](/fr/cra/classes-de-criticite/). C'est la page qui pilote le budget et le planning : la classe détermine si un **organisme notifié** est obligatoire. > **À savoir répondre :** lesquels de vos produits ne peuvent pas s'auto-évaluer ? ### 4. Savoir ce que le marquage CE exige — 3 min Lire [Le marquage CE](/fr/cra/marquage-ce/). Sept conditions cumulatives préalables à l'apposition, dont le dossier technique et la déclaration UE de conformité. > **À savoir répondre :** quelles pièces manquent aujourd'hui pour votre produit phare ? ### 5. Comprendre la place du SBOM — 3 min Lire [Ce que le CRA exige du SBOM](/fr/sbom/exigence-cra/) puis [Le dossier technique](/fr/cra/dossier-technique/). Le SBOM est une **pièce constitutive** du dossier technique, pas un livrable technique annexe. > **À savoir répondre :** pourquoi un dossier sans SBOM exploitable fragilise-t-il > juridiquement le marquage CE ? ### 6. Intégrer les délais de signalement — 4 min Lire [Le signalement à l'ENISA](/fr/cra/signalement-enisa/) puis [Obligations de signalement, vue juridique](/fr/legal/obligations-de-signalement/). 24 heures, 72 heures, 14 jours. Ne pas confondre avec les 72 heures du RGPD ni avec la notification NIS 2 : un même événement peut déclencher les trois. > **À savoir répondre :** qui, chez vous, a autorité pour décider un signalement un > dimanche à 3 heures du matin ? ### 7. Mesurer l'exposition — 3 min Lire [Les sanctions](/fr/cra/sanctions/) puis [Exposition et risques](/fr/legal/sanctions-et-exposition/). L'amende n'est pas le pire : l'interdiction ou le retrait du marché de l'Union l'est. > **À savoir répondre :** combien représentent 2,5 % de votre chiffre d'affaires > consolidé, et quelle part de votre chiffre d'affaires est réalisée dans l'Union ? ### 8. Sécuriser la chaîne d'approvisionnement par le contrat — 3 min Lire [Clauses contractuelles](/fr/legal/clauses-contractuelles/). Vos délais de signalement dépendent de la réactivité de vos fournisseurs : leurs délais de notification doivent être **strictement inférieurs** aux nôtres. > **À savoir répondre :** vos contrats fournisseurs actuels vous permettent-ils de tenir > 24 heures ? ### 9. Traiter la propriété intellectuelle — 2 min Lire [Licences open source](/fr/licences/) — en particulier la [matrice famille × scénario](/fr/licences/) — puis [Propriété intellectuelle](/fr/legal/propriete-intellectuelle/). Le CRA n'impose pas la conformité aux licences, mais le SBOM qu'il rend obligatoire est exactement l'outil qui permet de la démontrer. C'est le meilleur argument de financement côté Juridique. ### 10. Verrouiller la mise sur le marché — 2 min Lire [Liste de contrôle avant mise sur le marché](/fr/legal/checklist-mise-sur-le-marche/). Quinze points, une page, imprimable et signable. C'est le livrable qui matérialise le droit de veto du Juridique. --- ### Et ensuite Les pages [Documentation utilisateur](/fr/legal/documentation-utilisateur/), [Période de support](/fr/legal/support-contractuel/) et [Conservation des preuves](/fr/legal/conservation-des-preuves/) complètent le parcours. Le [glossaire](/fr/glossaire/) et la [FAQ](/fr/faq/) répondent aux questions ponctuelles. ## Auto-diagnostic URL: https://cra-reference.eu/fr/diagnostic/ Description: Une grille d'évaluation en cinq modules pour situer votre maturité, identifier les écarts prioritaires et mesurer la progression d'un trimestre à l'autre. Audience: transverse Published 2026-08-19, updated 2026-08-19 À remplir trimestriellement, par le comité, sur la base de faits vérifiables — pas d'impressions. Chaque réponse est **oui** seulement si une preuve peut être produite dans l'heure. **Date du diagnostic :** ____________ **Participants :** ______________________ ### Module 1 — Périmètre et classification - [ ] Le portefeuille est **intégralement qualifié** : chaque produit a une fiche PDE signée - [ ] Les **exclusions** invoquées sont documentées par une fiche motivée - [ ] Chaque produit dans le périmètre a une **fiche de classification** co-signée - [ ] Le **registre de classification** consolidé existe et a été revu il y a moins d'un an - [ ] Les produits de **classe II et Critiques** sont identifiés, et un organisme notifié est **engagé contractuellement** pour chacun - [ ] La **voie d'évaluation** de chaque produit est décidée et documentée **Score : ___ / 6** ### Module 2 — SBOM et outillage - [ ] Un **format pivot** est décidé et appliqué uniformément - [ ] Le SBOM est généré **automatiquement** par la chaîne de construction sur tous les produits actifs - [ ] Un **score de qualité** est calculé et un seuil est **bloquant** en CI - [ ] Les SBOM sont **signés** et accompagnés d'une attestation de provenance - [ ] Une **plateforme de pilotage** ingère tous les SBOM produits - [ ] La **surveillance continue** couvre toutes les versions **livrées**, pas seulement la dernière - [ ] L'**outillage est figé et documenté** par famille de produits **Score : ___ / 7** ### Module 3 — Vulnérabilités et divulgation - [ ] Des **SLA de remédiation** sont écrits, publiés en interne et **mesurés** - [ ] Les vulnérabilités non corrigées font l'objet d'un **VEX** avec justification normalisée - [ ] Des **avis de sécurité** sont publiés pour les vulnérabilités corrigées - [ ] Une **politique CVD** est publiée et le point de contact est actif - [ ] Le fichier **`security.txt`** est en ligne et son champ `Expires` est dans le futur - [ ] Un **registre des signalements reçus** existe et est tenu - [ ] Le **ratio d'alertes actionnables** est mesuré et suivi dans le temps **Score : ___ / 7** ### Module 4 — Capacité de signalement - [ ] Une **astreinte** technique **et** juridique existe, avec suppléants nommés - [ ] Une **délégation écrite** de la décision de signaler est en vigueur - [ ] Des **comptes actifs** sur la plateforme de signalement existent et ont été testés il y a moins de six mois - [ ] Des **gabarits** d'alerte, de notification et de rapport final sont prêts - [ ] La **liste des États membres** de mise à disposition est tenue par produit - [ ] Un **registre des décisions** de signaler ou de ne pas signaler est tenu, avec les motivations - [ ] Un **exercice chronométré** a eu lieu dans les six derniers mois, et le délai obtenu est inférieur à 24 heures **Score : ___ / 7** ### Module 5 — Documentation et preuves - [ ] Un **gabarit de dossier technique** existe et est utilisé - [ ] Chaque produit mis sur le marché a un **dossier technique complet et gelé** - [ ] Les **déclarations UE de conformité** sont signées par une personne habilitée - [ ] Les **notices utilisateur** de l'annexe II sont livrées, avec la date de fin de support - [ ] La **période de support** de chaque produit est déterminée, justifiée et communiquée - [ ] Un **coffre de preuves** avec archivage dix ans est en place - [ ] Un **exercice de restitution** a eu lieu dans l'année, et il a **réussi** **Score : ___ / 7** --- ### Restitution | Module | Score | Sur | Niveau | | --- | --- | --- | --- | | 1. Périmètre et classification | | 6 | | | 2. SBOM et outillage | | 7 | | | 3. Vulnérabilités et divulgation | | 7 | | | 4. Capacité de signalement | | 7 | | | 5. Documentation et preuves | | 7 | | | **Total** | | **34** | | **Lecture des niveaux, par module :** | Part de « oui » | Niveau | Interprétation | | --- | --- | --- | | Moins de 30 % | **Initial** | Le sujet est identifié, rien n'est outillé | | 30 à 60 % | **En construction** | Des briques existent, sans continuité | | 60 à 85 % | **Opérationnel** | Le dispositif fonctionne, des angles morts subsistent | | Plus de 85 % | **Maîtrisé** | Le dispositif tient sous contrôle, l'enjeu est de le maintenir | ### Les trois questions qui priment sur le score Quel que soit le total, trois réponses négatives justifient une action immédiate : 1. **Le module 4 est-il complet ?** L'échéance de signalement est passée et s'applique au parc historique. 2. **Les organismes notifiés sont-ils engagés** pour les produits de classe II et Critiques ? C'est le seul délai que vous ne maîtrisez pas. 3. **L'exercice de restitution a-t-il réussi ?** C'est le seul contrôle qui prouve que l'archivage fonctionne. ### Usage Archiver chaque diagnostic daté. La **progression** entre deux diagnostics est plus informative que le score absolu, et c'est elle qui se présente au comité exécutif. ## Direction URL: https://cra-reference.eu/fr/direction/ Description: Le CRA en cinq minutes pour un comité exécutif : l'exposition au marché, l'exposition financière, les décisions attendues et l'état d'avancement. Audience: direction Published 2026-08-19, updated 2026-08-19 ### En une phrase **Sans nomenclature logicielle et sans processus documenté de traitement des vulnérabilités, vous ne pourrez plus apposer le marquage CE sur vos produits numériques — donc plus les vendre dans l'Union européenne.** ### En trois chiffres | | | | --- | --- | | **11 septembre 2026** | Signalement d'une vulnérabilité activement exploitée sous **24 heures** à l'ENISA et au CSIRT coordinateur. S'applique **aussi aux produits déjà sur le marché**. | | **11 décembre 2027** | Marquage CE, dossier technique, SBOM, période de support, information de l'utilisateur : application pleine et entière. | | **15 M€ ou 2,5 %** | Plafond de l'amende administrative pour manquement aux exigences essentielles ou aux obligations de signalement — le montant le plus élevé entre 15 millions d'euros et 2,5 % du chiffre d'affaires annuel mondial. | ### Les cinq faits qui déterminent l'effort 1. **La classe de criticité pilote le coût.** Un produit « par défaut » s'auto-évalue ; un produit Important de classe II ou Critique exige un **organisme notifié**, avec un délai de plusieurs mois et une capacité de marché limitée. C'est le chemin critique. 2. **La période de support engage sur cinq à dix ans.** Elle oblige à maintenir des chaînes de compilation, à rétroporter des correctifs et à conserver des artefacts bien au-delà de la fin de vie commerciale. 3. **L'échéance de signalement est déjà là**, et elle couvre le parc historique. Elle suppose une astreinte, pas un projet. 4. **Le CRA recoupe largement NIS 2, DORA et les questionnaires clients.** L'effort n'est pas perdu : il alimente aussi ces exigences. 5. **Le SBOM est devenu un argument commercial.** Grands comptes et acheteurs publics le demandent déjà ; le produire répond à une obligation et raccourcit les cycles de vente. ### Les décisions attendues du comité - **Nommer un sponsor exécutif** et valider la [matrice RACI](/fr/organisation/raci/), notamment les trois arbitrages listés dans [Organisation](/fr/organisation/). - **Arbitrer le scénario d'investissement** parmi les trois décrits dans [Budget et ressources](/fr/direction/budget/), en assumant explicitement le risque résiduel du scénario retenu. - **Autoriser l'engagement contractuel avec un organisme notifié** pour les produits qui ne peuvent pas s'auto-évaluer, sans attendre la publication des normes harmonisées. ### Où en êtes-vous L'état d'avancement se lit dans [Indicateurs](/fr/organisation/indicateurs/) : couverture du portefeuille, délais de remédiation, exposition résiduelle. Le [diagnostic](/fr/diagnostic/) permet de le réévaluer trimestriellement selon une grille stable. ## Budget, ressources et scénarios URL: https://cra-reference.eu/fr/direction/budget/ Description: Trois scénarios d'investissement avec leur risque résiduel, les postes à provisionner, les profils nécessaires et les arbitrages à trancher. Audience: direction Published 2026-08-19, updated 2026-08-19 ### Les postes à provisionner | Poste | Investissement | Récurrent | | --- | --- | --- | | Plateforme de pilotage | Intégration, migration | Licence ou exploitation | | Générateurs et intégration CI | Développement des scripts communs | Maintenance | | Coffre de preuves et archivage | Mise en place, indexation | Stockage, migrations | | Organismes notifiés | Première évaluation par produit | Extensions, réévaluations | | Certification des produits critiques | Cible de sécurité, laboratoire | Maintenance du certificat | | PSIRT et astreinte | Recrutement, outillage | Salaires, rotation | | Conformité et juridique | Clausier, modèles, formation | Veille, revues | | Maintien du support long | Environnements de construction conservés | **Rétroportages, sur 5 à 10 ans** | | Formation | Conception des supports | Sessions récurrentes | | Exercices et audits | Premier cycle | Semestriel et annuel | ### Les profils nécessaires | Profil | Rôle | Charge indicative | | --- | --- | --- | | **Responsable conformité produit** | Tient les registres, pilote les dossiers techniques, interface avec les autorités | Temps plein dès la vague 0 | | **Ingénieur sécurité applicative** | Outillage, intégration CI, qualité des SBOM | Temps plein en vagues 2 et 3 | | **Analyste PSIRT** | Triage, VEX, avis, signalement | Temps plein dès la vague 1 | | **Juriste** | Classification, contrats, décisions de signalement | Fraction, avec astreinte | | **Référent par équipe produit** | Applique, remédie, documente | Fraction, sur toutes les équipes | L'**astreinte** est le poste le plus souvent oublié : une obligation à 24 heures suppose une rotation, donc un effectif minimal, et une compensation. ### Trois scénarios #### Scénario A — Minimal conforme **Contenu.** Outillage ouvert, plateforme auto-hébergée, coffre de preuves sur l'infrastructure existante, astreinte mutualisée avec les astreintes existantes, dossiers techniques rédigés en interne, organismes notifiés uniquement là où c'est obligatoire. **Ce qu'il couvre.** Les obligations, sans marge. **Risque résiduel :** faible tolérance à l'imprévu. Un incident majeur simultané à une demande d'autorité sature l'équipe. Le maintien du support long est le poste qui craquera en premier, vers la troisième année. **À qui il convient :** portefeuille limité, produits majoritairement en catégorie par défaut. #### Scénario B — Recommandé **Contenu.** Le scénario A, plus : une équipe PSIRT dédiée avec astreinte propre, un outil commercial sur le maillon le plus faible — généralement le volet licences ou l'atteignabilité —, un budget de rétroportage identifié, deux exercices par an, un audit externe annuel. **Ce qu'il couvre.** Les obligations, avec la capacité d'absorber un incident et de tenir dans la durée. **Risque résiduel :** acceptable et nommé. **À qui il convient :** la plupart des organisations ayant des produits importants au sens de l'annexe III. #### Scénario C — Ambitieux **Contenu.** Le scénario B, plus : plateforme d'entreprise intégrée, analyse d'atteignabilité, portail client avec SBOM et avis au format lisible par machine, builds reproductibles, participation aux travaux de normalisation, statut d'autorité de numérotation. **Ce qu'il couvre.** Les obligations, et un positionnement commercial différenciant. **À qui il convient :** produits critiques, base installée large, secteurs régulés, ou stratégie de différenciation par la transparence. ### Le tableau de décision | | A — Minimal | B — Recommandé | C — Ambitieux | | --- | --- | --- | --- | | Couvre les obligations | Oui, sans marge | Oui | Oui | | Tient un incident majeur | Difficilement | Oui | Oui | | Tient sur dix ans | Incertain | Oui | Oui | | Argument commercial | Non | Partiel | **Oui** | | Risque résiduel | **Élevé** | Modéré | Faible | | Décision requise | Accepter le risque, nommément | Financer | Financer et arbitrer le portefeuille | ### Les arbitrages à trancher 1. **Internaliser ou externaliser** le PSIRT et l'astreinte ? L'externalisation réduit le coût fixe mais transfère mal la connaissance produit, qui est le cœur de la qualification. 2. **Outillage ouvert ou commercial ?** La recommandation est de commencer par l'ouvert pour mesurer, puis d'investir sur l'écart constaté — pas sur l'écart annoncé. 3. **Quel périmètre prioritaire ?** Traiter d'abord les produits de classe II et Critiques, puis ceux à plus fort chiffre d'affaires dans l'Union. 4. **Que faire des produits dont la conformité coûte plus qu'ils ne rapportent ?** C'est une décision de portefeuille, à prendre explicitement plutôt qu'à subir. Elle est légitime et doit être documentée. ### Ce qu'il faut demander au comité Une décision écrite sur : le **scénario retenu**, le **risque résiduel accepté** avec le nom de qui l'accepte, le **budget** en investissement et en récurrent, et les **produits sortis du portefeuille** le cas échéant. Un scénario retenu sans acceptation nommée du risque résiduel n'est pas une décision : c'est un report. ## Impact sur l'activité URL: https://cra-reference.eu/fr/direction/impact-business/ Description: Risque d'accès au marché, exposition financière, coût de la conformité, opportunités commerciales et effet d'entraînement sur NIS 2, DORA et les questionnaires clients. Audience: direction Published 2026-08-19, updated 2026-08-19 ### Le risque d'accès au marché C'est le risque principal, et il n'est pas graduel : sans marquage CE, un produit ne peut pas être mis sur le marché de l'Union. **Calcul à produire pour le comité :** | Ligne | Valeur | | --- | --- | | Chiffre d'affaires réalisé dans l'Union européenne | _____ M€ | | Part réalisée par des produits comportant des éléments numériques | _____ % | | **Chiffre d'affaires exposé** | _____ M€ | | Part de ce chiffre d'affaires portée par des produits de classe II ou Critique | _____ % | | **Chiffre d'affaires dépendant d'un organisme notifié** | _____ M€ | La dernière ligne est celle qui doit déclencher la décision : c'est le chiffre d'affaires dont la continuité dépend d'un tiers dont vous ne maîtrisez pas le délai. ### L'exposition financière Trois composantes, détaillées dans [Exposition et registre des risques](/fr/legal/sanctions-et-exposition/) : 1. **Administrative** — jusqu'à 15 M€ ou 2,5 % du chiffre d'affaires mondial. 2. **Commerciale** — chiffre d'affaires perdu pendant une interdiction ou un retrait, plus le coût d'un rappel pour un produit matériel. 3. **Contractuelle** — pénalités, résiliations et indemnisations prévues par vos contrats. À quoi s'ajoute l'exposition en **responsabilité civile** : la directive (UE) 2024/2853 inclut le logiciel et prend en compte l'absence de mises à jour de sécurité dans l'appréciation du défaut. ### Le coût de la conformité | Poste | Nature | Horizon | | --- | --- | --- | | **Outillage** | Investissement puis abonnement | Récurrent | | **Effectifs** | PSIRT, conformité, ingénierie sécurité | Récurrent | | **Astreinte** | Rotation technique et juridique | Récurrent | | **Organismes notifiés** | Évaluation initiale et maintien | Par produit, par cycle | | **Certification** des produits critiques | Laboratoire d'évaluation, maintenance du certificat | Par produit, cycle long | | **Maintien du support 5 à 10 ans** | Chaînes de compilation, rétroportages, archivage | **Le plus sous-estimé** | | **Formation** | Développement, juridique, achats | Ponctuel puis récurrent | Le poste le plus sous-estimé est le dernier de la colonne : **maintenir la capacité de produire un correctif pour une version livrée il y a huit ans** suppose des environnements de construction conservés, des compétences disponibles et une organisation qui y consacre du temps sans revenu associé. ### Les opportunités Elles sont réelles et rarement mises en avant, alors qu'elles portent une partie du financement. **Le SBOM est devenu un argument commercial.** Les grands comptes et les acheteurs publics le demandent déjà dans leurs appels d'offres. Le produire répond à une obligation et raccourcit les cycles de vente. **Les questionnaires de sécurité clients** se répondent en heures au lieu de semaines lorsque les preuves existent. Sur un volume significatif d'appels d'offres, l'économie est mesurable. **Les diligences d'acquisition et de levée de fonds** intègrent désormais le CRA. Un dossier propre évite une garantie de passif ou une retenue de prix. **La dette technique devient visible et chiffrable.** L'inventaire révèle les composants abandonnés, les versions figées, les dépendances à mainteneur unique. C'est la première fois que ces informations sont disponibles à l'échelle du portefeuille. **Le temps de réponse à un incident majeur** passe de plusieurs semaines à quelques heures. La valeur de ce gain se mesure au coût du dernier incident de chaîne d'approvisionnement public. ### L'effet d'entraînement La conformité au CRA couvre une large part de ce qui est attendu par ailleurs : | Exigence externe | Couverte par les travaux CRA | | --- | --- | | **NIS 2** — sécurité de la chaîne d'approvisionnement, gestion des incidents | Largement | | **DORA** — pour vos clients du secteur financier | Partiellement | | **Questionnaires clients** de sécurité | Largement | | **ISO/IEC 27001** — maîtrise des actifs et des vulnérabilités | Partiellement | | **Audits de licences** | Largement, via le SBOM | | **Diligences d'acquisition** | Largement | Présenter le projet comme un **socle de preuves mutualisées** plutôt que comme un silo réglementaire change la façon dont il est financé. ### Le message à retenir Le CRA transforme une bonne pratique en condition d'accès au marché. Le coût de la conformité est réel et récurrent ; le coût de la non-conformité est discontinu et potentiellement fatal pour une ligne de produits. L'arbitrage ne porte pas sur « faire ou ne pas faire », mais sur **le rythme et le périmètre**. ## Questions fréquentes URL: https://cra-reference.eu/fr/faq/ Description: Quarante réponses courtes aux questions les plus posées par les équipes Juridique et Cyber, chacune renvoyant à la page de référence. Audience: transverse Published 2026-08-19, updated 2026-08-19 ### Périmètre **Le SaaS est-il concerné ?** Le SaaS autonome relève de NIS 2, pas du CRA. Le back-end indissociable d'un produit connecté entre dans le périmètre en tant que solution de traitement de données à distance. → [Périmètre](/fr/cra/perimetre-pde/) **Un logiciel vendu par abonnement est-il concerné ?** Oui. Le modèle de facturation est indifférent : c'est un produit logiciel. **Une bibliothèque que vous vendez seule est-elle concernée ?** Oui, en tant que composant mis sur le marché séparément. Elle a son propre dossier technique et son propre marquage CE. **Vous fabriquez des dispositifs médicaux : êtes-vous exclus ?** Vos dispositifs médicaux relèvent du MDR et sont exclus du CRA. Vos autres produits, non. → [Exclusions](/fr/cra/exclusions/) **Vous êtes établis hors de l'Union : êtes-vous concernés ?** Oui, dès lors que le produit est mis à disposition sur le marché de l'Union. Un mandataire établi dans l'Union doit être désigné. → [Acteurs](/fr/cra/roles-et-responsabilites/) **Vous revendez un produit tiers sous votre marque : quel est votre statut ?** **Fabricant.** Toutes les obligations vous incombent. **Un outil interne, non commercialisé, est-il concerné ?** Non, faute de mise sur le marché. Il reste pertinent d'y appliquer les mêmes pratiques. ### Calendrier **Un produit vendu en 2025 est-il concerné ?** Pour le marquage CE : non, sauf modification substantielle. Pour le **signalement** : oui, depuis le 11 septembre 2026. → [Calendrier](/fr/cra/calendrier/) **Peut-on espérer un report des échéances ?** Non. Le règlement est entré en vigueur et ne prévoit pas de mécanisme de report. **Qu'est-ce qu'une modification substantielle ?** Une modification qui change la destination du produit ou affecte sa conformité aux exigences essentielles. Une mise à jour de sécurité seule n'en est pas une. **Quelle est la première chose à faire ?** Classer le portefeuille, puis engager les organismes notifiés pour les produits de classe II et Critiques. → [Feuille de route](/fr/organisation/feuille-de-route/) ### Classification **Faut-il un organisme notifié pour un pare-feu ?** Oui : les pare-feu relèvent de l'annexe III, partie II, où l'auto-évaluation est exclue. → [Classe II](/fr/cra/classes-de-criticite/important-classe-2/) **Votre produit remplit plusieurs fonctions listées : quelle classe ?** La **plus élevée** applicable. **« Auto-évaluation » signifie-t-il moins d'obligations ?** Non. Seule la vérification par un tiers disparaît. Le fond est identique. → [Catégorie par défaut](/fr/cra/classes-de-criticite/par-defaut/) **Peut-on s'auto-évaluer en classe I ?** Seulement en appliquant **intégralement** des normes harmonisées couvrant toutes les exigences pertinentes. Tant qu'elles ne sont pas citées au *Journal officiel*, la voie est fermée en pratique. ### SBOM **Peut-on utiliser un tableur comme SBOM ?** Non. Le règlement exige un format couramment utilisé et **lisible par machine**. **Un PDF suffit-il ?** Non, pour la même raison. **Les dépendances transitives sont-elles obligatoires ?** Le minimum légal est le premier niveau. C'est un plancher, pas une cible : les incidents passent majoritairement par le transitif. → [Ce que le CRA exige](/fr/sbom/exigence-cra/) **Devez-vous publier votre SBOM ?** Non. Il doit figurer au dossier technique, tenu à disposition des autorités. Sa communication aux clients est une décision commerciale. → [Diffusion](/fr/sbom/diffusion-et-confidentialite/) **CycloneDX ou SPDX ?** Les deux sont recevables. Votre format pivot est CycloneDX, avec export SPDX à la demande. → [Formats](/fr/sbom/formats/) **Combien de temps devez-vous conserver les SBOM ?** Dix ans après la mise sur le marché, ou la durée de la période de support si elle est plus longue. → [Conservation](/fr/legal/conservation-des-preuves/) **Deux outils donnent deux SBOM différents : lequel est bon ?** Les deux, dans leur périmètre. Il faut figer l'outillage par famille de produits et documenter le choix. → [Générer un SBOM](/fr/cyber/generer-un-sbom/) **Faut-il un SBOM par version ?** Par **construction publiable**. Un SBOM sans référence de version n'a pas de valeur. ### Vulnérabilités et signalement **Que se passe-t-il si vous manquez le délai de 24 heures ?** C'est un manquement à l'article 14, relevant du plafond de sanction le plus élevé — sans préjudice des mesures non pécuniaires. → [Sanctions](/fr/cra/sanctions/) **Un exploit public déclenche-t-il l'obligation de signaler ?** Non, pas à lui seul. Il faut une **preuve fiable d'exploitation** dans un système réel. **Une exploitation chez un seul client suffit-elle ?** Oui. → [Signalement](/fr/cra/signalement-enisa/) **Qui décide de signaler ?** Le juridique, sur qualification du PSIRT, avec délégation écrite et suppléant. → [Obligations de signalement](/fr/legal/obligations-de-signalement/) **Devez-vous corriger toutes les vulnérabilités détectées par vos outils ?** Non. Il faut les **traiter**. Une vulnérabilité analysée et déclarée non exploitable, avec une justification normalisée en VEX, a été traitée. → [VEX](/fr/sbom/vex/) **Peut-on désactiver une alerte de scanner ?** On peut l'écarter par un VEX motivé, ou la mettre en sourdine de façon **datée**. On ne peut pas l'effacer. → [Faux positifs](/fr/cyber/faux-positifs/) **Le signalement CRA remplace-t-il la notification RGPD ?** Non. Trois régimes distincts peuvent s'appliquer au même événement. → [Articulation](/fr/cra/articulation-autres-textes/) ### Open source **Une bibliothèque libre que vous publiez gratuitement est-elle concernée ?** Non, si la mise à disposition est hors activité commerciale. → [Développeur individuel](/fr/cra/open-source/developpeur-individuel/) **Accepter des dons rend-il l'activité commerciale ?** Non, à lui seul. **Êtes-vous responsables des composants libres que vous intégrez ?** Oui, intégralement. L'amont n'est pas responsable à votre place. → [Intégrer de l'open source](/fr/cra/open-source/integrer-de-l-oss/) **Qu'est-ce qu'un sponsor de logiciel libre ?** Une personne morale, autre qu'un fabricant, qui soutient de façon systématique et durable le développement de logiciels libres destinés à des activités commerciales et en assure la viabilité. Régime allégé, sans amendes. → [Sponsor](/fr/cra/open-source/sponsor-oss/) **Devez-vous remonter les correctifs à l'amont ?** Oui : signaler la vulnérabilité au mainteneur et, lorsque c'est pertinent, partager le correctif. ### Documentation et preuves **Qui signe la déclaration UE de conformité ?** Une personne habilitée par l'entreprise, qui l'engage. La déclaration est établie sous la **seule responsabilité du fabricant**. → [Déclaration](/fr/legal/declaration-de-conformite/) **Le SBOM doit-il figurer dans le dossier technique ?** Oui, au titre des processus de traitement des vulnérabilités. → [Dossier technique](/fr/cra/dossier-technique/) **Que faire si une autorité demande votre dossier ?** Appliquer la fiche réflexe : accuser réception, qualifier, geler les preuves, répondre dans le délai, tout consigner. → [Surveillance du marché](/fr/cra/surveillance-du-marche/) **Peut-on facturer l'accès aux correctifs de sécurité ?** Non, pendant la période de support, sauf accord contraire pour des produits sur mesure entre professionnels. → [Période de support](/fr/legal/support-contractuel/) **La période de support est-elle négociable commercialement ?** Sa durée doit être **justifiée**, au minimum cinq ans sauf durée de vie attendue inférieure. Ce n'est pas une variable commerciale libre. --- *Une question absente de cette liste ? Voir [Contact](/fr/contact/) — la FAQ est alimentée par les questions réellement posées.* ## Glossaire URL: https://cra-reference.eu/fr/glossaire/ Description: Les termes du CRA et du SBOM, en français et en anglais, avec le renvoi vers la page de référence. Audience: transverse Published 2026-08-19, updated 2026-08-19 Le vocabulaire européen fait autorité en anglais ; le terme anglais est donc indiqué quand il diffère. ### A **ADCO** — *Administrative Cooperation Group*. Groupe de coopération administrative des autorités de surveillance du marché ; organise notamment les contrôles coordonnés. **AGPL** — *Affero General Public License*. Licence à copyleft **réseau** : la mise à disposition d'un service en ligne déclenche l'obligation de fourniture du code source. → [Familles de licences](/fr/licences/familles/) **Annexe I** — Exigences essentielles. **Partie I** : sécurité du produit. **Partie II** : traitement des vulnérabilités. → [Exigences essentielles](/fr/cra/exigences-essentielles/) **Annexe II** — Informations et instructions à l'utilisateur. → [Documentation utilisateur](/fr/legal/documentation-utilisateur/) **Annexe III** — Produits importants : partie I (classe I), partie II (classe II). **Annexe IV** — Produits critiques. **Annexe V** — Contenu de la déclaration UE de conformité. **Annexe VII** — Contenu du dossier technique. **Annexe VIII** — Procédures d'évaluation de la conformité (modules). **[ANSSI](https://cyber.gouv.fr/)** — Agence nationale de la sécurité des systèmes d'information. **Atteignabilité** (*reachability*) — Caractère effectivement appelable, depuis vos points d'entrée, d'une fonction vulnérable. Critère central de priorisation. → [Faux positifs](/fr/cyber/faux-positifs/) **Attestation de provenance** — Déclaration signée décrivant comment un artefact a été produit. → [Signature](/fr/sbom/signature-et-integrite/) **Autorité de surveillance du marché** — Autorité nationale chargée des contrôles, des injonctions et des mesures de retrait. → [Surveillance](/fr/cra/surveillance-du-marche/) ### C **CE (marquage)** — Déclaration du fabricant, sous sa seule responsabilité, que le produit satisfait aux exigences applicables. → [Marquage CE](/fr/cra/marquage-ce/) **CPE** — *Common Platform Enumeration*. Identifiant historique de produit, imprécis, cause majeure de faux positifs. → [Identifiants](/fr/sbom/identifiants/) **CRA** — *Cyber Resilience Act*, règlement (UE) 2024/2847. **CSAF** — *Common Security Advisory Framework* 2.0, norme OASIS de publication d'avis de sécurité lisibles par machine, avec un profil VEX. **CSIRT coordinateur** — Équipe nationale de réponse désignée destinataire des signalements. **CVD** — *Coordinated Vulnerability Disclosure*, divulgation coordonnée des vulnérabilités. → [Politique CVD](/fr/cyber/politique-cvd/) **CVE** — *Common Vulnerabilities and Exposures*. Identifiant public de vulnérabilité. **CVSS** — *Common Vulnerability Scoring System*. Score de gravité intrinsèque. **[CycloneDX](https://cyclonedx.org/)** — Format de SBOM de l'OWASP, normalisé ECMA-424. → [CycloneDX](/fr/sbom/formats/cyclonedx/) ### D **Déclaration UE de conformité** — Document par lequel le fabricant atteste la conformité. → [Déclaration](/fr/legal/declaration-de-conformite/) **Dépendance transitive** — Dépendance entraînée par une de vos dépendances, sans que vous l'ayez déclarée. → [Qualité](/fr/sbom/qualite-et-completude/) **Distributeur** — Opérateur qui met un produit à disposition sans le fabriquer ni l'importer. → [Acteurs](/fr/cra/roles-et-responsabilites/) **Dossier technique** — Ensemble des pièces prévues à l'annexe VII. → [Dossier technique](/fr/cra/dossier-technique/) ### E **ENISA** — Agence de l'Union européenne pour la cybersécurité. Opère la plateforme de signalement unique et contribue à l'EUVD. **EPSS** — *Exploit Prediction Scoring System*. Probabilité d'exploitation à court terme. **EUCC** — Schéma européen de certification de cybersécurité adopté sous le règlement (UE) 2019/881. **[EUVD](https://euvd.enisa.europa.eu/)** — *European Vulnerability Database*. Base européenne de vulnérabilités, créée sous NIS 2, opérée par l'ENISA. → [Surveillance continue](/fr/cyber/surveillance-continue/) **Exploitation active** — Existence d'une preuve fiable qu'un acteur malveillant a exploité la vulnérabilité dans un système sans autorisation. Déclencheur du délai de 24 heures. ### F **Fabricant** — Personne qui développe ou fait développer un produit et le commercialise sous son nom ou sa marque. Porte l'essentiel des obligations. **Fichier de verrouillage** (*lock file*) — Enregistrement de la résolution exacte des dépendances, transitives comprises, avec leurs empreintes. Condition de la reproductibilité. → [Verrouiller les dépendances](/fr/cyber/verrouillage-dependances/) **FPGA** — Réseau de portes programmables. Relève de la classe I s'il porte des fonctionnalités liées à la sécurité. ### I **Importateur** — Opérateur établi dans l'Union qui met sur le marché un produit provenant d'un pays tiers. **Incident grave** — Événement affectant la capacité du produit à protéger la disponibilité, l'authenticité, l'intégrité ou la confidentialité. Déclencheur de signalement. **[in-toto](https://in-toto.io/)** — Cadre d'attestations sur la chaîne de construction. ### M **Mandataire** — Personne établie dans l'Union mandatée par écrit par un fabricant. **Mise sur le marché** — Première mise à disposition d'un produit sur le marché de l'Union. Instant où s'apprécie la conformité. → [Périmètre](/fr/cra/perimetre-pde/) **Modification substantielle** — Modification changeant la destination du produit ou affectant sa conformité. Rouvre l'évaluation. **Module A / B / C / H** — Procédures d'évaluation de la conformité de l'annexe VIII. → [Évaluation](/fr/cra/evaluation-de-conformite/) ### N **NANDO** — Base de données des organismes notifiés de la Commission européenne. **NIS 2** — Directive (UE) 2022/2555, relative aux **entités** et non aux produits. **Normes harmonisées** — Normes européennes dont les références sont citées au *Journal officiel* et qui confèrent une présomption de conformité. **[NVD](https://nvd.nist.gov/)** — *National Vulnerability Database*. Base américaine, corrélation par CPE. ### O **Organisme notifié** — Organisme d'évaluation de la conformité accrédité, désigné et notifié à la Commission. **OSS Steward** — Voir *Sponsor de logiciel libre*. **[OSV](https://osv.dev/)** — *Open Source Vulnerabilities*. Base par écosystème, corrélation par PURL, précision élevée. ### P **PDE** — Produit comportant des éléments numériques (*product with digital elements*). → [Périmètre](/fr/cra/perimetre-pde/) **Période de support** — Durée pendant laquelle le fabricant produit des mises à jour de sécurité. Au moins cinq ans, sauf durée de vie attendue inférieure. → [Période de support](/fr/cra/support-et-cycle-de-vie/) **Présomption de conformité** — Effet de l'application de normes harmonisées, de spécifications communes ou d'un schéma de certification. **PPE** — *Poisoned Pipeline Execution*. Attaque consistant à faire exécuter par la chaîne de construction du code non validé, apporté par une proposition de modification, dans un contexte qui détient des secrets. → [Sécuriser la chaîne de construction](/fr/cyber/chaine-ci-securisee/) **PSIRT** — *Product Security Incident Response Team*. Équipe de réponse aux incidents de sécurité produit. **[PURL](https://github.com/package-url/purl-spec)** — *Package URL*. Identifiant canonique par écosystème, à privilégier. → [Identifiants](/fr/sbom/identifiants/) ### R **RED** — Directive 2014/53/UE sur les équipements radio, et son règlement délégué (UE) 2022/30. **Référence immuable** — Empreinte de commit ou de contenu, par opposition à une étiquette de version, qui peut être repointée. → [Verrouiller les dépendances](/fr/cyber/verrouillage-dependances/) **Rétroportage** (*backport*) — Application d'un correctif à une version antérieure sans changement du numéro de version amont. Cause fréquente de faux positifs. ### S **SBOM** — *Software Bill of Materials*, nomenclature logicielle. → [SBOM](/fr/sbom/) **Scorecard** — *OpenSSF Scorecard*. Outil ouvert qui exécute dix-huit contrôles automatisés sur un dépôt et en tire une note sur 10, ce qui rend la diligence calculable. → [Évaluer un composant](/fr/cyber/evaluer-un-composant/) **S2C2F** — *Secure Supply Chain Consumption Framework*. Cadre de l'OpenSSF décrivant comment consommer de l'open source de façon maîtrisée, avec un modèle de maturité. → [Évaluer un composant](/fr/cyber/evaluer-un-composant/) **`security.txt`** — Fichier normalisé RFC 9116 indiquant le point de contact pour le signalement de vulnérabilités. **[Sigstore](https://www.sigstore.dev/)** — Infrastructure de signature avec journal de transparence. **[SLSA](https://slsa.dev/)** — Cadre de niveaux de maturité de la chaîne de construction. **Solution de traitement de données à distance** — Traitement conçu par le fabricant dont l'absence empêcherait le produit d'exécuter une de ses fonctions. Porte d'entrée du cloud dans le CRA. **[SPDX](https://spdx.dev/)** — *Software Package Data Exchange*. Format de SBOM de la Linux Foundation, normalisé ISO/IEC 5962. Sa **liste de licences** fait autorité. → [SPDX](/fr/sbom/formats/spdx/) **Sponsor de logiciel libre** (*open-source software steward*) — Personne morale, autre qu'un fabricant, soutenant durablement des logiciels libres destinés à des activités commerciales. Régime allégé. → [Sponsor](/fr/cra/open-source/sponsor-oss/) **SRP** — *Single Reporting Platform*. Plateforme de signalement unique opérée par l'ENISA. → [Signalement](/fr/cra/signalement-enisa/) ### V **VEX** — *Vulnerability Exploitability eXchange*. Assertion structurée sur le statut d'exploitabilité d'une vulnérabilité dans un produit donné. → [VEX](/fr/sbom/vex/) **Vulnérabilité activement exploitée** — Voir *Exploitation active*. ## Parcours Juridique URL: https://cra-reference.eu/fr/legal/ Description: Les obligations du CRA vues par l'équipe Juridique et Conformité : marquage CE, dossier technique, déclaration UE, signalement, sanctions, contrats, licences, support et conservation des preuves. Audience: legal Legal basis: Art. 13, 14, 30, 31 · Annexes II, V, VII Published 2026-08-19, updated 2026-08-19 Cette section ne redéfinit pas le règlement — elle le traduit en **obligations, preuves et points de contrôle** relevant du Juridique. Chaque page renvoie à la définition canonique dans [Le cadre CRA](/fr/cra/). ### Tableau maître des obligations | Obligation | Base légale | Échéance | Preuve attendue | Page | | --- | --- | --- | --- | --- | | Qualifier le produit comme PDE | Art. 2, 3 | 11/12/2027 | Fiche de qualification signée | [Périmètre](/fr/cra/perimetre-pde/) | | Déterminer la classe de criticité | Annexes III, IV | 11/12/2027 | Fiche de classification | [Classes](/fr/cra/classes-de-criticite/) | | Choisir la voie d'évaluation | Art. 32, annexe VIII | 11/06/2026 | Contrat d'organisme notifié | [Évaluation](/fr/cra/evaluation-de-conformite/) | | Constituer le dossier technique | Annexe VII | 11/12/2027 | Dossier complet, SBOM inclus | [Dossier technique](/fr/legal/marquage-ce-et-dossier/) | | Établir la déclaration UE de conformité | Annexe V | 11/12/2027 | Déclaration signée | [Déclaration](/fr/legal/declaration-de-conformite/) | | Apposer le marquage CE | Art. 30 | 11/12/2027 | Procès-verbal de revue | [Marquage CE](/fr/cra/marquage-ce/) | | Signaler sous 24 h / 72 h / 14 j | Art. 14 | **11/09/2026** | Registre + accusés de la plateforme | [Signalement](/fr/legal/obligations-de-signalement/) | | Déterminer et publier la période de support | Art. 13, annexe II | 11/12/2027 | Registre + mention à l'acheteur | [Support](/fr/legal/support-contractuel/) | | Fournir les informations à l'utilisateur | Annexe II | 11/12/2027 | Notice livrée avec le produit | [Documentation](/fr/legal/documentation-utilisateur/) | | Conserver dossier et déclaration | Art. 13, 31 | 11/12/2027 | Coffre de preuves + journal d'audit | [Conservation](/fr/legal/conservation-des-preuves/) | ### Ce que le Juridique doit obtenir de la Cyber - le **SBOM** validé et signé, par produit et par version, dans le format retenu ; - l'**analyse de risques de cybersécurité** documentée ; - le **journal de traitement des vulnérabilités** et les **VEX** motivant les vulnérabilités non corrigées ; - la **politique de divulgation coordonnée** opérationnelle et son point de contact actif ; - les **rapports de tests** de sécurité ; - la description du **mécanisme de diffusion des mises à jour** ; - les éléments techniques justifiant la **durée de la période de support** retenue ; - en cas d'événement, la **qualification « vulnérabilité activement exploitée »**, dans les deux heures. ### Ce que le Juridique doit fournir à la Cyber - la **classification réglementaire** de chaque produit et la voie d'évaluation retenue ; - la **politique de licences** et la liste des licences interdites ; - les **clauses fournisseurs** négociées et les engagements obtenus ; - l'arbitrage sur la **diffusion du SBOM** aux clients ; - la **décision de signaler** et le texte validé du signalement ; - la **période de support** engagée contractuellement. Le détail de ces échanges, avec délais et formats, est formalisé dans [Interface Juridique ↔ Cyber](/fr/organisation/interface-legal-cyber/). ### Le point de contrôle qui compte Une seule chose doit être non négociable côté Juridique : **un droit de veto formel sur la mise sur le marché** tant que les quinze points de la [liste de contrôle](/fr/legal/checklist-mise-sur-le-marche/) ne sont pas cochés. Sans ce point de blocage, le dossier technique se constitue après coup, ce qui est exactement ce que la surveillance du marché cherche à détecter. ## Liste de contrôle avant mise sur le marché URL: https://cra-reference.eu/fr/legal/checklist-mise-sur-le-marche/ Description: Quinze points, une page, imprimable et signable. Le document qui matérialise le droit de veto du Juridique sur la commercialisation. Audience: legal Legal basis: Art. 13, 28, 30, 31 · Annexes I, II, V, VII Published 2026-08-19, updated 2026-08-19 À imprimer, remplir en séance de revue de conformité, signer et archiver avec le dossier technique. Aucun point ne peut rester ouvert au moment de l'apposition du marquage. **Produit :** ______________________ **Version exacte :** ______________________ **Date de la revue :** ____________ **Mise sur le marché prévue le :** ____________ --- ### Périmètre et classification - [ ] **1.** Le produit est qualifié **PDE** ; la fiche de qualification est signée et versée au dossier. → [Périmètre](/fr/cra/perimetre-pde/) - [ ] **2.** Les **exclusions** ont été examinées et écartées, ou une fiche d'exclusion motivée existe. → [Exclusions](/fr/cra/exclusions/) - [ ] **3.** La **classe de criticité** est déterminée et justifiée par une fiche de classification co-signée. → [Classes](/fr/cra/classes-de-criticite/) ### Voie de conformité - [ ] **4.** La **voie d'évaluation** est choisie et documentée ; si un organisme notifié est requis, il est engagé et son **certificat** figure au dossier. → [Évaluation](/fr/cra/evaluation-de-conformite/) ### Exigences essentielles - [ ] **5.** L'**analyse de risques de cybersécurité** est réalisée, datée, signée, et justifie les exigences écartées. - [ ] **6.** Les exigences de l'**annexe I, partie I** applicables sont couvertes ; la matrice de traçabilité est complète. → [Sécurité du produit](/fr/cra/exigences-essentielles/securite-des-produits/) - [ ] **7.** Le processus de **traitement des vulnérabilités** de l'annexe I, partie II, est opérationnel et documenté. → [Traitement des vulnérabilités](/fr/cra/exigences-essentielles/traitement-des-vulnerabilites/) ### Nomenclature et divulgation - [ ] **8.** Le **SBOM** de cette version exacte est généré, validé au-dessus du seuil de qualité, signé et archivé. → [SBOM](/fr/sbom/) - [ ] **9.** La **politique de divulgation coordonnée** est publiée et le **point de contact** est actif et testé. → [Politique CVD](/fr/cyber/politique-cvd/) ### Cycle de vie et information - [ ] **10.** La **période de support** est déterminée, justifiée au dossier, approuvée par la direction générale et **communiquée à l'acheteur** au mois près. → [Support](/fr/legal/support-contractuel/) - [ ] **11.** Les **informations et instructions à l'utilisateur** de l'annexe II sont rédigées, traduites et livrées avec le produit. → [Documentation utilisateur](/fr/legal/documentation-utilisateur/) ### Dossier et déclaration - [ ] **12.** Le **dossier technique** de l'annexe VII est complet ; sa version est gelée et référencée. → [Dossier technique](/fr/cra/dossier-technique/) - [ ] **13.** La **déclaration UE de conformité** de l'annexe V est établie, exacte et signée par une personne habilitée. → [Déclaration](/fr/legal/declaration-de-conformite/) ### Opérationnel - [ ] **14.** La procédure de **signalement 24 h / 72 h / 14 j** est en place, l'astreinte est désignée et le canal a été testé pour ce produit. → [Signalement](/fr/legal/obligations-de-signalement/) - [ ] **15.** L'**archivage dix ans** est configuré pour toutes les pièces, et la restitution a été testée. → [Conservation](/fr/legal/conservation-des-preuves/) --- ### Décision - [ ] **Autorisation d'apposer le marquage CE et de mettre le produit sur le marché.** - [ ] **Refus** — motifs et échéances de reprise : _______________________________________________________________________ **Réserves acceptées** (points ouverts, avec responsable et date de résolution) : _______________________________________________________________________ | Rôle | Nom | Signature | Date | | --- | --- | --- | --- | | Direction juridique | | | | | RSSI | | | | | Direction produit | | | | --- > **Rappel.** Cette liste n'est pas une formalité administrative : c'est la trace qui > démontrera, en cas de contrôle, que la conformité a été vérifiée **avant** la mise sur le > marché. Une liste signée avec des cases cochées à tort est plus dommageable qu'une liste > honnête portant des réserves. ## Clauses contractuelles fournisseurs et clients URL: https://cra-reference.eu/fr/legal/clauses-contractuelles/ Description: Les clauses à exiger en amont pour tenir vos propres délais, celles à négocier en aval, et le cas particulier des composants libres pour lesquels il n'existe aucun contrat. Audience: legal Legal basis: Art. 13, paragraphe 5 — diligence sur les composants tiers · Art. 14 — délais de signalement Published 2026-08-19, updated 2026-08-19 Vos obligations réglementaires ne s'arrêtent pas à votre périmètre technique : elles dépendent de la réactivité de vos fournisseurs. Le contrat est le seul instrument qui permette de la garantir. ### Le principe de la cascade des délais Vous devez émettre une alerte précoce **sous 24 heures**. Si votre fournisseur vous prévient sous 72 heures, vous êtes en infraction sans avoir rien fait de mal. Les délais contractuels amont doivent donc être **strictement inférieurs** aux nôtres. | Votre obligation | Délai fournisseur à exiger | | --- | --- | | Alerte précoce sous 24 h | **Notification sous 8 h** de toute vulnérabilité activement exploitée | | Notification sous 72 h | Informations circonstanciées sous 36 h | | Rapport final sous 14 j après correctif | Correctif ou contournement documenté sous 7 j | ### Clauses à insérer dans vos contrats d'achat #### Nomenclature logicielle - Fourniture d'un **SBOM** au format CycloneDX ou SPDX, dans une version minimale précisée. - **À chaque livraison de version**, sans demande de votre part. - Engagement sur la **profondeur** — dépendances transitives comprises — et déclaration honnête de complétude. - Fourniture des **licences** en identifiants SPDX. #### Sécurité et vulnérabilités - **Délais de notification** selon la cascade ci-dessus. - **Délais de correction** par niveau de criticité, avec pénalités. - Fourniture des **VEX** ou d'une position motivée sur les vulnérabilités non corrigées. - **Accès aux avis de sécurité**, dans un format lisible par machine si possible. #### Cycle de vie - **Période de support** au moins alignée sur celle que vous engagez envers vos clients. - **Préavis de fin de support**, d'une durée permettant une migration — douze mois au minimum pour un composant central. - **Notification du changement de mainteneur** ou de licence. #### Conformité - **Engagement de conformité au CRA** pour les composants qui sont eux-mêmes des produits au sens du règlement, et fourniture de la déclaration UE de conformité. - **Droit d'audit** et accès aux résultats des tests de sécurité. - **Garantie de titularité** des droits et des licences, et fourniture des informations permettant de respecter les obligations d'attribution. #### Continuité - **Réversibilité** et, pour les composants critiques, **dépôt du code source auprès d'un tiers séquestre**, avec conditions de libération incluant la cessation d'activité et l'arrêt du support. #### Responsabilité - **Indemnisation** en cas de non-conformité imputable au fournisseur, y compris des sanctions administratives que vous encourriez de ce fait. - Articulation avec les plafonds de responsabilité : un plafond exprimé en pourcentage du contrat annuel est sans commune mesure avec une amende assise sur votre chiffre d'affaires mondial. Ce déséquilibre doit être identifié et arbitré, pas ignoré. ### Clauses à négocier dans vos contrats de vente - **Périmètre du support** : ce qui est couvert, ce qui ne l'est pas, et la date de fin de la période de support, exprimée au moins par le mois et l'année. - **Modalités de fourniture du SBOM** : format, fréquence, canal, confidentialité — voir [Diffusion et confidentialité](/fr/sbom/diffusion-et-confidentialite/). - **Canal d'information** en cas de vulnérabilité, et engagement du client à maintenir des coordonnées valides — vous ne pouvez pas informer un client injoignable. - **Obligation de mise à jour** du côté client : vos correctifs ne protègent que s'ils sont appliqués. - **Limitation de responsabilité** cohérente avec votre exposition réglementaire. - **Traitement des versions non maintenues** après la fin de la période de support. ### Le cas des composants libres Il n'y a pas de contrat, donc pas de clause. Aucune négociation n'est possible avec un projet communautaire, et lui demander un engagement de support est dépourvu de sens. Le risque se traite donc par d'autres moyens : 1. la **diligence à la sélection** — voir [Intégrer de l'open source](/fr/cra/open-source/integrer-de-l-oss/) ; 2. la **surveillance continue** de l'activité du projet et du changement de mainteneur ; 3. la **capacité interne** à reprendre la maintenance, forker ou remplacer ; 4. le cas échéant, le **financement** du projet amont, qui améliore sa viabilité sans créer d'obligation juridique à votre égard. > **À dire clairement en interne.** Un composant libre critique, maintenu par une seule > personne, dans un produit couvert par une période de support de cinq ans, est un risque > non transférable. Il ne peut être ni assuré, ni contractualisé — seulement provisionné ou > supprimé. ### Le clausier Un **clausier type** en français et en anglais, tenu par la direction juridique, avec pour chaque clause : le texte, la justification réglementaire, le niveau de négociabilité, et la position de repli acceptable. C'est ce document qui permet aux achats de négocier sans solliciter le juridique à chaque contrat. ## Conservation des preuves URL: https://cra-reference.eu/fr/legal/conservation-des-preuves/ Description: Quels artefacts conserver, combien de temps, sous quelles garanties d'intégrité, et l'exercice annuel de restitution qui seul prouve que le dispositif fonctionne. Audience: legal Legal basis: Art. 13 et 31 — conservation du dossier technique et de la déclaration Published 2026-08-19, updated 2026-08-19 ### La règle Le **dossier technique** et la **déclaration UE de conformité** sont tenus à la disposition des autorités de surveillance du marché pendant **au moins dix ans après la mise sur le marché du produit, ou pendant la période de support si celle-ci est plus longue**. Par cohérence, tout ce qui fonde le dossier suit la même durée. ### Ce qu'il faut conserver | Artefact | Pourquoi | Durée | | --- | --- | --- | | **Dossier technique**, dans sa version gelée à la mise sur le marché | Pièce maîtresse du contrôle | 10 ans / période de support | | **Déclaration UE de conformité** signée | Idem | Idem | | **SBOM** de chaque version livrée, signé | Pièce du dossier, base de la réponse à un incident | Idem | | **VEX** et journal de traitement des vulnérabilités | Preuve que les vulnérabilités ont été traitées | Idem | | **Rapports de tests** de sécurité | Preuve de l'exigence de tests réguliers | Idem | | **Analyse de risques** et ses révisions | Justifie les exigences écartées | Idem | | **Registre des signalements** et accusés de la plateforme | Preuve du respect des délais de l'article 14 | Idem | | **Correspondance avec les autorités** et les organismes notifiés | Traçabilité des échanges | Idem | | **Certificats** d'organisme notifié | Fondement de la voie d'évaluation | Idem | | **Avis de sécurité** publiés | Preuve de l'annexe I, partie II, point 4 | Idem | | **Informations à l'utilisateur** livrées | Preuve de l'annexe II | Idem | | **Clés publiques** de vérification des signatures | Sans elles, les signatures ne se vérifient plus | Illimitée en pratique | ### Les garanties à assurer | Garantie | Ce qu'elle implique | | --- | --- | | **Intégrité** | Stockage en écriture unique, ou empreintes horodatées vérifiables | | **Horodatage** | Preuve de la date d'existence — le journal de transparence d'une infrastructure de signature y répond bien | | **Traçabilité des accès** | Journal d'audit : qui a consulté, qui a versé, qui a extrait | | **Ségrégation des droits** | Nul ne peut à la fois produire, approuver et modifier | | **Lisibilité dans le temps** | Formats normalisés, pas de dépendance à un outil propriétaire | | **Portabilité** | Capacité à migrer l'ensemble vers un autre support sans perte | | **Indexation** | Retrouver le dossier d'une version précise, dix ans plus tard, en heures | ### Le point le plus souvent manqué Ce n'est ni le stockage, ni la durée : c'est la **capacité de restitution**. Conserver des fichiers est facile. Retrouver, en 2038, le dossier technique exact de la version 4.2.1 mise sur le marché en 2028, avec son SBOM, ses VEX, sa déclaration signée et la clé permettant de vérifier cette signature, suppose une chaîne d'indexation qui aura survécu à deux changements de plateforme et à trois générations d'équipes. ### L'exercice annuel de restitution C'est le seul contrôle qui prouve quelque chose. **Protocole :** 1. Tirer au sort une version livrée il y a plus de deux ans. 2. Sans préparation, demander à l'équipe de produire, **en moins d'une journée ouvrée** : le dossier technique gelé, la déclaration signée, le SBOM signé et sa signature vérifiée, les VEX associés, le registre des signalements pour ce produit, et la notice utilisateur livrée. 3. Chronométrer, consigner les difficultés, corriger. 4. Rédiger un compte rendu, versé au dossier de gouvernance. Un exercice échoué n'est pas un incident : c'est l'information la plus utile de l'année. Un exercice jamais réalisé signifie que vous ne savez pas si le dispositif fonctionne. ### Articulation avec le RGPD Une durée de conservation de dix ans doit rester **justifiée** au regard du principe de limitation de la conservation. Deux précautions : - ne conserver dans le coffre de preuves que ce qui est **nécessaire à la conformité CRA** — un dossier technique n'a pas vocation à contenir de données personnelles ; - documenter la **base** de cette durée dans le registre des traitements, en citant l'obligation légale. ### Suppression À l'échéance, la suppression doit être **effective et tracée** : une entrée au journal d'audit indiquant ce qui a été supprimé, quand, et sur quel fondement. Conserver au-delà de la durée nécessaire, sans décision, est un défaut symétrique de la conservation insuffisante. ## La déclaration UE de conformité URL: https://cra-reference.eu/fr/legal/declaration-de-conformite/ Description: Contenu obligatoire de l'annexe V, forme simplifiée de l'annexe VI, exigences linguistiques, modèle prêt à l'emploi et règles de mise à jour. Audience: legal Legal basis: Art. 28 — déclaration UE de conformité · Annexe V — contenu · Annexe VI — déclaration simplifiée Published 2026-08-19, updated 2026-08-19 ### Ce qu'est la déclaration Le document par lequel le fabricant **atteste, sous sa seule responsabilité**, que le produit satisfait aux exigences essentielles applicables. Elle est établie **avant** la mise sur le marché et accompagne le produit. C'est un document court — une à deux pages — mais engageant : c'est lui qui fait du marquage CE une affirmation opposable. ### Le contenu obligatoire (annexe V) 1. **Nom et type du produit**, avec les éléments permettant sa traçabilité : référence, numéro de version, et le cas échéant une photographie. 2. **Nom et adresse** du fabricant ou de son mandataire. 3. La mention que la déclaration est établie **sous la seule responsabilité du fabricant**. 4. L'**objet de la déclaration** : identification du produit permettant sa traçabilité, avec si nécessaire une image en couleur d'une netteté suffisante. 5. La déclaration que l'objet est **conforme au règlement (UE) 2024/2847** et, le cas échéant, aux autres actes d'harmonisation de l'Union applicables. 6. Les **références des normes harmonisées** appliquées, des spécifications communes ou des schémas de certification européens, avec leur date de version. 7. Le cas échéant, le **nom et le numéro** de l'organisme notifié, la description de la procédure d'évaluation suivie et la référence du certificat délivré. 8. **Informations complémentaires** éventuelles. 9. **Lieu et date** de délivrance, **nom, fonction et signature** du signataire. ### La déclaration simplifiée (annexe VI) Une forme abrégée est admise, comportant au minimum l'identification du produit, la mention de conformité au règlement, et l'**adresse internet exacte** où la déclaration complète est accessible. Elle est utile sur les emballages et les notices, mais ne remplace pas la déclaration complète, qui doit rester disponible. ### Les exigences linguistiques La déclaration est **traduite dans la ou les langues exigées par l'État membre** sur le marché duquel le produit est mis à disposition. En pratique, pour une distribution dans l'ensemble de l'Union, cela signifie prévoir une chaîne de traduction et un contrôle de cohérence entre versions. La version faisant foi est celle établie par le fabricant ; les traductions doivent y être fidèles. ### Modèle ``` DÉCLARATION UE DE CONFORMITÉ 1. Produit : Acme Gateway, référence AG-4200, version logicielle 4.2.1 2. Fabricant : [Raison sociale] [Adresse postale complète] [Adresse électronique] — [Site web] 3. La présente déclaration de conformité est établie sous la seule responsabilité du fabricant. 4. Objet de la déclaration : produit comportant des éléments numériques « Acme Gateway », version 4.2.1, identifié par [empreinte / numéro de série]. 5. L'objet de la déclaration décrit ci-dessus est conforme à la législation d'harmonisation de l'Union applicable : — Règlement (UE) 2024/2847 (règlement sur la cyberrésilience) — [le cas échéant, autres actes applicables] 6. Références des normes harmonisées appliquées, ou des autres spécifications par rapport auxquelles la conformité est déclarée : — [référence et date de la norme] — [description des solutions retenues pour les exigences non couvertes] 7. Organisme notifié : [nom], numéro [NNNN], a réalisé [procédure] et délivré le certificat [référence]. [Ou : sans objet — évaluation réalisée selon le module A, contrôle interne.] 8. Informations complémentaires : période de support jusqu'au [mois/année]. Signé pour et au nom de : [Raison sociale] Lieu et date : [ville], le [date] Nom et fonction : [nom], [fonction] Signature : ____________________ ``` ### Les règles de mise à jour | Événement | Faut-il une nouvelle déclaration ? | | --- | --- | | Nouvelle version corrective de sécurité, sans autre changement | Non, si la déclaration couvre explicitement la ligne de version | | Nouvelle version fonctionnelle | **Oui**, si la version déclarée change | | Modification substantielle | **Oui**, après nouvelle évaluation | | Changement de raison sociale ou d'adresse | **Oui** | | Nouvelle norme harmonisée citée au JOUE remplaçant celle appliquée | À examiner ; la déclaration doit refléter les références réellement appliquées | La question du **périmètre de version** doit être tranchée dès la première déclaration : déclarer une version précise est plus rigoureux, déclarer une ligne de version est plus maniable. Le choix doit être cohérent avec la stratégie de versionnement, et documenté. ### Conservation Dix ans après la mise sur le marché, ou la durée de la période de support si elle est plus longue — comme le dossier technique. Voir [Conservation des preuves](/fr/legal/conservation-des-preuves/). ## Informations et instructions à l'utilisateur (annexe II) URL: https://cra-reference.eu/fr/legal/documentation-utilisateur/ Description: Les dix mentions obligatoires à fournir avec le produit, le modèle de notice de cybersécurité, les exigences linguistiques et la durée de conservation. Audience: legal Legal basis: Annexe II — informations et instructions à l'utilisateur · Art. 13 — obligations du fabricant Published 2026-08-19, updated 2026-08-19 L'annexe II est courte, souvent oubliée, et sa violation constitue une **non-conformité formelle** immédiatement constatable par une autorité qui achète le produit dans le commerce. C'est le contrôle le moins coûteux à réaliser, donc le plus probable. ### Les mentions obligatoires Fournies avec le produit, dans une **langue aisément compréhensible** par les utilisateurs et les autorités de surveillance du marché. 1. **Nom, raison sociale ou marque déposée du fabricant**, adresse postale, adresse électronique ou autre coordonnée numérique, et le cas échéant site web. 2. **Point de contact unique** permettant de signaler des vulnérabilités et d'en recevoir des informations en retour, avec indication de l'endroit où il est situé. 3. **Nom et type du produit**, avec les éléments de traçabilité : référence, version. 4. **Utilisation prévue**, y compris l'**environnement de sécurité prévu**, et **fonctionnalités de sécurité principales**. 5. Toute **circonstance connue ou prévisible** liée à l'utilisation du produit conformément à sa destination, ou dans des conditions de mauvais usage raisonnablement prévisible, pouvant entraîner un risque de cybersécurité. 6. Le cas échéant, l'**adresse internet où la déclaration UE de conformité** est accessible. 7. **Type de support technique en matière de sécurité** offert et **date de fin de la période de support**, au moins le mois et l'année, de manière claire et compréhensible. 8. **Instructions détaillées** — ou l'adresse internet y renvoyant — couvrant : les mesures de sécurité à la mise en service et à l'exploitation, l'incidence des changements de configuration, les modalités d'installation sécurisée des mises à jour, la désinstallation sécurisée, la conservation des données et la réinitialisation. 9. Lorsque le produit prend en charge des **mises à jour automatiques**, information sur le mécanisme et sur la **possibilité de le désactiver**. 10. Le cas échéant, indication de l'endroit où la **nomenclature logicielle (SBOM)** peut être obtenue. ### Modèle de notice de cybersécurité À décliner par produit, en deux pages. ``` NOTICE DE CYBERSÉCURITÉ — Acme Gateway AG-4200, version 4.2.x 1. FABRICANT [Raison sociale], [adresse postale complète] [courriel] — [site web] 2. SIGNALER UNE VULNÉRABILITÉ Point de contact : psirt@[domaine] — [pays où le point de contact est situé] Politique de divulgation : [URL] Clé publique de chiffrement : [URL] 3. IDENTIFICATION DU PRODUIT Nom, référence, versions couvertes par la présente notice. 4. UTILISATION PRÉVUE ET ENVIRONNEMENT DE SÉCURITÉ Le produit est conçu pour [usage]. Il suppose un environnement dans lequel [hypothèses : réseau segmenté, accès physique contrôlé, etc.]. Fonctionnalités de sécurité principales : [liste]. 5. RISQUES CONNUS ET USAGES DÉCONSEILLÉS [Circonstances pouvant entraîner un risque, y compris mauvais usage raisonnablement prévisible.] 6. DÉCLARATION UE DE CONFORMITÉ Disponible à l'adresse : [URL] 7. SUPPORT DE SÉCURITÉ Mises à jour de sécurité fournies jusqu'au : [mois année] Correctifs publiés restant disponibles jusqu'au : [mois année] Nature du support : [description] 8. INSTRUCTIONS Mise en service sécurisée : [URL ou texte] Effets des changements de configuration : [URL ou texte] Installation des mises à jour : [URL ou texte] Désinstallation sécurisée et effacement des données : [URL ou texte] Réinitialisation à l'état d'origine : [URL ou texte] 9. MISES À JOUR AUTOMATIQUES Activées par défaut : oui / non. Mécanisme : [description]. Désactivation : [procédure]. Conséquences de la désactivation : [texte]. 10. NOMENCLATURE LOGICIELLE (SBOM) Disponible : [URL du portail / sur demande à l'adresse …] / non communiquée. ``` ### Points d'attention **La localisation du point de contact.** L'annexe demande d'indiquer **où** le point de contact est situé. Une simple adresse électronique ne suffit pas : il faut préciser le pays. **« Langue aisément compréhensible ».** Pour une distribution paneuropéenne, cela implique une chaîne de traduction, et un contrôle de cohérence entre versions linguistiques. Les États membres peuvent exiger leur propre langue. **Le format.** La notice peut renvoyer à une adresse internet pour les instructions détaillées, mais **les mentions principales doivent accompagner le produit**. Un renvoi intégral vers un site n'est pas conforme, et un lien qui cesse de fonctionner après la fin de commercialisation l'est encore moins. **La cohérence.** Trois informations circulent dans plusieurs documents à la fois : la date de fin de support, le point de contact, l'adresse de la déclaration. Elles doivent être générées depuis une **source unique**, sinon elles divergeront. ### Conservation Les informations et instructions doivent rester disponibles pendant **au moins dix ans après la mise sur le marché, ou la durée de la période de support si elle est plus longue** — au même titre que le dossier technique. Cela signifie qu'une URL citée dans une notice de 2028 doit encore répondre en 2038. La politique d'URL pérennes est donc un sujet de conformité, pas seulement de communication. ## Marquage CE et dossier technique : le processus interne URL: https://cra-reference.eu/fr/legal/marquage-ce-et-dossier/ Description: Qui constitue, qui relit, qui signe. Le workflow d'approbation, la porte de mise sur le marché et le procès-verbal de revue de conformité. Audience: legal Legal basis: Art. 30 — marquage CE · Art. 31 et annexe VII — dossier technique Published 2026-08-19, updated 2026-08-19 Le contenu du dossier est décrit dans [Le dossier technique](/fr/cra/dossier-technique/) ; les règles d'apposition dans [Le marquage CE](/fr/cra/marquage-ce/). Cette page traite du **processus interne** : qui fait quoi, dans quel outil, avec quelle validation. ### Le principe : une porte, pas une formalité Le dossier technique n'est pas un document rédigé à la fin par le juridique à partir de ce que l'ingénierie veut bien lui envoyer. C'est un **assemblage de pièces produites en continu**, dont l'absence bloque la mise sur le marché. D'où un point de contrôle unique, la **porte de mise sur le marché**, franchi sur présentation de pièces, pas sur déclaration d'intention. ### Répartition des rôles | Pièce du dossier | Producteur | Relecteur | Approbateur | | --- | --- | --- | --- | | Description générale, versions | Direction produit | Juridique | Juridique | | Schémas d'architecture | Ingénierie | RSSI | RSSI | | **SBOM** | Chaîne CI | RSSI | RSSI | | Politique CVD et preuve de publication | PSIRT | Juridique | Juridique | | Preuve de fonctionnement du point de contact | PSIRT | Juridique | Juridique | | Processus de distribution des mises à jour | Ingénierie | RSSI | RSSI | | Analyse de risques | RSSI | Juridique | RSSI | | Période de support et justification | Direction produit | Juridique | **Direction générale** | | Normes appliquées et écarts | RSSI | Juridique | RSSI | | Rapports de tests | Qualité et RSSI | RSSI | RSSI | | Déclaration UE de conformité | Juridique | Direction générale | **Signataire habilité** | | Attestations d'organisme notifié | Juridique | — | Juridique | La période de support remonte à la direction générale parce qu'elle engage financièrement l'entreprise sur cinq à dix ans : ce n'est pas une décision technique. ### Le workflow 1. **Ouverture du dossier** à la décision de développer, pas à la veille du lancement. Le dossier est un espace vivant, alimenté au fil du projet. 2. **Jalons de complétude** aux étapes clés du projet : conception, fin de développement, pré-lancement. À chaque jalon, un état des pièces manquantes. 3. **Revue de conformité** avant mise sur le marché, en séance, avec les responsables de chaque pièce. 4. **Procès-verbal signé**, qui vaut autorisation d'apposer le marquage. 5. **Gel et archivage** de la version du dossier correspondant à la version mise sur le marché. 6. **Réouverture** en cas de modification substantielle. ### Le procès-verbal de revue de conformité Une page, structurée ainsi : - identification du produit et de la **version exacte** mise sur le marché ; - classe de criticité et voie d'évaluation retenue, avec renvoi à la fiche de classification ; - **état des quinze points** de la [liste de contrôle](/fr/legal/checklist-mise-sur-le-marche/), coché par pièce ; - réserves éventuelles, avec échéance et responsable ; - **décision** : autorisation d'apposer le marquage, ou refus motivé ; - date, participants, signatures. Ce document est la trace de la diligence de l'entreprise. En cas de contrôle, il démontre que la conformité a été vérifiée **avant** la mise sur le marché, et non reconstruite après. ### L'outil Le dossier technique doit vivre dans un système qui garantit : - la **traçabilité** des versions et des approbations ; - l'**immuabilité** des états gelés ; - la **restitution** d'un état passé, dix ans plus tard ; - la **liaison** avec les artefacts techniques — SBOM, rapports de tests — plutôt que leur recopie. Un dossier partagé sans versionnement ne satisfait aucun de ces quatre critères. ## Obligations de signalement : la décision juridique URL: https://cra-reference.eu/fr/legal/obligations-de-signalement/ Description: Quand court le délai de 24 heures, qui décide, comment documenter la décision de signaler ou de ne pas signaler, et comment organiser l'astreinte juridique. Audience: legal Legal basis: Art. 14 — obligations de signalement · Art. 15 — signalement volontaire Published 2026-08-19, updated 2026-08-19 Le déroulé opérationnel est décrit dans [Procédure 24 h / 72 h / 14 j](/fr/cyber/procedure-24h/) et le cadre légal dans [Le signalement à l'ENISA](/fr/cra/signalement-enisa/). Cette page traite des trois questions juridiques : **quand**, **qui**, et **comment le prouver**. ### Quand le délai commence-t-il à courir ? Le délai de 24 heures court à compter du moment où le fabricant **a connaissance** de la vulnérabilité activement exploitée ou de l'incident grave. « Avoir connaissance » n'est ni la première alerte d'un outil, ni la conclusion d'une analyse forensique complète. C'est le moment où l'organisation dispose d'**éléments suffisamment sérieux** pour caractériser les faits. En pratique, il faut fixer une règle interne : > **Votre règle.** Le compteur démarre à l'instant où un élément crédible d'exploitation > active parvient à une personne exerçant une fonction de sécurité — PSIRT, astreinte, > support de niveau 2 — que cet élément soit interne ou externe. L'horodatage de cette > réception est enregistré et fait foi. Fixer une règle plus restrictive que nécessaire est risqué : une autorité appréciera la connaissance au regard de ce que l'organisation **aurait dû** savoir compte tenu des informations en sa possession. ### Comment qualifier l'exploitation active Le critère est l'existence d'une **preuve fiable** qu'un acteur malveillant a exploité la vulnérabilité dans un système sans l'autorisation de son propriétaire. | Élément | Suffit-il seul ? | | --- | --- | | Publication d'un exploit de démonstration | **Non** | | Score de gravité élevé | **Non** | | Inscription à un catalogue public de vulnérabilités exploitées | **Fort indice**, à confronter à la présence du composant chez vous | | Indicateurs de compromission concordants dans les journaux d'un client | **Oui** | | Analyse forensique établissant l'exploitation | **Oui** | | Signalement crédible et circonstancié d'un CERT ou d'un client | **Oui**, sous réserve de vérification rapide | La qualification technique relève du PSIRT ; la **décision de signaler** relève du juridique. Le PSIRT doit transmettre sa qualification dans un délai court — vous retenez **deux heures** — pour laisser au juridique le temps de décider. ### Qui décide Trois rôles, à nommer et à doubler : | Rôle | Fonction | Suppléant | | --- | --- | --- | | **Qualificateur** | Établit les faits techniques | Responsable PSIRT | | **Décideur** | Décide de signaler ou non | Directeur juridique, ou personne titulaire d'une délégation écrite | | **Émetteur** | Rédige et transmet via la plateforme | PSIRT, avec validation du décideur | La **délégation écrite** est indispensable : un délai de 24 heures ne s'accommode pas d'une chaîne de validation remontant jusqu'à la direction générale un week-end. ### La règle de décision par défaut En cas de doute sérieux et persistant après qualification : **signaler**. Le raisonnement est asymétrique. Le règlement prévoit expressément le [signalement volontaire](/fr/cra/signalement-enisa/), qui **n'entraîne aucune obligation supplémentaire**. Le coût d'un signalement non strictement obligatoire est donc nul en droit. Le coût d'un signalement manqué relève, lui, du plafond de sanction le plus élevé. Cette règle doit être écrite et connue de l'astreinte, faute de quoi la décision par défaut sera, en pratique, l'inaction. ### Documenter la décision C'est la pièce défensive centrale. Chaque événement qualifié donne lieu à une entrée au registre, **que l'on ait signalé ou non** : | Champ | Contenu | | --- | --- | | Horodatage de la connaissance | Date, heure, canal, personne réceptrice | | Faits | Description de l'élément déclencheur | | Produits et versions concernés | Liste, avec la base installée estimée | | Qualification | Exploitation active : oui / non / indéterminé, avec les éléments retenus | | **Décision** | Signaler / ne pas signaler / signaler volontairement | | **Motivation** | Le raisonnement, pas seulement la conclusion | | Décideur | Nom et fonction | | Horodatage de la décision | Délai écoulé depuis la connaissance | | Envois | Alerte précoce, notification, rapport final : dates et accusés | | Information des utilisateurs | Date, canal, contenu | Un registre où ne figurent que les événements signalés est suspect : il laisse penser qu'aucune décision négative n'a jamais été prise, ce qui est invraisemblable. ### L'astreinte juridique Un délai de 24 heures couvre les nuits, les week-ends et les jours fériés. Cela suppose : - un **tour d'astreinte** juridique, ou à défaut une délégation permanente à une fonction disponible ; - des **gabarits pré-remplis** avec vos identifiants d'entreprise, pour que la rédaction ne soit pas le facteur limitant ; - un **accès nominatif actif** à la plateforme de signalement pour les personnes d'astreinte, testé et non expiré ; - une **procédure d'escalade** si le décideur est injoignable, avec un délai maximal avant bascule sur le suppléant. ### Les trois régimes en parallèle Un même événement peut relever du CRA, de NIS 2 et du RGPD. Le tableau comparatif figure dans [Articulation avec les autres réglementations](/fr/cra/articulation-autres-textes/). La cellule de crise doit statuer sur les trois **simultanément**, avec trois gabarits distincts — les traiter en série fait mécaniquement dépasser le délai le plus court. ## Propriété intellectuelle et licences URL: https://cra-reference.eu/fr/legal/propriete-intellectuelle/ Description: La politique de licences appliquée en CI, le processus d'exception, le registre, les livrables d'attribution et la préparation des audits clients. Audience: legal Published 2026-08-19, updated 2026-08-19 Le fond du sujet est traité ailleurs : les [familles de licences](/fr/licences/familles/) et ce qu'elles imposent, les [mécanismes qui déclenchent une obligation](/fr/licences/mecanismes/), le [verdict par type de produit](/fr/licences/scenarios/) et les [pièges](/fr/licences/pieges/) qui échappent à la grille. La licence en tant que donnée du SBOM est dans [La licence comme donnée du SBOM](/fr/sbom/licences-spdx/). Cette page-ci décrit **le dispositif** : la politique, le processus, le registre et les livrables. ### Pourquoi c'est un chantier CRA Le CRA n'exige pas la conformité aux licences. Mais il exige un SBOM, et un SBOM correctement renseigné rend la conformité aux licences **automatisable pour la première fois**. C'est un bénéfice collatéral majeur, et l'argument qui permet de financer l'outillage sur deux budgets plutôt qu'un. ### La politique de licences Trois listes, déclinées par **contexte d'usage** : | Contexte | Ce qui change | | --- | --- | | **Produit distribué** au client | Le plus restrictif : le copyleft fort est en liste noire | | **Service en ligne** | Le copyleft **réseau** (AGPL) devient bloquant | | **Outil interne** non distribué | Le plus permissif : la plupart des obligations ne se déclenchent pas | | **Code de test** non livré | Régime allégé, mais surveillé | La politique est un document **versionné**, approuvé, avec une date d'effet. Elle est publiée aux équipes et **exécutée par la chaîne de construction**, pas seulement affichée. ### Le processus, de bout en bout 1. **Détection.** Le SBOM porte les licences ; la plateforme les confronte à la politique. 2. **Décision automatique.** Liste blanche : la construction passe. Liste noire : la construction **échoue**. Liste grise : avertissement et création d'un ticket. 3. **Analyse.** L'ingénierie documente le chemin d'introduction du composant, l'usage réel, et propose une option : remplacer, isoler, ou demander une exception. 4. **Décision juridique.** Le juridique statue, avec conditions et **date d'expiration**. 5. **Enregistrement.** Inscription au registre des exceptions, horodatée. 6. **Réexamen.** À l'expiration, ou plus tôt si le contexte change. ### Le registre des exceptions | Colonne | Contenu | | --- | --- | | Composant et version | Identifié par `purl` | | Licence | Expression SPDX complète | | Produit et contexte | Où l'exception s'applique | | Motif de la demande | Absence d'alternative, coût de migration, criticité | | Conditions | Isolation technique, absence de distribution, attribution renforcée | | **Date d'expiration** | Obligatoire | | Décideur | Nom et fonction | | Statut | Active, expirée, révoquée | Une exception sans date d'expiration devient une règle non écrite. C'est le principal défaut observé dans les dispositifs existants. ### Les livrables | Livrable | Quand | Généré depuis | | --- | --- | --- | | **Fichier d'attributions** (`NOTICE`) livré avec le produit | À chaque version | Le SBOM | | **Offre écrite de fourniture du code source** | Si un composant sous copyleft le requiert | Le registre | | **Rapport de conformité** pour un client | Sur demande | Le SBOM + le registre | | **Inventaire par licence** du portefeuille | Trimestriel | La plateforme | Le fichier d'attributions est le manquement le plus fréquent et le plus facile à corriger : sa génération doit être **automatique** et sa présence **vérifiée en CI**. ### La préparation aux audits Les demandes viennent de trois sources : clients grands comptes, investisseurs lors d'une opération, et acquéreurs. Elles portent toujours sur les mêmes points : - l'existence d'une **politique** de licences écrite et appliquée ; - la **complétude** de l'inventaire, y compris transitif ; - la **cohérence** entre l'inventaire et les attributions livrées ; - le traitement des **licences à obligations fortes** ; - le **registre des exceptions** et sa tenue. Répondre à ces demandes est instantané si le dispositif est en place, et représente plusieurs semaines de travail sinon. C'est le meilleur indicateur de la maturité réelle. ### Le point de friction à traiter Une politique de propriété intellectuelle interdisant à vos salariés de publier du code entre en conflit direct avec l'obligation du règlement de **remonter les correctifs de sécurité aux projets amont** — voir [Intégrer de l'open source](/fr/cra/open-source/integrer-de-l-oss/). Les deux politiques doivent être réconciliées par écrit, avec une procédure de contribution suffisamment légère pour être compatible avec un délai de correction de quelques jours. ## Exposition et registre des risques URL: https://cra-reference.eu/fr/legal/sanctions-et-exposition/ Description: Chiffrer l'exposition administrative, commerciale et contractuelle ; tenir un registre des risques de conformité ; anticiper l'effet sur les diligences d'acquisition. Audience: direction Legal basis: Art. 64 — sanctions · Chapitre V — mesures de surveillance du marché Published 2026-08-19, updated 2026-08-19 Le barème est décrit dans [Les sanctions](/fr/cra/sanctions/). Cette page sert à en tirer un chiffre, puis un registre. ### Les trois expositions #### 1. Exposition administrative Le plafond le plus élevé entre **15 000 000 €** et **2,5 % du chiffre d'affaires annuel mondial total** de l'exercice précédent, pour les manquements aux exigences essentielles et aux obligations des articles 13 et 14. Calcul à porter au comité : ``` Exposition administrative = max(15 000 000 € ; 0,025 × CA mondial consolidé N-1) ``` Ce chiffre est un **plafond**, pas une prévision. Il sert à dimensionner l'effort, pas à prédire une amende. #### 2. Exposition commerciale Souvent supérieure d'un ordre de grandeur à la précédente, et plus rapide à se matérialiser. ``` Exposition commerciale = (CA réalisé dans l'Union / 12) × durée en mois d'une interdiction de mise à disposition ou d'un retrait ``` À compléter par le coût d'un **rappel** si le produit est matériel : logistique, remplacement, communication. #### 3. Exposition contractuelle Pénalités, clauses de conformité réglementaire, droits de résiliation et engagements d'indemnisation prévus dans vos contrats clients. Cette exposition se lit dans les contrats, pas dans le règlement, et elle est souvent la plus immédiate : un grand compte peut suspendre un contrat bien avant qu'une autorité n'agisse. ### Le registre des risques de conformité Tenu par la direction juridique, revu à chaque comité. Une ligne par risque identifié : | Colonne | Contenu | | --- | --- | | Risque | Formulé comme un événement, pas comme une lacune | | Produits concernés | Avec leur part de chiffre d'affaires | | Cause | Lacune technique, organisationnelle ou documentaire | | Probabilité | Échelle à quatre niveaux, avec critères écrits | | Impact | Les trois expositions ci-dessus | | Mesures en cours | Avec responsable et échéance | | Risque résiduel | Après mesures | | Décision | Traiter, réduire, transférer, **accepter** — avec le nom de qui accepte | La colonne « accepter » est essentielle : un risque accepté par une personne identifiée n'est pas un risque ignoré. C'est aussi ce qui protège les équipes lorsqu'un arbitrage budgétaire a été fait en connaissance de cause. ### Exemples de lignes typiques | Risque | Cause | Mesure | | --- | --- | --- | | Impossibilité de produire le dossier technique d'une version livrée en 2028 lors d'un contrôle en 2033 | Archivage non testé | Exercice annuel de restitution | | Dépassement du délai de 24 heures un week-end | Absence d'astreinte juridique | Délégation écrite + tour d'astreinte | | Produit de classe II sans organisme notifié engagé | Capacité de marché saturée | Contractualisation immédiate | | Période de support intenable sur un produit reposant sur un composant amont abandonné | Diligence insuffisante à l'intégration | Plan de remplacement ou de reprise | | Composant AGPL dans une offre en ligne | Politique de licences non appliquée en CI | Blocage en CI + audit du parc existant | ### L'effet sur les opérations de croissance Le CRA est devenu un point d'audit standard des **diligences d'acquisition** et des levées de fonds. Un acquéreur demandera : - le **registre de classification** du portefeuille ; - l'existence et la complétude des **dossiers techniques** ; - le **registre des signalements** et le respect des délais ; - le **registre des périodes de support** et les engagements associés ; - la **conformité des licences**, avec le registre des exceptions. Une lacune sur ces points se traduit par une garantie de passif, une retenue de prix ou une condition suspensive. C'est un argument de financement du projet à part entière, et souvent le plus efficace auprès d'un comité. ## Traduire la période de support en engagements URL: https://cra-reference.eu/fr/legal/support-contractuel/ Description: Du texte du règlement aux conditions générales : mention obligatoire à l'acheteur, désynchronisation avec les fournisseurs, politique de fin de vie et registre. Audience: legal Legal basis: Art. 13, paragraphe 8 · Annexe II, point 8 Published 2026-08-19, updated 2026-08-19 La règle est exposée dans [Période de support et cycle de vie](/fr/cra/support-et-cycle-de-vie/). Cette page traite de sa traduction contractuelle et commerciale. ### Ce qui doit figurer où | Support | Contenu | | --- | --- | | **Documentation produit** (annexe II) | Type de support technique de sécurité offert et **date de fin de la période de support**, au moins le mois et l'année, en des termes clairs et compréhensibles | | **Fiche commerciale et page produit** | La même date, visible **au moment de l'achat** | | **Conditions générales** | Le contenu du support de sécurité, ce qu'il couvre et ne couvre pas, les modalités de mise à disposition des correctifs | | **Dossier technique** | La durée retenue **et sa justification** | | **Registre interne** | La consolidation, avec les dépendances limitantes | ### La rédaction de la mention Elle doit être compréhensible par un acheteur non spécialiste. Une formulation type : > **Support de sécurité.** Ce produit bénéficie de mises à jour de sécurité jusqu'au > **[mois année]**. Pendant cette période, les correctifs de sécurité sont fournis > gratuitement et diffusés séparément des évolutions fonctionnelles lorsque cela est > techniquement possible. Après cette date, aucun nouveau correctif ne sera produit ; les > correctifs déjà publiés restent téléchargeables jusqu'au **[mois année]**. Les deux dates sont distinctes et doivent apparaître toutes les deux : la fin de la **production** de correctifs, et la fin de leur **mise à disposition**. ### La désynchronisation avec l'amont Le problème structurel : vous engagez cinq ans envers vos clients, sur un produit reposant sur des composants dont le support amont s'arrête plus tôt. | Situation | Options | | --- | --- | | Composant tiers commercial dont le support s'arrête avant le nôtre | Négocier un support étendu ; prévoir une migration ; réduire votre engagement | | Composant libre abandonné | Forker et maintenir, remplacer, internaliser — voir [Intégrer de l'open source](/fr/cra/open-source/integrer-de-l-oss/) | | Système d'exploitation ou plateforme sous-jacente en fin de vie | Planifier la migration, ou aligner votre fin de support | Chacune de ces options a un coût, qui doit être **provisionné à la décision d'intégrer le composant**, pas découvert trois ans plus tard. C'est pourquoi le critère « durée de support amont » figure dans la grille de diligence. ### La gratuité Les correctifs de sécurité sont diffusés **gratuitement** pendant la période de support, sauf accord contraire pour des produits sur mesure entre professionnels. Conséquence commerciale directe : **un contrat de maintenance ne peut pas conditionner l'accès aux correctifs de sécurité**. Il peut porter sur le support fonctionnel, les évolutions, l'assistance, les délais de réponse garantis — pas sur les correctifs de sécurité eux-mêmes. Les offres existantes doivent être revues à ce titre. C'est une remise en cause de modèle économique pour certains éditeurs, et elle doit être traitée comme telle. ### La politique de fin de vie À écrire une fois, appliquée à tous les produits : 1. **Annonce** de la fin de support, avec un préavis défini — douze mois est une pratique raisonnable pour un produit professionnel. 2. **Rappels** à intervalles réguliers pendant le préavis, via tous les canaux disponibles. 3. **Chemin de migration** proposé : produit successeur, procédure, accompagnement. 4. **Dernière mise à jour** publiée, avec la liste des vulnérabilités connues non corrigées. 5. **Information sur le risque résiduel** de l'usage après la fin de support. 6. **Maintien de la mise à disposition** des correctifs déjà publiés jusqu'à la date due. 7. **Archivage** du dossier technique et du SBOM pour la durée restante. ### En cas de cessation d'activité Le règlement prévoit que le fabricant qui cesse ses opérations en informe les **autorités de surveillance du marché** et, **par tout moyen disponible**, les **utilisateurs** des produits concernés. Il encourage par ailleurs le transfert du code source ou sa publication en logiciel libre pour permettre la poursuite de la maintenance. Ces dispositions doivent être anticipées dans vos statuts et vos procédures de liquidation : il est trop tard pour les organiser une fois la cessation décidée. ### Le registre Le tableau à tenir figure dans [Période de support et cycle de vie](/fr/cra/support-et-cycle-de-vie/). Il est revu à chaque comité, car c'est lui qui révèle les engagements devenus intenables — et le seul moment où les corriger sans coût est **avant** de les prendre. ## Licences open source URL: https://cra-reference.eu/fr/licences/ Description: Les familles de licences libres, ce qui déclenche réellement leurs obligations, et neuf scénarios de distribution réels — du backend SaaS à l'objet connecté — avec le verdict par famille. Audience: transverse Legal basis: Art. 13, paragraphe 5 — diligence sur les composants tiers · Annexe I, partie II, point 1 — inventaire des composants Published 2026-08-20, updated 2026-08-20 ### La seule idée à retenir > **Une licence ne pose jamais problème dans l'absolu. Elle pose problème dans un > scénario.** La même bibliothèque sous AGPL-3.0 est **inoffensive** dans un outil interne et **fatale** dans un backend SaaS. La même bibliothèque sous GPL-3.0 est **banale** sur un poste de travail et **bloquante** dans un objet connecté verrouillé. Un composant sous CC-BY-NC est sans conséquence dans une maquette et **interdit** dans un produit vendu. Ce qui déclenche une obligation, ce n'est pas le nom de la licence : c'est **ce que vous faites du logiciel** — le distribuez-vous ? à qui ? sous quelle forme ? l'exposez-vous par le réseau ? l'utilisateur peut-il remplacer le composant ? C'est pourquoi cette section est organisée en **matrice** : les [familles de licences](/fr/licences/familles/) d'un côté, les [scénarios de distribution](/fr/licences/scenarios/) de l'autre, et [ce qui fait le lien](/fr/licences/mecanismes/) entre les deux. ### La matrice, en une page Lecture : **●** sans difficulté · **◐** sous conditions, à instruire · **○** à éviter · **✕** incompatible en pratique. | Scénario | Permissive | Copyleft faible fichier | Copyleft faible bibliothèque | Copyleft fort | Copyleft réseau | Source-available | | --- | :--: | :--: | :--: | :--: | :--: | :--: | | | MIT, Apache-2.0 | MPL-2.0, EPL-2.0 | LGPL-2.1/3.0 | GPL-2.0/3.0 | AGPL-3.0 | BSL, SSPL, ELv2 | | [Cas général](/fr/licences/scenarios/cas-general/) | ● | ◐ | ○ | ○ | ✕ | ✕ | | [Backend SaaS](/fr/licences/scenarios/saas-backend/) | ● | ● | ● | ● | **✕** | ○ | | [Frontend web](/fr/licences/scenarios/frontend-web/) | ◐ | ◐ | ○ | ✕ | ✕ | ✕ | | [Application bureau / CLI](/fr/licences/scenarios/application-bureau/) | ● | ● | ◐ | ◐ | ○ | ✕ | | [Application mobile](/fr/licences/scenarios/application-mobile/) | ● | ● | ○ | **✕** | ✕ | ✕ | | [Bibliothèque / SDK publié](/fr/licences/scenarios/bibliotheque-sdk/) | ● | ◐ | ○ | ○ | ○ | ✕ | | [On-premise](/fr/licences/scenarios/on-premise/) | ● | ● | ◐ | ◐ | ○ | ✕ | | [Embarqué / IoT](/fr/licences/scenarios/embarque-iot/) | ● | ● | ○ | **○ v2 / ✕ v3** | ✕ | ✕ | | [Outil interne](/fr/licences/scenarios/outil-interne/) | ● | ● | ● | ● | ◐ | ◐ | Chaque case est expliquée dans la page du scénario correspondant. Les symboles ne remplacent pas la lecture : un **◐** peut cacher une contrainte d'ingénierie lourde, et un **●** ne dispense jamais de l'attribution. ### Ce que cette section n'est pas Elle **ne remplace pas un avis juridique**. Le droit des licences libres repose sur le droit d'auteur, qui est national ; la notion d'« œuvre dérivée » n'a **pas de définition jurisprudentielle stabilisée en Europe** pour le logiciel, et les positions des auteurs de licences — notamment sur la liaison — ne sont pas du droit positif. Là où une question est disputée, la page le dit. Elle **ne traite pas non plus de votre processus interne** : la politique de licences, les listes blanche/grise/noire, le registre des exceptions et les livrables d'attribution sont dans [Propriété intellectuelle](/fr/legal/propriete-intellectuelle/). ### Le rapport avec le CRA Le règlement (UE) 2024/2847 **n'impose pas** la conformité aux licences. Il la rend mesurable, et il en fait un sujet de diligence : - l'**inventaire obligatoire** (annexe I, partie II, point 1) porte les identifiants de licence : pour la première fois, la conformité juridique devient calculable à l'échelle du portefeuille ; - la **diligence sur les composants tiers** (art. 13, paragraphe 5) inclut l'examen de la licence, au même titre que la maintenance et l'historique de sécurité ; - l'obligation de **remonter les correctifs à l'amont** (art. 13, paragraphe 6) suppose une politique de contribution qui autorise vos ingénieurs à publier du code ; - la **période de support** de cinq à dix ans impose de conserver le code source correspondant et la chaîne de compilation — exactement ce que la GPL exige par ailleurs. Autrement dit : le travail de conformité CRA et le travail de conformité aux licences partagent leurs artefacts. Les mener séparément, c'est les payer deux fois. ### Par où commencer - Vous découvrez le sujet : [Les familles de licences](/fr/licences/familles/). - Vous voulez comprendre pourquoi la même licence change de nature selon le contexte : [Ce qui déclenche une obligation](/fr/licences/mecanismes/). - Vous avez un produit précis en tête : allez directement au [scénario](/fr/licences/scenarios/) qui lui correspond. - Vous cherchez ce qui échappe à la matrice : [Les pièges](/fr/licences/pieges/). ## Les familles de licences URL: https://cra-reference.eu/fr/licences/familles/ Description: Domaine public, permissives, copyleft faible par fichier ou par bibliothèque, copyleft fort, copyleft réseau, source-available, licences de contenu : ce que chacune impose réellement. Audience: transverse Published 2026-08-20, updated 2026-08-20 Il existe des centaines de licences ; la liste SPDX en référence plus de six cents. Mais elles se rangent en **huit familles**, et à l'intérieur d'une famille les obligations sont quasiment les mêmes. Connaître les huit suffit à traiter 99 % des cas. ### Vue d'ensemble | Famille | Réciprocité | Ce qu'elle impose | Représentants | | --- | --- | --- | --- | | **1. Domaine public** | Aucune | Rien, ou presque | CC0-1.0, Unlicense, 0BSD | | **2. Permissive** | Aucune | Attribution, conservation des mentions | MIT, BSD, Apache-2.0, ISC | | **3. Copyleft faible — fichier** | Par fichier modifié | Publier les fichiers modifiés | MPL-2.0, EPL-2.0, CDDL | | **4. Copyleft faible — bibliothèque** | Par bibliothèque | Publier la bibliothèque, permettre son remplacement | LGPL-2.1, LGPL-3.0 | | **5. Copyleft fort** | Sur l'œuvre entière | Publier le source de l'œuvre dérivée distribuée | GPL-2.0, GPL-3.0, CeCILL | | **6. Copyleft réseau** | Sur l'œuvre entière, réseau compris | Idem, y compris sans distribution | AGPL-3.0, OSL-3.0, EUPL-1.2 | | **7. Source-available** | Variable | Restrictions d'usage — **pas du libre** | BSL-1.1, SSPL-1.0, ELv2 | | **8. Contenu et données** | Variable | Régime propre aux œuvres non logicielles | CC-BY, CC-BY-SA, OFL, ODbL | --- ### 1. Domaine public et renonciation **[CC0-1.0](https://spdx.org/licenses/CC0-1.0.html)**, **[Unlicense](https://spdx.org/licenses/Unlicense.html)**, **[0BSD](https://spdx.org/licenses/0BSD.html)**, **WTFPL**. L'auteur renonce à ses droits ou concède une licence maximalement permissive. Aucune attribution due. **Le piège** : **CC0 exclut expressément la concession de brevets**. Un composant CC0 dont l'auteur détient un brevet ne vous protège de rien. Plusieurs fondations restreignent son usage pour cette raison, et lui préfèrent une licence permissive avec clause de brevets. En droit français et allemand, la renonciation pure aux droits moraux est en outre inopérante — ce qui n'a pas de conséquence pratique en général, mais explique pourquoi certains juristes préfèrent MIT à CC0. --- ### 2. Permissives **[MIT](https://spdx.org/licenses/MIT.html)**, **[BSD-2-Clause](https://spdx.org/licenses/BSD-2-Clause.html)**, **[BSD-3-Clause](https://spdx.org/licenses/BSD-3-Clause.html)**, **[ISC](https://spdx.org/licenses/ISC.html)**, **[Apache-2.0](https://spdx.org/licenses/Apache-2.0.html)**, **[Zlib](https://spdx.org/licenses/Zlib.html)**, **[BSL-1.0](https://spdx.org/licenses/BSL-1.0.html)** (Boost), **[CECILL-B](https://spdx.org/licenses/CECILL-B.html)**. Vous faites ce que vous voulez, y compris intégrer dans du propriétaire, à condition de **conserver les mentions de copyright et le texte de la licence** et de les transmettre aux destinataires. #### Ce qui les distingue entre elles | Licence | Spécificité | | --- | --- | | **MIT**, **ISC** | Les plus courtes. Attribution, rien d'autre. | | **BSD-2-Clause** | Équivalent MIT. | | **BSD-3-Clause** | Ajoute une clause de **non-endossement** : interdiction d'utiliser le nom des auteurs pour promouvoir votre produit. | | **BSD-4-Clause** | Ajoute une **clause de publicité** obsolète : toute publicité doit mentionner l'auteur. Ingérable à l'échelle, et **incompatible GPL**. À refuser. | | **Apache-2.0** | **Concession expresse de brevets**, **résiliation automatique** de cette concession si vous engagez une action en contrefaçon de brevet contre un contributeur, et obligation de signaler les fichiers modifiés. Fichier `NOTICE` à propager s'il existe. | > **Pourquoi Apache-2.0 est souvent le meilleur choix.** C'est la seule permissive courante > qui traite explicitement la question des brevets. Pour un produit vendu, c'est une > protection réelle que MIT n'offre pas. **L'incompatibilité à connaître** : selon la [position de la Free Software Foundation](https://www.gnu.org/licenses/license-list.html), **Apache-2.0 est incompatible avec GPL-2.0-only** (à cause des clauses de brevets et d'indemnisation, vues comme des restrictions supplémentaires), mais **compatible avec GPL-3.0**. C'est la raison pour laquelle beaucoup de projets sont passés en `GPL-2.0-or-later`. **Le vrai risque des permissives**, en pratique, n'est pas juridique mais opérationnel : c'est **l'oubli du fichier d'attributions**. Il concerne des centaines de composants, il se génère automatiquement depuis le SBOM, et son absence est le manquement le plus fréquent et le plus facile à corriger. --- ### 3. Copyleft faible, à granularité **fichier** **[MPL-2.0](https://spdx.org/licenses/MPL-2.0.html)**, **[EPL-2.0](https://spdx.org/licenses/EPL-2.0.html)**, **[CDDL-1.0](https://spdx.org/licenses/CDDL-1.0.html)**, **[CECILL-C](https://spdx.org/licenses/CECILL-C.html)**. La réciprocité porte sur **les fichiers eux-mêmes**. Si vous modifiez un fichier sous MPL-2.0, ce fichier reste MPL-2.0 et doit être publié. Le reste de votre projet, y compris les fichiers qui l'appellent, peut rester propriétaire. C'est la famille la plus **maniable** : elle protège l'amont sans contaminer votre code. | Licence | Spécificité | | --- | --- | | **MPL-2.0** | Le modèle de référence. Clause de brevets. Compatible GPL par une clause explicite (sauf si l'auteur l'a désactivée). | | **EPL-2.0** | Réciprocité comparable. Une clause optionnelle de « licence secondaire » permet la compatibilité GPL, à activer par l'auteur. | | **CDDL-1.0** | **Incompatible GPL**, et cette incompatibilité est la raison pour laquelle ZFS n'est pas intégré au noyau Linux. À traiter comme un cas particulier. | **Le piège** : « par fichier » suppose de savoir **quels fichiers ont été modifiés**. Un copier-coller d'une fonction MPL dans l'un de vos fichiers propriétaire fait basculer *votre* fichier sous MPL. La discipline de séparation des fichiers est donc une contrainte d'ingénierie, pas seulement une formalité. --- ### 4. Copyleft faible, à granularité **bibliothèque** **[LGPL-2.1](https://spdx.org/licenses/LGPL-2.1-only.html)**, **[LGPL-3.0](https://spdx.org/licenses/LGPL-3.0-only.html)**. La bibliothèque reste libre ; l'œuvre qui l'utilise peut rester propriétaire. Mais à une condition, souvent mal comprise : > **L'utilisateur final doit pouvoir remplacer la bibliothèque par une version modifiée de > son choix, et faire fonctionner votre programme avec.** C'est ce qui rend la **liaison dynamique** naturelle et la **liaison statique** coûteuse : en statique, vous devez fournir les fichiers objets de votre application pour que l'utilisateur puisse relier lui-même, ou tout autre moyen équivalent. | Version | Spécificité | | --- | --- | | **LGPL-2.1** | Le régime classique. Pas de clause anti-verrouillage. | | **LGPL-3.0** | Hérite des clauses de **GPL-3.0** : brevets, anti-DRM, et surtout **informations d'installation** pour les produits de consommation. Beaucoup plus contraignante en embarqué et sur mobile. | **Le piège** : dans les écosystèmes où la liaison dynamique n'existe pas — un *bundle* JavaScript, un binaire Go, un exécutable Rust, une application mobile — la LGPL doit être traitée **comme du copyleft fort**, parce que la condition de remplacement est en pratique impossible à satisfaire. --- ### 5. Copyleft fort **[GPL-2.0-only](https://spdx.org/licenses/GPL-2.0-only.html)**, **[GPL-2.0-or-later](https://spdx.org/licenses/GPL-2.0-or-later.html)**, **[GPL-3.0-only](https://spdx.org/licenses/GPL-3.0-only.html)**, **[GPL-3.0-or-later](https://spdx.org/licenses/GPL-3.0-or-later.html)**, **[CeCILL](https://spdx.org/licenses/CECILL-2.1.html)** (équivalent français, compatible GPL). Si vous **distribuez** un binaire contenant du code GPL — ou une œuvre dérivée de ce code — vous devez fournir à chaque destinataire le **code source correspondant** de l'œuvre entière, sous la même licence, y compris les scripts de compilation et d'installation. Le mot décisif est **distribuez** : la GPL ne se déclenche que par la transmission à un tiers. Un usage purement interne, ou l'exécution sur vos propres serveurs, ne la déclenche pas — voir [Backend SaaS](/fr/licences/scenarios/saas-backend/). #### `only` contre `or-later` Le suffixe n'est pas cosmétique : il détermine si le destinataire peut appliquer une version ultérieure de la licence. - `GPL-2.0-only` : figé en version 2. **Incompatible** avec les composants GPL-3.0. - `GPL-2.0-or-later` : le destinataire peut choisir la version 3, ce qui rétablit la compatibilité. - Un projet sans mention explicite est réputé, selon les usages, `-or-later` — mais la question s'est posée en contentieux. Documentez ce que vous constatez, ne présumez pas. #### Ce que GPL-3.0 ajoute à GPL-2.0 | Ajout | Effet | | --- | --- | | **Concession de brevets** explicite | Protection réelle, absente de la v2 | | **Clause anti-verrouillage** (« informations d'installation ») | Pour un **produit de consommation**, vous devez fournir de quoi installer une version modifiée. Voir [Embarqué / IoT](/fr/licences/scenarios/embarque-iot/) | | **Clause anti-DRM** | Le logiciel ne doit pas être invoqué comme mesure technique de protection | | **Compatibilité Apache-2.0** | Résout l'incompatibilité de la v2 | | **Résiliation avec délai de grâce** | Une violation corrigée sous 30 jours après notification n'entraîne plus la perte définitive des droits | #### Les exceptions Certains projets assortissent la GPL d'une **exception** qui en limite la portée. Elles s'expriment en SPDX avec l'opérateur `WITH` : | Exception | Effet | | --- | --- | | [`GPL-2.0-only WITH Classpath-exception-2.0`](https://spdx.org/licenses/Classpath-exception-2.0.html) | Utilisée par OpenJDK : la liaison ne crée pas d'œuvre dérivée. C'est ce qui permet d'écrire du Java propriétaire. | | [`GPL-3.0-only WITH GCC-exception-3.1`](https://spdx.org/licenses/GCC-exception-3.1.html) | Le code compilé par GCC n'est pas contaminé par les bibliothèques d'exécution. | | [`Apache-2.0 WITH LLVM-exception`](https://spdx.org/licenses/LLVM-exception.html) | Lève une contrainte d'attribution pour le code généré. | | [`GPL-2.0-only WITH Autoconf-exception-2.0`](https://spdx.org/licenses/Autoconf-exception-2.0.html) | Les scripts générés ne sont pas contaminés. | **Ne jamais lire une licence GPL sans vérifier s'il y a une exception** : elle change complètement le verdict. --- ### 6. Copyleft réseau **[AGPL-3.0](https://spdx.org/licenses/AGPL-3.0-only.html)**, **[OSL-3.0](https://spdx.org/licenses/OSL-3.0.html)**, **[EUPL-1.2](https://spdx.org/licenses/EUPL-1.2.html)** (dans sa lecture la plus large), **RPL**. Conçues pour fermer ce que l'on appelle la « faille du fournisseur de service » : la GPL ne se déclenche qu'à la distribution, or un service en ligne ne distribue rien. **AGPL-3.0, article 13** : si vous **modifiez** le programme et que des utilisateurs interagissent avec votre version modifiée **à distance par un réseau**, vous devez leur offrir le code source correspondant de votre version. #### La nuance qui compte Littéralement, l'obligation vise la version **modifiée**. Exécuter un logiciel AGPL **strictement inchangé** comme service ne déclenche pas l'article 13. Mais dans la pratique, l'exception ne sert presque jamais : dès que vous **combinez** le composant AGPL avec votre propre code — un appel de bibliothèque suffit à poser la question de l'œuvre combinée — c'est l'ensemble qui devient « votre version », et c'est l'ensemble dont il faut offrir le source. > **La position prudente**, et celle que retiennent la plupart des politiques d'entreprise : > **considérer que tout composant AGPL présent dans un service exposé déclenche l'obligation**, > et ne conserver la lecture littérale que pour un composant strictement inchangé, isolé dans > son propre processus, et documenté comme tel. **EUPL-1.2** mérite une mention particulière sur un site européen : c'est la licence de l'Union, elle comporte une clause de copyleft étendue à la mise à disposition par réseau, et surtout une **clause de compatibilité** qui liste les licences vers lesquelles l'œuvre peut être relicenciée (GPL, AGPL, MPL, EPL, CeCILL, LGPL…). Cette clause en fait un choix intéressant pour un projet public européen. --- ### 7. Source-available — ce n'est pas du libre **[BSL-1.1](https://mariadb.com/bsl11/)** (Business Source License), **[SSPL-1.0](https://www.mongodb.com/legal/licensing/server-side-public-license)**, **[Elastic License 2.0](https://www.elastic.co/licensing/elastic-license)**, **Confluent Community License**, **Redis Source Available License**, famille **[PolyForm](https://polyformproject.org/)**, et le rider **[Commons Clause](https://commonsclause.com/)**. Le code est lisible, parfois modifiable, mais **l'usage est restreint**. Aucune n'est approuvée par l'[Open Source Initiative](https://opensource.org/osd). **Traitez-les comme du logiciel propriétaire** : elles relèvent de la négociation contractuelle, pas de la politique open source. | Licence | Restriction principale | | --- | --- | | **[BSL-1.1](https://mariadb.com/bsl11/)** | Usage en production restreint, sauf « *additional use grant* ». Bascule automatiquement vers une licence libre à une **date de changement**, typiquement quatre ans. | | **[SSPL-1.0](https://www.mongodb.com/legal/licensing/server-side-public-license)** | Si vous fournissez le logiciel **en tant que service**, vous devez publier l'intégralité du code de ce service — orchestration, sauvegarde, supervision, interfaces. En pratique dissuasif. | | **[Elastic License 2.0](https://www.elastic.co/licensing/elastic-license)** | Interdit de fournir le produit en **service managé**, de contourner les clés de licence, et de retirer les mentions. | | **[Commons Clause](https://commonsclause.com/)** | Ce n'est pas une licence mais un **avenant** greffé sur une licence libre, qui en retire le droit de vendre. Une bibliothèque « MIT + Commons Clause » n'est pas MIT. | **Le vrai risque de cette famille, c'est le changement de licence en amont.** Plusieurs projets majeurs ont basculé d'une licence libre vers une licence source-available au cours des dernières années. Vos versions déjà obtenues restent couvertes par l'ancienne licence, mais **les versions ultérieures ne le sont plus** — et vos mises à jour de sécurité viennent des versions ultérieures. Voir [Les pièges](/fr/licences/pieges/). --- ### 8. Contenu, données et polices Souvent oubliées parce qu'elles ne concernent pas du code — et régulièrement à l'origine des problèmes les plus concrets. | Licence | Objet | Ce qu'il faut savoir | | --- | --- | --- | | **[CC-BY-4.0](https://spdx.org/licenses/CC-BY-4.0.html)** | Contenu | Attribution requise, y compris dans un produit commercial | | **[CC-BY-SA-4.0](https://spdx.org/licenses/CC-BY-SA-4.0.html)** | Contenu | **Partage à l'identique** : une œuvre dérivée doit être publiée sous la même licence. Contamination du contenu. | | **[CC-BY-NC](https://spdx.org/licenses/CC-BY-NC-4.0.html)** | Contenu | **Usage non commercial uniquement.** Interdit dans un produit vendu. L'erreur la plus fréquente sur les icônes et illustrations. | | **[CC-BY-ND](https://spdx.org/licenses/CC-BY-ND-4.0.html)** | Contenu | Pas d'œuvre dérivée : pas de recadrage, pas de recoloration. | | **[OFL-1.1](https://spdx.org/licenses/OFL-1.1.html)** | Polices | Redistribution libre, mais **clause de nom réservé** : une police modifiée ne peut pas conserver son nom d'origine. Interdiction de vendre la police seule. | | **[ODbL](https://spdx.org/licenses/ODbL-1.0.html)** | Bases de données | Copyleft sur la base et sur les bases dérivées. | Creative Commons **déconseille elle-même** ses licences pour du code : elles ne traitent ni de la distinction source/binaire, ni des brevets. --- ### Le cas qui n'est pas une famille : l'absence de licence Un dépôt public **sans fichier de licence n'est pas libre**. En l'absence de concession expresse, le droit d'auteur s'applique dans sa plénitude : tous droits réservés. Le fait que le code soit visible ne concède rien. En SPDX, cela se note `NOASSERTION`. Dans votre politique, cela doit être **bloquant**, au même titre qu'une licence interdite — et non traité comme une donnée manquante bénigne. ## Ce qui déclenche une obligation URL: https://cra-reference.eu/fr/licences/mecanismes/ Description: Distribution, interaction réseau, œuvre dérivée, liaison statique ou dynamique, simple agrégation, produit de consommation, brevets : les huit mécanismes qui font qu'une licence mord — ou pas. Audience: transverse Published 2026-08-20, updated 2026-08-20 C'est la page qui explique pourquoi la même licence change complètement de nature d'un produit à l'autre. Huit mécanismes, dont trois seulement décident de l'essentiel. --- ### 1. La distribution — le mécanisme principal Presque toutes les obligations de copyleft sont conditionnées à la **transmission du logiciel à un tiers**. La GPL-3.0 parle de *conveying* : tout acte qui permet à quelqu'un d'autre de faire ou de recevoir des copies. **Est une distribution :** - livrer un binaire, un installeur, un paquet, un micrologiciel ; - publier une **image de conteneur** sur un registre, même privé mais accessible à un tiers ; - servir du **JavaScript à un navigateur** — c'est du code, et il change de main ; - fournir une **appliance virtuelle** ou une image machine ; - déployer chez un client, en **on-premise** ; - transmettre à une **autre personne morale du groupe** : une filiale est un tiers. **N'est pas une distribution :** - exécuter le logiciel sur vos propres serveurs pour rendre un service ; - l'utiliser en interne, y compris par des milliers de salariés ; - le déplacer entre vos propres machines. > **La conséquence la plus contre-intuitive du droit des licences libres :** vous pouvez > construire un service en ligne entier sur du code GPL sans avoir la moindre obligation de > publier quoi que ce soit. C'est ce qu'on appelle la « faille du fournisseur de service », > et c'est précisément ce que l'AGPL a été écrite pour fermer. --- ### 2. L'interaction par un réseau Mécanisme propre à l'**AGPL-3.0** et à l'**OSL-3.0**. L'obligation naît de l'usage à distance, sans qu'aucun binaire ne change de main. Trois conditions cumulatives pour l'AGPL, article 13 : 1. le programme a été **modifié** — ou combiné avec votre code, ce qui revient au même ; 2. des utilisateurs **interagissent avec lui à distance par un réseau** ; 3. votre version **prend en charge** cette interaction. Le détail de la nuance sur la version non modifiée est traité dans [Les familles](/fr/licences/familles/). Retenez la règle pratique : **dans un service exposé, un composant AGPL doit être considéré comme déclencheur** sauf démonstration contraire, documentée. --- ### 3. L'œuvre dérivée et l'œuvre combinée C'est **la question la plus disputée du domaine**, et il faut le dire clairement : elle n'a pas de réponse jurisprudentielle stabilisée en Europe pour le logiciel. Le copyleft ne se propage qu'à ce qui constitue une **œuvre dérivée** au sens du droit d'auteur. Reste à savoir ce qui en est une. **Ce qui fait consensus :** - modifier le code source d'un composant crée une œuvre dérivée ; - copier une portion substantielle de code dans votre fichier crée une œuvre dérivée ; - placer deux programmes indépendants côte à côte n'en crée pas (voir la simple agrégation). **Ce qui ne fait pas consensus :** la **liaison**. La Free Software Foundation soutient, dans sa [foire aux questions sur la GPL](https://www.gnu.org/licenses/gpl-faq.html), que lier un programme à une bibliothèque, statiquement ou dynamiquement, crée une œuvre combinée soumise au copyleft. Cette position est une **interprétation de l'auteur de la licence**, pas du droit positif ; une partie de la doctrine la conteste, en particulier pour la liaison dynamique via une interface stable et publique. **Les critères habituellement retenus** dans une analyse, du plus au moins contaminant : | Situation | Analyse dominante | | --- | --- | | Code copié dans votre fichier | Œuvre dérivée, sans discussion | | Liaison statique | Œuvre combinée selon la lecture majoritaire | | Liaison dynamique, structures de données partagées, appels intimes | Œuvre combinée selon la FSF, contesté | | Liaison dynamique via une interface stable et documentée | Zone grise | | Processus séparés communiquant par tube, socket ou HTTP | Généralement **pas** une œuvre dérivée | | Exécution d'un programme comme sous-processus | Généralement **pas** une œuvre dérivée | > **La conséquence d'ingénierie.** Lorsqu'un composant sous copyleft fort est indispensable et > qu'on veut préserver le reste du code, la parade classique consiste à l'**isoler dans un > processus séparé** communiquant par une interface réseau ou par ligne de commande. Ce n'est > pas une astuce d'avocat : c'est une décision d'architecture, à prendre tôt, et à documenter > comme telle. --- ### 4. La simple agrégation Réunir plusieurs programmes indépendants sur un même support de distribution ne crée pas d'œuvre dérivée. La GPL le dit expressément. **Exemples d'agrégation, donc sans contamination :** - une distribution Linux qui livre côte à côte des milliers de paquets sous des licences différentes ; - une **image de conteneur** contenant votre application et, séparément, des utilitaires GPL du système de base ; - un installeur qui dépose plusieurs exécutables indépendants. **La limite** : l'agrégation cesse dès qu'il y a **combinaison**. Une image qui contient un binaire GPL que votre application se contente d'exécuter reste une agrégation. La même image où votre application est liée à une bibliothèque GPL ne l'est plus. Chaque composant agrégé conserve en revanche **ses propres obligations** : l'agrégation ne dispense ni de l'attribution, ni de la fourniture du source pour les composants GPL présents. --- ### 5. Liaison statique contre liaison dynamique Décisif pour la **LGPL**, et pour elle seule. La LGPL autorise une application propriétaire à utiliser la bibliothèque, à condition que l'utilisateur puisse la **remplacer par une version modifiée** et faire fonctionner l'application avec. | Mode | Ce que vous devez fournir | | --- | --- | | **Liaison dynamique** | Rien de plus : l'utilisateur remplace la bibliothèque partagée. Le mode naturel. | | **Liaison statique** | Les **fichiers objets** de votre application, ou tout moyen équivalent permettant à l'utilisateur de relier avec sa propre version de la bibliothèque. | **Le point aveugle** : de nombreux écosystèmes modernes ne connaissent que la liaison statique — Go, Rust, les *bundles* JavaScript, les applications mobiles, la plupart des micrologiciels. Dans ces contextes, la condition de remplacement est en pratique inatteignable, et la LGPL doit être traitée comme du copyleft fort. --- ### 6. Le produit de consommation et les informations d'installation Mécanisme propre à **GPL-3.0** et **LGPL-3.0**, article 6 — l'« anti-verrouillage ». Si le logiciel est distribué dans un **produit de consommation**, vous devez fournir les **informations d'installation** : les méthodes, procédures, clés d'autorisation ou autres éléments nécessaires pour installer et exécuter une version modifiée sur ce produit. Autrement dit : **si l'appareil refuse de démarrer un logiciel que l'utilisateur a modifié, vous ne respectez pas la GPL-3.0.** C'est le mécanisme qui rend la GPL-3.0 problématique dans l'embarqué verrouillé et sur les plateformes à signature de code obligatoire — et qui explique pourquoi tant de projets embarqués restent délibérément en GPL-2.0. Voir [Embarqué / IoT](/fr/licences/scenarios/embarque-iot/). --- ### 7. Les mesures techniques de protection **GPL-3.0, article 3** : le logiciel couvert ne doit pas être considéré comme faisant partie d'une mesure technique de protection, et vous renoncez au droit d'en interdire le contournement. Conséquence directe : un composant GPL-3.0 ne peut pas participer à un dispositif de gestion des droits numériques. Point de friction récurrent avec les plateformes de distribution d'applications et avec les décodeurs. --- ### 8. Les clauses de brevets et leur résiliation Présentes dans **Apache-2.0** (article 3), **GPL-3.0** (article 11), **MPL-2.0** (article 2.1 b), **EPL-2.0**. Deux effets, souvent ignorés des équipes techniques : - **une concession** : les contributeurs vous accordent une licence sur leurs brevets couvrant leur contribution ; - **une résiliation** : si vous engagez une action en contrefaçon de brevet contre un contributeur au sujet de ce logiciel, **vous perdez cette concession**, et parfois la licence entière. Pour une entreprise qui détient un portefeuille de brevets, cette seconde clause est un sujet à part entière : elle peut neutraliser une stratégie contentieuse. Elle relève de la direction juridique, pas de l'équipe qui choisit la bibliothèque. --- ### Tableau de synthèse Quel mécanisme déclenche quelle famille : | Mécanisme | Permissive | MPL / EPL | LGPL | GPL | AGPL | | --- | :--: | :--: | :--: | :--: | :--: | | Usage interne, sans transmission | — | — | — | — | — | | Exposition réseau, sans transmission | — | — | — | — | **✔** | | Distribution binaire | Attribution | Fichiers modifiés | Bibliothèque + remplacement | **Œuvre entière** | **Œuvre entière** | | Liaison statique | — | — | **✔** objets à fournir | ✔ | ✔ | | Produit de consommation verrouillé | — | — | **✔** en v3 | **✔** en v3 | ✔ | | Action en contrefaçon de brevet | Apache : résiliation | Résiliation | v3 : résiliation | v3 : résiliation | Résiliation | ### Ce qu'il faut en faire Avant d'autoriser un composant, trois questions suffisent à instruire 90 % des dossiers : 1. **Ce composant sortira-t-il de l'entreprise sous forme exécutable ?** 2. **Sera-t-il exposé à des utilisateurs par un réseau ?** 3. **Sera-t-il lié à votre code, et de quelle manière ?** Les réponses désignent le [scénario](/fr/licences/scenarios/) applicable, et le scénario donne le verdict. ## Les pièges qui échappent à la matrice URL: https://cra-reference.eu/fr/licences/pieges/ Description: Changement de licence en amont, absence de licence, code copié, code généré par IA, assets, CLA, incompatibilités mutuelles : ce que la grille famille × scénario ne montre pas. Audience: transverse Published 2026-08-20, updated 2026-08-20 La matrice [famille × scénario](/fr/licences/) traite le cas normal : un composant identifié, sous une licence connue, dans un produit défini. Les incidents réels viennent presque toujours d'ailleurs. --- ### 1. Le changement de licence en amont Le risque le plus actif de la période. Plusieurs projets d'infrastructure majeurs ont quitté une licence libre pour une licence source-available au cours des dernières années — bases de données, moteurs de recherche, outils d'infrastructure, supervision, systèmes de tickets. **Le mécanisme :** les versions déjà publiées restent sous l'ancienne licence, définitivement. Mais **les versions suivantes ne le sont plus** — et vos correctifs de sécurité viennent des versions suivantes. L'organisation se retrouve alors devant trois options, toutes coûteuses : | Option | Coût | | --- | --- | | Rester sur la dernière version libre | Plus de correctifs de sécurité en amont : dette réglementaire directe au regard du CRA | | Basculer sur un fork communautaire | Maturité incertaine, écosystème fragmenté | | Accepter la nouvelle licence | Négociation commerciale, restrictions d'usage, coût récurrent | **Ce qu'il faut mettre en place :** - **épingler** les versions et les licences dans le SBOM, et **comparer d'une version à l'autre** — un changement de champ `license` est un événement à traiter, pas une donnée parmi d'autres ; - surveiller les **dix à vingt composants d'infrastructure critiques**, ceux dont le remplacement prendrait des mois ; - inscrire ce risque au **registre des risques de conformité**, avec un porteur nommé. --- ### 2. L'absence de licence Un dépôt public sans fichier de licence **n'est pas libre**. En l'absence de concession expresse, le droit d'auteur s'applique dans sa plénitude : tous droits réservés. La visibilité du code ne concède rien, et les conditions générales d'une forge ne concèdent au mieux qu'un droit de consultation et de duplication interne à la plateforme. En SPDX, cela s'écrit `NOASSERTION`. Dans une politique de licences, cela doit être **bloquant** — au même titre qu'une licence interdite, et non traité comme une métadonnée manquante. Variante fréquente et plus insidieuse : le dépôt **annonce** une licence dans son fichier `README` mais ne contient aucun texte de licence, ou en contient un autre. --- ### 3. Les licences multiples dans un même dépôt Le dépôt se déclare MIT. Un sous-dossier `vendor/`, `third_party/` ou `contrib/` contient du code sous une autre licence, parfois du copyleft. Aucun gestionnaire de paquets ne le voit : ils lisent le champ de licence déclaré dans le manifeste, pas le contenu des fichiers. **La seule parade** est l'analyse du **contenu des fichiers**, par empreinte, avec les outils dédiés — voir [Générateurs](/fr/outils/generation/). C'est lent, verbeux, et c'est la différence entre une conformité déclarative et une conformité établie. --- ### 4. Le code copié **Depuis un forum ou un site de questions-réponses.** Les contributions des principales plateformes sont sous licence de partage à l'identique. Un extrait substantiel copié dans du code propriétaire pose, en théorie, une question de contamination. La pratique universelle est de l'ignorer pour quelques lignes triviales, et la doctrine considère qu'en deçà d'un seuil d'originalité il n'y a pas d'œuvre protégeable. Le risque devient réel pour une fonction entière recopiée. **Depuis un autre projet.** Le copier-coller d'une fonction depuis un projet sous copyleft crée une œuvre dérivée, sans qu'aucun gestionnaire de dépendances n'en garde trace. **Le code vendorisé.** Copier un composant dans votre arborescence plutôt que le déclarer en dépendance casse la traçabilité : il n'apparaît ni au manifeste, ni au SBOM produit depuis le manifeste. Il n'apparaît qu'à l'analyse de contenu. --- ### 5. Le code généré par intelligence artificielle Sujet ouvert, qu'il faut traiter comme tel plutôt que trancher. Les faits établis : les assistants de génération de code sont entraînés sur du code public, sous licences variées, dont du copyleft. Il est démontré qu'ils peuvent restituer des extraits substantiels quasi identiques à leur source, en particulier pour du code peu commun. Les questions ouvertes : le statut juridique de la sortie, la titularité des droits, la qualification d'œuvre dérivée, et la responsabilité en cas de reproduction. Aucune réponse jurisprudentielle stabilisée à ce jour en Europe. **Ce qui est raisonnable en attendant :** - activer les **filtres de correspondance** proposés par les outils, qui bloquent la restitution d'extraits identiques à du code public connu ; - **relire** le code généré pour les fonctions non triviales, comme on relit une contribution ; - **ne pas générer** de code dans les zones où une contamination serait irrattrapable — cœur cryptographique, composant destiné à être publié sous licence permissive ; - documenter la position retenue, pour ne pas avoir à l'improviser lors d'une diligence d'acquisition, où la question est désormais posée. --- ### 6. Les assets, ignorés par tous les outils Aucun scanner de dépendances ne regarde les polices, les icônes, les images, les sons, les modèles 3D ou les jeux de données. Ils sont pourtant à l'origine de problèmes très concrets, parce que leurs licences sont souvent **plus restrictives** que celles du code. | Asset | Piège | | --- | --- | | **Polices** | `OFL-1.1` : clause de nom réservé, le sous-ensemblage est une modification. Polices commerciales : licences par domaine ou par nombre de pages vues | | **Icônes** | `CC-BY-NC` interdit dans un produit vendu ; `CC-BY` impose une attribution rarement faite | | **Images** | Banques d'images : licence par usage, souvent non transférable au client | | **Sons** | Mêmes règles, plus les droits voisins | | **Jeux de données** | `ODbL` : copyleft sur les bases dérivées. Décisif pour un produit d'apprentissage automatique | | **Modèles pré-entraînés** | Licences propres, parfois avec restrictions d'usage — famille dite « responsable » | **Ce qu'il faut faire :** tenir un **inventaire des assets** distinct du SBOM logiciel, avec la source, la licence, la preuve d'acquisition et le périmètre d'usage concédé. Personne ne le fait spontanément ; c'est pourtant le premier endroit où un audit trouve quelque chose. --- ### 7. Les incompatibilités mutuelles Deux licences peuvent être libres toutes les deux et impossibles à combiner. Les combinaisons à connaître : | Combinaison | Statut | | --- | --- | | `Apache-2.0` + `GPL-2.0-only` | **Incompatible** selon la position de la FSF | | `Apache-2.0` + `GPL-3.0` | Compatible | | `CDDL-1.0` + `GPL-2.0` | **Incompatible** — c'est l'origine du problème ZFS sous Linux | | `GPL-2.0-only` + `GPL-3.0-only` | **Incompatible** entre elles | | `GPL-2.0-or-later` + `GPL-3.0` | Compatible, par bascule en v3 | | `BSD-4-Clause` + `GPL` | **Incompatible** — clause de publicité | | `EPL-1.0` + `GPL` | **Incompatible** ; l'EPL-2.0 le résout par une clause optionnelle | | Deux copylefts forts différents | Généralement incompatibles entre eux | Une incompatibilité ne se contourne pas : elle rend la **distribution** de l'œuvre combinée impossible. Elle se détecte tôt, ou elle se paie en réécriture. --- ### 8. Les clauses de brevets et leur effet en retour Apache-2.0, GPL-3.0, MPL-2.0 et EPL-2.0 comportent une concession de brevets **assortie d'une résiliation** : engager une action en contrefaçon de brevet contre un contributeur au sujet de ce logiciel fait perdre la concession, et parfois la licence entière. Pour une entreprise détentrice d'un portefeuille de brevets, c'est un sujet de direction juridique et non d'équipe technique : une stratégie contentieuse peut être neutralisée par le choix d'une bibliothèque fait trois ans plus tôt par un développeur. --- ### 9. Le CLA absent Sans accord de licence de contributeur ni certificat d'origine, chaque contributeur externe conserve ses droits. Conséquences pour un projet que vous publiez : - **relicenciement impossible** sans le consentement de chacun ; - **double licence commerciale impossible** ; - **action en contrefaçon difficile** contre un tiers qui violerait votre licence, faute de détenir tous les droits. À trancher **avant** la première contribution externe. Voir [Bibliothèque / SDK](/fr/licences/scenarios/bibliotheque-sdk/). --- ### 10. Les fausses licences libres Des textes qui ressemblent à des licences libres sans en être : | Texte | Problème | | --- | --- | | **Commons Clause** | Un **avenant** greffé sur une licence libre, qui en retire le droit de vendre. « MIT + Commons Clause » n'est pas MIT | | **JSON License** | Contient la clause « le logiciel sera utilisé pour le Bien, pas pour le Mal » : ambiguë, non libre en pratique, plusieurs fondations l'interdisent | | Licences « maison » | Rédigées par l'auteur, non revues, à l'interprétation imprévisible. À traiter comme du propriétaire | | Licences « éthiques » | Restrictions d'usage selon la finalité. Sortent de la définition du libre et posent un problème d'appréciation permanent | --- ### Ce que ces dix pièges ont en commun Aucun n'est détecté par un scanner de dépendances lisant les manifestes. Tous exigent soit une **analyse du contenu des fichiers**, soit une **surveillance dans le temps**, soit une **décision de gouvernance**. C'est la raison pour laquelle la conformité aux licences ne se réduit pas à un outil : elle suppose une politique, un registre, une veille et un propriétaire nommé — voir [Propriété intellectuelle](/fr/legal/propriete-intellectuelle/). ## Neuf scénarios de distribution URL: https://cra-reference.eu/fr/licences/scenarios/ Description: Le même composant, neuf contextes : ce qui change, ce qui se déclenche, et le verdict par famille de licences pour chaque type de produit. Audience: transverse Published 2026-08-20, updated 2026-08-20 Chaque page suit la même trame : **ce qui se passe réellement** (y a-t-il distribution ? interaction réseau ? liaison ?), **le verdict par famille**, **les pièges propres au scénario**, et **ce que le CRA y ajoute**. ### Les trois questions qui classent un scénario Avant de chercher votre cas dans la liste, répondez à ces trois questions : elles suffisent à prédire l'essentiel. | Question | Si oui | Si non | | --- | --- | --- | | **Un tiers reçoit-il le logiciel** sous une forme exécutable ? | Le copyleft se déclenche | La GPL est sans effet | | **Un tiers interagit-il avec lui par un réseau** ? | Le copyleft réseau se déclenche | L'AGPL est sans effet | | **L'utilisateur peut-il remplacer le composant** par une version modifiée ? | La LGPL est satisfaite | La LGPL impose de le rendre possible | Le détail de ces mécanismes est dans [Ce qui déclenche une obligation](/fr/licences/mecanismes/). ### Le classement des neuf scénarios Du plus permissif au plus contraint : **[Cas général](/fr/licences/scenarios/cas-general/)** vient en premier parce que ce n'est pas un produit : c'est la **posture par défaut**, celle qu'on applique tant qu'on ne sait pas encore où le composant finira — et celle qui doit gouverner une bibliothèque de base réutilisée partout. Les huit autres sont classés du **moins au plus contraint** : | Rang | Scénario | Ce qui le caractérise | | --- | --- | --- | | 1 | [Outil interne](/fr/licences/scenarios/outil-interne/) | Aucune distribution — presque tout est permis | | 2 | [Backend SaaS](/fr/licences/scenarios/saas-backend/) | Pas de distribution, mais exposition réseau | | 3 | [Bibliothèque / SDK](/fr/licences/scenarios/bibliotheque-sdk/) | Vous êtes l'amont : votre licence contraint vos utilisateurs | | 4 | [Application bureau / CLI](/fr/licences/scenarios/application-bureau/) | Distribution binaire classique | | 5 | [On-premise](/fr/licences/scenarios/on-premise/) | Distribution complète, système d'exploitation compris | | 6 | [Frontend web](/fr/licences/scenarios/frontend-web/) | Distribution de code source, presque toujours ignorée | | 7 | [Application mobile](/fr/licences/scenarios/application-mobile/) | Distribution + conditions de magasin restrictives | | 8 | [Embarqué / IoT](/fr/licences/scenarios/embarque-iot/) | Distribution + verrouillage matériel | ### Un produit relève souvent de plusieurs scénarios C'est le piège d'application le plus fréquent. Un même produit combine : - un **backend SaaS**, qui ne distribue rien ; - un **frontend web**, qui distribue du code à chaque visiteur ; - une **application mobile**, soumise aux conditions des magasins ; - un **agent** installé chez le client, qui est une distribution binaire ; - une **image de conteneur** publiée sur un registre, qui est aussi une distribution ; - une éventuelle édition **on-premise**. Chaque brique doit être évaluée dans son propre scénario, avec sa propre liste de licences autorisées. Un composant acceptable dans le backend peut être interdit dans l'agent, et la politique de licences doit le refléter — voir [Propriété intellectuelle](/fr/legal/propriete-intellectuelle/), qui décline vos listes par contexte d'usage. > **La règle de la brique la plus contrainte.** Si le même dépôt sert à construire le backend > et l'agent installé chez le client, c'est le régime de l'agent qui s'applique à tout le > dépôt. Séparer les dépôts est parfois la seule façon de conserver une liberté de choix sur > les composants du backend. ## Application bureau ou ligne de commande URL: https://cra-reference.eu/fr/licences/scenarios/application-bureau/ Description: La distribution binaire classique — le cas d'école pour lequel la GPL a été écrite. Contraignant mais praticable, à condition de préparer la fourniture du source. Audience: cyber Published 2026-08-20, updated 2026-08-20 Un exécutable téléchargé et installé par l'utilisateur, sur Windows, macOS ou Linux. Outil en ligne de commande, application graphique, installeur. ### Ce qui se passe réellement | Question | Réponse | | --- | --- | | Un tiers reçoit-il le logiciel sous forme exécutable ? | **Oui** — c'est la définition du scénario | | Un tiers interagit-il avec lui par un réseau ? | Non, sauf composant serveur embarqué | | Le produit est-il un bien de consommation verrouillé ? | Généralement **non** : l'utilisateur contrôle sa machine | | Le composant est-il lié à votre code ? | Souvent, et le mode de liaison est le choix retenu | C'est le scénario pour lequel la GPL a été écrite. Les obligations sont pleines, mais elles sont **connues, bornées et outillables**. ### Le verdict par famille | Famille | Verdict | Raison | | --- | :--: | --- | | Permissive | ● | Attribution due, à livrer avec le produit | | Copyleft faible fichier (MPL, EPL) | ● | Publier les fichiers modifiés, votre code reste privé | | Copyleft faible bibliothèque (LGPL) | ◐ | Praticable en **liaison dynamique** ; coûteux en statique | | Copyleft fort (GPL) | ◐ | Obligation pleine de fournir le source de l'œuvre distribuée. Possible si assumé | | Copyleft réseau (AGPL) | ○ | Se comporte comme la GPL ici ; l'article 13 s'y ajoute si l'application expose un service | | Source-available | ✕ | Restrictions d'usage incompatibles avec une distribution large | ### La liaison dynamique, décision d'architecture C'est le levier principal de ce scénario. En liaison dynamique, la LGPL est satisfaite sans rien de plus : l'utilisateur peut remplacer la bibliothèque partagée. | Plateforme | Liaison dynamique | | --- | --- | | Linux | Naturelle — `.so`, dépendances de paquets | | Windows | Naturelle — `.dll` | | macOS | Naturelle — `.dylib`, mais la **signature de code et la notarisation** compliquent le remplacement | | Binaire Go, Rust, application « portable » | **Impossible en pratique** : tout est statique | Le dernier cas est important : distribuer un binaire Go statique contenant une bibliothèque LGPL revient à devoir fournir les fichiers objets permettant de relier. Peu d'équipes le font, et c'est une non-conformité silencieuse. ### Ce que « fournir le source » veut dire concrètement Pour un composant GPL distribué, le **code source correspondant** comprend : - le code source de l'œuvre, y compris vos modifications ; - les **scripts de compilation et d'installation** ; - les fichiers de définition d'interface, les scripts de génération ; - tout ce qui est nécessaire pour **régénérer et installer** l'exécutable. Deux modalités possibles : | Modalité | Contrainte | | --- | --- | | Fournir le source **avec** le binaire | Le plus simple : une archive à côté du téléchargement | | Fournir une **offre écrite** de fourniture du source | GPL-2.0 : valable **trois ans** après la dernière distribution ; GPL-3.0 : au moins la durée de fourniture des pièces détachées | L'offre écrite paraît plus légère, mais elle crée une obligation d'archivage longue durée : il faut pouvoir régénérer, trois ans après, la version exacte livrée. C'est exactement le même problème que la [période de support](/fr/cra/support-et-cycle-de-vie/) du CRA — et donc la même solution. ### Les pièges de ce scénario **L'installeur qui empaquette des bibliothèques tierces.** Chaque composant conserve sa licence. Un installeur n'est pas une œuvre unique : c'est le plus souvent une [simple agrégation](/fr/licences/mecanismes/), ce qui est une bonne nouvelle — mais chaque composant garde ses obligations propres. **Le fichier d'attributions introuvable.** Sur un poste de travail, l'attribution doit être accessible à l'utilisateur : boîte « À propos », fichier livré, entrée de menu. Un fichier `NOTICE` au fond d'une archive n'est pas une mise à disposition sérieuse. **Le composant appelé en sous-processus.** Invoquer un exécutable GPL depuis votre application ne crée généralement pas d'œuvre dérivée — mais si vous le **distribuez** avec votre produit, vous distribuez du GPL et l'obligation de source s'applique à ce composant. **Les mises à jour.** Chaque nouvelle version distribuée est une nouvelle distribution, avec ses propres obligations. Le source correspondant doit suivre les versions. **macOS et la notarisation.** La signature obligatoire ne pose pas de problème de GPL-3.0 sur un ordinateur généraliste — il ne s'agit pas d'un « produit de consommation » verrouillé au sens de l'article 6, puisque l'utilisateur peut désactiver les contrôles. La question se pose en revanche pour du matériel dédié. ### Ce que le CRA ajoute Une application distribuée est un **produit comportant des éléments numériques** de plein exercice : dossier technique, SBOM, période de support, marquage CE, divulgation coordonnée. Le recoupement heureux : le **code source correspondant** à conserver pour la GPL et la **capacité de reconstruire** exigée par la période de support sont le même artefact. Un dispositif d'archivage bien conçu sert les deux — voir [Conservation des preuves](/fr/legal/conservation-des-preuves/). ## Application mobile URL: https://cra-reference.eu/fr/licences/scenarios/application-mobile/ Description: Distribution binaire plus conditions de magasin : le seul scénario où une licence libre peut être purement et simplement incompatible avec le canal de distribution. Audience: legal Published 2026-08-20, updated 2026-08-20 Application distribuée par un magasin d'applications — App Store, Google Play, magasins alternatifs, distribution d'entreprise. ### Ce qui se passe réellement | Question | Réponse | | --- | --- | | Un tiers reçoit-il le logiciel sous forme exécutable ? | **Oui** | | Le produit est-il un bien de consommation ? | **Oui** | | L'utilisateur peut-il installer une version modifiée ? | **Non** sur iOS, difficilement sur Android | | Un intermédiaire impose-t-il ses propres conditions ? | **Oui — et c'est la particularité du scénario** | C'est le seul scénario où la difficulté ne vient pas seulement de la licence, mais du **conflit entre la licence et les conditions du canal de distribution**. ### Le verdict par famille | Famille | Verdict | Raison | | --- | :--: | --- | | Permissive | ● | Attribution due, à rendre accessible depuis l'application | | Copyleft faible fichier (MPL, EPL) | ● | Praticable : réciprocité limitée aux fichiers modifiés | | Copyleft faible bibliothèque (LGPL) | ○ | La condition de remplacement est inatteignable sur un magasin | | **Copyleft fort (GPL)** | **✕** | **Conflit avec les conditions de magasin** — voir ci-dessous | | Copyleft réseau (AGPL) | ✕ | Idem, aggravé | | Source-available | ✕ | Restrictions incompatibles avec une distribution publique | ### Le conflit GPL / magasin d'applications Le mécanisme est le suivant. La GPL interdit d'imposer aux destinataires **des restrictions supplémentaires** au-delà de celles de la licence — GPL-2.0 article 6, GPL-3.0 article 10. Or les conditions d'utilisation des magasins imposent précisément de telles restrictions : limitation du nombre d'appareils sur lesquels l'application peut être installée, interdiction de redistribution, gestion des droits numériques. **Distribuer une application contenant du code GPL via un magasin qui impose ces restrictions place donc le distributeur en violation de la licence.** Le précédent est connu : **VLC** a été retiré de l'App Store en 2011 à la suite d'une notification d'un contributeur, puis republié après relicenciement d'une partie du code en LGPL puis MPL. L'affaire n'a pas été tranchée par un juge — c'est un précédent de fait, pas de droit, mais il structure la pratique du secteur depuis. **GPL-3.0 aggrave le conflit** de deux façons : - l'**anti-verrouillage** de l'article 6 exige de fournir de quoi installer une version modifiée sur le produit — impossible face à la signature de code obligatoire d'iOS ; - la **clause anti-DRM** de l'article 3 s'oppose frontalement au modèle de distribution des magasins. ### La LGPL sur mobile Théoriquement possible, pratiquement très difficile. La LGPL exige que l'utilisateur puisse remplacer la bibliothèque par sa propre version et faire fonctionner l'application avec. | Plateforme | Obstacle | | --- | --- | | iOS | Le paquet est signé ; toute modification invalide la signature et empêche l'exécution | | Android | Techniquement plus ouvert, mais le paquet publié sur le magasin est signé, et le remplacement suppose de recompiler | La voie parfois retenue — fournir les fichiers objets permettant de relier, et documenter la procédure — est lourde et rarement mise en œuvre correctement. Elle suppose un avis juridique et une décision assumée. ### Ce qui reste praticable | Famille | Comment | | --- | --- | | **Permissive** | Sans réserve. C'est le socle de l'écosystème mobile | | **MPL-2.0** | Réciprocité par fichier, sans contrainte de liaison : la relicence de VLC vers MPL est exactement ce mouvement | | **Apache-2.0** | Recommandée : permissive **et** protection brevets, ce qui compte sur un marché où le contentieux brevets est actif | ### Les pièges de ce scénario **Les SDK tiers.** Publicité, analytique, paiement, notifications, cartographie : ils arrivent avec des licences propriétaires, souvent assorties d'obligations d'affichage, de clauses de données personnelles et de restrictions d'usage. Ils sont rarement dans le SBOM, et jamais dans la revue de licences. **L'attribution introuvable.** L'obligation d'attribution des licences permissives suppose un écran accessible depuis l'application. Les deux plateformes fournissent un emplacement standard pour cela ; il faut l'alimenter, automatiquement, depuis le SBOM. **Les bibliothèques natives.** Un module natif compilé emporte les licences de ses dépendances C ou C++, invisibles dans le gestionnaire de paquets mobile. **Le partage de code avec le web.** Un frontend et une application mobile qui partagent une base de code partagent aussi ses composants — mais **pas** les mêmes contraintes. C'est le régime le plus strict qui s'applique au code partagé. **La distribution d'entreprise.** Diffuser une application en interne à ses propres salariés n'est pas une distribution à des tiers ; les conditions du magasin ne s'appliquent pas non plus. Le régime se rapproche de l'[outil interne](/fr/licences/scenarios/outil-interne/). ### Ce que le CRA ajoute Une application mobile est un produit comportant des éléments numériques. Deux points méritent attention : - **la classification** : une application de suivi de santé, un assistant domotique, un gestionnaire de mots de passe relèvent de l'**annexe III, partie I** — classe I, avec la contrainte d'évaluation qui s'y attache. Voir [Les classes de criticité](/fr/cra/classes-de-criticite/) ; - **la période de support** doit tenir malgré les cycles imposés par les plateformes, qui obligent à recompiler régulièrement pour rester publiable. Un produit encore supporté mais devenu impubliable est une situation à anticiper contractuellement. ## Bibliothèque ou SDK que vous publiez URL: https://cra-reference.eu/fr/licences/scenarios/bibliotheque-sdk/ Description: Ici vous êtes l'amont : vos dépendances contraignent votre licence, et votre licence contraint vos utilisateurs. La contamination remonte et descend. Audience: legal Legal basis: Art. 3, point 1 — composants mis sur le marché séparément Published 2026-08-20, updated 2026-08-20 Inversion de perspective : vous ne êtes plus le consommateur mais le fournisseur. Deux contraintes se répondent. ### Ce qui se passe réellement | Question | Réponse | | --- | --- | | Un tiers reçoit-il le logiciel sous forme exécutable ? | **Oui**, et sous forme source le plus souvent | | Votre licence contraint-elle vos utilisateurs ? | **Oui — c'est le point central** | | Vos dépendances contraignent-elles votre licence ? | **Oui** | ### La règle qui gouverne tout > **On ne peut pas publier sous une licence plus permissive que la plus restrictive de ses > dépendances.** Une bibliothèque qui embarque un composant GPL ne peut pas être publiée sous MIT. La licence que vous affichez doit être **compatible en aval** avec tout ce que vous incluez. Corollaire : la composition de vos dépendances est une **décision de produit**, pas une décision technique. Ajouter une dépendance LGPL à un SDK permissif transfère une contrainte d'ingénierie à tous vos utilisateurs, souvent sans qu'ils s'en aperçoivent. ### Le verdict pour vos dépendances | Famille de la dépendance | Verdict | Effet sur votre publication | | --- | :--: | --- | | Permissive | ● | Aucun. Vous restez libres de votre licence | | Copyleft faible fichier (MPL) | ◐ | Vos fichiers restent libres ; les fichiers MPL modifiés doivent être publiés | | Copyleft faible bibliothèque (LGPL) | ○ | Vos utilisateurs héritent de la contrainte de remplacement, souvent à leur insu | | Copyleft fort (GPL) | ○ | Votre bibliothèque devient GPL. Choix légitime, mais qui doit être délibéré | | Copyleft réseau (AGPL) | ○ | Votre bibliothèque devient AGPL, ce qui la rend inutilisable par la plupart des intégrateurs | | Source-available | ✕ | Vous ne pouvez pas redistribuer | ### Le choix de votre propre licence C'est une décision commerciale autant que juridique. | Votre licence | Qui peut vous intégrer | Ce que vous en retirez | | --- | --- | --- | | **Apache-2.0** | Tout le monde | Adoption maximale, et protection brevets pour vous comme pour eux. Le choix par défaut d'un SDK destiné à être adopté | | **MIT** | Tout le monde | Adoption maximale, aucune protection brevets | | **MPL-2.0** | Tout le monde, avec réciprocité par fichier | Les améliorations de votre code vous reviennent, sans bloquer l'intégration | | **LGPL** | Tout le monde, avec contrainte de liaison | Réciprocité forte, mais exclut de fait l'embarqué et le mobile | | **GPL / AGPL** | Uniquement les projets libres | Modèle de **double licence** : gratuit pour le libre, payant pour le propriétaire | | **BSL / source-available** | Selon les restrictions | Protection contre la revente en service managé, au prix de la sortie du libre | Le modèle de la **double licence** — GPL ou AGPL d'un côté, licence commerciale de l'autre — suppose de détenir l'intégralité des droits sur le code. Ce qui conduit au point suivant. ### Le CLA, sujet à traiter avant la première contribution externe Sans **accord de licence de contributeur** (CLA) ou, a minima, sans **DCO**, chaque contributeur conserve ses droits sur sa contribution. Conséquences : - **impossible de relicencier** plus tard sans le consentement de chacun ; - **impossible de proposer une licence commerciale** sur du code que vous ne détenez pas entièrement ; - **difficile de faire appliquer** la licence en cas de violation par un tiers, faute de détenir tous les droits. C'est une décision à prendre **avant** d'accepter la première contribution externe. La rattraper après suppose de retrouver chaque contributeur, ou de réécrire sa contribution. ### Les pièges de ce scénario **La dépendance transitive invisible.** Votre SDK est Apache-2.0, mais il tire une dépendance LGPL. Vos utilisateurs héritent de la contrainte de liaison sans que rien ne le leur signale. La parade : publier votre propre SBOM avec le SDK, et documenter explicitement les licences transitives à obligations. **Les licences imbriquées dans un dépôt.** Un dépôt annoncé MIT dont un sous-dossier `vendor/` est GPL. Votre déclaration de licence devient inexacte. **Le code d'exemple.** Les extraits que vous publiez dans la documentation sont réutilisés tels quels par vos utilisateurs. S'ils ne portent pas de licence explicite, leur statut est incertain — préciser qu'ils sont sous la même licence, ou sous une licence plus permissive. **Les fichiers générés.** Un SDK généré depuis une spécification d'interface hérite parfois de la licence du générateur. Vérifier ce que dit le générateur sur la sortie qu'il produit — les exceptions du type `Autoconf-exception` existent précisément pour cela. **La marque.** Aucune licence libre ne concède de droits sur la marque. Un utilisateur peut forker votre code, il ne peut pas l'appeler comme vous. ### Ce que le CRA ajoute Beaucoup, et c'est souvent ignoré : **une bibliothèque mise sur le marché séparément est un produit comportant des éléments numériques à part entière** (art. 3, point 1). Elle a donc, pour elle-même : son dossier technique, son SBOM, sa période de support, sa politique de divulgation coordonnée, son marquage CE. Sauf si elle est mise à disposition **hors activité commerciale**, auquel cas elle sort du champ — voir [Le logiciel libre](/fr/cra/open-source/). La frontière est celle du caractère commercial, pas celle de la licence : publier un SDK sous Apache-2.0 en accompagnement d'une offre payante reste une activité commerciale. ## Cas général — hypothèse la plus défavorable URL: https://cra-reference.eu/fr/licences/scenarios/cas-general/ Description: La posture à adopter quand on ne sait pas encore comment le composant sera distribué : supposer la distribution binaire, l'exposition réseau et le produit de consommation. Audience: transverse Published 2026-08-20, updated 2026-08-20 Ce n'est pas un produit, c'est une **posture par défaut**. Elle s'applique dans trois situations : - une équipe veut adopter un composant et **ne sait pas encore** dans quels produits il finira ; - le composant entre dans une **bibliothèque interne partagée**, réutilisée par plusieurs produits relevant de scénarios différents ; - on instruit une **politique de licences d'entreprise**, applicable avant de connaître les cas d'usage. ### L'hypothèse retenue On suppose le pire de manière cumulative : | Question | Hypothèse par défaut | | --- | --- | | Un tiers reçoit-il le logiciel sous forme exécutable ? | **Oui** | | Un tiers interagit-il avec lui par un réseau ? | **Oui** | | Le produit est-il un bien de consommation verrouillé ? | **Oui** | | Le composant est-il lié à votre code ? | **Oui, statiquement** | Sous ces hypothèses, tous les mécanismes de [déclenchement](/fr/licences/mecanismes/) sont actifs simultanément. ### Le verdict par famille | Famille | Verdict | Raison | | --- | :--: | --- | | Domaine public | ● | Aucune obligation, hors question de brevets pour CC0 | | Permissive | ● | Attribution seule, coût nul si automatisée | | Copyleft faible fichier (MPL, EPL) | ◐ | Acceptable si la discipline de séparation des fichiers est tenue | | Copyleft faible bibliothèque (LGPL) | ○ | La liaison statique supposée impose de fournir les objets ; en v3, l'anti-verrouillage s'ajoute | | Copyleft fort (GPL) | ○ | Publication du source de l'œuvre entière, et anti-verrouillage en v3 | | Copyleft réseau (AGPL) | ✕ | Déclenchée par l'hypothèse d'exposition réseau | | Source-available (BSL, SSPL, ELv2) | ✕ | Restrictions d'usage incompatibles avec un produit vendu | | Contenu non commercial (CC-BY-NC, CC-BY-ND) | ✕ | Interdit dans un produit commercial | ### Comment s'en servir Cette grille est celle qui doit alimenter la **liste blanche par défaut** de la politique de licences : un composant en liste blanche ici est utilisable partout, sans instruction supplémentaire. C'est ce qui permet aux équipes d'avancer sans solliciter le juridique à chaque dépendance. Les composants **◐** et **○** ne sont pas interdits : ils passent par le [processus d'exception](/fr/legal/propriete-intellectuelle/), qui exige de nommer le scénario réel et de vérifier que la contrainte y est tenable. > **Le raisonnement à ne pas faire.** « Ce composant est GPL mais votre produit est un SaaS, > donc c'est bon. » C'est exact aujourd'hui, et faux le jour où l'on livre un agent, un > connecteur, une édition on-premise ou une image publiée sur un registre public. Si le > composant entre dans un dépôt partagé, c'est l'hypothèse la plus défavorable des produits > qui en dérivent qui doit s'appliquer. ### La question qui fait basculer un dossier **Ce dépôt sert-il à construire un seul artefact, ou plusieurs ?** Un dépôt qui produit à la fois le backend et l'agent client hérite du régime de l'agent — le plus contraint. La séparation des dépôts n'est pas un raffinement d'organisation : c'est souvent la seule façon de conserver une liberté de choix sur les composants du backend. ### Ce que le CRA ajoute Rien, directement — le règlement ne traite pas des licences. Mais la [diligence sur les composants tiers](/fr/cra/open-source/integrer-de-l-oss/) qu'il impose comporte un examen de la licence, et cet examen n'a de sens que rapporté à un scénario. Une grille de diligence qui note la licence sans dire dans quel produit le composant ira ne démontre rien. ## Embarqué et objets connectés URL: https://cra-reference.eu/fr/licences/scenarios/embarque-iot/ Description: Le scénario le plus contraint, et le seul où une exigence de licence entre en tension directe avec une exigence de sécurité du CRA : l'anti-verrouillage de la GPL-3.0 contre le démarrage vérifié. Audience: transverse Legal basis: Annexe I, partie I — protection de l'intégrité · Art. 13, paragraphe 5 — diligence sur les composants tiers Published 2026-08-20, updated 2026-08-20 Micrologiciel livré dans un appareil : routeur, caméra, automate, capteur, passerelle, équipement médical hors périmètre CRA, véhicule hors périmètre CRA. ### Ce qui se passe réellement | Question | Réponse | | --- | --- | | Un tiers reçoit-il le logiciel sous forme exécutable ? | **Oui**, intégré au matériel | | Le produit est-il un bien de consommation ? | **Souvent oui** — et c'est le point critique | | L'utilisateur peut-il installer une version modifiée ? | **Non**, par construction : démarrage vérifié, signature | | Le composant est-il lié à votre code ? | **Oui, statiquement**, presque toujours | | Quel volume de composants ? | Un système complet : noyau, `libc`, utilitaires, pile réseau | Tous les mécanismes de [déclenchement](/fr/licences/mecanismes/) sont actifs simultanément. C'est le scénario le plus contraint, et **c'est aussi celui où le contentieux réel est le plus concentré** : l'essentiel des affaires publiques de violation de la GPL, en Europe comme ailleurs, concerne des routeurs, des téléviseurs et des équipements réseau. ### Le verdict par famille | Famille | Verdict | Raison | | --- | :--: | --- | | Permissive | ● | Attribution due, à rendre accessible malgré l'absence d'écran | | Copyleft faible fichier (MPL, EPL) | ● | Réciprocité limitée, sans contrainte de liaison | | Copyleft faible bibliothèque (LGPL-2.1) | ○ | Liaison statique quasi systématique : fichiers objets à fournir | | Copyleft faible bibliothèque (LGPL-3.0) | ✕ | Ajoute l'anti-verrouillage de la v3 | | **Copyleft fort GPL-2.0** | **○** | Obligation pleine de source, mais **pas** d'anti-verrouillage. Praticable, et c'est le régime de Linux, BusyBox, U-Boot | | **Copyleft fort GPL-3.0** | **✕** | **Anti-verrouillage incompatible avec un appareil verrouillé** | | Copyleft réseau (AGPL) | ✕ | Cumul | | Source-available | ✕ | Restrictions incompatibles avec la vente d'un produit | ### Le conflit central : anti-verrouillage contre intégrité C'est le point le plus important de toute cette section. **La GPL-3.0, article 6**, impose, pour un produit de consommation, de fournir les **informations d'installation** : ce qu'il faut pour installer et exécuter une version modifiée du logiciel sur l'appareil. Si l'appareil refuse de démarrer un logiciel modifié par l'utilisateur, la licence n'est pas respectée. **Le CRA, annexe I, partie I**, impose de protéger l'**intégrité** des programmes et configurations contre toute modification non autorisée. La réponse d'ingénierie standard à cette exigence est le **démarrage vérifié** : l'appareil ne démarre que du code signé. Les deux exigences pointent en sens contraire. | | GPL-3.0, article 6 | CRA, annexe I | | --- | --- | --- | | Objectif | L'utilisateur garde le contrôle de son appareil | L'appareil résiste à la modification non autorisée | | Moyen | Fournir les clés ou la procédure d'installation | Refuser tout code non signé | #### Comment le secteur résout la tension Il n'existe pas de solution universelle. Quatre approches, par ordre de fréquence : 1. **Rester en GPL-2.0** pour les composants système. C'est la raison — rarement dite mais bien réelle — pour laquelle le noyau Linux, BusyBox et U-Boot demeurent en GPL-2.0-only. Cela suppose de refuser les composants qui ont migré en v3. 2. **Distinguer les niveaux de confiance** : un démarrage vérifié verrouillé pour la partie sécurité, et une partition applicative où l'utilisateur peut installer sa propre version. Techniquement propre, mais coûteux. 3. **Fournir les informations d'installation**, y compris une procédure de déverrouillage documentée, tout en conservant l'intégrité par défaut. C'est la lecture littérale de la licence, et elle est défendable au regard du CRA, qui exige la protection contre les modifications **non autorisées** — une modification faite par le propriétaire de l'appareil, selon une procédure documentée, est autorisée. 4. **Écarter la GPL-3.0** du produit, ce qui suppose une politique appliquée dès le choix du *board support package*. > **La lecture qui réconcilie les deux textes.** Le CRA protège contre les modifications *non > autorisées* ; il n'impose nulle part que le propriétaire légitime d'un appareil ne puisse > pas y installer son propre logiciel. Une procédure de déverrouillage explicite, volontaire, > et qui remet l'appareil dans un état signalé comme non conforme au support, satisfait les > deux exigences. C'est la position à instruire avec le conseil juridique **avant** de figer > l'architecture de démarrage, pas après. ### La liaison statique, systématique en embarqué Il n'y a généralement pas de chargeur dynamique. Toute bibliothèque LGPL est donc liée statiquement, ce qui impose de fournir les **fichiers objets** de l'application permettant à l'utilisateur de relier avec sa propre version de la bibliothèque. Peu de fabricants le font. C'est l'une des non-conformités les plus répandues du secteur, et l'une des plus faciles à établir pour un tiers qui analyse un micrologiciel. ### Le volume : un micrologiciel, c'est des milliers de composants | Composant type | Licence | | --- | --- | | Noyau Linux | `GPL-2.0-only` | | BusyBox | `GPL-2.0-only` | | U-Boot | `GPL-2.0-or-later` | | glibc | `LGPL-2.1-or-later` | | musl | `MIT` | | OpenSSL 3.x | `Apache-2.0` (les versions antérieures : double licence historique, incompatible GPL) | | Buildroot, Yocto | Recettes sous licences diverses, produisant des artefacts sous licences diverses | Une image de micrologiciel typique contient plusieurs milliers de paquets. Sans SBOM produit par la chaîne de construction, l'inventaire est impossible à établir a posteriori — et c'est exactement ce que le CRA rend obligatoire. ### Les pièges de ce scénario **Le BSP du fournisseur de puce.** Le *board support package* arrive sous forme d'archive, sans inventaire, avec des pilotes propriétaires, des blobs binaires et parfois du code GPL modifié sans que le source correspondant soit fourni. C'est le point le plus faible de la chaîne, et la [diligence](/fr/cra/open-source/integrer-de-l-oss/) exigée par le CRA impose désormais de le traiter — donc de l'exiger contractuellement du fournisseur. **Les blobs binaires.** Micrologiciels de puce Wi-Fi, de modem, de GPU : redistribuables sous conditions, souvent avec une licence propriétaire restrictive. À inventorier et à documenter. **L'attribution sans écran.** L'obligation d'attribution demeure sur un appareil sans interface. Les solutions usuelles : une page web servie par l'appareil, un fichier accessible par l'interface d'administration, la notice papier, ou une adresse internet imprimée sur le produit — cette dernière devant rester valide pendant toute la durée de vie de l'appareil. **L'offre écrite de dix ans.** L'obligation de fournir le source correspondant survit très longtemps : trois ans après la dernière distribution en GPL-2.0, davantage en GPL-3.0. Elle se superpose à la [période de support](/fr/cra/support-et-cycle-de-vie/) du CRA. Les deux imposent la même chose : conserver le source, la chaîne de compilation et la capacité de reconstruire, pendant une décennie. **La reprise de projet abandonné.** Un composant embarqué non maintenu dans un produit couvert par une période de support de dix ans est une dette double : sécurité et licence. ### Ce que le CRA ajoute Beaucoup, et pas seulement le conflit décrit plus haut : - **classification** : microprocesseurs et microcontrôleurs dotés de fonctionnalités de sécurité relèvent de la **classe I** ; s'ils sont **résistants à l'altération**, de la **classe II**, où l'auto-évaluation est exclue. Voir [Les classes de criticité](/fr/cra/classes-de-criticite/) ; - **période de support** : les cycles de vie matériels dépassent souvent dix ans, et les fournisseurs de composants ne suivent pas. Voir [Période de support](/fr/cra/support-et-cycle-de-vie/) ; - **SBOM du micrologiciel** : à produire par la chaîne de construction, pas par analyse a posteriori ; - **mises à jour sécurisées** : mécanisme de mise à jour signé, résistant à la coupure, avec protection contre le retour arrière — voir [Mises à jour sécurisées](/fr/cyber/mises-a-jour-securisees/), qui est le lieu où le conflit avec l'article 6 de la GPL-3.0 se matérialise techniquement. ## Frontend web URL: https://cra-reference.eu/fr/licences/scenarios/frontend-web/ Description: Le scénario le plus mal compris : servir du JavaScript à un navigateur est une distribution de code. Le bundler mélange tout, la minification efface les attributions. Audience: cyber Published 2026-08-20, updated 2026-08-20 Application web exécutée dans le navigateur : JavaScript, TypeScript compilé, WebAssembly, feuilles de style, polices, icônes. ### Ce qui se passe réellement | Question | Réponse | | --- | --- | | Un tiers reçoit-il le logiciel sous forme exécutable ? | **Oui — le navigateur télécharge et exécute le code** | | Un tiers interagit-il avec lui par un réseau ? | Oui, mais c'est secondaire ici | | Le composant est-il lié à votre code ? | **Oui, statiquement, dans un seul fichier** | > **Le point que presque tout le monde manque.** Un frontend web **distribue du code source** > à chaque visiteur. Ce n'est pas un service : c'est une livraison de logiciel, à des milliers > de destinataires anonymes, plusieurs fois par jour. > > Une équipe qui se dit « vous faites du SaaS, la GPL ne vous concerne pas » a raison pour son > backend et tort pour son frontend. C'est le **même produit**, mais **deux régimes opposés**. ### Le verdict par famille | Famille | Verdict | Raison | | --- | :--: | --- | | Permissive | ◐ | Autorisée, mais l'attribution survit mal au *bundling* : voir ci-dessous | | Copyleft faible fichier (MPL, EPL) | ◐ | Réciprocité par fichier, mais le *bundle* dissout la notion de fichier | | Copyleft faible bibliothèque (LGPL) | ○ | **La liaison dynamique n'existe pas dans un bundle** : traiter comme du copyleft fort | | Copyleft fort (GPL) | ✕ | Distribution avérée : le source de l'œuvre combinée est dû à chaque visiteur | | Copyleft réseau (AGPL) | ✕ | Cumul distribution + réseau | | Source-available | ✕ | Le code est de toute façon livré au client, ce que ces licences n'anticipent pas | | Contenu non commercial (CC-BY-NC) | ✕ | Fréquent sur les icônes et illustrations, et interdit dans un produit vendu | ### Pourquoi le bundler aggrave tout Dans une application native, la question de l'œuvre combinée se discute : liaison dynamique ? processus séparé ? interface stable ? Dans un frontend, **la discussion n'a pas lieu**. Le bundler prend votre code et celui des dépendances, applique un *tree-shaking*, renomme les symboles, inline les fonctions, et produit **un seul fichier**. Il n'y a plus de frontière observable entre votre code et le composant tiers. Conséquences : - l'argument « vous ne faites que lier dynamiquement » est **indisponible** ; - l'argument « ce sont des programmes séparés » est **indisponible** ; - un composant GPL dans le graphe de dépendances contamine, en pratique, l'artefact livré. La seule parade architecturale est l'**isolement réel** : charger le composant depuis une origine distincte, dans un `iframe` ou un `worker` séparé, sans partage de code. C'est lourd, et cela ne se décide pas après coup. ### L'attribution, problème n° 1 des permissives Les licences permissives exigent de conserver les mentions de copyright et de licence. La minification les supprime toutes. Ce qu'il faut mettre en place : | Mesure | Effet | | --- | --- | | Préservation des **bannières de licence** par le bundler | Conserve les blocs `/*! … */` marqués comme à préserver | | Génération d'un fichier **`licenses.txt`** à la construction | Depuis le SBOM, avec le texte complet des licences | | **Lien accessible** depuis l'application | Pied de page, page « Mentions légales », « À propos » | | Contrôle **bloquant en CI** | Échec de la construction si le fichier d'attributions n'est pas généré | Sans ces quatre mesures, un frontend moderne est en violation de dizaines de licences permissives simultanément. C'est le manquement le plus répandu du domaine, et le plus simple à corriger. ### Les pièges propres au frontend **Les cartes de source.** Publier les *source maps* en production expose votre code source, et révèle du même coup la composition exacte du *bundle*. C'est souvent ainsi qu'une violation est constatée par un tiers. **Les polices.** `OFL-1.1` autorise la redistribution mais comporte une **clause de nom réservé** : une police modifiée — sous-ensemble de glyphes, conversion de format, renommage — ne peut pas conserver son nom d'origine. Le sous-ensemblage de police, pratique courante d'optimisation, est une modification. **Les icônes et illustrations.** C'est là que se trouvent les vrais problèmes. `CC-BY-NC` interdit l'usage commercial ; `CC-BY-SA` impose le partage à l'identique de l'œuvre dérivée ; `CC-BY-ND` interdit le recadrage et la recoloration. Un jeu d'icônes récupéré sans vérification est un risque bien plus immédiat qu'une bibliothèque JavaScript. **Les dépendances de développement embarquées par erreur.** Un composant destiné aux tests qui se retrouve dans le *bundle* de production entre dans le périmètre distribué. **Les scripts tiers chargés depuis un CDN.** Ils ne sont pas distribués par vous — mais ils introduisent une dépendance externe qui pose d'autres questions, de sécurité cette fois. **WebAssembly.** Un module compilé depuis du C ou du Rust emporte les licences de ses dépendances natives, invisibles dans le graphe des paquets JavaScript. Le SBOM du frontend doit couvrir la chaîne de compilation WebAssembly. ### Ce que le CRA ajoute Le frontend fait partie du produit. Ses composants doivent figurer au **SBOM**, au même titre que ceux du backend — et c'est rarement le cas dans les dispositifs que l'on rencontre, où l'inventaire s'arrête souvent aux dépendances serveur. Les exigences de l'annexe I s'y appliquent aussi : minimisation des données, protection de l'intégrité, absence de vulnérabilité exploitable connue. Une dépendance JavaScript vulnérable livrée au navigateur est une vulnérabilité du produit. ## On-premise et auto-hébergé URL: https://cra-reference.eu/fr/licences/scenarios/on-premise/ Description: Distribution complète chez le client, souvent système d'exploitation compris. Le client obtient le droit de redistribuer ce que vous lui avez livré. Audience: legal Published 2026-08-20, updated 2026-08-20 Le logiciel est installé et exécuté sur l'infrastructure du client : appliance virtuelle, image machine, paquet d'installation, ensemble de conteneurs, cluster livré clés en main. ### Ce qui se passe réellement | Question | Réponse | | --- | --- | | Un tiers reçoit-il le logiciel sous forme exécutable ? | **Oui, intégralement** | | Un tiers interagit-il avec lui par un réseau ? | Oui, mais c'est **le client** qui devient l'opérateur | | Le produit est-il un bien de consommation ? | Non — client professionnel | | Que reçoit exactement le client ? | Souvent **tout un système**, système d'exploitation compris | C'est, avec l'embarqué, le scénario où le volume de composants distribués est le plus important — et de très loin. ### Le verdict par famille | Famille | Verdict | Raison | | --- | :--: | --- | | Permissive | ● | Attribution due pour l'ensemble de ce qui est livré | | Copyleft faible fichier (MPL, EPL) | ● | Publier les fichiers modifiés | | Copyleft faible bibliothèque (LGPL) | ◐ | Praticable si liaison dynamique ; en conteneur, souvent le cas | | Copyleft fort (GPL) | ◐ | Obligation pleine, y compris envers le client, qui peut ensuite redistribuer | | Copyleft réseau (AGPL) | ○ | Vous distribuez : les articles 4 et 5 s'appliquent. L'article 13 s'appliquera **au client**, ce qu'il faut lui dire | | Source-available | ✕ | Presque toutes interdisent la redistribution | ### Le point qui change tout : le client hérite de droits En recevant un binaire sous GPL, le client devient **titulaire des droits de la licence**. Il peut : - exiger le **code source correspondant**, y compris de vos modifications ; - le **redistribuer** à qui il veut, sous la même licence ; - **modifier** le composant et déployer sa version. Ce n'est pas théorique : c'est la voie par laquelle une violation devient publique. Un client mécontent, ou simplement curieux, demande le source. S'il ne l'obtient pas, il dispose d'un levier considérable — et, s'il est lui-même contributeur du projet amont, d'un intérêt à agir. > **La conséquence commerciale.** Sur du copyleft fort livré en on-premise, il n'y a pas de > secret de composition possible. Si le code combiné a une valeur concurrentielle, le > composant doit être isolé dans un processus séparé, ou remplacé. ### L'appliance : le piège de volume Livrer une image machine ou une image de conteneur complète, c'est distribuer **tout le système** : noyau, bibliothèque C, utilitaires, interpréteurs, gestionnaire de paquets. Des milliers de composants, très majoritairement sous GPL et LGPL. | Ce qu'on croit livrer | Ce qu'on livre réellement | | --- | --- | | Votre application | Votre application **plus** une distribution complète | | Une dizaine de dépendances | Plusieurs milliers de paquets | Bonne nouvelle : il s'agit très largement de [simple agrégation](/fr/licences/mecanismes/) — votre application n'est pas une œuvre dérivée du noyau. Mauvaise nouvelle : **chaque paquet agrégé conserve ses obligations**, dont l'attribution et, pour les composants GPL, la fourniture du source correspondant. La parade standard : partir d'une **image de base minimale**, et s'appuyer sur les archives de source que l'éditeur de la distribution met déjà à disposition, en les référençant explicitement — à condition de vérifier que cette mise à disposition couvre bien la version exacte livrée. ### Les pièges de ce scénario **L'offre écrite qui survit au contrat.** En GPL-2.0, l'offre de fourniture du source doit rester valable **trois ans** après la dernière distribution — indépendamment de la fin du contrat commercial, de la fin de vie du produit ou du départ de l'équipe. **Les correctifs livrés au coup par coup.** Chaque correctif transmis au client est une nouvelle distribution, avec ses obligations propres et son source correspondant. **La version modifiée pour un client.** Un développement spécifique livré à un seul client reste une distribution. Le fait qu'il n'y ait qu'un destinataire ne change rien. **Le client qui redistribue.** Rien ne l'en empêche pour les composants sous copyleft. Vos conditions contractuelles peuvent l'interdire pour *votre* code, pas pour le code tiers sous licence libre. **La double casquette AGPL.** Vous distribuez, donc vous devez fournir le source. Le client exploite un service réseau, donc l'article 13 s'appliquera à lui s'il modifie. Cela mérite d'être écrit dans la documentation, sous peine de créer chez lui une non-conformité qu'il n'avait pas vue. ### Ce que le CRA ajoute Le scénario le plus lourd du point de vue réglementaire aussi. Le produit est mis sur le marché, avec toutes les obligations qui s'ensuivent, et deux difficultés propres : - **le SBOM doit couvrir tout ce qui est livré**, image de base comprise. Un SBOM applicatif qui ignore les milliers de paquets du système sous-jacent est incomplet — voir [Qualité et complétude](/fr/sbom/qualite-et-completude/) ; - **la période de support** porte sur l'ensemble : corriger une vulnérabilité de la bibliothèque C livrée dans votre appliance vous incombe, pendant cinq à dix ans. C'est la raison technique pour laquelle les images minimales ne sont pas seulement une bonne pratique de sécurité : elles réduisent directement le périmètre de vos obligations, sur les deux terrains à la fois. ## Outil interne URL: https://cra-reference.eu/fr/licences/scenarios/outil-interne/ Description: Aucune distribution, donc presque aucune obligation — et le seul vrai risque : la frontière interne/externe qui bouge sans que personne ne rouvre le dossier. Audience: cyber Published 2026-08-20, updated 2026-08-20 Outillage de développement, tableaux de bord, scripts d'exploitation, applications métier utilisées uniquement par les salariés. ### Ce qui se passe réellement | Question | Réponse | | --- | --- | | Un tiers reçoit-il le logiciel sous forme exécutable ? | **Non** | | Un tiers interagit-il avec lui par un réseau ? | Non — les salariés ne sont pas des tiers | | Le produit est-il un bien de consommation ? | Non | Aucun mécanisme de copyleft ne se déclenche. C'est le scénario le plus libre. ### Le verdict par famille | Famille | Verdict | Raison | | --- | :--: | --- | | Permissive | ● | Attribution non due faute de distribution, mais bonne pratique de créditer | | Copyleft faible (MPL, EPL, LGPL) | ● | Pas de distribution, pas de réciprocité | | Copyleft fort (GPL) | ● | **La GPL ne se déclenche qu'à la distribution** | | Copyleft réseau (AGPL) | ◐ | Voir ci-dessous | | Source-available (BSL, SSPL, ELv2) | ◐ | Lire les restrictions : certaines visent l'usage, pas seulement la revente | ### Le cas de l'AGPL L'article 13 vise « tous les utilisateurs qui interagissent à distance par un réseau ». Rien n'exclut les salariés. Une lecture stricte impose donc, pour un outil interne AGPL modifié, d'**offrir le code source aux utilisateurs internes**. En pratique c'est indolore : publier le source sur le dépôt interne suffit. Mais l'obligation existe, et elle mérite d'être connue plutôt que découverte. ### Les licences source-available Contrairement au copyleft, elles restreignent parfois l'**usage lui-même**, sans qu'il y ait distribution : - une **BSL-1.1** interdit typiquement l'usage en production au-delà de la concession additionnelle accordée par l'éditeur ; - une **Elastic License 2.0** interdit de fournir le produit en service managé, ce qui peut couvrir une plateforme interne mutualisée entre filiales ; - **Commons Clause** retire le droit de vendre, mais pas celui d'utiliser. Il faut donc les lire, alors même que le scénario est le plus permissif de tous. ### Le seul vrai risque : la frontière bouge C'est la totalité du risque de ce scénario, et il est réel. | Événement | Effet | | --- | --- | | L'outil interne devient un **produit** | Tous les mécanismes se réveillent d'un coup | | L'outil est déployé chez un **client** ou un partenaire | Distribution | | L'outil est transmis à une **filiale**, personne morale distincte | **Distribution** — une filiale est un tiers | | Un **prestataire** externe reçoit le binaire | Distribution | | L'image de conteneur est publiée sur un **registre public** | Distribution | | L'outil est ouvert à des **utilisateurs externes**, même gratuitement | L'AGPL se déclenche | Le point sur la filiale surprend souvent : la distribution intra-groupe entre deux personnes morales distinctes **est** une distribution au sens des licences libres. La consolidation comptable n'a aucun effet ici. > **La recommandation.** Appliquer malgré tout la politique de licences aux outils internes, > au moins en mode avertissement. Non pas parce que l'obligation existe aujourd'hui, mais > pour que la promotion en produit ne se heurte pas, deux ans plus tard, à un composant > impossible à retirer. ### Ce que le CRA ajoute Un outil interne n'est **pas** un produit comportant des éléments numériques : il n'est pas mis sur le marché. Il sort du champ du règlement — voir [Le périmètre](/fr/cra/perimetre-pde/). Cela ne signifie pas qu'il échappe à toute exigence : les outils de la chaîne de construction participent à la sécurité des produits que vous mettez sur le marché, et relèvent à ce titre de la [maîtrise de la chaîne d'approvisionnement](/fr/cyber/risques-supply-chain/). ## Backend SaaS URL: https://cra-reference.eu/fr/licences/scenarios/saas-backend/ Description: Pas de distribution, donc la GPL est sans effet — et l'AGPL devient le risque numéro un. Le scénario où les intuitions sont le plus souvent fausses, dans les deux sens. Audience: transverse Published 2026-08-20, updated 2026-08-20 Le code s'exécute sur vos serveurs. L'utilisateur reçoit des réponses, pas des binaires. ### Ce qui se passe réellement | Question | Réponse | | --- | --- | | Un tiers reçoit-il le logiciel sous forme exécutable ? | **Non** | | Un tiers interagit-il avec lui par un réseau ? | **Oui** | | Le produit est-il un bien de consommation ? | Non | Un seul mécanisme est actif, mais il est décisif : l'**interaction réseau**. ### Le verdict par famille | Famille | Verdict | Raison | | --- | :--: | --- | | Permissive | ● | Aucune obligation de distribution ; créditer reste une bonne pratique | | Copyleft faible (MPL, EPL, LGPL) | ● | Réciprocité conditionnée à la distribution | | **Copyleft fort (GPL-2.0, GPL-3.0)** | **●** | **Sans effet.** Pas de distribution, pas d'obligation de publier | | **Copyleft réseau (AGPL-3.0, OSL)** | **✕** | **C'est exactement le cas qu'elles visent** | | SSPL-1.0 | ✕ | Exige la publication de toute la pile de service | | Elastic License 2.0, BSL | ○ | Voir ci-dessous : dépend de ce que le service *est* | ### Les deux intuitions fausses #### « La GPL va contaminer votre SaaS » **Non.** La GPL se déclenche par la *distribution*, et un service en ligne ne distribue rien. Vous pouvez bâtir un backend entier sur des composants GPL sans avoir à publier une ligne. C'est la conséquence la plus contre-intuitive du domaine — au point que beaucoup de politiques d'entreprise interdisent la GPL dans un SaaS sans raison juridique, se privant de composants majeurs. #### « L'AGPL c'est juste une GPL un peu plus stricte » **Non.** C'est un changement de nature. Dans ce scénario précis, l'AGPL est la seule famille qui puisse vous obliger à publier votre code — et l'obligation porte sur **l'œuvre combinée**, c'est-à-dire potentiellement l'ensemble de votre service. ### Comment l'AGPL mord, concrètement Trois situations, par ordre de gravité : | Situation | Analyse | | --- | --- | | Composant AGPL **strictement inchangé**, dans son propre processus, appelé par une interface réseau | L'article 13 vise la version *modifiée*. Position défendable, à **documenter** | | Composant AGPL **modifié**, même légèrement | Article 13 déclenché sur votre version | | Bibliothèque AGPL **liée** à votre code de service | L'œuvre combinée devient « votre version » : le source du tout est dû aux utilisateurs | Le troisième cas est le plus fréquent et le plus coûteux. Il suffit d'un `import`. > **La règle interne recommandée.** L'AGPL est en **liste noire** pour tout composant destiné > à être lié au code de service. Elle passe en **liste grise** — instruction au cas par cas, > décision documentée — pour un composant déployé inchangé dans un processus isolé, du type > base de données ou service d'infrastructure autonome. ### Les licences source-available dans ce scénario Elles visent précisément les fournisseurs de services managés. La question n'est pas *où* le logiciel tourne, mais **ce que vous vendez** : | Cas | Elastic License 2.0 / BSL | | --- | --- | | Le produit **est** votre offre, revendue en service managé | **Interdit** — c'est le cas visé | | Le produit est un **composant interne** de votre plateforme, invisible du client | Généralement autorisé, à vérifier dans le texte exact | | Le produit sert à **exploiter** votre infrastructure | Généralement autorisé | Chaque licence de cette famille a sa propre rédaction. Il n'existe pas de réponse générique : il faut lire, et faire trancher par le juridique. ### Les pièges propres au SaaS **L'image de conteneur publiée.** Pousser une image sur un registre public — ou sur un registre privé accessible à un client — **est une distribution**. Toutes les obligations endormies se réveillent sur le contenu de l'image. **L'agent, le connecteur, le SDK client.** Le jour où l'on livre le moindre composant à installer, ce composant relève d'un autre scénario. La GPL présente dans le backend est sans effet ; la même GPL dans l'agent est une obligation de publication. **L'édition on-premise.** C'est la mutation la plus brutale : le produit passe du scénario le plus permissif au [plus contraint](/fr/licences/scenarios/on-premise/), avec un code qui a été construit pendant des années sous une hypothèse inverse. **Le frontend.** Le JavaScript servi au navigateur **est** distribué, quoi qu'il en soit du backend. Voir [Frontend web](/fr/licences/scenarios/frontend-web/) — c'est le même produit, mais pas le même régime. **Le code exporté.** Une fonctionnalité qui génère et livre au client du code, un modèle, une configuration, peut emporter des composants sous licence. ### Ce que le CRA ajoute Un SaaS autonome relève de NIS 2, **pas** du CRA. Mais un backend indissociable d'un produit connecté est une **solution de traitement de données à distance** au sens de l'article 3, et entre donc dans le périmètre du produit — voir [Le périmètre](/fr/cra/perimetre-pde/). Conséquence : ses composants figurent au **SBOM** et au dossier technique, même lorsqu'aucune obligation de licence ne se déclenche. L'inventaire est dû pour des raisons de sécurité, pas de droit d'auteur. ## Organisation URL: https://cra-reference.eu/fr/organisation/ Description: Deux niveaux d'outillage, une architecture cible, une matrice RACI, des instances de gouvernance, un contrat d'interface entre Juridique et Cyber, des indicateurs et une feuille de route. Audience: transverse Published 2026-08-19, updated 2026-08-19 La conformité au CRA n'échoue presque jamais sur la technique. Elle échoue sur l'organisation : personne n'est propriétaire de la décision de signaler, le dossier technique est constitué après la mise sur le marché, et les SBOM sont générés mais jamais agrégés. Cette section fixe qui fait quoi, avec quel outillage et selon quel calendrier. ### Le point de départ Une seule page conditionne la compréhension du reste : **[Générer et piloter](/fr/organisation/deux-niveaux/)**. Elle distingue la génération technique du SBOM au niveau de l'application — dans la chaîne CI/CD, à chaque build — et la centralisation pour le pilotage au niveau de l'organisation, dans une plateforme qui réévalue le portefeuille en continu. Le CRA exige **les deux**. L'annexe I, partie II, point 1 impose l'inventaire ; les points 2, 3, 4 et 7 imposent un processus continu, qu'un fichier posé à côté d'un artefact ne peut pas démontrer. ### Les trois arbitrages à trancher explicitement Ils relèvent du comité, pas d'une équipe : 1. **Qui décide de signaler sous 24 heures ?** Et qui décide en son absence, un dimanche ? 2. **Qui a le droit de veto sur la mise sur le marché** lorsque le dossier technique est incomplet ? 3. **Qui arbitre entre « corriger » et « documenter en VEX »** lorsque les deux sont défendables ? Tant que ces trois réponses ne sont pas écrites, la conformité repose sur des personnes, pas sur un processus — et ne survivra pas au premier départ. ### Les pages de cette section Elles se lisent dans l'ordre : le principe d'outillage, l'architecture qui en découle, la répartition des rôles, les instances qui décident, le contrat d'interface entre les deux équipes, les indicateurs qui mesurent, et la feuille de route qui séquence. ## Architecture cible URL: https://cra-reference.eu/fr/organisation/architecture-cible/ Description: Les flux de bout en bout, du dépôt de code au coffre de preuves ; les points de contrôle, la souveraineté des données et trois scénarios selon la maturité. Audience: cyber Published 2026-08-19, updated 2026-08-19 ### Le schéma de bout en bout ``` Dépôts de code │ ▼ Chaîne CI/CD ──► génération SBOM ──► validation ──► signature │ │ │ ▼ │ Registre d'artefacts │ (artefact + SBOM + signature) ▼ │ Plateforme de pilotage ◄────────── ingestion ───────────┘ ▲ │ │ ├──► moteur de politiques ──► CI (blocage) │ ├──► alertes ciblées ──────► outil de tickets │ ├──► tableaux de bord ─────► Direction │ └──► exports ───────────────► dossier technique │ Sources de vulnérabilités EUVD · OSV · NVD · avis éditeurs · catalogues d'exploitation avérée Coffre de preuves (archivage 10 ans, immuable, indexé) ▲ └── SBOM signés · VEX · dossiers techniques · déclarations · registres Plateforme de signalement unique de l'ENISA ◄── alertes 24 h / 72 h / rapports Portail client ◄── SBOM · avis de sécurité (CSAF) · VEX ``` ### Les flux, un par un | Flux | De → vers | Protocole | Fréquence | Propriétaire | | --- | --- | --- | --- | --- | | Publication du SBOM | CI → plateforme | API | À chaque construction publiable | Équipe produit | | Ingestion des vulnérabilités | Sources → plateforme | Flux et API | Quotidienne | RSSI | | Décision de politique | Plateforme → CI | API | À chaque construction | RSSI | | Alerte | Plateforme → tickets | API | À l'événement | PSIRT | | Export de preuve | Plateforme → coffre | Export signé | À chaque version livrée | Conformité | | Signalement | PSIRT → plateforme ENISA | Interface dédiée | À l'événement | PSIRT + Juridique | | Publication client | Plateforme → portail | Export CSAF | À chaque avis | PSIRT | ### Les points de contrôle | Point | Condition de passage | Qui peut lever | | --- | --- | --- | | Construction publiable | SBOM valide, score au-dessus du seuil, signature présente | Personne — c'est un prérequis technique | | Promotion en production | Aucune vulnérabilité critique exploitable sans VEX ; aucune licence en liste noire | RSSI (vulnérabilités), Juridique (licences), avec dérogation datée | | Mise sur le marché | [Liste de contrôle juridique](/fr/legal/checklist-mise-sur-le-marche/) complète | Direction juridique, en revue formelle | ### Souveraineté et localisation des données Trois questions à trancher explicitement, et à documenter : 1. **Où sont hébergés vos SBOM ?** Ils décrivent la composition de vos produits ; leur agrégation constitue une information sensible. 2. **Quelles données sortent de l'Union ?** Une plateforme en mode service hébergée hors d'Europe implique un transfert, avec les conséquences contractuelles et, le cas échéant, réglementaires afférentes. 3. **Que se passe-t-il si la plateforme est indisponible ?** Les constructions doivent-elles échouer ? Le mode dégradé doit être défini, testé, et sa durée maximale acceptable fixée. Une réponse robuste passe par la conservation, dans le **coffre de preuves interne**, de tout ce qui a valeur probante — indépendamment de la plateforme. La plateforme est un outil de travail ; le coffre est la mémoire de l'entreprise. ### Trois scénarios selon la maturité #### Minimal — outillage ouvert, coût logiciel nul Générateur ouvert en CI, plateforme de pilotage auto-hébergée, coffre de preuves reposant sur le stockage objet existant en mode immuable, signalement manuel avec gabarits. **Pour qui :** portefeuille limité, produits majoritairement en catégorie par défaut, équipe sécurité réduite. **Coût :** essentiellement de l'exploitation et du temps d'ingénierie. **Limite :** peu de détection de licences par analyse de fichiers, pas d'analyse d'atteignabilité, corrélation à affiner. #### Intermédiaire — hybride Génération ouverte, plateforme de pilotage ouverte, complétée par une solution commerciale sur le volet **licences et propriété intellectuelle**, qui est celui où l'écart entre l'offre ouverte et l'offre commerciale est le plus marqué. **Pour qui :** portefeuille diversifié, exigences clients sur la conformité des licences. #### Complet — plateforme d'entreprise Plateforme commerciale intégrée, analyse d'atteignabilité, détection par empreinte de fichier, intégration au référentiel d'artefacts, portail client. **Pour qui :** produits importants ou critiques, base installée large, exigences contractuelles fortes, équipe PSIRT constituée. Le choix se fait selon la grille de [Critères de choix](/fr/outils/criteres-de-choix/). La recommandation est de **commencer par le scénario minimal** : il valide les processus, révèle les vrais besoins, et donne une base de comparaison factuelle pour toute évaluation ultérieure. ## Générer et piloter : les deux niveaux URL: https://cra-reference.eu/fr/organisation/deux-niveaux/ Description: La distinction fondatrice entre la génération technique du SBOM au niveau de l'application et la centralisation pour le pilotage au niveau de l'organisation. Le CRA exige les deux. Audience: transverse Legal basis: Annexe I, partie II, point 1 — inventaire · Annexe I, partie II, points 2, 3, 4 et 7 — processus continu Published 2026-08-19, updated 2026-08-19 C'est le malentendu le plus coûteux du sujet, et la page qui conditionne la compréhension de tout le reste. Beaucoup d'organisations achètent une plateforme sans avoir de génération fiable, ou génèrent des milliers de SBOM que personne n'agrège. ### Le schéma ``` ┌─────────────────────────────────────────────────────────────────┐ │ NIVEAU 1 — APPLICATION / ÉQUIPE « GÉNÉRER » │ │ │ │ Où ? Dans la chaîne CI/CD, à chaque construction │ │ Qui ? L'équipe de développement, le DevSecOps │ │ Quoi ? Produire un inventaire fidèle de CET artefact │ │ Outils Syft · Trivy · Grype · cdxgen · osv-scanner · │ │ plugins natifs Maven, Gradle, npm, .NET, Cargo │ │ Sortie Un fichier CycloneDX ou SPDX signé, lié à l'artefact │ │ Maille 1 SBOM = 1 artefact = 1 construction │ │ Temps Instantané, figé, immuable │ └──────────────────────────────┬──────────────────────────────────┘ │ ingestion automatisée (API) ▼ ┌─────────────────────────────────────────────────────────────────┐ │ NIVEAU 2 — ORGANISATION / PORTEFEUILLE « PILOTER » │ │ │ │ Où ? Dans une plateforme centrale, en continu │ │ Qui ? RSSI, PSIRT, Conformité, Direction produit │ │ Quoi ? Agréger, historiser, corréler chaque jour, décider │ │ Outils OWASP Dependency-Track · Snyk · FOSSA · │ │ Black Duck · Mend · Sonatype · JFrog Xray │ │ Sortie Vue portefeuille, alertes ciblées, VEX, rapports, │ │ pièces pour le dossier technique et les autorités │ │ Maille N produits × M versions × K composants │ │ Temps Continu, historisé, réévalué chaque jour │ └─────────────────────────────────────────────────────────────────┘ ``` ### Les six différences | | **Niveau application — générer** | **Niveau organisation — piloter** | | --- | --- | --- | | **Question posée** | « Que contient cet artefact ? » | « Lesquels de vos produits contiennent ce composant ? » | | **Déclencheur** | Une construction | Une vulnérabilité nouvellement publiée | | **Propriétaire** | Équipe produit | PSIRT, RSSI, Conformité | | **Fréquence** | À chaque construction publiable | Réévaluation quotidienne du parc | | **Sortie** | Un fichier | Un tableau de bord, des alertes, des rapports, une API | | **Sans lui** | Aucune donnée : rien n'est possible | Des milliers de fichiers inexploitables | ### Ce que chaque niveau démontre au regard du CRA | Exigence | Niveau qui la couvre | | --- | --- | | Annexe I, partie II, point 1 — **inventaire** des composants | **Génération** | | Annexe VII — SBOM au **dossier technique** | **Génération** (+ archivage) | | Annexe I, partie II, point 2 — traiter les vulnérabilités **sans délai** | **Pilotage** | | Annexe I, partie II, point 3 — tests et revues **réguliers** | Les deux | | Annexe I, partie II, point 4 — **publier** les avis | **Pilotage** | | Art. 14 — **signaler** sous 24 h en connaissant le périmètre affecté | **Pilotage** | | Réponse à une **demande d'autorité** portant sur une version ancienne | **Pilotage** (+ archivage) | > **Le CRA exige les deux.** Le point 1 impose l'inventaire ; les points 2, 3, 4 et 7 > imposent un processus continu, qu'un fichier posé à côté d'un artefact ne peut pas > démontrer. ### L'erreur classique, nommée > « On a mis un scanner dans la CI, on est conformes. » Non. Un scanner en CI vous dit ce qui va mal **maintenant, ici, dans cette construction**. Il ne vous dit pas : - quelles **versions déjà livrées** chez des clients contiennent le composant vulnérable ; - ce qui est devenu vulnérable **depuis** la dernière construction, sans qu'aucun code n'ait changé ; - quel est le **périmètre affecté** à déclarer dans une alerte à 24 heures ; - ce que contenait la version **4.2.1 livrée en 2028**, interrogée par une autorité en 2033. L'erreur symétrique existe aussi : acheter une plateforme sans génération fiable. La plateforme affiche alors une couverture trompeuse, alimentée par des SBOM partiels produits manuellement. ### Le message par public **Pour le Juridique.** Le niveau 1 produit la **pièce du dossier technique**. Le niveau 2 produit la **preuve du processus continu**. Sans le premier, le dossier est incomplet ; sans le second, on ne peut ni répondre à une autorité, ni tenir un délai de 24 heures. **Pour la Cyber.** Ne pas confondre le scanner et la plateforme. Ce ne sont pas deux produits concurrents : c'est une chaîne, et le maillon manquant est presque toujours le second. **Pour la Direction.** Deux lignes budgétaires, deux propriétaires, deux calendriers. Le niveau 1 se déploie par équipe, progressivement. Le niveau 2 est une **plateforme transverse** qui doit exister avant que les SBOM ne s'accumulent sans destination. ### L'ordre de déploiement 1. **Choisir le format pivot** et figer l'outillage par famille de produits. 2. **Déployer la plateforme** de pilotage, même minimale, avant de généraliser la génération. 3. **Généraliser la génération**, en publiant systématiquement vers la plateforme. 4. **Activer la surveillance continue** une fois la couverture significative. 5. **Ajouter les politiques bloquantes**, en avertissement d'abord, en blocage ensuite. Déployer dans cet ordre évite la situation la plus fréquente : des équipes qui génèrent consciencieusement des SBOM depuis dix-huit mois, sans que personne ne puisse répondre à la question qui compte. ## Feuille de route URL: https://cra-reference.eu/fr/organisation/feuille-de-route/ Description: Six vagues de déploiement, du cadrage à l'amélioration continue, avec les jalons, les livrables et les dépendances entre elles. Audience: direction Published 2026-08-19, updated 2026-08-19 Six vagues. Elles se recouvrent partiellement, mais leurs **dépendances sont strictes** : une vague dont le prérequis n'est pas tenu produit du travail inutilisable. ### Vague 0 — Cadrage **Objectif :** savoir de quoi on parle et qui décide. | Livrable | Responsable | | --- | --- | | Registre de **qualification PDE** du portefeuille | Juridique | | Registre de **classification** de criticité | Juridique + RSSI | | Choix des **voies d'évaluation** | Juridique | | [Matrice RACI](/fr/organisation/raci/) nominative validée | Sponsor | | [Instances de gouvernance](/fr/organisation/gouvernance/) installées | Sponsor | | Choix du **format pivot** et de l'outillage | RSSI | | **Politique de licences** v1 | Juridique | **Ne pas passer à la suite sans :** la classification. Sans elle, on ne sait pas quels produits exigent un organisme notifié — c'est-à-dire quel est le chemin critique. ### Vague 1 — Réagir **Placée en deuxième position à dessein :** l'échéance de signalement est la plus proche, et elle s'applique au parc historique. | Livrable | Responsable | | --- | --- | | **Astreinte** technique et juridique, avec délégation écrite | Sponsor | | **Comptes** actifs sur la plateforme de signalement, testés | PSIRT | | **Gabarits** de signalement | PSIRT + Juridique | | **Registre** des décisions | Juridique | | [Politique CVD](/fr/cyber/politique-cvd/) publiée, `security.txt` en ligne | PSIRT | | **Premier exercice** chronométré | PSIRT | | **Liste des États membres** de mise à disposition, par produit | Produit | ### Vague 2 — Générer | Livrable | Responsable | | --- | --- | | **SBOM automatisé** sur les chaînes prioritaires | DevSecOps | | **Validation qualité** et seuils bloquants | RSSI | | **Signature** et attestation de provenance | DevSecOps | | Fiches d'**outillage** par famille de produits | RSSI | **Prérequis :** le format pivot est choisi (vague 0). ### Vague 3 — Piloter | Livrable | Responsable | | --- | --- | | **Plateforme** de pilotage en production | RSSI | | **Ingestion** automatique depuis toutes les chaînes | DevSecOps | | **Sources de vulnérabilités** branchées | RSSI | | **Surveillance continue** active sur les versions livrées | RSSI | | **Politiques** en avertissement, puis en blocage | RSSI + Juridique | | **Routage** des alertes vers les équipes propriétaires | PSIRT | **Prérequis :** la génération produit des SBOM de qualité (vague 2). Déployer la plateforme avant est possible et même recommandé, mais l'activer sur des SBOM médiocres discrédite l'outil. ### Vague 4 — Prouver | Livrable | Responsable | | --- | --- | | **Dossiers techniques** pilotes sur deux produits représentatifs | Juridique + RSSI | | **Organismes notifiés** engagés et évaluations lancées | Juridique | | **Notices utilisateur** annexe II | Produit + Juridique | | **Périodes de support** déterminées et communiquées | Produit + Juridique | | **Déclarations UE** et marquage CE | Juridique | | **Coffre de preuves** avec archivage dix ans | Juridique + DevSecOps | | **Premier exercice de restitution** réussi | Juridique | **Prérequis :** les vagues 0, 2 et 3. Un dossier technique se constitue à partir d'artefacts existants ; le rédiger avant qu'ils n'existent produit un document déclaratif sans preuve. ### Vague 5 — Tenir | Livrable | Responsable | | --- | --- | | **Veille réglementaire** structurée, avec impact évalué | Juridique | | **Revues périodiques** : classification, licences, supports | Juridique | | **Exercices** semestriels : signalement, restitution | PSIRT | | **Amélioration continue** du ratio d'alertes actionnables | RSSI | | **Extension** du périmètre aux nouveaux produits, par défaut | Tous | C'est la vague qui n'a pas de fin, et celle qu'on oublie de budgéter. Un dispositif de conformité non entretenu se dégrade en dix-huit mois. ### Les dépendances, en un schéma ``` Vague 0 — Cadrage │ ├──► Vague 1 — Réagir (indépendante, échéance la plus proche) │ └──► Vague 2 — Générer │ └──► Vague 3 — Piloter │ └──► Vague 4 — Prouver │ └──► Vague 5 — Tenir ``` ### Ce qu'il faut décider maintenant Trois actions ne peuvent pas attendre, parce que leur délai ne dépend pas de vous : 1. **Contractualiser les organismes notifiés** pour les produits de classe II et Critiques. 2. **Armer l'astreinte de signalement**, si ce n'est pas fait. 3. **Classer le portefeuille**, sans quoi le point 1 est impossible. Le reste peut être séquencé. Ces trois-là, non. ## Instances de gouvernance URL: https://cra-reference.eu/fr/organisation/gouvernance/ Description: Comité CRA, cellule PSIRT, revue de mise sur le marché, revue de la politique de licences : composition, fréquence, ordre du jour et décisions relevant de chaque niveau. Audience: direction Published 2026-08-19, updated 2026-08-19 Quatre instances suffisent. En créer davantage dilue la responsabilité ; en créer moins fait remonter des décisions techniques au comité exécutif. ### Le comité CRA **Fréquence :** trimestrielle, plus une séance extraordinaire sur événement. **Composition :** sponsor exécutif (président), direction juridique, RSSI, direction produit, responsable PSIRT, achats en tant que de besoin. **Ordre du jour type :** 1. Avancement du [rétroplanning](/fr/cra/calendrier/) et écarts. 2. [Indicateurs](/fr/organisation/indicateurs/) : couverture, délais, exposition. 3. Registre des risques de conformité : nouvelles lignes, risques acceptés. 4. Registre de classification : produits entrants, reclassements. 5. Registre des périodes de support : engagements devenus tendus. 6. [Veille réglementaire](/fr/actualites/) : ce qui a changé, ce que cela implique. 7. Décisions à arbitrer. 8. Retour d'expérience des incidents et exercices du trimestre. **Décisions de son niveau :** priorisation du portefeuille, engagement d'un organisme notifié, budget d'outillage, acceptation d'un risque résiduel, arbitrage entre équipes. ### La cellule PSIRT **Fréquence :** permanente, activée sur événement. **Composition en veille :** responsable PSIRT, astreinte technique, astreinte juridique. **Composition en cellule :** coordinateur d'incident, analyste, référent juridique, communication, ingénierie produit, direction si impact commercial. **Procédure d'activation :** définie dans [Procédure 24 h](/fr/cyber/procedure-24h/). Le déclencheur est la qualification d'une exploitation active ou d'un incident grave. **Moyens à garantir :** accès nominatifs actifs à la plateforme de signalement, gabarits, canal d'information des utilisateurs, liste de rappel testée, salle et moyens de conférence. ### La revue de mise sur le marché **Fréquence :** à chaque mise sur le marché, et à chaque modification substantielle. **Composition :** direction juridique (préside), RSSI, direction produit, responsable du projet. **Support :** la [liste de contrôle juridique](/fr/legal/checklist-mise-sur-le-marche/) et la [liste de contrôle technique](/fr/cyber/checklist-technique/). **Sortie :** un **procès-verbal signé** valant autorisation d'apposer le marquage CE, ou refus motivé avec échéances. C'est l'instance la plus importante du dispositif, parce que c'est la seule qui **bloque**. ### La revue de la politique de licences **Fréquence :** trimestrielle. **Composition :** direction juridique (préside), RSSI, un représentant des équipes de développement. **Ordre du jour :** exceptions arrivant à expiration, nouvelles demandes, évolutions des listes, changements de licence constatés en amont, état du registre. **Sortie :** politique mise à jour et versionnée, registre des exceptions à jour. ### Le reporting au comité exécutif **Fréquence :** semestrielle, ou à l'événement. **Format :** une page. Trois indicateurs de couverture, trois indicateurs de risque, l'état du rétroplanning, les décisions attendues. **Ce qui ne doit pas y figurer :** le détail technique, le nombre de vulnérabilités détectées — un chiffre qui augmente quand le dispositif s'améliore, et qui est donc ininterprétable hors contexte. ### Le principe qui les relie Chaque instance produit un **compte rendu écrit avec des décisions nommées**. Une décision sans nom n'est pas une décision ; une réunion sans compte rendu n'a pas eu lieu du point de vue d'un contrôle. ## Indicateurs URL: https://cra-reference.eu/fr/organisation/indicateurs/ Description: Couverture, performance, risque et préparation : les indicateurs à suivre, ceux à ne pas suivre, et la maquette du tableau de bord de direction. Audience: direction Published 2026-08-19, updated 2026-08-19 ### Indicateurs de couverture Les premiers à regarder : ils disent si le dispositif existe. | Indicateur | Cible | Source | | --- | --- | --- | | Part des produits **qualifiés PDE** | 100 % | Registre de qualification | | Part des produits **classés** | 100 % | Registre de classification | | Part des produits avec **SBOM automatisé** | 100 % des produits actifs | Plateforme | | Part des SBOM au-dessus du **seuil de qualité** | 100 % | Plateforme | | Part des produits sous **surveillance continue** | 100 % des versions livrées | Plateforme | | Part des produits avec **période de support déclarée** | 100 % | Registre | | Part des produits avec **dossier technique complet** | 100 % avant mise sur le marché | Suivi de conformité | | Part des produits de classe II ou Critique avec **organisme notifié engagé** | 100 % | Registre | ### Indicateurs de performance Ils disent si le dispositif fonctionne. | Indicateur | Cible indicative | | --- | --- | | Délai médian de **détection** (publication → alerte chez vous) | < 24 h | | Délai médian de **triage** (alerte → décision) | < 5 jours | | Délai médian de **remédiation**, par niveau de criticité | Selon [SLA](/fr/cyber/gestion-des-vulnerabilites/) | | Part des **SLA respectés** | > 90 % | | **Âge moyen** des vulnérabilités ouvertes | En baisse continue | | **Ratio d'alertes actionnables** sur alertes brutes | En hausse continue | | Délai obtenu lors du dernier **exercice de signalement** | < 12 h pour l'alerte précoce | | Délai obtenu lors du dernier **exercice de restitution** | < 1 jour ouvré | ### Indicateurs de risque Ils disent ce qui reste exposé. | Indicateur | Signification | | --- | --- | | Nombre de composants **en fin de maintenance** dans des produits supportés | Dette réglementaire directe | | Nombre de composants à **mainteneur unique** dans des produits critiques | Risque de reprise ou d'abandon | | Nombre de **licences en écart** de politique, hors exception active | Risque de propriété intellectuelle | | Nombre d'**exceptions expirées** non traitées | Défaut de processus | | Nombre de **périodes de support** dont un composant limitant s'arrête avant l'échéance | Engagements intenables | | **Exposition financière** estimée | Voir [Exposition](/fr/legal/sanctions-et-exposition/) | ### Indicateurs de préparation | Indicateur | Source | | --- | --- | | Jours restants avant chaque échéance légale | [Calendrier](/fr/cra/calendrier/) | | Avancement du rétroplanning, par vague | [Feuille de route](/fr/organisation/feuille-de-route/) | | Date du dernier exercice de signalement | Comptes rendus | | Date du dernier exercice de restitution | Comptes rendus | | Score de [diagnostic](/fr/diagnostic/) par module | Auto-évaluation trimestrielle | ### Les indicateurs à ne pas suivre | Indicateur trompeur | Pourquoi | | --- | --- | | **Nombre de vulnérabilités détectées** | Il augmente quand le dispositif s'améliore. Le présenter à un comité crée une incitation perverse à moins détecter. | | **Nombre de SBOM générés** | Sans couverture ni qualité, c'est un compteur de fichiers. | | **Nombre d'alertes fermées** | Fermer une alerte sans la traiter la fait disparaître du compteur. | | **Score de sécurité global** | Agrégat non actionnable, qui masque les écarts entre produits. | ### Maquette du tableau de bord de direction Une page, quatre blocs. ``` ┌──────────────────────────────┬──────────────────────────────┐ │ COUVERTURE │ ÉCHÉANCES │ │ │ │ │ Produits classés ██ % │ Signalement opérationnel ✓ │ │ SBOM automatisé ██ % │ Application pleine : J-___ │ │ Surveillance active ██ % │ Organismes notifiés __/__ │ │ Dossiers complets ██ % │ Rétroplanning : vague __/6 │ ├──────────────────────────────┼──────────────────────────────┤ │ PERFORMANCE │ RISQUES OUVERTS │ │ │ │ │ Remédiation critique __ j │ Composants abandonnés __ │ │ SLA respectés __ % │ Licences en écart __ │ │ Dernier exercice 24 h __ h │ Supports intenables __ │ │ Alertes actionnables __ % │ Exposition estimée __ M€ │ └──────────────────────────────┴──────────────────────────────┘ Décisions attendues du comité : … ``` ### La règle de tenue Chaque indicateur a un **propriétaire nommé**, une **source unique** et une **fréquence de mise à jour**. Un indicateur dont la valeur est calculée à la main la veille du comité n'est pas un indicateur : c'est une estimation. ## Interface Juridique ↔ Cyber URL: https://cra-reference.eu/fr/organisation/interface-legal-cyber/ Description: Le contrat d'interface entre les deux équipes : livrables croisés avec délais et formats, vocabulaire partagé et chemin d'escalade. Audience: transverse Published 2026-08-19, updated 2026-08-19 C'est la page qui justifie qu'un même site s'adresse à deux publics. Elle formalise ce que chaque équipe doit à l'autre, avec des délais et des formats — parce qu'un échange non formalisé devient, sous pression, un échange qui n'a pas lieu. ### Les livrables croisés #### De la Cyber vers le Juridique | Livrable | Fréquence | Format | Délai | | --- | --- | --- | --- | | **SBOM** validé et signé | À chaque version livrée | CycloneDX, plus export SPDX à la demande | J+1 après publication | | **Analyse de risques** de cybersécurité | Par produit, à chaque évolution majeure | Document type | Avant la revue de mise sur le marché | | **Matrice de traçabilité** de l'annexe I | Par produit et par version | Tableau | Avant la revue | | **Journal de traitement** des vulnérabilités et VEX | Mensuel | Export de la plateforme | J+5 | | **Rapports de tests** de sécurité | Par campagne | Rapport daté | J+10 | | **Description du mécanisme** de mise à jour | Par produit | Document type | Avant la revue | | **Qualification « vulnérabilité activement exploitée »** | À l'événement | Fiche de qualification | **H+2** | | **Justification technique** de la période de support | Par produit | Note | Avant la revue | #### Du Juridique vers la Cyber | Livrable | Fréquence | Format | Délai | | --- | --- | --- | --- | | **Classification de criticité** par produit | À l'entrée au catalogue | Fiche signée | Avant le lancement du développement | | **Voie d'évaluation** retenue | Idem | Fiche | Idem | | **Politique de licences** et listes | Trimestrielle | Politique versionnée | J+5 après la revue | | **Décisions d'exception** de licence | À la demande | Entrée au registre | 5 jours ouvrés | | **Clauses fournisseurs** obtenues | Par contrat | Extrait du clausier | À la signature | | **Arbitrage sur la diffusion** du SBOM | Par produit | Décision | Avant la mise sur le marché | | **Décision de signalement** et texte validé | À l'événement | Validation écrite | **H+20**, pour un envoi à H+24 | | **Période de support** engagée | Par produit | Registre | Avant la mise sur le marché | ### Les deux délais critiques Deux lignes conditionnent le respect de l'article 14, et méritent d'être affichées : > **H+2** — la Cyber transmet la qualification au Juridique. > **H+20** — le Juridique renvoie la décision et le texte validé. > **H+24** — l'alerte précoce est envoyée. Toute autre organisation de ces délais fait porter l'incertitude sur les dernières heures, c'est-à-dire au pire moment. ### Le vocabulaire partagé Cinq termes que les deux équipes emploient différemment, et dont la définition commune doit être écrite : | Terme | Sens côté Cyber | Sens côté Juridique | **Définition retenue** | | --- | --- | --- | --- | | **Vulnérabilité** | Toute faiblesse détectée par un outil | Une faiblesse exploitable créant un risque | Une faiblesse d'un composant ; son **exploitabilité** est qualifiée séparément par un VEX | | **Incident** | Toute alerte de sécurité | Un événement à notifier | Un événement compromettant effectivement la sécurité du produit ; « grave » est une qualification distincte | | **Produit** | Un dépôt, un service, un artefact | Ce qui est mis sur le marché sous votre marque | Ce qui est **mis sur le marché**, au sens de l'article 3 | | **Version** | Un identifiant de construction | Une référence commerciale | Les deux, **explicitement liées** dans le registre | | **Support** | La maintenance opérationnelle | La période de support au sens de l'article 13 | Toujours préciser : « support commercial » ou « **période de support réglementaire** » | Cette table paraît triviale. Elle évite les incidents où une équipe déclare « le produit est supporté » quand l'autre entend « vous avez une obligation légale de correctifs ». ### Le chemin d'escalade En cas de désaccord persistant sur une qualification, une décision de signalement ou un arbitrage VEX : 1. **Responsable PSIRT et référent juridique**, sous deux heures en situation d'incident. 2. **RSSI et directeur juridique**, sous quatre heures. 3. **Sponsor exécutif**, sous huit heures. 4. En l'absence de résolution dans les délais compatibles avec l'échéance légale : **la règle par défaut s'applique** — signaler, ne pas mettre sur le marché, ne pas lever le blocage. La règle par défaut est ce qui rend l'escalade sûre : elle garantit qu'un désaccord ne produit jamais une infraction par inaction. ## Qui fait quoi — matrice RACI URL: https://cra-reference.eu/fr/organisation/raci/ Description: La répartition des rôles sur les vingt activités du dispositif, et les trois arbitrages qui doivent être tranchés explicitement par le comité. Audience: transverse Published 2026-08-19, updated 2026-08-19 **R** responsable de l'exécution · **A** approbateur, comptable du résultat · **C** consulté · **I** informé. | Activité | Dév | DevSecOps | PSIRT | RSSI | Juridique | Produit | Achats | Direction | | --- | --- | --- | --- | --- | --- | --- | --- | --- | | Qualification PDE | | | | C | **A/R** | C | | I | | Classification de criticité | | | | **R** | **A** | C | | I | | Choix de la voie d'évaluation | | | | C | **A/R** | C | | I | | Contractualisation d'un organisme notifié | | | | C | **R** | I | C | **A** | | Analyse de risques | C | C | C | **A/R** | C | C | | I | | Génération du SBOM | **R** | **A/R** | I | C | I | | | | | Validation qualité du SBOM | R | **R** | | **A** | I | | | | | Politique de licences | I | C | | C | **A/R** | C | C | I | | Traitement des exceptions de licence | R | C | | C | **A** | C | | | | Triage des vulnérabilités | C | R | **A/R** | C | I | I | | | | Production des VEX | **R** | C | **A** | C | C | | | | | **Décision de signaler** | | | **R** | C | **A** | I | | I | | Rédaction et envoi du signalement | | | **A/R** | C | **C** | I | | I | | Relation avec les autorités | | | C | C | **A/R** | I | | I | | Constitution du dossier technique | C | C | C | **R** | **A** | C | | I | | Signature de la déclaration UE | | | | C | **R** | I | | **A** | | Apposition du marquage CE | | | | I | **A/R** | R | | I | | Détermination de la période de support | C | | | C | **R** | R | C | **A** | | Publication des avis de sécurité | C | | **A/R** | C | C | I | | | | Gestion de la politique CVD | | | **A/R** | C | **C** | I | | I | | Clauses fournisseurs | | | | C | **A/R** | C | **R** | I | | Archivage des preuves | | R | | C | **A/R** | | | I | ### Lecture de la matrice Trois principes en découlent. **Le juridique approuve, la cyber exécute — sauf sur le triage.** La qualification technique d'une vulnérabilité relève du PSIRT, qui en est comptable. La décision de signaler relève du juridique. La frontière est nette et doit le rester. **La direction générale approuve trois choses seulement** : l'engagement d'un organisme notifié, la période de support, et la signature de la déclaration. Ce sont les trois décisions qui engagent financièrement l'entreprise sur plusieurs années. **Personne n'est seul.** Chaque ligne comporte au moins un consulté. Une activité sans consultation croisée est une activité qui produira un livrable inutilisable par l'aval. ### Les trois arbitrages à trancher explicitement Ils ne se déduisent pas de la matrice : ils doivent faire l'objet d'une décision écrite du comité. #### 1. Qui décide de signaler sous 24 heures, et qui décide en son absence ? La réponse doit nommer une **personne**, un **suppléant**, et prévoir une **délégation écrite**. Un délai de 24 heures ne s'accommode pas d'une remontée hiérarchique le dimanche. Voir [Obligations de signalement](/fr/legal/obligations-de-signalement/). #### 2. Qui a le droit de veto sur la mise sur le marché ? Si personne ne peut bloquer une mise sur le marché, le dossier technique sera constitué après coup. La position recommandée : **la direction juridique**, sur la base de la [liste de contrôle](/fr/legal/checklist-mise-sur-le-marche/), avec possibilité de passer outre uniquement par une décision écrite de la direction générale — décision qui devient alors une pièce du registre des risques. #### 3. Qui arbitre entre corriger et documenter en VEX ? Les deux sont défendables ; le coût et le risque diffèrent. La position recommandée : le **PSIRT approuve** le statut VEX, avec escalade au RSSI en cas de désaccord avec l'équipe produit, et information du juridique dès lors que la vulnérabilité est publique. ### Ce qu'il faut écrire La matrice ci-dessus, **complétée avec des noms** — fonction et personne, avec suppléant pour chaque rôle critique. Une matrice en fonctions génériques ne survit pas au premier départ ; une matrice nominative se met à jour, ce qui oblige à constater les vacances de poste. ## Outils URL: https://cra-reference.eu/fr/outils/ Description: Les deux familles d'outillage : générateurs de SBOM insérés dans la chaîne de construction, et plateformes de pilotage du portefeuille. Fiches, comparatif et critères de choix. Audience: cyber Published 2026-08-19, updated 2026-08-19 Les outils du sujet se rangent en **deux familles qui ne font pas le même métier** et ne sont pas substituables. Confondre les deux est l'erreur la plus coûteuse du projet ; la page [Générer et piloter](/fr/organisation/deux-niveaux/) explique pourquoi. | | [Générateurs](/fr/outils/generation/) | [Plateformes](/fr/outils/plateformes/) | | --- | --- | --- | | Niveau | Application, un artefact | Organisation, le portefeuille | | Question | « Que contient cet artefact ? » | « Lesquels de vos produits contiennent ce composant ? » | | Déclencheur | Un build | Une vulnérabilité nouvellement publiée | | Sortie | Un fichier CycloneDX ou SPDX | Tableaux de bord, alertes, rapports, API | | Exemples | Syft, Trivy, Grype, cdxgen, osv-scanner | OWASP Dependency-Track, Snyk, FOSSA, Black Duck | ### Comment lire les fiches Chaque outil est décrit selon le même gabarit : éditeur, licence et modèle économique, niveau, formats pris en charge, écosystèmes couverts, sources de vulnérabilités, détection de licences, prise en charge du VEX, intégrations, mode de déploiement et souveraineté des données, points forts, limites, et verdict pour votre contexte. > **Avertissement.** Les fiches décrivent des catégories de produits et leurs propriétés > structurantes, pas un état du marché à un instant donné : versions, tarifs et couvertures > évoluent. Toute décision d'achat doit être fondée sur une évaluation menée sur vos > propres artefacts, selon le protocole décrit dans > [Critères de choix](/fr/outils/criteres-de-choix/). ### Le parti pris retenu Deux principes guident l'outillage cible : 1. **Un générateur ouvert et standardisé**, pour que les SBOM produits restent portables et indépendants de la plateforme qui les consomme. Un SBOM propriétaire est une dette. 2. **Une plateforme de pilotage**, en commençant par une solution auto-hébergeable pour valider les processus à coût logiciel nul, avant d'arbitrer sur une offre commerciale si l'échelle ou les besoins juridiques le justifient. ## Critères de choix et protocole d'évaluation URL: https://cra-reference.eu/fr/outils/criteres-de-choix/ Description: Une grille pondérée, un protocole d'évaluation sur vos propres artefacts, et la recommandation d'architecture outillée. Audience: direction Published 2026-08-19, updated 2026-08-19 ### La grille pondérée À pondérer une fois, en comité, **avant** de regarder les produits — sans quoi la pondération s'ajuste inconsciemment au favori. | Critère | Question | Poids indicatif | | --- | --- | --- | | **Couverture des écosystèmes** | Couvre-t-il les langages et plateformes que vous utilisez réellement ? | 20 % | | **Fidélité des SBOM produits** | Écart mesuré avec un contrôle croisé, sur vos artefacts | 15 % | | **Qualité de la corrélation** | Taux de faux positifs mesuré sur un échantillon connu | 15 % | | **Prise en charge du VEX et de CSAF** | Peut-on documenter et publier les décisions ? | 10 % | | **Archivage long terme** | Historique conservé, export intégral possible | 10 % | | **API et automatisation** | Tout est-il pilotable sans interface graphique ? | 10 % | | **Souveraineté** | Où sont hébergées les données ? Quelles sorties de l'Union ? | 8 % | | **Réversibilité** | Peut-on partir avec vos SBOM, votre historique et vos VEX ? | 5 % | | **Besoins juridiques** | Attributions, rapports de licences, registre d'exceptions | 5 % | | **Coût total sur cinq ans** | Licence, exploitation, intégration, formation | Éliminatoire au-delà du budget | Les deux critères les plus souvent sous-pondérés sont la **réversibilité** et le **coût d'exploitation**. Les deux se paient à la fin. ### Le protocole d'évaluation Une évaluation crédible se mène sur **vos artefacts**, pas sur la démonstration du fournisseur. **Durée :** quatre à six semaines. **Périmètre :** trois produits représentatifs — un produit simple, un produit multi-langages, un produit embarqué ou conteneurisé. #### Étapes 1. **Constituer un jeu de référence.** Pour chaque produit, établir manuellement la liste des composants attendus, au moins pour les dépendances directes et un échantillon de transitives. C'est le travail le plus ingrat, et c'est lui qui rend l'évaluation objective. 2. **Injecter des cas connus.** Ajouter délibérément un composant vulnérable connu, un composant sous licence copyleft, un composant vendorisé, un composant lié statiquement. 3. **Mesurer**, pour chaque candidat : - composants trouvés / attendus (**rappel**) ; - composants signalés à tort (**précision**) ; - vulnérabilités réelles détectées et **faux positifs** ; - licences correctement identifiées ; - temps ajouté à la construction ; - effort d'intégration en jours-personnes. 4. **Tester la réversibilité.** Exporter l'intégralité des données et vérifier que l'export est exploitable sans l'outil. 5. **Tester la restitution.** Simuler une demande d'autorité sur une version ingérée trois semaines plus tôt. 6. **Noter** selon la grille, et documenter. #### Ce qui n'est pas une évaluation - Une démonstration sur les dépôts de démonstration du fournisseur. - Une comparaison de listes de fonctionnalités. - Un essai gratuit sur un seul projet simple. - Un avis d'analyste sans mesure sur vos artefacts. ### La recommandation d'architecture 1. **Un générateur ouvert et standardisé** comme source primaire, pour que les SBOM restent **portables**. Un SBOM enfermé dans un format propriétaire est une dette. 2. **Une plateforme de pilotage auto-hébergeable pour démarrer**, afin de valider les processus, de mesurer les vrais volumes et de disposer d'une base de comparaison factuelle. 3. **Une décision d'investissement ensuite**, fondée sur des écarts mesurés et non sur des promesses : atteignabilité, détection par empreinte, profondeur du volet licences, intégration. 4. **Le coffre de preuves reste interne**, quel que soit l'outil. La plateforme est un outil de travail ; la mémoire probante de l'entreprise ne doit pas dépendre d'un contrat. ### Les trois questions à poser à tout fournisseur 1. **Que se passe-t-il si vous partez ?** Format de l'export, exhaustivité, historique et VEX compris, délai de mise à disposition. 2. **Où sont les données, et qui y accède ?** Localisation, sous-traitants, conditions d'accès du support. 3. **Comment mesurez-vous vos faux positifs ?** Une réponse évasive à cette question est en soi une information. ## Générateurs de SBOM URL: https://cra-reference.eu/fr/outils/generation/ Description: Les outils du niveau application : Syft, Grype, Trivy, cdxgen, osv-scanner, ScanCode, OSS Review Toolkit et les plugins natifs de chaîne de construction. Audience: cyber Published 2026-08-19, updated 2026-08-19 Outils du **niveau 1** : ils produisent l'inventaire d'un artefact. Voir [Générer et piloter](/fr/organisation/deux-niveaux/) pour la distinction avec les plateformes. > **Avertissement.** Ces fiches décrivent des catégories d'outils et leurs propriétés > structurantes, pas un état du marché à un instant donné. Couvertures, formats et > performances évoluent ; toute décision doit reposer sur une évaluation menée sur vos > propres artefacts. ### Syft | | | | --- | --- | | **Site** | [github.com/anchore/syft](https://github.com/anchore/syft) | | **Éditeur** | Anchore | | **Licence** | Ouverte (Apache 2.0) | | **Niveau** | Génération | | **Formats** | CycloneDX, SPDX, format natif | | **Couverture** | Très large, multi-écosystèmes : paquets système, langages, images de conteneur, systèmes de fichiers | | **Vulnérabilités** | Non — c'est le rôle de Grype | | **Licences** | Métadonnées déclarées, pas d'analyse de fichiers | | **Déploiement** | Binaire autonome, auto-hébergé | | **Points forts** | Référence de fait pour la génération ; sortie propre ; excellente intégration en CI ; couvre à la fois le système de fichiers et l'image | | **Limites** | Ne détecte pas les licences par analyse de contenu ; couverture perfectible sur les binaires compilés natifs | | **Verdict** | **Générateur de référence** pour la majorité de vos chaînes | ### Grype | | | | --- | --- | | **Site** | [github.com/anchore/grype](https://github.com/anchore/grype) | | **Éditeur** | Anchore | | **Licence** | Ouverte | | **Niveau** | Détection, en aval de la génération | | **Entrée** | Un SBOM, une image, un répertoire | | **Sources** | Bases publiques agrégées, avis de distributions | | **Points forts** | Complémentaire de Syft ; consomme un SBOM déjà produit, donc évite de rescanner ; gère les rétroportages de distributions | | **Limites** | Pas d'analyse d'atteignabilité | | **Verdict** | Contrôle **local** en CI, en complément de la corrélation faite par la plateforme | ### Trivy | | | | --- | --- | | **Site** | [trivy.dev](https://trivy.dev/) | | **Éditeur** | Aqua Security | | **Licence** | Ouverte | | **Niveau** | Génération **et** détection | | **Périmètre** | SBOM, vulnérabilités, secrets, mauvaises configurations d'infrastructure déclarative, licences déclarées | | **Formats** | CycloneDX, SPDX | | **Points forts** | Tout-en-un, très simple à intégrer, une seule commande couvre plusieurs contrôles ; base de vulnérabilités propre et fréquemment mise à jour | | **Limites** | Le tout-en-un rend les responsabilités moins nettes ; pour un dispositif mature, séparer génération et détection facilite le remplacement d'un maillon | | **Verdict** | **Excellent point d'entrée** et bon choix pour les chaînes simples ; à réévaluer une fois la plateforme de pilotage en place | ### cdxgen | | | | --- | --- | | **Site** | [github.com/cdxgen/cdxgen](https://github.com/cdxgen/cdxgen) | | **Éditeur** | OWASP | | **Licence** | Ouverte | | **Niveau** | Génération | | **Formats** | CycloneDX natif, y compris les extensions | | **Couverture** | **Très large en langages**, y compris des écosystèmes peu couverts ailleurs | | **Points forts** | Profondeur d'analyse paramétrable ; produit des documents CycloneDX riches, avec relations et métadonnées de construction | | **Limites** | Configuration plus exigeante ; sortie volumineuse | | **Verdict** | À retenir pour les **écosystèmes mal couverts** par les générateurs génériques | ### osv-scanner | | | | --- | --- | | **Site** | [google.github.io/osv-scanner](https://google.github.io/osv-scanner/) | | **Éditeur** | Google | | **Licence** | Ouverte | | **Niveau** | Détection | | **Source** | Base OSV, corrélation par `purl` | | **Points forts** | **Précision d'appariement élevée** grâce aux identifiants par écosystème ; réduit fortement les faux positifs par rapport à une corrélation par CPE | | **Limites** | Couverture centrée sur les écosystèmes de paquets ; moins pertinent sur les binaires systèmes exotiques | | **Verdict** | À utiliser **en complément**, précisément pour son taux de faux positifs bas | ### ScanCode Toolkit et OSS Review Toolkit | | | | --- | --- | | **Site** | [ScanCode](https://github.com/aboutcode-org/scancode-toolkit) · [ORT](https://oss-review-toolkit.org/) | | **Éditeur** | Communautés open source | | **Licence** | Ouverte | | **Niveau** | Génération, orientée **licences** | | **Méthode** | Analyse du **contenu des fichiers**, pas seulement des manifestes | | **Points forts** | Détectent les licences et les copyrights **dans le code**, y compris pour du code vendorisé ou copié — ce que les générateurs génériques ne voient pas | | **Limites** | Lents ; sortie volumineuse nécessitant un travail de revue | | **Verdict** | Indispensables pour le volet **propriété intellectuelle** ; à exécuter à cadence réduite plutôt qu'à chaque construction | ### Plugins natifs des chaînes de construction CycloneDX pour Maven et Gradle, `npm sbom`, générateurs pour .NET, Rust, Go, et leurs équivalents. | | | | --- | --- | | **Points forts** | Voient le **graphe de résolution réel**, avec les arbitrages de versions effectivement retenus ; distinguent nativement les portées — exécution, compilation, test | | **Limites** | Un plugin par écosystème à maintenir ; ne voient rien en dehors de leur périmètre | | **Verdict** | **À privilégier** comme source primaire pour les langages à gestionnaire de dépendances, complétés par un générateur générique sur l'artefact | ### La combinaison recommandée | Contexte | Primaire | Contrôle croisé | Licences | | --- | --- | --- | --- | | Java, .NET, Node, Python | Plugin natif | Générateur générique sur l'artefact | Outil d'analyse de contenu, à cadence réduite | | Go, Rust | Générateur générique sur le binaire | — | Idem | | C / C++ | Générateur sur le binaire + système de construction | Analyse du système de fichiers | Idem | | Image de conteneur | Générateur sur l'image | Scanner tout-en-un | Idem | | Micrologiciel | Outillage spécialisé | Exigence de SBOM auprès du fournisseur | Idem | Le principe : **un générateur primaire par famille, figé et documenté**, un contrôle croisé, et une analyse de licences distincte, moins fréquente. ## Plateformes de pilotage URL: https://cra-reference.eu/fr/outils/plateformes/ Description: Les outils du niveau organisation : OWASP Dependency-Track, Snyk, FOSSA, Black Duck, Mend, Sonatype, JFrog Xray, GUAC — et ce qui les distingue vraiment. Audience: cyber Published 2026-08-19, updated 2026-08-19 Outils du **niveau 2** : ils agrègent les SBOM du portefeuille et les réévaluent en continu. Voir [Générer et piloter](/fr/organisation/deux-niveaux/). > **Avertissement.** Ces fiches décrivent des catégories de solutions et leurs propriétés > structurantes, pas un état du marché à un instant donné. Toute décision d'achat doit > reposer sur une évaluation menée sur vos propres artefacts, selon le protocole de > [Critères de choix](/fr/outils/criteres-de-choix/). ### OWASP Dependency-Track | | | | --- | --- | | **Site** | [dependencytrack.org](https://dependencytrack.org/) | | **Porteur** | OWASP | | **Licence** | Ouverte | | **Déploiement** | **Auto-hébergeable** — souveraineté totale des données | | **Entrée** | Ingestion **[CycloneDX](https://cyclonedx.org/) native**, par API | | **Fonctions** | Réévaluation continue du portefeuille, politiques, prise en charge du VEX, gestion des projets et versions, API complète, notifications | | **Sources** | Bases publiques agrégées | | **Licences** | Suivi des licences déclarées, politiques associées | | **Points forts** | **Coût logiciel nul** ; conçu exactement pour l'usage que le CRA impose : agréger des SBOM et les rejouer dans le temps ; API de qualité ; auto-hébergement | | **Limites** | Coût d'exploitation réel ; pas d'analyse d'atteignabilité ; détection de licences limitée aux métadonnées déclarées ; interface austère | | **Verdict** | **Le meilleur point d'entrée.** Permet de démontrer la valeur et de roder les processus avant tout investissement, et reste suffisant pour beaucoup d'organisations | ### Snyk | | | | --- | --- | | **Site** | [snyk.io](https://snyk.io/) | | **Modèle** | Service, tarification à l'usage | | **Orientation** | **Expérience développeur** | | **Points forts** | Intégration forte aux environnements de développement, aux dépôts et aux chaînes CI ; base de vulnérabilités enrichie ; propositions de correctifs automatisées ; analyse d'atteignabilité | | **Limites** | Données hébergées par l'éditeur — à instruire au regard de la souveraineté ; coût croissant avec le nombre de projets ; le volet licences est moins profond que celui des spécialistes | | **Verdict** | Pertinent lorsque l'objectif est de **faire adopter** le sujet par les équipes de développement | ### FOSSA | | | | --- | --- | | **Site** | [fossa.com](https://fossa.com/) | | **Modèle** | Service | | **Orientation** | **Conformité des licences et propriété intellectuelle**, avec volet sécurité | | **Points forts** | Génération des fichiers d'attribution ; gestion des politiques juridiques ; rapports adaptés aux diligences d'investisseurs et d'acquéreurs ; **parle le langage du Juridique** | | **Limites** | Volet sécurité moins profond que les spécialistes ; hébergement à instruire | | **Verdict** | À considérer si le **volet propriété intellectuelle** est le moteur du projet | ### Black Duck | | | | --- | --- | | **Site** | [www.blackduck.com](https://www.blackduck.com/) | | **Modèle** | Entreprise, service ou installation locale | | **Orientation** | Analyse de composition logicielle d'entreprise | | **Points forts** | **Analyse par empreinte de fichier** — détecte le code copié-collé et les composants non déclarés, ce qu'aucune analyse de manifestes ne voit ; couverture licences très profonde ; forte présence sur l'embarqué et les secteurs régulés | | **Limites** | Coût élevé ; volume de résultats nécessitant un travail de revue ; déploiement lourd | | **Verdict** | Pertinent pour l'**embarqué**, les secteurs régulés et les organisations exposées à des audits de licences | ### Mend | | | | --- | --- | | **Site** | [www.mend.io](https://www.mend.io/) | | **Modèle** | Service, entreprise | | **Points forts** | Remédiation automatisée, priorisation par atteignabilité, couverture large | | **Limites** | Hébergement à instruire ; recouvrement fonctionnel avec les précédents | | **Verdict** | Alternative crédible sur le segment entreprise | ### Sonatype Nexus Lifecycle | | | | --- | --- | | **Site** | [www.sonatype.com](https://www.sonatype.com/) | | **Modèle** | Entreprise | | **Particularité** | Couplage fort avec le **référentiel d'artefacts** | | **Points forts** | Applique les politiques **à l'entrée du dépôt** : un composant non conforme n'entre pas dans l'organisation, ce qui déplace le contrôle en amont | | **Limites** | Cohérent surtout si le référentiel d'artefacts est déjà de cet éditeur | | **Verdict** | À considérer si vous voulez **bloquer à la source** plutôt qu'en CI | ### JFrog Xray | | | | --- | --- | | **Site** | [jfrog.com/xray](https://jfrog.com/xray/) | | **Modèle** | Entreprise | | **Particularité** | Intégré au référentiel d'artefacts du même éditeur | | **Verdict** | Pertinent **si et seulement si** ce référentiel est déjà en place ; sinon, le couplage est un inconvénient | ### GUAC | | | | --- | --- | | **Site** | [guac.sh](https://guac.sh/) | | **Nature** | Projet ouvert d'agrégation et de mise en graphe des métadonnées de chaîne d'approvisionnement — SBOM, attestations, avis | | **Usage** | Requêtes transverses complexes sur le graphe des dépendances et des provenances | | **Verdict** | **À surveiller**, pour des usages avancés ; ne remplace pas une plateforme de pilotage aujourd'hui | ### Ce qui distingue vraiment ces solutions Au-delà des listes de fonctionnalités, quatre axes différencient réellement : 1. **La méthode de détection.** Manifestes seuls, ou **analyse par empreinte de fichier** ? C'est ce qui détermine la capacité à voir le code vendorisé. 2. **La profondeur du volet licences.** Métadonnées déclarées, ou analyse du contenu et génération d'attributions ? 3. **L'atteignabilité.** Le produit sait-il dire si la fonction vulnérable est appelée ? C'est le levier principal contre le bruit. 4. **La souveraineté et la réversibilité.** Où sont les données, et pouvez-vous partir avec vos SBOM et votre historique ? Le quatrième point est celui qu'on oublie à l'achat et qui coûte le plus cher à la sortie. ## Ressources URL: https://cra-reference.eu/fr/ressources/ Description: Les gabarits, modèles, registres, listes de contrôle et fiches réflexes à reprendre : dossier technique, déclaration UE, notice utilisateur, politique CVD, gabarits de signalement, clauses. Audience: transverse Published 2026-08-19, updated 2026-08-19 Tous les modèles cités sur ce site, rassemblés. Chacun renvoie à la page qui l'explique et qui en donne le contenu détaillé. ### Qualification et classification | Modèle | Contenu | Page de référence | | --- | --- | --- | | **Fiche de qualification PDE** | Nature du produit, connexion, traitement de données à distance, caractère commercial, statut, signataires | [Périmètre](/fr/cra/perimetre-pde/) | | **Fiche d'exclusion** | Texte sectoriel invoqué, justification, signataires | [Exclusions](/fr/cra/exclusions/) | | **Fiche de classification** | Fonctionnalités effectives, annexes examinées, classe retenue, voie d'évaluation | [Méthode de classification](/fr/cra/classes-de-criticite/methode/) | | **Registre de classification** du portefeuille | Vue consolidée, revue annuelle | Idem | ### Conformité et mise sur le marché | Modèle | Contenu | Page de référence | | --- | --- | --- | | **Gabarit de dossier technique** | Plan en huit sections selon l'annexe VII | [Dossier technique](/fr/cra/dossier-technique/) | | **Liste de complétude** du dossier | Treize points à cocher | Idem | | **Déclaration UE de conformité** | Modèle annexe V, français et anglais | [Déclaration](/fr/legal/declaration-de-conformite/) | | **Déclaration simplifiée** | Modèle annexe VI | Idem | | **Notice de cybersécurité** | Modèle annexe II en dix sections | [Documentation utilisateur](/fr/legal/documentation-utilisateur/) | | **Liste de contrôle juridique** | Quinze points, imprimable, signable | [Liste de contrôle](/fr/legal/checklist-mise-sur-le-marche/) | | **Liste de contrôle technique** | Quinze points, imprimable | [Liste technique](/fr/cyber/checklist-technique/) | | **Procès-verbal de revue de conformité** | Structure et signatures | [Processus interne](/fr/legal/marquage-ce-et-dossier/) | ### Vulnérabilités et signalement | Modèle | Contenu | Page de référence | | --- | --- | --- | | **Politique de divulgation coordonnée** | Structure en onze sections | [Politique CVD](/fr/cyber/politique-cvd/) | | **Fichier `security.txt`** | Modèle RFC 9116 | Idem | | **Fiche de qualification** d'exploitation active | À transmettre au juridique sous deux heures | [Procédure 24 h](/fr/cyber/procedure-24h/) | | **Gabarit d'alerte précoce** (24 h) | Champs minimaux | Idem | | **Gabarit de notification** (72 h) | Champs minimaux | Idem | | **Gabarit de rapport final** (14 j / 1 mois) | Champs minimaux | Idem | | **Fiche réflexe** de crise | Format A4, à afficher | Idem | | **Registre des signalements** | Décisions, motivations, accusés | [Obligations de signalement](/fr/legal/obligations-de-signalement/) | ### SBOM et outillage | Modèle | Contenu | Page de référence | | --- | --- | --- | | **Politique de qualité SBOM** | Format, profondeur, seuils, dérogations | [Qualité](/fr/sbom/qualite-et-completude/) | | **Fiche d'outillage** par famille de produits | Outils, commandes, périmètre, exclusions | [Générer un SBOM](/fr/cyber/generer-un-sbom/) | | **Exemple de SBOM commenté** | CycloneDX et SPDX | [Formats](/fr/sbom/formats/) | | **Exemple de VEX** | Statuts et justifications | [VEX](/fr/sbom/vex/) | | **Grille d'évaluation d'outil** | Critères pondérés et protocole | [Critères de choix](/fr/outils/criteres-de-choix/) | ### Propriété intellectuelle | Modèle | Contenu | Page de référence | | --- | --- | --- | | **Politique de licences** | Trois listes par contexte d'usage | [Propriété intellectuelle](/fr/legal/propriete-intellectuelle/) | | **Registre des exceptions** | Composant, licence, conditions, expiration | Idem | | **Grille de diligence** d'un composant open source | Neuf critères | [Intégrer de l'open source](/fr/cra/open-source/integrer-de-l-oss/) | | **Grille d'auto-qualification** de sponsor | Six questions | [Sponsor de logiciel libre](/fr/cra/open-source/sponsor-oss/) | | **Politique de contribution** open source | Cadre des contributions des salariés | [Développeur individuel](/fr/cra/open-source/developpeur-individuel/) | ### Contrats | Modèle | Contenu | Page de référence | | --- | --- | --- | | **Clausier fournisseurs** | SBOM, délais, support, conformité, réversibilité, responsabilité | [Clauses contractuelles](/fr/legal/clauses-contractuelles/) | | **Clauses clients** | Support, SBOM, information, limitation | Idem | ### Gouvernance | Modèle | Contenu | Page de référence | | --- | --- | --- | | **Matrice RACI** | Vingt-deux activités, huit rôles | [RACI](/fr/organisation/raci/) | | **Contrat d'interface** Juridique ↔ Cyber | Livrables croisés, délais, vocabulaire | [Interface](/fr/organisation/interface-legal-cyber/) | | **Registre des périodes de support** | Engagements et composants limitants | [Période de support](/fr/cra/support-et-cycle-de-vie/) | | **Registre des risques de conformité** | Risques, mesures, acceptations nommées | [Exposition](/fr/legal/sanctions-et-exposition/) | | **Tableau de bord de direction** | Quatre blocs, une page | [Indicateurs](/fr/organisation/indicateurs/) | | **Rétroplanning** | Six vagues et leurs dépendances | [Feuille de route](/fr/organisation/feuille-de-route/) | ### Comment les utiliser Ces modèles sont des **structures**, pas des documents à signer en l'état. Chacun doit être adapté à votre organisation, relu par la fonction propriétaire, puis **versionné**. Un modèle repris sans adaptation produit un document générique, qui est précisément ce qu'une autorité de surveillance repère en premier. ## Le SBOM URL: https://cra-reference.eu/fr/sbom/ Description: La nomenclature logicielle : définition, exigence du CRA, formats CycloneDX et SPDX, typologies, qualité, identifiants, VEX, licences SPDX, signature, diffusion et cycle de vie. Audience: transverse Legal basis: Annexe I, partie II, point 1 · Annexe VII, point 2 Published 2026-08-19, updated 2026-08-19 Le **SBOM** (*software bill of materials*, nomenclature logicielle) est l'inventaire structuré, formel et lisible par machine des composants logiciels contenus dans un produit et de leurs relations. Cette section en est la référence technique. Elle est écrite pour être lue par les deux équipes : les pages [Définition](/fr/sbom/definition/), [Ce que le CRA exige](/fr/sbom/exigence-cra/), [VEX](/fr/sbom/vex/) et [La licence comme donnée du SBOM](/fr/sbom/licences-spdx/) sont accessibles sans culture technique, les autres supposent de connaître une chaîne de construction. ### Pourquoi le sujet est devenu réglementaire Le CRA n'a pas inventé le SBOM ; il a rendu obligatoire une pratique déjà répandue, en l'inscrivant dans les exigences essentielles : > **Annexe I, partie II, point 1** — recenser et documenter les vulnérabilités et les > composants contenus dans le produit, **notamment en établissant une nomenclature > logicielle dans un format couramment utilisé et lisible par machine, couvrant au minimum > les dépendances de premier niveau**. Trois expressions y sont décisives, et chacune a une conséquence opérationnelle : - **« format couramment utilisé »** — en pratique **[CycloneDX](https://cyclonedx.org/)** ou **[SPDX](https://spdx.dev/)**. Un tableur n'en est pas un. - **« lisible par machine »** — JSON, XML, tag-value. Un PDF n'est pas lisible par machine. - **« au minimum les dépendances de premier niveau »** — c'est un **plancher légal, pas une cible**. Les attaques de chaîne d'approvisionnement passent majoritairement par les dépendances transitives. ### La chaîne de valeur, en une ligne **SBOM → dossier technique (annexe VII) → déclaration UE de conformité (annexe V) → marquage CE → droit de commercialiser dans l'Union.** C'est la phrase à retenir côté Juridique : le SBOM n'est pas un livrable technique annexe, c'est une **pièce constitutive du dossier permettant d'obtenir le marquage CE**. ### Ce que le SBOM n'est pas - Ce n'est **pas un rapport de vulnérabilités**. C'est la donnée qui permet d'en produire un. - Ce n'est **pas un audit de licences**. C'est la donnée qui permet d'en faire un. - Ce n'est **pas une preuve d'absence de code malveillant**. Un composant peut être correctement inventorié et compromis — voir [Risques de chaîne d'approvisionnement](/fr/cyber/risques-supply-chain/). ### Le test de réalité Une seule question suffit à mesurer votre maturité : **combien de temps vous a-t-il fallu, la dernière fois, pour répondre à « êtes-vous affectés par cette vulnérabilité ? »** Sans SBOM centralisé, la réponse se compte en semaines et repose sur des courriels. Avec, elle se compte en minutes et repose sur une requête. ## Le cycle de vie du SBOM URL: https://cra-reference.eu/fr/sbom/cycle-de-vie/ Description: Un SBOM par construction, immuable et versionné ; conservation alignée sur le dossier technique ; archivage, indexation, restitution et comparaison entre versions. Audience: cyber Legal basis: Art. 31 — conservation de la documentation technique Published 2026-08-19, updated 2026-08-19 ### La règle de base **Un SBOM par construction.** Immuable une fois produit, versionné, associé à l'artefact par son empreinte cryptographique. Corollaires : - on ne **modifie jamais** un SBOM émis ; on en émet un nouveau ; - un SBOM « du produit », sans référence de version ni de construction, n'a pas de valeur ; - deux constructions du même code à deux dates différentes peuvent produire deux SBOM différents, si les dépendances ont été résolues différemment — ce qui est en soi une information utile. ### Les étapes | Étape | Où | Ce qui est produit | | --- | --- | --- | | Génération | Pipeline de construction | Build SBOM | | Validation | Pipeline | Score de qualité, échec sous le seuil | | Signature | Pipeline | SBOM signé, attestation de provenance | | Publication | Plateforme de pilotage | Ingestion, corrélation initiale | | Attachement | Registre d'artefacts | SBOM indexé par empreinte, à côté de l'image | | Surveillance | Plateforme | Réévaluation quotidienne contre les sources | | Enrichissement | PSIRT | Ajout des [VEX](/fr/sbom/vex/) au fil des analyses | | Archivage | Coffre de preuves | Conservation longue durée, immuable | | Restitution | Sur demande | Extraction d'une version historique | | Suppression | Fin de la durée de conservation | Purge tracée | ### La durée de conservation Alignée sur celle du [dossier technique](/fr/cra/dossier-technique/) : **au moins dix ans après la mise sur le marché du produit, ou pendant la période de support si celle-ci est plus longue**. Cela signifie qu'un SBOM produit aujourd'hui pour un produit encore commercialisé dans cinq ans devra être restituable dans quinze ans. Les conséquences pratiques sont sous-estimées : - le **format** doit rester lisible — d'où l'intérêt de formats normalisés plutôt que propriétaires ; - les **clés publiques** de vérification des signatures doivent être conservées ; - le **support de stockage** doit être migré au moins une fois ; - l'**indexation** doit survivre au changement de plateforme. ### L'indexation Un SBOM inaccessible équivaut à un SBOM absent. L'index minimal : | Clé | Pourquoi | | --- | --- | | Produit et version commerciale | Point d'entrée d'une demande d'autorité ou de client | | Référence de construction | Lien avec la chaîne CI | | Empreinte de l'artefact | Preuve de correspondance | | Date de construction et de mise sur le marché | Point de départ des dix ans | | Format et version du format | Choix de l'outil de lecture | | Signature et clé | Vérification | | VEX associés | Contexte de la décision de traitement | ### La comparaison entre versions Le **différentiel de SBOM** entre deux versions répond à des questions récurrentes : - quels composants ont été **ajoutés**, et par quel chemin de dépendance ? - quels composants ont été **mis à jour**, et cela corrige-t-il des vulnérabilités connues ? - quelles **licences** ont fait leur apparition ? - la **surface** augmente-t-elle version après version ? Cette comparaison alimente utilement la revue de changement, et détecte les introductions non intentionnelles — un candidat sérieux au tableau de bord d'ingénierie. ### Le test qui compte Une fois par an, un exercice de restitution : choisir au hasard une version livrée il y a plus de deux ans, et **produire en moins d'une journée** son SBOM signé, sa signature vérifiée, ses VEX et son dossier technique. Tant que cet exercice n'a pas été réussi, le dispositif d'archivage est une hypothèse. ## Qu'est-ce qu'un SBOM URL: https://cra-reference.eu/fr/sbom/definition/ Description: Définition accessible aux deux équipes, données minimales attendues par composant, usages par public, et ce que le SBOM n'est pas. Audience: transverse Published 2026-08-19, updated 2026-08-19 ### La définition Un **SBOM** (*software bill of materials*, nomenclature logicielle) est un **inventaire structuré, formel et lisible par machine des composants logiciels contenus dans un produit et de leurs relations**. L'analogie de l'étiquette des ingrédients est utile pour poser l'idée, et trompeuse au-delà : une étiquette est statique et se lit à l'œil, un SBOM change à chaque construction et n'a de valeur que traité par une machine. ### Les données attendues par composant | Donnée | Pourquoi elle compte | | --- | --- | | **Nom** | Identification humaine | | **Version** | Sans version, aucune corrélation avec une vulnérabilité n'est possible | | **Fournisseur ou éditeur** | Distingue deux composants homonymes | | **Identifiant unique** — [PURL, CPE](/fr/sbom/identifiants/) | Permet la corrélation automatique | | **Empreintes cryptographiques** | Lie l'inventaire à l'artefact réel | | **Licence** en identifiant [SPDX](/fr/sbom/licences-spdx/) | Conformité juridique et propriété intellectuelle | | **Relations de dépendance** | Distingue direct et transitif, permet de remonter le chemin d'introduction | | **Auteur de l'inventaire et horodatage** | Traçabilité, opposabilité | Un inventaire sans version ni identifiant résolvable n'est pas un SBOM exploitable : c'est une liste de noms. ### Les usages, par public | Public | Ce que le SBOM permet | | --- | --- | | **Juridique** | Constituer le dossier technique, démontrer la conformité aux licences, répondre aux questionnaires clients et aux diligences d'investisseurs | | **Cyber / PSIRT** | Répondre en minutes à « êtes-vous affectés ? », prioriser, produire des VEX, alimenter le signalement | | **Achats** | Instruire la diligence fournisseur, comparer des offres sur une base factuelle | | **Produit** | Suivre l'obsolescence, anticiper les fins de support des composants, arbitrer la dette technique | | **Direction** | Mesurer l'exposition du portefeuille, suivre les indicateurs de couverture | ### Ce que le SBOM n'est pas - **Pas un rapport de vulnérabilités.** C'est la donnée d'entrée qui permet d'en produire un, en confrontant l'inventaire à des bases qui évoluent chaque jour. - **Pas un audit de licences.** C'est la donnée qui permet d'en faire un. - **Pas une preuve d'absence de code malveillant.** Un composant peut être correctement inventorié et compromis. Le SBOM répond à « qu'y a-t-il dedans », pas à « est-ce sain ». - **Pas un document figé.** Un SBOM est attaché à une **construction** précise. Un SBOM « du produit », sans version, n'a pas de sens. ### Le test de réalité Une organisation sait où elle en est avec une seule question : **combien de temps vous a-t-il fallu, la dernière fois, pour répondre à « êtes-vous affectés par cette vulnérabilité, et dans quelles versions livrées ? »** - Plusieurs semaines, par courriels et tableurs : vous n'avez pas de SBOM exploitable. - Quelques jours, en interrogeant chaque équipe : vous générez des SBOM mais vous ne les centralisez pas. - Quelques minutes, par une requête : le dispositif décrit dans [Générer et piloter](/fr/organisation/deux-niveaux/) est en place. ## Diffusion et confidentialité URL: https://cra-reference.eu/fr/sbom/diffusion-et-confidentialite/ Description: Faut-il publier son SBOM ? Niveaux de diffusion, clauses contractuelles, régime de confidentialité des informations transmises aux autorités, et la matrice décisionnelle. Audience: legal Legal basis: Annexe VII — dossier technique tenu à disposition des autorités · Annexe II, point 10 — indication de l'endroit où obtenir le SBOM · Art. 66 — confidentialité Published 2026-08-19, updated 2026-08-19 ### Ce que le règlement impose — et n'impose pas **Impose** : que le SBOM figure dans le **dossier technique**, tenu à la disposition des autorités de surveillance du marché. **N'impose pas** : sa publication, ni sa communication systématique aux clients. **Prévoit toutefois** : que les informations à l'utilisateur indiquent, **le cas échéant**, l'endroit où le SBOM peut être obtenu (annexe II). La formulation suppose donc d'avoir tranché la question et de savoir répondre. ### Le débat : le SBOM aide-t-il l'attaquant ? L'argument avancé contre la publication est qu'un SBOM révèle la composition exacte du produit et facilite le ciblage. Il mérite d'être examiné, pas balayé. **Ce qui l'affaiblit :** - un attaquant motivé détermine la composition d'un binaire par analyse, sans votre aide ; - les vulnérabilités des composants sont **publiques par construction** ; - l'asymétrie joue en votre défaveur si vous ne connaissez pas votre propre composition aussi bien que l'attaquant. **Ce qui le renforce :** - un SBOM public **daté** permet de repérer les produits non mis à jour ; - il facilite le ciblage de masse par balayage automatisé du marché ; - il peut révéler des informations couvertes par le secret des affaires — architecture, fournisseurs, choix techniques. Position raisonnable : **le SBOM n'est pas un secret, mais sa diffusion large sans VEX associé est une mauvaise pratique**. Publier un inventaire brut sans dire ce qui est exploitable transfère le bruit à vos clients. ### Les niveaux de diffusion | Niveau | Destinataire | Quand | | --- | --- | --- | | **Interne** | Équipes, plateforme de pilotage | Toujours | | **Autorités sur demande** | Surveillance du marché, organisme notifié | Obligatoire | | **Client sous accord de confidentialité** | Grand compte, secteur régulé | Sur demande contractuelle | | **Client via portail authentifié** | Base installée | Politique standard recommandée | | **Public** | Tous | Décision explicite, produit par produit | Le niveau « portail authentifié » est le bon équilibre par défaut : il satisfait la demande légitime des clients, trace les accès, et permet de fournir le SBOM **accompagné des VEX et des avis**, ce qui est bien plus utile qu'un inventaire seul. ### Les clauses contractuelles Côté **client**, ce qui doit être écrit : - le **format** et la version fournis ; - la **profondeur** couverte, et la déclaration honnête de complétude ; - la **fréquence** de mise à jour — par version livrée, ou à intervalle défini ; - les **modalités d'accès** : portail, sur demande, avec ou sans authentification ; - la **confidentialité** et l'interdiction de rediffusion ; - l'articulation avec les **avis de sécurité** et les VEX. Côté **fournisseur**, les clauses symétriques que vous exigez figurent dans [Clauses contractuelles](/fr/legal/clauses-contractuelles/). ### La confidentialité côté autorités Le règlement encadre l'usage des informations obtenues par les autorités, les organismes notifiés et l'ENISA : elles sont traitées dans le respect des **secrets d'affaires** et des **droits de propriété intellectuelle**, et ne sont utilisées que dans la mesure nécessaire à l'exercice de leurs missions. Cela ne dispense pas de marquer explicitement les documents transmis et de tracer les échanges. ### La matrice décisionnelle | Critère | Vers la restriction | Vers l'ouverture | | --- | --- | --- | | Nature du produit | Composant de sécurité, produit critique | Produit grand public | | Base installée | Petite et identifiée | Large et anonyme | | Demande client | Absente | Contractuelle et récurrente | | Maturité de vos VEX | Faible : publier créerait du bruit | Élevée : publier réduit les sollicitations | | Positionnement | Le secret de composition est un avantage | La transparence est un argument commercial | La décision est prise **par produit**, documentée, et revue annuellement. Elle est de la compétence conjointe du Juridique et de la direction produit, pas de l'ingénierie seule. ## Ce que le CRA exige du SBOM URL: https://cra-reference.eu/fr/sbom/exigence-cra/ Description: Le texte exact, le décryptage de ses trois expressions clés, la question de la publication, l'habilitation de la Commission, et la chaîne qui mène au marquage CE. Audience: transverse Legal basis: Annexe I, partie II, point 1 · Annexe VII, point 2 · Art. 13 — habilitation à préciser le format du SBOM Published 2026-08-19, updated 2026-08-19 ### Le texte > **Annexe I, partie II, point 1** — Les fabricants de produits comportant des éléments > numériques **recensent et documentent les vulnérabilités et les composants** contenus dans > ces produits, **notamment en établissant une nomenclature logicielle dans un format > couramment utilisé et lisible par machine, couvrant au minimum les dépendances de premier > niveau** des produits. ### Le décryptage #### « format couramment utilisé » En pratique, deux formats répondent au critère : **[CycloneDX](/fr/sbom/formats/cyclonedx/)** et **[SPDX](/fr/sbom/formats/spdx/)**. Tous deux sont normalisés, largement outillés et interopérables. Un tableur, une liste dans un document, un export propriétaire d'une plateforme ne sont pas des formats couramment utilisés au sens de l'exigence. #### « lisible par machine » JSON, XML, YAML, tag-value. **Un PDF n'est pas lisible par machine**, même s'il contient un tableau. Le critère n'est pas la lisibilité par un humain mais la capacité d'un programme à en extraire des données structurées sans heuristique. #### « au minimum les dépendances de premier niveau » C'est un **plancher légal, pas une cible**. Les dépendances de premier niveau sont celles que vous déclarez explicitement. Les dépendances **transitives** — celles que vos dépendances entraînent avec elles — sont généralement dix à cent fois plus nombreuses, et c'est **par elles que passent la plupart des incidents de chaîne d'approvisionnement**. Un SBOM limité au premier niveau satisfait la lettre de l'exigence et manque son objet. La position à tenir est la **profondeur complète**, avec la distinction explicite entre direct et transitif — voir [Qualité et complétude](/fr/sbom/qualite-et-completude/). ### Faut-il publier le SBOM ? **Non.** Le règlement n'impose pas la publication du SBOM. Il impose qu'il figure dans le **[dossier technique](/fr/cra/dossier-technique/)**, tenu à la disposition des autorités de surveillance du marché. Sa communication aux clients relève d'une **décision commerciale et contractuelle**, traitée dans [Diffusion et confidentialité](/fr/sbom/diffusion-et-confidentialite/). L'annexe II prévoit en revanche que les informations à l'utilisateur indiquent, le cas échéant, **où le SBOM peut être obtenu** — ce qui suppose d'avoir tranché la question. ### Ce que la Commission peut encore préciser Le règlement habilite la Commission à **spécifier, par acte d'exécution, le format et les éléments** de la nomenclature logicielle. Un tel acte fixerait un socle commun et réduirait l'incertitude actuelle sur le niveau de détail attendu. > **Conséquence sur vos choix.** Produire dès aujourd'hui un SBOM **riche** — profondeur > complète, licences, empreintes, relations — est la position robuste : un acte d'exécution > ultérieur ne demandera jamais moins que ce que les formats standards permettent déjà > d'exprimer. ### La chaîne à retenir **SBOM → dossier technique (annexe VII) → déclaration UE de conformité (annexe V) → marquage CE → droit de commercialiser dans l'Union.** C'est la formulation à employer côté Juridique. Elle transforme le SBOM d'un sujet d'ingénierie en un **prérequis d'accès au marché**. ### Ce qui accompagne nécessairement le SBOM Le point 1 de l'annexe I, partie II, ne vit pas seul. Un SBOM sans les points 2 à 8 ne démontre rien : il faut aussi **traiter** les vulnérabilités identifiées, **publier** les avis, tenir une **politique CVD** et **diffuser** les correctifs. Voir [Traitement des vulnérabilités](/fr/cra/exigences-essentielles/traitement-des-vulnerabilites/). ## Les formats URL: https://cra-reference.eu/fr/sbom/formats/ Description: CycloneDX et SPDX : origines, normalisation, points forts respectifs, comparatif, et le choix d'un format pivot avec export vers l'autre. Audience: cyber Legal basis: Annexe I, partie II, point 1 — « format couramment utilisé et lisible par machine » Published 2026-08-19, updated 2026-08-19 Deux formats répondent à l'exigence du règlement. Ils sont tous deux légitimes, normalisés et largement outillés ; ils n'ont pas la même histoire ni les mêmes points forts. ### Comparatif | | **[CycloneDX](/fr/sbom/formats/cyclonedx/)** | **[SPDX](/fr/sbom/formats/spdx/)** | | --- | --- | --- | | Origine | OWASP | Linux Foundation | | Normalisation | **[ECMA-424](https://ecma-international.org/publications-and-standards/standards/ecma-424/)** | **ISO/IEC 5962** (pour SPDX 2.2.1) | | Orientation d'origine | **Sécurité** | **Conformité des licences** | | Sérialisations | JSON, XML, Protobuf | Tag-value, JSON, YAML, RDF/XML, tableur | | Vulnérabilités dans le document | **Natif** (`vulnerabilities`) | Via profil sécurité (SPDX 3.x) | | **VEX** | **Natif** | Par mécanismes externes ou profil | | Richesse licences | Bonne | **Référence du domaine** (liste et expressions SPDX) | | Extensions | SaaSBOM, HBOM, ML-BOM, CBOM, OBOM | Profils SPDX 3 : sécurité, build, IA, données, licensing | | Adoption | Forte côté outillage sécurité et CI/CD | Forte côté conformité juridique et distributions | ### Ce qui les rapproche Les deux formats expriment les mêmes notions de base : composants, versions, identifiants, empreintes, licences, relations de dépendance, métadonnées de création. Les outils de conversion existent dans les deux sens. ### Ce qui les distingue vraiment **[CycloneDX](https://cyclonedx.org/)** a été conçu par une communauté sécurité, pour alimenter des chaînes de traitement automatisées. Il porte nativement les vulnérabilités et les assertions d'exploitabilité, ce qui en fait le format de travail naturel d'une plateforme de pilotage. **[SPDX](https://spdx.dev/)** a été conçu par une communauté de conformité juridique, autour de la question « quelles licences y a-t-il dans ce logiciel, et qu'imposent-elles ». Sa liste de licences et ses expressions de licence font autorité mondiale, y compris pour CycloneDX qui les réutilise. ### La conversion et ses pertes Convertir n'est pas neutre. Les pertes typiques : - les **extensions propres** à un format n'ont pas d'équivalent dans l'autre ; - les **relations** entre composants sont exprimées différemment et peuvent s'aplatir ; - les **assertions VEX** de CycloneDX n'ont pas de destination naturelle en SPDX 2.x ; - les **métadonnées de construction** peuvent disparaître. Toute conversion doit donc être documentée : outil utilisé, version, pertes connues. ### Le choix retenu **Format pivot : CycloneDX**, dans une version récente, produit par la chaîne de construction et consommé par la plateforme de pilotage. C'est le format qui porte nativement le [VEX](/fr/sbom/vex/), donc celui qui permet de documenter les décisions de ne pas corriger. **Export SPDX** à la demande, pour les usages juridiques et pour les clients qui l'exigent contractuellement. Ce choix doit être **figé et documenté**, avec les versions minimales acceptées, et appliqué uniformément : deux équipes produisant deux formats différents rendent le portefeuille incomparable. ## CycloneDX URL: https://cra-reference.eu/fr/sbom/formats/cyclonedx/ Description: Le format de l'OWASP normalisé ECMA-424 : structure du document, extensions BOM, prise en charge native du VEX, et exemple commenté. Audience: cyber Published 2026-08-19, updated 2026-08-19 ### Identité Format créé au sein de l'**OWASP**, normalisé sous la référence **[ECMA-424](https://ecma-international.org/publications-and-standards/standards/ecma-424/)**. Sérialisations **JSON** (recommandée), **XML** et **Protobuf**. Conçu par une communauté sécurité, pour être produit et consommé par des machines dans des chaînes automatisées. ### Structure du document | Section | Contenu | | --- | --- | | `metadata` | Horodatage, outil ayant produit le document, auteur, composant décrit (le produit lui-même), fournisseur, licences du produit | | `components` | La liste des composants : type, nom, version, éditeur, identifiants (`purl`, `cpe`), empreintes, licences, description | | `dependencies` | Le **graphe** : quel composant dépend de quel autre. C'est cette section qui distingue direct et transitif | | `services` | Services externes appelés — utile pour les architectures distribuées | | `compositions` | Déclaration de **complétude** : cet inventaire est-il complet, incomplet, ou de complétude inconnue | | `vulnerabilities` | Vulnérabilités connues affectant les composants, avec source, score, état | | `annotations` | Assertions signées portant sur tout ou partie du document | | `formulation` | Comment l'artefact a été produit : chaîne de construction, étapes, environnement | La section `compositions` est sous-utilisée et pourtant décisive pour la conformité : elle permet de **déclarer explicitement** qu'un inventaire ne couvre que les dépendances de premier niveau, plutôt que de laisser croire à une complétude qui n'existe pas. ### Les extensions CycloneDX ne se limite pas au logiciel : | Extension | Objet | | --- | --- | | **SaaSBOM** | Services et interfaces d'une architecture distribuée | | **HBOM** | Nomenclature matérielle | | **ML-BOM** | Modèles d'apprentissage automatique, jeux de données, cartes de modèle | | **CBOM** | Inventaire cryptographique — algorithmes, tailles de clés, protocoles | | **OBOM** | Configuration d'exploitation | | **VDR / VEX** | Rapport de vulnérabilités et assertions d'exploitabilité | Le **CBOM** mérite une attention particulière : il est l'outil naturel pour préparer la migration post-quantique, sujet qui rejoindra le CRA par la voie de l'état de l'art attendu par l'annexe I. ### Exemple commenté ```json { "bomFormat": "CycloneDX", "specVersion": "1.6", "serialNumber": "urn:uuid:3e671687-395b-41f5-a30f-a58921a69b79", "version": 1, "metadata": { "timestamp": "2026-08-19T09:12:04Z", "tools": { "components": [ { "type": "application", "name": "syft", "version": "1.x" } ] }, "component": { "type": "application", "bom-ref": "pkg:generic/acme-gateway@4.2.1", "name": "acme-gateway", "version": "4.2.1", "licenses": [ { "license": { "id": "Apache-2.0" } } ] } }, "components": [ { "type": "library", "bom-ref": "pkg:maven/org.example/http-client@5.3.1", "name": "http-client", "group": "org.example", "version": "5.3.1", "purl": "pkg:maven/org.example/http-client@5.3.1", "licenses": [ { "license": { "id": "MIT" } } ], "hashes": [ { "alg": "SHA-256", "content": "9f2c…" } ] } ], "dependencies": [ { "ref": "pkg:generic/acme-gateway@4.2.1", "dependsOn": [ "pkg:maven/org.example/http-client@5.3.1" ] } ], "compositions": [ { "aggregate": "complete", "assemblies": [ "pkg:generic/acme-gateway@4.2.1" ] } ] } ``` Points d'attention sur cet exemple : - `bom-ref` est la clé interne qui permet de relier composants et dépendances ; elle doit être stable d'une construction à l'autre pour que les comparaisons soient utiles ; - `purl` est l'identifiant qui rend la corrélation fiable — voir [Identifiants](/fr/sbom/identifiants/) ; - `hashes` lie l'inventaire à l'artefact réel : sans empreinte, rien ne prouve que ce SBOM décrit bien le binaire livré ; - `compositions.aggregate` déclare la complétude et engage le producteur. ### Pourquoi vous en faites votre format pivot Trois raisons : la prise en charge **native** du [VEX](/fr/sbom/vex/), donc la capacité à documenter les décisions de ne pas corriger dans le même écosystème ; la richesse des métadonnées de construction, utile pour la traçabilité exigée par l'annexe VII ; et l'ampleur de l'outillage disponible en CI/CD. ## SPDX URL: https://cra-reference.eu/fr/sbom/formats/spdx/ Description: Le format de la Linux Foundation normalisé ISO/IEC 5962 : structure, profils SPDX 3, liste et expressions de licence faisant autorité, et exemple commenté. Audience: legal Published 2026-08-19, updated 2026-08-19 ### Identité *Software Package Data Exchange*, créé au sein de la **Linux Foundation**, normalisé **ISO/IEC 5962** pour la version 2.2.1. Sérialisations **tag-value**, **JSON**, **YAML**, **RDF/XML** et tableur. Conçu par une communauté de conformité juridique, autour de la question des licences. ### Structure du document (SPDX 2.x) | Section | Contenu | | --- | --- | | *Document creation information* | Version SPDX, identifiant du document, licence des données, créateur, horodatage | | *Packages* | Les paquets : nom, version, fournisseur, empreinte, licence **déclarée** et licence **constatée**, notice de copyright, provenance | | *Files* | Le détail fichier par fichier, avec licence et copyright — granularité rare mais décisive en cas d'audit | | *Snippets* | Fragments de code d'origine distincte au sein d'un fichier | | *Relationships* | Les relations : contient, dépend de, est généré par, est un fichier source de… | | *Annotations* | Commentaires horodatés et attribués | | *Other licensing information* | Licences non référencées dans la liste SPDX | La distinction entre **licence déclarée** (`PackageLicenseDeclared`, ce que le projet affirme) et **licence constatée** (`PackageLicenseConcluded`, ce que l'analyse établit) est propre à SPDX et sans équivalent direct ailleurs. Elle est précieuse en contentieux : elle documente le fait que vous avez vérifié plutôt que cru sur parole. ### SPDX 3 et les profils SPDX 3 réorganise le modèle autour de **profils** activables : *core*, *software*, *licensing*, *security*, *build*, *AI*, *dataset*, *extension*. Cela rapproche SPDX de la couverture fonctionnelle de CycloneDX tout en conservant sa profondeur juridique. ### La liste de licences SPDX C'est l'apport le plus universel du projet : une **liste normalisée d'identifiants de licence** — `MIT`, `Apache-2.0`, `GPL-3.0-or-later`, `LGPL-2.1-only`, `MPL-2.0`, `BSD-3-Clause`, `AGPL-3.0-only` — utilisée par l'ensemble de l'écosystème, y compris par CycloneDX. Les **expressions de licence** permettent d'exprimer les cas composés : | Expression | Sens | | --- | --- | | `MIT` | Licence unique | | `MIT OR Apache-2.0` | Double licence, au choix du destinataire | | `GPL-2.0-only AND MIT` | Les deux s'appliquent cumulativement | | `GPL-2.0-only WITH Classpath-exception-2.0` | Licence assortie d'une exception normalisée | | `NOASSERTION` | Licence indéterminée — **à traiter comme un défaut bloquant** | Ce que chacune de ces licences impose réellement est traité dans [Les familles de licences](/fr/licences/familles/). ### Exemple commenté (tag-value) ``` SPDXVersion: SPDX-2.3 DataLicense: CC0-1.0 SPDXID: SPDXRef-DOCUMENT DocumentName: acme-gateway-4.2.1 DocumentNamespace: https://acme.example.org/spdx/acme-gateway-4.2.1 Creator: Tool: syft-1.x Created: 2026-08-19T09:12:04Z PackageName: acme-gateway SPDXID: SPDXRef-Package-acme-gateway PackageVersion: 4.2.1 PackageDownloadLocation: NOASSERTION FilesAnalyzed: true PackageLicenseDeclared: Apache-2.0 PackageLicenseConcluded: Apache-2.0 PackageCopyrightText: NOASSERTION PackageName: http-client SPDXID: SPDXRef-Package-http-client PackageVersion: 5.3.1 PackageLicenseDeclared: MIT PackageLicenseConcluded: MIT ExternalRef: PACKAGE-MANAGER purl pkg:maven/org.example/http-client@5.3.1 Relationship: SPDXRef-Package-acme-gateway DEPENDS_ON SPDXRef-Package-http-client ``` Points d'attention : - `PackageLicenseConcluded: NOASSERTION` en masse est le signal d'un outil qui n'a pas analysé les fichiers ; c'est un défaut de qualité, pas une propriété du composant ; - `ExternalRef … purl` porte l'identifiant qui rend la corrélation fiable ; - `DocumentNamespace` doit être unique et stable : c'est l'identité du document. ### Quand vous produisez du SPDX - Lorsqu'un **client l'exige contractuellement**. - Pour les **livrables juridiques** : fichier d'attributions, réponses aux diligences, préparation d'un audit de licences. - Lorsqu'un **écosystème amont** le publie déjà dans ce format et que vous l'agrégez. Dans tous les autres cas, votre format pivot reste [CycloneDX](/fr/sbom/formats/cyclonedx/), avec conversion documentée. ## Les identifiants de composants URL: https://cra-reference.eu/fr/sbom/identifiants/ Description: PURL, CPE, SWID, empreintes : pourquoi l'appariement entre un composant et une vulnérabilité est la cause numéro un des faux positifs, et comment le fiabiliser. Audience: cyber Published 2026-08-19, updated 2026-08-19 Tout le dispositif repose sur une opération apparemment triviale : **relier un composant de votre SBOM à une vulnérabilité publiée**. C'est là que se joue la fiabilité de l'ensemble, et c'est là que la plupart des dispositifs échouent. ### Les identifiants disponibles #### PURL — *package URL* Identifiant canonique par écosystème, de la forme `pkg:type/namespace/name@version?qualifiers`. ``` pkg:maven/org.example/http-client@5.3.1 pkg:npm/%40scope/package@1.2.3 pkg:pypi/requests@2.32.3 pkg:golang/github.com/example/mod@v1.4.0 pkg:deb/debian/openssl@3.0.11-1~deb12u2?arch=amd64 ``` **À privilégier systématiquement.** Le PURL est déterministe : il décrit sans ambiguïté un paquet dans un écosystème donné, ce qui rend la corrélation exacte. #### CPE — *common platform enumeration* Identifiant historique du NVD, de la forme `cpe:2.3:a:vendor:product:version:...`. Nécessaire pour interroger le NVD, mais **structurellement imprécis** : le couple « fournisseur / produit » est saisi manuellement, avec des variantes orthographiques, des homonymies et des CPE manquants. C'est la **cause numéro un des faux positifs et des faux négatifs**. #### SWID Étiquettes d'identification logicielle normalisées, peu répandues hors de certains environnements d'entreprise. #### Empreintes cryptographiques SHA-256 ou équivalent, calculées sur l'artefact. Elles n'identifient pas un composant dans un référentiel, mais elles **lient l'inventaire à l'objet réel** — ce qui est indispensable pour qu'un SBOM soit une preuve et pas une déclaration. #### OmniBOR / GitOID Identifiants dérivés du contenu source, permettant une traçabilité fine jusqu'au fichier. Émergent, à surveiller pour les cas où la granularité fichier est nécessaire. ### Le problème d'appariement Trois défaillances typiques : | Défaillance | Exemple | Conséquence | | --- | --- | --- | | **Faux positif par homonymie** | Deux produits de fournisseurs différents portant le même nom | Alerte sur un composant que vous n'avez pas | | **Faux négatif par CPE manquant** | Une vulnérabilité publiée sans CPE, ou avec un CPE erroné | Vulnérabilité réelle non détectée | | **Faux positif par version** | Une correction rétroportée par une distribution sans changement de numéro amont | Alerte sur une version en réalité corrigée | Le troisième cas est particulièrement pénible : les distributions Linux corrigent massivement par rétroportage, en conservant le numéro de version amont. Un scanner qui ne connaît pas la distribution signale des centaines de vulnérabilités déjà corrigées. ### Comment fiabiliser 1. **Exiger un `purl` valide** sur chaque composant, et faire échouer la construction en dessous d'un seuil de couverture. 2. **Interroger les bases par écosystème** — OSV en premier lieu — plutôt que de tout corréler par CPE. 3. **Renseigner les métadonnées de distribution** lorsque le composant vient d'un paquet système, pour que l'outil applique la bonne base de correctifs. 4. **Conserver les empreintes**, pour pouvoir vérifier a posteriori qu'un SBOM décrit bien l'artefact livré. 5. **Documenter les exceptions d'appariement** en [VEX](/fr/sbom/vex/) plutôt qu'en supprimant l'alerte : une alerte supprimée disparaît, une alerte documentée reste traçable. ### Le lien avec les faux positifs La qualité des identifiants détermine directement le volume de bruit que subiront les équipes. C'est un investissement d'infrastructure, pas un réglage d'outil : voir [Maîtriser les faux positifs](/fr/cyber/faux-positifs/). ## La licence comme donnée du SBOM URL: https://cra-reference.eu/fr/sbom/licences-spdx/ Description: Identifiants et expressions SPDX, ce que le SBOM permet de calculer en matière de conformité juridique, et la qualité de donnée sans laquelle rien n'est exploitable. Audience: legal Published 2026-08-19, updated 2026-08-20 Le CRA n'impose pas la conformité aux licences. Mais **le SBOM qu'il rend obligatoire est exactement l'outil qui permet de la démontrer** — c'est le meilleur argument de financement du projet côté Juridique, et son bénéfice le plus immédiat. Cette page traite de la licence **en tant que donnée** : comment elle s'exprime dans un SBOM et ce qu'on peut en calculer. Le fond du droit est ailleurs : - **ce que chaque famille impose** → [Les familles de licences](/fr/licences/familles/) ; - **quand une obligation se déclenche** → [Ce qui déclenche une obligation](/fr/licences/mecanismes/) ; - **le verdict par type de produit** → [Neuf scénarios](/fr/licences/scenarios/) ; - **votre politique et votre processus** → [Propriété intellectuelle](/fr/legal/propriete-intellectuelle/). ### Les identifiants SPDX La **[liste de licences SPDX](https://spdx.org/licenses/)** est le référentiel mondial des identifiants de licence : `MIT`, `Apache-2.0`, `BSD-3-Clause`, `MPL-2.0`, `LGPL-2.1-only`, `GPL-3.0-or-later`, `AGPL-3.0-only`, et plusieurs centaines d'autres. CycloneDX comme SPDX l'utilisent. Un identifiant normalisé est ce qui rend une licence **calculable** : sans lui, « GPL v3 ou supérieure », « GPLv3+ » et « GNU General Public License version 3 » sont trois chaînes distinctes qu'aucune politique automatique ne peut confronter à une liste. ### Les expressions de licence Elles couvrent les cas composés, et chacune a une conséquence juridique différente : | Expression | Sens | | --- | --- | | `MIT` | Licence unique | | `MIT OR Apache-2.0` | **Au choix du destinataire** : vous sélectionnez celle qui vous convient, et vous le documentez | | `GPL-2.0-only AND MIT` | **Cumulatif** : les deux jeux d'obligations s'appliquent | | `GPL-2.0-only WITH Classpath-exception-2.0` | Licence assortie d'une **exception** normalisée qui en limite la portée — à ne jamais ignorer, elle change le verdict | | `LicenseRef-…` | Licence hors liste SPDX, dont le texte doit être joint au document | | `NOASSERTION` | **Indéterminée** — un défaut bloquant, pas une licence | Le suffixe `-only` ou `-or-later` n'est pas cosmétique : il détermine si vous pouvez appliquer une version ultérieure de la licence, et donc la compatibilité avec le reste de l'arbre. `GPL-2.0-only` et `GPL-2.0-or-later` n'ont pas les mêmes conséquences. ### Déclarée contre constatée Le format SPDX distingue deux champs que CycloneDX ne sépare pas aussi nettement : | Champ | Signification | | --- | --- | | `PackageLicenseDeclared` | Ce que le projet **affirme** — le champ du manifeste, le fichier `LICENSE` | | `PackageLicenseConcluded` | Ce que l'**analyse établit**, après examen du contenu des fichiers | L'écart entre les deux est la donnée intéressante. Un dépôt déclaré `MIT` dont l'analyse conclut `MIT AND GPL-2.0-only` a un sous-dossier que personne n'avait regardé — c'est exactement le piège des [licences multiples dans un même dépôt](/fr/licences/pieges/). Documenter la licence constatée n'est pas une coquetterie : c'est ce qui démontre, en cas de litige, que vous avez **vérifié** plutôt que cru sur parole. ### Ce que le SBOM permet de calculer Une fois les licences correctement renseignées, quatre opérations deviennent automatiques : | Opération | Sortie | | --- | --- | | Confrontation à la **politique** par contexte d'usage | Blocage ou avertissement en CI | | Génération du **fichier d'attributions** | `NOTICE` livré avec le produit | | **Inventaire par licence** du portefeuille | Rapport pour un audit ou une diligence | | **Différentiel** entre deux versions | Détection d'un changement de licence en amont | Le dernier point est sous-estimé : comparer le champ de licence d'une version à l'autre est la seule façon de repérer à temps qu'un composant d'infrastructure a changé de licence — voir [Les pièges](/fr/licences/pieges/). ### La qualité de donnée, condition de tout le reste Un SBOM dont une part significative des composants porte `NOASSERTION` ne permet aucune analyse. Les causes habituelles : | Cause | Remède | | --- | --- | | Le générateur ne lit que les manifestes | Ajouter un outil d'**analyse de contenu**, à cadence réduite | | Le manifeste ne déclare pas de licence | Remonter à la source, et traiter l'absence comme bloquante | | Licence exprimée en texte libre non normalisé | Normalisation vers un identifiant SPDX | | Composant vendorisé, absent du manifeste | Analyse par empreinte de fichier | Le seuil de `NOASSERTION` toléré doit figurer dans la [politique de qualité SBOM](/fr/sbom/qualite-et-completude/), au même titre que la couverture des identifiants — et être **bloquant** en construction. ### Référentiels utiles **ISO/IEC 5230** (OpenChain, conformité des licences) et **ISO/IEC 18974** (OpenChain, assurance sécurité du logiciel libre) décrivent des systèmes de management reconnus, utiles pour structurer le dispositif et pour répondre aux exigences de clients grands comptes. ## Qualité, complétude et profondeur URL: https://cra-reference.eu/fr/sbom/qualite-et-completude/ Description: Critères de qualité d'un SBOM, notation automatisée, seuils bloquants en CI, profondeur des dépendances transitives, et les sept pièges qui produisent des inventaires faux. Audience: cyber Published 2026-08-19, updated 2026-08-19 Un SBOM incomplet est pire qu'absent : il donne une assurance fausse. Cette page définit ce qu'est un SBOM utilisable et comment le vérifier automatiquement. ### Les critères de qualité | Critère | Question | Vérifiable | | --- | --- | --- | | **Complétude** | Tous les composants sont-ils présents ? | Par écart avec l'[Analyzed SBOM](/fr/sbom/typologies/) | | **Exactitude** | Les versions correspondent-elles à l'artefact réel ? | Par empreinte | | **Fraîcheur** | Le SBOM correspond-il à la dernière construction ? | Par horodatage et référence de build | | **Identifiants résolvables** | Chaque composant porte-t-il un `purl` ou un `cpe` valide ? | Automatique | | **Licences renseignées** | Quelle proportion de `NOASSERTION` ? | Automatique | | **Relations exprimées** | Le graphe de dépendances est-il présent ? | Automatique | | **Absence d'inconnus** | Combien de composants sans nom, sans version, ou non identifiés ? | Automatique | | **Complétude déclarée** | La section de composition indique-t-elle honnêtement la couverture ? | Automatique | ### La notation automatisée Chaque SBOM produit reçoit un **score** calculé sur ces critères, et le seuil est **bloquant** en CI. La politique doit fixer, explicitement : - le score minimal pour qu'une construction soit **promouvable** en production ; - la proportion maximale tolérée de composants sans identifiant résolvable ; - la proportion maximale de licences `NOASSERTION` ; - l'écart maximal toléré entre Build SBOM et Analyzed SBOM. Sans seuil chiffré, la « qualité du SBOM » reste une intention. Avec un seuil bloquant, elle devient une propriété du pipeline. ### La profondeur : direct et transitif Le règlement exige **au minimum les dépendances de premier niveau**. Ce plancher est insuffisant en pratique. | | Dépendances directes | Dépendances transitives | | --- | --- | --- | | Définition | Déclarées explicitement par vous | Entraînées par vos dépendances | | Volume typique | Dizaines | **Centaines à milliers** | | Maîtrise | Vous les choisissez | Vous les subissez | | Part des incidents de chaîne d'approvisionnement | Minoritaire | **Majoritaire** | La doctrine retenue : **profondeur complète**, avec la distinction explicite direct / transitif dans le graphe, pour permettre la priorisation et pour identifier le chemin d'introduction d'un composant problématique. #### Quelles dépendances inclure | Catégorie | Dans le SBOM du produit livré ? | | --- | --- | | Dépendances d'**exécution** | **Oui**, sans discussion | | Dépendances de **compilation** dont le résultat est embarqué | **Oui** | | Dépendances de **compilation** non embarquées | Dans un SBOM de chaîne de construction distinct | | Dépendances de **test** | **Non** dans le SBOM du produit — leur présence est une cause majeure de faux positifs | | Paquets de l'**image de base** du conteneur | **Oui** s'ils sont livrés avec le produit | ### Les sept pièges **1. Binaires liés statiquement.** Une bibliothèque C ou Rust compilée dans l'exécutable n'apparaît dans aucun manifeste. Remède : analyse du binaire, et outils spécialisés par langage. **2. Code vendorisé.** Des sources tierces copiées dans votre dépôt, souvent modifiées. Remède : détection par empreinte de fichier, du type de celle que pratiquent les outils d'analyse de composition orientés licences. **3. Dépendances système du conteneur.** L'image de base apporte des dizaines de paquets. Remède : générer le SBOM sur l'**image**, pas seulement sur l'application ; réduire la surface avec des images minimales. **4. Artefacts multi-langages.** Un paquet Python embarquant une bibliothèque native compilée, un module Node avec un binaire. Remède : combiner plusieurs générateurs. **5. Code généré à la construction.** Le générateur lui-même a des dépendances, et le code produit peut en embarquer. Remède : documenter la chaîne de génération dans le SBOM. **6. Micrologiciels.** Systèmes de fichiers embarqués, partitions, blobs binaires. Remède : outils d'analyse de micrologiciel, et exigence de SBOM auprès du fournisseur de la plateforme. **7. Composants renommés ou reconditionnés.** Le même composant sous deux noms selon l'écosystème. Remède : normalisation par `purl` — voir [Identifiants](/fr/sbom/identifiants/). ### Ce qu'il faut écrire Une **politique de qualité SBOM**, d'une page, qui fixe : le format et la version, la profondeur exigée, les catégories de dépendances incluses, le score minimal, les seuils bloquants, la procédure de dérogation temporaire et son expiration automatique. ## Signature et intégrité URL: https://cra-reference.eu/fr/sbom/signature-et-integrite/ Description: Pourquoi un SBOM non signé n'est pas une preuve : signature, attestations de provenance, niveaux SLSA, builds reproductibles et journal de transparence. Audience: cyber Legal basis: Annexe I, partie I — intégrité · Annexe I, partie II, point 7 — diffusion sécurisée Published 2026-08-19, updated 2026-08-19 ### Le problème Un fichier JSON posé à côté d'un artefact n'engage personne. Rien n'y prouve : - **qui** l'a produit ; - **quand** il a été produit ; - **à quel artefact exactement** il correspond ; - qu'il **n'a pas été modifié** depuis. Un SBOM non signé est une déclaration, pas une preuve. Pour un dossier technique destiné à être opposé dix ans plus tard à une autorité, la différence est décisive. ### Les mécanismes #### Signature du document Signer le SBOM lui-même, en attachant la signature à l'artefact dans le registre. Deux approches courantes : signature détachée classique avec une clé de l'organisation, ou signature via une infrastructure de signature de chaîne d'approvisionnement du type **Sigstore / cosign**, avec identité éphémère et **journal de transparence**. L'apport du journal de transparence est spécifique : il rend la signature **vérifiable publiquement et horodatée**, ce qui répond directement à la question « ce SBOM existait-il bien à cette date ». #### Empreinte de l'artefact Le SBOM doit contenir l'**empreinte cryptographique de l'artefact qu'il décrit**, et l'artefact doit être retrouvable par cette empreinte. C'est ce lien qui permet de démontrer, des années plus tard, que ce SBOM décrit bien ce binaire. #### Attestations de provenance Une **attestation** est une déclaration signée sur la manière dont l'artefact a été produit : dépôt source, révision, chaîne de construction, paramètres, dépendances. Le modèle **[in-toto](https://in-toto.io/)** en fournit la structure ; le cadre **[SLSA](https://slsa.dev/)** en définit des niveaux progressifs. Le cadre [SLSA](https://slsa.dev/spec/v1.0/levels) définit, pour sa piste « construction », quatre niveaux nommés : | Niveau | Ce qui est exigé | | --- | --- | | **Build L0** | Aucune exigence — l'absence de SLSA | | **Build L1** | Le processus de construction est **cohérent** et une **provenance existe**, décrivant la plateforme, le processus et les entrées de premier niveau. Elle est distribuée aux consommateurs | | **Build L2** | La construction s'exécute sur une **infrastructure dédiée**, pas sur un poste individuel, et la provenance y est rattachée par une **signature** dont l'authenticité est vérifiable en aval | | **Build L3** | La plateforme empêche les exécutions de s'influencer entre elles, et rend le **matériel de signature inaccessible** aux étapes définies par l'utilisateur | Les builds reproductibles ne constituent pas un niveau de cette piste : c'est une propriété distincte, décrite ci-dessous, qui renforce la vérifiabilité par un tiers. #### Builds reproductibles Deux constructions du même code produisent des artefacts **bit à bit identiques**. C'est l'objectif le plus exigeant, et le plus probant : il permet à un tiers de vérifier que le binaire livré correspond bien au code source publié. Pour un produit soumis à une période de support de dix ans, la reproductibilité a un second intérêt, souvent décisif : elle oblige à figer et documenter l'environnement de construction, donc à pouvoir **reconstruire** dans huit ans. ### Le lien avec les exigences du règlement | Exigence | Ce que la signature apporte | | --- | --- | | Annexe I, partie I — protection de l'intégrité | Vérification à l'installation et à la mise à jour | | Annexe I, partie II, point 7 — diffusion sécurisée des mises à jour | Canal authentifié, correctifs signés, protection contre le retour arrière | | Annexe VII — dossier technique | Preuve datée et non modifiable de ce qui a été livré | ### Ce qu'il faut mettre en place 1. **Signer chaque SBOM** à la construction, dans le pipeline, sans intervention humaine. 2. **Générer une attestation de provenance** pour chaque artefact. 3. **Stocker signatures et attestations** avec l'artefact, indexées par empreinte. 4. **Vérifier la signature** avant tout déploiement et avant toute publication. 5. **Gérer les clés** : rotation, révocation, conservation des clés publiques historiques — sans la clé publique de 2027, une signature de 2027 ne se vérifie plus en 2035. 6. **Tester la restitution** : un exercice annuel consistant à retrouver, vérifier et présenter le SBOM signé d'une version ancienne. Ce dernier point est le seul qui prouve que le dispositif fonctionne. Voir [Conservation des preuves](/fr/legal/conservation-des-preuves/). ## Les six types de SBOM URL: https://cra-reference.eu/fr/sbom/typologies/ Description: Design, source, build, analyzed, deployed, runtime : ils ne décrivent pas la même chose et ne se valent pas. Lequel verser au dossier technique. Audience: cyber Published 2026-08-19, updated 2026-08-19 « Le » SBOM n'existe pas. Il y en a plusieurs, produits à des moments différents du cycle de vie, et **ils ne disent pas la même chose**. Confondre deux types est une source récurrente d'écarts inexpliqués entre équipes. | Type | Produit quand | Répond à | Fiabilité | | --- | --- | --- | --- | | **Design** | Avant développement | Ce qu'on **prévoit** d'utiliser | Intention | | **Source** | Depuis le code et les manifestes | Ce qui est **déclaré** | Manque le non déclaré | | **Build** | Pendant la construction | Ce qui est **effectivement assemblé** | **La plus fidèle pour le CRA** | | **Analyzed** | Après coup, sur l'artefact | Ce qu'on **retrouve** dans le binaire ou l'image | Dépend de la qualité de l'analyse | | **Deployed** | Sur l'environnement cible | Ce qui est **installé**, configuration comprise | Inclut l'environnement | | **Runtime** | Pendant l'exécution | Ce qui est **réellement chargé** en mémoire | Réduit le bruit, manque les chemins non exercés | ### Ce que chacun apporte **Design.** Utile en amont pour instruire la diligence avant d'adopter un composant, et pour détecter tôt une licence interdite. Sans valeur probante. **Source.** Rapide, produit à partir des manifestes de dépendances. Son angle mort est structurel : il ne voit pas ce qui n'est pas déclaré — code vendorisé, bibliothèque copiée, dépendance système. **Build.** Produit par la chaîne de construction, il voit le graphe de résolution réel, avec les versions effectivement retenues après arbitrage des contraintes. C'est celui qui doit être **versé au dossier technique**. **Analyzed.** Obtenu en analysant l'artefact fini — binaire, image de conteneur, image de micrologiciel. Il capte ce que le build a manqué : bibliothèques liées statiquement, paquets de l'image de base, fichiers copiés. Sert de **contrôle croisé** du build. **Deployed.** Ajoute l'environnement d'exécution : système hôte, configuration, variables. Utile pour la sécurité opérationnelle, moins pour la conformité produit. **Runtime.** Ce qui est effectivement chargé. Permet de **réduire le bruit** : un composant présent mais jamais chargé n'a pas la même criticité qu'un composant sur le chemin d'exécution. À manier avec prudence : un chemin non exercé pendant l'observation reste un chemin atteignable. ### La doctrine retenue 1. Le **Build SBOM** est le SBOM de référence, signé, archivé et versé au dossier technique. 2. L'**Analyzed SBOM** est produit systématiquement en contrôle croisé. **Tout écart significatif entre les deux est un défaut à instruire**, pas une curiosité : il révèle généralement du code vendorisé ou une dépendance non déclarée. 3. Le **Runtime SBOM** sert à la priorisation, jamais à la conformité. 4. Les types **Design** et **Deployed** sont produits au cas par cas, selon le besoin. ### L'écart build / analyzed C'est l'indicateur de qualité le plus révélateur du dispositif. Les causes typiques d'écart : - **liaison statique** : une bibliothèque C compilée dans le binaire n'apparaît pas au manifeste ; - **code vendorisé** : des sources tierces copiées dans votre dépôt ; - **image de base** : les paquets système du conteneur, absents des manifestes applicatifs ; - **artefacts multi-langages** : un composant Python appelant une bibliothèque native ; - **génération de code** : du code produit à la construction, embarquant des dépendances. Chacune de ces causes est traitée dans [Qualité et complétude](/fr/sbom/qualite-et-completude/). ## VEX : l'exploitabilité URL: https://cra-reference.eu/fr/sbom/vex/ Description: Le mécanisme qui distingue « traité » d'« ignoré » : statuts, justifications normalisées, implémentations CycloneDX, OpenVEX et CSAF, et valeur juridique de la décision de ne pas corriger. Audience: transverse Legal basis: Annexe I, partie II, point 2 — traiter les vulnérabilités · Annexe I, partie II, point 4 — publier l'information Published 2026-08-19, updated 2026-08-19 ### Le problème que le VEX résout Un SBOM confronté aux bases de vulnérabilités produit des centaines d'alertes par produit. Une large majorité d'entre elles n'est **pas exploitable dans votre contexte** : le code vulnérable n'est pas appelé, la fonction concernée n'est pas compilée, une mesure d'atténuation est en place. Sans mécanisme pour l'exprimer, deux issues, toutes deux mauvaises : soit l'équipe traite tout et s'épuise, soit elle supprime les alertes et perd la trace de ses décisions. Le second cas est exactement ce qu'une autorité cherchera à détecter. ### La définition **VEX** — *vulnerability exploitability exchange* — est une **assertion structurée du fournisseur sur le statut d'exploitabilité** d'une vulnérabilité donnée dans un produit donné. Ce n'est pas un format concurrent du SBOM : c'est un **complément**. Le SBOM dit ce qu'il y a dedans ; le VEX dit ce que cela implique. ### Les quatre statuts | Statut | Sens | Ce qui est attendu en plus | | --- | --- | --- | | `not_affected` | Le produit n'est pas affecté | Une **justification** normalisée, obligatoire | | `affected` | Le produit est affecté | Une recommandation d'action pour l'utilisateur | | `fixed` | La vulnérabilité est corrigée dans cette version | La version corrigée | | `under_investigation` | L'analyse est en cours | Un délai, et une reprise effective | `under_investigation` est un statut **temporaire**. Un VEX resté en investigation pendant six mois est un défaut de processus, pas une position. ### Les justifications de `not_affected` Elles sont normalisées, et c'est ce qui fait la valeur du mécanisme : | Justification | Signification | | --- | --- | | *component_not_present* | Le composant réputé vulnérable n'est pas dans le produit | | *vulnerable_code_not_present* | Le composant est présent, mais pas la portion de code vulnérable | | *vulnerable_code_not_in_execute_path* | Le code vulnérable existe mais n'est jamais exécuté | | *vulnerable_code_cannot_be_controlled_by_adversary* | Le code est exécuté mais l'attaquant ne peut pas en contrôler l'entrée | | *inline_mitigations_already_exist* | Une contre-mesure interne neutralise l'exploitation | Une justification hors de cette liste, ou une justification vide, n'est pas recevable. ### Les implémentations | Implémentation | Porteur | Usage typique | | --- | --- | --- | | **CycloneDX VEX** | OWASP | Intégré au même écosystème que votre SBOM pivot | | **[OpenVEX](https://github.com/openvex)** | Communauté | Format minimal, autonome, facile à générer et à signer | | **CSAF 2.0, profil VEX** | OASIS | Publication d'avis de sécurité lisibles par machine aux clients | Ces implémentations expriment les mêmes notions. Le choix se fait sur l'usage : interne et outillé pour CycloneDX ou OpenVEX, externe et normalisé pour CSAF. ### La valeur juridique C'est le point à faire comprendre au Juridique et à la Cyber en même temps. > L'annexe I, partie II, point 2, exige de **traiter et corriger les vulnérabilités sans > délai**. Elle n'exige pas de corriger l'intégralité des identifiants remontés par un > scanner. Une vulnérabilité analysée et déclarée non exploitable, avec une justification > normalisée, **a été traitée**. Le VEX est donc la **forme documentaire d'une décision motivée de ne pas corriger**. Il transforme un choix d'ingénierie en pièce défensive. Sans lui, la même décision est indiscernable d'une négligence. ### Le processus interne | Étape | Qui | Sortie | | --- | --- | --- | | Détection | Plateforme de pilotage | Alerte sur un couple produit / vulnérabilité | | Analyse d'exploitabilité | Ingénierie du produit | Statut proposé + justification | | Revue | PSIRT | Statut validé ou renvoyé | | Arbitrage en cas de désaccord | Comité, selon la [matrice RACI](/fr/organisation/raci/) | Décision tracée | | Émission | Chaîne automatisée | Document VEX signé, horodaté | | Publication éventuelle | PSIRT + Juridique | Avis client, format CSAF | | Réexamen | PSIRT | À chaque nouvelle version du produit | Un VEX est attaché à un **produit et à une version**. Il n'est pas transposable automatiquement à la version suivante : le réexamen fait partie du processus. ### Le lien avec les avis de sécurité L'annexe I, partie II, point 4, impose de publier des informations sur les vulnérabilités **corrigées**. Le format **[CSAF 2.0](https://www.csaf.io/)** permet de publier à la fois les avis de correction et les assertions VEX, sous une forme que vos clients peuvent traiter automatiquement — ce qui réduit leur charge et la nôtre. ## Divulgation des vulnérabilités URL: https://cra-reference.eu/fr/securite/ Description: La politique de divulgation coordonnée de ce site : périmètre, canal de signalement, délais d'engagement, engagement de non-poursuite et reconnaissance des chercheurs. Audience: transverse Published 2026-08-19, updated 2026-08-20 > **Ce que couvre cette page.** C'est la politique de divulgation **de ce site**. Le > **modèle** destiné à un fabricant — structure complète, engagement de non-poursuite, > articulation avec les normes et avec l'annexe I du règlement — est dans > [La politique de divulgation coordonnée](/fr/cyber/politique-cvd/). Nous accueillons les signalements de vulnérabilités affectant ce site. Cette page décrit comment nous les recevoir, ce que nous nous engageons à faire, et ce que nous demandons en retour. ### Comment nous signaler une vulnérabilité **Adresse :** `contact@cra-reference.eu` **Fichier normalisé :** [`/.well-known/security.txt`](/.well-known/security.txt) **Langues acceptées :** français, anglais Merci d'inclure, dans la mesure du possible : la page ou le composant concerné, une description de la vulnérabilité, les étapes de reproduction, l'impact estimé, et vos coordonnées. ### Périmètre **Couvert :** le site `cra-reference.eu`, ses sous-domaines éventuels, et les fichiers qu'il publie — dont [`/.well-known/security.txt`](/.well-known/security.txt), [`/llms.txt`](/llms.txt) et le sitemap. Ce site est **entièrement statique** : pas de serveur applicatif, pas de base de données, pas de compte utilisateur, aucun cookie déposé. La seule ressource chargée depuis un domaine tiers est le script de mesure d'audience de l'hébergeur, décrit dans les [mentions légales](/fr/a-propos/). La surface d'attaque est donc réduite, mais elle n'est pas nulle — configuration d'en-têtes, intégrité des ressources servies, chaîne de publication. **Hors périmètre :** l'infrastructure de l'hébergeur, les services tiers que nous ne contrôlons pas, les rapports automatisés sans démonstration d'impact, et les observations relevant des seules bonnes pratiques sans conséquence de sécurité établie. ### Nos engagements | Étape | Délai | | --- | --- | | **Accusé de réception** | 3 jours ouvrés | | **Première évaluation qualifiée**, transmise au déclarant | 10 jours ouvrés | | **Information sur l'avancement** | Tous les 15 jours tant que le sujet est ouvert | | **Correction ou position motivée** | Selon la gravité, dans le délai annoncé lors de l'évaluation | | **Publication coordonnée** | Par défaut 90 jours après le signalement, ajustable d'un commun accord | Si nous ne parvenons pas à corriger dans le délai convenu, nous vous en informons, nous expliquons pourquoi, et nous proposons une nouvelle échéance. ### Engagement de non-poursuite Nous n'engagerons aucune action civile ni aucune plainte pénale à l'encontre d'une personne qui, agissant de bonne foi : - reste dans le **périmètre** décrit ci-dessus ; - **ne dégrade pas** la disponibilité du site ; - **ne divulgue pas** la vulnérabilité avant la date convenue ; - nous **signale** par le canal indiqué sur cette page. Cet engagement ne couvre pas les actions menées à des fins malveillantes, ni celles qui enfreindraient des droits de tiers. ### Ce que nous demandons - Un **délai raisonnable** pour corriger avant toute publication. - La **coordination** de la date de publication avec nous. - L'**absence de demande de contrepartie financière** conditionnant la communication des détails. ### Reconnaissance Sauf demande contraire de votre part, nous **créditons** les personnes ayant signalé une vulnérabilité dans le journal des révisions du site et sur cette page. Nous ne proposons pas de programme de récompense financière. ### Voie alternative En France, l'**article L. 2321-4 du code de la défense** permet à toute personne de bonne foi de transmettre à l'ANSSI une information sur une vulnérabilité, l'agence préservant la confidentialité de son identité. Cette voie vous reste ouverte à tout moment, indépendamment de la présente politique. ### Cadre de référence Cette politique suit la structure décrite dans [La politique de divulgation coordonnée](/fr/cyber/politique-cvd/), qui s'appuie sur les normes **ISO/IEC 29147** (divulgation des vulnérabilités) et **ISO/IEC 30111** (traitement des vulnérabilités). Elle ne relève pas du règlement (UE) 2024/2847 : ce site est une ressource documentaire, pas un produit comportant des éléments numériques mis sur le marché. Elle en applique néanmoins la logique, parce qu'un site qui documente l'obligation de divulgation coordonnée serait mal venu de ne pas s'y tenir. --- # English (en) ## About this site URL: https://cra-reference.eu/en/about/ Description: Purpose, scope, editorial governance, legal disclaimer, technical principles and legal notices. Audience: transverse Published 2026-08-19, updated 2026-08-20 ### Purpose **CRA Reference** is a public reference on Regulation (EU) 2024/2847, the Cyber Resilience Act, on software bills of materials (SBOM), on open source licensing and on supply chain security. It addresses two audiences whose obligations are distinct but inseparable — **Legal / Compliance** and **Cybersecurity / DevSecOps** — and **leadership**, for the trade-offs. ### Disclaimer > This site is **information only**. It **does not constitute legal advice**. > > Only the text of **Regulation (EU) 2024/2847 as published in the *Official Journal of the > European Union*** is authoritative. The article and annex numbers cited here must be checked > against the consolidated text before any enforceable use, and the pages in the regulatory > section must be reviewed by legal counsel before being relied on against a third party. > > Three matters remain open and may render some pages obsolete: **harmonised standards**, the > Commission's **delegated and implementing acts**, and the **designation of national > authorities**. See [Regulatory watch](/en/updates/). > > Tool and product names are cited to illustrate technical categories. No commercial > recommendation is made, and no market information is guaranteed current. ### Scope **What the site covers:** the CRA regulatory framework, the SBOM as a technical and legal object, the translation into obligations for each team, and your target organisation. **What it does not cover:** operational security of your information systems (which falls under NIS 2 and the security management system), personal data protection, and sectoral compliance for products outside CRA scope. ### Editorial governance | Section | Owner | | --- | --- | | [The CRA framework](/en/cra/) | Legal department | | [Legal path](/en/legal/) | Legal department | | [SBOM](/en/sbom/) | CISO | | [Cyber path](/en/cyber/) | CISO | | [Tooling](/en/tooling/) | CISO | | [Organisation](/en/organisation/) | Executive sponsor | | [Leadership](/en/leadership/) | Executive sponsor | | Cross-cutting sections | CRA committee | **Review cadence:** - **Quarterly** for every page in the regulatory section; - **Immediately** on publication of a delegated act, an implementing act or a harmonised standard cited in the *Official Journal*; - **Annually** for the other pages. Every page shows its **last review date** and its **owning function**. A page whose review date is too old should be flagged: it is a defect, not a detail. ### Editorial rule A regulatory concept is defined **exactly once**, in [The CRA framework](/en/cra/) or [SBOM](/en/sbom/). Role-based paths offer only oriented readings, with a link to the canonical page. That is what stops the two paths from diverging, and it is the rule most easily broken. ### Technical principles This site is built on a few explicit choices: - **entirely static**, with no application server and no database; - **no client-side JavaScript dependency**, apart from the progressive-enhancement share script; - **a single third-party request** from the pages, the audience measurement described in the legal notices; any other one fails the build; - **bilingual French / English**, with strict page pairing; - **printable**: checklists and response cards come out cleanly on A4, because they will be used offline, including in a crisis room; - **accessible**: contrast, keyboard navigation, heading structure, skip link. An index for AI agents and engines is published at [`/llms.txt`](/llms.txt), and the full content at [`/llms-full.txt`](/llms-full.txt). ### Reporting an error A factual error, a dead link, an out-of-date page: see [Contact](/en/contact/). Corrections to the regulatory pages take priority. ### Legal notices **Publisher.** An independent documentation resource, published on a non-professional basis and with no commercial purpose. Under Article 6 of the French law on confidence in the digital economy, the publisher's identifying details are held by the host and disclosable to the judicial authority upon request. **Editorial contact.** `contact@cra-reference.eu` **Hosting.** Cloudflare, Inc., 101 Townsend Street, San Francisco, CA 94107, United States. **Personal data.** This site requires no sign-up, sets no cookies and uses no browser storage. Traffic is measured with Cloudflare Web Analytics: every page loads a script from `static.cloudflareinsights.com`, which reports the URL visited, the referring page, the browser type and page-load timings. That request exposes the visitor's IP address to Cloudflare — as hosting the site already does: the measurement adds no further recipient. It sets no cookie and no individual identifier, and enables no tracking across sites. No consent banner is shown, the measurement being limited to aggregate usage statistics. **Accessibility.** This site aims to conform to the RGAA and to EN 301 549. Any access difficulty can be reported through [Contact](/en/contact/). **Intellectual property.** The content is made available for information. Extracts from Regulation (EU) 2024/2847 fall under the European Union's document reuse regime. Tool and product names cited belong to their respective owners. ## Contact URL: https://cra-reference.eu/en/contact/ Description: One address: report an error, suggest content, ask a question — and what this site does not do. Audience: transverse Published 2026-08-19, updated 2026-08-20 **`contact@cra-reference.eu`** One address, for everything. State the subject at the top of your message; that is enough to route it. ### Reporting an error — the most useful message An inaccurate article reference, a wrong date, a dead link, a page whose last review date is too old. This is the enquiry we handle **first**, by a wide margin. A legal error in a public reference spreads: it gets copied into internal notes, quoted in meetings, reused in tenders. Fixing it quickly matters more than anything else here. Where you can, state: the page address, the passage concerned, what seems inaccurate, and your source. Corrections to [The CRA framework](/en/cra/) go to the front of the queue. ### Suggesting content A scenario you have lived through, a frequent question that is missing, a distribution case the licence matrix does not cover, an incident worth documenting. The [worked scenarios](/en/scenarios/), the [FAQ](/en/faq/) and the [reference incidents](/en/cyber/incidents/) are driven by situations people actually encounter. That is what makes them useful. ### Asking a question Before writing, two reflexes answer most questions: the [FAQ](/en/faq/), which covers around forty, and the [glossary](/en/glossary/). If your question concerns something the site handles badly or not at all, we want to hear it — it will probably end up in the FAQ. ### Reporting a vulnerability in this site **Do not use this page for that.** Follow the procedure in [Vulnerability disclosure](/en/security/), which states the scope, our response commitments and the safe harbour. ### What this site does not do Worth saying plainly, so nobody wastes their time. **We do not give legal advice.** This site is a documentation resource; it is no substitute for counsel. For a question about a specific product, a qualification or litigation risk, speak to a lawyer or to your legal department. **We do not support compliance engagements.** We carry out no audits, no classifications and no technical documentation on anyone's behalf. **We do not answer on behalf of an authority.** For anything concerning market surveillance, the designation of a notified body or the reporting of an actively exploited vulnerability, your counterpart is your **national authority**, not this site. The official entry points are listed in [Regulatory watch](/en/updates/). **We recommend no product.** The tools cited illustrate technical categories, with no commercial relationship of any kind. See [Tooling](/en/tooling/). ## The CRA framework URL: https://cra-reference.eu/en/cra/ Description: Regulation (EU) 2024/2847: identity of the text, scope, exclusions, criticality classes, essential requirements, support period, open source, reporting, timeline and penalties. Audience: transverse Legal basis: Regulation (EU) 2024/2847 Published 2026-08-19, updated 2026-08-19 This section is the site's **single source of truth** on the Cyber Resilience Act. Everything else — Legal path, Cyber path, organisation — links here rather than rephrasing. ### Identity of the text **Regulation (EU) 2024/2847 of the European Parliament and of the Council of 23 October 2024 on horizontal cybersecurity requirements for products with digital elements and amending Regulations (EU) No 168/2013 and (EU) 2019/1020 and Directive (EU) 2020/1828 (Cyber Resilience Act).** | Milestone | Date | | --- | --- | | Adoption | 23 October 2024 | | Publication in the *Official Journal of the European Union* | 20 November 2024 | | Entry into force | 10 December 2024 | | Application of the provisions on notified bodies | 11 June 2026 | | Application of the reporting obligations (Art. 14) | 11 September 2026 | | Full application | 11 December 2027 | ### Legal nature It is a **Regulation**, therefore directly applicable across all twenty-seven Member States with no transposition — unlike the NIS 2 Directive. It is also **Union harmonisation legislation** under the "new legislative framework": it borrows the grammar of CE marking for machinery or toys and applies it to cybersecurity. Practical consequence: the notions of *placing on the market*, *essential requirements*, *presumption of conformity through harmonised standards*, *assessment modules*, *technical documentation* and *EU declaration of conformity* are not CRA inventions. Teams that already handle other CE markings know this vocabulary, and it should remain theirs. ### What the Regulation pursues The five objectives stated by the legislator, useful to cite internally when building a case: 1. reduce the number of vulnerable products placed on the market; 2. make manufacturers accountable for security **across the whole life cycle**, not only at the point of sale; 3. improve **transparency** about the security properties of products; 4. enable users, professional and consumer alike, to choose and use secure products; 5. close the gaps between existing sectoral legislation. ### Structure of the Regulation | Part | Content | | --- | --- | | Chapter I | Subject matter, scope, definitions | | Chapter II | Obligations of economic operators, provisions on open source | | Chapter III | Presumption of conformity, harmonised standards, conformity assessment | | Chapter IV | Notification of conformity assessment bodies | | Chapter V | Market surveillance and enforcement | | Chapter VI | Delegated and implementing acts | | Chapter VII | Confidentiality and penalties | | Chapter VIII | Transitional and final provisions | | **Annex I** | Essential requirements — **Part I**: product security; **Part II**: vulnerability handling | | **Annex II** | Information and instructions to the user | | **Annex III** | Important products — Part I (class I) and Part II (class II) | | **Annex IV** | Critical products | | **Annex V** | Content of the EU declaration of conformity | | **Annex VI** | Simplified EU declaration of conformity | | **Annex VII** | Content of the technical documentation | | **Annex VIII** | Conformity assessment procedures | ### Official sources - The **text of the Regulation** on EUR-Lex: [Regulation (EU) 2024/2847](https://eur-lex.europa.eu/eli/reg/2024/2847/oj) — the only authoritative version. All twenty-four language versions carry equal legal force. - The European Commission's **Cyber Resilience Act** page: [digital-strategy.ec.europa.eu](https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act) — guidance, FAQ, delegated and implementing acts as they are adopted. - **ENISA**: [enisa.europa.eu](https://www.enisa.europa.eu/) for publications, and the **European vulnerability database** at [euvd.enisa.europa.eu](https://euvd.enisa.europa.eu/). - **CEN and CENELEC**: [cencenelec.eu](https://www.cencenelec.eu/), for progress on the harmonised standards that condition the presumption of conformity. - **ANSSI**: [cyber.gouv.fr](https://cyber.gouv.fr/), and [CERT-FR](https://www.cert.ssi.gouv.fr/) for alerts. > **Caveat.** The pages in this section are a working reading. The article and annex numbers > cited must be checked against the consolidated text before any enforceable use, and the > pages must be reviewed by legal counsel. ## CE marking URL: https://cra-reference.eu/en/cra/ce-marking/ Description: What the marking means legally, the seven cumulative conditions before affixing it, the rules for software, and the commercial gate it represents. Audience: legal Legal basis: Art. 29 — general principles of the CE marking · Art. 30 — rules and conditions for affixing · Art. 28 — EU declaration of conformity Published 2026-08-19, updated 2026-08-19 ### What the CE marking is — and is not The CE marking is the manufacturer's declaration, **under its sole responsibility**, that the product satisfies all applicable requirements of the Union harmonisation legislation providing for its affixing. It is **not** a quality label, **not** a certification, **not** a guarantee that no vulnerability exists, and **not** issued by an authority. It is a unilateral statement, enforceable and punishable if false. ### The seven cumulative conditions Before affixing, in this order: 1. the applicable **Annex I essential requirements** are satisfied; 2. a **cybersecurity risk assessment** has been carried out and documented; 3. the **Annex VII technical documentation** is compiled, **SBOM included**; 4. the **conformity assessment procedure** applicable to the product's class has been completed; 5. the **Annex V EU declaration of conformity** has been drawn up and signed; 6. the **Annex II information and instructions to the user** are supplied with the product; 7. the **manufacturer's identification** and the **contact point** for reporting vulnerabilities appear on the product, its packaging or its accompanying documentation. A single missing condition makes the affixing irregular. ### Rules for affixing - **Visibly, legibly and indelibly.** Where the nature of the product does not allow it, on the packaging and on the accompanying documents. - **For a software product**: on the **EU declaration of conformity** and, where applicable, on the **website** accompanying the product, in a place easily accessible from the download or purchase page. - **Before** placing on the market. - Where a **notified body** was involved in the production control phase, its **identification number** is affixed **after** the CE marking — by the body itself or by the manufacturer on its instructions. - No marking, sign or inscription liable to mislead third parties as to the meaning or form of the CE marking may be affixed beside it. ### The commercial gate **No CE marking = no placing on the Union market.** That is the sentence that makes the topic legible to an executive committee. The organisational consequence follows directly: the legal function **owns the marking process** and must hold a **formal right of veto** over placing on the market. That veto is embodied in a **conformity review record**, signed before affixing, which walks through the fifteen points of the [checklist](/en/legal/placing-checklist/) and names who is responsible for each item. ### Common mistakes | Mistake | Consequence | | --- | --- | | Affixing the marking "in anticipation", pending completion of the file | Formal non-compliance **and** an inaccurate declaration | | Reusing a previous version's declaration without updating it | The declaration does not cover the product actually placed on the market | | Omitting the notified body number where the body was involved | Formal non-compliance | | Affixing the marking to a product outside CRA scope | Misleading marking | | Treating the marking as acquired once and for all | Any **substantial modification** reopens the procedure | ## Conformity assessment URL: https://cra-reference.eu/en/cra/conformity-assessment/ Description: Presumption of conformity, harmonised standards and request M/606, modules A, B+C and H, notified bodies, EUCC certification, and support measures for SMEs. Audience: legal Legal basis: Art. 27 — presumption of conformity · Art. 32 — assessment procedures · Chapter IV — notified bodies · Annex VIII — modules Published 2026-08-19, updated 2026-08-19 ### The presumption of conformity A product that conforms, wholly or partly, to **harmonised standards** whose references have been published in the *Official Journal of the European Union* is **presumed to conform** to the essential requirements those standards cover. Three routes open that presumption: 1. **harmonised standards** cited in the OJ; 2. **common specifications** adopted by the Commission through an implementing act, in the absence of a satisfactory harmonised standard; 3. **European cybersecurity certification schemes** adopted under Regulation (EU) 2019/881, at assurance level at least "substantial". The presumption is a **shift in the burden of proof**, not an exemption: it removes neither the technical documentation, nor the declaration, nor the marking. ### The state of standardisation The Commission addressed standardisation request **M/606** to [CEN and CENELEC](https://www.cencenelec.eu/). The work is carried out by joint technical committee **JTC 13**, working group 9, and comprises: - **horizontal standards** — principles of cyber resilience, generic security requirements, vulnerability handling — applicable to all products; - **vertical standards**, by Annex III product category. > **This is the main source of schedule uncertainty.** A standard adopted but not yet **cited > in the OJ** confers no presumption. This page must be re-read at each publication; see > [updates](/en/updates/). ### The assessment modules | Module | Name | Who assesses | Open to | | --- | --- | --- | --- | | **A** | Internal control of production | The manufacturer | Default; class I **conditionally** on full application of standards | | **B** | EU type-examination | Notified body | Classes I and II, Critical — followed by module C | | **C** | Conformity to type based on internal control | The manufacturer, after module B | Same | | **H** | Conformity based on full quality assurance | Notified body (system audit) | Classes I and II, Critical | Choosing between B+C and H is discussed in [Important class II](/en/cra/criticality-classes/important-class-2/). ### Notified bodies A notified body is an **accredited** conformity assessment body, designated by a national **notifying authority**, **notified to the Commission** and listed in the **[NANDO](https://single-market-economy.ec.europa.eu/single-market/goods/building-blocks/notified-bodies_en)** database, where it receives an identification number. The Regulation requires independence, technical competence, impartiality, confidentiality and liability insurance. They are subject to information obligations towards the notifying authority and towards other bodies. The corresponding chapter has applied since **11 June 2026**. Two things to anticipate: - **capacity** — the entire European market must pass through these bodies before 11 December 2027, with a limited number of bodies at the outset; - **sectoral competence** — not every body will cover every Annex III category; check the exact scope of the notification in NANDO before contracting. ### The certification route Holding a **European cybersecurity certificate**, issued under a scheme adopted pursuant to the Cybersecurity Act at assurance level at least "substantial" and covering the relevant essential requirements, counts as conformity assessment. For **critical products** in Annex IV, the Commission may **make that route mandatory** by delegated act — see [Critical products](/en/cra/criticality-classes/critical/). ### Costs and lead times: what to budget The Regulation of course sets no tariff. The line items to provision are known: - notified body assessment fees, per product and per cycle; - internal cost of preparing the file, generally higher than the external cost; - the cost of the **version freeze** during examination, in days of delayed market entry; - **maintenance** cost: certificate extensions, surveillance audits, reassessment after substantial modification; - for critical products subject to certification, the evaluation laboratory and certificate maintenance. ### Micro, small and medium-sized enterprises The Regulation provides **support measures**: a **simplified technical documentation form** made available by the Commission for micro and small enterprises, awareness and training actions by Member States, and consideration of company size when setting penalties. These measures lighten the documentation burden; they reduce **no** substantive requirement. ## Criticality classes URL: https://cra-reference.eu/en/cra/criticality-classes/ Description: Default, Important class I, Important class II, Critical: the classification determines whether a notified body is mandatory, and therefore the cost, the lead time and the critical path. Audience: transverse Legal basis: Art. 7 — important products · Art. 8 — critical products · Annex III — important products, Parts I and II · Annex IV — critical products · Annex VIII — assessment procedures Published 2026-08-19, updated 2026-08-19 This is the most structuring page of the reference. A product's class does not change *what* it must comply with — the Annex I essential requirements are identical for all. It changes **how compliance must be proven**, and therefore the cost, the lead time and the critical path. ### The four-level pyramid | Level | Reference | Examples | Self-assessment | Third party required | | --- | --- | --- | --- | --- | | **[Default](/en/cra/criticality-classes/default/)** | No annex: everything not listed | Word processors, games, business applications, the vast majority of products | **Yes** (module A) | No | | **[Important — class I](/en/cra/criticality-classes/important-class-1/)** | Annex III, Part I | Browsers, password managers, VPNs, antivirus, SIEM, routers, identity management | **Yes, but only if harmonised standards are applied in full** | Otherwise yes | | **[Important — class II](/en/cra/criticality-classes/important-class-2/)** | Annex III, Part II | Operating systems, hypervisors and container runtimes, firewalls, IDS/IPS, tamper-resistant microprocessors | **No** | **Yes** | | **[Critical](/en/cra/criticality-classes/critical/)** | Annex IV | Hardware security boxes, smart meter gateways, smart cards and secure elements | No | **Yes**, with possible **EUCC** certification at assurance level at least "substantial" | ### Three rules of method **1. Classify by actual functionality, not by product name.** A product called an "administration console" that performs a network management function falls under class I. The marketing label is not binding. **2. A multi-function product falls into the highest applicable class.** A suite bundling a password manager (class I) and a firewall (class II) is treated as class II. **3. The lists move.** The Commission may specify by delegated act the technical description of the categories and **update Annexes III and IV**. This page carries a review date; the [updates](/en/updates/) feed keeps it current. ### Why this is the critical path The argument to make to a committee, in three steps: 1. A class II or Critical product **cannot self-assess**: a notified body is required. 2. Notified bodies can only be designated since **11 June 2026**, and their number will be limited at first. 3. Third-party assessment requires **freezing a version**, compiling a file, and counting in months rather than weeks. Conclusion: for every class II or Critical product, **contracting an assessment slot is a task for now**, before the technical documentation is even complete. It is the only item on the programme whose lead time is not yours to control. ### The uncertainty to accept For class I, the self-assessment route is open **only** where the manufacturer applies in full harmonised standards, common specifications or a European certification scheme covering all the relevant essential requirements. Until the harmonised standards arising from standardisation request **M/606** are published and cited in the *Official Journal*, that route is **closed in practice**. Two scenarios must therefore be planned for class I: self-assessment if the standards arrive in time, notified body otherwise. Treating the second as the base case is the prudent position. ### What to produce A **classification sheet** per product, filed with the technical documentation: actual functionality, Annex III and IV categories examined, the category retained or the reason for ruling it out, the resulting class, the assessment route chosen, date and signatories. The [method](/en/cra/criticality-classes/method/) sets out the line of questioning. ## Critical products URL: https://cra-reference.eu/en/cra/criticality-classes/critical/ Description: Annex IV: hardware security boxes, smart meter gateways, smart cards and secure elements. A reinforced regime and a possible EUCC certification requirement. Audience: transverse Legal basis: Art. 8 — critical products · Annex IV · Regulation (EU) 2019/881 — certification schemes Published 2026-08-19, updated 2026-08-19 ### The list (Annex IV) - **Hardware devices with security boxes** — hardware security modules, cryptographic safes. - **Smart meter gateways** within smart metering systems as defined in [Directive (EU) 2019/944](https://eur-lex.europa.eu/eli/dir/2019/944/oj), and **other devices for advanced security purposes**, including for **secure cryptoprocessing**. - **Smart cards or similar devices**, including **secure elements**. The list is short and deliberately restrictive: it targets components whose compromise degrades the security of everything built on them. ### The reinforced regime Critical products first follow the class II regime — **notified body mandatory**, modules B+C or H. On top of that sits a specific empowerment: the Commission may require, by **delegated act**, that a **European cybersecurity certificate** be obtained under a scheme adopted pursuant to Regulation (EU) 2019/881 — typically the **EUCC** scheme — at **assurance level at least "substantial"**. That requirement is triggered category by category, according to the level of risk and the availability of a suitable scheme. Tracking the delegated acts is therefore essential for any affected manufacturer: it is a standing item in [updates](/en/updates/). ### What that changes in practice | | Class II | **Critical with EUCC requirement** | | --- | --- | --- | | Assessor | Notified body | **Evaluation laboratory (ITSEF)** accredited under the scheme | | Input deliverable | Technical documentation | **Security target**, description of mechanisms, design evidence | | Method | Type examination or quality audit | Evaluation under the scheme's methodology, close to **Common Criteria** | | Typical duration | A few months | **Often more than a year** for a first pass | | Cost | Significant | **Substantially higher** | | Maintenance | Certificate extension | **Certificate maintenance**, reassessment at each evolution | ### Consequences for the roadmap For a critical product, CRA compliance is not a documentation exercise: it is a **security engineering programme** to be launched well ahead of the application date, with: - a certification lead appointed, distinct from the product manager; - the **security target** drafted early and the environmental assumptions identified; - the evaluation laboratory selected and contracted; - the product roadmap aligned with evaluation windows, including a freeze on changes during critical phases; - the **maintenance** of the certificate budgeted, not only its issuance. > **To put to the committee.** For a critical product the question is not "how do you comply?" > but "does this product stay in the portfolio given the recurring cost of certification?". > That is a portfolio decision, not a compliance decision, and it must be taken explicitly. ## Default category URL: https://cra-reference.eu/en/cra/criticality-classes/default/ Description: What self-assessment means: module A, what it removes and above all what it does not, and the real risk of a self-declared but empty file. Audience: legal Legal basis: Art. 32(1) · Annex VIII, Part I — module A Published 2026-08-19, updated 2026-08-19 ### What the category covers Every product with digital elements that appears **neither in Annex III nor in Annex IV**. That covers the vast majority of the market: business software, mobile applications, games, office tools, connected objects with no security function, general-purpose libraries. The category is therefore defined **by subtraction**, not by a list. The classification sheet must accordingly demonstrate that the product was tested against the Annex III and Annex IV lists and ruled out of each — not merely assert that it is "standard". ### The conformity route: module A **Module A — internal control of production** (Annex VIII, Part I) is open without condition. The manufacturer: 1. carries out and documents the **cybersecurity risk assessment**; 2. designs, develops and produces the product in accordance with the **Annex I essential requirements**; 3. compiles the **Annex VII technical documentation**; 4. takes the measures needed for the manufacturing process to ensure series conformity; 5. draws up the **EU declaration of conformity** (Annex V); 6. affixes the **CE marking**. No notified body is involved, and no body number is affixed next to the marking. ### What "self-assessment" does not mean This is the most widespread misreading in the field, and an expensive one. | What module A removes | What module A **does not** remove | | --- | --- | | Having the file verified by an accredited third party | **Compiling** the technical documentation | | Paying a notified body | Carrying out and documenting the risk assessment | | Waiting for an assessment slot | Producing a machine-readable **SBOM** | | Freezing a version for type examination | Establishing a **coordinated disclosure policy** | | — | Determining and publishing a **support period** | | — | **Reporting within 24 hours** actively exploited vulnerabilities | | — | **Retaining** file and declaration for ten years | The substance of the obligations is **identical** to that of a class II product. Only external verification disappears. ### The real risk It lies not in the classification but in the inspection. A **market surveillance authority** may, at any time and without prior grounds, demand the technical documentation for a product it bought off the shelf. Three situations follow: - **Complete file**: the demonstration takes days, and the matter ends there. - **Incomplete file**: an order to bring the product into conformity within a set period, with a risk of restriction on making it available while the gaps are closed. - **No file at all, despite an affixed CE marking**: this is formal non-compliance compounded by an inaccurate declaration. The penalty ceiling for supplying incorrect or misleading information to authorities applies on top. > **The point.** Self-assessment shifts the burden of proof; it does not remove it. A > self-declared but empty file is worse than an absent marking, because it is a false > statement rather than an omission. ### Module A checklist - [ ] Signed PDE qualification sheet - [ ] Classification sheet demonstrating that Annexes III and IV were ruled out - [ ] Documented and dated cybersecurity risk assessment - [ ] Coverage of the Annex I, Part I requirements, with justification for those ruled out - [ ] Operational Annex I, Part II vulnerability handling process - [ ] SBOM generated, validated, signed, archived - [ ] Coordinated disclosure policy published, contact point live - [ ] Support period determined, justified, communicated to the buyer - [ ] Annex II information and instructions to the user shipped - [ ] Annex VII technical documentation complete - [ ] Annex V EU declaration of conformity signed - [ ] CE marking affixed in accordance with the rules - [ ] Ten-year archiving configured ## Important — class I URL: https://cra-reference.eu/en/cra/criticality-classes/important-class-1/ Description: Annex III, Part I: browsers, password managers, VPNs, antivirus, SIEM, routers, identity management. Three assessment routes, one of them conditional on harmonised standards. Audience: transverse Legal basis: Art. 7 — important products · Annex III, Part I · Art. 32(2) — assessment routes Published 2026-08-19, updated 2026-08-19 ### The list (Annex III, Part I) The categories as enumerated by the Regulation. Classification follows **actual functionality**. - **Identity management systems** and privileged access management software and hardware. - **Standalone and embedded browsers.** - **Password managers.** - Software that searches for, removes or quarantines **malicious software** — antivirus, endpoint protection. - **Virtual private network (VPN) products.** - **Network management systems.** - **Security information and event management (SIEM) systems.** - **Boot managers.** - **Public key infrastructure and digital certificate issuance software.** - **Physical and virtual network interfaces.** - **Routers, modems intended for the connection to the internet, and switches.** - **Microprocessors, microcontrollers, ASICs and FPGAs** with security-related functionalities. - **Smart home general purpose virtual assistants.** - **Smart home products with security functionalities**: smart locks, security cameras, alarm systems, baby monitoring systems. - **Internet-connected toys** with social interactive features or location tracking. - **Personal wearable products** intended for health monitoring or worn on the body. ### The three assessment routes | Route | Content | Third party | | --- | --- | --- | | **Module A** — internal control | Full self-assessment | None — **but conditional, see below** | | **Modules B + C** | EU type-examination by a notified body, then conformity to type based on internal control | **Notified body** | | **Module H** | Full quality assurance of the design, development and production system, audited | **Notified body** | A fourth possibility exists: holding a **European cybersecurity certificate** issued under a scheme adopted pursuant to the Cybersecurity Act, at assurance level at least "substantial", covering the relevant essential requirements. ### The condition that changes everything Module A is open to class I products **only if the manufacturer applies in full** harmonised standards, common specifications or a European certification scheme **covering all the relevant essential requirements**. "In full" and "all" are the two words that matter. Partial application with justified deviations is not enough: it closes the self-assessment route. > **Scheduling consequence.** Until the harmonised standards arising from standardisation > request **M/606** — work of the joint technical committee **CEN/CENELEC JTC 13, working > group 9** — are published and **cited in the *Official Journal of the European Union***, > the module A route is **closed in practice** for class I. A standard adopted but not cited > in the OJ confers no presumption of conformity. ### What to decide now Two scenarios to work in parallel, and one default: 1. **Standards scenario** — the harmonised standards are published and cited in time; you demonstrate full application and stay in module A. Low cost, controlled lead time, **uncertain probability**. 2. **Notified body scenario** — you engage a body under modules B+C or H. Significant cost, several months of lead time, **within your control provided you book early**. The prudent position is to **treat scenario 2 as the base case** and scenario 1 as a possible saving. The reverse exposes you to discovering in 2027 that no assessment slot is available. ### Qualification watch points - An **embedded browser** inside another product pushes that product into class I. A web rendering component inside a desktop application must be examined on that basis. - A **microcontroller with security-related functionalities** falls under class I; if it is also **tamper-resistant**, it falls under class II. The boundary is technical and must be settled by engineering, not by Legal. - A **smart home product** is class I only if it has **security functionalities**. A connected light bulb is not; a security camera is. - **Connected toys** fall under class I only where there is social interaction or location tracking — but they remain subject to toy safety legislation regardless. ## Important — class II URL: https://cra-reference.eu/en/cra/criticality-classes/important-class-2/ Description: Annex III, Part II: operating systems, hypervisors, firewalls, IDS/IPS, tamper-resistant microprocessors. Self-assessment is excluded, a notified body is mandatory. Audience: transverse Legal basis: Art. 7 — important products · Annex III, Part II · Art. 32(3) Published 2026-08-19, updated 2026-08-19 ### The list (Annex III, Part II) - **Hypervisors and container runtime systems** that support virtualised execution of operating systems and similar environments. - **Firewalls, intrusion detection and prevention systems** (IDS / IPS). - **Tamper-resistant microprocessors.** - **Tamper-resistant microcontrollers.** - **Operating systems.** ### The regime **Self-assessment is excluded.** Only two modules are open, and both involve a **notified body**: | Module | Content | What is certified | | --- | --- | --- | | **B + C** | EU type-examination, then conformity to type based on internal control of production | **The product**, in a given version | | **H** | Full quality assurance: the design, development and production system is audited and approved | **The process** | Holding a European cybersecurity certificate at assurance level at least "substantial" and covering the relevant essential requirements is also an admissible route. ### Choosing between B+C and H | Criterion | B + C | H | | --- | --- | --- | | Release cadence | Suits long-cycle products with rare versions | Suits **continuous delivery** | | New version | May require an extension or reassessment of the certificate | Covered by the approved quality system | | Up-front effort | Concentrated on a product file | Falls on the **organisation**: procedures, traceability, audits | | Recurring effort | At every significant version | Periodic surveillance audits | | Suited to | Firmware, hardware products, embedded operating systems | Software vendors releasing frequently | For a vendor releasing several times a month, module B+C becomes unmanageable quickly: every substantial modification reopens the certificate question. Module H costs more up front but absorbs the cadence. ### Programme implications - **Cost** of assessment, to be budgeted per product and per cycle. - **Lead time** of several months, dependent on the body's workload, not compressible. - **Version freeze** during examination, for module B. - **Managing substantial modifications** after certification: any change affecting conformity reopens a procedure. - **Contracting early**: this is the only item on the programme whose lead time you do not control. > **Scheduling alert.** The chapter on notification of conformity assessment bodies has > applied since **11 June 2026**. The number of accredited bodies and their capacity will be > limited at the outset, while the entire market must pass through them before 11 December > 2027. **Booking a slot is a task for now, not for when the file is ready.** ### Qualification watch points - "**Operating system**" reads broadly: an embedded or real-time operating system you distribute falls within the category. - A **container runtime** is covered; a mere **orchestrator** is not, on the same basis, but the whole must be examined component by component. - A **tamper-resistant** microcontroller falls under class II; the same microcontroller without that property falls under class I if it carries security-related functionalities. The qualification must be settled by engineering, on the basis of the physical countermeasures actually implemented, and documented. - A product that **embeds** an operating system without placing it on the market separately is not for that reason alone in class II: what counts is the function offered to the market. Due diligence on that third-party component remains owed, however. ## Classification method URL: https://cra-reference.eu/en/cra/criticality-classes/method/ Description: The line of questioning to classify a product, the classification sheet to produce, and the consolidated portfolio register. Audience: transverse Legal basis: Annexes III and IV Published 2026-08-19, updated 2026-08-19 Classification is a legal decision resting on technical facts. It must therefore be **co-signed**: engineering establishes the actual functionality, Legal settles the qualification. ### The line of questioning, in order #### Step 1 — Is the product a PDE? See [Scope](/en/cra/scope-pde/). If not, classification stops there; a negative qualification sheet is still produced. #### Step 2 — Is it excluded? See [Exclusions](/en/cra/exclusions/). If so, produce a reasoned exclusion sheet citing the applicable sectoral text. #### Step 3 — What functionality does the product actually offer? List the functions **actually offered to the user**, regardless of product name and marketing material. A function disabled by default but available remains a function offered. #### Step 4 — Does it appear in Annex IV? Hardware security box, smart meter gateway, secure cryptoprocessing device, smart card or secure element. If yes → **[Critical](/en/cra/criticality-classes/critical/)**, stop. #### Step 5 — Does it appear in Annex III, Part II? Operating system, hypervisor, container runtime, firewall, IDS/IPS, **tamper-resistant** microprocessor or microcontroller. If yes → **[Important class II](/en/cra/criticality-classes/important-class-2/)**, stop. #### Step 6 — Does it appear in Annex III, Part I? The seventeen categories listed in [Important class I](/en/cra/criticality-classes/important-class-1/). If yes → **class I**. #### Step 7 — Otherwise **[Default category](/en/cra/criticality-classes/default/)**. The sheet must demonstrate that Annexes III and IV were examined and each relevant category ruled out. ### The four questions that settle borderline cases 1. **Tamper resistance.** Does the component implement physical countermeasures against the extraction or modification of secrets — shielding, intrusion detection, encrypted memory, side-channel protection? This purely technical answer moves a microcontroller from class I to class II. 2. **Security-related functionality.** Does the component perform a security function for the system embedding it — key generation, secret storage, access control, verified boot? 3. **Embedded browser.** Does the product embed a web rendering engine exposed to untrusted remote content? 4. **Multi-function.** Does the product span several categories? Then the **highest class** applies. ### The classification sheet A one-page document, filed with the technical documentation. It must contain: | Field | Content | | --- | --- | | Product and versions covered | Traceable identification | | Actual functionality | List, with the source (specification, code, documentation) | | Annex IV | Categories examined, retained or ruled out, with reasons | | Annex III Part II | Same | | Annex III Part I | Same | | **Class retained** | Default, I, II or Critical | | **Assessment route** | Module A, B+C, H, or certification | | Notified body | Where applicable, identity and contracting status | | Assumptions and reservations | Points that would trigger reassessment | | Date, signatories | Engineering **and** Legal | ### The consolidated register A single portfolio table, kept by Legal and reviewed at every committee: product, PDE status, any exclusion, class, assessment route, notified body, date of last classification, next review. This register is the first document a market surveillance authority will ask for, and the first an acquirer will ask for in a transaction. Keeping it is not optional. ### When to reclassify - Addition or activation of a **security function**. - **Substantial modification** within the meaning of Article 3. - **Update of Annexes III or IV** by delegated act. - Publication of Commission guidance clarifying the technical description of a category. - At minimum, an **annual review** of the whole register. ## Economic operators and their responsibilities URL: https://cra-reference.eu/en/cra/economic-operators/ Description: Manufacturer, authorised representative, importer, distributor, and the shift of responsibility in white-label arrangements. The authorities: Commission, ENISA, CSIRTs, market surveillance, notified bodies. Audience: legal Legal basis: Art. 13 — manufacturers · Art. 18 — authorised representatives · Art. 19 — importers · Art. 20 — distributors · Art. 22 — cases where manufacturers' obligations apply Published 2026-08-19, updated 2026-08-19 ### Economic operators #### The manufacturer Carries the bulk of the obligations: design in accordance with the essential requirements, conduct the risk assessment, follow the assessment procedure, compile the technical documentation, draw up the EU declaration of conformity, affix the CE marking, determine and honour the support period, handle vulnerabilities, report, inform users, cooperate with authorities, retain evidence. A manufacturer is any natural or legal person who **develops or manufactures** a product, or has it designed, developed or manufactured, and **markets it under its own name or trademark**, whether for payment or free of charge. #### The authorised representative Any natural or legal person established in the Union holding a **written mandate** from the manufacturer to act on its behalf. The mandate must at least allow it to keep the technical documentation and the EU declaration of conformity at the disposal of authorities, to provide them with requested information and to cooperate. A manufacturer established outside the Union must appoint an authorised representative. #### The importer Places only **compliant** products on the market. Before doing so, it verifies that the assessment procedure was carried out, that the manufacturer compiled the technical documentation, that the CE marking is affixed, that the user information is supplied, and that the contact point appears on the product. It indicates its own details. Where it has reason to believe there is non-compliance or a significant risk, it informs the manufacturer and the authorities. #### The distributor Acts with **due care**: verifies the presence of the CE marking, the user information and the details of upstream operators. It refrains from making available a product it knows or should know to be non-compliant. ### The shift of responsibility This is the most exposed point for an organisation that resells or customises. > An **importer or distributor is deemed to be a manufacturer** — and therefore assumes **all** > manufacturer obligations — where it places a product on the market **under its own name or > trademark**, or where it makes a **substantial modification** to a product already placed on > the market. Direct consequences for your activities: | Situation | Status | What it entails | | --- | --- | --- | | You resell a third-party product **under its own brand** | Distributor | Documentary checks | | You resell a third-party product **under your brand** (white label, OEM) | **Manufacturer** | Technical documentation, SBOM, CE marking, support period, reporting — everything | | You embed a third-party product in your solution | **Manufacturer** of the solution | Same, plus due diligence on the component | | You substantially modify a third-party product | **Manufacturer** | Same, and a new assessment | | You distribute unmodified, under the original brand | Distributor | Documentary checks | This table must be run against the commercial catalogue **before anything else**: it usually reveals products nobody realised you were the manufacturer of. ### The authorities | Actor | Role | | --- | --- | | **European Commission** | Delegated acts (updating Annexes III and IV, mandatory certification of critical products) and implementing acts (common specifications, SBOM format), guidance | | **[ENISA](https://www.enisa.europa.eu/)** | Operates the **single reporting platform**, contributes to the **European vulnerability database**, produces technical reports and a biennial trends report | | **Coordinating CSIRTs** | Recipients of reports in each Member State, coordinate disclosure, may delay dissemination of a notification on justified grounds | | **Market surveillance authorities** | Inspections, requests for technical documentation, testing, injunctions, restrictions, withdrawals, recalls | | **ADCO** | Administrative cooperation group of surveillance authorities: coordination, joint activities, coordinated sweeps | | **Notifying authorities** | Designate, notify and monitor conformity assessment bodies | | **Notified bodies** | Carry out module B, C and H assessments for products that cannot self-assess | ### In France The Regulation leaves the designation of authorities to Member States. In play: **[ANSSI](https://cyber.gouv.fr/)**, whose positioning as a market surveillance authority and **[CERT-FR](https://www.cert.ssi.gouv.fr/)** as coordinating CSIRT are the best-documented hypotheses, and, where applicable, the administrations competent for product market surveillance. > **A page to keep current.** National designations and their practical arrangements — desk, > exchange format, language — are a standing item in [updates](/en/updates/). Do not freeze > here an organisation that is not yet official. ## Reporting to ENISA and CSIRTs URL: https://cra-reference.eu/en/cra/enisa-reporting/ Description: The nearest obligation: 24 hours, 72 hours, 14 days or one month. Triggers, the meaning of active exploitation, the single reporting platform, confidentiality and the extended time scope. Audience: transverse Legal basis: Art. 14 — reporting obligations · Art. 15 — voluntary reporting · Art. 16 — single reporting platform · Art. 17 — other reporting provisions · Art. 69 — application to products already on the market Published 2026-08-19, updated 2026-08-19 This obligation arrived **first**, on 11 September 2026, and its breach is the most visible: the deadlines are short, public and verifiable. ### The two triggers | Trigger | Definition | | --- | --- | | **Actively exploited vulnerability** contained in the product | A vulnerability for which there is **reliable evidence** that a malicious actor has exploited it in a system without the permission of the system owner | | **Severe incident having an impact on the security** of the product | An incident that negatively affects, or is capable of negatively affecting, the ability of the product to protect the availability, authenticity, integrity or confidentiality of data or functions | #### What "actively exploited" means - The existence of a **public proof-of-concept exploit** does not, on its own, establish active exploitation. - Conversely, exploitation **observed at a single customer** is enough. - A high severity score is not a criterion: a critical vulnerability never exploited does not trigger the obligation; a medium-severity vulnerability being exploited does. The delicate point is **reliable evidence**: consistent indicators of compromise, logs, forensic analysis, a credible report from a customer or a CERT. The decision must be **documented**, including when it concludes there is no active exploitation. ### The channel Reports go through the **single reporting platform** (SRP) established and operated by **[ENISA](https://www.enisa.europa.eu/)**. They are routed to the **CSIRT designated as coordinator** of the Member State concerned and to ENISA. The manufacturer must therefore, in advance: register on the platform, hold live named accounts for on-call staff, and have **tested** submission. ### The three stages — actively exploited vulnerability | Deadline | Deliverable | Content | | --- | --- | --- | | **≤ 24 hours** of becoming aware | **Early warning** | Indication of the Member States in which the product was made available; where applicable, suspected malicious character | | **≤ 72 hours** | **Vulnerability notification** | General information on the product, nature of the vulnerability, corrective or mitigating measures taken and those users can apply | | **≤ 14 days** after a corrective measure is available | **Final report** | Description of the vulnerability, severity and impact, information on the threat actor where available, details of the fix | ### The three stages — severe incident | Deadline | Deliverable | Content | | --- | --- | --- | | **≤ 24 hours** | **Early warning** | Indication of the suspected malicious character of the incident | | **≤ 72 hours** | **Incident notification** | Assessment of the incident, severity, impact, indicators of compromise where available | | **≤ 1 month** | **Final report** | Detailed description, severity and impact, type of threat or likely root cause, mitigation measures applied and ongoing | ### Informing users Independently of reporting to authorities, the manufacturer informs, **without undue delay**, the affected users — and, where applicable, all users — of the vulnerability or incident and of the **corrective or mitigating measures** they can apply. That information does not wait for the final report. It is distinct from the publication of a security advisory under Annex I, Part II, point 4, which follows once the fix is available. ### Voluntary reporting The Regulation allows **voluntary** reporting of vulnerabilities, incidents, near misses or cyber threats, even outside any obligation. A voluntary report imposes **no additional obligation** on its author. > **Practical consequence for your decision rule.** Where there is serious doubt about the > qualification, **reporting** is the default position: a voluntary report costs nothing in > law; a missed report does not. ### Confidentiality and delayed dissemination Reported information is protected: authorities and ENISA handle it while preserving trade secrets and intellectual property rights, and use it only for the purposes provided for. A coordinating CSIRT may also **delay dissemination** of a notification to other authorities, for a limited time and on justified cyber risk grounds — typically where dissemination would widen the risk before a fix is available. ### The extended time scope This is the most frequently missed point: > The Article 14 reporting obligations apply **also to products placed on the market before > 11 December 2027**, by derogation from the general transitional regime. Your **legacy portfolio** has therefore been in scope since 11 September 2026, even though it has neither a CRA CE marking nor technical documentation. That means knowing, for every product still deployed at customers: which versions are in circulation, which components they contain, and how to reach the users. ### Do not confuse The CRA / NIS 2 / GDPR comparison table is in [Interplay with other legislation](/en/cra/interplay/). A single event can trigger all three notifications, to three different recipients. The operational run-through — cell, roles, templates, on-call, exercises — is in [24 h / 72 h / 14 d procedure](/en/cyber/24h-runbook/); the legal decision to report is in [Reporting duties](/en/legal/reporting-duties/). ## Essential requirements URL: https://cra-reference.eu/en/cra/essential-requirements/ Description: Annex I: thirteen product security requirements in Part I, eight vulnerability handling obligations in Part II. The substance of the Regulation, identical for every class. Audience: cyber Legal basis: Art. 13 — obligations of manufacturers · Annex I, Parts I and II Published 2026-08-19, updated 2026-08-19 Annex I is the heart of the Regulation. It applies **identically whatever the criticality class**; what varies is how compliance is proven. It reads in two parts, very different in nature. | | **Part I — Product security** | **Part II — Vulnerability handling** | | --- | --- | --- | | Nature | Properties of the product at placing on the market | A **process** to run throughout the support period | | Horizon | A point in time | Continuous, five to ten years | | Evidence | Design, tests, configuration | Logs, SBOM, published advisories, measured intervals | | Detail | [Product security](/en/cra/essential-requirements/product-security/) | [Vulnerability handling](/en/cra/essential-requirements/vulnerability-handling/) | ### The proportionality principle Part I requirements apply "as appropriate to the product". That wording is not an escape hatch: it requires a **documented cybersecurity risk assessment** justifying, requirement by requirement, which are retained and which are ruled out. A requirement ruled out without documented justification is non-compliance. A requirement ruled out with a reasoned risk assessment is a defensible design decision. The difference is one document. The risk assessment is, in any case, an item expressly expected in the [technical documentation](/en/cra/technical-documentation/). ### What to produce A **traceability matrix**, kept per product, with one row per requirement: | Column | Content | | --- | --- | | Requirement | Reference in Annex I | | Applicable? | Yes / No, with a pointer to the risk assessment | | Control | The technical or organisational measure covering it | | Evidence | The artefact attesting it — test, configuration, log, document | | Tool | What produces the evidence | | Owner | By name | | Last verified | Date | This matrix is the most useful working document of the programme: engineering uses it to know what to build, Legal to compile the file, and the auditor to verify. ### The link to the presumption of conformity The Regulation prescribes no technical solution. It prescribes outcomes. The **presumption of conformity** allows those outcomes to be met by applying harmonised standards, common specifications or certification schemes — see [Conformity assessment](/en/cra/conformity-assessment/). Absent a published harmonised standard, conformity may still be demonstrated by other means: it simply takes longer to document, and it closes the module A route for class I products. ## Product security (Annex I, Part I) URL: https://cra-reference.eu/en/cra/essential-requirements/product-security/ Description: The thirteen design requirements: secure default configuration, no known exploitable vulnerabilities, encryption, integrity, data minimisation, logging, secure erasure. Audience: cyber Legal basis: Annex I, Part I · Art. 13(2) and (3) — risk assessment Published 2026-08-19, updated 2026-08-19 ### The overarching requirement Products with digital elements are **designed, developed and produced in such a way that they ensure an appropriate level of cybersecurity based on the risks**. Everything else follows. "Appropriate based on the risks" means the reference is not a universal catalogue of measures but **your documented risk assessment**. ### The requirements, one by one #### No known exploitable vulnerabilities The product is made available **without known exploitable vulnerabilities**. That requires a blocking gate at the end of the build chain, fed by the [SBOM](/en/sbom/) and by vulnerability sources — see [CI/CD integration](/en/cyber/ci-cd/). #### Secure by default configuration The product ships in a **secure by default configuration**, with the ability to **reset it to its original state**. Concretely: no shared default passwords, no service exposed without need, no active maintenance account. #### Remediation through security updates Vulnerabilities can be addressed through **security updates**, including, where appropriate, **automatic updates enabled by default**, with a clear **opt-out mechanism**, notification of available updates and the ability to defer them. #### Protection from unauthorised access Protection through **appropriate control mechanisms** — authentication, identity and access management — and **reporting of unauthorised access**. #### Confidentiality Protection of the **confidentiality** of data stored, transmitted or processed, through **encryption at rest and in transit** using state-of-the-art mechanisms. #### Integrity Protection of the **integrity** of data, commands, programs and configuration against any unauthorised manipulation or modification, and **reporting of corruption**. #### Data minimisation Processing only data that is **adequate, relevant and limited to what is necessary** in relation to the product's intended purpose. A mirror of the GDPR requirement, but here independent of whether the data is personal. #### Availability of essential functions Protection of the **availability of essential and basic functions**, including resilience against and mitigation of denial-of-service attacks. #### Not harming other systems **Minimising the negative impact** of the product on the availability of services provided by other devices or networks — a product must not become an attack relay. #### Limiting attack surfaces **Limiting attack surfaces**, including external interfaces: services disabled, ports closed, debug functions removed from production builds. #### Reducing incident impact Use of **appropriate exploitation mitigation mechanisms and techniques**: compartmentalisation, least privilege, binary hardening, memory protections. #### Logging and monitoring Providing security-related information by **recording and monitoring relevant internal activity**, including access to and modification of data, services and functions, with the **ability for the user to opt out**. #### Secure erasure and portability The ability for users to **securely and permanently remove** all data and settings and, where such data can be transferred to other products or systems, to do so securely. ### What makes these requirements verifiable None of these requirements is verifiable as written. Each must be turned into a **test criterion**: | Requirement | Typical test criterion | | --- | --- | | No known exploitable vulnerabilities | Blocking software composition analysis, defined threshold, VEX for exceptions | | Secure default configuration | Hardening baseline, install test from factory state | | Encryption | Inventory of flows and stores, verification of cipher suites | | Integrity | Signature verification at boot and at update, rollback test | | Attack surface | Map of ports and interfaces, delta against the specification | | Logging | Presence of expected events, opt-out test | | Erasure | Reset test, verification of non-recoverability | That table is the entry point to the traceability matrix described in [Essential requirements](/en/cra/essential-requirements/). ### Reference frameworks Pending harmonised standards, several frameworks cover a large share of these requirements and yield reusable evidence: **IEC 62443-4-1** (secure development process) and **62443-4-2** (technical component requirements), **[NIST SP 800-218](https://csrc.nist.gov/pubs/sp/800/218/final)** (Secure Software Development Framework), **[ETSI EN 303 645](https://www.etsi.org/deliver/etsi_en/303600_303699/303645/)** (consumer IoT), **EN 18031-1/-2/-3** (radio equipment), **ISO/IEC 27001**. Careful: applying these frameworks confers **no presumption of conformity** under the Regulation until they are harmonised standards cited in the *Official Journal*. They make the demonstration easier; they do not replace it. ## Vulnerability handling (Annex I, Part II) URL: https://cra-reference.eu/en/cra/essential-requirements/vulnerability-handling/ Description: The eight process obligations: SBOM, remediation without delay, regular testing, publishing advisories, CVD policy, information sharing, secure and free distribution of fixes. Audience: cyber Legal basis: Annex I, Part II, points 1 to 8 · Art. 13(5) and (6) — due diligence on third-party components Published 2026-08-19, updated 2026-08-19 This is where the SBOM becomes a **legal obligation**, and it is the part of Annex I that commits over time: it describes a process to run throughout the [support period](/en/cra/support-period/). ### The eight obligations #### 1. Identify and document — the SBOM > Identify and document vulnerabilities and components contained in the product, **including > by drawing up a software bill of materials in a commonly used and machine-readable format > covering at the very least the top-level dependencies** of the product. The detail is set out in [What the CRA requires of the SBOM](/en/sbom/cra-requirement/). Remember that "top-level" is a **legal floor**, and that the Commission may specify by implementing act the format and elements expected. #### 2. Address and remediate without delay Address and remediate vulnerabilities **without delay**, including by providing security updates. Where **technically feasible**, security updates are provided **separately** from functionality updates. That separation carries a heavy engineering consequence: it requires **maintenance branches** and backporting capability, hence a versioning strategy decided at design time. See [Secure updates](/en/cyber/secure-updates/). #### 3. Test and review regularly Apply **effective and regular security tests and reviews**. "Regular" implies a defined cadence that is actually kept, not a test at the release of a major version. #### 4. Publish information on fixed vulnerabilities Once a security update is available, **publicly disclose information about fixed vulnerabilities**: description, identification of affected products, impacts, severity, and information helping users remediate. In practice: **security advisories** published, ideally in **[CSAF 2.0](https://www.csaf.io/)** format, machine readable so your customers can process them automatically. #### 5. Put in place and enforce a CVD policy Put in place **and enforce** a policy on **coordinated vulnerability disclosure**. Both verbs matter: a policy that is published but whose reports go unanswered does not satisfy the requirement. See [Disclosure policy](/en/cyber/disclosure-policy/). #### 6. Facilitate information sharing Take measures to **facilitate the sharing of information** about potential vulnerabilities in the product and in the third-party components it contains, including by providing a **contact address**. #### 7. Distribute updates securely Provide for **mechanisms to securely distribute updates**, ensuring that vulnerabilities are fixed or mitigated in a timely manner and, where applicable for security fixes, in an **automatic** manner. #### 8. Distribute without delay and free of charge Ensure that available fixes and updates are disseminated **without delay** and, except for tailor-made products between businesses where otherwise agreed, **free of charge**, accompanied by **advisory messages** telling users what action to take. > **Frequently missed.** Free security fixes are a rule, not a commercial option. Charging for > a maintenance contract as a condition of access to security fixes during the support period > is incompatible with this requirement. ### Due diligence on third-party components Two complementary obligations in Article 13 frame the use of components you do not write — including free ones: - **Due diligence on integration**: assess the quality and maintenance of the component, check for known exploitable vulnerabilities, examine the security history, release frequency and licence. That diligence must be **documented**. - **Reporting upstream**: where a vulnerability is identified in a component, including a free one, **report it to the person or entity manufacturing or maintaining that component**, fix it, and — where relevant — **share the fix with the upstream project**. See [Integrating open source](/en/cra/open-source/integrating-oss/). ### The evidence to build | Obligation | Evidence artefact | | --- | --- | | 1 | Signed, archived SBOM per version | | 2 | Timestamped handling log, intervals measured by severity, patch branches | | 3 | Dated test reports, test plan, coverage | | 4 | Published advisories, browsable history | | 5 | Published CVD policy, register of reports received and their handling | | 6 | Live contact address, `security.txt`, acknowledgements | | 7 | Description of the mechanism, signing keys, update tests | | 8 | Publication history, advisory messages, evidence of free-of-charge supply | ## Exclusions from scope URL: https://cra-reference.eu/en/cra/exclusions/ Description: Medical devices, motor vehicles, civil aviation, marine equipment, defence, spare parts, non-commercial open source: what the Regulation leaves out, and the false friends. Audience: legal Legal basis: Art. 2, paragraphs 2 to 7 Published 2026-08-19, updated 2026-08-19 Over-scoping costs as much as under-scoping. Many organisations apply the CRA to products that are expressly excluded, while forgetting components that are firmly inside. ### Sectoral exclusions — the *lex specialis* rule The legislator carved out sectors that already have an equivalent or stricter cybersecurity regime. The exclusion rests on the **text that covers the product**, not on the company's line of business. | Excluded products | Prevailing text | Applicable cybersecurity regime | | --- | --- | --- | | **Medical devices** | [Regulation (EU) 2017/745](https://eur-lex.europa.eu/eli/reg/2017/745/oj) (MDR) | MDR Annex I requirements, MDCG 2019-16 guidance | | **In vitro diagnostic medical devices** | [Regulation (EU) 2017/746](https://eur-lex.europa.eu/eli/reg/2017/746/oj) (IVDR) | Same, IVD strand | | **Motor vehicles** | [Regulation (EU) 2019/2144](https://eur-lex.europa.eu/eli/reg/2019/2144/oj) | UN Regulations R155 (cybersecurity management system) and R156 (software update) | | **Civil aviation** | [Regulation (EU) 2018/1139](https://eur-lex.europa.eu/eli/reg/2018/1139/oj) | The "Part-IS" delegated regulation on information security | | **Marine equipment** | [Directive 2014/90/EU](https://eur-lex.europa.eu/eli/dir/2014/90/oj) | The marine equipment regime | ### Exclusions linked to national security and defence - Products **developed or modified exclusively for national security or defence purposes**. - Products **specifically designed to process classified information**. The word "exclusively" is decisive: a dual-use product also sold on the civil market is not excluded in its civil version. ### Other exclusions - **Spare parts** placed on the market to replace identical components in existing products and manufactured to the same specifications. - **Free and open-source software not supplied in the course of a commercial activity** — the full regime is set out in [Open source](/en/cra/open-source/). - **Products intended exclusively for research** and prototypes not placed on the market. - **Unfinished products** made available for testing or demonstration and not intended for end use. ### The false friends Four traps recur. **1. A component of an excluded product is not excluded.** A medical device falls under the MDR, but the communications library you sell into it, placed on the market separately, is a PDE in its own right — with its own CE marking under the CRA. **2. A sectoral exclusion does not exempt from NIS 2.** An essential or important entity remains subject to its risk management obligations, including supply chain security, whatever products it manufactures. **3. "You sell a service, not a product" is not an exclusion.** See the qualification of remote data processing solutions in [Scope](/en/cra/scope-pde/). **4. "It is open source" is not an exclusion in itself.** What is excluded is supply **outside a commercial activity**. Free software you embed in a product you sell engages your full responsibility: see [Integrating open source](/en/cra/open-source/integrating-oss/). ### What to produce For every product ruled out of scope, a reasoned **exclusion sheet**: the sectoral text relied on, its exact reference, the justification for its applicability, date and signatory. An undocumented exclusion is indefensible before a market surveillance authority, and the cost of demonstrating it after the fact bears no relation to the cost of a one-page sheet written at the right moment. ## Interplay with other legislation URL: https://cra-reference.eu/en/cra/interplay/ Description: NIS 2, Cybersecurity Act, AI Act, RED, Machinery, GPSR, DORA, GDPR, product liability: where the CRA stops, where it overlaps, and how to pool evidence. Audience: legal Legal basis: Art. 2 — scope · Art. 12 — relationship with Regulation (EU) 2024/1689 Published 2026-08-19, updated 2026-08-19 The CRA does not stand alone. This page serves two purposes: avoiding duplicated work by pooling evidence, and avoiding blind spots between two regimes. ### Interplay table | Text | What it governs | Relationship to the CRA | | --- | --- | --- | | **[Directive (EU) 2022/2555 (NIS 2)](https://eur-lex.europa.eu/eli/dir/2022/2555/oj)** | **Entities**: risk governance, supply chain security, incident notification | Complementary. The CRA governs **products**, NIS 2 governs **organisations**. One group can fall under both. Convergence point: the European vulnerability database (EUVD), created under NIS 2, is fed by CRA reports. | | **[Regulation (EU) 2019/881 (Cybersecurity Act)](https://eur-lex.europa.eu/eli/reg/2019/881/oj)** | European cybersecurity certification schemes, including **EUCC** | An instrument the CRA relies on: a certificate at assurance level at least "substantial" counts as a conformity assessment route. | | **[Regulation (EU) 2024/1689 (AI Act)](https://eur-lex.europa.eu/eli/reg/2024/1689/oj)** | AI systems, including high-risk ones | Explicit articulation: for a high-risk AI system that is also a PDE, compliance with the CRA essential requirements gives a **presumption of conformity** with the cybersecurity requirements of AI Act Article 15, to the extent they are covered. | | **[Directive 2014/53/EU (RED)](https://eur-lex.europa.eu/eli/dir/2014/53/oj)** and [Delegated Regulation (EU) 2022/30](https://eur-lex.europa.eu/eli/reg_del/2022/30/oj) | Cybersecurity of radio equipment, standards **EN 18031-1/-2/-3** | An interim regime, to be **superseded by the CRA** for products covered by both. Work done on EN 18031 remains reusable as evidence. | | **[Regulation (EU) 2023/1230 (Machinery)](https://eur-lex.europa.eu/eli/reg/2023/1230/oj)** | Machinery safety, including protection against corruption of safety software | Partial overlap on safety functions; the two markings coexist. | | **[Regulation (EU) 2023/988 (GPSR)](https://eur-lex.europa.eu/eli/reg/2023/988/oj)** | General consumer product safety | Residual safety net, applicable where no sectoral legislation exists. | | **[Regulation (EU) 2022/2554 (DORA)](https://eur-lex.europa.eu/eli/reg/2022/2554/oj)** | Digital operational resilience of the financial sector and its critical ICT providers | If you supply financial entities, their contractual requirements often anticipate the CRA's. | | **[Regulation (EU) 2016/679 (GDPR)](https://eur-lex.europa.eu/eli/reg/2016/679/oj)** | Personal data protection | Overlap on security by design (Art. 25) and security of processing (Art. 32). **The notifications do not merge**: see below. | | **[Directive (EU) 2024/2853](https://eur-lex.europa.eu/eli/dir/2024/2853/oj)** | Product liability | Now explicitly covers software, and takes the **absence of security updates** into account when assessing defectiveness. A CRA breach becomes evidence in a civil claim. | | **[Regulation (EU) 2019/1020](https://eur-lex.europa.eu/eli/reg/2019/1020/oj)** | Market surveillance | Amended by the CRA; grounds the powers of national authorities. | ### The concurrent notification trap A single event — a compromise exploiting a flaw in your product, with customer data leaking — can trigger **three separate notifications**, to three recipients, within three deadlines, with three different contents. | | **CRA (Art. 14)** | **NIS 2** | **GDPR (Art. 33)** | | --- | --- | --- | --- | | Subject | **Actively exploited** vulnerability in your product, or severe incident affecting its security | Significant incident affecting the provision of your services | Personal data breach | | Who notifies | The product **manufacturer** | The essential or important **entity** | The **controller** | | Recipient | **Coordinating CSIRT + ENISA**, via the single reporting platform | National CSIRT or competent authority | Data protection authority | | Early warning | **24 h** | 24 h | — | | Notification | **72 h** | 72 h | **72 h** | | Final report | **14 days** after a corrective measure is available (vulnerability) or **1 month** (incident) | 1 month | — | | Informing individuals / users | Affected users, without undue delay | Recipients of services, where applicable | Data subjects, where high risk | > **Organisational consequence.** A single crisis cell must rule on all three regimes at once, > with three distinct templates ready to use. Handling the regimes in sequence mechanically > misses the shortest deadline. ### Pooling evidence Many artefacts serve several texts at once. Produce them once, file them once: | Artefact | CRA | NIS 2 | GDPR | Customers | | --- | --- | --- | --- | --- | | SBOM | Annexes I and VII | Supply chain | — | Tenders | | Cybersecurity risk assessment | Art. 13, Annex VII | Risk management | Art. 32 | Questionnaires | | Coordinated disclosure policy | Annex I, Part II | Expected good practice | — | Market expectation | | Vulnerability handling log | Annex I, Part II | Incident management | Breach register | Audits | | Notification procedure | Art. 14 | Incident notification | Art. 33 | — | | Encryption and access control | Annex I, Part I | Technical measures | Art. 32 | Certifications | That "one piece of evidence, several texts" column is what makes the programme fundable: the CRA does not add a silo, it structures evidence that was already partly owed. ## Market surveillance URL: https://cra-reference.eu/en/cra/market-surveillance/ Description: Authorities' powers, the procedure for products presenting a significant risk, formal non-compliance, coordinated sweeps, and the response card for an authority request. Audience: legal Legal basis: Chapter V — market surveillance and enforcement · Regulation (EU) 2019/1020, as amended Published 2026-08-19, updated 2026-08-19 ### Authorities' powers Market surveillance authorities exercise the powers set out in Regulation (EU) 2019/1020, as amended by the CRA. In particular they may: - **require the technical documentation** and the EU declaration of conformity; - request any **information necessary** to establish conformity; - **purchase products** on the market, including under a concealed identity, and subject them to **testing**; - carry out **inspections**; - in justified cases, request access to elements of the **source code** in order to assess conformity with the essential requirements, subject to confidentiality; - order **corrective measures**, restrict or prohibit making available, order withdrawal or recall. ### The "significant risk" procedure Where an authority has sufficient reason to consider that a product presents a **significant cybersecurity risk**, it carries out an evaluation. If non-compliance is established, it **orders** the operator to take appropriate corrective measures within a reasonable period. If the operator does not act, the authority **restricts or prohibits** making the product available, orders its withdrawal or recall, and **informs the Commission and the other Member States**. A phase then opens in which other States may object; failing that, the measure is deemed justified and extended. A **Union safeguard procedure** allows the Commission to intervene where Member States disagree or where the risk is Union-wide. ### Formal non-compliance Distinct from risk: it concerns documentary failings. It covers in particular: - a **missing CE marking**, or one affixed in breach of the rules; - the absence of the **notified body identification number** where required; - an **EU declaration of conformity** that is missing or does not comply with Annex V; - **technical documentation** unavailable, incomplete or not retained; - the absence of the **manufacturer's details** or of the **contact point** for reporting; - the absence of the **Annex II information to the user**. It leads to an order to regularise and, if it persists, to the same measures as substantive non-compliance. ### Coordinated activities The Commission and the **administrative cooperation group (ADCO)** may organise **coordinated sweeps** on a product category or a particular requirement, simultaneously in several Member States. These campaigns are announced and their results published. They are the most likely form of inspection for widely distributed products. ### Response card: you receive a request from an authority To print and keep with the crisis procedures. 1. **Acknowledge receipt immediately**, confirming the single point of contact on your side — named in advance, with a deputy. 2. **Qualify the request**: which authority, which Member State, which product, which version, which legal basis, what deadline. 3. **Freeze the evidence**: lock the versions of the technical documentation, SBOM and logs corresponding to the version at issue. Change nothing retroactively. 4. **Assemble the response**: the technical documentation as it stood when the product was placed on the market, the declaration, and the items requested — without adding backdated documents, which would amount to supplying misleading information. 5. **Have Legal approve** before anything is sent. 6. **Respond within the deadline**, formally requesting an extension if the deadline is untenable — a reasoned request beats silence. 7. **Log** every exchange in the register, with timestamps. 8. **Inform** the committee and, if the matter could be material, executive management. ### What a request really tests A request from an authority tests your **archiving**, not your security. The question is not "is your product secure?" but "can you produce, within days, the exact file for a version shipped four years ago?". The answer is prepared years in advance: see [Evidence retention](/en/legal/evidence-retention/). ## Free and open-source software URL: https://cra-reference.eu/en/cra/open-source/ Description: The criterion is not the licence but the commercial nature of the supply. Four statuses, from the out-of-scope individual contributor to the fully responsible manufacturer. Audience: transverse Legal basis: Art. 2 — scope · Art. 3, point 14 — definition of open-source software steward · Art. 24 — obligations of open-source software stewards · Art. 25 — voluntary attestations of conformity Published 2026-08-19, updated 2026-08-19 The treatment of free software is the most discussed and most misunderstood part of the Regulation. One idea governs the whole reading: > **The distinguishing criterion is not the licence, it is the commercial nature of the > supply.** A free licence does not take you out of scope; a non-commercial activity does. ### The four statuses | Status | Who | Regime | | --- | --- | --- | | **[Individual developer or contributor](/en/cra/open-source/individual-developer/)** | A natural person or entity developing free software **outside a commercial activity** | **Out of scope.** No obligations. | | **[Open-source software steward](/en/cra/open-source/steward/)** | A legal person, other than a manufacturer, providing **systematic and sustained** support to the development of free software products intended for commercial activities, and ensuring their viability | **Lightened regime**: cybersecurity policy, cooperation, reporting. No CE marking, no technical documentation, no fines. | | **[Manufacturer integrating open source](/en/cra/open-source/integrating-oss/)** | You, in the vast majority of cases | **Full regime**, with **due diligence** on third-party components and **upstream reporting**. | | **Manufacturer distributing free software commercially** | A vendor monetising free software | **Full regime**, like any manufacturer. | ### Why the legislator did it this way The reasoning, worth knowing for internal arguments: subjecting the free software ecosystem to manufacturer obligations would have made volunteer contribution impossible while leaving untouched the responsibility of those who derive commercial value from it. The Regulation therefore puts the burden **on whoever places the product on the market**, not on whoever writes the code upstream. Corollary: **you cannot shift your responsibility upstream**. The maintainer of a library you embed answers for nothing on your behalf. ### Points to watch in your organisation **Do your employees contribute upstream on work time?** If so, in what framework, and does it make you a steward for some projects? An internal contribution policy must settle the question and be documented. **Do you publish free software projects yourselves?** If they are made available outside a commercial activity, they are out of scope. If they accompany a commercial offering, the qualification must be examined product by product. **Do you run or fund a foundation?** The open-source software steward status may then be in play, with its own obligations — lightened but real. ### Voluntary attestations of conformity The Regulation provides for a **voluntary attestation** mechanism: a developer or user of free software may draw up, on a voluntary basis, an attestation regarding the security properties of the component. Such attestations do not bind their author as a declaration of conformity, but they are a useful input to downstream integrators' **due diligence**. For you they have two uses: **consuming** them — an upstream attestation enriches your diligence file — and possibly **producing** them for the components you publish, which makes it easier for other CRA-bound manufacturers to adopt your building blocks. ## Individual developers and contributors URL: https://cra-reference.eu/en/cra/open-source/individual-developer/ Description: What does and does not push free software activity into the commercial sphere: donations, forges, paid support, corporate funding, and the question of your own contributions. Audience: legal Legal basis: Art. 2 — scope Published 2026-08-19, updated 2026-08-19 ### The rule Free and open-source software **not supplied in the course of a commercial activity** is outside the scope of the Regulation. No obligation falls on the developer, natural or legal person, who makes their work available on that basis. The whole difficulty lies at the boundary of "commercial". ### What is not enough to make an activity commercial The recitals expressly rule out several situations: - **contributing** to a free software project, even regularly and substantially; - **hosting** code on a forge or public repository, including with paid services for the maintainer; - **accepting donations** intended to cover development or infrastructure costs; - charging for **ancillary services** — technical support, consulting, training — distinct from the supply of the software itself; - **collaborating** with companies that use the software, including by integrating their contributions. ### What tips it over The activity becomes commercial when the software itself is supplied within a business relationship. Converging indicators: - the software is **charged for**, in any form — licence, subscription, access; - development is carried out **for remuneration** within an identified commercial relationship; - the free software serves as a **lead product** for a linked paid offering, such as an enterprise edition or reserved features; - the entity **integrates** the software into a product it places on the market — but then it is a **manufacturer**, which is a different status. ### Your own contributions Three situations must be settled by a written internal policy. **1. An employee contributes to an upstream project, on work time, to fix a defect that affects you.** This is the most common and healthiest case. It makes you neither a manufacturer of the upstream project nor a steward: you remain a user who contributes. The Regulation in fact expressly encourages sharing security fixes upstream — see [Integrating open source](/en/cra/open-source/integrating-oss/). **2. You publish a free software project arising from your work, with no associated commercial offering.** Out of scope as long as the supply remains non-commercial. To be re-examined if a paid offering is later attached to it. **3. You durably fund the development of a free software project you do not manufacture, and you ensure its viability.** That is the definition of an **open-source software steward**: see the [dedicated page](/en/cra/open-source/steward/). ### What to write down A short **internal open source contribution policy** answering: - In what cases may an employee contribute to an upstream project on work time? - Under whose identity — personal or corporate? - Who authorises the publication of a new free software project by the company? - Who verifies, before publication, that the project does not tip into an unintended commercial qualification? - How are your upstream security fix submissions documented, given that the Regulation expects them and they constitute evidence of due diligence? The policy belongs to Legal but is applied by engineering: it must fit on one page. ## Integrating open source URL: https://cra-reference.eu/en/cra/open-source/integrating-oss/ Description: Your most common situation: full regulatory responsibility, documented due diligence, upstream reporting of fixes, and handling abandoned components. Audience: cyber Legal basis: Art. 13(5) — due diligence on third-party components · Art. 13(6) — upstream reporting and sharing the fix · Annex I, Part II Published 2026-08-19, updated 2026-08-19 ### The core rule When you integrate a free component into a product you place on the market, **you carry the full regulatory responsibility for it**. Upstream is not responsible on your behalf, whatever the licence. That follows directly from the Regulation's architecture: responsibility tracks **placing on the market**, not writing the code. ### The due diligence obligation The manufacturer must exercise **due diligence when integrating components sourced from third parties**, including free components, so that those components do not compromise the cybersecurity of the product. That diligence must be **documented**, component by component, to be defensible. #### Diligence grid | Criterion | What you check | Source | | --- | --- | --- | | **Known vulnerabilities** | No unfixed known exploitable vulnerability | EUVD, OSV, NVD, upstream advisories | | **Project activity** | Release frequency, date of last commit, number of active maintainers | Repository | | **Governance** | Backed by a foundation or a [steward](/en/cra/open-source/steward/)? Single maintainer? | Project documentation | | **Upstream security policy** | Existence of a `SECURITY.md`, a reporting channel, an advisory history | Repository | | **Historical responsiveness** | Average interval between report and fix on past vulnerabilities | Advisory history | | **Licence** | SPDX identifier, family, compatibility with your policy | [Licence families](/en/licensing/families/) | | **Upstream SBOM** | Does the project publish an SBOM itself? | Project releases | | **Artefact signing** | Are releases signed and verifiable? | Releases | | **Depth** | Number and nature of transitive dependencies introduced | Analysis | A composite score supports the decision to adopt, adopt under watch, or refuse. The completed grid is filed with the product's diligence file. > **This grid is unworkable by hand beyond a few dozen components**, and a real dependency graph > holds thousands. Six of these nine criteria can be computed automatically: see > **[Assessing an open source component](/en/cyber/assessing-components/)**, which covers the > tooling, what it captures, what it does not tell you, and the threshold policy to write. ### The upstream reporting obligation Where you identify a vulnerability in an integrated component, including a free one, you must: 1. **report it to the person or entity manufacturing or maintaining** that component; 2. **address and remediate** the vulnerability in your product; 3. where relevant, **share with the upstream project the fix** you developed. This is an obligation, not a good practice. It requires a tooled process: - an **identified channel** to each critical upstream project — security address, private reporting procedure; - a **log of submissions**: date, project, vulnerability, content of the report, response received, fix shared; - a **contribution policy** allowing your engineers to publish a fix under the upstream project's licence, without a legal review cycle of several weeks that would make the obligation impossible to meet. > **A frequent point of friction.** An intellectual property policy that forbids employees from > publishing any code makes it impossible to meet this obligation. The two policies must be > reconciled explicitly, in writing. ### Abandoned components An unmaintained component inside a product covered by a five-year support period is a **regulatory liability**: there will be nobody upstream to fix the next vulnerability. Four strategies, to be decided product by product and documented: | Strategy | When | Cost | | --- | --- | --- | | **Replace** | A maintained alternative exists | Migration cost, one-off | | **Fork and maintain** | No alternative, central component | Recurring, over the whole support period | | **Bring in-house** | The component is small and its scope stable | Take-over cost, then maintenance | | **Contribute to reviving it** | The project is viable but under-resourced | Recurring, outcome not guaranteed | "Do nothing and hope" is not defensible before an authority, since the end of upstream maintenance is a public fact and therefore known to you. ### The malicious takeover watch point An abandoned component whose control is taken over by a third party is a documented supply chain attack vector. Monitoring **maintainer changes** on critical dependencies is part of ongoing diligence — see [Supply chain risk](/en/cyber/supply-chain-risk/). ## The open-source software steward URL: https://cra-reference.eu/en/cra/open-source/steward/ Description: Definition, the obligations actually owed, what stewards are not subject to — including fines — and your self-qualification grid. Audience: legal Legal basis: Art. 3, point 14 — definition · Art. 24 — obligations of open-source software stewards · Art. 14(1) and (3) — reporting · Art. 64 — penalties (stewards excluded) Published 2026-08-19, updated 2026-08-19 This is the CRA's genuine innovation on open source: the creation of an intermediate status between the volunteer contributor, out of scope, and the manufacturer, fully responsible. ### The definition An **open-source software steward** is a **legal person, other than a manufacturer**, which has the purpose or objective of **systematically providing support on a sustained basis** for the development of **specific products with digital elements, qualifying as free and open-source software and intended for commercial activities**, and which **ensures the viability** of those products. Four cumulative elements, each of them discriminating: | Element | What it rules out | | --- | --- | | **Legal person, other than a manufacturer** | Natural persons; whoever places the product on the market is a manufacturer, not a steward | | **Systematic and sustained support** | One-off funding, occasional patronage, episodic contribution | | **Products intended for commercial activities** | Purely academic or hobby projects | | **Ensures viability** | Mere hosting or matchmaking | The entities targeted are chiefly **software foundations** — Apache, Eclipse, the Linux Foundation and their equivalents — and certain structures providing sustained funding for code. ### The obligations actually owed The list is **exhaustive**. A steward must: 1. **put in place and document, in a verifiable manner, a cybersecurity policy** to foster the development of a secure product and effective handling of vulnerabilities, **appropriate to the nature of the entity and its resources**; 2. **cooperate with market surveillance authorities**, at their request, to mitigate the cybersecurity risks of the products concerned; 3. comply with the **reporting obligations** relating to **actively exploited vulnerabilities** and **severe incidents** affecting the security of the product, **to the extent it is involved in the development** of that product; 4. provide, on request from the authorities, the **necessary information** in a language easily understood. The phrase "appropriate to the nature of the entity and its resources" is essential: a foundation with three employees is not held to the same arrangement as one with two hundred people. ### What a steward is NOT subject to | Manufacturer obligation | Steward | | --- | --- | | CE marking | **No** | | EU declaration of conformity | **No** | | Annex VII technical documentation | **No** | | Conformity assessment procedure | **No** | | Annex I essential requirements as such | **No** — replaced by the cybersecurity policy | | Five-year support period | **No** | | Annex II information to the user | **No** | | **Administrative fines** | **No** — the financial penalty regime does not apply to stewards | The exclusion of administrative fines is the most commented point. It does not mean no consequences: market surveillance authorities keep their powers of injunction and cooperation, and a foundation's reputation is its principal asset. ### Your self-qualification grid Answer yes or no for each structure you run or fund: - [ ] Is the structure a separate **legal person**? - [ ] Is it **other than a manufacturer** of the product concerned — that is, does it not place the product on the market itself? - [ ] Does its purpose or objective include **supporting the development** of identified free software? - [ ] Is that support **systematic and sustained**, rather than one-off? - [ ] Is the software concerned **intended for commercial activities**, that is, used in products placed on the market by third parties? - [ ] Does the structure **ensure the viability** of that software — governance, funding, continuity over time? Six yeses: the steward status is probably established, and the four obligations above apply. A single no: it is not, but the qualification must be revisited if circumstances change. ### What this changes for you as an integrator A component maintained by an identified steward offers more assurance than one maintained by an isolated individual: there is a documented cybersecurity policy, a reporting channel and a duty to cooperate. That is a **selection criterion** to build into your diligence grid — see [Integrating open source](/en/cra/open-source/integrating-oss/). ## Penalties URL: https://cra-reference.eu/en/cra/penalties/ Description: The three-tier scale, the modulating criteria, non-financial measures — often heavier than the fine — and the interaction with product liability. Audience: direction Legal basis: Art. 64 — penalties · Art. 55 to 58 — market surveillance measures · Directive (EU) 2024/2853 — product liability Published 2026-08-19, updated 2026-08-19 ### The scale | Breach | Ceiling | | --- | --- | | Non-compliance with the **Annex I essential requirements** and the obligations in **Articles 13 and 14** (manufacturer obligations, reporting) | **EUR 15,000,000 or 2.5 % of total worldwide annual turnover** for the preceding financial year — whichever is higher | | Non-compliance with **any other obligation** under the Regulation | **EUR 10,000,000 or 2 %** | | **Supply of incorrect, incomplete or misleading information** to notified bodies and market surveillance authorities | **EUR 5,000,000 or 1 %** | Two structural points: - **open-source software stewards are not liable to administrative fines** — see [The open-source software steward](/en/cra/open-source/steward/); - the situation of **micro, small and medium-sized enterprises**, including start-ups, is taken into account when setting the amount. Member States set the national penalty regime within these ceilings and notify it to the Commission. ### Modulating criteria The amount is not mechanical. Account is taken, among other things, of: - the **nature, gravity and duration** of the infringement and its consequences; - whether the breach was **intentional or negligent**; - **measures taken to mitigate** the harm suffered by users; - **previous infringements** by the same operator; - the **degree of cooperation** with the authorities; - **financial benefits** gained from the breach, or losses avoided; - the **size** of the undertaking, in particular whether it is an SME. > **What that says about your posture.** A documented file, traced decisions and immediate > cooperation move the dial far more than technical perfection. The register of decisions — > report or do not report, fix or document in a VEX — is the central defensive record. ### Non-financial measures They are often heavier than the fine, and they arrive faster. | Measure | Effect | | --- | --- | | **Order to bring into conformity** within a set period | Emergency mobilisation, roadmap trade-offs | | **Restriction or prohibition of making available** on the Union market | Sales stop | | **Withdrawal from the market** | Pulling stock and distribution channels | | **Recall** of the product | Logistics cost, replacement cost, media exposure | | **Publication of the decision** | Lasting reputational effect | | **Union-level emergency measures** | In case of significant risk, via the safeguard procedure | For most players, a few months' prohibition on making a product available in the Union costs several times the maximum fine. ### Sizing your exposure The calculation to bring to the committee fits in three lines: 1. **Administrative exposure**: 2.5 % of consolidated turnover for the last financial year, compared with EUR 15 m — take the higher. 2. **Commercial exposure**: share of turnover made in the Union, multiplied by the plausible duration of a prohibition on making available. 3. **Contractual exposure**: penalties and termination rights in your customer contracts in the event of regulatory non-compliance. The method is detailed in [Exposure](/en/legal/exposure/). ### Civil liability The CRA combines with **Directive (EU) 2024/2853 on liability for defective products**, which now expressly covers **software** and takes the **absence of security updates** into account when assessing defectiveness. Consequence: a CRA breach — support period not honoured, fix not distributed, known vulnerability untreated — becomes **evidence** in a liability claim, independently of any administrative penalty. ### Insurance Two points to work through with the broker: - the **exclusion clauses** in cyber policies where a known regulatory obligation was not met; - cover for **recall costs** and forced remediation, which standard cyber policies rarely include. ## Regulation (EU) 2024/2847 URL: https://cra-reference.eu/en/cra/regulation-2024-2847/ Description: Identity, legal nature, objectives and structure of the Cyber Resilience Act, with publication milestones and the official sources to cite. Audience: legal Legal basis: Regulation (EU) 2024/2847 · Art. 1 — subject matter · Art. 71 — entry into force and application Published 2026-08-19, updated 2026-08-19 ### How to cite the text In full, once per document: > Regulation (EU) 2024/2847 of the European Parliament and of the Council of 23 October 2024 > on horizontal cybersecurity requirements for products with digital elements and amending > Regulations (EU) No 168/2013 and (EU) 2019/1020 and Directive (EU) 2020/1828 (Cyber > Resilience Act). Thereafter: "Regulation (EU) 2024/2847" or "the CRA". Avoid "the CRA directive" and "the CRA law", which are wrong and discredit the document they appear in. ### What "Regulation" means in practice | | Directive (e.g. NIS 2) | **Regulation (e.g. CRA)** | | --- | --- | --- | | Effect | Must be transposed into national law | **Directly applicable** | | National delay | A transposition deadline, often missed | None | | Variation between States | Possible, sometimes significant | Marginal | | Text to read | The national transposing law | **The European text itself** | There will therefore be no national CRA law to delay, soften or clarify the deadline. Member States intervene on three points only: designating authorities (market surveillance, notifying authority, coordinating CSIRT), setting the penalty regime within the ceilings the Regulation fixes, and support measures for small enterprises. ### The lineage: the new legislative framework The CRA is **Union harmonisation legislation**. It reuses the proven architecture of product directives and regulations: 1. **essential requirements** expressed as objectives, not technical solutions (Annex I); 2. a **presumption of conformity** for those applying harmonised standards; 3. **conformity assessment modules** graduated by risk; 4. **technical documentation** and an **EU declaration of conformity**; 5. the **CE marking** as the signal of conformity; 6. **market surveillance** after the fact, with power to withdraw. Two practical consequences. First, teams already handling other CE markings — machinery, radio equipment, toys — know this vocabulary: reuse their processes rather than inventing new ones. Second, the Regulation almost never says *how*: it says what result to achieve, and leaves the proof to the manufacturer. ### The legislator's five objectives Useful to cite in an internal memo justifying the effort: 1. reduce the number of vulnerable products placed on the Union market; 2. make manufacturers responsible for security **across the whole life cycle**, not only at the point of sale; 3. improve transparency about the security properties of products; 4. enable users — businesses and consumers — to choose and use secure products; 5. close the gaps between existing sectoral legislation. ### Date markers | Date | Event | | --- | --- | | 23 October 2024 | Adopted by the European Parliament and the Council | | 20 November 2024 | Published in the *Official Journal of the European Union* | | 10 December 2024 | Entry into force — the text is final, the clocks start | | 11 June 2026 | Application of the chapter on notification of conformity assessment bodies | | 11 September 2026 | Application of the Article 14 reporting obligations | | 11 December 2027 | Full application | The operational consequences of each date are set out in [The timeline](/en/cra/timeline/). ### Sources to rely on - **[EUR-Lex — Regulation (EU) 2024/2847](https://eur-lex.europa.eu/eli/reg/2024/2847/oj)** — the consolidated text, the only authoritative version. All language versions have equal legal force; where a national wording seems ambiguous, compare with English. - **[European Commission](https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act)** — the Cyber Resilience Act page: guidance, FAQ, delegated and implementing acts as they are adopted. - **[ENISA](https://www.enisa.europa.eu/)** — single reporting platform, [European vulnerability database](https://euvd.enisa.europa.eu/), technical documents. - **[CEN and CENELEC](https://www.cencenelec.eu/)** — progress of the harmonised standards (joint technical committee JTC 13, working group 9), which conditions the presumption of conformity. - **[ANSSI](https://cyber.gouv.fr/)** — national implementation guidance, and **[CERT-FR](https://www.cert.ssi.gouv.fr/)** for alerts. > **What is not a source.** Vendor blog posts, commercial white papers and unverified > AI-generated summaries circulate widely and contain recurring errors, particularly about > criticality classes and the status of open source. Any statement reused internally must be > traceable to an article or an annex. ## Scope: products with digital elements URL: https://cra-reference.eu/en/cra/scope-pde/ Description: Definition of a PDE, breakdown into hardware / software / remote data processing, triggering criteria, and the notions of placing on the market and substantial modification. Audience: legal Legal basis: Art. 2 — scope · Art. 3, points 1 and 2 — definitions · Art. 69 — transitional provisions Published 2026-08-19, updated 2026-08-19 This is the first question, and it conditions everything else: **are you in scope, and for which products?** ### The definition A **product with digital elements** (PDE) is *a software or hardware product and its remote data processing solutions, including software or hardware components being placed on the market separately* (Art. 3, point 1). Three elements, to be examined separately. #### Hardware Computers, servers, connected objects, network equipment, sensors, boards, chips, industrial controllers, payment terminals, medical-adjacent equipment not covered by the sectoral regulation, connected toys. #### Software Operating systems, applications, firmware, libraries, middleware, drivers — **including components placed on the market separately**. That last point is structural: a library you sell on its own is itself a PDE, with its own technical documentation and its own CE marking. #### Remote data processing solutions *Remote data processing designed and developed by the manufacturer, or under the responsibility of the manufacturer, and the absence of which would prevent the product with digital elements from performing one of its functions* (Art. 3, point 2). This is how the cloud enters the CRA. The criterion is **functional dependency**: if the connected object stops performing one of its functions when the back end goes down, that back end is within the product's scope. ### SaaS: in or out? The most frequently asked question, and the answer comes in two parts. | Case | Regime | | --- | --- | | Standalone SaaS application, sold as a service, with no associated product | **Out of CRA scope.** Falls, where applicable, under NIS 2 as a service of the entity. | | Back end inseparable from a connected product you sell | **In scope**, as the product's remote data processing solution. | | Downloadable software installed at the customer's site, even sold by subscription | **In scope**: it is a software product; the billing model is irrelevant. | | Optional administration portal whose absence deprives the product of no function | To qualify case by case; the absence of functional dependency argues for exclusion. | The business model is never the criterion. The criterion is **what is made available** and its **functional dependency** on the product. ### The cumulative triggering criteria A product falls under the Regulation when all three conditions are met: 1. it is **made available on the Union market**, wherever the manufacturer is established; 2. in the course of a **commercial activity**; 3. it has a **direct or indirect logical or physical data connection** to a device or network. "Indirect" is broad: a product that connects to nothing itself but exchanges data with another product that is connected satisfies the criterion. ### Three terms not to confuse - **Placing on the market** — the **first** making available of a product on the Union market. That is the moment at which conformity is assessed. - **Making available on the market** — any subsequent supply in the course of a commercial activity, whether for payment or free of charge. - **Putting into service** — the first use in accordance with its intended purpose. The pivot is this: conformity with the essential requirements is assessed **at the time of placing on the market**, but vulnerability handling and the supply of updates run **for the whole support period**. ### Substantial modification A modification is **substantial** where it changes the intended purpose of the product or affects its compliance with the essential requirements. It **brings the product back into scope** and triggers a new conformity assessment, updated technical documentation and, where applicable, a fresh involvement of the notified body. This notion carries the entire transitional regime: > Products placed on the market **before 11 December 2027** are subject to the Regulation only > if they are subsequently substantially modified — **except for the Article 14 reporting > obligations, which apply to all products within scope, including those already on the > market.** In other words: your legacy portfolio escapes CE marking, but **not** the 24-hour reporting obligation, which has applied since 11 September 2026. This is the point most often missed. A security update that fixes a vulnerability, with no other change, is not a substantial modification. ### What to produce A **qualification sheet** per product, filed with the technical documentation and signed, which decides explicitly: nature of the product, presence of a connection, presence of an associated remote data processing solution, commercial character, PDE status, date and signatory. A consolidated portfolio table follows from it. Products qualified as PDEs then go through [Exclusions](/en/cra/exclusions/) and [Criticality classes](/en/cra/criticality-classes/). ## Support period and life cycle URL: https://cra-reference.eu/en/cra/support-period/ Description: Five years minimum or the expected lifetime, ten years of fix availability, the duty to inform the buyer, end of support and cessation of operations: the CRA's long-term commitment. Audience: legal Legal basis: Art. 13(8) — support period · Annex II, point 8 — information to the user · Art. 13 — cessation of operations Published 2026-08-19, updated 2026-08-19 This is the most underestimated financial impact of the Regulation. The CRA does not only ask that a secure product be placed on the market: it asks that it be **kept secure for years**, including after it stops being sold. ### The rule The manufacturer determines the **support period** so as to reflect the **length of time the product is expected to be in use**. That period is **at least five years**. One exception only: if the **expected product lifetime is shorter than five years**, the support period corresponds to that lifetime. It is a narrow exception and must be reasoned; it applies because the product itself is not built to last, not because you would prefer a shorter commitment. ### The criteria to document The duration chosen must be justified in the [technical documentation](/en/cra/technical-documentation/), against: - **reasonable user expectations**; - the **nature of the product** and its use; - the **support periods of comparable products** on the market; - the **legislation applicable** to the product; - the **availability of the operating environment** — a product depending on an operating system whose support ends; - the **support periods of integrated components**, including free ones. That last criterion is the classic trap: you cannot guarantee five years on a product built on an upstream component maintained for two. Either you take over maintenance of that component, or you replace it, or you shorten — and justify — your support period. There is no fourth option. ### The ten-year rule on fixes Distinct from the support period, and often confused with it: after they are issued, **security updates remain available** for **at least ten years from the placing of the product on the market, or for the remainder of the support period, whichever is longer**. | | Support period | Availability of fixes | | --- | --- | --- | | What is owed | **Producing** fixes | **Making available** fixes already produced | | Duration | ≥ 5 years, or the expected lifetime | ≥ 10 years after placing on the market, or the support period if longer | | Consequence | Maintenance team, live build chain | Hosting, archiving, availability of the distribution channel | ### The duty to inform The **end date of the support period** must be communicated to the user in a clear and understandable manner **at the time of purchase**, expressed at least as a **month and year** (Annex II). It therefore appears in the product documentation, and should appear on the commercial datasheet. ### End of support and cessation of operations **Approaching end of support**: inform users, state the residual risk, offer a migration path, state the date after which no further fixes will be produced. **On cessation of operations**: the manufacturer informs the competent market surveillance authorities and, **by any means available**, the users of the products concerned. The Regulation also encourages, in that situation, transferring the source code or releasing it as free software so the community can maintain it. ### The financial translation — to carry to the committee This is the message for leadership: - keeping **reproducible build chains** and build environments alive for five to ten years, with the tools and dependencies of the time; - **backporting** fixes onto old branches, which requires available skills and a suitable versioning strategy; - **retaining** artefacts, SBOMs and technical documentation, with their storage and indexing cost; - **giving up the option of ending support** for a product still in use without regulatory consequence — commercial end of life no longer ends the obligations. ### The register to keep | Column | Content | | --- | --- | | Product and version | Traceable identification | | Date placed on the market | Start of the ten years | | Declared support period | Duration and end date, to the month | | Justification | Pointer to the section of the technical documentation | | Fixes available until | Calculated date | | Limiting components | Components whose upstream support ends earlier | | Estimated annual cost | Maintenance, hosting, archiving | | Owner | By name | The register is kept by Legal and fed by engineering. It is reviewed at every committee, because it is what reveals commitments that have become untenable. ## Technical documentation (Annex VII) URL: https://cra-reference.eu/en/cra/technical-documentation/ Description: The standard file structure, where the SBOM sits, the ten-year retention rule, and the completeness checklist to run before the pre-market review. Audience: legal Legal basis: Art. 31 — technical documentation · Annex VII — content of the technical documentation · Annex I — essential requirements Published 2026-08-19, updated 2026-08-19 The technical documentation is **the** deliverable of the CRA. It is what a market surveillance authority asks for, what a notified body examines, and what the EU declaration of conformity rests on. It is also the document that embodies the Legal–Cyber interface: the former structures and retains it, the latter produces most of its content. ### The standard structure #### 1. General description of the product Intended purpose, versions covered, photographs or illustrations showing external features, marking and internal configuration, description of software and hardware, information and instructions to the user (Annex II), installation instructions. #### 2. Design, development, production and vulnerability handling This is the substantive part. It comprises: - information on **design and development**, including architecture diagrams and a description of the components; - the **complete specification of the vulnerability handling processes** in place, expressly including: - the **software bill of materials (SBOM)**, - the **coordinated vulnerability disclosure policy**, - evidence of the provision of a **contact address** for reporting, - the **processes for distributing security updates**; - a description of the **production and control processes**. #### 3. Cybersecurity risk assessment The assessment carried out under Article 13, taken into account from the design stage and throughout the life cycle, with justification for the Annex I requirements retained and ruled out. #### 4. Determination of the support period The duration chosen **and its justification**: user expectations, nature of the product, market practice, support duration of embedded components. See [Support period](/en/cra/support-period/). #### 5. Standards applied The list of **harmonised standards** applied in whole or in part, whose references are published in the *Official Journal*, and — for the parts not covered — a description of the solutions adopted to meet the essential requirements. #### 6. Test reports Reports attesting the conformity of the product and of the vulnerability handling processes. #### 7. EU declaration of conformity A copy of the declaration drawn up under Annex V. #### 8. Where applicable, notified body documents Attestations, decisions and reports issued by the notified body involved. ### Where the SBOM sits At **point 2**, within the specification of the vulnerability handling processes. > **The sentence to get across on the Legal side.** The SBOM is not a side technical > deliverable: it is **a constituent part of the file that yields the CE marking**. No usable > SBOM → incomplete technical documentation → an ill-founded EU declaration of conformity → > a legally fragile CE marking → exposed sales. The Regulation does not require **publishing** the SBOM. It requires it to be in the file, held at the disposal of the authorities. Communicating it to customers is a commercial and contractual decision: see [SBOM distribution](/en/sbom/distribution/). ### Retention The technical documentation **and** the EU declaration of conformity are kept at the disposal of market surveillance authorities for **at least ten years after the product is placed on the market, or for the support period, whichever is longer**. That requires an archiving arrangement able to produce, ten years later, the exact version of the file corresponding to a given version of the product — SBOM included. See [Evidence retention](/en/legal/evidence-retention/). ### Completeness checklist - [ ] General description, versions covered unambiguously identified - [ ] Up-to-date architecture diagrams - [ ] **SBOM** for the version concerned, machine-readable, signed - [ ] **CVD policy** published, with evidence of publication - [ ] Evidence that the **contact address** exists and works - [ ] Description of the **update distribution process** - [ ] **Risk assessment**, dated and signed, with justification for requirements ruled out - [ ] **Support period** determined and justified - [ ] List of **harmonised standards** applied, deviations documented - [ ] **Test reports** covering the applicable requirements - [ ] Copy of the signed **EU declaration of conformity** - [ ] Where applicable, **notified body attestations** - [ ] **Ten-year archiving** policy configured and tested A simplified version of this file is provided for by the Commission for micro and small enterprises. ## The timeline URL: https://cra-reference.eu/en/cra/timeline/ Description: The three application dates, the transitional regime, the derogation that subjects the legacy portfolio to reporting, and the internal back-planning that follows. Audience: direction Legal basis: Art. 71 — entry into force and application · Art. 69 — transitional provisions Published 2026-08-19, updated 2026-08-19 ### The dates | Date | What applies | What it means for you | | --- | --- | --- | | **23 October 2024** | Adoption | — | | **20 November 2024** | Publication in the *OJEU* | Clocks start | | **10 December 2024** | **Entry into force** | The text is final; there will be no renegotiation | | **11 June 2026** | Chapter on **notification of conformity assessment bodies** | Notified bodies may be designated → **book a slot** for class II and Critical products | | **11 September 2026** | **Reporting obligations** (Art. 14), **including for products already on the market** | 24 h / 72 h / 14 d procedure operational, on-call rota, tested channel, ready templates, documented escalation rule | | **11 December 2027** | **Full application** | CE marking, technical documentation, essential requirements, SBOM, support period, user information | ### The transitional regime Two rules, the second a derogation from the first. **General rule.** Products placed on the market **before 11 December 2027** are subject to the Regulation only if they are subsequently **substantially modified**. **Derogation.** The **Article 14 reporting obligations** apply to **all** products within scope, **including those placed on the market before that date**. In other words: | | Legacy portfolio (before 11/12/2027) | New products (from 11/12/2027) | | --- | --- | --- | | CRA CE marking | No, unless substantially modified | **Yes** | | Technical documentation | No, unless substantially modified | **Yes** | | SBOM in the file | No, unless substantially modified | **Yes** | | Support period | No, unless substantially modified | **Yes** | | **24 h / 72 h / 14 d reporting** | **Yes, since 11/09/2026** | **Yes** | A security update fixing a vulnerability, with no other change, is not a substantial modification and therefore does not push a legacy product into the full regime. ### The internal back-planning Derived from the legal dates, to be approved by the committee and reviewed quarterly. #### Immediately — the costliest delays - **Contract notified bodies** for all class II and Critical products. It is the only item whose lead time is not yours to control. - **Arm the reporting procedure**, if that is not done: the deadline has passed. - **Classify the portfolio**: without it, you do not know which products need the first item. #### 24 months before full application Complete portfolio classification, assessment routes chosen, governance and RACI approved, licence policy settled. #### 18 months before SBOM automated across 100 % of build chains; centralisation platform in production; continuous monitoring active. #### 12 months before CVD policy published, `security.txt` online, first disclosure cycle handled, security advisories published in machine-readable form. #### 9 months before Complete technical documentation for two representative pilot products — one default, one important — to test the process before industrialising it. #### 6 months before Dry-run audit, third-party review, gap closure, timed reporting exercise. #### 3 months before EU declarations of conformity signed, CE marking affixed, Annex II notices shipped, ten-year archiving configured and tested by an actual retrieval. ### What can still move Three matters remain open and must be tracked: 1. the **publication and OJ citation of the harmonised standards** arising from request M/606, which conditions self-assessment of class I products; 2. the Commission's **delegated and implementing acts** — updating Annexes III and IV, SBOM format, mandatory certification of critical products; 3. the **designation of national authorities** and the practical arrangements of the single reporting platform. None of these three can move the Regulation's dates. They can, however, change the **route** to them, particularly for class I. ## Cyber path URL: https://cra-reference.eu/en/cyber/ Description: CRA obligations seen from Cybersecurity and DevSecOps: SBOM generation, CI/CD, secure by design, vulnerability management, coordinated disclosure, reporting, continuous monitoring. Audience: cyber Legal basis: Annex I, Parts I and II · Art. 13, 14 Published 2026-08-19, updated 2026-08-19 This section translates **Annex I** into technical capabilities to build, tools to deploy and evidence to produce. The text itself is explained in [Essential requirements](/en/cra/essential-requirements/). ### The eight capabilities to build Annex I, Part II sets out eight vulnerability handling obligations. Each maps to a technical capability, a tool and a verifiable artefact: | Requirement (Annex I, Part II) | Capability | Evidence produced | | --- | --- | --- | | 1. Identify components and vulnerabilities, machine-readable **SBOM** | Automated generation in CI | Signed CycloneDX SBOM, per build | | 2. Address and remediate **without delay**, security fixes separate from features | Vulnerability management, patch branches | Handling log, measured intervals | | 3. Regular security **testing and review** | SAST, DAST, SCA, fuzzing, penetration testing | Dated test reports | | 4. **Publish** information on fixed vulnerabilities | Security advisories in CSAF format | Published advisories | | 5. **Coordinated disclosure** policy | CVD channel, `security.txt` | Published policy, acknowledgements | | 6. Facilitate **information sharing**, contact address | PSIRT mailbox, public key | Live, tested address | | 7. **Secure distribution** of updates | Signing, authenticated channel, anti-rollback | Description of the mechanism | | 8. Distribution **without delay and free of charge**, with advisory messages | Publication process | Publication history | ### What Cyber must obtain from Legal The regulatory classification of each product (it drives the level of evidence expected), the licence policy, the committed support period, the decision on SBOM disclosure, and the decision to report during an incident. ### What Cyber must supply to Legal The signed SBOM, the risk assessment, the vulnerability handling log, the VEX statements, the test reports, the description of the update mechanism, and — within two hours of detection — the qualification of active exploitation. ### The nearest obligation It is not the SBOM, it is **reporting**. Since 11 September 2026, an actively exploited vulnerability triggers an early warning within **24 hours**, including for products placed on the market before that date. That requires an on-call rota, a tested channel and a documented escalation rule: see [24 h / 72 h / 14 d procedure](/en/cyber/24h-runbook/). > **The link to automate.** Moving from technical triage ("this vulnerability is exploited in > the wild") to the legal obligation ("you must report within 24 hours") must **not** depend on > the judgement of whoever is on call. It must be a tooled trigger, with escalation by default. ## 24 h / 72 h / 14 d procedure URL: https://cra-reference.eu/en/cyber/24h-runbook/ Description: The full reporting runbook: detection, qualification, crisis cell, submissions, informing users, on-call cover, exercises and a printable response card. Audience: cyber Legal basis: Art. 14 — reporting obligations · Art. 16 — single reporting platform Published 2026-08-19, updated 2026-08-19 The legal framework is in [Reporting to ENISA](/en/cra/enisa-reporting/), the legal decision in [Reporting duties](/en/legal/reporting-duties/). This page is the **runbook**. ### Prerequisites, to verify before any incident - [ ] Live named accounts on the **single reporting platform**, for every on-call person, tested within the last six months - [ ] **Templates** pre-filled: early warning, notification, final report - [ ] **List of Member States** where each product is made available — data to maintain, often missing - [ ] Operational **user notification channel**, with up-to-date contact details - [ ] **On-call rota**, technical **and** legal, with deputies - [ ] **Written delegation** of the decision to report - [ ] **Register** of decisions in place ### The run-through #### H+0 — Detection and timestamping An indication of active exploitation reaches a security function: a monitoring alert, a customer report, a CERT advisory, an upstream publication. **First action: timestamp receipt**, and open the register entry. That starting point is what will be examined in an inspection. #### H+0 to H+2 — Qualification The PSIRT establishes the facts: - does the vulnerability affect **your** products, which ones, in which versions? - is there **reliable evidence of exploitation** — consistent indicators, logs, analysis, a circumstantial report? - what is the **installed base** affected, and in which Member States? Deliverable: a **qualification sheet** passed to the legal decider. Target interval: **two hours**. #### H+2 to H+4 — Decision The legal decider rules: report, do not report, or report voluntarily. Where serious doubt persists, the default rule is to **report**. The decision and its reasoning are entered in the register, **whatever it is**. #### H+4 to H+20 — Drafting The PSIRT drafts the early warning from the template. Minimum content: product identification, Member States where it is made available, nature of the event, suspected malicious character where applicable. Legal review before sending. #### Before H+24 — Sending the early warning Submitted through the single reporting platform. **Keep the acknowledgement**: it is the proof that the deadline was met. Do not aim for H+23: aim for H+16, to absorb a technical failure on the platform. #### In parallel — Informing users Without undue delay, inform affected users of the vulnerability or incident and of the measures they can apply. That information **does not wait** for the final report. #### Before H+72 — Full notification General information on the product, nature of the vulnerability, corrective and mitigating measures taken and applicable by users. For an incident: assessment, severity, impact, available indicators of compromise. #### Then — Remediation Fix or workaround, testing, publication of the update, publication of the **security advisory** under Annex I, Part II, point 4. #### D+14 after the fix is available — Final report For a vulnerability: description, severity and impact, information on the threat actor where available, details of the fix. For a severe incident the deadline is **one month**: detailed description, likely root cause, measures applied and ongoing. #### Afterwards — Lessons learned Actual chronology against target chronology, friction points, updates to the reference and to the templates. ### Roles during the cell | Role | Responsibility | | --- | --- | | **Incident commander** | Keeps the chronology, arbitrates priorities, shields the team from interruptions | | **Analyst** | Establishes the technical facts, produces the qualification sheet | | **Legal lead** | Decides on reporting, approves wording, tracks the parallel regimes | | **Communications** | Prepares information for users and customers, with Legal | | **Product engineering** | Develops the fix or workaround | | **Leadership** | Kept informed, arbitrates commercially significant decisions | ### On-call cover A 24-hour deadline spans nights, weekends and public holidays. Concretely: - a **technical rota** and a **legal rota**, with deputies; - a single **on-call number**, known to support and to the teams; - a **maximum escalation delay** before switching to the deputy; - an up-to-date, tested **call list**. ### Exercises **Two a year at minimum.** One tabletop exercise for the decision, one full technical exercise running through to submission on the platform's test environment. What is measured: qualification interval, decision interval, submission interval, quality of the content produced, completeness of the register. The report is filed with the governance record; the gap between the interval achieved and 24 hours is a [metric](/en/organisation/metrics/) tracked at committee level. ### Response card To print and display. ``` ACTIVELY EXPLOITED VULNERABILITY — RESPONSE CARD 1. TIMESTAMP receipt. Open the register entry. 2. CALL the PSIRT on-call: [number] 3. QUALIFY within 2 h: your products? which versions? evidence of exploitation? which Member States? 4. PASS the sheet to the legal decider: [number] 5. DECIDE. In doubt → REPORT. 6. DRAFT the early warning (template: [location]) 7. SEND before H+16. Keep the acknowledgement. 8. INFORM affected users, without waiting. 9. H+72: full notification. 10. D+14 after the fix: final report. Do not forget: NIS 2 and the GDPR may apply to the same event. ``` ## Assessing an open source component URL: https://cra-reference.eu/en/cyber/assessing-components/ Description: Making the diligence required by Article 13(5) computable: the eighteen OpenSSF Scorecard checks, what they cover of the grid, what they do not tell you, and the S2C2F ingestion framework. Audience: cyber Legal basis: Art. 13(5) — due diligence on third-party components · Annex I, Part II, point 1 — component inventory Published 2026-08-20, updated 2026-08-20 ### The problem Article 13(5) requires **due diligence** when integrating third-party components, and that diligence must be **documented** to be enforceable. The [grid](/en/cra/open-source/integrating-oss/) that follows from it has nine criteria: known vulnerabilities, activity, governance, upstream security policy, historical responsiveness, licence, upstream SBOM, artefact signing, depth. Applied by hand it is impeccable across ten components and **unworkable across three thousand**. Which is the order of magnitude of a real dependency graph. Diligence that does not get done is not diligence. The grid therefore has to be made **computable**. ### OpenSSF Scorecard [Scorecard](https://scorecard.dev/) is an open tool from the [OpenSSF](https://openssf.org/) that runs a series of automated checks on a repository and produces, for each, a **score out of 10** together with a **risk level** that weights it into an aggregate score. Its contribution is not to replace judgement: it is to make **objective and repeatable** what was previously an impression. #### The eighteen checks | Family | Checks | | --- | --- | | **Security practices** | Vulnerabilities · Dependency-Update-Tool · Maintained · Security-Policy · License · CII-Best-Practices · CI-Tests · Fuzzing · SAST | | **Source risk** | Binary-Artifacts · Branch-Protection · Dangerous-Workflow · Code-Review · Contributors | | **Build risk** | Pinned-Dependencies · Token-Permissions · Packaging · Signed-Releases | #### What each of your criteria becomes | Your criterion | Matching Scorecard check | Automatable | | --- | --- | --- | | Known vulnerabilities | `Vulnerabilities` (via OSV) | **Yes** | | Project activity | `Maintained` | **Yes** | | Governance, lone maintainer | `Contributors` | **Partly** — it counts organisations, not fragility | | Upstream security policy | `Security-Policy` | **Yes** | | Historical responsiveness | — | **No** | | Licence | `License` (presence only) | **Partly** | | Upstream SBOM | — | **No** | | Artefact signing | `Signed-Releases` | **Yes** | | Dependency depth | — | **No**, that is the SBOM's job | Six of the nine become measurable, and Scorecard adds nine the grid did not have — branch protection, code review, token permissions, dependency pinning, dangerous workflow patterns, static analysis, tests, fuzzing, and non-auditable binary artefacts. #### What Scorecard does not tell you Essential, and worth writing into the policy to avoid a false sense of security: - **nothing about licence compatibility** with your context of use — see [Open source licensing](/en/licensing/); - **nothing about reachability**: a well-scored component may carry a vulnerability exploitable in your product, and a poorly scored one may be harmless; - **nothing about upstream support duration**, which nevertheless constrains your [support period](/en/cra/support-period/); - **nothing about code quality** or functional fit; - a high score **would have ruled out none** of the incidents documented in [Reference incidents](/en/cyber/incidents/) — those projects were active, reviewed and widely adopted. Scorecard measures **hygiene signals**, not the absence of malice. That is useful, bounded, and worth saying. ### S2C2F: the ingestion framework Where Scorecard scores a component, the **Secure Supply Chain Consumption Framework** ([S2C2F](https://github.com/ossf/s2c2f)), also stewarded by the OpenSSF, describes **how to consume** open source: a set of tool-agnostic practices, with a maturity model and a mapping to other supply chain specifications. Its guiding principle is the one you already apply without naming it: **do not consume directly from a public registry**, but go through controlled, inventoried and verified ingestion — see [Locking and updating dependencies](/en/cyber/dependency-locking/). Its value to you is twofold: it gives a **shared vocabulary** with your suppliers and customers, and it supplies a **maturity scale** usable in the [self-assessment](/en/self-assessment/). ### The threshold policy A score with no threshold is not a policy. What must be written down: | Situation | Proposed rule | | --- | --- | | New component, score ≥ 7 | Adopt with no further review | | New component, score 5 to 7 | Adoption possible, with **documented review** of the failing checks | | New component, score < 5 | **Refuse by default**, or a reasoned, dated waiver | | `Signed-Releases` failing on a critical component | Hash verification mandatory | | `Maintained` failing | Treat as an [abandoned component](/en/cra/open-source/integrating-oss/) | | Already-integrated component whose score **drops** | Alert, re-examine, no automatic removal | The last row is the one that gets forgotten: diligence is not an entry check, it is **monitoring**. A project can lose its maintainer three years after adoption. ### Where it runs | Moment | What happens | | --- | --- | | **Adoption request** for a component | Score computed, attached to the ticket, threshold applied | | **Build** | Threshold check on direct dependencies, warning below | | **Periodically** | Recomputation on critical components, alert on decline | | **Annual review** | Full re-examination, starting with components whose score has degraded | Continuous computation across the whole transitive graph is expensive and of limited use: restricting periodic monitoring to **direct** dependencies and **critical transitives** — those whose replacement would take months — captures most of the benefit. ### The evidence to keep | Artefact | Why | | --- | --- | | **Timestamped score** per component and version | Shows the state of knowledge **at the time of the decision** | | Completed **diligence grid**, with the non-automatable criteria | Covers what the tool does not measure | | Versioned **threshold policy** | Shows the decision follows a rule, not a preference | | **Waiver register**, with expiry | Shows exceptions are controlled | | **Re-examination log** | Shows diligence is continuous | It is that set, and not the score alone, that constitutes the documented diligence Article 13(5) expects. > **The trap to avoid.** A score archived without the decision it supported demonstrates > nothing. What an authority examines is not the number: it is that a written rule was applied, > and that departures from it were reasoned. ## CI/CD integration URL: https://cra-reference.eu/en/cyber/ci-cd/ Description: The eight steps of the target pipeline, the blocking rules, waiver handling, monorepos, and the cost in build time. Audience: cyber Legal basis: Annex I, Part II, points 1 and 3 Published 2026-08-19, updated 2026-08-19 ### The target pipeline ``` 1. build → produces the artefact 2. sbom-generate → build SBOM + analysed SBOM 3. sbom-validate → schema, quality score, build/analysed gap ↳ FAIL below threshold 4. sbom-sign → signature + provenance attestation 5. sbom-publish → send to the steering platform 6. policy-gate → vulnerabilities, licences, VEX ↳ FAIL or WARN depending on policy 7. attach → SBOM and signature attached to the artefact in the registry 8. archive → deposited in the evidence vault, indexed by hash ``` Steps 3 and 6 are **blocking**. The others are production steps: their failure must also fail the build, or artefacts without an SBOM will reach production. ### Example — GitHub Actions ```yaml jobs: build-and-attest: runs-on: ubuntu-latest permissions: contents: read id-token: write # keyless signing, no long-lived secret packages: write steps: - uses: actions/checkout@v4 - name: Build the artefact run: make build - name: Generate the SBOM (build) run: syft dir:. -o cyclonedx-json=sbom-build.cdx.json - name: Generate the SBOM (analysed) run: syft "$IMAGE" -o cyclonedx-json=sbom-analyzed.cdx.json - name: Validate quality and gap run: ./ci/validate-sbom.sh sbom-build.cdx.json sbom-analyzed.cdx.json - name: Sign run: cosign attest --predicate sbom-build.cdx.json --type cyclonedx "$IMAGE" - name: Publish to the platform run: ./ci/publish-sbom.sh sbom-build.cdx.json - name: Policy gate (vulnerabilities and licences) run: ./ci/policy-gate.sh sbom-build.cdx.json ``` The principle is the same on GitLab CI, Jenkins or Azure DevOps: the steps are identical, only the syntax changes. The `validate-sbom.sh`, `publish-sbom.sh` and `policy-gate.sh` scripts are **shared across all chains** and versioned in a central repository — that is what makes thresholds uniform. ### The blocking rules | Condition | Effect | Rationale | | --- | --- | --- | | SBOM not generated or schema invalid | **Fail** | Without an SBOM there is no possible compliance | | Quality score below threshold | **Fail** | An incomplete SBOM gives false assurance | | Build / analysed gap above threshold | **Fail** | Reveals undeclared code | | Critical exploitable vulnerability, no VEX | **Fail** | Annex I: no known exploitable vulnerability at placing on the market | | High-severity vulnerability, no VEX | Warning + ticket | Handled within the SLA | | Licence on the deny list for this context | **Fail** | Licence policy | | Licence on the review list | Warning + ticket | Legal review | | Signature or attestation missing | **Fail** | Without a signature, the SBOM is not evidence | ### Waivers A block with no escape hatch gets bypassed, usually by disabling the check. A **controlled waiver** is therefore needed: 1. requested through a ticket, with justification; 2. granted by a named person — the CISO for vulnerabilities, Legal for licences; 3. **time-limited**, with a mandatory expiry date; 4. recorded in a versioned file alongside the code, readable by the pipeline; 5. **automatically expired**: on the date, the block resumes. A permanent waiver is a change to the policy, and must be treated as one — not as an exception. ### Special cases **Monorepos.** One SBOM per **publishable artefact**, not one per repository. The difficulty is attributing shared dependencies correctly; native build-chain plugins handle this better than generic generators. **Matrix builds.** One artefact per OS or architecture combination, therefore one SBOM per combination. One variant's SBOM does not hold for the others. **Incremental builds and caching.** Caching can mask a dependency change. The SBOM must be regenerated for every publishable build, with no cache reuse. **Repackaged third-party artefacts.** If you republish an artefact you did not build, you must analyse it — the supplier's SBOM, where it exists, is a starting point to verify, not a document to adopt as is. ### The cost Generation adds anywhere from seconds to minutes per build, depending on artefact size and method. The usual levers: - produce the **analysed SBOM** only on publishable builds, not on every pull request; - **cache** the tools' vulnerability databases, not the results; - **parallelise** generation with the test suite; - reserve the **full cross-check** for release branches. None of these optimisations may reduce what is produced for a **shipped** artefact: that is the only case where compliance is at stake. ## Continuous monitoring URL: https://cra-reference.eu/en/cyber/continuous-monitoring/ Description: Replaying the SBOM daily against sources that move: architecture, EUVD and the ENISA reporting platform, upstream monitoring, metrics. Audience: cyber Legal basis: Annex I, Part II, points 1 and 2 Published 2026-08-19, updated 2026-08-19 ### The principle An SBOM is only valuable when **replayed continuously**. A component that is clean today is vulnerable tomorrow, **with no new build having taken place**. That is the difference between a CI check and a compliance arrangement. It is also why centralisation is mandatory: you do not re-evaluate thousands of files scattered across artefact registries every day. ### The architecture ``` Archived SBOMs (every shipped version) │ ▼ Steering platform ──── daily re-evaluation ────────┐ ▲ │ │ ▼ Vulnerability sources Targeted alerts EUVD · OSV · NVD · vendor advisories │ confirmed-exploitation catalogues ▼ upstream project advisories Team owning the product │ ▼ Triage → VEX → fix ``` The key word is **targeted**: the platform alerts only the teams whose products actually contain the component, in an affected version. Broadcasting produces noise and kills attention. ### Sources and their use | Source | Frequency | Use | | --- | --- | --- | | **[EUVD](https://euvd.enisa.europa.eu/)** — European vulnerability database, operated by ENISA | Daily | European reference, to be preferred in your reporting | | **[OSV](https://osv.dev/)** | Daily | `purl` correlation, high precision on packages | | **[NVD](https://nvd.nist.gov/)** | Daily | Broad coverage, to be filtered to avoid CPE false positives | | **Confirmed-exploitation catalogues** | Daily | Prioritisation trigger, strong indicator for qualification | | **Vendor and distribution advisories** | Daily | Avoids false positives caused by backports | | **Upstream project advisories** | By subscription | Often ahead of public databases | ### EUVD and the reporting platform Two distinct European arrangements, often confused: | | **EUVD** | **Single reporting platform (SRP)** | | --- | --- | --- | | Nature | A **vulnerability database** | A **reporting channel** | | Origin | Created under NIS 2, operated by ENISA | Created by the CRA, operated by ENISA | | Direction of flow | You **consume** it | You **submit** to it | | Use | Continuous monitoring | 24 h early warning, 72 h notification, final report | The link between them: after processing by the coordinating CSIRT and ENISA, your reports feed the European vulnerability knowledge ecosystem — of which the EUVD is the shop window. That is what "feeding the EUVD through the reporting platform" means. ### Monitoring upstream Distinct from vulnerability monitoring, and just as necessary: - **subscribing to security advisories** of the projects you depend on critically; - **tracking activity**: date of last commit, release frequency, number of active maintainers; - **detecting abandoned projects**, and triggering the strategy decided in [Integrating open source](/en/cra/open-source/integrating-oss/); - **alerting on maintainer or licence changes** — both are risk signals, one security, one legal. This monitoring covers a limited set of components: those critical to your products. Attempting to watch the entire transitive graph produces unusable noise. ### What must be automatic | Automatic | Manual | | --- | --- | | Daily re-evaluation of the estate | Exploitability analysis | | SBOM / source correlation | Drafting the VEX | | Routing the alert to the owning team | Priority arbitration in case of conflict | | Opening a ticket with the context | Reporting decision | | SLA deadline reminders | Customer communication | | Detecting a component reaching end of maintenance | Choosing the replacement strategy | The principle: **the machine finds and routes, the human decides**. Anything left to human initiative in the left-hand column eventually stops happening. ### Metrics - **Detection interval**: time between a vulnerability being published and your alert. - **Triage interval**: time between alert and handling decision. - **Remediation interval** by severity level. - **Coverage**: share of shipped products whose SBOM is actually monitored. - **Average age** of open vulnerabilities. - **Ratio of actionable alerts** to raw alerts — see [False positives](/en/cyber/false-positives/). **Coverage** is the first to look at: monitoring 40 % of the portfolio perfectly is not a compliance arrangement, it is a pilot. ## Locking and updating dependencies URL: https://cra-reference.eu/en/cyber/dependency-locking/ Description: The central tension: freeze so you can rebuild identically for ten years, and update so there is no known exploitable vulnerability. Lock files, hash pinning, automated updates and quarantine. Audience: cyber Legal basis: Annex I, Part I — no known exploitable vulnerabilities · Annex I, Part II, point 2 — remediate without delay · Art. 13(8) — support period Published 2026-08-20, updated 2026-08-20 ### Two obligations pulling in opposite directions | Requirement | What it demands | What it pushes you to do | | --- | --- | --- | | **Annex I, Part I** — no known exploitable vulnerability at placing on the market | Components must be **current** | Update often | | **Annex I, Part II, point 2** — remediate without delay | The same, continuously | Update fast | | **Art. 13(8)** — five-to-ten-year support period | Be able to **rebuild identically** a version shipped eight years ago | Freeze everything | The Regulation therefore demands freshness and reproducibility at the same time. The answer is not a soft compromise: it is to **freeze precisely, and update deliberately**. ### Freezing: the lock file A manifest declares **ranges** ("version 5 or above"); a lock file records the **exact resolution**, transitive dependencies included, with hashes. Without one, two builds of the same code on two dates produce two different artefacts. The consequences are directly regulatory: - the **SBOM** no longer reliably describes what was shipped; - **rebuilding** an old version becomes impossible, and so does the support period; - a **silent substitution** of a dependency goes unseen. **The rule**: the lock file is **committed**, it is part of the source, and a publishable build fails if resolution departs from it. That is what the strict install modes of the various ecosystems guarantee, by refusing to update the lock file on the fly. ### Freeze what is not an application dependency too This is the most common blind spot: libraries get locked, and everything else in the chain is left mutable. | Element | Mutable reference — to avoid | Immutable reference | | --- | --- | --- | | Reused CI action or step | Version tag | **Full commit hash** | | Container base image | `:latest`, or a version tag | **Content digest** | | Remote script run by the chain | URL pointing at the main branch | Frozen URL **+ hash verification** | | Tool installed on the fly | "latest version" | Exact version, hash verified | > **Why this is decisive.** A tag can be **repointed** to another commit without any of your > references changing. That is exactly the attack that exposed the secrets of thousands of > chains in March 2025 — see [Reference incidents](/en/cyber/incidents/). A hash cannot be > repointed. ### Updating: deliberately, not automatically Freezing without updating produces the opposite of the intended result: a product that is reproducible and vulnerable. Update bots — Dependabot, Renovate — are the standard tooling. They open pull requests when a version is published, with release notes and, depending on configuration, the vulnerability fixed. **But an update bot is itself a vector.** An automatically merged version bump introduces third-party code straight into production. Three safeguards: | Safeguard | Effect | | --- | --- | | **Quarantine delay** | No version published less than N days ago is proposed. Malicious packages are usually pulled within hours or days | | **Restricted auto-merge** | Limited to security fixes on allow-listed components, and never for a major version change | | **Human review of sensitive dependencies** | An explicit list of components whose every bump goes through a person | ### Controlled ingestion: cache or decision point? Routing dependencies through an internal mirror is widespread good practice, but two arrangements are often conflated: | | **Cache or mirror** | **Decision point at ingestion** | | --- | --- | --- | | Function | Serves faster, survives upstream outages | **Allows, denies, quarantines** | | Timing | After download | **Before entry into the organisation** | | Faced with a malicious package | It **propagates** it, and keeps it | It **blocks** it | A cache accelerates; it does not govern. If the goal is to stop a typosquatted or freshly published package from entering, the decision must be applied **before** ingestion, with a policy that lives beside the code rather than in a console. Often overlooked: configuration alone is not enough. As long as a workstation can reach the public registry directly, bypassing is trivial. **Egress filtering** is what makes the rule effective. ### Reproducibility, a long-term requirement On a product covered by a ten-year support period, you must be able to rebuild in eight years. That means retaining, alongside the code: - the **lock file** of the shipped version; - the **hashes** of base images and build tools; - a **copy of upstream artefacts** — a public registry is not an archival service, and packages do disappear; - the **chain definition** as it stood. The **[reproducible builds](https://reproducible-builds.org/)** effort takes the logic to its conclusion: two builds of the same code produce bit-for-bit identical artefacts. It is demanding, and it is the only proof a third party can genuinely verify. The overlap is worth stating: what the Regulation requires you to retain for the support period, and what the **GPL** requires you to supply as "corresponding source", are the same set of artefacts. See [Desktop or command-line application](/en/licensing/scenarios/desktop-cli/). ### Checklist - [ ] **Committed** lock file for each ecosystem - [ ] Publishable build in **strict mode**, failing if resolution departs from the lock file - [ ] CI actions and steps pinned by **commit hash** - [ ] Base images pinned by **content digest** - [ ] Update bot active, with a **quarantine delay** - [ ] Auto-merge limited to security fixes on allow-listed components - [ ] List of dependencies requiring **mandatory human review** - [ ] Dependencies served by an **internal mirror**, with egress filtering - [ ] Upstream artefacts **archived** for the duration of the support period - [ ] Annual test: **rebuild** a version shipped more than two years ago ## Coordinated disclosure policy URL: https://cra-reference.eu/en/cyber/disclosure-policy/ Description: What a CVD policy contains, security.txt and RFC 9116, the safe harbour commitment, ISO/IEC 29147 and 30111, the French legal route, and whether to become a CNA. Audience: cyber Legal basis: Annex I, Part II, point 5 — CVD policy · Annex I, Part II, point 6 — contact address · Annex II, point 2 — single point of contact Published 2026-08-19, updated 2026-08-19 ### The obligation Annex I, Part II, point 5 requires **putting in place and enforcing** a coordinated vulnerability disclosure policy. Both verbs matter: a policy that is published but whose reports go unanswered does not satisfy the requirement. Point 6 adds the provision of a **contact address**, and Annex II requires a **single point of contact** in the information to the user, **with an indication of where it is located**. ### What a CVD policy contains | Section | Content | | --- | --- | | **Scope** | Products, versions and domains covered — **and what is not** | | **Out of scope** | Third-party systems, customer test environments, defect types not handled | | **Reporting channel** | Dedicated address, form, public encryption key | | **Acknowledgement** | Committed interval — three working days is common practice | | **Response interval** | Time to a first qualified assessment | | **Disclosure interval** | The agreed window before publication — 90 days is the reference practice, adjustable | | **Safe harbour** | For good-faith research within scope | | **Recognition** | Credit in the advisory, acknowledgements page | | **Reward** | Where applicable, scale and conditions | | **Internal process** | What happens after receipt, and the escalation point | | **Languages accepted** | At minimum French and English | ### The safe harbour commitment This is the most sensitive clause, and the one that determines whether researchers will report anything to you at all. It commits the company not to bring civil or criminal action against a person who, in good faith: - stays within the **announced scope**; - **does not exfiltrate** data beyond what is strictly necessary to demonstrate the issue; - **does not degrade** the availability of the service; - **does not disclose** before the agreed window; - **reports** through the stated channel. It must be **approved by Legal** before publication, and drafted precisely: a vague clause is useless to the researcher and dangerous for the company. ### The `security.txt` file Standard **[RFC 9116](https://www.rfc-editor.org/rfc/rfc9116.html)**, published at `/.well-known/security.txt`: ``` Contact: mailto:psirt@example.org Expires: 2027-08-19T00:00:00Z Encryption: https://example.org/pgp-key.txt Preferred-Languages: fr, en Policy: https://example.org/en/security/ Acknowledgments: https://example.org/en/security/#acknowledgements Canonical: https://example.org/.well-known/security.txt ``` > **The trap.** The `Expires` field must stay **in the future**. An expired `security.txt` is a > visible signal of neglect, and it is routinely picked up by external assessment tools. Its > update must be **automated**, not entrusted to a calendar reminder. ### Reference standards - **ISO/IEC 29147** — vulnerability disclosure: how to receive and publish. - **ISO/IEC 30111** — vulnerability handling: how to investigate and fix. Referring to them explicitly in the policy strengthens its credibility and helps with customer questionnaires. ### The French route **Article L. 2321-4 of the French defence code** allows a person acting in good faith to pass information about a vulnerability to ANSSI, which preserves the confidentiality of their identity. It is a route open to researchers independently of your policy. Practical consequence: **a researcher may go through ANSSI rather than through you**. Better that your channel be the simpler and more reliable of the two. ### The internal process | Step | Target interval | Owner | | --- | --- | --- | | Acknowledgement | 3 working days | PSIRT | | Initial qualification | 7 days | PSIRT + engineering | | Qualified response to the researcher | 10 days | PSIRT | | Fix or reasoned position | Per the [SLAs](/en/cyber/vulnerability-management/) | Engineering | | Coordinating the publication date | Before publication | PSIRT + researcher | | Publishing the advisory | When the fix is available | PSIRT | | Acknowledgement of the researcher | At publication | PSIRT | Every report received is entered in a **register**, whether or not it is accepted. That register is the evidence that the policy is "enforced" and not merely "put in place". ### Should you become a CVE Numbering Authority? | For | Against | | --- | --- | | Control over the publication schedule | A commitment to quality and responsiveness | | Consistent identifiers across your products | A permanent process load | | Credibility with researchers and customers | Exposure: your publications become countable | | Easier correlation for your customers | Requires a genuinely staffed PSIRT | The question is only usefully asked once the CVD process is running and the volume of reports is significant. Asking it too early diverts attention from the real issue, which is answering reports within the intervals you announced. ### The public page Your policy is published at [Vulnerability disclosure](/en/security/). It must be accessible **without authentication**, at a stable URL, and referenced from `security.txt` and from each product's documentation. ## Managing false positives URL: https://cra-reference.eu/en/cyber/false-positives/ Description: The compliance risk of excess noise: root causes, remedies, a dated and reasoned suppression policy, and the metric to track. Audience: cyber Published 2026-08-19, updated 2026-08-19 ### The problem, stated plainly A raw scan of a typical application image reports **hundreds of alerts**. A large majority are not exploitable in your context. Untreated, there are two outcomes, both bad: 1. the team tries to handle everything, burns out, and the **real** vulnerabilities drown; 2. the team disables the checks, and the arrangement exists only on paper. > **This is a compliance risk, not merely a comfort problem.** An arrangement producing so much > noise that nobody reads it does not demonstrate the "without delay" handling Annex I requires. > Signal quality is a requirement, not a refinement. ### Root causes | Cause | Mechanism | Frequency | | --- | --- | --- | | **Imprecise matching** | CPE correlation: homonyms, spellings, missing entries | Very high | | **Unreachable vulnerable code** | The component is present, the vulnerable function is never called | High | | **Distribution backport** | The fix is applied without changing the upstream version number | High on container images | | **Test dependencies counted** | Dependencies never shipped appear in the product SBOM | High | | **Unused base image layers** | Packages present in the image but never executed | High | | **Disputed or low-quality entries** | An identifier published then disputed by the vendor | Moderate | | **Duplicate components** | Two versions of one library, only one loaded | Moderate | ### Remedies, by effectiveness **1. Prefer per-ecosystem identifiers.** Correlating by `purl` against a per-ecosystem database rather than by CPE against a general one cuts noise massively. It is the highest-return lever — see [Identifiers](/en/sbom/identifiers/). **2. Populate the distribution.** For system packages, stating the distribution and its version lets the tool apply the right fix database and ignore already-backported vulnerabilities. **3. Exclude test dependencies from the shipped product's SBOM.** They do not belong there — see [Quality and completeness](/en/sbom/quality/). **4. Reachability analysis.** Determine whether the vulnerable function is called from your entry points. Expensive to set up, very effective thereafter. **5. Systematic VEX.** Every discarded alert is documented by a [VEX](/en/sbom/vex/) with a standardised justification. The alert leaves the dashboards **without leaving the record**. **6. Shrink the surface.** Minimal base images, removal of unnecessary packages, controlled static compilation. Fewer components means fewer alerts — and less real risk. **7. Prioritise rather than filter.** Use exploitation probability and confirmed-exploitation catalogues to order, not to remove. ### Suppression policy An alert may be set aside. It may not be **erased**. | Permitted | Prohibited | | --- | --- | | VEX `not_affected` with a standardised justification | Silent suppression | | **Dated**, reasoned muting with a named owner | Permanent muting | | Documented exclusion of a file path | Globally disabling a check | | Traced, contextualised severity reduction | Editing the vulnerability database by hand | Every mute carries an **expiry date**. At expiry the alert reappears and the decision is re-examined. That is what separates an engineering decision from a workaround. ### The box for Legal > Deciding not to fix is **not** a breach, provided the decision is **reasoned, documented and > traced**. Annex I requires vulnerabilities to be addressed without delay; it does not require > fixing every identifier a scanner reports. > > A VEX is the **legal form** of that decision. Without it, a discarded vulnerability is > indistinguishable from an ignored one — and that is exactly the distinction a surveillance > authority will seek to establish. ### The metric **Ratio of actionable alerts to raw alerts**, measured per product and tracked over time. ``` ratio = alerts that led to an action (fix, workaround, reasoned VEX) ÷ raw alerts reported by the tools ``` A ratio of a few per cent signals a tooling problem, not excessive rigour. A steadily improving ratio signals a maturing arrangement. It is one of the rare metrics that measures the **quality** of the arrangement rather than its volume. It appears in the dashboard described in [Metrics](/en/organisation/metrics/). ## Generating SBOMs URL: https://cra-reference.eu/en/cyber/generating-sboms/ Description: The five generation methods by context, the tool families, the choice matrix by language, and why the toolchain must be pinned per product family. Audience: cyber Legal basis: Annex I, Part II, point 1 Published 2026-08-19, updated 2026-08-19 ### The principle The SBOM is produced **as close to the artefact as possible**, in the pipeline that builds it, never by hand afterwards. An SBOM written by a human is wrong the day it is written and obsolete the next. ### The five methods | Method | What it sees | Blind spot | | --- | --- | --- | | **From dependency manifests** | Declared and resolved dependencies | Whatever is not declared: vendored code, static linking | | **From the container image** | Base image system packages **and** the application | Anything compiled into a binary | | **From the compiled binary** | Statically linked libraries | Accuracy varies with the metadata the compiler leaves | | **From the file system or firmware** | The real content of an embedded image | Expensive, specialised tooling | | **From execution** | What is actually loaded in memory | Only sees exercised paths | These methods are not mutually exclusive: they **combine**. A mature pipeline produces a [build SBOM](/en/sbom/types/) from manifests and an analysed SBOM from the artefact, then compares the two. ### The tool families Detailed profiles are in [Generators](/en/tooling/generators/). In summary: | Family | Role | Representatives | | --- | --- | --- | | **Generic generators** | Produce the inventory, multi-ecosystem | Syft, cdxgen | | **All-in-one scanners** | Generate and detect vulnerabilities in one pass | Trivy | | **Detection engines** | Consume an SBOM and correlate it | Grype, osv-scanner | | **Licence-oriented tools** | Detect licences by analysing file content | ScanCode, OSS Review Toolkit | | **Native build-chain plugins** | Produce the inventory from the real resolution graph | CycloneDX Maven/Gradle, `npm sbom`, .NET, Rust, Go equivalents | ### Choice matrix by context | Context | Recommendation | Why | | --- | --- | --- | | Java, .NET, Node, Python, Ruby applications | **Native build-chain plugin**, complemented by a generic generator on the artefact | The plugin sees the real resolution graph, with version arbitration | | Go or Rust applications | Generic generator on the **binary** | Build metadata is present there | | C / C++ applications | Generator on the binary **and** on the build system | Static linking makes manifests insufficient | | Container image | Generator on the full **image** | Captures the base image | | Embedded firmware | Specialised tooling, **and** an SBOM requirement on the platform supplier | Few general tools cover this case | | Multi-artefact monorepo | One SBOM **per publishable artefact**, not one for the repository | An SBOM describes a shipped artefact | ### The floating-toolchain trap Two different tools produce two different SBOMs for the same artefact: detection scope, granularity, identifier normalisation and handling of test dependencies all vary. That is normal, and it is only a problem if the toolchain changes without your knowing. > **Rule.** Pin the toolchain **per product family**, document the choice, version the > configuration, and treat any tool change or major version bump as an event: recompute a > baseline, compare, write an explanatory note. Without that discipline, comparability over time is lost and differences between two versions become uninterpretable — which drains the arrangement of its value for the technical documentation. ### What must come out of the pipeline For every publishable artefact: 1. a **build SBOM** in the pivot format, at a fixed version; 2. an **analysed SBOM** as a cross-check; 3. a **quality score**, with the build failing below the threshold; 4. a **signature** and a provenance attestation; 5. **publication** to the steering platform; 6. **archiving** with indexing by hash. The detail is in [CI/CD integration](/en/cyber/ci-cd/). ### What to document One sheet per product family: tools used and versions, exact commands, output format and version, scope covered, deliberate exclusions and their reasons, quality thresholds, owner. That sheet is part of the technical documentation, because it explains **how** the SBOM was produced — information Annex VII expects under the process heading. ## Reference incidents URL: https://cra-reference.eu/en/cyber/incidents/ Description: Fourteen documented, dated compromises, from a vendor update channel to a hijacked CI action: what happened, what would have limited the damage, and the requirement each one illuminates. Audience: transverse Legal basis: Annex I, Part I — limiting attack surfaces, integrity · Art. 13(5) — due diligence on third-party components Published 2026-08-20, updated 2026-08-20 [Supply chain risk](/en/cyber/supply-chain-risk/) classifies the mechanisms. This page documents **what actually happened**. The distinction is not cosmetic. A typology can be argued with; a dated compromise, with its vendor, its vulnerability identifier and its blast radius, cannot. It is the argument that unlocks a budget and makes an engineering constraint acceptable. > **A reading caveat.** Each entry points to a countermeasure. Do not conclude that it would > have prevented the attack: in several cases **nothing recommended here would have been enough**. > The column names what would have **shortened detection or reduced the blast radius**, which > is already the essential part. ### The series | Date | Incident | Mechanism | What would have limited it | | --- | --- | --- | --- | | Jun 2017 | **M.E.Doc / NotPetya** | A vendor's update channel compromised; propagation through a legitimate update | Segmentation, least privilege on the update account | | Sep 2017 | **CCleaner** | The vendor's build environment compromised; the malicious binary carried a **legitimate signature** | Provenance attestations, isolation of the build service | | Nov 2018 | **event-stream** (npm) | The maintainer hands the project to a stranger, who adds a malicious dependency targeting a cryptocurrency wallet | Watching for **maintainer changes**, review of new dependencies | | Dec 2020 | **SolarWinds Orion** (SUNBURST) | Build system compromised; a backdoor inserted between verified source and distributed artefact | Reproducible builds, provenance signed by the build service | | Feb 2021 | **Dependency confusion** | Research showing a public package outranks an internal one of the same name, at several major vendors | Reserved namespaces, explicit resolution priority, internal registry | | Apr 2021 | **Codecov** | The coverage upload script is modified for months and **exfiltrates the environment variables** of every CI chain that runs it | Script hash verification, least-privilege tokens, egress filtering | | Jul 2021 | **Kaseya VSA** | Remote administration software used as a distribution vector for ransomware towards end customers | Segmentation, control of administration channels | | Oct 2021 | **ua-parser-js** (npm) | Maintainer account hijacked; malicious versions published on a very widely used package | Strong authentication on publishing accounts, quarantine on new versions | | Dec 2021 | **Log4Shell** (CVE-2021-44228) | Not a supply chain attack but a **critical vulnerability in a ubiquitous component**: the question becomes "where is it in your estate?" | **Centralised SBOM**: an answer in minutes rather than weeks | | Mar 2022 | **node-ipc** | Destructive code introduced **deliberately by the maintainer**, for political reasons | Version locking, review before version bumps | | Mar 2023 | **3CX** | Compromised installer — and a **cascading** compromise: the vendor had itself been hit through a trojanised third-party product | Diligence on suppliers' suppliers, signature verification | | Mar 2024 | **xz / liblzma** (CVE-2024-3094) | **Social engineering over more than two years** to obtain maintainership, then a backdoor targeting the SSH service. CVSS 10 | Very little — see below | | Jun 2024 | **polyfill.io** | The domain serving a script to hundreds of thousands of sites is **sold**, then serves malicious code | Self-hosting assets, subresource integrity checks | | Mar 2025 | **tj-actions/changed-files** (CVE-2025-30066) | The **version tags** of a CI action are repointed to a malicious commit that writes secrets into the logs | **Pinning by hash** rather than by tag, non-public logs | ### Five incidents that teach something precise #### SolarWinds — a signature says nothing about content The backdoor was inserted **inside the build system**, between intact source and a distributed artefact. The binary shipped was authentically signed by the vendor: any client-side signature check passed. **What it changes for you.** Signing an artefact proves **who** published it, not **what it contains nor how it was produced**. That is exactly the gap that [provenance attestations](/en/sbom/signing/) close: they describe the repository, the revision, the chain and the build parameters. A build service isolated so that user-defined steps cannot reach the signing material is the structural answer. #### Codecov — CI is a target, not a neutral tool A script downloaded and executed by thousands of integration chains was quietly modified, and for months exfiltrated the contents of environment variables — that is, the tokens, keys and credentials found there. **What it changes for you.** Everything the build chain executes is part of the product. See [Securing the build chain](/en/cyber/securing-the-build-chain/). #### xz — the incident your countermeasures do not catch Two years of legitimate contributions to earn the maintainer's trust, then a backdoor concealed in the release archives — absent from the source repository — targeting SSH authentication. Found by accident, by an engineer puzzled by abnormal CPU usage. **What it changes for you.** No diligence grid would have ruled this project out: it was active, maintained, widely audited and present in every distribution. Two lessons only, and they are modest: - **the divergence between repository and published archive** was the signal; building from source, or verifying that the archive matches the repository, would have exposed it; - **a lone maintainer under pressure** is a risk criterion, and it appears in your [assessment grid](/en/cyber/assessing-components/). It is worth saying plainly that an arrangement has limits. Claiming otherwise discredits the rest of it. #### polyfill.io — the dependency nobody counts A script loaded from a third-party domain appears in no manifest and in no SBOM generated from a package manager. Selling the domain was enough to turn an invisible dependency into a vector. **What it changes for you.** Resources loaded at runtime from a third party are dependencies in their own right, to be inventoried and justified like any other. This site loads exactly one — the audience measurement served by its own host — and a build check fails if a second appears: the useful discipline is not promising zero, but being able to enumerate. It is one of the blind spots of the [web frontend](/en/licensing/scenarios/web-frontend/). #### tj-actions — a tag is not a hash The attacker did not need to publish a version: they **repointed the existing tags** to a malicious commit. Every chain referencing the action by tag executed the new code on its next build, and wrote its secrets into logs that are often public. **What it changes for you.** Pinning by hash is not a refinement: it is the only immutable reference. See [Locking and updating dependencies](/en/cyber/dependency-locking/). ### What the series shows **The point of compromise moves upstream.** The older cases targeted the distribution channel; the recent ones target the **build system**, **publishing accounts** and **CI tooling**. The further upstream it goes, the more worthless the final product's signature becomes, since it is applied after the compromise. **Detection time matters more than prevention.** None of the fourteen was prevented by an automated control. Several were found by chance. What separates organisations is how long it took them to answer "**are you affected?**" — from minutes to weeks, depending on whether they had a centralised inventory. **The link to the Regulation is direct.** Article 13(5) requires **documented diligence** on third-party components; Annex I, Part I requires **limiting attack surfaces** and **protecting integrity**. These fourteen cases describe precisely which surfaces need reducing. > **This list is a selection, not an inventory.** It keeps publicly documented, well-established > incidents chosen to cover each mechanism in the typology. The most recent campaigns have > industrialised some of these patterns — notably **self-replicating worms** on package > registries, which abuse stolen publishing tokens to spread from package to package with no > human involvement. Keeping this page current is part of the > [regulatory watch](/en/updates/) process. ## Secure by design URL: https://cra-reference.eu/en/cyber/secure-by-design/ Description: Turning Annex I Part I into verifiable requirements: threat modelling, risk assessment, test plan, and the frameworks to use while harmonised standards are pending. Audience: cyber Legal basis: Annex I, Part I · Art. 13(2) and (3) — risk assessment Published 2026-08-19, updated 2026-08-19 The content of Annex I, Part I is detailed in [Product security](/en/cra/essential-requirements/product-security/). This page describes **how to produce it**. ### The risk assessment: the pivot document It is required on two counts: it conditions the application of the essential requirements "as appropriate to the product", and it is an item of the [technical documentation](/en/cra/technical-documentation/). **What it must contain:** | Section | Content | | --- | --- | | Scope | Product, versions, components, interfaces | | Intended security environment | Deployment assumptions — carried over verbatim into the user notice | | Assets to protect | Data, functions, secrets, availability | | Threat sources and scenarios | Who, with what capability, along which path | | Assessment | Likelihood and impact, on a defined and written scale | | Treatment | The measure adopted for each risk, or a reasoned acceptance | | **Annex I coverage** | Requirement by requirement: applicable or not, and why | | Residual risks | Accepted, by whom, with what information to the user | That last row is what feeds Annex II point 5 — known circumstances that may lead to a risk. **When to revise it:** at every major architecture change, at every added exposed feature, at every change in the assumed deployment environment, and at minimum annually. ### Threat modelling The risk assessment is a document; threat modelling is the **workshop** that produces it. Run it at design time, not afterwards. A practical run, two to four hours per scope: 1. draw the **data flow** and set the trust boundaries; 2. for each boundary, enumerate threats against a stable grid — spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege; 3. keep the credible scenarios, discard the others **with the reason**; 4. attach a countermeasure or an acceptance to each scenario kept; 5. derive **test criteria** from them. The deliverable is a diagram and a list. It is filed with the technical documentation and feeds the traceability matrix. ### The test plan Annex I, Part II, point 3 requires **effective and regular security tests and reviews**. "Regular" implies a written cadence that is actually kept. | Test type | What it covers | Typical cadence | | --- | --- | --- | | **Composition analysis** (SCA) | Third-party component vulnerabilities | Every build | | **Static analysis** (SAST) | Defects in the code you write | Every build | | **Secret scanning** | Keys and credentials in code | Every build | | **Configuration analysis** | Hardening, infrastructure as code | Every build | | **Dynamic analysis** (DAST) | Behaviour of the exposed application | Per version | | **Fuzzing** | Robustness of input parsers | Continuous on exposed components | | **Security code review** | Sensitive functions: authentication, cryptography, input parsing | Per sensitive change | | **Penetration testing** | Whole-system view, chaining of defects | Annual, and before major releases | Each test must produce a **dated, retained report**: that is the evidence for the requirement. A test run without an archived report does not exist for an auditor. ### Hardening by default The secure-default-configuration requirement translates into a written and automatically tested **hardening baseline**: - no default credentials shared across units; - no service or port open without functional need; - debug interfaces absent from production builds; - encryption enabled by default on flows and stores; - logging enabled, with a documented way to disable it; - a tested **reset to original state** procedure. An automated install test from the factory state is the most effective control: it verifies what the customer actually receives, rather than what the documentation claims. ### Frameworks to use Pending harmonised standards being cited in the *Official Journal*: | Framework | What it covers | | --- | --- | | **IEC 62443-4-1** | Secure development process | | **IEC 62443-4-2** | Technical component requirements | | **[NIST SP 800-218](https://csrc.nist.gov/pubs/sp/800/218/final)** (SSDF) | Secure development practices | | **[ETSI EN 303 645](https://www.etsi.org/deliver/etsi_en/303600_303699/303645/)** | Consumer IoT | | **EN 18031-1/-2/-3** | Radio equipment — reusable work | | **ISO/IEC 27001** | Information security management system | | **ISO/IEC 29147** and **30111** | Vulnerability disclosure and handling | | **ISO/IEC 18974** | OpenChain — open source security assurance | > **Important caveat.** Applying these frameworks confers **no presumption of conformity** under > the Regulation until they are harmonised standards cited in the OJ. They make the > demonstration easier and supply reusable evidence; they do not replace the demonstration. ## Secure updates URL: https://cra-reference.eu/en/cyber/secure-updates/ Description: Authenticated channel, signing, rollback protection, automatic updates with opt-out, separating fixes, free of charge, and the embedded case. Audience: cyber Legal basis: Annex I, Part I — automatic updates, integrity · Annex I, Part II, points 2, 7 and 8 · Annex II, point 9 — information on automatic updates Published 2026-08-19, updated 2026-08-19 ### What the Regulation requires Four requirements, split across the two parts of Annex I: 1. vulnerabilities can be addressed through **security updates**, including, where appropriate, **automatic updates enabled by default**, with a clear **opt-out mechanism** and notification of available updates; 2. security fixes are provided **separately** from functional updates where technically feasible; 3. **secure distribution mechanisms** ensure fixes reach users unaltered; 4. fixes are distributed **without delay** and **free of charge**, accompanied by **advisory messages** telling users what to do. ### The technical mechanism | Property | Implementation | | --- | --- | | **Authenticity** | Update package signed, verified by the product before applying | | **Integrity** | Hash verified; clean failure if altered | | **Channel confidentiality** | Encrypted transport and server authentication | | **Rollback protection** | Refuse to install an earlier version, except through an explicit restore procedure | | **Resilience** | Recovery after interruption; the product remains functional if the update fails | | **Verifiability** | The user can check the installed version and the history | | **Root of trust** | Verification key protected, rotation procedure designed and tested | **Key rotation** is the most frequently forgotten point. Over a ten-year support period the signing key will have to change. If the mechanism does not allow for it from the design stage, the product becomes unmaintainable. ### Automatic updates Enabled by default **where appropriate**. That qualifier calls for a documented decision, based on the risk assessment: industrial equipment where an unexpected restart would halt a production line is in a different position from a consumer application. In every case: - **inform the user** that the mechanism exists and what it does; - provide a clear **way to disable it**, with information about the consequences; - provide the ability to **defer** an update; - **notify** available updates where they are not automatic. These elements must appear in the user notice — see [User information](/en/legal/user-information/). ### Separating fixes This is the requirement with the greatest engineering consequence. Providing a security fix **without** functional change requires: - **maintenance branches** per supported version line; - the ability to **backport** the fix to those branches; - a **numbering scheme** that clearly marks a security fix; - **preserved build environments** for old branches — over ten years, that means archiving tools, not just code; - **regression tests** runnable on those branches. A continuous-delivery release model with no maintenance branches cannot satisfy this requirement: the customer must then accept functional changes to get the fix. The architectural decision must be taken **before** the first incident. ### Free of charge Security fixes are **free** during the support period, except where otherwise agreed for tailor-made products between businesses. A commercial consequence to work through: a maintenance contract cannot condition access to security fixes. See [Turning the support period into commitments](/en/legal/support-commitments/). ### Advisory messages Every release is accompanied by a message telling the user **what to do**. Minimum content: the vulnerabilities fixed, the products and versions concerned, severity, urgency of application, and any manual steps required. Publishing these in a **machine-readable** format — CSAF 2.0 — lets your customers process them automatically. It is not expressly required, but it is what large accounts will ask for, and it reduces your own support load. ### Embedded and constrained connectivity Specific constraints, to be handled at design time: - **size** of the update package and available bandwidth; - **power**: an update interrupted by a power cut must not brick the device — hence dual-partition schemes; - **no user interface**: how do you inform and collect an opt-out? - **unreachable deployed estate**: how do you reach equipment behind a closed corporate network? - **long hardware life**: storage capacity must absorb ten years of fixes. These constraints remove no requirement. They must be **addressed in the risk assessment** and reflected in the security environment assumptions communicated to the user. ### Evidence to produce Description of the mechanism in the technical documentation, key management procedure, update test reports — including failure and rollback tests — publication history and advisory messages. ## Securing the build chain URL: https://cra-reference.eu/en/cyber/securing-the-build-chain/ Description: The chain that produces and signs the SBOM is itself an attack surface: the six ways code executes in a pipeline, the pull-request attack, and the countermeasures. Audience: cyber Legal basis: Annex I, Part I — limiting attack surfaces, protecting integrity · Annex I, Part II, point 7 — secure distribution Published 2026-08-20, updated 2026-08-20 [CI/CD integration](/en/cyber/ci-cd/) explains how to **produce** an SBOM in the build chain. This page addresses the reverse problem: **the chain itself**. ### Why this is a compliance matter The build chain produces the artefact, generates the SBOM, applies the signature and issues the provenance attestation. **If it is compromised, everything downstream loses its value**: the SBOM describes whatever the attacker chooses to show, and the signature authenticates a tampered binary. [SolarWinds and Codecov](/en/cyber/incidents/) are exactly that. The Regulation devotes no article to the build chain, but three of its requirements lead there: **limiting attack surfaces** and **protecting integrity** (Annex I, Part I), **secure distribution of updates** (Annex I, Part II, point 7), and **due diligence on third-party components** (Art. 13(5)) — which also covers the components the chain itself consumes, actions and images included. ### The six ways code executes in a pipeline The counter-intuitive point: most of them exploit **no vulnerability**. They are documented features, used as designed. | Mechanism | How it works | Typical example | | --- | --- | --- | | **Direct execution** | The tool's purpose is to run commands described in a repository file | A build file launching a shell script | | **Executable configuration** | The config file is not parsed, it is **evaluated** | A tool configuration written in JavaScript or Python | | **Lifecycle scripts** | The package manager triggers scripts at install time | A package's install hooks | | **Registry redirection** | A repository file redirects resolution to an attacker-controlled source | A committed registry configuration file | | **Environment poisoning** | A variable silently changes a tool's behaviour | A variable read by the shell or by an archive utility | | **Booby-trapped input file** | A malformed archive or file exploits the parser handling it | An archive with absolute paths, a forged project file | **The practical consequence**: disabling install scripts is not enough. A repository that can modify any configuration file can, in most ecosystems, obtain code execution. ### The pull-request attack This is the dominant scenario, and it requires **no access** to the repository. 1. An outside contributor opens a pull request. 2. It touches a file the chain **executes**: a job configuration, a build file, a dependency manifest. 3. The chain triggers automatically on the pull request. 4. If it runs **with the repository's secrets**, they are exfiltrated — often quietly, through an outbound request or by writing them into the logs. The design error that makes this possible is a single one: **executing unreviewed code in a context that holds secrets**. ### Countermeasures, by effectiveness #### 1. Separate the execution contexts The structural measure, and the only one that addresses the cause. | Context | Trigger | Secrets | What it does | | --- | --- | --- | --- | | **Untrusted** | External pull request | **None** | Build, test, static analysis | | **Trusted** | After merge, or on explicit approval | Yes | Publish, sign, deploy | Anything needing a secret belongs to the second. No unmerged code runs there. #### 2. Pin by hash, never by tag A tag is **mutable**: it can be repointed to another commit with nothing changing on your side. That is what happened to a widely used CI action in March 2025. Actions, base images and remote scripts are referenced by **hash**. See [Locking and updating dependencies](/en/cyber/dependency-locking/). #### 3. Protect the files that execute Chain definition files, dependency manifests and evaluated configurations deserve their own review regime: designated owners, mandatory approval, and an alert on modification. #### 4. Least privilege on tokens By default a chain token should be read-only. Write, publish and identity-issuing permissions are granted **job by job**, and only where they are used. An ephemeral token beats a long-lived secret. #### 5. Disable what is not needed Install without running lifecycle scripts, configuration paths forced on the command line rather than read from the repository, registries forced by argument. #### 6. Isolate the runners Ephemeral runners, destroyed after each job, with no uncontrolled outbound network access. Egress filtering turns silent exfiltration into a visible failure. #### 7. Analyse the chain as code Three families of open tools inspect chain definitions and detect these defects: | Tool | What it looks at | | --- | --- | | [actionlint](https://github.com/rhysd/actionlint) | Job definition syntax and the safety of embedded scripts | | [zizmor](https://github.com/zizmorcore/zizmor) | Security defects specific to hosted build chains | | [poutine](https://github.com/boostsecurityio/poutine) | Supply chain analysis of build chains | They run in the chain, on the chain, and their failure must block just as a test does. ### What this produces as evidence | Artefact | What it is for | | --- | --- | | **Versioned** chain configuration | Shows the exact state on a date, for a shipped version | | Dated chain **analysis reports** | Evidence of the regular testing required by Annex I, Part II, point 3 | | **Provenance attestation** signed by the build service | Ties the artefact to the actual revision and parameters | | **Waiver log**, with expiry | Shows blocks are controlled, not bypassed | | Documented **token policy** | Evidence of least privilege | ### How this relates to the provenance level you target Separating contexts, isolating runners and preventing user-defined steps from reaching the signing material are exactly the conditions of the higher levels of the **SLSA** framework — see [Signing and integrity](/en/sbom/signing/). Securing the chain is therefore not a separate project: it is what makes the attestation credible. ## Supply chain risk URL: https://cra-reference.eu/en/cyber/supply-chain-risk/ Description: Attack typology, what an SBOM does and does not enable, countermeasures for hardening the build chain, and mapping your exposure. Audience: cyber Legal basis: Art. 13(5) — due diligence on third-party components · Annex I, Part I — integrity Published 2026-08-19, updated 2026-08-19 ### Why the CRA cares Most of the code in a modern product was not written by its manufacturer. The Regulation draws the consequence: it mandates an inventory, diligence at integration, and upstream reporting of vulnerabilities. The supply chain is the subject; the SBOM is only the instrument. ### Attack typology | Type | Mechanism | Documented case | What would have helped | | --- | --- | --- | --- | | **Repository or maintainer compromise** | Credential theft, takeover of a publishing account | ua-parser-js, Oct 2021 | Signature verification, hash pinning | | **Build chain compromise** | Injection into the supplier's build environment | SolarWinds, Dec 2020 · CCleaner, Sep 2017 | Provenance attestations, reproducible builds | | **Typosquatting** | A package named close to a legitimate one | Recurring campaigns on public registries | Internal proxy registry, allow list | | **Dependency confusion** | A public package outranks a same-named internal one | Research work, Feb 2021 | Reserved namespaces, explicit resolution priority | | **Malicious package published** | Hostile code from the first version | event-stream, Nov 2018 | Human review of new dependencies, quarantine period | | **Mass vulnerability in a ubiquitous library** | A defect in a component present everywhere | Log4Shell, Dec 2021 | **Centralised SBOM**: answer in minutes rather than weeks | | **Long-game social engineering backdoor** | A contributor earns the project's trust, then introduces a subtle defect | xz / liblzma, Mar 2024 | Maintainer diversity, review, reproducible builds | | **Commercial supplier compromise** | A legitimate third-party product becomes the vector | 3CX, Mar 2023 · Kaseya, Jul 2021 | Segmentation, least privilege, behavioural monitoring | | **Takeover of an abandoned component** | A third party takes control of a neglected project | polyfill.io, Jun 2024 | Monitoring maintainer changes | | **Hijacking a build chain step** | A reused CI action is repointed to malicious code | tj-actions, Mar 2025 | **Hash pinning**, least-privilege tokens | Each case is documented, dated and sourced in **[Reference incidents](/en/cyber/incidents/)**: what happened, what would have limited the damage, and the requirement the incident illuminates. ### What an SBOM does and does not enable **Enables:** knowing instantly which products and which shipped versions contain a given component. That is **response capability**, and it turns a multi-week crisis into a day's work. **Does not enable:** detecting malicious code. A hostile package that is correctly inventoried looks like any other. The SBOM answers "what is inside", not "is it clean". It must therefore be complemented by **provenance verification**, **signing**, **review** of new dependencies and **hardening** of the build chain. ### Countermeasures #### On dependencies - **Internal proxy registry**: all dependencies pass through a controlled mirror, never directly from a public repository. - **Version pinning and hash locking**: the lock file is committed, and the build fails if a hash differs. - **Reserved namespaces** for your internal packages, in the public registry where relevant, to prevent dependency confusion. - **Quarantine**: a new dependency becomes available only after a delay and a review. - **Human review** of additions and of major upgrades to sensitive dependencies. #### On the build chain The subject is covered in detail in [Securing the build chain](/en/cyber/securing-the-build-chain/); in summary: - **Isolated runners**, ephemeral, with no uncontrolled outbound network access. - **Least privilege** on publishing tokens; ephemeral tokens rather than long-lived secrets. - **Separation** between building and publishing. - **Provenance attestations** signed by the build service, not by the commit author. - **Reproducible builds**, in time, to allow independent verification. #### On detection - **Monitoring maintainer and licence changes** on critical dependencies. - **Behavioural analysis** of install scripts, a common vector. - **Detecting gaps** between build SBOM and analysed SBOM, which reveals undeclared additions. ### Mapping your exposure An exercise to run once, then maintain from the platform: | Question | What it reveals | | --- | --- | | Which components are present in **more than half** your products? | Single points of failure | | Which are maintained by **one person**? | Takeover or abandonment risk | | Which have had no release for **more than two years**? | Abandonment candidates | | Which are **deep** in the graph, out of your direct sight? | Diligence blind spots | | Which execute code **at install time**? | Build chain attack surface | | Which carry a **risky licence**, or one that has changed? | Legal risk | The map does not need to be exhaustive to be useful: the ten to twenty most critical components concentrate most of the risk, and dealing with them is fundable. ### The message for leadership A supply chain attack cannot be wholly prevented. What is decided is the **reaction time**. Without a centralised inventory that time is measured in weeks and the response is incomplete; with one it is measured in hours and the response is exhaustive. That is the value of the arrangement, independently of any regulatory obligation. ## Technical checklist URL: https://cra-reference.eu/en/cyber/technical-checklist/ Description: Fifteen points to verify per product before the conformity review, printable, to be attached to the pre-market review file. Audience: cyber Published 2026-08-19, updated 2026-08-19 The technical counterpart to the [legal checklist](/en/legal/placing-checklist/). To be completed before the conformity review and attached to the file. **Product:** ______________________ **Exact version:** ______________________ **Date:** ____________ **Owner:** ______________________ --- ### Bill of materials - [ ] **1.** The **SBOM** is generated automatically by the build chain, with no manual step. → [Generating SBOMs](/en/cyber/generating-sboms/) - [ ] **2.** The **format and version** match the company decision and are identical to those of other products. → [Formats](/en/sbom/formats/) - [ ] **3.** **Transitive depth** is covered, and completeness is declared honestly in the document. - [ ] **4.** The **quality score** is above the threshold, and the gap between build SBOM and analysed SBOM is within limits. → [Quality](/en/sbom/quality/) - [ ] **5.** The SBOM is **signed** and accompanied by a provenance attestation. → [Signing](/en/sbom/signing/) - [ ] **6.** The SBOM is **published** to the steering platform and **archived** with indexing by hash. ### Build chain - [ ] **7.** **Blocking policies** are active in CI: critical vulnerabilities, prohibited licences, missing SBOM. → [CI/CD integration](/en/cyber/ci-cd/) - [ ] **8.** Current **waivers** are documented and every one carries an expiry date. ### Vulnerabilities - [ ] **9.** **Continuous monitoring** is active on this product, across all shipped versions. → [Continuous monitoring](/en/cyber/continuous-monitoring/) - [ ] **10.** Uncorrected alerts carry a **VEX** with a standardised justification. → [VEX](/en/sbom/vex/) - [ ] **11.** **Security advisories** are published for fixed vulnerabilities, in a machine-readable format. ### Product security - [ ] **12.** The **risk assessment** is current for this version, and the Annex I traceability matrix is complete. → [Secure by design](/en/cyber/secure-by-design/) - [ ] **13.** The **security tests** in the plan have been run and their reports archived. - [ ] **14.** The **update mechanism** is described, tested — including failure and rollback — and security fixes are separable from functional changes. → [Secure updates](/en/cyber/secure-updates/) ### Response - [ ] **15.** The **CVD channel** is live for this product, `security.txt` is valid and not expired, and the reporting procedure has been **tested** within the last twelve months. → [Disclosure policy](/en/cyber/disclosure-policy/) · [24-hour procedure](/en/cyber/24h-runbook/) --- **Reservations** (open points, with owner and deadline): _______________________________________________________________________ **CISO opinion:** favourable ☐ favourable with reservations ☐ unfavourable ☐ Name, signature, date: ______________________ ## Vulnerability management URL: https://cra-reference.eu/en/cyber/vulnerability-management/ Description: The full cycle from detection to closure, the sources to aggregate, composite-score prioritisation, remediation SLAs and the automated reporting trigger. Audience: cyber Legal basis: Annex I, Part II, points 2 and 4 · Art. 14 — reporting Published 2026-08-19, updated 2026-08-19 ### The cycle ``` detection → SBOM correlation → triage → exploitability qualification (VEX) → prioritisation → remediation → verification → advisory publication → closure → archiving ``` Every transition is timestamped. That chronology is what demonstrates, in an inspection, the "without delay" handling Annex I requires. ### The sources to aggregate | Source | Nature | Role | | --- | --- | --- | | **[EUVD](https://euvd.enisa.europa.eu/)** | European vulnerability database, operated by ENISA | The European reference, fed by CRA reports | | **[NVD](https://nvd.nist.gov/)** | US database, CPE correlation | Broad coverage, latency and imprecise matching | | **[OSV](https://osv.dev/)** | Per-ecosystem database, PURL correlation | **High precision** on packages | | **Catalogues of confirmed exploitation** | Vulnerabilities actually exploited | Priority trigger | | **Vendor and distribution advisories** | Fixes and backports | Avoids version-based false positives | | **Upstream project advisories** | Often ahead of the databases | Early detection | | **National CERTs** | Alerts and threat context | Regional context | Aggregation is the job of the [steering platform](/en/tooling/platforms/), not of a spreadsheet. ### Triage Three questions, in this order: 1. **Is the component actually present?** Verify by `purl` and hash. Many alerts stop here — see [Identifiers](/en/sbom/identifiers/). 2. **Is the vulnerable code reachable?** Reachability analysis, examination of the execution path. This is where the [VEX](/en/sbom/vex/) status is decided. 3. **How urgent is it really?** Prioritisation, below. ### Prioritisation No single indicator suffices. | Indicator | What it tells you | What it does not | | --- | --- | --- | | **Base severity (CVSS)** | Intrinsic severity | Neither actual exploitation nor your context | | **Environmental score** | Severity for you | Requires contextualisation work | | **Exploitation probability** | Likelihood of near-term exploitation | Neither presence with you nor impact | | **Confirmed exploitation** | That it is exploited in the wild | Neither with you, nor on this path | | **Reachability** | That the code is called | Neither exploitability nor impact | | **Network exposure** | That the component is reachable | — | | **Business criticality of the product** | The impact of an incident | — | **Recommended composite score**, to be weighted once and documented: ``` priority = contextualised severity × exploitation factor (confirmed > likely > theoretical) × reachability (called > present but not called) × exposure (network > local) × business criticality of the product ``` What matters is not the formula but that it is **written down, stable and applied uniformly**: that is what makes decisions comparable and defensible. ### Remediation SLAs To be defined, published internally, and **measured**: | Level | Trigger | Target fix interval | | --- | --- | --- | | **Emergency** | Active exploitation observed on your product | Immediate workaround, fix within 72 h | | **Critical** | Remotely exploitable without authentication, reachable | 7 days | | **High** | Exploitable, reachable, specific conditions | 30 days | | **Medium** | Exploitable in a restricted scenario | 90 days | | **Low or not exploitable** | Documented in a VEX | Handled in the next release | These intervals are **internal**; the Regulation requires handling "without delay" without quantifying it. Written and honoured SLAs are the best demonstration of what you mean by "without delay". ### The reporting trigger This is the hinge between engineering and law. > As soon as a vulnerability in your product is qualified as **actively exploited**, the > **24-hour** clock in Article 14 starts. Moving from triage to legal obligation must **not** > depend on the initiative of whoever is on call. Implementation: a dedicated status in the tracking tool whose activation automatically raises an alert to the legal on-call rota and opens an entry in the decision register. See [24-hour procedure](/en/cyber/24h-runbook/) and [Reporting duties](/en/legal/reporting-duties/). ### Separating fixes Annex I asks that, where technically feasible, security fixes be provided **separately** from functional updates. That requires: - a **branching strategy** for maintenance per supported version line; - the ability to **backport** to older branches; - a **numbering scheme** that clearly marks a security fix; - **regression tests** runnable on old branches, hence a preserved build environment. It is a heavy engineering constraint, to be decided **at design time** rather than at the first incident. ### Metrics Median triage interval, median remediation interval by level, average age of open vulnerabilities, share of alerts handled through VEX, share of SLAs met, number of vulnerabilities inherited from abandoned components. See [Metrics](/en/organisation/metrics/). ## Frequently asked questions URL: https://cra-reference.eu/en/faq/ Description: Forty short answers to the questions Legal and Cyber teams ask most, each pointing to the reference page. Audience: transverse Published 2026-08-19, updated 2026-08-19 ### Scope **Is SaaS in scope?** Standalone SaaS falls under NIS 2, not the CRA. A back end inseparable from a connected product is in scope as a remote data processing solution. → [Scope](/en/cra/scope-pde/) **Is software sold by subscription in scope?** Yes. The billing model is irrelevant: it is a software product. **Is a library you sell on its own in scope?** Yes, as a component placed on the market separately. It has its own technical documentation and its own CE marking. **You make medical devices — are you excluded?** Your medical devices fall under the MDR and are excluded from the CRA. Your other products are not. → [Exclusions](/en/cra/exclusions/) **You are established outside the Union — are you in scope?** Yes, as soon as the product is made available on the Union market. An authorised representative established in the Union must be appointed. → [Economic operators](/en/cra/economic-operators/) **You resell a third-party product under your brand — what is your status?** **Manufacturer.** Every obligation falls on you. **Is an internal tool, not commercialised, in scope?** No, absent placing on the market. It is still worth applying the same practices to it. ### Timeline **Is a product sold in 2025 in scope?** For CE marking: no, unless substantially modified. For **reporting**: yes, since 11 September 2026. → [Timeline](/en/cra/timeline/) **Can you expect the deadlines to slip?** No. The Regulation is in force and provides no deferral mechanism. **What is a substantial modification?** A change that alters the product's intended purpose or affects its compliance with the essential requirements. A security update alone is not one. **What is the first thing to do?** Classify the portfolio, then engage notified bodies for class II and Critical products. → [Roadmap](/en/organisation/roadmap/) ### Classification **Does a firewall need a notified body?** Yes: firewalls fall under Annex III, Part II, where self-assessment is excluded. → [Class II](/en/cra/criticality-classes/important-class-2/) **Your product performs several listed functions — which class?** The **highest** applicable. **Does "self-assessment" mean fewer obligations?** No. Only third-party verification disappears. The substance is identical. → [Default category](/en/cra/criticality-classes/default/) **Can a class I product self-assess?** Only by applying **in full** harmonised standards covering all relevant requirements. Until they are cited in the *Official Journal*, that route is closed in practice. ### SBOM **Can a spreadsheet be used as an SBOM?** No. The Regulation requires a commonly used and **machine-readable** format. **Is a PDF enough?** No, for the same reason. **Are transitive dependencies mandatory?** The legal minimum is top level. That is a floor, not a target: incidents travel mostly through transitive dependencies. → [What the CRA requires](/en/sbom/cra-requirement/) **Must you publish your SBOM?** No. It must be in the technical documentation, held at the disposal of authorities. Sharing it with customers is a commercial decision. → [Distribution](/en/sbom/distribution/) **CycloneDX or SPDX?** Both are acceptable. Your pivot format is CycloneDX, with SPDX export on request. → [Formats](/en/sbom/formats/) **How long must you retain SBOMs?** Ten years after placing on the market, or the support period if longer. → [Retention](/en/legal/evidence-retention/) **Two tools give two different SBOMs — which one is right?** Both, within their scope. Pin the toolchain per product family and document the choice. → [Generating SBOMs](/en/cyber/generating-sboms/) **One SBOM per version?** Per **publishable build**. An SBOM with no version reference has no value. ### Vulnerabilities and reporting **What happens if you miss the 24-hour deadline?** It is a breach of Article 14, falling under the highest penalty ceiling — without prejudice to non-financial measures. → [Penalties](/en/cra/penalties/) **Does a public exploit trigger the reporting obligation?** No, not on its own. **Reliable evidence of exploitation** in a real system is required. **Is exploitation at a single customer enough?** Yes. → [Reporting](/en/cra/enisa-reporting/) **Who decides to report?** Legal, on the PSIRT's qualification, with a written delegation and a deputy. → [Reporting duties](/en/legal/reporting-duties/) **Must you fix every vulnerability your tools detect?** No. They must be **addressed**. A vulnerability analysed and declared non-exploitable, with a standardised justification in a VEX, has been addressed. → [VEX](/en/sbom/vex/) **Can a scanner alert be disabled?** It can be set aside through a reasoned VEX, or muted on a **dated** basis. It cannot be erased. → [False positives](/en/cyber/false-positives/) **Does CRA reporting replace GDPR notification?** No. Three distinct regimes may apply to the same event. → [Interplay](/en/cra/interplay/) ### Open source **Is a free library you publish at no charge in scope?** No, if the supply is outside a commercial activity. → [Individual developer](/en/cra/open-source/individual-developer/) **Does accepting donations make the activity commercial?** No, not on its own. **Are you responsible for the free components you embed?** Yes, fully. Upstream is not responsible on your behalf. → [Integrating open source](/en/cra/open-source/integrating-oss/) **What is an open-source software steward?** A legal person, other than a manufacturer, providing systematic and sustained support to the development of free software intended for commercial activities and ensuring its viability. A lightened regime, with no fines. → [Steward](/en/cra/open-source/steward/) **Must you report fixes upstream?** Yes: report the vulnerability to the maintainer and, where relevant, share the fix. ### Documentation and evidence **Who signs the EU declaration of conformity?** A person authorised to bind the company. The declaration is issued under the **sole responsibility of the manufacturer**. → [Declaration](/en/legal/declaration-of-conformity/) **Must the SBOM be in the technical documentation?** Yes, under the vulnerability handling processes. → [Technical documentation](/en/cra/technical-documentation/) **What if an authority asks for your file?** Apply the response card: acknowledge, qualify, freeze the evidence, answer within the deadline, log everything. → [Market surveillance](/en/cra/market-surveillance/) **Can you charge for access to security fixes?** No, during the support period, except where otherwise agreed for tailor-made products between businesses. → [Support period](/en/legal/support-commitments/) **Is the support period commercially negotiable?** Its duration must be **justified**, at minimum five years unless the expected lifetime is shorter. It is not a free commercial variable. --- *A question missing from this list? See [Contact](/en/contact/) — the FAQ is driven by the questions people actually ask.* ## Glossary URL: https://cra-reference.eu/en/glossary/ Description: The CRA and SBOM vocabulary, with the French equivalent where it differs, and a pointer to the reference page. Audience: transverse Published 2026-08-19, updated 2026-08-19 The European vocabulary is authoritative in English; the French term is given where it is in common internal use. ### A **Actively exploited vulnerability** — A vulnerability for which there is reliable evidence that a malicious actor has exploited it in a system without permission. Trigger for the 24-hour deadline. **ADCO** — Administrative Cooperation Group of market surveillance authorities; organises coordinated sweeps. **AGPL** — Affero General Public License. A **network** copyleft licence: making a service available online triggers the source-provision obligation. → [Licence families](/en/licensing/families/) **Annex I** — Essential requirements. **Part I**: product security. **Part II**: vulnerability handling. → [Essential requirements](/en/cra/essential-requirements/) **Annex II** — Information and instructions to the user. → [User information](/en/legal/user-information/) **Annex III** — Important products: Part I (class I), Part II (class II). **Annex IV** — Critical products. **Annex V** — Content of the EU declaration of conformity. **Annex VII** — Content of the technical documentation. **Annex VIII** — Conformity assessment procedures (modules). **[ANSSI](https://cyber.gouv.fr/)** — The French national cybersecurity agency. **Attestation, provenance** — A signed statement describing how an artefact was produced. → [Signing](/en/sbom/signing/) ### C **CE marking** — The manufacturer's declaration, under its sole responsibility, that the product meets the applicable requirements. → [CE marking](/en/cra/ce-marking/) **CPE** — Common Platform Enumeration. A historical product identifier, imprecise, a major cause of false positives. → [Identifiers](/en/sbom/identifiers/) **CRA** — Cyber Resilience Act, Regulation (EU) 2024/2847. **CSAF** — Common Security Advisory Framework 2.0, an OASIS standard for machine-readable security advisories, with a VEX profile. **CSIRT, coordinating** — The national response team designated to receive reports. **CVD** — Coordinated vulnerability disclosure. → [Disclosure policy](/en/cyber/disclosure-policy/) **CVE** — Common Vulnerabilities and Exposures. A public vulnerability identifier. **CVSS** — Common Vulnerability Scoring System. Intrinsic severity score. **[CycloneDX](https://cyclonedx.org/)** — The OWASP SBOM format, standardised as ECMA-424. → [CycloneDX](/en/sbom/formats/cyclonedx/) ### D **Distributor** — An operator that makes a product available without manufacturing or importing it. → [Economic operators](/en/cra/economic-operators/) **Due diligence** — The obligation to assess third-party components before integrating them, and to document that assessment. ### E **ENISA** — The European Union Agency for Cybersecurity. Operates the single reporting platform and contributes to the EUVD. **EPSS** — Exploit Prediction Scoring System. Short-term exploitation probability. **EUCC** — The European cybersecurity certification scheme adopted under Regulation (EU) 2019/881. **EU declaration of conformity** — The document by which the manufacturer attests conformity. → [Declaration](/en/legal/declaration-of-conformity/) **[EUVD](https://euvd.enisa.europa.eu/)** — European Vulnerability Database, created under NIS 2 and operated by ENISA. → [Continuous monitoring](/en/cyber/continuous-monitoring/) ### F **FPGA** — Field-programmable gate array. Falls under class I where it carries security-related functionalities. ### H **Harmonised standards** — European standards whose references are cited in the *Official Journal* and which confer a presumption of conformity. ### I **Importer** — An operator established in the Union that places on the market a product from a third country. **[in-toto](https://in-toto.io/)** — A framework for attestations about the build chain. **Incident, severe** — An event affecting the product's ability to protect availability, authenticity, integrity or confidentiality. A reporting trigger. ### M **Making available on the market** — Any supply in the course of a commercial activity, after the first. **Manufacturer** — A person who develops or has a product developed and markets it under their own name or trademark. Carries the bulk of the obligations. **Modules A / B / C / H** — The conformity assessment procedures in Annex VIII. → [Conformity assessment](/en/cra/conformity-assessment/) ### N **NANDO** — The European Commission's database of notified bodies. **NIS 2** — Directive (EU) 2022/2555, concerning **entities** rather than products. **Notified body** — An accredited conformity assessment body, designated and notified to the Commission. **[NVD](https://nvd.nist.gov/)** — National Vulnerability Database. The US database, CPE correlation. ### O **Open-source software steward** — A legal person, other than a manufacturer, providing systematic and sustained support to free software intended for commercial activities. A lightened regime. → [Steward](/en/cra/open-source/steward/) **[OSV](https://osv.dev/)** — Open Source Vulnerabilities. A per-ecosystem database, PURL correlation, high precision. ### P **PDE** — Product with digital elements. → [Scope](/en/cra/scope-pde/) **Placing on the market** — The first making available of a product on the Union market. The moment at which conformity is assessed. **Presumption of conformity** — The effect of applying harmonised standards, common specifications or a certification scheme. **PPE** — *Poisoned Pipeline Execution*. An attack that makes the build chain run unreviewed code, brought in by a pull request, in a context holding secrets. → [Securing the build chain](/en/cyber/securing-the-build-chain/) **PSIRT** — Product Security Incident Response Team. **[PURL](https://github.com/package-url/purl-spec)** — Package URL. The canonical per-ecosystem identifier, to be preferred. → [Identifiers](/en/sbom/identifiers/) ### R **Reachability** — Whether a vulnerable function can actually be called from your entry points. A central prioritisation criterion. → [False positives](/en/cyber/false-positives/) **RED** — Directive 2014/53/EU on radio equipment, and Delegated Regulation (EU) 2022/30. **Remote data processing solution** — Processing designed by the manufacturer whose absence would prevent the product from performing one of its functions. How the cloud enters the CRA. **Backport** — Applying a fix to an earlier version without changing the upstream version number. A frequent cause of false positives. **Immutable reference** — A commit or content hash, as opposed to a version tag, which can be repointed. → [Locking dependencies](/en/cyber/dependency-locking/) **Lock file** — A record of the exact resolution of dependencies, transitive ones included, with their hashes. The precondition for reproducibility. → [Locking dependencies](/en/cyber/dependency-locking/) ### S **SBOM** — Software bill of materials. → [SBOM](/en/sbom/) **Scorecard** — *OpenSSF Scorecard*. An open tool running eighteen automated checks on a repository and deriving a score out of 10, which makes diligence computable. → [Assessing a component](/en/cyber/assessing-components/) **S2C2F** — *Secure Supply Chain Consumption Framework*. An OpenSSF framework describing how to consume open source in a controlled way, with a maturity model. → [Assessing a component](/en/cyber/assessing-components/) **`security.txt`** — The RFC 9116 standardised file stating the contact point for vulnerability reports. **[Sigstore](https://www.sigstore.dev/)** — A signing infrastructure with a transparency log. **[SLSA](https://slsa.dev/)** — A framework of build chain maturity levels. **[SPDX](https://spdx.dev/)** — Software Package Data Exchange. The Linux Foundation SBOM format, standardised as ISO/IEC 5962. Its **licence list** is authoritative. → [SPDX](/en/sbom/formats/spdx/) **SRP** — Single reporting platform, operated by ENISA. → [Reporting](/en/cra/enisa-reporting/) **Substantial modification** — A change that alters the intended purpose or affects conformity. Reopens the assessment. **Support period** — The period during which the manufacturer produces security updates. At least five years, unless the expected lifetime is shorter. → [Support period](/en/cra/support-period/) ### T **Technical documentation** — The set of items required by Annex VII. → [Technical documentation](/en/cra/technical-documentation/) **Transitive dependency** — A dependency dragged in by one of your dependencies, without your declaring it. → [Quality](/en/sbom/quality/) ### V **VEX** — Vulnerability exploitability exchange. A structured assertion about the exploitability status of a vulnerability in a given product. → [VEX](/en/sbom/vex/) ## Leadership URL: https://cra-reference.eu/en/leadership/ Description: The CRA in five minutes for an executive committee: market access exposure, financial exposure, decisions required and current progress. Audience: direction Published 2026-08-19, updated 2026-08-19 ### In one sentence **Without a software bill of materials and a documented vulnerability handling process, you will no longer be able to affix the CE marking to your digital products — and therefore no longer sell them in the European Union.** ### In three numbers | | | | --- | --- | | **11 September 2026** | Report an actively exploited vulnerability within **24 hours** to ENISA and the coordinating CSIRT. Applies **to products already on the market too**. | | **11 December 2027** | CE marking, technical documentation, SBOM, support period, user information: full application. | | **EUR 15 m or 2.5 %** | Administrative fine ceiling for breaches of the essential requirements or the reporting obligations — the higher of EUR 15 million and 2.5 % of total worldwide annual turnover. | ### The five facts that drive the effort 1. **The criticality class drives the cost.** A default product self-assesses; an Important class II or Critical product requires a **notified body**, with a lead time of several months and limited market capacity. That is the critical path. 2. **The support period commits you for five to ten years.** It forces you to keep build chains alive, backport fixes and retain artefacts long after commercial end of life. 3. **The reporting deadline has already passed**, and it covers the legacy portfolio. It requires an on-call rota, not a project. 4. **The CRA overlaps substantially with NIS 2, DORA and customer questionnaires.** The effort is not wasted: it feeds those requirements too. 5. **The SBOM has become a commercial argument.** Large accounts and public buyers already ask for it; producing one meets an obligation and shortens sales cycles. ### Decisions required from the committee - **Appoint an executive sponsor** and approve the [RACI matrix](/en/organisation/raci/), in particular the three trade-offs listed in [Organisation](/en/organisation/). - **Choose an investment scenario** among the three described in [Budget and resources](/en/leadership/budget/), explicitly accepting the residual risk that goes with it. - **Authorise contracting with a notified body** for products that cannot self-assess, without waiting for harmonised standards to be published. ### Where you stand Progress is tracked in [Metrics](/en/organisation/metrics/): portfolio coverage, remediation intervals, residual exposure. The [self-assessment](/en/self-assessment/) re-measures it quarterly against a stable grid. ## Budget, resources and scenarios URL: https://cra-reference.eu/en/leadership/budget/ Description: Three investment scenarios with their residual risk, the items to provision, the profiles needed and the trade-offs to settle. Audience: direction Published 2026-08-19, updated 2026-08-19 ### Items to provision | Item | Investment | Recurring | | --- | --- | --- | | Steering platform | Integration, migration | Licence or operations | | Generators and CI integration | Development of shared scripts | Maintenance | | Evidence vault and archiving | Set-up, indexing | Storage, migrations | | Notified bodies | First assessment per product | Extensions, reassessments | | Certification of critical products | Security target, laboratory | Certificate maintenance | | PSIRT and on-call cover | Recruitment, tooling | Salaries, rota | | Compliance and legal | Clause set, templates, training | Watch, reviews | | Long support maintenance | Preserved build environments | **Backports, over 5 to 10 years** | | Training | Producing the materials | Recurring sessions | | Exercises and audits | First cycle | Six-monthly and annual | ### Profiles needed | Profile | Role | Indicative load | | --- | --- | --- | | **Product compliance lead** | Keeps the registers, drives the technical files, interfaces with authorities | Full time from wave 0 | | **Application security engineer** | Tooling, CI integration, SBOM quality | Full time during waves 2 and 3 | | **PSIRT analyst** | Triage, VEX, advisories, reporting | Full time from wave 1 | | **Lawyer** | Classification, contracts, reporting decisions | Part time, with on-call | | **Per-team product champion** | Applies, remediates, documents | Part time, across all teams | **On-call cover** is the most frequently forgotten item: a 24-hour obligation requires a rota, therefore a minimum headcount, and compensation. ### Three scenarios #### Scenario A — Minimally compliant **Content.** Open tooling, self-hosted platform, evidence vault on existing infrastructure, on-call cover shared with existing rotas, technical documentation written in-house, notified bodies only where mandatory. **What it covers.** The obligations, with no margin. **Residual risk:** low tolerance for the unexpected. A major incident coinciding with an authority request saturates the team. Long support maintenance is the item that will crack first, around year three. **Who it suits:** a limited portfolio, mostly default-category products. #### Scenario B — Recommended **Content.** Scenario A, plus: a dedicated PSIRT team with its own on-call rota, a commercial tool on the weakest link — usually licensing or reachability — an identified backport budget, two exercises a year, an annual external audit. **What it covers.** The obligations, with the capacity to absorb an incident and to last. **Residual risk:** acceptable and named. **Who it suits:** most organisations with important products under Annex III. #### Scenario C — Ambitious **Content.** Scenario B, plus: an integrated enterprise platform, reachability analysis, a customer portal with machine-readable SBOMs and advisories, reproducible builds, participation in standardisation work, CVE numbering authority status. **What it covers.** The obligations, and a differentiating commercial position. **Who it suits:** critical products, a large installed base, regulated sectors, or a strategy of differentiation through transparency. ### Decision table | | A — Minimal | B — Recommended | C — Ambitious | | --- | --- | --- | --- | | Covers the obligations | Yes, no margin | Yes | Yes | | Withstands a major incident | With difficulty | Yes | Yes | | Holds over ten years | Uncertain | Yes | Yes | | Commercial argument | No | Partial | **Yes** | | Residual risk | **High** | Moderate | Low | | Decision required | Accept the risk, by name | Fund | Fund and arbitrate the portfolio | ### Trade-offs to settle 1. **In-house or outsourced** PSIRT and on-call cover? Outsourcing reduces fixed cost but transfers product knowledge poorly, and product knowledge is the heart of qualification. 2. **Open or commercial tooling?** The recommendation is to start open in order to measure, then invest against the observed gap — not the advertised one. 3. **Which scope first?** Class II and Critical products first, then those with the highest Union turnover. 4. **What to do about products whose compliance costs more than they earn?** That is a portfolio decision, to be taken explicitly rather than endured. It is legitimate and must be documented. ### What to ask the committee for A written decision on: the **scenario chosen**, the **residual risk accepted** with the name of whoever accepts it, the **budget** in investment and recurring terms, and the **products removed from the portfolio** where applicable. A scenario chosen without a named acceptance of the residual risk is not a decision: it is a deferral. ## Business impact URL: https://cra-reference.eu/en/leadership/business-impact/ Description: Market access risk, financial exposure, the cost of compliance, commercial opportunities and the knock-on effect on NIS 2, DORA and customer questionnaires. Audience: direction Published 2026-08-19, updated 2026-08-19 ### Market access risk This is the principal risk, and it is not gradual: without CE marking a product cannot be placed on the Union market. **Calculation to produce for the committee:** | Line | Value | | --- | --- | | Turnover made in the European Union | _____ €m | | Share made by products with digital elements | _____ % | | **Turnover exposed** | _____ €m | | Share of that turnover carried by class II or Critical products | _____ % | | **Turnover dependent on a notified body** | _____ €m | The last line is what should trigger the decision: it is the turnover whose continuity depends on a third party whose lead time you do not control. ### Financial exposure Three components, detailed in [Exposure and risk register](/en/legal/exposure/): 1. **Administrative** — up to EUR 15 m or 2.5 % of worldwide turnover. 2. **Commercial** — turnover lost during a prohibition or withdrawal, plus recall costs for a hardware product. 3. **Contractual** — penalties, terminations and indemnities under your contracts. To which is added **civil liability** exposure: Directive (EU) 2024/2853 covers software and takes the absence of security updates into account when assessing defectiveness. ### The cost of compliance | Item | Nature | Horizon | | --- | --- | --- | | **Tooling** | Investment then subscription | Recurring | | **Headcount** | PSIRT, compliance, security engineering | Recurring | | **On-call cover** | Technical and legal rota | Recurring | | **Notified bodies** | Initial assessment per product and maintenance | Per product, per cycle | | **Certification** of critical products | Evaluation laboratory, certificate maintenance | Per product, long cycle | | **Maintaining 5–10 year support** | Preserved build chains, backports, archiving | **The most underestimated** | | **Training** | Development, legal, procurement | One-off then recurring | The most underestimated item is the second to last: **retaining the ability to produce a fix for a version shipped eight years ago** requires preserved build environments, available skills and an organisation that spends time on it with no revenue attached. ### The opportunities They are real and rarely highlighted, although they carry part of the funding case. **The SBOM has become a commercial argument.** Large accounts and public buyers already ask for it in tenders. Producing one meets an obligation and shortens sales cycles. **Customer security questionnaires** can be answered in hours rather than weeks once the evidence exists. Across a meaningful volume of tenders, the saving is measurable. **Acquisition and fundraising diligence** now covers the CRA. A clean file avoids a liability warranty or a price holdback. **Technical debt becomes visible and quantifiable.** The inventory reveals abandoned components, frozen versions and single-maintainer dependencies. It is the first time that information is available across the whole portfolio. **Response time to a major incident** falls from weeks to hours. The value of that gain is measured against the cost of the last public supply chain incident. ### The knock-on effect CRA compliance covers a large share of what is expected elsewhere: | External requirement | Covered by CRA work | | --- | --- | | **NIS 2** — supply chain security, incident management | Largely | | **DORA** — for your financial-sector customers | Partly | | Customer security **questionnaires** | Largely | | **ISO/IEC 27001** — asset and vulnerability control | Partly | | **Licence audits** | Largely, through the SBOM | | **Acquisition diligence** | Largely | Presenting the programme as a **shared evidence base** rather than a regulatory silo changes how it gets funded. ### The message to take away The CRA turns good practice into a condition of market access. The cost of compliance is real and recurring; the cost of non-compliance is discontinuous and potentially fatal for a product line. The trade-off is not "do it or not", but **at what pace and over what scope**. ## Legal path URL: https://cra-reference.eu/en/legal/ Description: CRA obligations seen from Legal and Compliance: CE marking, technical documentation, EU declaration, reporting, penalties, contracts, licensing, support and evidence retention. Audience: legal Legal basis: Art. 13, 14, 30, 31 · Annexes II, V, VII Published 2026-08-19, updated 2026-08-19 This section does not redefine the Regulation — it translates it into **obligations, evidence and control points** that belong to Legal. Every page links to the canonical definition in [The CRA framework](/en/cra/). ### Master table of obligations | Obligation | Legal basis | Deadline | Evidence expected | Page | | --- | --- | --- | --- | --- | | Qualify the product as a PDE | Art. 2, 3 | 11/12/2027 | Signed qualification sheet | [Scope](/en/cra/scope-pde/) | | Determine the criticality class | Annexes III, IV | 11/12/2027 | Classification sheet | [Classes](/en/cra/criticality-classes/) | | Choose the assessment route | Art. 32, Annex VIII | 11/06/2026 | Notified body contract | [Assessment](/en/cra/conformity-assessment/) | | Compile the technical documentation | Annex VII | 11/12/2027 | Complete file, SBOM included | [Technical documentation](/en/legal/ce-and-documentation/) | | Draw up the EU declaration of conformity | Annex V | 11/12/2027 | Signed declaration | [Declaration](/en/legal/declaration-of-conformity/) | | Affix the CE marking | Art. 30 | 11/12/2027 | Conformity review record | [CE marking](/en/cra/ce-marking/) | | Report within 24 h / 72 h / 14 d | Art. 14 | **11/09/2026** | Register + platform acknowledgements | [Reporting](/en/legal/reporting-duties/) | | Determine and publish the support period | Art. 13, Annex II | 11/12/2027 | Register + statement to the buyer | [Support](/en/legal/support-commitments/) | | Provide information to the user | Annex II | 11/12/2027 | Notice shipped with the product | [User information](/en/legal/user-information/) | | Retain file and declaration | Art. 13, 31 | 11/12/2027 | Evidence vault + audit log | [Retention](/en/legal/evidence-retention/) | ### What Legal must obtain from Cyber - the **SBOM**, validated and signed, per product and per version, in the agreed format; - the documented **cybersecurity risk assessment**; - the **vulnerability handling log** and the **VEX** statements justifying uncorrected vulnerabilities; - an operational **coordinated disclosure policy** with a live point of contact; - **security test reports**; - a description of the **update distribution mechanism**; - the technical grounds for the **support period** chosen; - in an incident, the **"actively exploited" qualification**, within two hours. ### What Legal must supply to Cyber - the **regulatory classification** of each product and the assessment route chosen; - the **licence policy** and the list of prohibited licences; - the **supplier clauses** negotiated and the commitments obtained; - the decision on **SBOM disclosure** to customers; - the **decision to report** and the approved wording; - the **support period** committed contractually. These exchanges, with deadlines and formats, are formalised in [Legal ↔ Cyber interface](/en/organisation/legal-cyber-interface/). ### The control point that matters One thing must be non-negotiable on the Legal side: **a formal right of veto over placing on the market** until the fifteen points of the [checklist](/en/legal/placing-checklist/) are ticked. Without that gate, technical documentation gets assembled after the fact — which is exactly what market surveillance is looking for. ## CE marking and technical documentation: the internal process URL: https://cra-reference.eu/en/legal/ce-and-documentation/ Description: Who compiles, who reviews, who signs. The approval workflow, the market gate and the conformity review record. Audience: legal Legal basis: Art. 30 — CE marking · Art. 31 and Annex VII — technical documentation Published 2026-08-19, updated 2026-08-19 The content of the file is described in [Technical documentation](/en/cra/technical-documentation/); the affixing rules in [CE marking](/en/cra/ce-marking/). This page covers the **internal process**: who does what, in which tool, with which approval. ### The principle: a gate, not a formality The technical documentation is not a document Legal writes at the end from whatever engineering chooses to send. It is an **assembly of items produced continuously**, whose absence blocks placing on the market. Hence a single control point, the **market gate**, passed on presentation of evidence, not on a statement of intent. ### Split of roles | File item | Producer | Reviewer | Approver | | --- | --- | --- | --- | | General description, versions | Product management | Legal | Legal | | Architecture diagrams | Engineering | CISO | CISO | | **SBOM** | CI chain | CISO | CISO | | CVD policy and evidence of publication | PSIRT | Legal | Legal | | Evidence the contact point works | PSIRT | Legal | Legal | | Update distribution process | Engineering | CISO | CISO | | Risk assessment | CISO | Legal | CISO | | Support period and justification | Product management | Legal | **Executive management** | | Standards applied and deviations | CISO | Legal | CISO | | Test reports | Quality and CISO | CISO | CISO | | EU declaration of conformity | Legal | Executive management | **Authorised signatory** | | Notified body attestations | Legal | — | Legal | The support period escalates to executive management because it commits the company financially for five to ten years: it is not a technical decision. ### The workflow 1. **Open the file** when the decision to develop is taken, not on the eve of launch. The file is a living space, fed throughout the project. 2. **Completeness milestones** at key project stages: design, end of development, pre-launch. At each milestone, a statement of missing items. 3. **Conformity review** before placing on the market, in session, with those responsible for each item. 4. **Signed record**, which authorises affixing the marking. 5. **Freeze and archive** the version of the file corresponding to the version placed on the market. 6. **Reopen** on substantial modification. ### The conformity review record One page, structured as: - identification of the product and the **exact version** placed on the market; - criticality class and assessment route chosen, with a pointer to the classification sheet; - **status of the fifteen points** of the [checklist](/en/legal/placing-checklist/), ticked item by item; - any reservations, with deadline and owner; - **decision**: authorisation to affix the marking, or reasoned refusal; - date, participants, signatures. This document is the trace of the company's diligence. In an inspection it demonstrates that conformity was verified **before** placing on the market, not reconstructed afterwards. ### The tool The technical documentation must live in a system that guarantees: - **traceability** of versions and approvals; - **immutability** of frozen states; - **retrieval** of a past state, ten years later; - **linking** to technical artefacts — SBOM, test reports — rather than copying them. A shared folder without versioning satisfies none of those four criteria. ## Supplier and customer contract clauses URL: https://cra-reference.eu/en/legal/contract-clauses/ Description: The clauses to require upstream so you can meet your own deadlines, those to negotiate downstream, and the special case of free components for which no contract exists. Audience: legal Legal basis: Art. 13(5) — due diligence on third-party components · Art. 14 — reporting deadlines Published 2026-08-19, updated 2026-08-19 Your regulatory obligations do not stop at your technical perimeter: they depend on how fast your suppliers react. The contract is the only instrument that can guarantee that. ### The deadline cascade principle You must issue an early warning **within 24 hours**. If your supplier notifies you within 72 hours, you are in breach without having done anything wrong. Upstream contractual deadlines must therefore be **strictly shorter** than yours. | Your obligation | Supplier deadline to require | | --- | --- | | Early warning within 24 h | **Notification within 8 h** of any actively exploited vulnerability | | Notification within 72 h | Circumstantial information within 36 h | | Final report within 14 d of a fix | Fix or documented workaround within 7 d | ### Clauses for your purchase contracts #### Software bill of materials - Supply of an **SBOM** in CycloneDX or SPDX format, at a specified minimum version. - **With every version delivered**, without you having to ask. - A commitment on **depth** — transitive dependencies included — and an honest completeness declaration. - Supply of **licences** as SPDX identifiers. #### Security and vulnerabilities - **Notification deadlines** per the cascade above. - **Fix deadlines** by severity level, with penalties. - Supply of **VEX statements** or a reasoned position on uncorrected vulnerabilities. - **Access to security advisories**, in a machine-readable format where possible. #### Life cycle - A **support period** at least aligned with the one you commit to your customers. - **Notice of end of support**, long enough to allow migration — twelve months minimum for a central component. - **Notification of maintainer or licence change.** #### Compliance - A **CRA compliance commitment** for components that are themselves products within the meaning of the Regulation, and supply of the EU declaration of conformity. - **Audit rights** and access to security test results. - **Warranty of title** to the rights and licences, and supply of the information needed to meet attribution obligations. #### Continuity - **Reversibility** and, for critical components, **source code escrow** with a third party, with release conditions including cessation of business and end of support. #### Liability - **Indemnity** for non-compliance attributable to the supplier, including administrative penalties you would incur as a result. - Interaction with liability caps: a cap expressed as a percentage of the annual contract bears no relation to a fine assessed on your worldwide turnover. That imbalance must be identified and arbitrated, not ignored. ### Clauses to negotiate in your sales contracts - **Support scope**: what is covered, what is not, and the end date of the support period, expressed at least as a month and year. - **SBOM supply arrangements**: format, frequency, channel, confidentiality — see [Distribution and confidentiality](/en/sbom/distribution/). - **Notification channel** in the event of a vulnerability, and a customer commitment to keep contact details valid — you cannot inform a customer you cannot reach. - A **duty to update** on the customer side: your fixes only protect if they are applied. - **Liability limitation** consistent with your regulatory exposure. - Treatment of **unmaintained versions** after the end of the support period. ### The case of free components There is no contract, therefore no clause. No negotiation is possible with a community project, and asking it for a support commitment is meaningless. The risk is therefore handled by other means: 1. **diligence at selection** — see [Integrating open source](/en/cra/open-source/integrating-oss/); 2. **continuous monitoring** of project activity and maintainer changes; 3. **internal capability** to take over maintenance, fork or replace; 4. where appropriate, **funding** the upstream project, which improves its viability without creating any legal obligation towards you. > **To say plainly internally.** A critical free component, maintained by one person, in a > product covered by a five-year support period, is a non-transferable risk. It can be neither > insured nor contracted away — only provisioned for or removed. ### The clause set A **standard clause set** in French and English, kept by Legal, with, for each clause: the wording, the regulatory justification, how negotiable it is, and the acceptable fallback. That document is what lets procurement negotiate without calling Legal on every contract. ## EU declaration of conformity URL: https://cra-reference.eu/en/legal/declaration-of-conformity/ Description: Mandatory content under Annex V, the simplified form in Annex VI, language requirements, a ready-to-use template and the update rules. Audience: legal Legal basis: Art. 28 — EU declaration of conformity · Annex V — content · Annex VI — simplified declaration Published 2026-08-19, updated 2026-08-19 ### What the declaration is The document by which the manufacturer **attests, under its sole responsibility**, that the product satisfies the applicable essential requirements. It is drawn up **before** placing on the market and accompanies the product. It is short — one or two pages — but binding: it is what turns the CE marking into an enforceable statement. ### Mandatory content (Annex V) 1. **Name and type of the product**, with the elements allowing its traceability: reference, version number, and where useful a photograph. 2. **Name and address** of the manufacturer or its authorised representative. 3. A statement that the declaration is issued **under the sole responsibility of the manufacturer**. 4. The **object of the declaration**: identification of the product allowing traceability, including where necessary a sufficiently clear colour image. 5. A statement that the object is **in conformity with Regulation (EU) 2024/2847** and, where applicable, with other applicable Union harmonisation legislation. 6. **References to the harmonised standards** applied, to common specifications or to European certification schemes, with their version date. 7. Where applicable, the **name and number** of the notified body, a description of the assessment procedure followed and the reference of the certificate issued. 8. Any **additional information**. 9. **Place and date** of issue, **name, function and signature** of the signatory. ### The simplified declaration (Annex VI) An abbreviated form is permitted, containing at minimum the product identification, the statement of conformity with the Regulation, and the **exact internet address** where the full declaration can be accessed. It is useful on packaging and notices, but does not replace the full declaration, which must remain available. ### Language requirements The declaration is **translated into the language or languages required by the Member State** in whose market the product is made available. In practice, for Union-wide distribution, that means planning a translation chain and a consistency check across versions. The authoritative version is the one drawn up by the manufacturer; translations must be faithful to it. ### Template ``` EU DECLARATION OF CONFORMITY 1. Product: Acme Gateway, reference AG-4200, software version 4.2.1 2. Manufacturer: [Legal name] [Full postal address] [Email address] — [Website] 3. This declaration of conformity is issued under the sole responsibility of the manufacturer. 4. Object of the declaration: product with digital elements "Acme Gateway", version 4.2.1, identified by [hash / serial number]. 5. The object of the declaration described above is in conformity with the relevant Union harmonisation legislation: — Regulation (EU) 2024/2847 (Cyber Resilience Act) — [where applicable, other applicable acts] 6. References to the harmonised standards applied, or to the other specifications against which conformity is declared: — [standard reference and date] — [description of the solutions adopted for requirements not covered] 7. Notified body: [name], number [NNNN], performed [procedure] and issued certificate [reference]. [Or: not applicable — assessment carried out under module A, internal control.] 8. Additional information: support period until [month/year]. Signed for and on behalf of: [Legal name] Place and date: [city], [date] Name and function: [name], [function] Signature: ____________________ ``` ### Update rules | Event | Is a new declaration needed? | | --- | --- | | New security-fix version, no other change | No, if the declaration expressly covers the version line | | New functional version | **Yes**, if the declared version changes | | Substantial modification | **Yes**, after a new assessment | | Change of legal name or address | **Yes** | | A new harmonised standard cited in the OJ replacing the one applied | To be examined; the declaration must reflect the references actually applied | The question of **version scope** must be settled with the first declaration: declaring a precise version is stricter, declaring a version line is more manageable. The choice must be consistent with the versioning strategy, and documented. ### Retention Ten years after placing on the market, or the support period if longer — like the technical documentation. See [Evidence retention](/en/legal/evidence-retention/). ## Evidence retention URL: https://cra-reference.eu/en/legal/evidence-retention/ Description: Which artefacts to keep, for how long, under what integrity guarantees, and the annual retrieval exercise that alone proves the arrangement works. Audience: legal Legal basis: Art. 13 and 31 — retention of technical documentation and declaration Published 2026-08-19, updated 2026-08-19 ### The rule The **technical documentation** and the **EU declaration of conformity** are kept at the disposal of market surveillance authorities for **at least ten years after the product is placed on the market, or for the support period, whichever is longer**. For consistency, everything the file rests on follows the same period. ### What to keep | Artefact | Why | Period | | --- | --- | --- | | **Technical documentation**, in the version frozen at placing on the market | The centrepiece of any inspection | 10 years / support period | | Signed **EU declaration of conformity** | Same | Same | | **SBOM** for every shipped version, signed | File item, basis for incident response | Same | | **VEX statements** and vulnerability handling log | Proof that vulnerabilities were addressed | Same | | Security **test reports** | Proof of the regular-testing requirement | Same | | **Risk assessment** and its revisions | Justifies the requirements ruled out | Same | | **Reporting register** and platform acknowledgements | Proof of compliance with Article 14 deadlines | Same | | **Correspondence with authorities** and notified bodies | Traceability of exchanges | Same | | Notified body **certificates** | Basis of the assessment route | Same | | Published **security advisories** | Proof of Annex I, Part II, point 4 | Same | | **Information to the user** shipped | Proof of Annex II | Same | | **Public keys** for verifying signatures | Without them, signatures cannot be verified | Effectively indefinite | ### The guarantees to provide | Guarantee | What it implies | | --- | --- | | **Integrity** | Write-once storage, or verifiable timestamped hashes | | **Timestamping** | Proof of the date of existence — a signing infrastructure's transparency log answers this well | | **Access traceability** | Audit log: who consulted, who deposited, who extracted | | **Separation of duties** | No one can produce, approve and modify | | **Long-term readability** | Standardised formats, no dependency on a proprietary tool | | **Portability** | The ability to migrate the whole set to another medium without loss | | **Indexing** | Finding the file for a specific version, ten years later, within hours | ### The most frequently missed point It is neither storage nor duration: it is the **ability to retrieve**. Keeping files is easy. Finding, in 2038, the exact technical documentation for version 4.2.1 placed on the market in 2028, with its SBOM, its VEX statements, its signed declaration and the key needed to verify that signature, requires an indexing chain that will have survived two platform changes and three generations of staff. ### The annual retrieval exercise It is the only control that proves anything. **Protocol:** 1. Draw at random a version shipped more than two years ago. 2. With no preparation, ask the team to produce, **within one working day**: the frozen technical documentation, the signed declaration, the signed SBOM with its signature verified, the associated VEX statements, the reporting register for that product, and the user notice shipped. 3. Time it, record the difficulties, fix them. 4. Write a report and file it with the governance record. A failed exercise is not an incident: it is the most useful information of the year. An exercise never run means you do not know whether the arrangement works. ### Interaction with the GDPR A ten-year retention period must remain **justified** against the storage limitation principle. Two precautions: - keep in the evidence vault only what is **necessary for CRA compliance** — technical documentation has no business containing personal data; - document the **basis** for that duration in the record of processing activities, citing the legal obligation. ### Deletion At the end of the period, deletion must be **effective and logged**: an audit log entry stating what was deleted, when, and on what basis. Keeping data beyond the necessary period, with no decision, is the mirror image of insufficient retention. ## Exposure and risk register URL: https://cra-reference.eu/en/legal/exposure/ Description: Quantifying administrative, commercial and contractual exposure; keeping a compliance risk register; anticipating the effect on acquisition due diligence. Audience: direction Legal basis: Art. 64 — penalties · Chapter V — market surveillance measures Published 2026-08-19, updated 2026-08-19 The scale is set out in [Penalties](/en/cra/penalties/). This page turns it into a number, and then into a register. ### The three exposures #### 1. Administrative exposure The higher of **EUR 15,000,000** and **2.5 % of total worldwide annual turnover** for the preceding financial year, for breaches of the essential requirements and of the Article 13 and 14 obligations. The calculation to put to the committee: ``` Administrative exposure = max(EUR 15,000,000 ; 0.025 × consolidated worldwide turnover FY-1) ``` That figure is a **ceiling**, not a forecast. It sizes the effort; it does not predict a fine. #### 2. Commercial exposure Often an order of magnitude larger, and faster to materialise. ``` Commercial exposure = (turnover made in the Union / 12) × duration in months of a prohibition on making available, or of a withdrawal ``` Add the cost of a **recall** where the product is hardware: logistics, replacement, communications. #### 3. Contractual exposure Penalties, regulatory compliance clauses, termination rights and indemnities in your customer contracts. This exposure is read in the contracts, not in the Regulation, and it is often the most immediate: a large account may suspend a contract long before an authority acts. ### The compliance risk register Kept by Legal, reviewed at every committee. One row per identified risk: | Column | Content | | --- | --- | | Risk | Phrased as an event, not as a gap | | Products affected | With their share of turnover | | Cause | Technical, organisational or documentary shortfall | | Likelihood | Four-point scale, with written criteria | | Impact | The three exposures above | | Measures in progress | With owner and deadline | | Residual risk | After measures | | Decision | Treat, reduce, transfer, **accept** — with the name of whoever accepts | The "accept" column is essential: a risk accepted by an identified person is not an ignored risk. It also protects the teams where a budget trade-off was made knowingly. ### Typical rows | Risk | Cause | Measure | | --- | --- | --- | | Unable to produce the technical documentation for a version shipped in 2028 during a 2033 inspection | Archiving never tested | Annual retrieval exercise | | Missing the 24-hour deadline over a weekend | No legal on-call cover | Written delegation + on-call rota | | A class II product with no notified body engaged | Market capacity saturated | Contract immediately | | An untenable support period on a product built on an abandoned upstream component | Insufficient diligence at integration | Replacement or take-over plan | | An AGPL component in an online offering | Licence policy not enforced in CI | CI blocking + audit of the existing estate | ### The effect on corporate transactions The CRA has become a standard item in **acquisition due diligence** and fundraising. An acquirer will ask for: - the portfolio **classification register**; - the existence and completeness of the **technical documentation**; - the **reporting register** and compliance with deadlines; - the **support period register** and the commitments attached; - **licence compliance**, with the exception register. A gap on any of these translates into a liability warranty, a price holdback or a condition precedent. It is a funding argument in its own right, and often the most effective one with a committee. ## Intellectual property and licensing URL: https://cra-reference.eu/en/legal/intellectual-property/ Description: The licence policy enforced in CI, the exception process, the register, attribution deliverables and preparing for customer audits. Audience: legal Published 2026-08-19, updated 2026-08-19 The substance is covered elsewhere: the [licence families](/en/licensing/families/) and what they require, the [mechanisms that trigger an obligation](/en/licensing/triggers/), the [verdict by product type](/en/licensing/scenarios/) and the [pitfalls](/en/licensing/pitfalls/) the grid does not capture. Licensing as SBOM data is in [Licensing as SBOM data](/en/sbom/spdx-licences/). This page describes **the arrangement**: the policy, the process, the register and the deliverables. ### Why this is a CRA workstream The CRA does not require licence compliance. But it requires an SBOM, and a properly populated SBOM makes licence compliance **automatable for the first time**. That is a major side benefit, and the argument that lets the tooling be funded from two budgets rather than one. ### The licence policy Three lists, broken down by **context of use**: | Context | What changes | | --- | --- | | **Product distributed** to customers | The strictest: strong copyleft is denied | | **Online service** | **Network** copyleft (AGPL) becomes blocking | | **Internal tool**, not distributed | The most permissive: most obligations are not triggered | | **Test code**, not shipped | A lighter regime, still monitored | The policy is a **versioned** document, approved, with an effective date. It is published to the teams and **enforced by the build chain**, not merely displayed. ### The process, end to end 1. **Detection.** The SBOM carries the licences; the platform matches them against the policy. 2. **Automatic decision.** Allow list: the build passes. Deny list: the build **fails**. Review list: warning and a ticket. 3. **Analysis.** Engineering documents the component's introduction path and actual use, and proposes an option: replace, isolate, or request an exception. 4. **Legal decision.** Legal rules, with conditions and an **expiry date**. 5. **Recording.** Entry in the exception register, timestamped. 6. **Re-examination.** At expiry, or earlier if the context changes. ### The exception register | Column | Content | | --- | --- | | Component and version | Identified by `purl` | | Licence | Full SPDX expression | | Product and context | Where the exception applies | | Reason for the request | No alternative, migration cost, criticality | | Conditions | Technical isolation, no distribution, enhanced attribution | | **Expiry date** | Mandatory | | Decider | Name and function | | Status | Active, expired, revoked | An exception with no expiry date becomes an unwritten rule. That is the main defect observed in existing arrangements. ### Deliverables | Deliverable | When | Generated from | | --- | --- | --- | | **Attribution file** (`NOTICE`) shipped with the product | Every version | The SBOM | | **Written offer to provide source code** | Where a copyleft component requires it | The register | | **Compliance report** for a customer | On request | The SBOM + the register | | **Portfolio inventory by licence** | Quarterly | The platform | The attribution file is the most frequent and most easily fixed breach: its generation must be **automatic** and its presence **checked in CI**. ### Preparing for audits Requests come from three sources: large-account customers, investors in a transaction, and acquirers. They always cover the same points: - the existence of a written and enforced licence **policy**; - the **completeness** of the inventory, transitive dependencies included; - **consistency** between the inventory and the attributions shipped; - the treatment of **licences with strong obligations**; - the **exception register** and how it is kept. Answering these is instantaneous where the arrangement exists, and takes several weeks where it does not. It is the best indicator of real maturity. ### The friction point to resolve An intellectual property policy forbidding employees from publishing code conflicts directly with the Regulation's obligation to **report security fixes upstream** — see [Integrating open source](/en/cra/open-source/integrating-oss/). The two policies must be reconciled in writing, with a contribution procedure light enough to be compatible with a fix deadline of a few days. ## Pre-market checklist URL: https://cra-reference.eu/en/legal/placing-checklist/ Description: Fifteen points, one page, printable and signable. The document that gives Legal's veto over commercialisation its substance. Audience: legal Legal basis: Art. 13, 28, 30, 31 · Annexes I, II, V, VII Published 2026-08-19, updated 2026-08-19 To print, complete in the conformity review session, sign and archive with the technical documentation. No point may remain open when the marking is affixed. **Product:** ______________________ **Exact version:** ______________________ **Review date:** ____________ **Planned market entry:** ____________ --- ### Scope and classification - [ ] **1.** The product is qualified as a **PDE**; the qualification sheet is signed and filed. → [Scope](/en/cra/scope-pde/) - [ ] **2.** **Exclusions** have been examined and ruled out, or a reasoned exclusion sheet exists. → [Exclusions](/en/cra/exclusions/) - [ ] **3.** The **criticality class** is determined and justified by a co-signed classification sheet. → [Classes](/en/cra/criticality-classes/) ### Conformity route - [ ] **4.** The **assessment route** is chosen and documented; where a notified body is required, it is engaged and its **certificate** is in the file. → [Assessment](/en/cra/conformity-assessment/) ### Essential requirements - [ ] **5.** The **cybersecurity risk assessment** is carried out, dated, signed, and justifies the requirements ruled out. - [ ] **6.** The applicable **Annex I, Part I** requirements are covered; the traceability matrix is complete. → [Product security](/en/cra/essential-requirements/product-security/) - [ ] **7.** The Annex I, Part II **vulnerability handling** process is operational and documented. → [Vulnerability handling](/en/cra/essential-requirements/vulnerability-handling/) ### Bill of materials and disclosure - [ ] **8.** The **SBOM** for this exact version is generated, validated above the quality threshold, signed and archived. → [SBOM](/en/sbom/) - [ ] **9.** The **coordinated disclosure policy** is published and the **contact point** is live and tested. → [Disclosure policy](/en/cyber/disclosure-policy/) ### Life cycle and information - [ ] **10.** The **support period** is determined, justified in the file, approved by executive management and **communicated to the buyer** to the month. → [Support](/en/legal/support-commitments/) - [ ] **11.** The **Annex II information and instructions to the user** are drafted, translated and shipped with the product. → [User information](/en/legal/user-information/) ### File and declaration - [ ] **12.** The **Annex VII technical documentation** is complete; its version is frozen and referenced. → [Technical documentation](/en/cra/technical-documentation/) - [ ] **13.** The **Annex V EU declaration of conformity** is drawn up, accurate and signed by an authorised person. → [Declaration](/en/legal/declaration-of-conformity/) ### Operational - [ ] **14.** The **24 h / 72 h / 14 d reporting** procedure is in place, the on-call rota is designated and the channel has been tested for this product. → [Reporting](/en/legal/reporting-duties/) - [ ] **15.** **Ten-year archiving** is configured for every item, and retrieval has been tested. → [Retention](/en/legal/evidence-retention/) --- ### Decision - [ ] **Authorisation to affix the CE marking and place the product on the market.** - [ ] **Refused** — reasons and remediation deadlines: _______________________________________________________________________ **Accepted reservations** (open points, with owner and resolution date): _______________________________________________________________________ | Role | Name | Signature | Date | | --- | --- | --- | --- | | Legal department | | | | | CISO | | | | | Product management | | | | --- > **Reminder.** This checklist is not paperwork: it is the record that will demonstrate, in an > inspection, that conformity was verified **before** placing on the market. A signed checklist > with boxes ticked incorrectly is more damaging than an honest one carrying reservations. ## Reporting duties: the legal decision URL: https://cra-reference.eu/en/legal/reporting-duties/ Description: When the 24-hour clock starts, who decides, how to document the decision to report or not, and how to organise legal on-call cover. Audience: legal Legal basis: Art. 14 — reporting obligations · Art. 15 — voluntary reporting Published 2026-08-19, updated 2026-08-19 The operational run-through is in [24 h / 72 h / 14 d procedure](/en/cyber/24h-runbook/) and the legal framework in [Reporting to ENISA](/en/cra/enisa-reporting/). This page covers three legal questions: **when**, **who**, and **how to prove it**. ### When does the clock start? The 24-hour period runs from the moment the manufacturer **becomes aware** of the actively exploited vulnerability or the severe incident. "Becoming aware" is neither the first tool alert nor the conclusion of a full forensic analysis. It is the moment the organisation holds **sufficiently serious elements** to characterise the facts. In practice an internal rule is needed: > **Your rule.** The clock starts at the moment a credible indication of active exploitation > reaches a person holding a security function — PSIRT, on-call, second-line support — whether > that indication is internal or external. The timestamp of that receipt is recorded and > governs. Setting a rule more restrictive than necessary is risky: an authority will assess awareness against what the organisation **ought** to have known given the information it held. ### How to qualify active exploitation The criterion is **reliable evidence** that a malicious actor has exploited the vulnerability in a system without the permission of its owner. | Element | Sufficient on its own? | | --- | --- | | Publication of a proof-of-concept exploit | **No** | | High severity score | **No** | | Listing in a public catalogue of exploited vulnerabilities | **Strong indicator**, to be matched against whether you carry the component | | Consistent indicators of compromise in a customer's logs | **Yes** | | Forensic analysis establishing exploitation | **Yes** | | A credible, circumstantial report from a CERT or a customer | **Yes**, subject to quick verification | Technical qualification belongs to the PSIRT; the **decision to report** belongs to Legal. The PSIRT must pass its qualification on within a short window — you set **two hours** — to leave Legal time to decide. ### Who decides Three roles, to be named and backed up: | Role | Function | Deputy | | --- | --- | --- | | **Qualifier** | Establishes the technical facts | Head of PSIRT | | **Decider** | Decides whether to report | General counsel, or a holder of a written delegation | | **Submitter** | Drafts and sends via the platform | PSIRT, with the decider's approval | The **written delegation** is essential: a 24-hour deadline does not accommodate an approval chain reaching executive management over a weekend. ### The default decision rule Where serious doubt persists after qualification: **report**. The reasoning is asymmetric. The Regulation expressly provides for [voluntary reporting](/en/cra/enisa-reporting/), which **imposes no additional obligation**. The cost of a report that was not strictly required is therefore nil in law. The cost of a missed report falls under the highest penalty ceiling. This rule must be written down and known to the on-call team; otherwise the default decision will, in practice, be inaction. ### Documenting the decision This is the central defensive record. Every qualified event produces a register entry, **whether or not you reported**: | Field | Content | | --- | --- | | Timestamp of awareness | Date, time, channel, person who received it | | Facts | Description of the triggering element | | Products and versions affected | List, with estimated installed base | | Qualification | Active exploitation: yes / no / undetermined, with the elements relied on | | **Decision** | Report / do not report / report voluntarily | | **Reasoning** | The argument, not just the conclusion | | Decider | Name and function | | Timestamp of the decision | Time elapsed since awareness | | Submissions | Early warning, notification, final report: dates and acknowledgements | | User notification | Date, channel, content | A register containing only reported events is suspect: it implies no negative decision was ever taken, which is implausible. ### Legal on-call cover A 24-hour deadline spans nights, weekends and public holidays. That requires: - a legal **on-call rota**, or failing that a standing delegation to an available function; - **pre-filled templates** carrying your company identifiers, so drafting is not the bottleneck; - **live named access** to the reporting platform for on-call staff, tested and unexpired; - an **escalation procedure** if the decider cannot be reached, with a maximum delay before switching to the deputy. ### The three regimes in parallel One event may fall under the CRA, NIS 2 and the GDPR. The comparison table is in [Interplay with other legislation](/en/cra/interplay/). The crisis cell must rule on all three **simultaneously**, with three distinct templates — handling them in sequence mechanically overruns the shortest deadline. ## Turning the support period into commitments URL: https://cra-reference.eu/en/legal/support-commitments/ Description: From the text of the Regulation to the terms and conditions: the mandatory statement to buyers, desynchronisation with suppliers, end-of-life policy and the register. Audience: legal Legal basis: Art. 13(8) · Annex II, point 8 Published 2026-08-19, updated 2026-08-19 The rule is set out in [Support period and life cycle](/en/cra/support-period/). This page covers its contractual and commercial translation. ### What goes where | Medium | Content | | --- | --- | | **Product documentation** (Annex II) | Type of security technical support offered and the **end date of the support period**, at least the month and year, in clear and understandable terms | | **Datasheet and product page** | The same date, visible **at the time of purchase** | | **Terms and conditions** | What security support covers and does not cover, and how fixes are made available | | **Technical documentation** | The duration chosen **and its justification** | | **Internal register** | The consolidated view, with limiting dependencies | ### Drafting the statement It must be understandable to a non-specialist buyer. A standard wording: > **Security support.** This product receives security updates until **[month year]**. During > that period, security fixes are provided free of charge and, where technically feasible, > distributed separately from functional updates. After that date no new fixes will be > produced; fixes already published remain downloadable until **[month year]**. The two dates are distinct and both must appear: the end of fix **production**, and the end of their **availability**. ### Desynchronisation with upstream The structural problem: you commit five years to your customers, on a product built from components whose upstream support ends earlier. | Situation | Options | | --- | --- | | Commercial third-party component whose support ends before yours | Negotiate extended support; plan a migration; shorten your commitment | | Abandoned free component | Fork and maintain, replace, bring in-house — see [Integrating open source](/en/cra/open-source/integrating-oss/) | | Underlying operating system or platform reaching end of life | Plan the migration, or align your end of support | Each option has a cost, which must be **provisioned when the decision to integrate the component is taken**, not discovered three years later. That is why "upstream support duration" appears in the diligence grid. ### Free of charge Security fixes are **free of charge** during the support period, except where otherwise agreed for tailor-made products between businesses. Direct commercial consequence: **a maintenance contract cannot condition access to security fixes**. It may cover functional support, upgrades, assistance, guaranteed response times — not the security fixes themselves. Existing offerings must be reviewed on that basis. For some vendors it is a business model question, and it should be treated as one. ### End-of-life policy To be written once and applied to every product: 1. **Announce** the end of support, with a defined notice period — twelve months is reasonable for a professional product. 2. **Remind** at regular intervals during the notice period, through every available channel. 3. Offer a **migration path**: successor product, procedure, support. 4. Publish the **last update**, with the list of known unfixed vulnerabilities. 5. State the **residual risk** of use after the end of support. 6. **Keep published fixes available** until the date owed. 7. **Archive** the technical documentation and the SBOM for the remaining period. ### On cessation of operations The Regulation provides that a manufacturer ceasing operations informs the **market surveillance authorities** and, **by any means available**, the **users** of the products concerned. It also encourages transferring the source code or publishing it as free software so maintenance can continue. These provisions must be anticipated in your articles and liquidation procedures: it is too late to arrange them once cessation has been decided. ### The register The table to keep is in [Support period and life cycle](/en/cra/support-period/). It is reviewed at every committee, because it reveals commitments that have become untenable — and the only moment to correct them at no cost is **before** they are made. ## Information and instructions to the user (Annex II) URL: https://cra-reference.eu/en/legal/user-information/ Description: The ten mandatory items to supply with the product, the cybersecurity notice template, language requirements and the retention period. Audience: legal Legal basis: Annex II — information and instructions to the user · Art. 13 — obligations of the manufacturer Published 2026-08-19, updated 2026-08-19 Annex II is short, often overlooked, and breaching it is **formal non-compliance** immediately observable by an authority that buys the product off the shelf. It is the cheapest inspection to run, and therefore the most likely. ### The mandatory items Supplied with the product, in a **language easily understood** by users and market surveillance authorities. 1. **Name, registered trade name or registered trademark of the manufacturer**, postal address, email address or other digital contact, and where applicable a website. 2. A **single point of contact** for reporting vulnerabilities and receiving information in return, with an indication of where it is located. 3. **Name and type of the product**, with traceability elements: reference, version. 4. **Intended purpose**, including the **intended security environment**, and the **main security features**. 5. Any **known or foreseeable circumstance** related to the use of the product in accordance with its intended purpose, or under conditions of reasonably foreseeable misuse, that may lead to a cybersecurity risk. 6. Where applicable, the **internet address at which the EU declaration of conformity** can be accessed. 7. The **type of security technical support** offered and the **end date of the support period**, at least the month and year, in a clear and understandable manner. 8. **Detailed instructions** — or the internet address pointing to them — covering: security measures at commissioning and during operation, the effect of configuration changes, how to install updates securely, secure decommissioning, data retention and reset. 9. Where the product supports **automatic updates**, information on the mechanism and on the **ability to disable it**. 10. Where applicable, an indication of where the **software bill of materials (SBOM)** can be obtained. ### Cybersecurity notice template To adapt per product, in two pages. ``` CYBERSECURITY NOTICE — Acme Gateway AG-4200, version 4.2.x 1. MANUFACTURER [Legal name], [full postal address] [email] — [website] 2. REPORTING A VULNERABILITY Contact point: psirt@[domain] — [country where the contact point is located] Disclosure policy: [URL] Public encryption key: [URL] 3. PRODUCT IDENTIFICATION Name, reference, versions covered by this notice. 4. INTENDED PURPOSE AND SECURITY ENVIRONMENT The product is designed for [use]. It assumes an environment in which [assumptions: segmented network, controlled physical access, etc.]. Main security features: [list]. 5. KNOWN RISKS AND DISCOURAGED USES [Circumstances that may lead to a risk, including reasonably foreseeable misuse.] 6. EU DECLARATION OF CONFORMITY Available at: [URL] 7. SECURITY SUPPORT Security updates provided until: [month year] Published fixes remain available until: [month year] Nature of support: [description] 8. INSTRUCTIONS Secure commissioning: [URL or text] Effects of configuration changes: [URL or text] Installing updates: [URL or text] Secure decommissioning and data erasure: [URL or text] Reset to original state: [URL or text] 9. AUTOMATIC UPDATES Enabled by default: yes / no. Mechanism: [description]. Disabling: [procedure]. Consequences of disabling: [text]. 10. SOFTWARE BILL OF MATERIALS (SBOM) Available: [portal URL / on request at …] / not disclosed. ``` ### Watch points **Location of the contact point.** The Annex requires stating **where** the contact point is located. An email address alone is not enough: the country must be given. **"Language easily understood".** For pan-European distribution that implies a translation chain and a consistency check across language versions. Member States may require their own language. **Format.** The notice may point to an internet address for detailed instructions, but **the main items must accompany the product**. A wholesale redirect to a website is not compliant, and a link that stops working once the product is off the market is less so. **Consistency.** Three pieces of information circulate across several documents at once: the end-of-support date, the contact point, the address of the declaration. They must be generated from a **single source**, or they will diverge. ### Retention The information and instructions must remain available for **at least ten years after placing on the market, or the support period if longer** — like the technical documentation. That means a URL cited in a 2028 notice must still respond in 2038. A persistent-URL policy is therefore a compliance matter, not merely a communications one. ## Open source licensing URL: https://cra-reference.eu/en/licensing/ Description: The families of free software licences, what actually triggers their obligations, and nine real distribution scenarios — from SaaS backend to connected device — with the verdict per family. Audience: transverse Legal basis: Art. 13(5) — due diligence on third-party components · Annex I, Part II, point 1 — component inventory Published 2026-08-20, updated 2026-08-20 ### The one idea to hold on to > **A licence is never a problem in the abstract. It is a problem in a scenario.** The same library under AGPL-3.0 is **harmless** in an internal tool and **fatal** in a SaaS backend. The same library under GPL-3.0 is **unremarkable** on a desktop and **blocking** in a locked-down connected device. A CC-BY-NC asset is irrelevant in a mock-up and **prohibited** in a product you sell. What triggers an obligation is not the licence's name: it is **what you do with the software** — do you distribute it? to whom? in what form? do you expose it over a network? can the user replace the component? That is why this section is built as a **matrix**: the [licence families](/en/licensing/families/) on one axis, the [distribution scenarios](/en/licensing/scenarios/) on the other, and [what connects them](/en/licensing/triggers/) in between. ### The matrix, on one page Key: **●** no difficulty · **◐** conditional, needs review · **○** avoid · **✕** incompatible in practice. | Scenario | Permissive | Weak copyleft, file | Weak copyleft, library | Strong copyleft | Network copyleft | Source-available | | --- | :--: | :--: | :--: | :--: | :--: | :--: | | | MIT, Apache-2.0 | MPL-2.0, EPL-2.0 | LGPL-2.1/3.0 | GPL-2.0/3.0 | AGPL-3.0 | BSL, SSPL, ELv2 | | [Worst case](/en/licensing/scenarios/worst-case/) | ● | ◐ | ○ | ○ | ✕ | ✕ | | [SaaS backend](/en/licensing/scenarios/saas-backend/) | ● | ● | ● | ● | **✕** | ○ | | [Web frontend](/en/licensing/scenarios/web-frontend/) | ◐ | ◐ | ○ | ✕ | ✕ | ✕ | | [Desktop / CLI app](/en/licensing/scenarios/desktop-cli/) | ● | ● | ◐ | ◐ | ○ | ✕ | | [Mobile app](/en/licensing/scenarios/mobile-app/) | ● | ● | ○ | **✕** | ✕ | ✕ | | [Library / SDK](/en/licensing/scenarios/library-sdk/) | ● | ◐ | ○ | ○ | ○ | ✕ | | [On-premises](/en/licensing/scenarios/on-premises/) | ● | ● | ◐ | ◐ | ○ | ✕ | | [Embedded / IoT](/en/licensing/scenarios/embedded-iot/) | ● | ● | ○ | **○ v2 / ✕ v3** | ✕ | ✕ | | [Internal tool](/en/licensing/scenarios/internal-tool/) | ● | ● | ● | ● | ◐ | ◐ | Every cell is explained on the corresponding scenario page. The symbols do not replace the reading: a **◐** can hide a heavy engineering constraint, and a **●** never removes the attribution duty. ### What this section is not It **does not replace legal advice**. Free software licensing rests on copyright, which is national; the notion of a "derivative work" has **no settled European case law** for software, and the positions taken by licence authors — on linking in particular — are not binding law. Where a question is contested, the page says so. It also **does not cover your internal process**: the licence policy, the allow / review / deny lists, the exception register and the attribution deliverables are in [Intellectual property](/en/legal/intellectual-property/). ### How this relates to the CRA Regulation (EU) 2024/2847 **does not require** licence compliance. It makes it measurable, and it turns it into a diligence matter: - the **mandatory inventory** (Annex I, Part II, point 1) carries licence identifiers: for the first time, legal compliance becomes computable across the portfolio; - **due diligence on third-party components** (Art. 13(5)) includes examining the licence, alongside maintenance and security history; - the duty to **report fixes upstream** (Art. 13(6)) presupposes a contribution policy that allows your engineers to publish code; - the **five-to-ten-year support period** requires keeping the corresponding source and the build chain — exactly what the GPL requires anyway. Put differently: CRA compliance work and licence compliance work share their artefacts. Running them separately means paying for them twice. ### Where to start - New to the topic: [The licence families](/en/licensing/families/). - To understand why one licence changes nature with the context: [What triggers an obligation](/en/licensing/triggers/). - You have a specific product in mind: go straight to the matching [scenario](/en/licensing/scenarios/). - Looking for what the matrix does not show: [Pitfalls](/en/licensing/pitfalls/). ## The licence families URL: https://cra-reference.eu/en/licensing/families/ Description: Public domain, permissive, weak copyleft by file or by library, strong copyleft, network copyleft, source-available, content licences: what each one actually requires. Audience: transverse Published 2026-08-20, updated 2026-08-20 There are hundreds of licences; the SPDX list catalogues more than six hundred. But they fall into **eight families**, and within a family the obligations are nearly identical. Knowing the eight covers 99 % of cases. ### Overview | Family | Reciprocity | What it requires | Representatives | | --- | --- | --- | --- | | **1. Public domain** | None | Nothing, or nearly | CC0-1.0, Unlicense, 0BSD | | **2. Permissive** | None | Attribution, preserve notices | MIT, BSD, Apache-2.0, ISC | | **3. Weak copyleft — file** | Per modified file | Publish modified files | MPL-2.0, EPL-2.0, CDDL | | **4. Weak copyleft — library** | Per library | Publish the library, allow replacement | LGPL-2.1, LGPL-3.0 | | **5. Strong copyleft** | Whole work | Publish the source of the distributed derivative | GPL-2.0, GPL-3.0, CeCILL | | **6. Network copyleft** | Whole work, network included | Same, even without distribution | AGPL-3.0, OSL-3.0, EUPL-1.2 | | **7. Source-available** | Varies | Usage restrictions — **not open source** | BSL-1.1, SSPL-1.0, ELv2 | | **8. Content and data** | Varies | A regime of its own for non-software works | CC-BY, CC-BY-SA, OFL, ODbL | --- ### 1. Public domain and dedication **[CC0-1.0](https://spdx.org/licenses/CC0-1.0.html)**, **[Unlicense](https://spdx.org/licenses/Unlicense.html)**, **[0BSD](https://spdx.org/licenses/0BSD.html)**, **WTFPL**. The author waives their rights or grants a maximally permissive licence. No attribution due. **The trap**: **CC0 expressly excludes any patent grant**. A CC0 component whose author holds a patent protects you from nothing. Several foundations restrict its use for that reason and prefer a permissive licence with a patent clause. Under French and German law, an outright waiver of moral rights is also ineffective — of no practical consequence in general, but it explains why some lawyers prefer MIT to CC0. --- ### 2. Permissive **[MIT](https://spdx.org/licenses/MIT.html)**, **[BSD-2-Clause](https://spdx.org/licenses/BSD-2-Clause.html)**, **[BSD-3-Clause](https://spdx.org/licenses/BSD-3-Clause.html)**, **[ISC](https://spdx.org/licenses/ISC.html)**, **[Apache-2.0](https://spdx.org/licenses/Apache-2.0.html)**, **[Zlib](https://spdx.org/licenses/Zlib.html)**, **[BSL-1.0](https://spdx.org/licenses/BSL-1.0.html)** (Boost), **[CECILL-B](https://spdx.org/licenses/CECILL-B.html)**. Do what you like, including embedding in proprietary software, provided you **preserve the copyright notices and the licence text** and pass them on to recipients. #### What separates them | Licence | Distinctive feature | | --- | --- | | **MIT**, **ISC** | The shortest. Attribution, nothing more. | | **BSD-2-Clause** | Equivalent to MIT. | | **BSD-3-Clause** | Adds a **non-endorsement** clause: you may not use the authors' names to promote your product. | | **BSD-4-Clause** | Adds an obsolete **advertising clause**: every advertisement must credit the author. Unmanageable at scale, and **GPL-incompatible**. Refuse it. | | **Apache-2.0** | **Express patent grant**, **automatic termination** of that grant if you bring patent litigation against a contributor over the software, and a duty to flag modified files. A `NOTICE` file to propagate where one exists. | > **Why Apache-2.0 is often the best choice.** It is the only common permissive licence that > addresses patents explicitly. For a product you sell, that is real protection MIT does not > offer. **The incompatibility to know**: on the [Free Software Foundation's reading](https://www.gnu.org/licenses/license-list.html), **Apache-2.0 is incompatible with GPL-2.0-only** (the patent and indemnity clauses count as further restrictions) but **compatible with GPL-3.0**. That is why many projects moved to `GPL-2.0-or-later`. **The real risk of permissive licences** is operational, not legal: **the forgotten attribution file**. It concerns hundreds of components, it generates automatically from the SBOM, and its absence is the most frequent and most easily fixed breach in the field. --- ### 3. Weak copyleft, at **file** granularity **[MPL-2.0](https://spdx.org/licenses/MPL-2.0.html)**, **[EPL-2.0](https://spdx.org/licenses/EPL-2.0.html)**, **[CDDL-1.0](https://spdx.org/licenses/CDDL-1.0.html)**, **[CECILL-C](https://spdx.org/licenses/CECILL-C.html)**. Reciprocity attaches to **the files themselves**. Modify a file under MPL-2.0 and that file stays MPL-2.0 and must be published. The rest of your project, including the files that call it, may remain proprietary. This is the most **workable** family: it protects upstream without contaminating your code. | Licence | Distinctive feature | | --- | --- | | **MPL-2.0** | The reference model. Patent clause. GPL-compatible through an explicit clause, unless the author disabled it. | | **EPL-2.0** | Comparable reciprocity. An optional "secondary licence" clause enables GPL compatibility, at the author's choice. | | **CDDL-1.0** | **GPL-incompatible**, and that incompatibility is why ZFS is not merged into the Linux kernel. Treat as a special case. | **The trap**: "per file" assumes you know **which files were modified**. Copy-pasting an MPL function into one of your proprietary files moves *your* file under MPL. File separation is therefore an engineering discipline, not a formality. --- ### 4. Weak copyleft, at **library** granularity **[LGPL-2.1](https://spdx.org/licenses/LGPL-2.1-only.html)**, **[LGPL-3.0](https://spdx.org/licenses/LGPL-3.0-only.html)**. The library stays free; the work that uses it may stay proprietary. But on one condition, often misread: > **The end user must be able to replace the library with a modified version of their choosing > and have your program run with it.** That is what makes **dynamic linking** natural and **static linking** expensive: statically, you must supply your application's object files so the user can relink themselves, or any equivalent means. | Version | Distinctive feature | | --- | --- | | **LGPL-2.1** | The classic regime. No anti-lock-down clause. | | **LGPL-3.0** | Inherits the **GPL-3.0** clauses: patents, anti-DRM, and above all **installation information** for consumer products. Far more constraining in embedded and mobile. | **The trap**: in ecosystems where dynamic linking does not exist — a JavaScript bundle, a Go binary, a Rust executable, a mobile app — the LGPL must be treated **as strong copyleft**, because the replacement condition is in practice impossible to satisfy. --- ### 5. Strong copyleft **[GPL-2.0-only](https://spdx.org/licenses/GPL-2.0-only.html)**, **[GPL-2.0-or-later](https://spdx.org/licenses/GPL-2.0-or-later.html)**, **[GPL-3.0-only](https://spdx.org/licenses/GPL-3.0-only.html)**, **[GPL-3.0-or-later](https://spdx.org/licenses/GPL-3.0-or-later.html)**, **[CeCILL](https://spdx.org/licenses/CECILL-2.1.html)** (the French equivalent, GPL-compatible). If you **distribute** a binary containing GPL code — or a work derived from it — you must give every recipient the **corresponding source** of the whole work, under the same licence, including build and installation scripts. The decisive word is **distribute**: the GPL is triggered only by conveying to a third party. Purely internal use, or running the software on your own servers, does not trigger it — see [SaaS backend](/en/licensing/scenarios/saas-backend/). #### `only` versus `or-later` The suffix is not cosmetic: it determines whether the recipient may apply a later version of the licence. - `GPL-2.0-only`: frozen at version 2. **Incompatible** with GPL-3.0 components. - `GPL-2.0-or-later`: the recipient may choose version 3, restoring compatibility. - A project with no explicit statement is conventionally read as `-or-later` — but the question has been litigated. Document what you observe; do not presume. #### What GPL-3.0 adds to GPL-2.0 | Addition | Effect | | --- | --- | | Explicit **patent grant** | Real protection, absent from v2 | | **Anti-lock-down clause** ("Installation Information") | For a **consumer product**, you must supply what is needed to install a modified version. See [Embedded / IoT](/en/licensing/scenarios/embedded-iot/) | | **Anti-DRM clause** | The software must not be invoked as a technological protection measure | | **Apache-2.0 compatibility** | Resolves the v2 incompatibility | | **Termination with a cure period** | A violation cured within 30 days of notice no longer permanently forfeits rights | #### Exceptions Some projects attach an **exception** that narrows the GPL's reach. In SPDX these use the `WITH` operator: | Exception | Effect | | --- | --- | | [`GPL-2.0-only WITH Classpath-exception-2.0`](https://spdx.org/licenses/Classpath-exception-2.0.html) | Used by OpenJDK: linking does not create a derivative work. It is what makes proprietary Java possible. | | [`GPL-3.0-only WITH GCC-exception-3.1`](https://spdx.org/licenses/GCC-exception-3.1.html) | Code compiled by GCC is not contaminated by the runtime libraries. | | [`Apache-2.0 WITH LLVM-exception`](https://spdx.org/licenses/LLVM-exception.html) | Lifts an attribution constraint on generated code. | | [`GPL-2.0-only WITH Autoconf-exception-2.0`](https://spdx.org/licenses/Autoconf-exception-2.0.html) | Generated scripts are not contaminated. | **Never read a GPL licence without checking for an exception**: it changes the verdict entirely. --- ### 6. Network copyleft **[AGPL-3.0](https://spdx.org/licenses/AGPL-3.0-only.html)**, **[OSL-3.0](https://spdx.org/licenses/OSL-3.0.html)**, **[EUPL-1.2](https://spdx.org/licenses/EUPL-1.2.html)** (on its broadest reading), **RPL**. Designed to close what is known as the "service provider loophole": the GPL triggers only on distribution, and an online service distributes nothing. **AGPL-3.0, section 13**: if you **modify** the program and users interact with your modified version **remotely over a network**, you must offer them the corresponding source of your version. #### The nuance that matters Read literally, the obligation targets the **modified** version. Running strictly **unmodified** AGPL software as a service does not trigger section 13. In practice the exception almost never applies: as soon as you **combine** the AGPL component with your own code — a library call is enough to raise the combined-work question — the whole becomes "your version", and it is the whole whose source must be offered. > **The prudent position**, and the one most corporate policies take: **treat any AGPL component > present in an exposed service as triggering the obligation**, and reserve the literal reading > for a strictly unmodified component, isolated in its own process, and documented as such. **EUPL-1.2** deserves a mention on a European site: it is the Union's own licence, its copyleft extends to making the work available over a network, and above all it carries a **compatibility clause** listing the licences the work may be relicensed to (GPL, AGPL, MPL, EPL, CeCILL, LGPL…). That clause makes it an interesting choice for a European public project. --- ### 7. Source-available — not open source **[BSL-1.1](https://mariadb.com/bsl11/)** (Business Source License), **[SSPL-1.0](https://www.mongodb.com/legal/licensing/server-side-public-license)**, **[Elastic License 2.0](https://www.elastic.co/licensing/elastic-license)**, **Confluent Community License**, **Redis Source Available License**, the **[PolyForm](https://polyformproject.org/)** family, and the **[Commons Clause](https://commonsclause.com/)** rider. The code is readable, sometimes modifiable, but **use is restricted**. None is approved by the [Open Source Initiative](https://opensource.org/osd). **Treat them as proprietary software**: they belong to contract negotiation, not to open source policy. | Licence | Principal restriction | | --- | --- | | **[BSL-1.1](https://mariadb.com/bsl11/)** | Production use restricted, save for an "additional use grant". Automatically converts to an open source licence on a **change date**, typically four years out. | | **[SSPL-1.0](https://www.mongodb.com/legal/licensing/server-side-public-license)** | If you offer the software **as a service**, you must publish that service's entire source — orchestration, backup, monitoring, interfaces. Prohibitive in practice. | | **[Elastic License 2.0](https://www.elastic.co/licensing/elastic-license)** | Prohibits providing the product as a **managed service**, circumventing licence keys, and removing notices. | | **[Commons Clause](https://commonsclause.com/)** | Not a licence but an **addendum** grafted onto a free licence, removing the right to sell. A library under "MIT + Commons Clause" is not MIT. | **The real risk in this family is the upstream licence change.** Several major projects moved from a free licence to a source-available one in recent years. Versions you already obtained remain covered by the old licence, but **later versions do not** — and your security updates come from later versions. See [Pitfalls](/en/licensing/pitfalls/). --- ### 8. Content, data and fonts Often forgotten because they do not concern code — and regularly the source of the most concrete problems. | Licence | Object | What to know | | --- | --- | --- | | **[CC-BY-4.0](https://spdx.org/licenses/CC-BY-4.0.html)** | Content | Attribution required, including in a commercial product | | **[CC-BY-SA-4.0](https://spdx.org/licenses/CC-BY-SA-4.0.html)** | Content | **Share-alike**: a derivative must be published under the same licence. Content contamination. | | **[CC-BY-NC](https://spdx.org/licenses/CC-BY-NC-4.0.html)** | Content | **Non-commercial use only.** Prohibited in a product you sell. The most frequent error on icons and illustrations. | | **[CC-BY-ND](https://spdx.org/licenses/CC-BY-ND-4.0.html)** | Content | No derivatives: no cropping, no recolouring. | | **[OFL-1.1](https://spdx.org/licenses/OFL-1.1.html)** | Fonts | Free redistribution, but a **reserved font name** clause: a modified font may not keep its original name. Selling the font on its own is prohibited. | | **[ODbL](https://spdx.org/licenses/ODbL-1.0.html)** | Databases | Copyleft on the database and on derived databases. | Creative Commons **itself advises against** using its licences for code: they address neither the source/binary distinction nor patents. --- ### The case that is not a family: no licence at all A public repository **with no licence file is not open source**. Absent an express grant, copyright applies in full: all rights reserved. Code being visible grants nothing. In SPDX this is `NOASSERTION`. In your policy it must be **blocking**, on the same footing as a prohibited licence — not treated as a benign missing field. ## Pitfalls the matrix does not show URL: https://cra-reference.eu/en/licensing/pitfalls/ Description: Upstream licence changes, missing licences, copied code, AI-generated code, assets, CLAs, mutual incompatibilities: what the family × scenario grid cannot capture. Audience: transverse Published 2026-08-20, updated 2026-08-20 The [family × scenario](/en/licensing/) matrix handles the normal case: an identified component, under a known licence, in a defined product. Real incidents almost always come from elsewhere. --- ### 1. The upstream licence change The most active risk of the period. Several major infrastructure projects have left a free licence for a source-available one in recent years — databases, search engines, infrastructure tools, monitoring, ticketing systems. **The mechanism:** versions already published stay under the old licence, permanently. But **later versions do not** — and your security fixes come from later versions. The organisation then faces three options, all costly: | Option | Cost | | --- | --- | | Stay on the last free version | No more upstream security fixes: a direct regulatory liability under the CRA | | Move to a community fork | Uncertain maturity, fragmented ecosystem | | Accept the new licence | Commercial negotiation, usage restrictions, recurring cost | **What to put in place:** - **pin** versions and licences in the SBOM, and **compare across versions** — a change in the `license` field is an event to handle, not just another data point; - watch the **ten to twenty critical infrastructure components**, the ones whose replacement would take months; - record the risk in the **compliance risk register**, with a named owner. --- ### 2. No licence at all A public repository with no licence file **is not open source**. Absent an express grant, copyright applies in full: all rights reserved. The code being visible grants nothing, and a forge's terms of service grant at most a right to view and copy within the platform. In SPDX this is `NOASSERTION`. In a licence policy it must be **blocking** — on the same footing as a prohibited licence, not treated as missing metadata. A frequent and more insidious variant: the repository **announces** a licence in its `README` but contains no licence text, or contains a different one. --- ### 3. Multiple licences in one repository The repository declares MIT. A `vendor/`, `third_party/` or `contrib/` subdirectory holds code under another licence, sometimes copyleft. No package manager sees it: they read the licence field declared in the manifest, not the contents of the files. **The only remedy** is analysing the **contents of the files**, by hash, with dedicated tools — see [Generators](/en/tooling/generators/). It is slow and verbose, and it is the difference between declared compliance and established compliance. --- ### 4. Copied code **From a Q&A site or forum.** Contributions to the main platforms are under a share-alike licence. A substantial snippet copied into proprietary code raises, in theory, a contamination question. Universal practice ignores it for a few trivial lines, and the doctrine holds that below an originality threshold there is no protectable work. The risk becomes real for a whole function copied across. **From another project.** Copy-pasting a function from a copyleft project creates a derivative work, with no dependency manager recording it. **Vendored code.** Copying a component into your tree rather than declaring it as a dependency breaks traceability: it appears neither in the manifest nor in the SBOM generated from the manifest. It only appears under content analysis. --- ### 5. AI-generated code An open question, to be handled as such rather than settled. The established facts: code generation assistants are trained on public code under a range of licences, copyleft included. They have been shown to reproduce substantial, near-identical excerpts of their source, particularly for uncommon code. The open questions: the legal status of the output, ownership of rights, whether it qualifies as a derivative work, and liability in case of reproduction. No settled European case law to date. **What is reasonable in the meantime:** - enable the **match filters** the tools offer, which block the reproduction of excerpts identical to known public code; - **review** generated code for non-trivial functions, as you would review a contribution; - **do not generate** code in areas where contamination would be irrecoverable — cryptographic core, a component intended for publication under a permissive licence; - document the position taken, so it does not have to be improvised during acquisition diligence, where the question is now asked. --- ### 6. Assets, which no tool looks at No dependency scanner examines fonts, icons, images, sounds, 3D models or datasets. Yet they cause very concrete problems, because their licences are often **more restrictive** than those of the code. | Asset | Pitfall | | --- | --- | | **Fonts** | `OFL-1.1`: reserved font name clause; subsetting is a modification. Commercial fonts: licences per domain or per page view | | **Icons** | `CC-BY-NC` prohibited in a product you sell; `CC-BY` requires an attribution rarely given | | **Images** | Stock libraries: licence by use, often not transferable to the customer | | **Sounds** | Same rules, plus neighbouring rights | | **Datasets** | `ODbL`: copyleft on derived databases. Decisive for a machine learning product | | **Pre-trained models** | Their own licences, sometimes with usage restrictions — the so-called "responsible" family | **What to do:** keep an **asset inventory** separate from the software SBOM, with the source, the licence, proof of acquisition and the scope of use granted. Nobody does this spontaneously; it is nonetheless the first place an audit finds something. --- ### 7. Mutual incompatibilities Two licences can both be free and impossible to combine. The combinations to know: | Combination | Status | | --- | --- | | `Apache-2.0` + `GPL-2.0-only` | **Incompatible** on the FSF's reading | | `Apache-2.0` + `GPL-3.0` | Compatible | | `CDDL-1.0` + `GPL-2.0` | **Incompatible** — the origin of the ZFS-on-Linux problem | | `GPL-2.0-only` + `GPL-3.0-only` | **Incompatible** with each other | | `GPL-2.0-or-later` + `GPL-3.0` | Compatible, by moving to v3 | | `BSD-4-Clause` + `GPL` | **Incompatible** — advertising clause | | `EPL-1.0` + `GPL` | **Incompatible**; EPL-2.0 resolves it with an optional clause | | Two different strong copylefts | Generally incompatible with each other | An incompatibility cannot be worked around: it makes **distributing** the combined work impossible. It is caught early, or paid for in rewriting. --- ### 8. Patent clauses and their backfire Apache-2.0, GPL-3.0, MPL-2.0 and EPL-2.0 carry a patent grant **with a termination**: bringing patent infringement litigation against a contributor over the software forfeits the grant, and sometimes the whole licence. For a company holding a patent portfolio this is a legal-department matter, not an engineering one: a litigation strategy can be neutralised by a library choice a developer made three years earlier. --- ### 9. The missing CLA Without a contributor licence agreement or a developer certificate of origin, every external contributor keeps their rights. Consequences for a project you publish: - **relicensing impossible** without everyone's consent; - **dual commercial licensing impossible**; - **enforcement difficult** against a third party breaching your licence, since you do not hold all rights. To settle **before** the first external contribution. See [Library / SDK](/en/licensing/scenarios/library-sdk/). --- ### 10. Fake free licences Texts that look like free licences without being one: | Text | Problem | | --- | --- | | **Commons Clause** | An **addendum** grafted onto a free licence, removing the right to sell. "MIT + Commons Clause" is not MIT | | **JSON License** | Contains the clause "the Software shall be used for Good, not Evil": ambiguous, non-free in practice, banned by several foundations | | "Home-made" licences | Written by the author, unreviewed, unpredictable in interpretation. Treat as proprietary | | "Ethical" licences | Usage restrictions by purpose. They fall outside the open source definition and create a permanent judgement problem | --- ### What these ten pitfalls have in common None is caught by a dependency scanner reading manifests. All require either **file content analysis**, or **monitoring over time**, or a **governance decision**. That is why licence compliance does not reduce to a tool: it requires a policy, a register, a watch and a named owner — see [Intellectual property](/en/legal/intellectual-property/). ## Nine distribution scenarios URL: https://cra-reference.eu/en/licensing/scenarios/ Description: The same component, nine contexts: what changes, what gets triggered, and the verdict per licence family for each type of product. Audience: transverse Published 2026-08-20, updated 2026-08-20 Each page follows the same pattern: **what actually happens** (is there distribution? network interaction? linking?), **the verdict per family**, **the pitfalls specific to the scenario**, and **what the CRA adds**. ### The three questions that classify a scenario Before looking for your case in the list, answer these three. They predict most of the outcome. | Question | If yes | If no | | --- | --- | --- | | **Does a third party receive the software** in executable form? | Copyleft is triggered | The GPL has no effect | | **Does a third party interact with it over a network**? | Network copyleft is triggered | The AGPL has no effect | | **Can the user replace the component** with a modified version? | The LGPL is satisfied | The LGPL requires you to make it possible | These mechanisms are detailed in [What triggers an obligation](/en/licensing/triggers/). ### The nine scenarios **[Worst case](/en/licensing/scenarios/worst-case/)** comes first because it is not a product: it is the **default posture**, the one to apply while you do not yet know where the component will end up — and the one that should govern a shared internal library reused everywhere. The other eight are ordered from **least to most constrained**: | Rank | Scenario | What characterises it | | --- | --- | --- | | 1 | [Internal tool](/en/licensing/scenarios/internal-tool/) | No distribution — almost everything is permitted | | 2 | [SaaS backend](/en/licensing/scenarios/saas-backend/) | No distribution, but network exposure | | 3 | [Library / SDK](/en/licensing/scenarios/library-sdk/) | You are upstream: your licence constrains your users | | 4 | [Desktop / CLI app](/en/licensing/scenarios/desktop-cli/) | Classic binary distribution | | 5 | [On-premises](/en/licensing/scenarios/on-premises/) | Full distribution, operating system included | | 6 | [Web frontend](/en/licensing/scenarios/web-frontend/) | Source code distribution, almost always overlooked | | 7 | [Mobile app](/en/licensing/scenarios/mobile-app/) | Distribution plus restrictive store terms | | 8 | [Embedded / IoT](/en/licensing/scenarios/embedded-iot/) | Distribution plus hardware lock-down | ### One product often spans several scenarios This is the most frequent application error. A single product combines: - a **SaaS backend**, which distributes nothing; - a **web frontend**, which distributes code to every visitor; - a **mobile app**, subject to store terms; - an **agent** installed at the customer's site, which is a binary distribution; - a **container image** published to a registry, which is also a distribution; - possibly an **on-premises** edition. Each part must be assessed in its own scenario, with its own list of permitted licences. A component acceptable in the backend may be prohibited in the agent, and the licence policy must reflect that — see [Intellectual property](/en/legal/intellectual-property/), which breaks your lists down by context of use. > **The most-constrained-part rule.** If the same repository builds both the backend and the > agent shipped to customers, the agent's regime applies to the whole repository. Splitting > repositories is sometimes the only way to keep freedom of choice over backend components. ## Desktop or command-line application URL: https://cra-reference.eu/en/licensing/scenarios/desktop-cli/ Description: Classic binary distribution — the textbook case the GPL was written for. Demanding but workable, provided you prepare to supply the source. Audience: cyber Published 2026-08-20, updated 2026-08-20 An executable downloaded and installed by the user, on Windows, macOS or Linux. A command-line tool, a graphical application, an installer. ### What actually happens | Question | Answer | | --- | --- | | Does a third party receive the software in executable form? | **Yes** — that is the definition | | Does a third party interact with it over a network? | No, unless an embedded server component | | Is the product a locked-down consumer good? | Generally **no**: the user controls their machine | | Is the component linked to your code? | Often, and the linking mode is yours to choose | This is the scenario the GPL was written for. The obligations are full, but they are **known, bounded and tractable**. ### The verdict per family | Family | Verdict | Reason | | --- | :--: | --- | | Permissive | ● | Attribution owed, to ship with the product | | Weak copyleft, file (MPL, EPL) | ● | Publish modified files; your code stays private | | Weak copyleft, library (LGPL) | ◐ | Workable with **dynamic linking**; costly statically | | Strong copyleft (GPL) | ◐ | Full duty to supply the source of the distributed work. Possible if accepted | | Network copyleft (AGPL) | ○ | Behaves like the GPL here; section 13 adds to it if the app exposes a service | | Source-available | ✕ | Usage restrictions incompatible with broad distribution | ### Dynamic linking, an architectural decision This is the main lever in this scenario. With dynamic linking the LGPL is satisfied with nothing further: the user can swap the shared library. | Platform | Dynamic linking | | --- | --- | | Linux | Natural — `.so`, package dependencies | | Windows | Natural — `.dll` | | macOS | Natural — `.dylib`, but **code signing and notarisation** complicate replacement | | Go or Rust binary, "portable" application | **Impossible in practice**: everything is static | The last case matters: shipping a static Go binary containing an LGPL library means owing the object files needed to relink. Few teams do it, and it is a silent non-compliance. ### What "supply the source" means in practice For a distributed GPL component, the **corresponding source** comprises: - the work's source code, including your modifications; - the **build and installation scripts**; - interface definition files and generation scripts; - everything needed to **regenerate and install** the executable. Two possible arrangements: | Arrangement | Constraint | | --- | --- | | Ship the source **with** the binary | The simplest: an archive next to the download | | Provide a **written offer** to supply the source | GPL-2.0: valid for **three years** after the last distribution; GPL-3.0: at least as long as spare parts are offered | The written offer looks lighter, but it creates a long archiving duty: you must be able to regenerate, three years later, the exact version shipped. That is precisely the [support period](/en/cra/support-period/) problem under the CRA — and therefore the same solution. ### Pitfalls in this scenario **The installer bundling third-party libraries.** Each component keeps its licence. An installer is not a single work: it is most often [mere aggregation](/en/licensing/triggers/), which is good news — but every component keeps its own obligations. **The unfindable attribution file.** On a desktop, attribution must be reachable by the user: an About box, a shipped file, a menu entry. A `NOTICE` file buried in an archive is not a serious provision. **The component invoked as a subprocess.** Calling a GPL executable from your application generally does not create a derivative work — but if you **distribute** it with your product, you are distributing GPL code and the source obligation applies to that component. **Updates.** Every new version distributed is a new distribution, with its own obligations. The corresponding source must track versions. **macOS and notarisation.** Mandatory signing raises no GPL-3.0 issue on a general-purpose computer — it is not a locked-down "consumer product" under section 6, since the user can disable the checks. The question does arise for dedicated hardware. ### What the CRA adds A distributed application is a fully fledged **product with digital elements**: technical documentation, SBOM, support period, CE marking, coordinated disclosure. The happy overlap: the **corresponding source** to retain for the GPL and the **ability to rebuild** required by the support period are the same artefact. A well-designed archive serves both — see [Evidence retention](/en/legal/evidence-retention/). ## Embedded and IoT URL: https://cra-reference.eu/en/licensing/scenarios/embedded-iot/ Description: The most constrained scenario, and the only one where a licensing requirement runs directly against a CRA security requirement: GPL-3.0 anti-lock-down versus verified boot. Audience: transverse Legal basis: Annex I, Part I — integrity protection · Art. 13(5) — due diligence on third-party components Published 2026-08-20, updated 2026-08-20 Firmware shipped inside a device: router, camera, controller, sensor, gateway, medical equipment outside CRA scope, vehicle outside CRA scope. ### What actually happens | Question | Answer | | --- | --- | | Does a third party receive the software in executable form? | **Yes**, embedded in hardware | | Is the product a consumer good? | **Often yes** — and that is the critical point | | Can the user install a modified version? | **No**, by construction: verified boot, signing | | Is the component linked to your code? | **Yes, statically**, almost always | | What volume of components? | A whole system: kernel, `libc`, utilities, network stack | Every [trigger](/en/licensing/triggers/) is active at once. This is the most constrained scenario, and **it is also where real litigation is concentrated**: most public GPL enforcement cases, in Europe and elsewhere, concern routers, televisions and network equipment. ### The verdict per family | Family | Verdict | Reason | | --- | :--: | --- | | Permissive | ● | Attribution owed, to be made reachable despite the absence of a screen | | Weak copyleft, file (MPL, EPL) | ● | Limited reciprocity, no linking constraint | | Weak copyleft, library (LGPL-2.1) | ○ | Static linking is near-universal: object files owed | | Weak copyleft, library (LGPL-3.0) | ✕ | Adds the v3 anti-lock-down clause | | **Strong copyleft GPL-2.0** | **○** | Full source obligation, but **no** anti-lock-down. Workable, and it is the regime of Linux, BusyBox and U-Boot | | **Strong copyleft GPL-3.0** | **✕** | **Anti-lock-down incompatible with a locked device** | | Network copyleft (AGPL) | ✕ | Cumulative | | Source-available | ✕ | Restrictions incompatible with selling a product | ### The central conflict: anti-lock-down versus integrity This is the most important point in the whole section. **GPL-3.0, section 6** requires, for a consumer product, supplying the **Installation Information**: what is needed to install and run a modified version of the software on the device. If the device refuses to boot software the user modified, the licence is not respected. **The CRA, Annex I, Part I**, requires protecting the **integrity** of programs and configurations against unauthorised modification. The standard engineering answer to that requirement is **verified boot**: the device only boots signed code. The two requirements point in opposite directions. | | GPL-3.0, section 6 | CRA, Annex I | | --- | --- | --- | | Objective | The user keeps control of their device | The device resists unauthorised modification | | Means | Supply the keys or the installation procedure | Refuse any unsigned code | #### How the sector resolves the tension There is no universal answer. Four approaches, in order of frequency: 1. **Stay on GPL-2.0** for system components. That is the rarely stated but very real reason the Linux kernel, BusyBox and U-Boot remain on GPL-2.0-only. It means refusing components that have moved to v3. 2. **Separate the trust levels**: locked verified boot for the security partition, and an application partition where the user can install their own build. Technically clean, but costly. 3. **Supply the Installation Information**, including a documented unlocking procedure, while keeping integrity on by default. That is the licence's literal reading, and it is defensible under the CRA, which requires protection against **unauthorised** modification — a change made by the device's owner, following a documented procedure, is authorised. 4. **Exclude GPL-3.0** from the product, which means a policy applied from the choice of board support package onwards. > **The reading that reconciles the two texts.** The CRA protects against *unauthorised* > modification; nowhere does it require that a device's legitimate owner be unable to install > their own software. An explicit, deliberate unlocking procedure that leaves the device in a > state flagged as unsupported satisfies both. This is the position to work through with legal > counsel **before** freezing the boot architecture, not after. ### Static linking, systematic in embedded There is usually no dynamic loader. Every LGPL library is therefore statically linked, which means owing the **object files** of the application so the user can relink against their own build of the library. Few manufacturers do it. It is among the sector's most widespread non-compliances, and among the easiest for a third party to establish by analysing a firmware image. ### Volume: firmware means thousands of components | Typical component | Licence | | --- | --- | | Linux kernel | `GPL-2.0-only` | | BusyBox | `GPL-2.0-only` | | U-Boot | `GPL-2.0-or-later` | | glibc | `LGPL-2.1-or-later` | | musl | `MIT` | | OpenSSL 3.x | `Apache-2.0` (earlier versions: a historical dual licence, GPL-incompatible) | | Buildroot, Yocto | Recipes under various licences, producing artefacts under various licences | A typical firmware image contains several thousand packages. Without an SBOM produced by the build chain, the inventory cannot be reconstructed afterwards — and that is exactly what the CRA makes mandatory. ### Pitfalls in this scenario **The chip vendor's BSP.** The board support package arrives as an archive, with no inventory, proprietary drivers, binary blobs and sometimes modified GPL code whose corresponding source is not supplied. It is the weakest link in the chain, and the [due diligence](/en/cra/open-source/integrating-oss/) the CRA requires now forces you to address it — which means requiring it contractually from the supplier. **Binary blobs.** Wi-Fi, modem and GPU firmware: redistributable under conditions, often under a restrictive proprietary licence. To inventory and document. **Attribution with no screen.** The attribution duty survives on a device with no interface. The usual solutions: a web page served by the device, a file reachable through the administration interface, the printed manual, or a URL printed on the product — the last of which must remain valid for the device's whole service life. **The ten-year written offer.** The duty to supply the corresponding source lasts a long time: three years after the last distribution under GPL-2.0, longer under GPL-3.0. It overlays the CRA's [support period](/en/cra/support-period/). Both require the same thing: keeping the source, the toolchain and the ability to rebuild, for a decade. **Taking over an abandoned project.** An unmaintained embedded component inside a product covered by a ten-year support period is a double liability: security and licensing. ### What the CRA adds A great deal, and not only the conflict described above: - **classification**: microprocessors and microcontrollers with security-related functionalities fall under **class I**; if they are **tamper-resistant**, under **class II**, where self-assessment is excluded. See [Criticality classes](/en/cra/criticality-classes/); - **support period**: hardware life cycles often exceed ten years, and component suppliers do not follow. See [Support period](/en/cra/support-period/); - **firmware SBOM**: to be produced by the build chain, not reconstructed by later analysis; - **secure updates**: a signed update mechanism, resilient to power loss, with rollback protection — see [Secure updates](/en/cyber/secure-updates/), which is where the conflict with GPL-3.0 section 6 becomes technically concrete. ## Internal tool URL: https://cra-reference.eu/en/licensing/scenarios/internal-tool/ Description: No distribution, therefore almost no obligation — and the only real risk: the internal/external boundary moving without anyone reopening the file. Audience: cyber Published 2026-08-20, updated 2026-08-20 Development tooling, dashboards, operations scripts, business applications used only by employees. ### What actually happens | Question | Answer | | --- | --- | | Does a third party receive the software in executable form? | **No** | | Does a third party interact with it over a network? | No — employees are not third parties | | Is the product a consumer good? | No | No copyleft mechanism triggers. This is the freest scenario. ### The verdict per family | Family | Verdict | Reason | | --- | :--: | --- | | Permissive | ● | Attribution not owed absent distribution, though crediting remains good practice | | Weak copyleft (MPL, EPL, LGPL) | ● | No distribution, no reciprocity | | Strong copyleft (GPL) | ● | **The GPL triggers only on distribution** | | Network copyleft (AGPL) | ◐ | See below | | Source-available (BSL, SSPL, ELv2) | ◐ | Read the restrictions: some target use itself, not only resale | ### The AGPL case Section 13 covers "all users interacting with it remotely through a computer network". Nothing excludes employees. A strict reading therefore requires, for a modified AGPL internal tool, **offering the source to internal users**. In practice this is painless: publishing the source on the internal repository is enough. But the obligation exists, and it is better known than discovered. ### Source-available licences Unlike copyleft, they sometimes restrict **use itself**, with no distribution involved: - a **BSL-1.1** typically prohibits production use beyond the additional use grant the vendor offers; - an **Elastic License 2.0** prohibits providing the product as a managed service, which can cover an internal platform shared between subsidiaries; - **Commons Clause** removes the right to sell, not the right to use. They must therefore be read, even in the most permissive of scenarios. ### The only real risk: the boundary moves That is the whole risk of this scenario, and it is real. | Event | Effect | | --- | --- | | The internal tool becomes a **product** | Every mechanism wakes up at once | | The tool is deployed at a **customer** or partner | Distribution | | The tool goes to a **subsidiary**, a separate legal entity | **Distribution** — a subsidiary is a third party | | An external **contractor** receives the binary | Distribution | | The container image is published to a **public registry** | Distribution | | The tool is opened to **external users**, even free of charge | The AGPL triggers | The subsidiary point often surprises: intra-group distribution between two separate legal entities **is** distribution under free software licences. Consolidated accounting has no bearing here. > **The recommendation.** Apply the licence policy to internal tools anyway, at least in warning > mode. Not because the obligation exists today, but so that promotion to a product does not > run, two years later, into a component that cannot be removed. ### What the CRA adds An internal tool is **not** a product with digital elements: it is not placed on the market. It falls outside the Regulation — see [Scope](/en/cra/scope-pde/). That does not mean it escapes every requirement: build chain tooling contributes to the security of the products you do place on the market, and falls under [supply chain control](/en/cyber/supply-chain-risk/) on that basis. ## Library or SDK you publish URL: https://cra-reference.eu/en/licensing/scenarios/library-sdk/ Description: Here you are upstream: your dependencies constrain your licence, and your licence constrains your users. Contamination runs both ways. Audience: legal Legal basis: Art. 3, point 1 — components placed on the market separately Published 2026-08-20, updated 2026-08-20 A reversal of perspective: you are no longer the consumer but the supplier. Two constraints answer each other. ### What actually happens | Question | Answer | | --- | --- | | Does a third party receive the software in executable form? | **Yes**, and usually in source form too | | Does your licence constrain your users? | **Yes — that is the central point** | | Do your dependencies constrain your licence? | **Yes** | ### The rule that governs everything > **You cannot publish under a licence more permissive than the most restrictive of your > dependencies.** A library embedding a GPL component cannot be published under MIT. The licence you display must be **downstream-compatible** with everything you include. Corollary: the composition of your dependencies is a **product decision**, not a technical one. Adding an LGPL dependency to a permissive SDK transfers an engineering constraint to all your users, usually without their noticing. ### The verdict for your dependencies | Dependency family | Verdict | Effect on what you publish | | --- | :--: | --- | | Permissive | ● | None. You remain free to choose your licence | | Weak copyleft, file (MPL) | ◐ | Your files stay free; modified MPL files must be published | | Weak copyleft, library (LGPL) | ○ | Your users inherit the replacement constraint, often unknowingly | | Strong copyleft (GPL) | ○ | Your library becomes GPL. A legitimate choice, but it must be deliberate | | Network copyleft (AGPL) | ○ | Your library becomes AGPL, which makes it unusable by most integrators | | Source-available | ✕ | You cannot redistribute | ### Choosing your own licence A commercial decision as much as a legal one. | Your licence | Who can integrate you | What you get | | --- | --- | --- | | **Apache-2.0** | Everyone | Maximum adoption, plus patent protection for you and for them. The default choice for an SDK meant to be adopted | | **MIT** | Everyone | Maximum adoption, no patent protection | | **MPL-2.0** | Everyone, with per-file reciprocity | Improvements to your code come back to you without blocking integration | | **LGPL** | Everyone, with a linking constraint | Strong reciprocity, but effectively rules out embedded and mobile | | **GPL / AGPL** | Free software projects only | The **dual licensing** model: free for open source, paid for proprietary | | **BSL / source-available** | Depends on the restrictions | Protection against managed-service resale, at the cost of leaving open source | The **dual licensing** model — GPL or AGPL on one side, a commercial licence on the other — requires owning all rights in the code. Which leads to the next point. ### The CLA, to settle before the first external contribution Without a **contributor licence agreement** or, at minimum, a **DCO**, each contributor keeps their rights in their contribution. Consequences: - **relicensing later is impossible** without everyone's consent; - **offering a commercial licence is impossible** over code you do not fully own; - **enforcing the licence** against a third party is difficult, since you do not hold all rights. This must be decided **before** accepting the first external contribution. Fixing it afterwards means tracking down every contributor, or rewriting their work. ### Pitfalls in this scenario **The invisible transitive dependency.** Your SDK is Apache-2.0 but pulls in an LGPL dependency. Your users inherit the linking constraint with nothing to warn them. The remedy: publish your own SBOM alongside the SDK, and explicitly document transitive licences carrying obligations. **Nested licences in one repository.** A repository announced as MIT with a `vendor/` subdirectory under GPL. Your licence declaration becomes inaccurate. **Example code.** The snippets you publish in the documentation are reused verbatim by your users. Without an explicit licence their status is uncertain — state that they are under the same licence, or a more permissive one. **Generated files.** An SDK generated from an interface specification sometimes inherits the generator's licence. Check what the generator says about its output — exceptions of the `Autoconf-exception` kind exist for exactly this. **Trademarks.** No free software licence grants trademark rights. A user may fork your code; they may not call it by your name. ### What the CRA adds A great deal, and it is often overlooked: **a library placed on the market separately is a product with digital elements in its own right** (Art. 3, point 1). It therefore has, for itself: its technical documentation, its SBOM, its support period, its coordinated disclosure policy, its CE marking. Unless it is made available **outside a commercial activity**, in which case it falls outside the scope — see [Open source](/en/cra/open-source/). The boundary is commercial character, not licence: publishing an Apache-2.0 SDK alongside a paid offering is still a commercial activity. ## Mobile app URL: https://cra-reference.eu/en/licensing/scenarios/mobile-app/ Description: Binary distribution plus store terms: the only scenario where a free licence can be flatly incompatible with the distribution channel itself. Audience: legal Published 2026-08-20, updated 2026-08-20 An application distributed through an app store — App Store, Google Play, alternative stores, enterprise distribution. ### What actually happens | Question | Answer | | --- | --- | | Does a third party receive the software in executable form? | **Yes** | | Is the product a consumer good? | **Yes** | | Can the user install a modified version? | **No** on iOS, with difficulty on Android | | Does an intermediary impose its own terms? | **Yes — and that is what makes this scenario special** | It is the only scenario where the difficulty comes not only from the licence, but from the **conflict between the licence and the distribution channel's terms**. ### The verdict per family | Family | Verdict | Reason | | --- | :--: | --- | | Permissive | ● | Attribution owed, to be reachable from inside the app | | Weak copyleft, file (MPL, EPL) | ● | Workable: reciprocity limited to modified files | | Weak copyleft, library (LGPL) | ○ | The replacement condition is unreachable through a store | | **Strong copyleft (GPL)** | **✕** | **Conflict with store terms** — see below | | Network copyleft (AGPL) | ✕ | Same, aggravated | | Source-available | ✕ | Restrictions incompatible with public distribution | ### The GPL / app store conflict The mechanism is as follows. The GPL prohibits imposing **further restrictions** on recipients beyond those of the licence — GPL-2.0 section 6, GPL-3.0 section 10. Store terms of service impose exactly such restrictions: limits on the number of devices the application may be installed on, prohibitions on redistribution, digital rights management. **Distributing an application containing GPL code through a store that imposes those restrictions therefore places the distributor in breach of the licence.** The precedent is well known: **VLC** was pulled from the App Store in 2011 after a contributor gave notice, and returned once part of the code had been relicensed to LGPL and then MPL. No judge ruled on it — it is a precedent of practice, not of law — but it has shaped the sector ever since. **GPL-3.0 aggravates the conflict** twice over: - the **anti-lock-down** clause of section 6 requires supplying what is needed to install a modified version on the product — impossible against iOS's mandatory code signing; - the **anti-DRM** clause of section 3 runs directly against the stores' distribution model. ### The LGPL on mobile Theoretically possible, practically very hard. The LGPL requires the user to be able to replace the library with their own build and have the application run with it. | Platform | Obstacle | | --- | --- | | iOS | The bundle is signed; any modification invalidates the signature and blocks execution | | Android | Technically more open, but the published package is signed, and replacement means recompiling | The route sometimes taken — supplying object files for relinking and documenting the procedure — is heavy and rarely done properly. It needs legal advice and a deliberate decision. ### What remains workable | Family | How | | --- | --- | | **Permissive** | Without reservation. It is the bedrock of the mobile ecosystem | | **MPL-2.0** | Per-file reciprocity with no linking constraint: VLC's move to MPL is exactly this | | **Apache-2.0** | Recommended: permissive **and** patent protection, which matters in a market with active patent litigation | ### Pitfalls in this scenario **Third-party SDKs.** Advertising, analytics, payment, notifications, mapping: they arrive under proprietary licences, often with display obligations, personal data clauses and usage restrictions. They are rarely in the SBOM and never in the licence review. **The unreachable attribution.** The attribution duty under permissive licences requires a screen reachable from inside the application. Both platforms provide a standard location for it; it needs to be populated, automatically, from the SBOM. **Native libraries.** A compiled native module carries its C or C++ dependencies' licences, invisible to the mobile package manager. **Code shared with the web.** A frontend and a mobile app sharing a codebase share its components too — but **not** the same constraints. The strictest regime applies to the shared code. **Enterprise distribution.** Distributing an app internally to your own employees is not distribution to third parties, and store terms do not apply either. The regime moves closer to the [internal tool](/en/licensing/scenarios/internal-tool/). ### What the CRA adds A mobile app is a product with digital elements. Two points deserve attention: - **classification**: a health monitoring app, a home assistant, a password manager fall under **Annex III, Part I** — class I, with the assessment constraint that follows. See [Criticality classes](/en/cra/criticality-classes/); - **the support period** must hold despite platform-imposed cycles that force regular recompilation to stay publishable. A product still supported but no longer publishable is a situation to anticipate contractually. ## On-premises and self-hosted URL: https://cra-reference.eu/en/licensing/scenarios/on-premises/ Description: Full distribution at the customer's site, often operating system included. The customer gains the right to redistribute what you shipped them. Audience: legal Published 2026-08-20, updated 2026-08-20 The software is installed and runs on the customer's infrastructure: a virtual appliance, a machine image, an installation package, a set of containers, a turnkey cluster. ### What actually happens | Question | Answer | | --- | --- | | Does a third party receive the software in executable form? | **Yes, in full** | | Does a third party interact with it over a network? | Yes, but **the customer** becomes the operator | | Is the product a consumer good? | No — a professional customer | | What exactly does the customer receive? | Often **a whole system**, operating system included | Along with embedded, this is the scenario with by far the largest volume of distributed components. ### The verdict per family | Family | Verdict | Reason | | --- | :--: | --- | | Permissive | ● | Attribution owed for everything shipped | | Weak copyleft, file (MPL, EPL) | ● | Publish modified files | | Weak copyleft, library (LGPL) | ◐ | Workable with dynamic linking; in containers, usually the case | | Strong copyleft (GPL) | ◐ | Full obligation, including towards the customer, who may then redistribute | | Network copyleft (AGPL) | ○ | You distribute: sections 4 and 5 apply. Section 13 will apply **to the customer**, which they should be told | | Source-available | ✕ | Almost all prohibit redistribution | ### The point that changes everything: the customer gains rights On receiving a GPL binary, the customer becomes a **holder of the licence's rights**. They may: - demand the **corresponding source**, including your modifications; - **redistribute** it to anyone, under the same licence; - **modify** the component and deploy their version. This is not theoretical: it is how a violation becomes public. An unhappy — or merely curious — customer asks for the source. If they do not get it they hold considerable leverage, and if they themselves contribute to the upstream project, an interest in acting on it. > **The commercial consequence.** With strong copyleft shipped on-premises, there is no possible > composition secrecy. If the combined code carries competitive value, the component must be > isolated in a separate process, or replaced. ### The appliance: the volume trap Shipping a machine image or a full container image means distributing **the whole system**: kernel, C library, utilities, interpreters, package manager. Thousands of components, overwhelmingly GPL and LGPL. | What you think you ship | What you actually ship | | --- | --- | | Your application | Your application **plus** an entire distribution | | A dozen dependencies | Several thousand packages | Good news: this is largely [mere aggregation](/en/licensing/triggers/) — your application is not a derivative work of the kernel. Bad news: **every aggregated package keeps its obligations**, including attribution and, for GPL components, supply of the corresponding source. The standard remedy: start from a **minimal base image**, and rely on the source archives the distribution vendor already publishes, referencing them explicitly — provided you verify that they cover the exact version shipped. ### Pitfalls in this scenario **The written offer that outlives the contract.** Under GPL-2.0 the offer to supply the source must remain valid for **three years** after the last distribution — regardless of the commercial contract ending, the product reaching end of life, or the team leaving. **Patches shipped one at a time.** Every patch sent to the customer is a new distribution, with its own obligations and its own corresponding source. **The customer-specific build.** A bespoke development delivered to a single customer is still a distribution. Having only one recipient changes nothing. **The customer who redistributes.** Nothing stops them for components under copyleft. Your contractual terms can prohibit it for *your* code, not for third-party code under a free licence. **The AGPL double hat.** You distribute, so you owe the source. The customer operates a network service, so section 13 will apply to them if they modify it. That deserves to be written into the documentation, or you create a non-compliance on their side that they never saw coming. ### What the CRA adds The heaviest scenario in regulatory terms too. The product is placed on the market with all the obligations that follow, and two difficulties of its own: - **the SBOM must cover everything shipped**, base image included. An application SBOM that ignores the thousands of packages in the underlying system is incomplete — see [Quality and completeness](/en/sbom/quality/); - **the support period** covers the whole: fixing a vulnerability in the C library shipped inside your appliance falls to you, for five to ten years. That is the technical reason minimal images are not merely a security good practice: they directly shrink the scope of your obligations, on both fronts at once. ## SaaS backend URL: https://cra-reference.eu/en/licensing/scenarios/saas-backend/ Description: No distribution, so the GPL has no effect — and the AGPL becomes risk number one. The scenario where intuitions are most often wrong, in both directions. Audience: transverse Published 2026-08-20, updated 2026-08-20 The code runs on your servers. Users receive responses, not binaries. ### What actually happens | Question | Answer | | --- | --- | | Does a third party receive the software in executable form? | **No** | | Does a third party interact with it over a network? | **Yes** | | Is the product a consumer good? | No | One mechanism is active, and it is decisive: **network interaction**. ### The verdict per family | Family | Verdict | Reason | | --- | :--: | --- | | Permissive | ● | No distribution obligation; crediting remains good practice | | Weak copyleft (MPL, EPL, LGPL) | ● | Reciprocity is conditioned on distribution | | **Strong copyleft (GPL-2.0, GPL-3.0)** | **●** | **No effect.** No distribution, no duty to publish | | **Network copyleft (AGPL-3.0, OSL)** | **✕** | **This is exactly the case they target** | | SSPL-1.0 | ✕ | Requires publishing the whole service stack | | Elastic License 2.0, BSL | ○ | See below: depends on what the service *is* | ### The two wrong intuitions #### "The GPL will contaminate your SaaS" **No.** The GPL triggers on *distribution*, and an online service distributes nothing. You can build an entire backend on GPL components with no obligation to publish a line. It is the most counter-intuitive consequence in the field — so much so that many corporate policies ban the GPL in SaaS for no legal reason, denying themselves major components. #### "The AGPL is just a slightly stricter GPL" **No.** It is a change of nature. In this specific scenario the AGPL is the only family that can force you to publish your code — and the obligation covers the **combined work**, potentially your entire service. ### How the AGPL bites, concretely Three situations, in order of severity: | Situation | Analysis | | --- | --- | | **Strictly unmodified** AGPL component, in its own process, called over a network interface | Section 13 targets the *modified* version. A defensible position, to be **documented** | | **Modified** AGPL component, however slightly | Section 13 triggered on your version | | AGPL library **linked** to your service code | The combined work becomes "your version": the source of the whole is owed to users | The third case is the most common and the most expensive. One `import` is enough. > **The recommended internal rule.** The AGPL is on the **deny list** for any component to be > linked to service code. It moves to the **review list** — case-by-case, decision documented — > for a component deployed unmodified in an isolated process, such as a database or a standalone > infrastructure service. ### Source-available licences in this scenario They target managed service providers precisely. The question is not *where* the software runs but **what you sell**: | Case | Elastic License 2.0 / BSL | | --- | --- | | The product **is** your offering, resold as a managed service | **Prohibited** — this is the targeted case | | The product is an **internal component** of your platform, invisible to the customer | Generally allowed, verify against the exact text | | The product is used to **operate** your infrastructure | Generally allowed | Each licence in this family is drafted differently. There is no generic answer: read it, and have Legal decide. ### Pitfalls specific to SaaS **The published container image.** Pushing an image to a public registry — or to a private one a customer can reach — **is distribution**. Every dormant obligation wakes up over the image's contents. **The agent, the connector, the client SDK.** The day you ship any installable component, that component falls into another scenario. GPL in the backend has no effect; the same GPL in the agent is a publication obligation. **The on-premises edition.** The most brutal mutation: the product moves from the most permissive scenario to the [most constrained](/en/licensing/scenarios/on-premises/), carrying code built for years on the opposite assumption. **The frontend.** The JavaScript served to the browser **is** distributed, whatever the backend does. See [Web frontend](/en/licensing/scenarios/web-frontend/) — same product, different regime. **Exported code.** A feature that generates and delivers code, a model or a configuration to the customer can carry licensed components with it. ### What the CRA adds Standalone SaaS falls under NIS 2, **not** the CRA. But a backend inseparable from a connected product is a **remote data processing solution** within the meaning of Article 3, and therefore sits inside the product's scope — see [Scope](/en/cra/scope-pde/). Consequence: its components belong in the **SBOM** and in the technical documentation, even where no licence obligation triggers. The inventory is owed for security reasons, not copyright ones. ## Web frontend URL: https://cra-reference.eu/en/licensing/scenarios/web-frontend/ Description: The most misunderstood scenario: serving JavaScript to a browser is a distribution of code. The bundler mixes everything, minification erases the attributions. Audience: cyber Published 2026-08-20, updated 2026-08-20 A web application running in the browser: JavaScript, compiled TypeScript, WebAssembly, style sheets, fonts, icons. ### What actually happens | Question | Answer | | --- | --- | | Does a third party receive the software in executable form? | **Yes — the browser downloads and runs the code** | | Does a third party interact with it over a network? | Yes, but that is secondary here | | Is the component linked to your code? | **Yes, statically, in a single file** | > **The point almost everyone misses.** A web frontend **distributes source code** to every > visitor. It is not a service: it is a software delivery, to thousands of anonymous recipients, > several times a day. > > A team saying "you do SaaS, the GPL does not concern you" is right about the backend and wrong > about the frontend. Same product, **two opposite regimes**. ### The verdict per family | Family | Verdict | Reason | | --- | :--: | --- | | Permissive | ◐ | Allowed, but attribution survives bundling badly: see below | | Weak copyleft, file (MPL, EPL) | ◐ | Per-file reciprocity, but the bundle dissolves the notion of a file | | Weak copyleft, library (LGPL) | ○ | **Dynamic linking does not exist in a bundle**: treat as strong copyleft | | Strong copyleft (GPL) | ✕ | Distribution is established: the combined work's source is owed to every visitor | | Network copyleft (AGPL) | ✕ | Distribution and network combined | | Source-available | ✕ | The code is delivered to the client anyway, which these licences do not anticipate | | Non-commercial content (CC-BY-NC) | ✕ | Common on icons and illustrations, and prohibited in a product you sell | ### Why the bundler makes everything worse In a native application the combined-work question is arguable: dynamic linking? separate process? stable interface? In a frontend, **there is no argument to have**. The bundler takes your code and the dependencies', tree-shakes, renames symbols, inlines functions, and emits **a single file**. There is no longer any observable boundary between your code and the third-party component. Consequences: - the "you only link dynamically" argument is **unavailable**; - the "these are separate programs" argument is **unavailable**; - a GPL component in the dependency graph contaminates, in practice, the shipped artefact. The only architectural remedy is **real isolation**: loading the component from a separate origin, in its own `iframe` or worker, with no shared code. It is heavy, and it cannot be decided after the fact. ### Attribution, problem number one for permissive licences Permissive licences require preserving copyright and licence notices. Minification removes them all. What to put in place: | Measure | Effect | | --- | --- | | **Licence banner preservation** in the bundler | Keeps `/*! … */` blocks marked for preservation | | Generating a **`licenses.txt`** at build time | From the SBOM, with the full licence texts | | An **accessible link** from the application | Footer, "Legal notices" page, "About" | | A **blocking CI check** | Build fails if the attribution file is not generated | Without those four measures, a modern frontend breaches dozens of permissive licences at once. It is the most widespread failing in the field, and the easiest to fix. ### Pitfalls specific to frontends **Source maps.** Publishing source maps in production exposes your source code, and with it the exact composition of the bundle. That is often how a third party establishes a violation. **Fonts.** `OFL-1.1` allows redistribution but carries a **reserved font name** clause: a modified font — glyph subsetting, format conversion, renaming — may not keep its original name. Font subsetting, a routine optimisation, is a modification. **Icons and illustrations.** This is where the real problems are. `CC-BY-NC` prohibits commercial use; `CC-BY-SA` requires share-alike on the derivative; `CC-BY-ND` prohibits cropping and recolouring. An icon set picked up without checking is a far more immediate risk than a JavaScript library. **Development dependencies shipped by mistake.** A test-only component that ends up in the production bundle enters the distributed scope. **Third-party scripts loaded from a CDN.** You do not distribute them — but they introduce an external dependency that raises other questions, of security this time. **WebAssembly.** A module compiled from C or Rust carries its native dependencies' licences, invisible in the JavaScript package graph. The frontend SBOM must cover the WebAssembly build chain. ### What the CRA adds The frontend is part of the product. Its components belong in the **SBOM** just as much as the backend's — and they rarely are, in the arrangements one encounters, where the inventory usually stops at server dependencies. The Annex I requirements apply there too: data minimisation, integrity protection, no known exploitable vulnerabilities. A vulnerable JavaScript dependency served to the browser is a vulnerability of the product. ## Worst case — the least favourable assumption URL: https://cra-reference.eu/en/licensing/scenarios/worst-case/ Description: The posture to adopt when you do not yet know how the component will be distributed: assume binary distribution, network exposure and a consumer product. Audience: transverse Published 2026-08-20, updated 2026-08-20 This is not a product, it is a **default posture**. It applies in three situations: - a team wants to adopt a component and **does not yet know** which products it will end up in; - the component goes into a **shared internal library** reused by products in different scenarios; - you are drafting a **company licence policy**, to apply before the use cases are known. ### The assumption Assume the worst, cumulatively: | Question | Default assumption | | --- | --- | | Does a third party receive the software in executable form? | **Yes** | | Does a third party interact with it over a network? | **Yes** | | Is the product a locked-down consumer good? | **Yes** | | Is the component linked to your code? | **Yes, statically** | Under these assumptions every [trigger](/en/licensing/triggers/) is active at once. ### The verdict per family | Family | Verdict | Reason | | --- | :--: | --- | | Public domain | ● | No obligation, patents aside for CC0 | | Permissive | ● | Attribution only, at no cost once automated | | Weak copyleft, file (MPL, EPL) | ◐ | Acceptable if the file-separation discipline holds | | Weak copyleft, library (LGPL) | ○ | Assumed static linking means supplying object files; v3 adds anti-lock-down | | Strong copyleft (GPL) | ○ | Publishing the whole work's source, plus anti-lock-down in v3 | | Network copyleft (AGPL) | ✕ | Triggered by the network-exposure assumption | | Source-available (BSL, SSPL, ELv2) | ✕ | Usage restrictions incompatible with a product you sell | | Non-commercial content (CC-BY-NC, CC-BY-ND) | ✕ | Prohibited in a commercial product | ### How to use it This grid is what should feed the **default allow list** in the licence policy: a component on the allow list here is usable anywhere, with no further review. That is what lets teams move without calling Legal for every dependency. Components marked **◐** and **○** are not banned: they go through the [exception process](/en/legal/intellectual-property/), which requires naming the actual scenario and checking that the constraint is bearable there. > **The reasoning to avoid.** "This component is GPL but your product is SaaS, so you are fine." > True today, and false the day you ship an agent, a connector, an on-premises edition or an > image published to a public registry. If the component enters a shared repository, the least > favourable assumption among the derived products must apply. ### The question that decides a case **Does this repository build one artefact, or several?** A repository producing both the backend and the client agent inherits the agent's regime — the most constrained. Splitting repositories is not an organisational nicety: it is often the only way to keep freedom of choice over backend components. ### What the CRA adds Nothing directly — the Regulation does not address licences. But the [due diligence on third-party components](/en/cra/open-source/integrating-oss/) it requires includes examining the licence, and that examination is meaningless unless tied to a scenario. A diligence grid that records a licence without saying which product the component will enter demonstrates nothing. ## What triggers an obligation URL: https://cra-reference.eu/en/licensing/triggers/ Description: Distribution, network interaction, derivative works, static or dynamic linking, mere aggregation, consumer products, patents: the eight mechanisms that make a licence bite — or not. Audience: transverse Published 2026-08-20, updated 2026-08-20 This is the page that explains why the same licence changes nature entirely from one product to the next. Eight mechanisms, of which three decide most of the outcome. --- ### 1. Distribution — the principal mechanism Almost every copyleft obligation is conditioned on **transmitting the software to a third party**. GPL-3.0 calls this *conveying*: any act that enables someone else to make or receive copies. **This is distribution:** - shipping a binary, an installer, a package, a firmware image; - publishing a **container image** to a registry, even a private one a third party can reach; - serving **JavaScript to a browser** — it is code, and it changes hands; - providing a **virtual appliance** or a machine image; - deploying at a customer's site, **on-premises**; - transferring to **another legal entity in the group**: a subsidiary is a third party. **This is not distribution:** - running the software on your own servers to deliver a service; - using it internally, including by thousands of employees; - moving it between your own machines. > **The most counter-intuitive consequence in free software law:** you can build an entire > online service on GPL code without any obligation to publish anything. This is the "service > provider loophole", and it is precisely what the AGPL was written to close. --- ### 2. Network interaction Specific to **AGPL-3.0** and **OSL-3.0**. The obligation arises from remote use, with no binary changing hands. Three cumulative conditions under AGPL section 13: 1. the program has been **modified** — or combined with your code, which amounts to the same; 2. users **interact with it remotely over a network**; 3. your version **supports** that interaction. The nuance about unmodified versions is covered in [The families](/en/licensing/families/). Keep the working rule: **in an exposed service, an AGPL component must be treated as a trigger** unless the contrary is demonstrated and documented. --- ### 3. Derivative and combined works This is **the most contested question in the field**, and it must be said plainly: it has no settled European case law for software. Copyleft propagates only to what constitutes a **derivative work** under copyright. What counts as one is the question. **Where there is consensus:** - modifying a component's source creates a derivative work; - copying a substantial portion of code into your file creates a derivative work; - placing two independent programs side by side does not (see mere aggregation). **Where there is no consensus:** **linking**. The Free Software Foundation holds, in its [GPL FAQ](https://www.gnu.org/licenses/gpl-faq.html), that linking a program to a library, statically or dynamically, creates a combined work subject to copyleft. That position is the **licence author's interpretation**, not positive law; part of the doctrine disputes it, particularly for dynamic linking through a stable public interface. **The criteria usually applied**, from most to least contaminating: | Situation | Prevailing analysis | | --- | --- | | Code copied into your file | Derivative work, no debate | | Static linking | Combined work on the majority reading | | Dynamic linking, shared data structures, intimate calls | Combined work per the FSF, contested | | Dynamic linking through a stable, documented interface | Grey zone | | Separate processes over a pipe, socket or HTTP | Generally **not** a derivative work | | Running a program as a subprocess | Generally **not** a derivative work | > **The engineering consequence.** Where a strong-copyleft component is indispensable and you > want to protect the rest of the code, the classic remedy is to **isolate it in a separate > process** communicating over a network or command-line interface. This is not a lawyer's > trick: it is an architectural decision, to be taken early and documented as such. --- ### 4. Mere aggregation Placing several independent programs on the same distribution medium does not create a derivative work. The GPL says so expressly. **Examples of aggregation, therefore no contamination:** - a Linux distribution shipping thousands of packages under different licences side by side; - a **container image** holding your application and, separately, GPL system utilities; - an installer dropping several independent executables. **The limit**: aggregation ends as soon as there is **combination**. An image containing a GPL binary your application merely executes is still aggregation. The same image where your application links to a GPL library is not. Each aggregated component keeps **its own obligations**: aggregation removes neither the attribution duty nor the source obligation for the GPL components present. --- ### 5. Static versus dynamic linking Decisive for the **LGPL**, and for it alone. The LGPL allows a proprietary application to use the library, provided the user can **replace it with a modified version** and have the application run with it. | Mode | What you must supply | | --- | --- | | **Dynamic linking** | Nothing more: the user swaps the shared library. The natural mode. | | **Static linking** | Your application's **object files**, or any equivalent means allowing the user to relink against their own build of the library. | **The blind spot**: many modern ecosystems only know static linking — Go, Rust, JavaScript bundles, mobile apps, most firmware. In those contexts the replacement condition is unreachable in practice, and the LGPL must be treated as strong copyleft. --- ### 6. Consumer products and installation information Specific to **GPL-3.0** and **LGPL-3.0**, section 6 — the "anti-tivoization" clause. If the software is distributed inside a **consumer product**, you must supply the **Installation Information**: the methods, procedures, authorisation keys or other information required to install and execute a modified version on that product. In other words: **if the device refuses to boot software the user has modified, you are not complying with GPL-3.0.** This is the mechanism that makes GPL-3.0 problematic in locked-down embedded systems and on platforms with mandatory code signing — and it explains why so many embedded projects deliberately remain on GPL-2.0. See [Embedded / IoT](/en/licensing/scenarios/embedded-iot/). --- ### 7. Technological protection measures **GPL-3.0, section 3**: the covered work shall not be deemed part of an effective technological measure, and you waive the power to forbid circumvention. Direct consequence: a GPL-3.0 component cannot take part in a digital rights management scheme. A recurring friction point with app distribution platforms and set-top boxes. --- ### 8. Patent clauses and their termination Present in **Apache-2.0** (section 3), **GPL-3.0** (section 11), **MPL-2.0** (section 2.1(b)), **EPL-2.0**. Two effects, usually invisible to engineering teams: - **a grant**: contributors license you their patents covering their contribution; - **a termination**: if you bring patent infringement litigation against a contributor over the software, **you lose that grant**, and sometimes the whole licence. For a company holding a patent portfolio, that second clause is a subject in itself: it can neutralise a litigation strategy. It belongs to the legal department, not to the team choosing the library. --- ### Summary table Which mechanism triggers which family: | Mechanism | Permissive | MPL / EPL | LGPL | GPL | AGPL | | --- | :--: | :--: | :--: | :--: | :--: | | Internal use, no transmission | — | — | — | — | — | | Network exposure, no transmission | — | — | — | — | **✔** | | Binary distribution | Attribution | Modified files | Library + replacement | **Whole work** | **Whole work** | | Static linking | — | — | **✔** object files | ✔ | ✔ | | Locked-down consumer product | — | — | **✔** in v3 | **✔** in v3 | ✔ | | Patent infringement action | Apache: termination | Termination | v3: termination | v3: termination | Termination | ### What to do with this Before approving a component, three questions handle 90 % of cases: 1. **Will this component leave the company in executable form?** 2. **Will it be exposed to users over a network?** 3. **Will it be linked to your code, and how?** The answers identify the applicable [scenario](/en/licensing/scenarios/), and the scenario gives the verdict. ## Organisation URL: https://cra-reference.eu/en/organisation/ Description: Two tooling levels, a target architecture, a RACI matrix, governance bodies, a Legal-Cyber interface contract, metrics and a roadmap. Audience: transverse Published 2026-08-19, updated 2026-08-19 CRA compliance almost never fails on the technology. It fails on the organisation: nobody owns the decision to report, technical documentation is assembled after the product ships, and SBOMs are generated but never aggregated. This section sets out who does what, with which tooling, on which timeline. ### The starting point One page conditions everything else: **[Generate and steer](/en/organisation/two-levels/)**. It separates technical SBOM generation at application level — in the CI/CD chain, at every build — from centralisation for steering at organisation level, in a platform that re-evaluates the portfolio continuously. The CRA requires **both**. Annex I, Part II, point 1 mandates the inventory; points 2, 3, 4 and 7 mandate a continuous process, which a file sitting next to an artefact cannot demonstrate. ### The three trade-offs to settle explicitly They belong to the committee, not to a team: 1. **Who decides to report within 24 hours?** And who decides in their absence, on a Sunday? 2. **Who holds the right of veto over placing on the market** when the technical documentation is incomplete? 3. **Who arbitrates between "fix" and "document in a VEX"** when both are defensible? Until those three answers are written down, compliance rests on individuals rather than on a process — and will not survive the first departure. ### The pages in this section They read in order: the tooling principle, the architecture that follows from it, the split of roles, the bodies that decide, the interface contract between the two teams, the metrics that measure, and the roadmap that sequences. ## Governance bodies URL: https://cra-reference.eu/en/organisation/governance/ Description: CRA committee, PSIRT cell, pre-market review, licence policy review: composition, frequency, agenda and the decisions belonging to each level. Audience: direction Published 2026-08-19, updated 2026-08-19 Four bodies are enough. More dilutes responsibility; fewer pushes technical decisions up to the executive committee. ### The CRA committee **Frequency:** quarterly, plus an extraordinary session on event. **Composition:** executive sponsor (chair), legal department, CISO, product management, head of PSIRT, procurement as needed. **Standard agenda:** 1. Progress against the [back-planning](/en/cra/timeline/) and gaps. 2. [Metrics](/en/organisation/metrics/): coverage, intervals, exposure. 3. Compliance risk register: new rows, accepted risks. 4. Classification register: new products, reclassifications. 5. Support period register: commitments becoming strained. 6. [Regulatory watch](/en/updates/): what has changed, what it implies. 7. Decisions to arbitrate. 8. Lessons learned from the quarter's incidents and exercises. **Decisions at its level:** portfolio prioritisation, engaging a notified body, tooling budget, accepting a residual risk, arbitration between teams. ### The PSIRT cell **Frequency:** standing, activated on event. **Standby composition:** head of PSIRT, technical on-call, legal on-call. **Active composition:** incident commander, analyst, legal lead, communications, product engineering, leadership where there is commercial impact. **Activation procedure:** defined in [24-hour procedure](/en/cyber/24h-runbook/). The trigger is the qualification of active exploitation or of a severe incident. **Means to guarantee:** live named access to the reporting platform, templates, user notification channel, a tested call list, a room and conferencing facilities. ### The pre-market review **Frequency:** at every placing on the market, and at every substantial modification. **Composition:** legal department (chair), CISO, product management, project lead. **Support:** the [legal checklist](/en/legal/placing-checklist/) and the [technical checklist](/en/cyber/technical-checklist/). **Output:** a **signed record** authorising the CE marking to be affixed, or a reasoned refusal with deadlines. This is the most important body in the arrangement, because it is the only one that **blocks**. ### The licence policy review **Frequency:** quarterly. **Composition:** legal department (chair), CISO, a representative of the development teams. **Agenda:** exceptions reaching expiry, new requests, changes to the lists, upstream licence changes observed, state of the register. **Output:** an updated, versioned policy and an up-to-date exception register. ### Reporting to the executive committee **Frequency:** twice yearly, or on event. **Format:** one page. Three coverage metrics, three risk metrics, the state of the back-planning, the decisions required. **What must not appear:** technical detail, and the number of vulnerabilities detected — a figure that rises as the arrangement improves, and is therefore uninterpretable out of context. ### The principle that binds them Every body produces **written minutes with named decisions**. A decision with no name is not a decision; a meeting with no minutes did not happen, from an inspection's point of view. ## Legal ↔ Cyber interface URL: https://cra-reference.eu/en/organisation/legal-cyber-interface/ Description: The interface contract between the two teams: cross deliverables with deadlines and formats, a shared vocabulary and an escalation path. Audience: transverse Published 2026-08-19, updated 2026-08-19 This is the page that justifies one site addressing two audiences. It formalises what each team owes the other, with deadlines and formats — because an unformalised exchange becomes, under pressure, an exchange that does not happen. ### Cross deliverables #### From Cyber to Legal | Deliverable | Frequency | Format | Deadline | | --- | --- | --- | --- | | Validated, signed **SBOM** | Every shipped version | CycloneDX, plus SPDX export on request | D+1 after release | | Cybersecurity **risk assessment** | Per product, at every major change | Standard document | Before the pre-market review | | Annex I **traceability matrix** | Per product and version | Table | Before the review | | Vulnerability **handling log** and VEX statements | Monthly | Platform export | D+5 | | Security **test reports** | Per campaign | Dated report | D+10 | | **Description of the update mechanism** | Per product | Standard document | Before the review | | **"Actively exploited" qualification** | On event | Qualification sheet | **H+2** | | **Technical justification** of the support period | Per product | Memo | Before the review | #### From Legal to Cyber | Deliverable | Frequency | Format | Deadline | | --- | --- | --- | --- | | **Criticality classification** per product | On entry to the catalogue | Signed sheet | Before development starts | | **Assessment route** chosen | Same | Sheet | Same | | **Licence policy** and lists | Quarterly | Versioned policy | D+5 after the review | | Licence **exception decisions** | On request | Register entry | 5 working days | | **Supplier clauses** obtained | Per contract | Extract from the clause set | On signature | | **Decision on SBOM disclosure** | Per product | Decision | Before placing on the market | | **Reporting decision** and approved wording | On event | SRP form | **H+20**, for submission at H+24 | | **Support period** committed | Per product | Register | Before placing on the market | ### The two critical deadlines Two rows determine compliance with Article 14, and deserve to be displayed: > **H+2** — Cyber passes the qualification to Legal. > **H+20** — Legal returns the decision and approved wording. > **H+24** — the early warning is sent. Any other arrangement of these intervals pushes the uncertainty into the final hours, which is the worst possible moment. ### Shared vocabulary Five terms the two teams use differently, whose common definition must be written down: | Term | Cyber sense | Legal sense | **Agreed definition** | | --- | --- | --- | --- | | **Vulnerability** | Any weakness a tool detects | An exploitable weakness creating risk | A weakness in a component; its **exploitability** is qualified separately by a VEX | | **Incident** | Any security alert | An event to be notified | An event that actually compromises product security; "severe" is a separate qualification | | **Product** | A repository, a service, an artefact | What is placed on the market under your brand | What is **placed on the market**, within the meaning of Article 3 | | **Version** | A build identifier | A commercial reference | Both, **explicitly linked** in the register | | **Support** | Operational maintenance | The support period under Article 13 | Always say which: "commercial support" or "**regulatory support period**" | The table looks trivial. It prevents incidents where one team says "the product is supported" while the other hears "you have a legal obligation to supply fixes". ### The escalation path Where disagreement persists on a qualification, a reporting decision or a VEX arbitration: 1. **Head of PSIRT and legal lead**, within two hours during an incident. 2. **CISO and general counsel**, within four hours. 3. **Executive sponsor**, within eight hours. 4. If unresolved within the intervals compatible with the legal deadline: **the default rule applies** — report, do not place on the market, do not lift the block. The default rule is what makes escalation safe: it guarantees that a disagreement never produces a breach through inaction. ## Metrics URL: https://cra-reference.eu/en/organisation/metrics/ Description: Coverage, performance, risk and readiness: which metrics to track, which to avoid, and a mock-up of the leadership dashboard. Audience: direction Published 2026-08-19, updated 2026-08-19 ### Coverage metrics The first to look at: they tell you whether the arrangement exists. | Metric | Target | Source | | --- | --- | --- | | Share of products **qualified as PDEs** | 100 % | Qualification register | | Share of products **classified** | 100 % | Classification register | | Share of products with an **automated SBOM** | 100 % of active products | Platform | | Share of SBOMs above the **quality threshold** | 100 % | Platform | | Share of products under **continuous monitoring** | 100 % of shipped versions | Platform | | Share of products with a **declared support period** | 100 % | Register | | Share of products with **complete technical documentation** | 100 % before market entry | Compliance tracking | | Share of class II / Critical products with a **notified body engaged** | 100 % | Register | ### Performance metrics They tell you whether the arrangement works. | Metric | Indicative target | | --- | --- | | Median **detection** interval (publication → your alert) | < 24 h | | Median **triage** interval (alert → decision) | < 5 days | | Median **remediation** interval, by severity | Per [SLAs](/en/cyber/vulnerability-management/) | | Share of **SLAs met** | > 90 % | | **Average age** of open vulnerabilities | Steadily falling | | **Ratio of actionable alerts** to raw alerts | Steadily rising | | Interval achieved at the last **reporting exercise** | < 12 h for the early warning | | Interval achieved at the last **retrieval exercise** | < 1 working day | ### Risk metrics They tell you what remains exposed. | Metric | Meaning | | --- | --- | | Number of components **at end of maintenance** inside supported products | Direct regulatory liability | | Number of **single-maintainer** components in critical products | Takeover or abandonment risk | | Number of **licences out of policy**, with no active exception | Intellectual property risk | | Number of **expired exceptions** not dealt with | Process defect | | Number of **support periods** with a limiting component ending earlier | Untenable commitments | | Estimated **financial exposure** | See [Exposure](/en/legal/exposure/) | ### Readiness metrics | Metric | Source | | --- | --- | | Days remaining before each legal deadline | [Timeline](/en/cra/timeline/) | | Back-planning progress, by wave | [Roadmap](/en/organisation/roadmap/) | | Date of the last reporting exercise | Exercise reports | | Date of the last retrieval exercise | Exercise reports | | [Self-assessment](/en/self-assessment/) score by module | Quarterly assessment | ### Metrics not to track | Misleading metric | Why | | --- | --- | | **Number of vulnerabilities detected** | It rises as the arrangement improves. Presenting it to a committee creates a perverse incentive to detect less. | | **Number of SBOMs generated** | Without coverage and quality it is a file counter. | | **Number of alerts closed** | Closing an alert without handling it removes it from the counter. | | **Overall security score** | A non-actionable aggregate that hides variation between products. | ### Leadership dashboard mock-up One page, four blocks. ``` ┌──────────────────────────────┬──────────────────────────────┐ │ COVERAGE │ DEADLINES │ │ │ │ │ Products classified ██ % │ Reporting operational ✓ │ │ SBOM automated ██ % │ Full application: D-___ │ │ Monitoring active ██ % │ Notified bodies __/__ │ │ Files complete ██ % │ Back-planning: wave __/6 │ ├──────────────────────────────┼──────────────────────────────┤ │ PERFORMANCE │ OPEN RISKS │ │ │ │ │ Critical remediation __ d │ Abandoned components __ │ │ SLAs met __ % │ Licences out of policy __ │ │ Last 24 h exercise __ h │ Untenable support __ │ │ Actionable alerts __ % │ Estimated exposure __ €m │ └──────────────────────────────┴──────────────────────────────┘ Decisions required from the committee: … ``` ### The keeping rule Every metric has a **named owner**, a **single source** and an **update frequency**. A metric computed by hand the day before the committee is not a metric: it is an estimate. ## Who does what — RACI matrix URL: https://cra-reference.eu/en/organisation/raci/ Description: The split of roles across the twenty activities of the arrangement, and the three trade-offs the committee must settle explicitly. Audience: transverse Published 2026-08-19, updated 2026-08-19 **R** responsible for execution · **A** accountable for the outcome · **C** consulted · **I** informed. | Activity | Dev | DevSecOps | PSIRT | CISO | Legal | Product | Procurement | Leadership | | --- | --- | --- | --- | --- | --- | --- | --- | --- | | PDE qualification | | | | C | **A/R** | C | | I | | Criticality classification | | | | **R** | **A** | C | | I | | Choice of assessment route | | | | C | **A/R** | C | | I | | Contracting a notified body | | | | C | **R** | I | C | **A** | | Risk assessment | C | C | C | **A/R** | C | C | | I | | SBOM generation | **R** | **A/R** | I | C | I | | | | | SBOM quality validation | R | **R** | | **A** | I | | | | | Licence policy | I | C | | C | **A/R** | C | C | I | | Licence exception handling | R | C | | C | **A** | C | | | | Vulnerability triage | C | R | **A/R** | C | I | I | | | | Producing VEX statements | **R** | C | **A** | C | C | | | | | **Decision to report** | | | **R** | C | **A** | I | | I | | Drafting and sending the report | | | **A/R** | C | **C** | I | | I | | Relations with authorities | | | C | C | **A/R** | I | | I | | Compiling the technical documentation | C | C | C | **R** | **A** | C | | I | | Signing the EU declaration | | | | C | **R** | I | | **A** | | Affixing the CE marking | | | | I | **A/R** | R | | I | | Determining the support period | C | | | C | **R** | R | C | **A** | | Publishing security advisories | C | | **A/R** | C | C | I | | | | Managing the CVD policy | | | **A/R** | C | **C** | I | | I | | Supplier clauses | | | | C | **A/R** | C | **R** | I | | Evidence archiving | | R | | C | **A/R** | | | I | ### Reading the matrix Three principles follow. **Legal approves, Cyber executes — except on triage.** The technical qualification of a vulnerability belongs to the PSIRT, which is accountable for it. The decision to report belongs to Legal. The line is clean and must stay clean. **Executive management approves three things only**: engaging a notified body, the support period, and signing the declaration. Those are the three decisions that commit the company financially over several years. **Nobody works alone.** Every row has at least one consulted party. An activity with no cross-consultation will produce a deliverable the next stage cannot use. ### The three trade-offs to settle explicitly They do not follow from the matrix: they require a written committee decision. #### 1. Who decides to report within 24 hours, and who decides in their absence? The answer must name a **person**, a **deputy**, and provide for a **written delegation**. A 24-hour deadline does not accommodate escalation up the hierarchy on a Sunday. See [Reporting duties](/en/legal/reporting-duties/). #### 2. Who holds the right of veto over placing on the market? If nobody can block a market launch, the technical documentation will be assembled afterwards. Recommended position: **the legal department**, on the basis of the [checklist](/en/legal/placing-checklist/), with an override available only through a written decision of executive management — which then becomes an entry in the risk register. #### 3. Who arbitrates between fixing and documenting in a VEX? Both are defensible; cost and risk differ. Recommended position: the **PSIRT approves** the VEX status, with escalation to the CISO on disagreement with the product team, and notice to Legal as soon as the vulnerability is public. ### What to write down The matrix above, **completed with names** — function and person, with a deputy for every critical role. A matrix in generic functions does not survive the first departure; a named matrix gets updated, which forces vacancies to be noticed. ## Roadmap URL: https://cra-reference.eu/en/organisation/roadmap/ Description: Six deployment waves, from scoping to continuous improvement, with milestones, deliverables and the dependencies between them. Audience: direction Published 2026-08-19, updated 2026-08-19 Six waves. They overlap in part, but their **dependencies are strict**: a wave whose prerequisite is unmet produces unusable work. ### Wave 0 — Scoping **Objective:** know what you are talking about and who decides. | Deliverable | Owner | | --- | --- | | Portfolio **PDE qualification register** | Legal | | Criticality **classification register** | Legal + CISO | | Choice of **assessment routes** | Legal | | Named [RACI matrix](/en/organisation/raci/) approved | Sponsor | | [Governance bodies](/en/organisation/governance/) established | Sponsor | | Choice of **pivot format** and toolchain | CISO | | **Licence policy** v1 | Legal | **Do not proceed without:** the classification. Without it you do not know which products need a notified body — that is, what the critical path is. ### Wave 1 — Respond **Placed second deliberately:** the reporting deadline is the nearest, and it applies to the legacy portfolio. | Deliverable | Owner | | --- | --- | | Technical and legal **on-call rota**, with written delegation | Sponsor | | Live **accounts** on the reporting platform, tested | PSIRT | | Reporting **templates** | PSIRT + Legal | | Decision **register** | Legal | | [CVD policy](/en/cyber/disclosure-policy/) published, `security.txt` online | PSIRT | | **First timed exercise** | PSIRT | | **List of Member States** where each product is made available | Product | ### Wave 2 — Generate | Deliverable | Owner | | --- | --- | | **Automated SBOM** on priority chains | DevSecOps | | **Quality validation** and blocking thresholds | CISO | | **Signing** and provenance attestation | DevSecOps | | **Tooling sheets** per product family | CISO | **Prerequisite:** the pivot format is chosen (wave 0). ### Wave 3 — Steer | Deliverable | Owner | | --- | --- | | **Steering platform** in production | CISO | | **Automatic ingestion** from every chain | DevSecOps | | **Vulnerability sources** connected | CISO | | **Continuous monitoring** active on shipped versions | CISO | | **Policies** in warning mode, then blocking | CISO + Legal | | **Alert routing** to owning teams | PSIRT | **Prerequisite:** generation produces quality SBOMs (wave 2). Deploying the platform earlier is possible and even advisable, but activating it on poor SBOMs discredits the tool. ### Wave 4 — Prove | Deliverable | Owner | | --- | --- | | Pilot **technical documentation** for two representative products | Legal + CISO | | **Notified bodies** engaged and assessments launched | Legal | | Annex II **user notices** | Product + Legal | | **Support periods** determined and communicated | Product + Legal | | **EU declarations** and CE marking | Legal | | **Evidence vault** with ten-year archiving | Legal + DevSecOps | | **First successful retrieval exercise** | Legal | **Prerequisite:** waves 0, 2 and 3. Technical documentation is assembled from existing artefacts; writing it before they exist produces a declaratory document with no evidence behind it. ### Wave 5 — Sustain | Deliverable | Owner | | --- | --- | | Structured **regulatory watch**, with impact assessed | Legal | | **Periodic reviews**: classification, licences, support | Legal | | Six-monthly **exercises**: reporting, retrieval | PSIRT | | **Continuous improvement** of the actionable-alert ratio | CISO | | **Extension** of scope to new products, by default | Everyone | This is the wave with no end, and the one that gets left out of the budget. An unmaintained compliance arrangement degrades within eighteen months. ### The dependencies, in one diagram ``` Wave 0 — Scoping │ ├──► Wave 1 — Respond (independent, nearest deadline) │ └──► Wave 2 — Generate │ └──► Wave 3 — Steer │ └──► Wave 4 — Prove │ └──► Wave 5 — Sustain ``` ### What to decide now Three actions cannot wait, because their lead time is not yours to control: 1. **Contract notified bodies** for class II and Critical products. 2. **Arm the reporting on-call rota**, if that is not done. 3. **Classify the portfolio**, without which point 1 is impossible. The rest can be sequenced. Those three cannot. ## Target architecture URL: https://cra-reference.eu/en/organisation/target-architecture/ Description: End-to-end flows from code repository to evidence vault; control points, data sovereignty, and three scenarios by maturity. Audience: cyber Published 2026-08-19, updated 2026-08-19 ### The end-to-end picture ``` Code repositories │ ▼ CI/CD chain ──► SBOM generation ──► validation ──► signing │ │ │ ▼ │ Artefact registry │ (artefact + SBOM + signature) ▼ │ Steering platform ◄──────────── ingestion ───────────┘ ▲ │ │ ├──► policy engine ──────► CI (blocking) │ ├──► targeted alerts ────► ticketing tool │ ├──► dashboards ─────────► leadership │ └──► exports ────────────► technical documentation │ Vulnerability sources EUVD · OSV · NVD · vendor advisories · confirmed-exploitation catalogues Evidence vault (10-year archive, immutable, indexed) ▲ └── signed SBOMs · VEX · technical files · declarations · registers ENISA single reporting platform ◄── 24 h / 72 h warnings, reports Customer portal ◄── SBOMs · security advisories (CSAF) · VEX ``` ### The flows, one by one | Flow | From → to | Protocol | Frequency | Owner | | --- | --- | --- | --- | --- | | SBOM publication | CI → platform | API | Every publishable build | Product team | | Vulnerability ingestion | Sources → platform | Feeds and API | Daily | CISO | | Policy decision | Platform → CI | API | Every build | CISO | | Alert | Platform → tickets | API | On event | PSIRT | | Evidence export | Platform → vault | Signed export | Every shipped version | Compliance | | Reporting | PSIRT → ENISA platform | Dedicated interface | On event | PSIRT + Legal | | Customer publication | Platform → portal | CSAF export | Every advisory | PSIRT | ### Control points | Point | Condition to pass | Who can override | | --- | --- | --- | | Publishable build | Valid SBOM, score above threshold, signature present | Nobody — a technical prerequisite | | Promotion to production | No critical exploitable vulnerability without a VEX; no denied licence | CISO (vulnerabilities), Legal (licences), via a dated waiver | | Placing on the market | [Legal checklist](/en/legal/placing-checklist/) complete | Legal, in a formal review | ### Sovereignty and data location Three questions to settle explicitly and document: 1. **Where are your SBOMs hosted?** They describe the composition of your products; aggregated, they are sensitive information. 2. **What data leaves the Union?** A hosted platform outside Europe implies a transfer, with the contractual and, where relevant, regulatory consequences that follow. 3. **What happens if the platform is unavailable?** Should builds fail? The degraded mode must be defined, tested, and its maximum acceptable duration set. A robust answer keeps everything with evidential value in the **internal evidence vault**, independently of the platform. The platform is a working tool; the vault is the company's memory. ### Three scenarios by maturity #### Minimal — open tooling, zero software cost Open generator in CI, self-hosted steering platform, evidence vault on existing object storage in immutable mode, manual reporting with templates. **For whom:** a limited portfolio, mostly default-category products, a small security team. **Cost:** essentially operations and engineering time. **Limits:** little file-content licence detection, no reachability analysis, correlation to refine. #### Intermediate — hybrid Open generation, open steering platform, complemented by a commercial product on the **licence and intellectual property** side, which is where the gap between open and commercial offerings is widest. **For whom:** a diverse portfolio, customer requirements on licence compliance. #### Complete — enterprise platform Integrated commercial platform, reachability analysis, file-hash detection, integration with the artefact registry, customer portal. **For whom:** important or critical products, a large installed base, strong contractual requirements, a staffed PSIRT. The choice follows the grid in [Selection criteria](/en/tooling/selection/). The recommendation is to **start with the minimal scenario**: it validates the processes, reveals the real needs, and provides a factual baseline for any later evaluation. ## Generate and steer: the two levels URL: https://cra-reference.eu/en/organisation/two-levels/ Description: The founding distinction between technical SBOM generation at application level and centralisation for steering at organisation level. The CRA requires both. Audience: transverse Legal basis: Annex I, Part II, point 1 — inventory · Annex I, Part II, points 2, 3, 4 and 7 — continuous process Published 2026-08-19, updated 2026-08-19 This is the most expensive misunderstanding in the field, and the page that conditions everything else. Many organisations buy a platform without reliable generation, or generate thousands of SBOMs that nobody aggregates. ### The diagram ``` ┌─────────────────────────────────────────────────────────────────┐ │ LEVEL 1 — APPLICATION / TEAM « GENERATE » │ │ │ │ Where? In the CI/CD chain, at every build │ │ Who? The development team, DevSecOps │ │ What? Produce a faithful inventory of THIS artefact │ │ Tools Syft · Trivy · Grype · cdxgen · osv-scanner · │ │ native Maven, Gradle, npm, .NET, Cargo plugins │ │ Output A signed CycloneDX or SPDX file, tied to the artefact │ │ Grain 1 SBOM = 1 artefact = 1 build │ │ Time Instant, frozen, immutable │ └──────────────────────────────┬──────────────────────────────────┘ │ automated ingestion (API) ▼ ┌─────────────────────────────────────────────────────────────────┐ │ LEVEL 2 — ORGANISATION / PORTFOLIO « STEER » │ │ │ │ Where? In a central platform, continuously │ │ Who? CISO, PSIRT, Compliance, Product management │ │ What? Aggregate, retain, correlate daily, decide │ │ Tools OWASP Dependency-Track · Snyk · FOSSA · │ │ Black Duck · Mend · Sonatype · JFrog Xray │ │ Output Portfolio view, targeted alerts, VEX, reports, │ │ items for the technical file and for authorities │ │ Grain N products × M versions × K components │ │ Time Continuous, historised, re-evaluated daily │ └─────────────────────────────────────────────────────────────────┘ ``` ### The six differences | | **Application level — generate** | **Organisation level — steer** | | --- | --- | --- | | **Question asked** | "What is inside this artefact?" | "Which of your products contain this component?" | | **Trigger** | A build | A newly published vulnerability | | **Owner** | Product team | PSIRT, CISO, Compliance | | **Frequency** | Every publishable build | Daily re-evaluation of the estate | | **Output** | A file | A dashboard, alerts, reports, an API | | **Without it** | No data: nothing is possible | Thousands of unusable files | ### What each level demonstrates under the CRA | Requirement | Level that covers it | | --- | --- | | Annex I, Part II, point 1 — component **inventory** | **Generation** | | Annex VII — SBOM in the **technical documentation** | **Generation** (+ archiving) | | Annex I, Part II, point 2 — address vulnerabilities **without delay** | **Steering** | | Annex I, Part II, point 3 — **regular** tests and reviews | Both | | Annex I, Part II, point 4 — **publish** advisories | **Steering** | | Art. 14 — **report** within 24 h knowing the affected scope | **Steering** | | Answering an **authority request** about an old version | **Steering** (+ archiving) | > **The CRA requires both.** Point 1 mandates the inventory; points 2, 3, 4 and 7 mandate a > continuous process, which a file sitting next to an artefact cannot demonstrate. ### The classic mistake, named > "You put a scanner in CI, you are compliant." No. A scanner in CI tells you what is wrong **now, here, in this build**. It does not tell you: - which **versions already shipped** to customers contain the vulnerable component; - what has become vulnerable **since** the last build, without any code changing; - what **affected scope** to declare in a 24-hour early warning; - what version **4.2.1 shipped in 2028** contained, when an authority asks in 2033. The mirror mistake also exists: buying a platform without reliable generation. The platform then displays misleading coverage, fed by partial SBOMs produced by hand. ### The message by audience **For Legal.** Level 1 produces the **item in the technical documentation**. Level 2 produces the **evidence of the continuous process**. Without the first, the file is incomplete; without the second, you can neither answer an authority nor meet a 24-hour deadline. **For Cyber.** Do not confuse the scanner with the platform. These are not two competing products: they are a chain, and the missing link is almost always the second. **For leadership.** Two budget lines, two owners, two timelines. Level 1 is deployed team by team, gradually. Level 2 is a **cross-cutting platform** that must exist before SBOMs pile up with nowhere to go. ### Deployment order 1. **Choose the pivot format** and pin the toolchain per product family. 2. **Deploy the steering platform**, even minimally, before generalising generation. 3. **Generalise generation**, publishing systematically to the platform. 4. **Turn on continuous monitoring** once coverage is meaningful. 5. **Add blocking policies**, in warning mode first, then blocking. Deploying in that order avoids the most common situation: teams that have diligently generated SBOMs for eighteen months, while nobody can answer the question that matters. ## Resources URL: https://cra-reference.eu/en/resources/ Description: The templates, models, registers, checklists and response cards to reuse: technical documentation, EU declaration, user notice, CVD policy, reporting templates, contract clauses. Audience: transverse Published 2026-08-19, updated 2026-08-19 Every template cited on this site, in one place. Each links to the page that explains it and gives its detailed content. ### Qualification and classification | Template | Content | Reference page | | --- | --- | --- | | **PDE qualification sheet** | Nature of the product, connection, remote data processing, commercial character, status, signatories | [Scope](/en/cra/scope-pde/) | | **Exclusion sheet** | Sectoral text relied on, justification, signatories | [Exclusions](/en/cra/exclusions/) | | **Classification sheet** | Actual functionality, annexes examined, class retained, assessment route | [Classification method](/en/cra/criticality-classes/method/) | | Portfolio **classification register** | Consolidated view, annual review | Same | ### Conformity and market entry | Template | Content | Reference page | | --- | --- | --- | | **Technical documentation template** | Eight-section structure per Annex VII | [Technical documentation](/en/cra/technical-documentation/) | | **File completeness checklist** | Thirteen points to tick | Same | | **EU declaration of conformity** | Annex V template, French and English | [Declaration](/en/legal/declaration-of-conformity/) | | **Simplified declaration** | Annex VI template | Same | | **Cybersecurity notice** | Ten-section Annex II template | [User information](/en/legal/user-information/) | | **Legal checklist** | Fifteen points, printable, signable | [Checklist](/en/legal/placing-checklist/) | | **Technical checklist** | Fifteen points, printable | [Technical checklist](/en/cyber/technical-checklist/) | | **Conformity review record** | Structure and signatures | [Internal process](/en/legal/ce-and-documentation/) | ### Vulnerabilities and reporting | Template | Content | Reference page | | --- | --- | --- | | **Coordinated disclosure policy** | Eleven-section structure | [Disclosure policy](/en/cyber/disclosure-policy/) | | **`security.txt` file** | RFC 9116 template | Same | | Active-exploitation **qualification sheet** | To pass to Legal within two hours | [24-hour procedure](/en/cyber/24h-runbook/) | | **Early warning template** (24 h) | Minimum fields | Same | | **Notification template** (72 h) | Minimum fields | Same | | **Final report template** (14 d / 1 month) | Minimum fields | Same | | Crisis **response card** | A4 format, for display | Same | | **Reporting register** | Decisions, reasoning, acknowledgements | [Reporting duties](/en/legal/reporting-duties/) | ### SBOM and tooling | Template | Content | Reference page | | --- | --- | --- | | **SBOM quality policy** | Format, depth, thresholds, waivers | [Quality](/en/sbom/quality/) | | **Tooling sheet** per product family | Tools, commands, scope, exclusions | [Generating SBOMs](/en/cyber/generating-sboms/) | | **Annotated SBOM examples** | CycloneDX and SPDX | [Formats](/en/sbom/formats/) | | **VEX example** | Statuses and justifications | [VEX](/en/sbom/vex/) | | **Tool evaluation grid** | Weighted criteria and protocol | [Selection criteria](/en/tooling/selection/) | ### Intellectual property | Template | Content | Reference page | | --- | --- | --- | | **Licence policy** | Three lists by context of use | [Intellectual property](/en/legal/intellectual-property/) | | **Exception register** | Component, licence, conditions, expiry | Same | | Open source component **diligence grid** | Nine criteria | [Integrating open source](/en/cra/open-source/integrating-oss/) | | Steward **self-qualification grid** | Six questions | [Steward](/en/cra/open-source/steward/) | | Open source **contribution policy** | Framework for employee contributions | [Individual developer](/en/cra/open-source/individual-developer/) | ### Contracts | Template | Content | Reference page | | --- | --- | --- | | **Supplier clause set** | SBOM, deadlines, support, compliance, reversibility, liability | [Contract clauses](/en/legal/contract-clauses/) | | **Customer clauses** | Support, SBOM, notification, limitation | Same | ### Governance | Template | Content | Reference page | | --- | --- | --- | | **RACI matrix** | Twenty-two activities, eight roles | [RACI](/en/organisation/raci/) | | Legal ↔ Cyber **interface contract** | Cross deliverables, deadlines, vocabulary | [Interface](/en/organisation/legal-cyber-interface/) | | **Support period register** | Commitments and limiting components | [Support period](/en/cra/support-period/) | | **Compliance risk register** | Risks, measures, named acceptances | [Exposure](/en/legal/exposure/) | | **Leadership dashboard** | Four blocks, one page | [Metrics](/en/organisation/metrics/) | | **Back-planning** | Six waves and their dependencies | [Roadmap](/en/organisation/roadmap/) | ### How to use them These templates are **structures**, not documents to sign as they stand. Each must be adapted to your organisation, reviewed by the owning function, then **versioned**. A template reused without adaptation produces a generic document, which is exactly what a market surveillance authority spots first. ## SBOM URL: https://cra-reference.eu/en/sbom/ Description: The software bill of materials: definition, CRA requirement, CycloneDX and SPDX formats, types, quality, identifiers, VEX, SPDX licensing, signing, distribution and life cycle. Audience: transverse Legal basis: Annex I, Part II, point 1 · Annex VII, point 2 Published 2026-08-19, updated 2026-08-19 An **SBOM** (software bill of materials) is a structured, formal, machine-readable inventory of the software components contained in a product, and of their relationships. This section is the technical reference for it. It is written to be read by both teams: [Definition](/en/sbom/definition/), [What the CRA requires](/en/sbom/cra-requirement/), [VEX](/en/sbom/vex/) and [Licensing as SBOM data](/en/sbom/spdx-licences/) need no engineering background; the others familiarity with a build chain. ### Why this became a regulatory topic The CRA did not invent the SBOM; it made an already widespread practice mandatory by writing it into the essential requirements: > **Annex I, Part II, point 1** — identify and document vulnerabilities and components > contained in the product, **including by drawing up a software bill of materials in a > commonly used and machine-readable format covering at the very least the top-level > dependencies** of the product. Three phrases are decisive, and each has an operational consequence: - **"commonly used format"** — in practice **[CycloneDX](https://cyclonedx.org/)** or **[SPDX](https://spdx.dev/)**. A spreadsheet is not one. - **"machine-readable"** — JSON, XML, tag-value. A PDF is not machine-readable. - **"at the very least the top-level dependencies"** — this is a **legal floor, not a target**. Supply chain attacks travel mostly through transitive dependencies. ### The value chain, in one line **SBOM → technical documentation (Annex VII) → EU declaration of conformity (Annex V) → CE marking → the right to sell in the Union.** That is the sentence to keep on the Legal side: the SBOM is not a side deliverable for engineers, it is **a constituent part of the file that yields the CE marking**. ### What an SBOM is not - **Not a vulnerability report.** It is the data that makes one possible. - **Not a licence audit.** It is the data that makes one possible. - **Not proof that there is no malicious code.** A component can be correctly inventoried and compromised — see [Supply chain risk](/en/cyber/supply-chain-risk/). ### The reality test One question is enough to measure your maturity: **how long did it take you, last time, to answer "are you affected by this vulnerability?"** Without a centralised SBOM the answer takes weeks and rests on emails. With one it takes minutes and rests on a query. ## What the CRA requires of the SBOM URL: https://cra-reference.eu/en/sbom/cra-requirement/ Description: The exact text, a reading of its three key phrases, the publication question, the Commission's empowerment, and the chain that leads to CE marking. Audience: transverse Legal basis: Annex I, Part II, point 1 · Annex VII, point 2 · Art. 13 — empowerment to specify the SBOM format Published 2026-08-19, updated 2026-08-19 ### The text > **Annex I, Part II, point 1** — Manufacturers of products with digital elements shall > **identify and document vulnerabilities and components** contained in those products, > **including by drawing up a software bill of materials in a commonly used and > machine-readable format covering at the very least the top-level dependencies** of the > products. ### Reading it #### "commonly used format" In practice two formats meet the criterion: **[CycloneDX](/en/sbom/formats/cyclonedx/)** and **[SPDX](/en/sbom/formats/spdx/)**. Both are standardised, widely tooled and interoperable. A spreadsheet, a list in a document, or a platform's proprietary export are not commonly used formats within the meaning of the requirement. #### "machine-readable" JSON, XML, YAML, tag-value. **A PDF is not machine-readable**, even when it contains a table. The criterion is not human legibility but the ability of a program to extract structured data without heuristics. #### "at the very least the top-level dependencies" This is a **legal floor, not a target**. Top-level dependencies are the ones you declare explicitly. **Transitive** dependencies — those your dependencies drag in — are typically ten to a hundred times more numerous, and **most supply chain incidents travel through them**. An SBOM limited to the top level satisfies the letter of the requirement and misses its point. The position to hold is **full depth**, with an explicit distinction between direct and transitive — see [Quality and completeness](/en/sbom/quality/). ### Must the SBOM be published? **No.** The Regulation does not require publishing the SBOM. It requires it to be in the **[technical documentation](/en/cra/technical-documentation/)**, held at the disposal of market surveillance authorities. Communicating it to customers is a **commercial and contractual decision**, covered in [Distribution and confidentiality](/en/sbom/distribution/). Annex II does, however, provide that the information to the user state, **where applicable**, where the SBOM can be obtained — which presupposes that the question has been settled. ### What the Commission may still specify The Regulation empowers the Commission to **specify, by implementing act, the format and elements** of the software bill of materials. Such an act would set a common baseline and reduce today's uncertainty about the level of detail expected. > **Consequence for the choice adopteds.** Producing a **rich** SBOM today — full depth, licences, > hashes, relationships — is the robust position: a later implementing act will never ask for > less than what the standard formats already allow you to express. ### The chain to remember **SBOM → technical documentation (Annex VII) → EU declaration of conformity (Annex V) → CE marking → the right to sell in the Union.** That is the phrasing to use on the Legal side. It turns the SBOM from an engineering topic into a **market access prerequisite**. ### What necessarily accompanies the SBOM Annex I, Part II, point 1 does not stand alone. An SBOM without points 2 to 8 demonstrates nothing: the vulnerabilities identified must also be **handled**, advisories **published**, a **CVD policy** maintained and fixes **distributed**. See [Vulnerability handling](/en/cra/essential-requirements/vulnerability-handling/). ## What an SBOM is URL: https://cra-reference.eu/en/sbom/definition/ Description: A definition both teams can read, the minimum data expected per component, uses by audience, and what an SBOM is not. Audience: transverse Published 2026-08-19, updated 2026-08-19 ### The definition An **SBOM** (software bill of materials) is a **structured, formal, machine-readable inventory of the software components contained in a product and of their relationships**. The ingredient-label analogy is useful for framing the idea and misleading beyond that: a label is static and read by eye; an SBOM changes with every build and is only valuable when processed by a machine. ### The data expected per component | Data | Why it matters | | --- | --- | | **Name** | Human identification | | **Version** | Without a version, no correlation with a vulnerability is possible | | **Supplier or publisher** | Distinguishes two components with the same name | | **Unique identifier** — [PURL, CPE](/en/sbom/identifiers/) | Enables automatic correlation | | **Cryptographic hashes** | Ties the inventory to the actual artefact | | **Licence** as an [SPDX](/en/sbom/spdx-licences/) identifier | Legal compliance and intellectual property | | **Dependency relationships** | Distinguishes direct from transitive, traces how a component got in | | **Author of the inventory and timestamp** | Traceability, enforceability | An inventory without versions or resolvable identifiers is not a usable SBOM: it is a list of names. ### Uses, by audience | Audience | What the SBOM enables | | --- | --- | | **Legal** | Compile the technical documentation, demonstrate licence compliance, answer customer questionnaires and investor diligence | | **Cyber / PSIRT** | Answer "are you affected?" in minutes, prioritise, produce VEX statements, feed the reporting process | | **Procurement** | Run supplier diligence, compare offers on a factual basis | | **Product** | Track obsolescence, anticipate component end of support, arbitrate technical debt | | **Leadership** | Measure portfolio exposure, track coverage metrics | ### What an SBOM is not - **Not a vulnerability report.** It is the input that makes one possible, by matching the inventory against databases that change daily. - **Not a licence audit.** It is the data that makes one possible. - **Not proof that there is no malicious code.** A component can be correctly inventoried and compromised. The SBOM answers "what is inside", not "is it clean". - **Not a static document.** An SBOM belongs to a specific **build**. An SBOM "of the product", with no version, is meaningless. ### The reality test One question tells an organisation where it stands: **how long did it take you, last time, to answer "are you affected by this vulnerability, and in which shipped versions?"** - Several weeks, by email and spreadsheet: you have no usable SBOM. - A few days, by asking each team: you generate SBOMs but do not centralise them. - A few minutes, by running a query: the arrangement described in [Generate and steer](/en/organisation/two-levels/) is in place. ## Distribution and confidentiality URL: https://cra-reference.eu/en/sbom/distribution/ Description: Should you publish your SBOM? Disclosure levels, contract clauses, the confidentiality regime for information given to authorities, and the decision matrix. Audience: legal Legal basis: Annex VII — technical documentation held at the disposal of authorities · Annex II, point 10 — where the SBOM can be obtained · Art. 66 — confidentiality Published 2026-08-19, updated 2026-08-19 ### What the Regulation requires — and does not **Requires**: that the SBOM be in the **technical documentation**, held at the disposal of market surveillance authorities. **Does not require**: publishing it, nor systematically providing it to customers. **Does provide, however**: that the information to the user state, **where applicable**, where the SBOM can be obtained (Annex II). The wording therefore presupposes that the question has been settled and can be answered. ### The debate: does an SBOM help the attacker? The argument against publication is that an SBOM reveals the exact composition of the product and makes targeting easier. It deserves examination, not dismissal. **What weakens it:** - a motivated attacker determines a binary's composition by analysis, without your help; - component vulnerabilities are **public by construction**; - the asymmetry works against you if you do not know your own composition as well as the attacker does. **What strengthens it:** - a **dated** public SBOM makes it easy to spot products that have not been updated; - it facilitates mass targeting by automated market scanning; - it may reveal trade-secret information — architecture, suppliers, technical choices. A reasonable position: **the SBOM is not a secret, but broad distribution without accompanying VEX is poor practice**. Publishing a raw inventory without saying what is exploitable transfers the noise to your customers. ### Disclosure levels | Level | Recipient | When | | --- | --- | --- | | **Internal** | Teams, steering platform | Always | | **Authorities on request** | Market surveillance, notified body | Mandatory | | **Customer under NDA** | Large account, regulated sector | On contractual request | | **Customer via authenticated portal** | Installed base | Recommended standard policy | | **Public** | Everyone | Explicit decision, product by product | The authenticated portal is the right default balance: it satisfies legitimate customer demand, logs access, and allows the SBOM to be supplied **with the VEX statements and advisories**, which is far more useful than an inventory on its own. ### Contract clauses On the **customer** side, what must be written: - the **format** and version supplied; - the **depth** covered, and an honest completeness declaration; - the **update frequency** — per shipped version, or at a defined interval; - **access arrangements**: portal, on request, with or without authentication; - **confidentiality** and a prohibition on redistribution; - the relationship with **security advisories** and VEX statements. On the **supplier** side, the mirror clauses you require are in [Contract clauses](/en/legal/contract-clauses/). ### Confidentiality on the authority side The Regulation frames the use of information obtained by authorities, notified bodies and ENISA: it is handled with respect for **trade secrets** and **intellectual property rights**, and used only so far as necessary to carry out their tasks. That does not remove the need to mark transmitted documents explicitly and to log exchanges. ### The decision matrix | Criterion | Towards restriction | Towards openness | | --- | --- | --- | | Nature of the product | Security component, critical product | Consumer product | | Installed base | Small and identified | Large and anonymous | | Customer demand | Absent | Contractual and recurring | | Maturity of your VEX practice | Low: publishing would create noise | High: publishing reduces enquiries | | Positioning | Composition secrecy is an advantage | Transparency is a commercial argument | The decision is taken **per product**, documented, and reviewed annually. It belongs jointly to Legal and product management, not to engineering alone. ## Formats URL: https://cra-reference.eu/en/sbom/formats/ Description: CycloneDX and SPDX: origins, standardisation, respective strengths, comparison, and the choice of a pivot format with export to the other. Audience: cyber Legal basis: Annex I, Part II, point 1 — 'commonly used and machine-readable format' Published 2026-08-19, updated 2026-08-19 Two formats meet the Regulation's requirement. Both are legitimate, standardised and widely tooled; they do not share the same history or the same strengths. ### Comparison | | **[CycloneDX](/en/sbom/formats/cyclonedx/)** | **[SPDX](/en/sbom/formats/spdx/)** | | --- | --- | --- | | Origin | OWASP | Linux Foundation | | Standardisation | **[ECMA-424](https://ecma-international.org/publications-and-standards/standards/ecma-424/)** | **ISO/IEC 5962** (for SPDX 2.2.1) | | Original orientation | **Security** | **Licence compliance** | | Serialisations | JSON, XML, Protobuf | Tag-value, JSON, YAML, RDF/XML, spreadsheet | | Vulnerabilities in the document | **Native** (`vulnerabilities`) | Via the security profile (SPDX 3.x) | | **VEX** | **Native** | Through external mechanisms or a profile | | Licence depth | Good | **The reference of the field** (SPDX list and expressions) | | Extensions | SaaSBOM, HBOM, ML-BOM, CBOM, OBOM | SPDX 3 profiles: security, build, AI, dataset, licensing | | Adoption | Strong in security tooling and CI/CD | Strong in legal compliance and distributions | ### What they share Both formats express the same basic notions: components, versions, identifiers, hashes, licences, dependency relationships, creation metadata. Conversion tools exist both ways. ### What really separates them **[CycloneDX](https://cyclonedx.org/)** was designed by a security community, to feed automated processing chains. It natively carries vulnerabilities and exploitability assertions, which makes it the natural working format for a steering platform. **[SPDX](https://spdx.dev/)** was designed by a legal compliance community, around the question "which licences are in this software, and what do they require?". Its licence list and licence expressions are the global reference, reused by CycloneDX itself. ### Conversion and its losses Conversion is not neutral. Typical losses: - **format-specific extensions** have no equivalent in the other; - **relationships** are expressed differently and may flatten; - CycloneDX **VEX assertions** have no natural destination in SPDX 2.x; - **build metadata** may disappear. Every conversion must therefore be documented: tool used, version, known losses. ### The choice adopted **Pivot format: CycloneDX**, in a recent version, produced by the build chain and consumed by the steering platform. It is the format that natively carries [VEX](/en/sbom/vex/), and therefore the one that lets you document decisions not to fix. **SPDX export** on demand, for legal uses and for customers who require it contractually. That choice must be **frozen and documented**, with minimum accepted versions, and applied uniformly: two teams producing two different formats make the portfolio incomparable. ## CycloneDX URL: https://cra-reference.eu/en/sbom/formats/cyclonedx/ Description: The OWASP format standardised as ECMA-424: document structure, BOM extensions, native VEX support, and an annotated example. Audience: cyber Published 2026-08-19, updated 2026-08-19 ### Identity A format created within **OWASP** and standardised as **[ECMA-424](https://ecma-international.org/publications-and-standards/standards/ecma-424/)**. Serialisations: **JSON** (recommended), **XML** and **Protobuf**. Designed by a security community, to be produced and consumed by machines in automated chains. ### Document structure | Section | Content | | --- | --- | | `metadata` | Timestamp, tool that produced the document, author, component described (the product itself), supplier, product licences | | `components` | The component list: type, name, version, publisher, identifiers (`purl`, `cpe`), hashes, licences, description | | `dependencies` | The **graph**: which component depends on which. This is the section that separates direct from transitive | | `services` | External services called — useful for distributed architectures | | `compositions` | **Completeness** declaration: is this inventory complete, incomplete, or of unknown completeness | | `vulnerabilities` | Known vulnerabilities affecting the components, with source, score, state | | `annotations` | Signed assertions about all or part of the document | | `formulation` | How the artefact was produced: build chain, steps, environment | The `compositions` section is under-used and yet decisive for compliance: it lets you **explicitly declare** that an inventory covers only top-level dependencies, rather than implying a completeness that does not exist. ### The extensions CycloneDX is not limited to software: | Extension | Purpose | | --- | --- | | **SaaSBOM** | Services and interfaces of a distributed architecture | | **HBOM** | Hardware bill of materials | | **ML-BOM** | Machine learning models, datasets, model cards | | **CBOM** | Cryptographic inventory — algorithms, key sizes, protocols | | **OBOM** | Runtime configuration | | **VDR / VEX** | Vulnerability disclosure report and exploitability assertions | **CBOM** deserves particular attention: it is the natural tool for preparing post-quantum migration, a topic that will meet the CRA through the state-of-the-art expectation in Annex I. ### Annotated example ```json { "bomFormat": "CycloneDX", "specVersion": "1.6", "serialNumber": "urn:uuid:3e671687-395b-41f5-a30f-a58921a69b79", "version": 1, "metadata": { "timestamp": "2026-08-19T09:12:04Z", "tools": { "components": [ { "type": "application", "name": "syft", "version": "1.x" } ] }, "component": { "type": "application", "bom-ref": "pkg:generic/acme-gateway@4.2.1", "name": "acme-gateway", "version": "4.2.1", "licenses": [ { "license": { "id": "Apache-2.0" } } ] } }, "components": [ { "type": "library", "bom-ref": "pkg:maven/org.example/http-client@5.3.1", "name": "http-client", "group": "org.example", "version": "5.3.1", "purl": "pkg:maven/org.example/http-client@5.3.1", "licenses": [ { "license": { "id": "MIT" } } ], "hashes": [ { "alg": "SHA-256", "content": "9f2c…" } ] } ], "dependencies": [ { "ref": "pkg:generic/acme-gateway@4.2.1", "dependsOn": [ "pkg:maven/org.example/http-client@5.3.1" ] } ], "compositions": [ { "aggregate": "complete", "assemblies": [ "pkg:generic/acme-gateway@4.2.1" ] } ] } ``` Points to note in this example: - `bom-ref` is the internal key linking components and dependencies; it must be stable across builds for comparisons to be meaningful; - `purl` is the identifier that makes correlation reliable — see [Identifiers](/en/sbom/identifiers/); - `hashes` ties the inventory to the actual artefact: without a hash, nothing proves this SBOM describes the shipped binary; - `compositions.aggregate` declares completeness and commits the producer. ### Why it works as the pivot format Three reasons: **native** support for [VEX](/en/sbom/vex/), and therefore the ability to document decisions not to fix within the same ecosystem; the richness of build metadata, useful for the traceability Annex VII expects; and the breadth of available CI/CD tooling. ## SPDX URL: https://cra-reference.eu/en/sbom/formats/spdx/ Description: The Linux Foundation format standardised as ISO/IEC 5962: structure, SPDX 3 profiles, the authoritative licence list and expressions, and an annotated example. Audience: legal Published 2026-08-19, updated 2026-08-19 ### Identity Software Package Data Exchange, created within the **Linux Foundation** and standardised as **ISO/IEC 5962** for version 2.2.1. Serialisations: **tag-value**, **JSON**, **YAML**, **RDF/XML** and spreadsheet. Designed by a legal compliance community, around the licensing question. ### Document structure (SPDX 2.x) | Section | Content | | --- | --- | | *Document creation information* | SPDX version, document identifier, data licence, creator, timestamp | | *Packages* | Packages: name, version, supplier, hash, **declared** and **concluded** licence, copyright notice, provenance | | *Files* | File-by-file detail, with licence and copyright — a rare granularity, decisive in an audit | | *Snippets* | Fragments of code of distinct origin within a file | | *Relationships* | Relationships: contains, depends on, is generated by, is a source file of… | | *Annotations* | Timestamped, attributed comments | | *Other licensing information* | Licences not in the SPDX list | The distinction between the **declared licence** (`PackageLicenseDeclared`, what the project asserts) and the **concluded licence** (`PackageLicenseConcluded`, what analysis establishes) is specific to SPDX and has no direct equivalent elsewhere. It is valuable in litigation: it documents that you verified rather than took someone's word. ### SPDX 3 and profiles SPDX 3 reorganises the model around activatable **profiles**: *core*, *software*, *licensing*, *security*, *build*, *AI*, *dataset*, *extension*. That brings SPDX closer to CycloneDX's functional coverage while keeping its legal depth. ### The SPDX licence list This is the project's most universal contribution: a **standardised list of licence identifiers** — `MIT`, `Apache-2.0`, `GPL-3.0-or-later`, `LGPL-2.1-only`, `MPL-2.0`, `BSD-3-Clause`, `AGPL-3.0-only` — used across the whole ecosystem, including by CycloneDX. **Licence expressions** cover compound cases: | Expression | Meaning | | --- | --- | | `MIT` | A single licence | | `MIT OR Apache-2.0` | Dual licence, at the recipient's choice | | `GPL-2.0-only AND MIT` | Both apply cumulatively | | `GPL-2.0-only WITH Classpath-exception-2.0` | A licence with a standardised exception | | `NOASSERTION` | Licence undetermined — **treat as a blocking defect** | What each of these licences actually requires is set out in [The licence families](/en/licensing/families/). ### Annotated example (tag-value) ``` SPDXVersion: SPDX-2.3 DataLicense: CC0-1.0 SPDXID: SPDXRef-DOCUMENT DocumentName: acme-gateway-4.2.1 DocumentNamespace: https://acme.example.org/spdx/acme-gateway-4.2.1 Creator: Tool: syft-1.x Created: 2026-08-19T09:12:04Z PackageName: acme-gateway SPDXID: SPDXRef-Package-acme-gateway PackageVersion: 4.2.1 PackageDownloadLocation: NOASSERTION FilesAnalyzed: true PackageLicenseDeclared: Apache-2.0 PackageLicenseConcluded: Apache-2.0 PackageCopyrightText: NOASSERTION PackageName: http-client SPDXID: SPDXRef-Package-http-client PackageVersion: 5.3.1 PackageLicenseDeclared: MIT PackageLicenseConcluded: MIT ExternalRef: PACKAGE-MANAGER purl pkg:maven/org.example/http-client@5.3.1 Relationship: SPDXRef-Package-acme-gateway DEPENDS_ON SPDXRef-Package-http-client ``` Points to note: - `PackageLicenseConcluded: NOASSERTION` in bulk signals a tool that did not analyse the files; that is a quality defect, not a property of the component; - `ExternalRef … purl` carries the identifier that makes correlation reliable; - `DocumentNamespace` must be unique and stable: it is the document's identity. ### When you produce SPDX - When a **customer requires it contractually**. - For **legal deliverables**: attribution file, diligence responses, preparation of a licence audit. - When an **upstream ecosystem** already publishes in that format and you aggregate it. In every other case your pivot format remains [CycloneDX](/en/sbom/formats/cyclonedx/), with documented conversion. ## Component identifiers URL: https://cra-reference.eu/en/sbom/identifiers/ Description: PURL, CPE, SWID, hashes: why matching a component to a vulnerability is the number-one cause of false positives, and how to make it reliable. Audience: cyber Published 2026-08-19, updated 2026-08-19 The whole arrangement rests on an apparently trivial operation: **linking a component in your SBOM to a published vulnerability**. That is where the reliability of everything else is decided, and where most arrangements fail. ### The available identifiers #### PURL — package URL A canonical per-ecosystem identifier, of the form `pkg:type/namespace/name@version?qualifiers`. ``` pkg:maven/org.example/http-client@5.3.1 pkg:npm/%40scope/package@1.2.3 pkg:pypi/requests@2.32.3 pkg:golang/github.com/example/mod@v1.4.0 pkg:deb/debian/openssl@3.0.11-1~deb12u2?arch=amd64 ``` **Always prefer it.** A PURL is deterministic: it describes a package in a given ecosystem unambiguously, which makes correlation exact. #### CPE — common platform enumeration The NVD's historical identifier, of the form `cpe:2.3:a:vendor:product:version:...`. Necessary to query the NVD, but **structurally imprecise**: the vendor/product pair is entered by hand, with spelling variants, homonyms and missing entries. It is the **number-one cause of false positives and false negatives**. #### SWID Standardised software identification tags, little used outside certain enterprise environments. #### Cryptographic hashes SHA-256 or equivalent, computed over the artefact. They do not identify a component in a registry, but they **tie the inventory to the real object** — which is what makes an SBOM evidence rather than a statement. #### OmniBOR / GitOID Content-derived identifiers allowing fine traceability down to the file. Emerging; worth watching where file-level granularity is needed. ### The matching problem Three typical failures: | Failure | Example | Consequence | | --- | --- | --- | | **False positive by homonymy** | Two products from different vendors sharing a name | An alert about a component you do not have | | **False negative by missing CPE** | A vulnerability published with no CPE, or a wrong one | A real vulnerability goes undetected | | **False positive by version** | A distribution backports a fix without changing the upstream version number | An alert about a version that is in fact fixed | The third case is particularly painful: Linux distributions backport heavily while keeping the upstream version number. A scanner unaware of the distribution reports hundreds of already fixed vulnerabilities. ### How to make it reliable 1. **Require a valid `purl`** on every component, and fail the build below a coverage threshold. 2. **Query per-ecosystem databases** — OSV first — rather than correlating everything by CPE. 3. **Populate distribution metadata** where the component comes from a system package, so the tool applies the right fix database. 4. **Keep hashes**, so it is possible to verify later that an SBOM really describes the shipped artefact. 5. **Document matching exceptions** in a [VEX](/en/sbom/vex/) rather than suppressing the alert: a suppressed alert disappears, a documented one remains traceable. ### The link to false positives The quality of identifiers directly determines the volume of noise teams will face. It is an infrastructure investment, not a tool setting: see [Managing false positives](/en/cyber/false-positives/). ## SBOM life cycle URL: https://cra-reference.eu/en/sbom/lifecycle/ Description: One SBOM per build, immutable and versioned; retention aligned with the technical documentation; archiving, indexing, retrieval and version-to-version comparison. Audience: cyber Legal basis: Art. 31 — retention of technical documentation Published 2026-08-19, updated 2026-08-19 ### The ground rule **One SBOM per build.** Immutable once produced, versioned, tied to the artefact by its cryptographic hash. Corollaries: - an issued SBOM is **never modified**; a new one is issued instead; - an SBOM "of the product", with no build or version reference, has no value; - two builds of the same code at two different dates may produce different SBOMs, if dependencies resolved differently — which is itself useful information. ### The stages | Stage | Where | What is produced | | --- | --- | --- | | Generation | Build pipeline | Build SBOM | | Validation | Pipeline | Quality score, failure below threshold | | Signing | Pipeline | Signed SBOM, provenance attestation | | Publication | Steering platform | Ingestion, initial correlation | | Attachment | Artefact registry | SBOM indexed by hash, alongside the image | | Monitoring | Platform | Daily re-evaluation against sources | | Enrichment | PSIRT | [VEX](/en/sbom/vex/) statements added as analysis proceeds | | Archiving | Evidence vault | Long-term, immutable retention | | Retrieval | On request | Extraction of a historical version | | Deletion | End of retention period | Logged purge | ### Retention period Aligned with the [technical documentation](/en/cra/technical-documentation/): **at least ten years after the product is placed on the market, or for the support period if longer**. That means an SBOM produced today for a product still sold in five years must be retrievable in fifteen. The practical consequences are underestimated: - the **format** must stay readable — hence standardised rather than proprietary formats; - the **public keys** for verifying signatures must be retained; - the **storage medium** will need migrating at least once; - the **index** must survive a change of platform. ### Indexing An SBOM that cannot be found is an SBOM that does not exist. The minimum index: | Key | Why | | --- | --- | | Product and commercial version | Entry point for an authority or customer request | | Build reference | Link back to the CI chain | | Artefact hash | Proof of correspondence | | Build date and date placed on the market | Start of the ten years | | Format and format version | Choice of reader | | Signature and key | Verification | | Associated VEX statements | Context of the handling decision | ### Version-to-version comparison An **SBOM diff** between two versions answers recurring questions: - which components were **added**, and through which dependency path? - which components were **updated**, and does that fix known vulnerabilities? - which **licences** appeared? - is the surface growing version after version? That comparison is a useful input to change review, and it catches unintended introductions — a strong candidate for the engineering dashboard. ### The test that counts Once a year, a retrieval exercise: pick at random a version shipped more than two years ago, and **produce within one working day** its signed SBOM, its verified signature, its VEX statements and its technical documentation. Until that exercise has been passed, the archiving arrangement is a hypothesis. ## Quality, completeness and depth URL: https://cra-reference.eu/en/sbom/quality/ Description: Quality criteria for an SBOM, automated scoring, blocking thresholds in CI, transitive dependency depth, and the seven traps that produce false inventories. Audience: cyber Published 2026-08-19, updated 2026-08-19 An incomplete SBOM is worse than no SBOM: it gives false assurance. This page defines what a usable SBOM is and how to verify it automatically. ### Quality criteria | Criterion | Question | Verifiable | | --- | --- | --- | | **Completeness** | Are all components present? | By gap with the [analysed SBOM](/en/sbom/types/) | | **Accuracy** | Do the versions match the actual artefact? | By hash | | **Freshness** | Does the SBOM correspond to the latest build? | By timestamp and build reference | | **Resolvable identifiers** | Does every component carry a valid `purl` or `cpe`? | Automatic | | **Licences populated** | What proportion of `NOASSERTION`? | Automatic | | **Relationships expressed** | Is the dependency graph present? | Automatic | | **No unknowns** | How many components have no name, no version, or are unidentified? | Automatic | | **Declared completeness** | Does the composition section honestly state coverage? | Automatic | ### Automated scoring Every SBOM produced receives a **score** against these criteria, and the threshold is **blocking** in CI. The policy must state explicitly: - the minimum score for a build to be **promotable** to production; - the maximum tolerated proportion of components without a resolvable identifier; - the maximum proportion of `NOASSERTION` licences; - the maximum tolerated gap between build SBOM and analysed SBOM. Without a numeric threshold, "SBOM quality" remains an intention. With a blocking threshold it becomes a property of the pipeline. ### Depth: direct and transitive The Regulation requires **at the very least top-level dependencies**. That floor is insufficient in practice. | | Direct dependencies | Transitive dependencies | | --- | --- | --- | | Definition | Explicitly declared by you | Dragged in by your dependencies | | Typical volume | Dozens | **Hundreds to thousands** | | Control | You choose them | You inherit them | | Share of supply chain incidents | Minority | **Majority** | The doctrine adopted: **full depth**, with an explicit direct / transitive distinction in the graph, to support prioritisation and to identify how a problematic component got in. #### Which dependencies to include | Category | In the shipped product's SBOM? | | --- | --- | | **Runtime** dependencies | **Yes**, no discussion | | **Build** dependencies whose output is embedded | **Yes** | | **Build** dependencies not embedded | In a separate build-chain SBOM | | **Test** dependencies | **No** in the product SBOM — their presence is a major cause of false positives | | Container **base image** packages | **Yes** if shipped with the product | ### The seven traps **1. Statically linked binaries.** A C or Rust library compiled into the executable appears in no manifest. Remedy: binary analysis, and language-specific tools. **2. Vendored code.** Third-party sources copied into your repository, often modified. Remedy: file-hash detection, of the kind licence-oriented composition analysis tools perform. **3. Container system dependencies.** The base image brings in dozens of packages. Remedy: generate the SBOM on the **image**, not only on the application; shrink the surface with minimal images. **4. Multi-language artefacts.** A Python package embedding a compiled native library, a Node module with a binary. Remedy: combine several generators. **5. Code generated at build time.** The generator itself has dependencies, and the code it produces may embed some. Remedy: document the generation chain in the SBOM. **6. Firmware.** Embedded file systems, partitions, binary blobs. Remedy: firmware analysis tooling, and a contractual SBOM requirement on the platform supplier. **7. Renamed or repackaged components.** The same component under two names in two ecosystems. Remedy: normalisation by `purl` — see [Identifiers](/en/sbom/identifiers/). ### What to write down A one-page **SBOM quality policy** setting: format and version, required depth, dependency categories included, minimum score, blocking thresholds, the temporary waiver procedure and its automatic expiry. ## Signing and integrity URL: https://cra-reference.eu/en/sbom/signing/ Description: Why an unsigned SBOM is not evidence: signing, provenance attestations, SLSA levels, reproducible builds and the transparency log. Audience: cyber Legal basis: Annex I, Part I — integrity · Annex I, Part II, point 7 — secure distribution Published 2026-08-19, updated 2026-08-19 ### The problem A JSON file sitting next to an artefact commits nobody. Nothing in it proves: - **who** produced it; - **when** it was produced; - **which artefact exactly** it corresponds to; - that it **has not been modified** since. An unsigned SBOM is a statement, not evidence. For technical documentation meant to be put to an authority ten years later, the difference is decisive. ### The mechanisms #### Signing the document Sign the SBOM itself and attach the signature to the artefact in the registry. Two common approaches: a classic detached signature with an organisational key, or signing through a supply chain signing infrastructure such as **Sigstore / cosign**, with an ephemeral identity and a **transparency log**. The transparency log adds something specific: it makes the signature **publicly verifiable and timestamped**, which directly answers "did this SBOM exist on that date?". #### Artefact hash The SBOM must contain the **cryptographic hash of the artefact it describes**, and the artefact must be retrievable by that hash. It is this link that lets you show, years later, that this SBOM describes that binary. #### Provenance attestations An **attestation** is a signed statement about how the artefact was produced: source repository, revision, build chain, parameters, dependencies. The **[in-toto](https://in-toto.io/)** model provides the structure; the **[SLSA](https://slsa.dev/)** framework defines progressive levels. The [SLSA](https://slsa.dev/spec/v1.0/levels) framework defines four named levels for its build track: | Level | What is required | | --- | --- | | **Build L0** | No requirements — the absence of SLSA | | **Build L1** | The build process is **consistent** and **provenance exists**, describing the platform, the process and the top-level inputs. It is distributed to consumers | | **Build L2** | The build runs on **dedicated infrastructure**, not an individual's workstation, and provenance is tied to it by a **signature** whose authenticity is verified downstream | | **Build L3** | The platform prevents runs from influencing one another, and makes the **signing material inaccessible** to user-defined build steps | Reproducible builds are not a level of that track: they are a distinct property, described below, that strengthens third-party verifiability. #### Reproducible builds Two builds of the same code produce **bit-for-bit identical** artefacts. This is the most demanding objective and the most probative: it lets a third party verify that the shipped binary matches the published source. For a product under a ten-year support period, reproducibility has a second, often decisive benefit: it forces the build environment to be pinned and documented, and therefore makes it possible to **rebuild** eight years from now. ### The link to the Regulation's requirements | Requirement | What signing contributes | | --- | --- | | Annex I, Part I — integrity protection | Verification at install and at update | | Annex I, Part II, point 7 — secure distribution of updates | Authenticated channel, signed fixes, rollback protection | | Annex VII — technical documentation | Dated, tamper-evident proof of what was shipped | ### What to put in place 1. **Sign every SBOM** at build time, in the pipeline, with no human step. 2. **Generate a provenance attestation** for every artefact. 3. **Store signatures and attestations** with the artefact, indexed by hash. 4. **Verify the signature** before any deployment and before any publication. 5. **Manage keys**: rotation, revocation, retention of historical public keys — without the 2027 public key, a 2027 signature cannot be verified in 2035. 6. **Test retrieval**: an annual exercise consisting of finding, verifying and presenting the signed SBOM of an old version. That last point is the only one that proves the arrangement works. See [Evidence retention](/en/legal/evidence-retention/). ## Licensing as SBOM data URL: https://cra-reference.eu/en/sbom/spdx-licences/ Description: SPDX identifiers and expressions, what an SBOM lets you compute about legal compliance, and the data quality without which none of it works. Audience: legal Published 2026-08-19, updated 2026-08-20 The CRA does not require licence compliance. But **the SBOM it does require is precisely the tool that makes compliance demonstrable** — the strongest funding argument on the Legal side, and its most immediate benefit. This page covers licensing **as data**: how it is expressed in an SBOM and what can be computed from it. The substance of the law is elsewhere: - **what each family requires** → [The licence families](/en/licensing/families/); - **when an obligation triggers** → [What triggers an obligation](/en/licensing/triggers/); - **the verdict by product type** → [Nine scenarios](/en/licensing/scenarios/); - **your policy and process** → [Intellectual property](/en/legal/intellectual-property/). ### SPDX identifiers The **[SPDX licence list](https://spdx.org/licenses/)** is the global reference for licence identifiers: `MIT`, `Apache-2.0`, `BSD-3-Clause`, `MPL-2.0`, `LGPL-2.1-only`, `GPL-3.0-or-later`, `AGPL-3.0-only`, and several hundred more. Both CycloneDX and SPDX use it. A standardised identifier is what makes a licence **computable**: without one, "GPL v3 or later", "GPLv3+" and "GNU General Public License version 3" are three distinct strings that no automated policy can match against a list. ### Licence expressions They cover compound cases, and each carries a different legal consequence: | Expression | Meaning | | --- | --- | | `MIT` | A single licence | | `MIT OR Apache-2.0` | **At the recipient's choice**: you pick the one that suits and document it | | `GPL-2.0-only AND MIT` | **Cumulative**: both sets of obligations apply | | `GPL-2.0-only WITH Classpath-exception-2.0` | A licence with a standardised **exception** narrowing its reach — never ignore it, it changes the verdict | | `LicenseRef-…` | A licence outside the SPDX list, whose text must accompany the document | | `NOASSERTION` | **Undetermined** — a blocking defect, not a licence | The `-only` and `-or-later` suffixes are not cosmetic: they determine whether you may apply a later version of the licence, and therefore compatibility with the rest of the tree. `GPL-2.0-only` and `GPL-2.0-or-later` do not carry the same consequences. ### Declared versus concluded The SPDX format distinguishes two fields that CycloneDX does not separate as cleanly: | Field | Meaning | | --- | --- | | `PackageLicenseDeclared` | What the project **asserts** — the manifest field, the `LICENSE` file | | `PackageLicenseConcluded` | What **analysis establishes**, after examining the file contents | The gap between them is the interesting datum. A repository declared `MIT` whose analysis concludes `MIT AND GPL-2.0-only` has a subdirectory nobody looked at — exactly the [multiple licences in one repository](/en/licensing/pitfalls/) pitfall. Documenting the concluded licence is not fussiness: it is what shows, in a dispute, that you **verified** rather than took someone's word. ### What an SBOM lets you compute Once licences are properly populated, four operations become automatic: | Operation | Output | | --- | --- | | Matching against the **policy** by context of use | Block or warn in CI | | Generating the **attribution file** | `NOTICE` shipped with the product | | **Inventory by licence** across the portfolio | A report for an audit or diligence | | **Diff** between two versions | Detection of an upstream licence change | The last point is underrated: comparing the licence field from one version to the next is the only way to catch, in time, that an infrastructure component has changed licence — see [Pitfalls](/en/licensing/pitfalls/). ### Data quality, the precondition for everything else An SBOM where a significant share of components carries `NOASSERTION` supports no analysis. The usual causes: | Cause | Remedy | | --- | --- | | The generator only reads manifests | Add a **content analysis** tool, at reduced cadence | | The manifest declares no licence | Go back to the source, and treat absence as blocking | | Licence expressed as unnormalised free text | Normalise to an SPDX identifier | | Vendored component, absent from the manifest | File-hash analysis | The tolerated `NOASSERTION` threshold belongs in the [SBOM quality policy](/en/sbom/quality/), alongside identifier coverage — and it must be **blocking** at build time. ### Useful frameworks **ISO/IEC 5230** (OpenChain, licence compliance) and **ISO/IEC 18974** (OpenChain, open source security assurance) describe recognised management systems, useful for structuring the arrangement and for answering large-account customer requirements. ## The six types of SBOM URL: https://cra-reference.eu/en/sbom/types/ Description: Design, source, build, analysed, deployed, runtime: they do not describe the same thing and are not equivalent. Which one belongs in the technical documentation. Audience: cyber Published 2026-08-19, updated 2026-08-19 There is no such thing as "the" SBOM. There are several, produced at different points in the life cycle, and **they do not say the same thing**. Confusing two types is a recurring source of unexplained discrepancies between teams. | Type | Produced when | Answers | Reliability | | --- | --- | --- | --- | | **Design** | Before development | What you **plan** to use | Intent | | **Source** | From code and manifests | What is **declared** | Misses the undeclared | | **Build** | During the build | What is **actually assembled** | **The most faithful for the CRA** | | **Analysed** | After the fact, on the artefact | What you **find** in the binary or image | Depends on the quality of the analysis | | **Deployed** | On the target environment | What is **installed**, configuration included | Includes the environment | | **Runtime** | During execution | What is **actually loaded** | Cuts noise, misses unexercised paths | ### What each one brings **Design.** Useful upstream to run diligence before adopting a component, and to catch a prohibited licence early. No evidential value. **Source.** Fast, produced from dependency manifests. Its blind spot is structural: it does not see what is not declared — vendored code, copied libraries, system dependencies. **Build.** Produced by the build chain, it sees the real resolution graph, with the versions actually selected after constraint arbitration. This is the one that must be **filed with the technical documentation**. **Analysed.** Obtained by analysing the finished artefact — binary, container image, firmware image. It catches what the build missed: statically linked libraries, base image packages, copied files. Serves as a **cross-check** on the build. **Deployed.** Adds the runtime environment: host system, configuration, variables. Useful for operational security, less so for product compliance. **Runtime.** What is actually loaded. Allows **noise reduction**: a component present but never loaded does not carry the same criticality as one on the execution path. Handle with care: a path not exercised during observation is still a reachable path. ### The doctrine adopted 1. The **build SBOM** is the reference SBOM: signed, archived and filed with the technical documentation. 2. The **analysed SBOM** is produced systematically as a cross-check. **Any significant gap between the two is a defect to investigate**, not a curiosity: it usually reveals vendored code or an undeclared dependency. 3. The **runtime SBOM** serves prioritisation, never compliance. 4. **Design** and **deployed** types are produced case by case, as needed. ### The build / analysed gap This is the most revealing quality indicator in the whole arrangement. Typical causes: - **static linking**: a C library compiled into the binary does not appear in the manifest; - **vendored code**: third-party sources copied into your repository; - **base image**: the container's system packages, absent from application manifests; - **multi-language artefacts**: a Python component calling a native library; - **code generation**: code produced at build time, carrying dependencies. Each of these causes is addressed in [Quality and completeness](/en/sbom/quality/). ## VEX: exploitability URL: https://cra-reference.eu/en/sbom/vex/ Description: The mechanism that separates 'handled' from 'ignored': statuses, standardised justifications, CycloneDX, OpenVEX and CSAF implementations, and the legal value of a decision not to fix. Audience: transverse Legal basis: Annex I, Part II, point 2 — address vulnerabilities · Annex I, Part II, point 4 — publish information Published 2026-08-19, updated 2026-08-19 ### The problem VEX solves An SBOM matched against vulnerability databases produces hundreds of alerts per product. A large majority are **not exploitable in your context**: the vulnerable code is not called, the function is not compiled in, a mitigation is in place. With no mechanism to express that, there are two outcomes, both bad: either the team handles everything and burns out, or it suppresses the alerts and loses the record of its decisions. The second is exactly what an authority will look for. ### The definition **VEX** — vulnerability exploitability exchange — is a **structured assertion by the supplier about the exploitability status** of a given vulnerability in a given product. It is not a competitor to the SBOM: it is a **complement**. The SBOM says what is inside; the VEX says what that implies. ### The four statuses | Status | Meaning | What else is expected | | --- | --- | --- | | `not_affected` | The product is not affected | A standardised **justification**, mandatory | | `affected` | The product is affected | A recommended action for the user | | `fixed` | The vulnerability is fixed in this version | The fixed version | | `under_investigation` | Analysis is in progress | A deadline, and an actual follow-up | `under_investigation` is a **temporary** status. A VEX left under investigation for six months is a process defect, not a position. ### `not_affected` justifications They are standardised, and that is what gives the mechanism its value: | Justification | Meaning | | --- | --- | | *component_not_present* | The allegedly vulnerable component is not in the product | | *vulnerable_code_not_present* | The component is present, but not the vulnerable portion of code | | *vulnerable_code_not_in_execute_path* | The vulnerable code exists but is never executed | | *vulnerable_code_cannot_be_controlled_by_adversary* | The code executes but an attacker cannot control its input | | *inline_mitigations_already_exist* | An internal countermeasure neutralises exploitation | A justification outside that list, or an empty one, is not acceptable. ### The implementations | Implementation | Steward | Typical use | | --- | --- | --- | | **CycloneDX VEX** | OWASP | Same ecosystem as your pivot SBOM | | **[OpenVEX](https://github.com/openvex)** | Community | Minimal, standalone, easy to generate and sign | | **CSAF 2.0, VEX profile** | OASIS | Publishing machine-readable advisories to customers | These implementations express the same notions. The choice follows the use: internal and tooled for CycloneDX or OpenVEX, external and standardised for CSAF. ### The legal value This is the point to land with Legal and Cyber at the same time. > Annex I, Part II, point 2 requires **addressing and remediating vulnerabilities without > delay**. It does not require fixing every identifier a scanner reports. A vulnerability that > has been analysed and declared non-exploitable, with a standardised justification, **has been > addressed**. A VEX is therefore the **documentary form of a reasoned decision not to fix**. It turns an engineering choice into a defensible record. Without it, the same decision is indistinguishable from negligence. ### The internal process | Step | Who | Output | | --- | --- | --- | | Detection | Steering platform | Alert on a product / vulnerability pair | | Exploitability analysis | Product engineering | Proposed status + justification | | Review | PSIRT | Status approved or returned | | Arbitration on disagreement | Committee, per the [RACI matrix](/en/organisation/raci/) | Traced decision | | Issuance | Automated chain | Signed, timestamped VEX document | | Publication where relevant | PSIRT + Legal | Customer advisory, CSAF format | | Re-examination | PSIRT | At every new product version | A VEX belongs to a **product and a version**. It does not carry over automatically to the next version: re-examination is part of the process. ### The link to security advisories Annex I, Part II, point 4 requires publishing information about **fixed** vulnerabilities. The **[CSAF 2.0](https://www.csaf.io/)** format allows publishing both fix advisories and VEX assertions in a form your customers can process automatically — reducing their workload and yours. ## Worked scenarios URL: https://cra-reference.eu/en/scenarios/ Description: Ten end-to-end scenarios: the Legal question, the Cyber question, the decision, the evidence produced and the lesson. Audience: transverse Published 2026-08-19, updated 2026-08-19 Each scenario follows the same pattern: the situation, each team's question, the decision, the evidence produced, the lesson. ### 1 — A critical vulnerability hits twelve of your products **Situation.** A vulnerability is published in a widely used library. Your platform identifies twelve affected products within ten minutes, four of them in versions still supported at customers. **Legal:** is there active exploitation? If so, the 24-hour clock is running. **Cyber:** exactly which versions, which customers, is the vulnerable code reachable? **Decision.** No evidence of active exploitation at this stage → **no reporting obligation**, but urgent handling within the SLAs, VEX statements for products where the code is unreachable, and heightened watch for signs of exploitation. **Evidence.** Register entry justifying the absence of a report, handling log, VEX statements, security advisory once the fix is published. **Lesson.** Without a centralised SBOM, the "which products are affected" step would have taken weeks — and the 24-hour deadline would have been missed had exploitation been observed meanwhile. --- ### 2 — A researcher reports a flaw on a Friday evening **Situation.** An email arrives at the PSIRT address at 7 p.m. on a Friday, describing a remotely exploitable vulnerability with a proof of concept. **Legal:** is this active exploitation? A proof of concept supplied by a researcher **is not** exploitation in the wild. **Cyber:** is the flaw real, which versions, what immediate workaround? **Decision.** Acknowledgement within the CVD policy's interval, qualification within seven days, **no CRA report** absent active exploitation, coordination of the publication date with the researcher. **Evidence.** CVD register, acknowledgement, correspondence with the researcher, published advisory, credit. **Lesson.** The CVD policy absorbs this case without mobilising the on-call rota. Without it the email would have gone unanswered until Monday, and the researcher might have published. --- ### 3 — A customer requires your SBOM in a tender **Situation.** A large account requires, as a mandatory item, an SBOM in SPDX format for the version to be delivered. **Legal:** what does the document reveal, and under what conditions may it be shared? **Cyber:** your pivot format is CycloneDX; does conversion lose information? **Decision.** Supplied under NDA, through the authenticated portal, accompanied by the VEX statements. Documented conversion, with known losses stated. **Evidence.** Disclosure decision, contract clause, record of delivery. **Lesson.** The disclosure question must be settled **before** the tender — see [Distribution and confidentiality](/en/sbom/distribution/). Handling it under pressure leads to over-promising. --- ### 4 — A critical open source component is abandoned **Situation.** The sole maintainer of a library present in three of your products announces they are stopping. **Legal:** your support periods on those products still run for three years. **Cyber:** replace, fork, or bring in-house? **Decision.** Fork and maintain internally for the remaining support period, with a budget provision; replacement planned for the next major version. **Evidence.** Documented decision in the risk register, updated support period register, replacement plan. **Lesson.** The "upstream support duration" criterion must be in the diligence grid **at integration**, not discovered three years later. --- ### 5 — You want to embed an AGPL library in an online offering **Situation.** A team proposes an AGPL library to speed up development. **Legal:** making it available over a network triggers the obligation to provide the derivative work's source to users of the service. **Cyber:** does a permissively licensed alternative exist? **Decision.** Refused, with an alternative proposed. If none exists: strict isolation in a separate service, or negotiation of a commercial licence with the author. **Evidence.** CI block, ticket, decision in the exception register. **Lesson.** The licence policy must be **enforced by the build chain**, not merely published. An automatic block avoids a debate three months later, once the code is written. --- ### 6 — You launch a new product: which class? **Situation.** A new product includes an access management function and an embedded web rendering engine. **Legal:** two Annex III, Part I categories are in play. **Cyber:** is the rendering engine exposed to untrusted remote content? **Decision.** **Class I.** Two assessment scenarios worked in parallel: self-assessment if harmonised standards are published and cited in time, notified body otherwise — the latter kept as the base case. **Evidence.** Co-signed classification sheet, filed with the documentation. **Lesson.** Classification happens **when development starts**, not before market entry: it determines budget and schedule. --- ### 7 — An authority asks for the file on a product sold four years ago **Situation.** A market surveillance authority in another Member State requests the technical documentation for version 3.1.4, placed on the market four years earlier. **Legal:** deadline, single point of contact, evidence freeze. **Cyber:** find the signed SBOM, verify its signature, produce the VEX statements and the logs of the time. **Decision.** Apply the [response card](/en/cra/market-surveillance/), answer within the deadline, with no reconstruction of documents. **Evidence.** The file as it stood, plus the register of exchanges. **Lesson.** This case is not prepared when it happens. It is prepared through the **annual retrieval exercise** — see [Evidence retention](/en/legal/evidence-retention/). --- ### 8 — A supplier refuses to provide an SBOM **Situation.** A commercial component supplier refuses, citing trade secrets. **Legal:** your inventory obligation does not disappear; the contract must be renegotiated. **Cyber:** can you produce the inventory by analysing the delivered artefact? **Decision.** Three options, in order: negotiate supply under NDA; failing that, produce an **analysed SBOM** yourselves and document the limitation; failing that, plan the component's replacement. **Evidence.** Record of the request and refusal, SBOM produced by analysis with a partial completeness declaration, decision in the risk register. **Lesson.** The SBOM completeness declaration exists precisely for this: to state honestly what the inventory covers. A partial inventory declared as such beats a partial inventory presented as complete. --- ### 9 — What support period for a long-lived embedded product? **Situation.** Industrial equipment with an expected physical lifetime of fifteen years. **Legal:** the support period must reflect the length of time the product is expected to be in use — potentially fifteen years. **Cyber:** can you guarantee fixes for fifteen years, on a hardware platform whose chip supplier will stop support before then? **Decision.** Analyse the limiting components, negotiate extended support with the platform supplier, and set a **justified and documented** support period — shorter than the physical lifetime if the components cannot follow, with explicit information to the buyer. **Evidence.** Justification in the technical documentation, statement to the buyer, register entry. **Lesson.** The support period is not a free commercial decision: it must be **justified**. And justifying it often reveals that your suppliers cannot keep up. --- ### 10 — Exploitation observed at a single customer **Situation.** A customer reports consistent indicators of compromise exploiting a vulnerability in your product. No other customer is affected as far as you know. **Legal:** exploitation observed at **one** customer is enough to establish active exploitation. **Cyber:** verify the indicators, establish the scope, prepare a workaround. **Decision.** **Report.** Early warning within 24 hours, notification of every user of the affected version, workaround published, fix under the emergency SLA. **Evidence.** Register, platform acknowledgements, user communication, published advisory. **Lesson.** There is no victim-count threshold. One customer is enough. This is the case the on-call team must have in mind, because instinct pushes towards waiting "until you know more". ## Vulnerability disclosure URL: https://cra-reference.eu/en/security/ Description: This site's coordinated disclosure policy: scope, reporting channel, response commitments, safe harbour and recognition of researchers. Audience: transverse Published 2026-08-19, updated 2026-08-20 > **What this page covers.** This is the disclosure policy **for this site**. The **model** > for a manufacturer — full structure, safe harbour clause, and how it maps to the standards > and to Annex I of the Regulation — is in > [Coordinated disclosure policy](/en/cyber/disclosure-policy/). We welcome reports of vulnerabilities affecting this site. This page sets out how to reach us, what we commit to, and what we ask in return. ### How to report a vulnerability **Address:** `contact@cra-reference.eu` **Standardised file:** [`/.well-known/security.txt`](/.well-known/security.txt) **Languages accepted:** English, French Please include, where you can: the page or component concerned, a description of the vulnerability, reproduction steps, the estimated impact, and your contact details. ### Scope **Covered:** the site `cra-reference.eu`, any subdomains, and the files it publishes — including [`/.well-known/security.txt`](/.well-known/security.txt), [`/llms.txt`](/llms.txt) and the sitemap. This site is **entirely static**: no application server, no database, no user accounts, no cookies set. The only resource loaded from a third-party domain is the host's audience measurement script, described in the [legal notices](/en/about/). The attack surface is therefore small, but it is not nil — header configuration, integrity of the resources served, the publication chain. **Out of scope:** the hosting provider's infrastructure, third-party services we do not control, automated reports with no demonstrated impact, and observations concerning best practice alone with no established security consequence. ### Our commitments | Step | Interval | | --- | --- | | **Acknowledgement** | 3 working days | | **First qualified assessment**, sent to the reporter | 10 working days | | **Progress updates** | Every 15 days while the matter is open | | **Fix or reasoned position** | By severity, within the interval stated at assessment | | **Coordinated publication** | By default 90 days after the report, adjustable by agreement | If we cannot fix within the agreed interval, we will tell you, explain why, and propose a new date. ### Safe harbour We will bring no civil action and file no criminal complaint against a person who, acting in good faith: - stays within the **scope** described above; - **does not degrade** the availability of the site; - **does not disclose** the vulnerability before the agreed date; - **reports** through the channel stated on this page. This commitment does not cover actions taken for malicious purposes, nor actions that would infringe the rights of third parties. ### What we ask - A **reasonable interval** to fix before any publication. - **Coordination** of the publication date with us. - **No demand for payment** as a condition of disclosing the details. ### Recognition Unless you ask otherwise, we **credit** the people who report a vulnerability in the site's revision log and on this page. We do not operate a financial reward programme. ### Alternative route In France, **Article L. 2321-4 of the defence code** allows any person acting in good faith to pass information about a vulnerability to ANSSI, which preserves the confidentiality of their identity. That route remains open to you at any time, independently of this policy. ### Reference framework This policy follows the structure described in [Coordinated disclosure policy](/en/cyber/disclosure-policy/), which draws on **ISO/IEC 29147** (vulnerability disclosure) and **ISO/IEC 30111** (vulnerability handling). It does not fall under Regulation (EU) 2024/2847: this site is a documentation resource, not a product with digital elements placed on the market. It nonetheless applies the same logic, because a site that documents the coordinated disclosure obligation would be poorly placed not to honour it. ## Self-assessment URL: https://cra-reference.eu/en/self-assessment/ Description: A five-module grid to locate your maturity, identify priority gaps and measure progress from one quarter to the next. Audience: transverse Published 2026-08-19, updated 2026-08-19 To be completed quarterly, by the committee, on the basis of verifiable facts — not impressions. Each answer is **yes** only if evidence can be produced within the hour. **Assessment date:** ____________ **Participants:** ______________________ ### Module 1 — Scope and classification - [ ] The portfolio is **fully qualified**: every product has a signed PDE sheet - [ ] **Exclusions** relied on are documented by a reasoned sheet - [ ] Every in-scope product has a co-signed **classification sheet** - [ ] The consolidated **classification register** exists and was reviewed less than a year ago - [ ] **Class II and Critical** products are identified, and a notified body is **contractually engaged** for each - [ ] The **assessment route** for each product is decided and documented **Score: ___ / 6** ### Module 2 — SBOM and tooling - [ ] A **pivot format** is decided and applied uniformly - [ ] The SBOM is generated **automatically** by the build chain across all active products - [ ] A **quality score** is computed and a threshold is **blocking** in CI - [ ] SBOMs are **signed** and accompanied by a provenance attestation - [ ] A **steering platform** ingests every SBOM produced - [ ] **Continuous monitoring** covers all **shipped** versions, not just the latest - [ ] **Tooling is pinned and documented** per product family **Score: ___ / 7** ### Module 3 — Vulnerabilities and disclosure - [ ] **Remediation SLAs** are written, published internally and **measured** - [ ] Uncorrected vulnerabilities carry a **VEX** with a standardised justification - [ ] **Security advisories** are published for fixed vulnerabilities - [ ] A **CVD policy** is published and the contact point is live - [ ] The **`security.txt`** file is online and its `Expires` field is in the future - [ ] A **register of reports received** exists and is kept - [ ] The **ratio of actionable alerts** is measured and tracked over time **Score: ___ / 7** ### Module 4 — Reporting capability - [ ] A technical **and** legal **on-call rota** exists, with named deputies - [ ] A **written delegation** of the decision to report is in force - [ ] **Live accounts** on the reporting platform exist and were tested less than six months ago - [ ] **Templates** for early warning, notification and final report are ready - [ ] The **list of Member States** where each product is made available is maintained - [ ] A **register of decisions** to report or not is kept, with the reasoning - [ ] A **timed exercise** took place in the last six months, and the interval achieved is under 24 hours **Score: ___ / 7** ### Module 5 — Documentation and evidence - [ ] A **technical documentation template** exists and is used - [ ] Every product placed on the market has **complete, frozen technical documentation** - [ ] **EU declarations of conformity** are signed by an authorised person - [ ] **Annex II user notices** are shipped, with the end-of-support date - [ ] Each product's **support period** is determined, justified and communicated - [ ] An **evidence vault** with ten-year archiving is in place - [ ] A **retrieval exercise** took place within the year, and it **succeeded** **Score: ___ / 7** --- ### Results | Module | Score | Out of | Level | | --- | --- | --- | --- | | 1. Scope and classification | | 6 | | | 2. SBOM and tooling | | 7 | | | 3. Vulnerabilities and disclosure | | 7 | | | 4. Reporting capability | | 7 | | | 5. Documentation and evidence | | 7 | | | **Total** | | **34** | | **Reading the levels, per module:** | Share of "yes" | Level | Interpretation | | --- | --- | --- | | Under 30 % | **Initial** | The topic is identified, nothing is tooled | | 30 to 60 % | **Building** | Blocks exist, without continuity | | 60 to 85 % | **Operational** | The arrangement works, blind spots remain | | Over 85 % | **Managed** | The arrangement is under control; the issue is sustaining it | ### The three questions that outrank the score Whatever the total, three negative answers justify immediate action: 1. **Is module 4 complete?** The reporting deadline has passed and applies to the legacy portfolio. 2. **Are notified bodies engaged** for class II and Critical products? It is the only lead time you do not control. 3. **Did the retrieval exercise succeed?** It is the only control that proves archiving works. ### Use Archive each dated assessment. **Progress** between two assessments is more informative than the absolute score, and it is progress that goes to the executive committee. ## Start here URL: https://cra-reference.eu/en/start/ Description: How this site is organised, which reading path suits your team, and the fifteen terms to know before opening the Regulation. Audience: transverse Published 2026-08-19, updated 2026-08-19 This site is a public reference on software bills of materials (SBOM) and Regulation (EU) 2024/2847, the **Cyber Resilience Act**. It addresses two teams whose obligations are distinct but inseparable: **Legal / Compliance** and **Cybersecurity / DevSecOps**. ### The organising principle Three failure modes threaten this kind of reference: duplicating the regulatory content across a Legal section and a Cyber section — they diverge within six months; following the order of the Regulation's articles, which nobody reads; and mixing doctrine (what the law says) with internal practice (what you do). The site therefore separates four layers: | Layer | Role | Sections | | --- | --- | --- | | **Regulatory reference** | Single source of truth on the Regulation. Neutral, sourced, dated. | The CRA framework | | **Technical reference** | Single source of truth on the SBOM: formats, quality, VEX, licensing. | SBOM | | **Role-based paths** | Translation into obligations, risks and actions for a given role. Redefines nothing. | Legal, Cyber, Leadership | | **Operational** | Your organisation, tooling, templates and roadmap. | Organisation, Tooling, Resources | > **Editorial rule.** A regulatory concept is defined **exactly once**, in "The CRA > framework". The Legal and Cyber paths only offer role-oriented readings of it, with a link > to the canonical page. A duplicated definition is a defect to be reported. ### How to read a page Every page carries the same markers, in the same place: - a **primary audience badge** — Legal, Cyber, Leadership or Cross-cutting; - a **deadline** where one of the Regulation's three dates applies; - an **"At a glance"** box in the side column: legal basis (articles and annexes), the **evidence artefact** expected at audit, the owning function, and the **last review date**. The review date is not decoration. Undated regulatory content is content you cannot know is still true; three topics are still moving (harmonised standards, delegated acts, designation of national authorities), and the [updates](/en/updates/) section exists for that reason. ### Choosing a path - **[Legal path](/en/start/legal-path/)** — from qualifying the product to affixing the CE marking, in ten steps and about thirty minutes. - **[Cyber path](/en/start/cyber-path/)** — from generating an SBOM to the 24-hour reporting procedure, in ten steps. - **[Leadership view](/en/leadership/)** — exposure, cost, trade-offs. If you do not yet know whether you are in scope, start with [scope](/en/cra/scope-pde/) and then [exclusions](/en/cra/exclusions/): together they answer the only question that matters at the outset, in ten minutes. ### Four things to know before anything else 1. The CRA is a **Regulation**: directly applicable, with no national transposition. There will be no national law that pushes the deadline back. 2. The first deadline is not CE marking, it is **reporting**. Since 11 September 2026, an actively exploited vulnerability must be reported within **24 hours** — including for products placed on the market before that date. 3. The **SBOM is part of the technical documentation**. Without complete technical documentation there is no EU declaration of conformity; without a declaration there is no CE marking; without CE marking there is no sale in the Union. 4. Generating an SBOM in the build chain and steering the portfolio from a central platform are **two different jobs** — see [Generate and steer](/en/organisation/two-levels/). ## Cyber path in 10 steps URL: https://cra-reference.eu/en/start/cyber-path/ Description: A linear thirty-minute reading path, from generating an SBOM to the 24-hour reporting procedure, for an engineer new to the Cyber Resilience Act. Audience: cyber Published 2026-08-19, updated 2026-08-19 Thirty minutes, ten steps, in order. Each step ends with the question you should be able to answer before moving on. ### 1. Read what the Regulation technically requires — 5 min Read [Essential requirements](/en/cra/essential-requirements/), then the two pages that follow: [Product security](/en/cra/essential-requirements/product-security/) (Annex I, Part I) and [Vulnerability handling](/en/cra/essential-requirements/vulnerability-handling/) (Annex I, Part II). > **Be able to answer:** of the thirteen Part I requirements, which do not apply to your > product, and on what documented basis? ### 2. Know what a compliant SBOM is — 3 min Read [Definition](/en/sbom/definition/) and [What the CRA requires](/en/sbom/cra-requirement/). Commonly used format, machine-readable, at the very least top-level dependencies — a legal floor, not a target. > **Be able to answer:** why do a spreadsheet and a PDF fail the requirement? ### 3. Pick a format and stick to it — 3 min Read [Formats](/en/sbom/formats/), then [CycloneDX](/en/sbom/formats/cyclonedx/) and [SPDX](/en/sbom/formats/spdx/). > **Be able to answer:** what is your pivot format, and in which cases do you export to the > other? ### 4. Generate — 4 min Read [Generating SBOMs](/en/cyber/generating-sboms/) and [Generators](/en/tooling/generators/). The SBOM is produced **as close to the artefact as possible**, in the pipeline that builds it, never by hand afterwards. > **Be able to answer:** two tools produce two different SBOMs for the same artefact — how do > you keep them comparable over time? ### 5. Wire it into CI/CD — 3 min Read [CI/CD integration](/en/cyber/ci-cd/). Eight steps: build, generate, validate, sign, publish, apply policy, attach, archive. > **Be able to answer:** which conditions fail a build, and how does one obtain a waiver that > expires? ### 6. Understand generate versus steer — 4 min Read [Generate and steer](/en/organisation/two-levels/) then [Platforms](/en/tooling/platforms/). This is the most expensive misunderstanding in the field. "You put a scanner in CI, you are compliant" is false: without centralisation you can neither answer an authority nor know which shipped versions are affected. > **Be able to answer:** how long does it take you to list every product containing a given > component, across all shipped versions? ### 7. Handle vulnerabilities without drowning — 4 min Read [Vulnerability management](/en/cyber/vulnerability-management/), [VEX](/en/sbom/vex/) and [False positives](/en/cyber/false-positives/). A VEX is the documentary form of a reasoned decision not to fix. It is what distinguishes "handled" from "ignored". > **Be able to answer:** what is your ratio of actionable to raw alerts? ### 8. Open a disclosure channel — 2 min Read [Disclosure policy](/en/cyber/disclosure-policy/) and the public page [Vulnerability disclosure](/en/security/). The contact address and the published policy are **substantive obligations**, not courtesy pages. > **Be able to answer:** is your `security.txt` online, and is its `Expires` field still in > the future? ### 9. Arm the 24-hour procedure — 3 min Read [24 h / 72 h / 14 d procedure](/en/cyber/24h-runbook/) and [Reporting to ENISA](/en/cra/enisa-reporting/). An on-call rota, a tested channel, pre-filled templates, two exercises a year. > **Be able to answer:** what interval did you actually measure at the last exercise? ### 10. Monitor continuously — 2 min Read [Continuous monitoring](/en/cyber/continuous-monitoring/) and [Supply chain risk](/en/cyber/supply-chain-risk/). A component that is clean today is vulnerable tomorrow, with no new build. An SBOM is only useful if it is replayed daily against sources that move. --- ### Next [Secure by design](/en/cyber/secure-by-design/), [Secure updates](/en/cyber/secure-updates/) and the [technical checklist](/en/cyber/technical-checklist/) complete the path. Four pages cover the supply chain itself, and read in this order: 1. **[Reference incidents](/en/cyber/incidents/)** — fourteen dated compromises, so you know what is being discussed; 2. **[Securing the build chain](/en/cyber/securing-the-build-chain/)** — CI as an attack surface, not merely a tool; 3. **[Locking and updating dependencies](/en/cyber/dependency-locking/)** — freeze to rebuild, update to stay clear of known vulnerabilities; 4. **[Assessing an open source component](/en/cyber/assessing-components/)** — making Article 13(5) diligence computable. ## Legal path in 10 steps URL: https://cra-reference.eu/en/start/legal-path/ Description: A linear thirty-minute reading path, from qualifying the product to affixing the CE marking, for a lawyer new to the Cyber Resilience Act. Audience: legal Published 2026-08-19, updated 2026-08-19 Thirty minutes, ten steps, in order. Each step ends with the question you should be able to answer before moving on. ### 1. Understand what kind of text this is — 3 min Read [The CRA framework](/en/cra/) and [Regulation (EU) 2024/2847](/en/cra/regulation-2024-2847/). A Regulation, not a Directive: directly applicable, no transposition. Union harmonisation legislation under the new legislative framework: the grammar of CE marking, applied to cybersecurity. > **Be able to answer:** why will there be no national transposition law capable of pushing > the deadline back? ### 2. Determine whether your products are in scope — 5 min Read [Scope](/en/cra/scope-pde/) then [Exclusions](/en/cra/exclusions/). Watch three points: **components placed on the market separately** are products in their own right; **remote data processing solutions** inseparable from the product are in scope; pure SaaS falls under NIS 2 instead. > **Be able to answer:** is your cloud offering a remote data processing solution within the > meaning of the Regulation, or an out-of-scope service? ### 3. Classify each product — 4 min Read [Criticality classes](/en/cra/criticality-classes/). This is the page that drives budget and schedule: the class determines whether a **notified body** is mandatory. > **Be able to answer:** which of your products cannot self-assess? ### 4. Know what CE marking requires — 3 min Read [CE marking](/en/cra/ce-marking/). Seven cumulative conditions before affixing, including the technical documentation and the EU declaration of conformity. > **Be able to answer:** which pieces are missing today for your flagship product? ### 5. Understand where the SBOM fits — 3 min Read [What the CRA requires of the SBOM](/en/sbom/cra-requirement/) then [Technical documentation](/en/cra/technical-documentation/). The SBOM is a **constituent part** of the technical documentation, not a side deliverable. > **Be able to answer:** why does a file without a usable SBOM legally weaken the CE marking? ### 6. Internalise the reporting deadlines — 4 min Read [Reporting to ENISA](/en/cra/enisa-reporting/) then [Reporting duties, legal view](/en/legal/reporting-duties/). 24 hours, 72 hours, 14 days. Do not confuse this with the GDPR's 72 hours or with NIS 2 notification: one event can trigger all three. > **Be able to answer:** who, here, has authority to decide on a report at 3 a.m. on a > Sunday? ### 7. Size the exposure — 3 min Read [Penalties](/en/cra/penalties/) then [Exposure](/en/legal/exposure/). The fine is not the worst of it: a ban on, or withdrawal from, the Union market is. > **Be able to answer:** what is 2.5 % of your consolidated turnover, and what share of your > turnover is made in the Union? ### 8. Secure the supply chain by contract — 3 min Read [Contract clauses](/en/legal/contract-clauses/). Your reporting deadlines depend on how fast your suppliers react: their notification deadlines must be **strictly shorter** than yours. > **Be able to answer:** do your current supplier contracts let you meet 24 hours? ### 9. Handle intellectual property — 2 min Read [Open source licensing](/en/licensing/) — in particular the [family × scenario matrix](/en/licensing/) — then [Intellectual property](/en/legal/intellectual-property/). The CRA does not mandate licence compliance, but the SBOM it does mandate is precisely the tool that makes licence compliance demonstrable. That is the strongest funding argument on the Legal side. ### 10. Lock the market gate — 2 min Read [Pre-market checklist](/en/legal/placing-checklist/). Fifteen points, one page, printable and signable. It is the deliverable that gives Legal's veto its substance. --- ### Next [User information](/en/legal/user-information/), [Support period](/en/legal/support-commitments/) and [Evidence retention](/en/legal/evidence-retention/) complete the path. The [glossary](/en/glossary/) and [FAQ](/en/faq/) answer point questions. ## Tooling URL: https://cra-reference.eu/en/tooling/ Description: The two tooling families: SBOM generators inside the build chain, and platforms for steering the portfolio. Profiles, comparison and selection criteria. Audience: cyber Published 2026-08-19, updated 2026-08-19 The tools in this field fall into **two families that do different jobs** and are not substitutes. Confusing them is the most expensive mistake in the programme; the page [Generate and steer](/en/organisation/two-levels/) explains why. | | [Generators](/en/tooling/generators/) | [Platforms](/en/tooling/platforms/) | | --- | --- | --- | | Level | Application, one artefact | Organisation, the portfolio | | Question | "What is inside this artefact?" | "Which of your products contain this component?" | | Trigger | A build | A newly published vulnerability | | Output | A CycloneDX or SPDX file | Dashboards, alerts, reports, API | | Examples | Syft, Trivy, Grype, cdxgen, osv-scanner | OWASP Dependency-Track, Snyk, FOSSA, Black Duck | ### How to read the profiles Each tool is described against the same template: vendor, licence and business model, level, supported formats, ecosystem coverage, vulnerability sources, licence detection, VEX support, integrations, deployment mode and data sovereignty, strengths, limits, and a verdict for your context. > **Caveat.** These profiles describe categories of product and their structural properties, > not a snapshot of the market: versions, pricing and coverage change. Any purchasing decision > must rest on an evaluation run against your own artefacts, following the protocol in > [Selection criteria](/en/tooling/selection/). ### The position adopted Two principles guide the target tooling: 1. **An open, standardised generator**, so the SBOMs you produce stay portable and independent of whichever platform consumes them. A proprietary SBOM is a liability. 2. **A steering platform**, starting with a self-hostable option to validate the processes at zero software cost, before deciding on a commercial product if scale or legal requirements justify it. ## SBOM generators URL: https://cra-reference.eu/en/tooling/generators/ Description: Application-level tools: Syft, Grype, Trivy, cdxgen, osv-scanner, ScanCode, OSS Review Toolkit and native build-chain plugins. Audience: cyber Published 2026-08-19, updated 2026-08-19 **Level 1** tools: they produce the inventory of an artefact. See [Generate and steer](/en/organisation/two-levels/) for the distinction from platforms. > **Caveat.** These profiles describe categories of tool and their structural properties, not a > snapshot of the market. Coverage, formats and performance change; any decision must rest on an > evaluation run against your own artefacts. ### Syft | | | | --- | --- | | **Site** | [github.com/anchore/syft](https://github.com/anchore/syft) | | **Vendor** | Anchore | | **Licence** | Open (Apache 2.0) | | **Level** | Generation | | **Formats** | CycloneDX, SPDX, native format | | **Coverage** | Very broad, multi-ecosystem: system packages, languages, container images, file systems | | **Vulnerabilities** | No — that is Grype's role | | **Licences** | Declared metadata, no file-content analysis | | **Deployment** | Standalone binary, self-hosted | | **Strengths** | The de facto reference for generation; clean output; excellent CI integration; covers both file system and image | | **Limits** | Does not detect licences by content analysis; imperfect coverage of natively compiled binaries | | **Verdict** | **Reference generator** for most of your chains | ### Grype | | | | --- | --- | | **Site** | [github.com/anchore/grype](https://github.com/anchore/grype) | | **Vendor** | Anchore | | **Licence** | Open | | **Level** | Detection, downstream of generation | | **Input** | An SBOM, an image, a directory | | **Sources** | Aggregated public databases, distribution advisories | | **Strengths** | Complements Syft; consumes an already-produced SBOM, avoiding a rescan; handles distribution backports | | **Limits** | No reachability analysis | | **Verdict** | **Local** check in CI, alongside the correlation performed by the platform | ### Trivy | | | | --- | --- | | **Site** | [trivy.dev](https://trivy.dev/) | | **Vendor** | Aqua Security | | **Licence** | Open | | **Level** | Generation **and** detection | | **Scope** | SBOM, vulnerabilities, secrets, infrastructure-as-code misconfigurations, declared licences | | **Formats** | CycloneDX, SPDX | | **Strengths** | All-in-one, very easy to integrate, one command covers several checks; own, frequently updated vulnerability database | | **Limits** | All-in-one blurs responsibilities; for a mature arrangement, separating generation from detection makes replacing a link easier | | **Verdict** | **An excellent entry point** and a good fit for simple chains; to reassess once the steering platform is in place | ### cdxgen | | | | --- | --- | | **Site** | [github.com/cdxgen/cdxgen](https://github.com/cdxgen/cdxgen) | | **Vendor** | OWASP | | **Licence** | Open | | **Level** | Generation | | **Formats** | Native CycloneDX, including extensions | | **Coverage** | **Very broad across languages**, including ecosystems poorly covered elsewhere | | **Strengths** | Configurable analysis depth; produces rich CycloneDX documents with relationships and build metadata | | **Limits** | More demanding to configure; verbose output | | **Verdict** | Worth keeping for **ecosystems poorly covered** by generic generators | ### osv-scanner | | | | --- | --- | | **Site** | [google.github.io/osv-scanner](https://google.github.io/osv-scanner/) | | **Vendor** | Google | | **Licence** | Open | | **Level** | Detection | | **Source** | The OSV database, `purl` correlation | | **Strengths** | **High matching precision** thanks to per-ecosystem identifiers; sharply reduces false positives compared with CPE correlation | | **Limits** | Coverage centred on package ecosystems; less relevant for exotic system binaries | | **Verdict** | Use it **alongside** others, precisely for its low false-positive rate | ### ScanCode Toolkit and OSS Review Toolkit | | | | --- | --- | | **Site** | [ScanCode](https://github.com/aboutcode-org/scancode-toolkit) · [ORT](https://oss-review-toolkit.org/) | | **Vendor** | Open source communities | | **Licence** | Open | | **Level** | Generation, **licence**-oriented | | **Method** | Analysis of **file content**, not only of manifests | | **Strengths** | Detect licences and copyrights **in the code**, including vendored or copied code — which generic generators do not see | | **Limits** | Slow; verbose output requiring review effort | | **Verdict** | Essential for the **intellectual property** strand; run at a reduced cadence rather than on every build | ### Native build-chain plugins CycloneDX for Maven and Gradle, `npm sbom`, generators for .NET, Rust, Go, and their equivalents. | | | | --- | --- | | **Strengths** | See the **real resolution graph**, with the version arbitration actually applied; natively distinguish scopes — runtime, build, test | | **Limits** | One plugin per ecosystem to maintain; blind outside their own scope | | **Verdict** | **Prefer** as the primary source for languages with a dependency manager, complemented by a generic generator on the artefact | ### Recommended combination | Context | Primary | Cross-check | Licences | | --- | --- | --- | --- | | Java, .NET, Node, Python | Native plugin | Generic generator on the artefact | Content-analysis tool, at reduced cadence | | Go, Rust | Generic generator on the binary | — | Same | | C / C++ | Generator on the binary + build system | File-system analysis | Same | | Container image | Generator on the image | All-in-one scanner | Same | | Firmware | Specialised tooling | SBOM requirement on the supplier | Same | The principle: **one primary generator per family, pinned and documented**, one cross-check, and a separate, less frequent licence analysis. ## Steering platforms URL: https://cra-reference.eu/en/tooling/platforms/ Description: Organisation-level tools: OWASP Dependency-Track, Snyk, FOSSA, Black Duck, Mend, Sonatype, JFrog Xray, GUAC — and what really separates them. Audience: cyber Published 2026-08-19, updated 2026-08-19 **Level 2** tools: they aggregate the portfolio's SBOMs and re-evaluate them continuously. See [Generate and steer](/en/organisation/two-levels/). > **Caveat.** These profiles describe categories of solution and their structural properties, not > a snapshot of the market. Any purchasing decision must rest on an evaluation run against your > own artefacts, following the protocol in > [Selection criteria](/en/tooling/selection/). ### OWASP Dependency-Track | | | | --- | --- | | **Site** | [dependencytrack.org](https://dependencytrack.org/) | | **Steward** | OWASP | | **Licence** | Open | | **Deployment** | **Self-hostable** — full data sovereignty | | **Input** | Native **[CycloneDX](https://cyclonedx.org/)** ingestion, via API | | **Functions** | Continuous portfolio re-evaluation, policies, VEX support, project and version management, full API, notifications | | **Sources** | Aggregated public databases | | **Licences** | Tracking of declared licences, with associated policies | | **Strengths** | **Zero software cost**; designed for exactly the use the CRA imposes: aggregating SBOMs and replaying them over time; good API; self-hosting | | **Limits** | Real operating cost; no reachability analysis; licence detection limited to declared metadata; austere interface | | **Verdict** | **The best entry point.** Lets you demonstrate value and run in the processes before any investment, and remains sufficient for many organisations | ### Snyk | | | | --- | --- | | **Site** | [snyk.io](https://snyk.io/) | | **Model** | Service, usage-based pricing | | **Orientation** | **Developer experience** | | **Strengths** | Strong integration with IDEs, repositories and CI chains; enriched vulnerability database; automated fix suggestions; reachability analysis | | **Limits** | Vendor-hosted data — to be assessed against sovereignty requirements; cost grows with project count; the licensing strand is shallower than the specialists' | | **Verdict** | Relevant where the goal is to get **development teams to adopt** the topic | ### FOSSA | | | | --- | --- | | **Site** | [fossa.com](https://fossa.com/) | | **Model** | Service | | **Orientation** | **Licence compliance and intellectual property**, with a security strand | | **Strengths** | Attribution file generation; legal policy management; reports suited to investor and acquirer diligence; **speaks Legal's language** | | **Limits** | Shallower security strand than the specialists; hosting to be assessed | | **Verdict** | Worth considering where the **intellectual property strand** drives the programme | ### Black Duck | | | | --- | --- | | **Site** | [www.blackduck.com](https://www.blackduck.com/) | | **Model** | Enterprise, hosted or on-premises | | **Orientation** | Enterprise software composition analysis | | **Strengths** | **File-hash analysis** — detects copy-pasted code and undeclared components, which no manifest analysis sees; very deep licence coverage; strong presence in embedded and regulated sectors | | **Limits** | High cost; large result volumes requiring review effort; heavy deployment | | **Verdict** | Relevant for **embedded**, regulated sectors and organisations exposed to licence audits | ### Mend | | | | --- | --- | | **Site** | [www.mend.io](https://www.mend.io/) | | **Model** | Service, enterprise | | **Strengths** | Automated remediation, reachability-based prioritisation, broad coverage | | **Limits** | Hosting to be assessed; functional overlap with the above | | **Verdict** | A credible alternative in the enterprise segment | ### Sonatype Nexus Lifecycle | | | | --- | --- | | **Site** | [www.sonatype.com](https://www.sonatype.com/) | | **Model** | Enterprise | | **Distinctive feature** | Tight coupling with the **artefact repository** | | **Strengths** | Applies policy **at the repository gate**: a non-compliant component never enters the organisation, moving the control upstream | | **Limits** | Coherent mainly if the artefact repository is already from this vendor | | **Verdict** | Worth considering if you want to **block at source** rather than in CI | ### JFrog Xray | | | | --- | --- | | **Site** | [jfrog.com/xray](https://jfrog.com/xray/) | | **Model** | Enterprise | | **Distinctive feature** | Integrated with the same vendor's artefact repository | | **Verdict** | Relevant **if and only if** that repository is already in place; otherwise the coupling is a drawback | ### GUAC | | | | --- | --- | | **Site** | [guac.sh](https://guac.sh/) | | **Nature** | An open project that aggregates and graphs supply chain metadata — SBOMs, attestations, advisories | | **Use** | Complex cross-cutting queries over the dependency and provenance graph | | **Verdict** | **Worth watching**, for advanced uses; does not replace a steering platform today | ### What really separates these solutions Beyond feature lists, four axes make a real difference: 1. **Detection method.** Manifests only, or **file-hash analysis**? That determines whether vendored code is visible. 2. **Depth of the licensing strand.** Declared metadata, or content analysis and attribution generation? 3. **Reachability.** Can the product tell you whether the vulnerable function is called? That is the main lever against noise. 4. **Sovereignty and reversibility.** Where is the data, and can you leave with your SBOMs and your history? The fourth is the one forgotten at purchase and the most expensive on exit. ## Selection criteria and evaluation protocol URL: https://cra-reference.eu/en/tooling/selection/ Description: A weighted grid, an evaluation protocol run against your own artefacts, and the recommended tooling architecture. Audience: direction Published 2026-08-19, updated 2026-08-19 ### The weighted grid Weight it once, in committee, **before** looking at products — otherwise the weighting quietly adjusts itself to the favourite. | Criterion | Question | Indicative weight | | --- | --- | --- | | **Ecosystem coverage** | Does it cover the languages and platforms you actually use? | 20 % | | **Fidelity of the SBOMs produced** | Measured gap against a cross-check, on your artefacts | 15 % | | **Correlation quality** | False positive rate measured on a known sample | 15 % | | **VEX and CSAF support** | Can decisions be documented and published? | 10 % | | **Long-term archiving** | History retained, full export possible | 10 % | | **API and automation** | Is everything drivable without a graphical interface? | 10 % | | **Sovereignty** | Where is the data hosted? What leaves the Union? | 8 % | | **Reversibility** | Can you leave with your SBOMs, history and VEX statements? | 5 % | | **Legal needs** | Attributions, licence reports, exception register | 5 % | | **Total cost over five years** | Licence, operations, integration, training | Disqualifying above budget | The two most commonly under-weighted criteria are **reversibility** and **operating cost**. Both are paid at the end. ### The evaluation protocol A credible evaluation runs on **your artefacts**, not on the vendor's demonstration. **Duration:** four to six weeks. **Scope:** three representative products — a simple one, a multi-language one, an embedded or containerised one. #### Steps 1. **Build a reference set.** For each product, establish by hand the list of expected components, at least for direct dependencies and a sample of transitive ones. It is the most thankless work, and it is what makes the evaluation objective. 2. **Inject known cases.** Deliberately add a known vulnerable component, a copyleft-licensed component, a vendored component, a statically linked component. 3. **Measure**, for each candidate: - components found / expected (**recall**); - components wrongly reported (**precision**); - real vulnerabilities detected and **false positives**; - licences correctly identified; - time added to the build; - integration effort in person-days. 4. **Test reversibility.** Export all the data and check the export is usable without the tool. 5. **Test retrieval.** Simulate an authority request about a version ingested three weeks earlier. 6. **Score** against the grid, and document. #### What is not an evaluation - A demonstration on the vendor's demo repositories. - A comparison of feature lists. - A free trial on a single simple project. - An analyst opinion with no measurement on your artefacts. ### The recommended architecture 1. **An open, standardised generator** as the primary source, so SBOMs stay **portable**. An SBOM locked into a proprietary format is a liability. 2. **A self-hostable steering platform to start with**, to validate the processes, measure real volumes and provide a factual baseline for comparison. 3. **An investment decision afterwards**, based on measured gaps rather than promises: reachability, hash-based detection, depth of the licensing strand, integration. 4. **The evidence vault stays internal**, whatever the tool. The platform is a working tool; the company's evidential memory must not depend on a contract. ### The three questions to ask any vendor 1. **What happens if you leave?** Export format, exhaustiveness, history and VEX statements included, time to make it available. 2. **Where is the data, and who can access it?** Location, subprocessors, support access conditions. 3. **How do you measure your false positives?** An evasive answer to that question is itself information. ## Regulatory watch URL: https://cra-reference.eu/en/updates/ Description: What is still moving: harmonised standards, delegated and implementing acts, designation of national authorities. The mechanism that keeps this site from becoming wrong. Audience: transverse Published 2026-08-19, updated 2026-08-19 An unmaintained regulatory reference becomes wrong without warning. This page sets out **what is liable to change**, **where to check it**, and **what to do when it does**. ### The three open matters #### 1. Harmonised standards **Stake:** they condition the **presumption of conformity** and, for class I products, whether self-assessment is possible at all. **Where to track:** the work of joint technical committee **CEN/CENELEC JTC 13, working group 9**, in response to standardisation request **M/606**; and above all the **citation of the references in the *Official Journal of the European Union***, which alone produces the legal effect. **What changes when a standard is cited:** the module A route opens for the class I products covered, subject to **full** application. The pages [Criticality classes](/en/cra/criticality-classes/), [Class I](/en/cra/criticality-classes/important-class-1/) and [Conformity assessment](/en/cra/conformity-assessment/) must be reviewed, and each affected product's assessment scenario re-examined. #### 2. Commission delegated and implementing acts **Stake:** they can change scope and detail. | Expected act | Effect | | --- | --- | | **Update of Annexes III and IV** | A product may change class, or enter one | | **Specification of the SBOM format and elements** | Your format and level of detail become constrained | | **Certification requirement** for critical product categories | A move to EUCC-style assessment | | **Common specifications** | An alternative presumption route absent a standard | | **Simplified technical documentation form** for small enterprises | A documentation easement | **What to do:** on each publication, assess the impact on the **classification register** and on the affected pages, then produce an impact note for the committee. #### 3. National implementation **Stake:** knowing who to address, in which language, through which channel. **Points to track:** designation of **market surveillance authorities** and **coordinating CSIRTs** by Member States; national **penalty regimes**; the practical arrangements of ENISA's **single reporting platform**; **accreditation of notified bodies** and the exact scope of their notification in the NANDO database. **What to do:** keep up to date, per Member State where your products are made available, the competent authority and the reporting channel. ### Sources to follow | Source | What it holds | Consultation frequency | | --- | --- | --- | | **[EUR-Lex — the Regulation](https://eur-lex.europa.eu/eli/reg/2024/2847/oj)** | Consolidated text, delegated and implementing acts | Monthly | | ***[Official Journal of the European Union](https://eur-lex.europa.eu/oj/direct-access.html)*** | **Citation of harmonised standards** | Monthly | | **[European Commission, CRA page](https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act)** | Guidance, FAQ, timeline | Monthly | | **[ENISA](https://www.enisa.europa.eu/)** · **[EUVD](https://euvd.enisa.europa.eu/)** | Reporting platform, vulnerability database, technical documents | Monthly | | **[CEN / CENELEC](https://www.cencenelec.eu/)** JTC 13 | Standards progress | Quarterly | | **[Notified bodies](https://single-market-economy.ec.europa.eu/single-market/goods/building-blocks/notified-bodies_en)** (NANDO database) | Designated bodies and the scope of their notification | Quarterly | | **[ANSSI](https://cyber.gouv.fr/)** · **[CERT-FR](https://www.cert.ssi.gouv.fr/)** | National implementation, alerts | Monthly | > **What is not a source.** Vendor blog posts, commercial white papers, unverified summaries. They > contain recurring errors, particularly about criticality classes and the status of open source. > Any statement reused internally must be traceable to a published article, annex or act. ### The watch process 1. **Monthly review** of the sources by the legal department. 2. **Impact note** whenever something changes: what the new element says, which pages are affected, what action is required, by when. 3. **Update the affected pages**, refreshing their review date. 4. **Quarterly item at the CRA committee**: what changed, what you did. 5. **Re-examine the registers** for classification and support if the change affects them. ### Tagging entries Every entry in the watch feed carries one or more tags: - **Legal impact** — changes a documentary or contractual obligation - **Cyber impact** — changes a technical requirement or a tool - **Timeline impact** — changes a deadline or a critical path - **Action required** — calls for a decision, as opposed to information only ### Site revision log | Date | Subject | Pages affected | | --- | --- | --- | | 19 August 2026 | Initial publication of the reference | All | This table is updated at every significant revision. It records **what the organisation knew, and since when** — useful information in an inspection.