À partir du 11 septembre 2026, tout éditeur qui vend un produit connecté dans l’Union européenne devra prouver, avec des preuves cryptographiques vérifiables, que son code n’a pas été trafiqué. Le Cyber Resilience Act (règlement UE 2024/2847) fait basculer la signature numérique et le hachage cryptographique du rang de bonne pratique à celui d’obligation légale, sous peine d’une amende pouvant grimper jusqu’à 15 millions d’euros ou 2,5 % du chiffre d’affaires mondial annuel, le montant le plus élevé étant retenu. Entre le 27 et le 29 juillet 2026, deux textes ont précisé les contours techniques de cette obligation : la Commission européenne a publié ses lignes directrices sur l’article 26 du CRA, et l’agence américaine CISA a mis à jour sa nomenclature logicielle (SBOM) pour y intégrer une signature d’auteur et un hachage de chaque composant exécutable.

Ce n’est pas une nouvelle échéance administrative de plus. C’est un changement de nature : la conformité ne se prouve plus par une déclaration papier, mais par une chaîne de signatures et de hachages que n’importe quel auditeur, régulateur ou client peut vérifier techniquement. Pour les développeurs, les RSSI et les éditeurs de logiciels qui vendent en Europe, cela signifie revoir en profondeur la manière dont le code est construit, signé et documenté d’ici la fin de l’année.

Le 11 septembre 2026, une échéance qui arrive plus vite qu’il n’y paraît

Le règlement CRA est entré en vigueur le 10 décembre 2024, mais son application se fait par vagues. Le chapitre IV, qui régit la désignation des organismes d’évaluation de la conformité, s’applique depuis le 11 juin 2026. L’article 14, celui qui concentre l’attention des équipes sécurité, entre en application le 11 septembre 2026. À partir de cette date, tout fabricant d’un produit comportant des éléments numériques devra signaler à l’ENISA et au CSIRT national compétent toute vulnérabilité activement exploitée ou tout incident grave touchant son produit, dans un délai de 24 heures après en avoir eu connaissance.

L’application intégrale du texte, elle, ne tombera que le 11 décembre 2027. Mais les cabinets d’avocats qui suivent le dossier insistent sur un point : les obligations de signalement de septembre 2026 s’appliquent dès le premier jour à tous les produits déjà commercialisés, pas seulement à ceux lancés après cette date. Un éditeur qui vend depuis 2019 un logiciel encore utilisé aujourd’hui tombe donc sous le coup de la loi, même sans nouvelle sortie de version.

Pourquoi la signature numérique devient le cœur du dispositif

Le CRA reste, sur le papier, technologiquement neutre. Le texte ne cite aucun algorithme précis. Mais l’annexe I, qui fixe les exigences essentielles de cybersécurité, impose de garantir l’intégrité du code et de ses mises à jour tout au long du cycle de vie du produit. En pratique, la seule manière crédible de tenir cette obligation reste la cryptographie : signer chaque exécutable avec une clé privée, publier le hachage de chaque composant, et conserver la preuve que rien n’a changé entre le build validé par les équipes qualité et le binaire livré au client.

La Commission a explicité cette logique dans sa communication C(2026) 5252 du 27 juillet 2026, qui accompagne le règlement d’un guide non contraignant truffé d’exemples concrets. Le texte rappelle que seule la Cour de justice de l’UE peut donner une interprétation faisant autorité, et que seules les normes harmonisées déclenchent une présomption de conformité au sens de l’article 27. Mais dans les faits, cette guidance sert déjà de feuille de route à des dizaines d’éditeurs qui s’en servent pour prioriser leurs chantiers techniques avant l’échéance de septembre.

Fonctions de hachage : SHA-256 et SHA-512 en position dominante

Les cartographies techniques associées au SBOM version 2.1 privilégient les algorithmes de la famille SHA-2, en particulier SHA-256 et SHA-512, pour calculer l’empreinte de chaque composant exécutable. Ce choix suit les recommandations du NIST et s’aligne avec les référentiels déjà utilisés dans les formats CycloneDX et SPDX. Rien n’interdit SHA-3, mais son adoption reste marginale dans les chaînes d’outillage actuelles faute de support natif généralisé dans les registres de paquets.

Schémas de signature : RSA, ECDSA et EdDSA cohabitent

Pour la signature elle-même, trois familles dominent la pratique : RSA (souvent en 2048 ou 3072 bits), ECDSA sur la courbe P-256, et EdDSA avec Ed25519. Les outils de signature de conteneurs comme Sigstore et Cosign, largement utilisés dans les pipelines CI/CD open source, ont accéléré l’adoption d’Ed25519 pour sa rapidité et la taille compacte de ses signatures. Les grands éditeurs qui doivent maintenir une compatibilité avec du matériel plus ancien continuent, eux, de s’appuyer sur RSA.

Le SBOM 2.1 : signature d’auteur et hachage de composant deviennent obligatoires

Le 29 juillet 2026, la CISA a publié une révision de son document de référence sur les éléments minimaux d’une nomenclature logicielle. Deux ajouts changent la donne pour les équipes techniques. Le premier, la « SBOM Author Signature », est une signature numérique attribuable à l’auteur de la nomenclature. Elle garantit que la personne ou le système qui a signé est bien celui qu’il prétend être, et que les données n’ont pas été modifiées après signature. Le second, le couple « Component Hash Value » et « Component Hash Algorithm », impose de fournir l’empreinte cryptographique de chaque composant exécutable ainsi que l’algorithme utilisé pour la calculer.

La documentation technique reste stricte sur un point : si l’auteur de la SBOM n’a pas accès à l’artefact exécutable au moment de la rédaction, il doit marquer le hachage comme « inconnu ». Il lui est explicitement interdit de fabriquer une valeur de substitution. Cette exigence vise directement les pratiques de certains fournisseurs qui remplissaient leurs nomenclatures avec des valeurs approximatives faute d’accès au binaire final.

Voici, à titre d’illustration, la structure d’un bloc de composant conforme à cette nouvelle exigence, dans un format inspiré de CycloneDX :

{
  "component": {
    "name": "auth-service",
    "version": "3.4.1",
    "hashes": [
      {
        "alg": "SHA-256",
        "content": "a94a8fe5ccb19ba61c4c0873d391e987982fbbd3"
      }
    ],
    "authorSignature": {
      "algorithm": "Ed25519",
      "signer": "[email protected]",
      "signature": "3f8a91c2..."
    }
  }
}

Ce n’est pas un standard légal en soi, mais une spécification technique américaine. Son intérêt pour un éditeur européen tient à sa convergence avec les attentes du CRA : un composant signé et haché de cette manière fournit exactement la preuve technique que l’article 26 réclame pour démontrer l’intégrité du produit.

Le calendrier complet, échéance par échéance

DateObligationTexte de référence
10 décembre 2024Entrée en vigueur du règlement CRARèglement (UE) 2024/2847
11 juin 2026Application du chapitre IV (organismes d’évaluation de la conformité)Articles 35 à 51
27 juillet 2026Publication de la guidance de la Commission sur l’article 26Communication C(2026) 5252
29 juillet 2026Mise à jour du SBOM Minimum Elements (v2.1), signature et hachage requisCISA / NTIA
11 septembre 2026Signalement obligatoire des vulnérabilités exploitées sous 24 hArticle 14
11 décembre 2027Application intégrale du règlement, exigences essentielles de l’annexe IEnsemble du règlement

15 millions d’euros ou 2,5 % du chiffre d’affaires : comment le calcul fonctionne

Le régime de sanctions du CRA suit une logique à deux étages. Pour les infractions les plus graves, celles qui touchent aux exigences essentielles de l’annexe I, aux obligations des fabricants de l’article 13, ou au signalement de l’article 14, l’amende peut atteindre 15 millions d’euros ou 2,5 % du chiffre d’affaires mondial annuel de l’exercice précédent, le montant le plus élevé étant retenu. Pour un grand groupe technologique, cela peut représenter plusieurs centaines de millions d’euros. Pour les manquements moins sévères, notamment certaines obligations d’information, le plafond descend à 10 millions d’euros ou 2 % du chiffre d’affaires.

Cette architecture reprend le mécanisme déjà connu du RGPD, où le pourcentage du chiffre d’affaires vise explicitement les multinationales pour qui une amende forfaitaire resterait négligeable. La différence avec le RGPD tient à la nature de la preuve : là où une autorité de protection des données examine des registres de traitement et des contrats, un régulateur CRA pourra demander à examiner des signatures cryptographiques, des journaux de build et des hachages de composants. La conformité devient vérifiable techniquement, pas seulement déclarative.

Comparaison : l’approche européenne face à l’approche américaine

Les deux textes publiés à trois jours d’intervalle fin juillet 2026, la guidance de la Commission côté européen et le SBOM v2.1 côté américain, ne poursuivent pas exactement le même objectif, mais ils convergent techniquement. Le tableau suivant résume les différences principales.

CritèreCyber Resilience Act (UE)SBOM Minimum Elements v2.1 (États-Unis)
Nature juridiqueRèglement contraignant, sanctions financièresSpécification technique non contraignante
PortéeTout produit avec éléments numériques vendu dans l’UEFournisseurs de l’administration fédérale américaine et écosystème volontaire
Signature exigéeIntégrité démontrable, technologie neutreSBOM Author Signature, champ obligatoire
Hachage de composantImplicite via les exigences d’intégrité de l’annexe IComponent Hash Value et Component Hash Algorithm, champs obligatoires
Sanction en cas de non-conformitéJusqu’à 15 M€ ou 2,5 % du CA mondialExclusion des marchés publics fédéraux
Échéance clé 202611 septembre (signalement des vulnérabilités)29 juillet (publication de la révision v2.1)

Pour un éditeur qui vend des deux côtés de l’Atlantique, la bonne nouvelle tient dans cette convergence technique. Une chaîne de build qui signe ses artefacts et publie des hachages conformes au SBOM v2.1 couvre déjà une bonne partie des attentes techniques du CRA en matière d’intégrité. Le travail supplémentaire porte surtout sur la partie processus : signalement sous 24 heures, documentation du cycle de vie, et interaction avec les autorités de surveillance du marché de chaque État membre.

Ce que disent les institutions européennes

Au Parlement européen, l’eurodéputé rapporteur Nicola Danti avait résumé l’ambition du texte au moment de son adoption : « Le Cyber Resilience Act va renforcer la cybersécurité des produits connectés, en s’attaquant aux vulnérabilités du matériel comme du logiciel, pour faire de l’UE un continent plus sûr et plus résilient ».

La portée du texte, elle, est décrite sans détour par l’Office des publications de l’UE : « Une législation inédite à l’échelle de l’UE : le Cyber Resilience Act introduit des exigences de cybersécurité obligatoires pour les produits matériels et logiciels, tout au long de leur cycle de vie ».

Le règlement lui-même pose sa logique dès son préambule : « La cybersécurité est l’un des enjeux clés pour l’Union », avant de préciser qu’il est « nécessaire de renforcer l’approche de l’Union en matière de cybersécurité, de traiter la cyber-résilience au niveau de l’Union et d’améliorer le fonctionnement du marché intérieur en établissant un cadre juridique uniforme pour les exigences essentielles de cybersécurité applicables à la mise sur le marché de produits comportant des éléments numériques ». La Commission européenne, de son côté, présente le texte comme « le nouveau plan de l’UE pour garantir que tous les produits numériques du marché européen sont protégés contre les cybermenaces ».

Contexte historique : pourquoi signer le code n’est plus optionnel

La signature de code existe depuis les années 1990, mais elle est longtemps restée une pratique volontaire, réservée aux pilotes de systèmes d’exploitation ou aux applications mobiles distribuées sur les stores officiels. Deux incidents ont changé la perception du risque. L’attaque SolarWinds, découverte fin 2020, a montré qu’un attaquant capable de compromettre une chaîne de build pouvait signer du code malveillant avec une clé légitime, rendant la détection quasiment impossible pendant des mois. L’incident xz-utils de mars 2024, où une porte dérobée avait été introduite dans une bibliothèque de compression largement utilisée par les distributions Linux, a rappelé que l’open source n’est pas épargné.

Le CRA et le SBOM v2.1 traduisent cette leçon en obligation réglementaire. Une signature seule ne suffit pas si elle n’est pas rattachée, par un hachage vérifiable, à un artefact précis. C’est exactement l’écueil que la nouvelle exigence de « Component Hash Value » vient combler : elle empêche qu’une signature valide couvre un binaire différent de celui réellement livré.

Impact sur le marché : un chantier pluriannuel, coûteux pour les PME

Le CRA couvre, selon sa définition, tout produit comportant des éléments numériques mis sur le marché européen, ce qui englobe potentiellement des millions de références logicielles et matérielles, des objets connectés grand public aux serveurs d’entreprise. Les cabinets de conseil qui accompagnent la mise en conformité décrivent un effort pluriannuel et coûteux en millions d’euros pour les grands fabricants, avec une charge disproportionnée pour les petites structures.

Grands groupes : un chantier d’infrastructure

Pour un éditeur qui gère des centaines de pipelines de build, la mise en conformité passe par le déploiement de modules matériels de sécurité (HSM) pour protéger les clés de signature, la refonte des manifestes de mise à jour (SUIT, UEFI) pour y intégrer hachages et métadonnées d’intégrité, et la mise en place de journaux d’audit traçant qui a signé quoi et à quel moment. Ce sont des projets qui se comptent en semestres, pas en semaines.

PME et éditeurs open source : une charge disproportionnée

L’article 26 du CRA prévoit une attention particulière aux micro-entreprises et PME dans la guidance de la Commission, mais l’écart de moyens reste réel. Une petite structure qui maintient un composant open source largement réutilisé peut se retrouver, du jour au lendemain, dans le champ d’application du texte sans disposer d’une équipe sécurité dédiée. C’est un sujet que la Commission dit vouloir clarifier davantage dans les prochaines révisions de sa guidance.

La suite post-quantique : Let’s Encrypt mise sur les certificats Merkle Tree

Début juin 2026, l’autorité de certification Let’s Encrypt a annoncé sa stratégie pour préparer le Web PKI à l’ère post-quantique. Plutôt que d’intégrer directement de lourdes signatures ML-DSA dans chaque certificat, ce qui alourdirait chaque poignée de main TLS, l’organisation a choisi de développer des certificats basés sur des arbres de Merkle (Merkle Tree Certificates). Le principe consiste à regrouper des millions de certificats sous une seule racine signée, avec des preuves d’inclusion compactes pour chaque certificat individuel, ce qui intègre nativement la transparence des certificats au processus de délivrance.

La feuille de route prévoit un environnement de test délivrant ces certificats fin 2026, avec un déploiement en production visé pour 2027. Let’s Encrypt précise que les abonnés actuels n’ont rien à faire dans l’immédiat, mais que les clients ACME, bibliothèques et outils devront évoluer pour supporter ce nouveau format. La bascule prendra plusieurs années, un calendrier qui recoupe presque l’échéance d’application intégrale du CRA en décembre 2027.

NIS2 et CRA : deux textes qui se recoupent sur le terrain

Le 26 mai 2026, le groupe de coopération NIS a validé des modèles communs de signalement d’incidents pour la directive NIS2, applicables dans l’ensemble des États membres. Ces gabarits couvrent la classification de l’incident, les systèmes touchés, le nombre estimé d’utilisateurs affectés, la chronologie des événements et l’implication éventuelle de fournisseurs tiers. Plusieurs cabinets de conseil distribuaient dès la mi-juillet 2026 des versions prêtes à l’emploi de ces modèles, avec des rapports à 24 heures, 72 heures et un rapport final.

Pour une entreprise soumise aux deux textes, ces gabarits NIS2 servent de base pratique pour bâtir le processus de signalement exigé par l’article 14 du CRA à partir de septembre 2026. C’est un des rares cas où deux réglementations européennes distinctes convergent sur un outil opérationnel commun, plutôt que d’imposer des formats concurrents.

Les praticiens du droit tirent la sonnette d’alarme

Les cabinets qui suivent le dossier de près insistent sur l’urgence du calendrier. Le cabinet Crowell & Moring a publié une alerte client qualifiant l’obligation de signalement de l’article 14 de disposition la plus exigeante sur le plan opérationnel du règlement, rappelant que les fabricants de produits connectés vendus dans l’UE doivent avoir un processus de gestion des vulnérabilités prêt avant le 11 septembre 2026. Le cabinet Noerr, dans une analyse similaire, décrit la guidance du 27 juillet comme une aide précieuse à l’interprétation pour les opérateurs économiques concernés, tout en soulignant les frictions persistantes avec les règles sectorielles existantes et la directive NIS2.

Du côté des analystes indépendants, plusieurs commentateurs spécialisés en droit du numérique ont souligné, dès la fin juillet 2026, que cette guidance ne modifie ni la loi ni les délais. Elle sert avant tout de lecture pratique sur laquelle les fabricants peuvent bâtir leur plan de mise en conformité, avec des dizaines d’exemples concrets pour trancher les cas ambigus, notamment autour des logiciels open source et de la notion de modification substantielle.

Ce que les entreprises françaises doivent faire d’ici la fin de l’année

Pour une entreprise française qui vend un produit connecté ou un logiciel en Europe, la priorité immédiate reste le processus de signalement des vulnérabilités. Un canal de contact avec le CSIRT national et l’ENISA doit être opérationnel avant le 11 septembre 2026, avec une procédure interne capable de qualifier un incident et de le notifier en moins de 24 heures. En parallèle, cartographier les composants logiciels critiques, identités numériques, infrastructures PKI et canaux TLS reste la meilleure façon de prioriser les efforts de signature et de hachage avant l’échéance de 2027.

Sur le plan technique, générer des SBOM au format CycloneDX ou SPDX avec signature d’auteur et hachage de composant dès aujourd’hui évite un rattrapage précipité l’an prochain. Les équipes qui utilisent déjà des outils comme Sigstore, Cosign ou des HSM pour signer leurs artefacts ont une longueur d’avance mesurable sur celles qui découvrent le sujet à l’approche de l’échéance.

Cinq prédictions pour 2027-2030

  • La signature de code deviendra un critère d’achat. Les appels d’offres publics européens commenceront à exiger des SBOM signés dès 2027, en s’appuyant sur la convergence entre CRA et SBOM v2.1.
  • Un marché des HSM et de la gestion de secrets progressera fortement en Europe. La demande pour des modules de sécurité matériels et des plateformes de gestion de clés devrait croître à mesure que les échéances de 2026 et 2027 se rapprochent.
  • Les PME et les mainteneurs open source réclameront des dérogations élargies. La pression sur les petites structures poussera la Commission à publier une guidance complémentaire spécifique aux projets communautaires d’ici fin 2027.
  • Les certificats Merkle Tree de Let’s Encrypt deviendront la norme de facto du Web PKI post-quantique une fois le déploiement en production lancé en 2027, entraînant une mise à jour en cascade des clients ACME.
  • D’autres juridictions s’aligneront sur le modèle CRA. Le Royaume-Uni et des pays hors UE qui commercent avec le marché européen devraient introduire des exigences de signature et de hachage comparables pour rester compatibles avec les chaînes d’approvisionnement européennes.

Foire aux questions

Le CRA impose-t-il un algorithme de signature précis ?

Non. Le règlement reste technologiquement neutre et ne cite aucun algorithme dans son texte. Dans la pratique, les guides techniques associés au SBOM v2.1 orientent vers SHA-256 ou SHA-512 pour le hachage, et RSA, ECDSA ou EdDSA pour la signature.

Mon entreprise est-elle concernée si elle vend uniquement du logiciel, sans matériel ?

Oui. La définition de produit comportant des éléments numériques couvre le logiciel autonome, y compris les solutions de traitement de données à distance, dès lors qu’il est mis sur le marché européen.

Que risque une entreprise qui ne signale pas une vulnérabilité exploitée dans les 24 heures ?

Le manquement à l’article 14 relève des infractions les plus graves du règlement, exposant l’entreprise à une amende pouvant atteindre 15 millions d’euros ou 2,5 % de son chiffre d’affaires mondial annuel.

Les logiciels open source sont-ils exemptés du CRA ?

Pas totalement. La guidance du 27 juillet 2026 prévoit un traitement spécifique pour certaines configurations open source, mais un composant open source intégré dans un produit commercial reste dans le champ d’application du texte, ce qui pousse les éditeurs à documenter et signer leurs dépendances.

Quelle est la différence entre le SBOM v2.1 américain et les exigences du CRA ?

Le SBOM v2.1 est une spécification technique publiée par la CISA, non contraignante juridiquement en dehors des marchés publics fédéraux américains. Le CRA est un règlement européen assorti de sanctions financières. Les deux convergent techniquement sur la nécessité de signer et de hacher les composants logiciels.

Faut-il déjà migrer vers des algorithmes post-quantiques pour être conforme au CRA ?

Non, pas dans l’immédiat. Le CRA porte sur l’intégrité et la signature du code, pas sur la résistance quantique des algorithmes. La feuille de route ANSSI fixe séparément une transition post-quantique par étapes, avec des jalons à horizon 2030.

Où une entreprise française peut-elle signaler une vulnérabilité au titre du CRA ?

Le signalement passe par le CSIRT national désigné et par l’ENISA, via la plateforme de notification unique prévue à l’article 16 du règlement.

Le guide de la Commission du 27 juillet 2026 change-t-il les délais légaux ?

Non. La Commission le précise explicitement : cette guidance n’est pas contraignante, ne modifie pas le règlement et ne crée aucun nouveau délai. Elle sert uniquement à clarifier l’application pratique du texte déjà en vigueur.