CRA : le 11 septembre 2026, le signalement devient obligatoire

8 septembre 2026

Les Tontons

Mis à jour le 7 septembre 2026

On vous a dit que le CRA, c’est pour décembre 2027 ? Faux.

Le 11 septembre 2026, la première obligation contraignante entre en vigueur : le signalement des vulnérabilités activement exploitées et des incidents graves. Et contrairement à ce que beaucoup croient, elle ne concerne pas que vos produits futurs.

Ce qui change réellement le 11 septembre

Le Cyber Resilience Act (règlement UE 2024/2847) entre en application par paliers. La première échéance (juin 2026) concernait la notification des organismes d’évaluation de conformité — largement invisible pour les fabricants. La deuxième, le 11 septembre 2026, ne l’est pas : les obligations de signalement de l’article 14 démarrent.[2]

Concrètement, tout fabricant de produits comportant des éléments numériques (PDE) mis sur le marché européen devra notifier, via la plateforme unique de l’ENISA (Single Reporting Platform, SRP) :

Les vulnérabilités activement exploitées — une faille pour laquelle il existe une preuve fiable qu’un acteur malveillant l’exploite dans un système sans l’autorisation du propriétaire. Pas chaque CVE publié, pas un proof-of-concept de chercheur : l’exploitation réelle, en conditions réelles.[1]
Les incidents graves — un incident qui affecte, ou est susceptible d’affecter, la capacité du produit à protéger la disponibilité, l’authenticité, l’intégrité ou la confidentialité des données ou fonctions.

Les délais : 24 h / 72 h / 14 jours — avec un piège

La mécanique est en trois temps, à compter du moment où le fabricant prend connaissance de l’événement :

24 heures : early warning (alerte précoce)
72 heures : notification détaillée (nature de la vulnérabilité, mode d’exploitation, première évaluation d’impact)
Rapport final : dans les 14 jours après qu’une mesure corrective (patch complet ou contournement) est disponible[3]

Le piège que la plupart ratent : pour les incidents graves, le rapport final n’est pas dû 14 jours après un correctif, mais un mois après la notification de 72 h.[3] Et le délai de 14 jours court dès qu’un workaround existe — on ne peut pas le repousser indéfiniment en arguant que le correctif définitif n’est pas prêt.

Le point qui va faire mal : votre parc déjà vendu est dans le scope

C’est l’angle mort numéro un. L’article 69(2) prévoit une règle transitoire : les produits placés sur le marché avant le 11 décembre 2027 ne relèvent du règlement complet que s’ils sont substantiellement modifiés après cette date. Beaucoup en ont conclu que leur catalogue existant était tranquille.

L’article 69(3) casse ce raisonnement[1] : il exclut explicitement l’article 14 de la transition. Traduction : un produit vendu en 2020, plus jamais touché, n’aura peut-être jamais besoin de marquage CE au titre du CRA — mais si une vulnérabilité activement exploitée est découverte dessus après le 11 septembre 2026, elle est signalable.[1] Votre base installée est dans le scope du reporting, même quand elle est hors scope des exigences produit.

Deux limites à connaître :

Pas de rétroactivité temporelle : une exploitation dont vous aviez connaissance avant le 11 septembre 2026 n’a pas à être notifiée. L’obligation s’attache au moment de la prise de connaissance, à partir de cette date.
Pas de seuil d’exonération[5] : startups, PME et grands groupes sont logés à la même enseigne. Le CRA ne prévoit aucun seuil.

Pourquoi c’est le premier endroit où les amendes vont tomber

Le reporting est une obligation vivante et continue : elle peut se déclencher à tout moment, contrairement au marquage CE qui se fait une fois avant la mise sur le marché. C’est aussi la plus facile à contrôler pour les autorités de surveillance du marché — et la non-conformité est simple à constater : vous n’avez pas notifié dans les délais.

Sanctions possibles au titre de l’article 64 (Tier 1) : jusqu’à 15 millions d’euros ou 2,5 % du chiffre d’affaires mondial.[6] Et les premières priorités d’enforcement annoncées visent explicitement la ponctualité des dépôts sous 24 h et la qualité de l’analyse de cause racine.

Les implications pour le hardware et l’IoT

Pour les équipes qui conçoivent des produits embarqués, trois conséquences concrètes :

Le « vendre puis oublier » est terminé. Le CRA impose une veille post-commercialisation : surveiller les vulnérabilités découvertes après la mise sur le marché, publier des correctifs pendant toute la durée d’assistance (5 ans minimum par défaut), conserver documentation et mises à jour 10 ans.
Le SBOM devient structurellement indispensable. Plus de 48 000 CVE publiées en 2025, soit ~131 par jour[4] : impossible de corréler manuellement une vulnérabilité exploitée à un composant de votre BOM sans inventaire machine-lisible (CycloneDX ou SPDX). Le SBOM formel n’est exigé qu’en décembre 2027 — mais le reporting du 11 septembre est pratiquement irréalisable sans lui.
Les composants open source ne vous protègent pas. Si une faille activement exploitée vient d’un composant open source que vous avez intégré, vous devez la signaler — et le fabricant du composant, s’il l’a mis sur le marché séparément, a la même obligation. Les dépendances en fin de vie deviennent un passif juridique : si plus personne ne maintient le composant, vous ne pouvez pas produire le « correctif » que le rapport final suppose.

Ce qu’il faut faire avant le 11 septembre

Désigner un responsable et un chemin d’escalade — qui a l’autorité et l’accès pour déposer une notification en moins de 24 h, y compris le week-end.
Vérifier l’accès à la SRP — la plateforme ENISA est le canal unique ; les soumissions par email ne seront acceptées que si l’ENISA déclare officiellement la plateforme hors ligne. Attention : au 1er septembre, l’URL publique de la SRP n’était toujours pas publiée[4] — un point à surveiller de près dans les prochains jours.
Documenter votre inventaire de composants (SBOM) et vos canaux de veille CVE, pour pouvoir corréler une exploitation à un produit en quelques minutes.
Tester le scénario : simulez une exploitation active découverte un vendredi soir. Combien de temps pour produire l’early warning 24 h ?

Le point de vue LTT

Le CRA a mauvaise presse — paperasse, conformité, coûts. Mais regardez-le du bon côté : il force ce que toute équipe hardware sérieuse devrait déjà faire. Une cartographie propre de vos composants, une veille de sécurité active sur votre parc, un processus de réponse documenté : c’est de l’ingénierie de base, pas de la bureaucratie.

La vraie question n’est pas « serons-nous contrôlés le 12 septembre ? ». C’est : avez-vous la capacité de savoir, en moins de 24 h, si une faille de votre produit est activement exploitée — et de le déclarer proprement si c’est le cas ?

Vous concevez ou industrialisez des produits connectés pour le marché européen ? Votre processus de signalement CRA est-il opérationnel pour le 11 septembre — ou est-ce encore une ligne de votre roadmap ?

Et vous, où en êtes-vous sur le CRA ? Entreprises prêtes, équipes qui découvrent l’article 14, ou sceptiques qui pensent que ça ne sera jamais appliqué ? Contacter nous pour préparer cette échéance.