- Les obligations de signalement des vulnérabilités et incidents du Cyber Resilience Act (règlement UE 2024/2847), prévues à l'article 14, s'appliquent à compter du 11 septembre 2026 .
- Cette exigence s'applique aux produits déjà sur le marché. Les fabricants doivent signaler les vulnérabilités activement exploitées sous 24 heures à l'ENISA et au CSIRT national.
- Les PME éditrices doivent établir un contact de sécurité, un circuit de tri et une nomenclature logicielle (SBOM) avant cette échéance.
Le CRA en bref : Le Cyber Resilience Act (règlement UE 2024/2847) fixe les exigences de cybersécurité applicables aux produits comportant des éléments numériques mis sur le marché de l'Union, y compris les logiciels. Les obligations de signalement des vulnérabilités et incidents prévues à l'article 14 s'appliquent à compter du 11 septembre 2026 . L'ensemble des exigences produit s'applique à compter du 11 décembre 2027 .
Points clés
- Périmètre des règles obligatoires au 11 septembre 2026
- La cascade de signalement en trois temps : 24 heures, 72 heures, 14 jours
- Application aux produits déjà sur le marché , y compris les versions existantes
- Nécessité d'une nomenclature logicielle (SBOM) avant le mandat de 2027
- Règles applicables à l'open source et limites de l'activité commerciale
L'échéance qui arrive avant le règlement
Les équipes classent souvent le Cyber Resilience Act parmi les échéances de 2027. La documentation technique, le marquage CE, l'évaluation de conformité et les exigences essentielles de cybersécurité prennent effet le 11 décembre 2027.
L'article 14 s'applique plus tôt. À compter du 11 septembre 2026 , les fabricants de produits comportant des éléments numériques doivent signaler les vulnérabilités activement exploitées et les incidents de sécurité graves à l'ENISA et à leur CSIRT national.
Deux facteurs créent l'urgence :
Premièrement, l'obligation vise les produits déjà sur le marché. Le texte ne prévoit aucun régime d'antériorité. Si des clients utilisent votre logiciel dans l'UE le 11 septembre 2026 et qu'une vulnérabilité activement exploitée survient, l'obligation de signalement s'applique quelle que soit la date de livraison initiale.
Deuxièmement, le délai s'élève à 24 heures. Les équipes ne peuvent pas concevoir un processus de divulgation de vulnérabilités après la réception d'une alerte d'exploitation. L'organisation opérationnelle doit exister avant le 10 septembre.
Pour les PME du logiciel, le 11 septembre constitue un jalons de préparation opérationnelle avec une date fixe.
Exigences de l'article 14
Deux événements déclenchent le signalement : les vulnérabilités activement exploitées dans votre produit et les incidents graves affectant la sécurité du produit.
Gérez les constatations issues de vos propres tests via votre gestion de vulnérabilités habituelle. Signalez les vulnérabilités faisant l'objet d'une exploitation active contre vos utilisateurs.
La cascade de signalement
| Étape | Délai | Destinataire | Contenu |
|---|---|---|---|
| Alerte précoce | Sous 24 heures après prise de connaissance | ENISA et CSIRT national via la plateforme unique de signalement | Existence d'une vulnérabilité activement exploitée ou d'un incident grave ; États membres concernés si connus |
| Notification | Sous 72 heures après prise de connaissance | ENISA et CSIRT national | Informations sur le produit, nature de l'exploitation, mesures correctives ou d'atténuation prises |
| Rapport final | Sous 14 jours après disponibilité d'une mesure corrective (vulnérabilités) ; sous 1 mois (incidents graves) | ENISA et CSIRT national | Description de la vulnérabilité, gravité, impact, détails d'exploitation connus, mesures correctives |
La prise de connaissance déclenche le délai, non la confirmation. Si un chercheur écrit à votre adresse de sécurité le vendredi à 14 h avec des détails d'exploitation active, le délai de 24 heures débute le vendredi à 14 h.
Obligations pour le 11 septembre 2026
- Un contact de sécurité surveillé. Publiez une adresse de sécurité dédiée pour la réception des signalements plutôt qu'une file de support générique.
- Un circuit de tri défini. Désignez des membres de l'équipe pour évaluer les signalements en quelques heures et escalader les exploitations actives.
- Un inventaire produit. Maintenez une liste définitive des produits supportés, des versions déployées et des forks maintenus.
- Un accès à la plateforme de signalement. L'ENISA opère la plateforme unique pour les notifications CRA. Enregistrez-vous et vérifiez vos accès au préalable.
- Une nomenclature logicielle (SBOM). Maintenez un inventaire à jour des composants logiciels tiers.
Pourquoi une SBOM dès 2026, et non en 2027
Les obligations légales de SBOM font partie de la documentation technique applicable en décembre 2027. Reporter la mise en place de la SBOM à 2027 ne tient pas face aux exigences de septembre 2026.
Lorsqu'une vulnérabilité activement exploitée touche une dépendance courante, votre équipe doit déterminer sous 24 heures si votre produit intègre le composant affecté. Les audits manuels du code source sur l'ensemble des versions livrées ne s'exécutent pas en 24 heures.
Une SBOM à jour offre la visibilité nécessaire pour respecter le délai de 24 heures.
Minimum pratique pour une PME du logiciel :
- Générez une SBOM par version au format SPDX ou CycloneDX au sein de votre pipeline de build
- Conservez les SBOM de chaque version encore supportée ou déployée chez vos clients
- Connectez la SBOM aux flux de vulnérabilités pour rapprocher les nouvelles CVE de votre graphe de dépendances
- Intégrez les dépendances transitives où se concentrent les risques logiciels tiers
Les outils de build génèrent des SBOM sans frais de licence logicielle. L'intégration nécessite quelques jours de travail ingénieur avant l'échéance de septembre.
Le problème des dépendances en fin de vie
Les dépendances en fin de vie ne reçoivent plus de correctifs amont. Si une exploitation vise un composant non maintenu dans votre logiciel, l'article 14 exige toujours un avertissement sous 24 heures et un rapport final détaillant la remédiation. L'absence de maintenance amont ne constitue pas une mesure corrective validée.
Auditez votre arbre de dépendances pour repérer les paquets arrivés en fin de vie. Les options incluent la mise à jour, le remplacement du composant, la souscription d'un support étendu ou le maintien d'un fork privé. Chaque option demande plus de 24 heures de réalisation.
Qui est concerné
Le CRA s'applique aux fabricants de produits comportant des éléments numériques mis sur le marché de l'Union. La qualité de fabricant désigne toute entité qui développe un logiciel ou le fait développer pour le commercialiser sous sa marque.
| Profil | Concerné ? | Précisions |
|---|---|---|
| Éditeur de logiciel commercial (UE) | ✅ Oui | Cœur du champ |
| Fournisseur SaaS | ⚠️ Partiel | Le SaaS pur relève de NIS2 plutôt que du CRA ; les logiciels distribués pour exécution chez le client relèvent du CRA. Évaluez par produit. |
| Fabricant de matériel / IoT | ✅ Oui | Cœur du champ |
| Développeur de firmware | ✅ Oui | Cœur du champ |
| Éditeur non européen vendant dans l'UE | ✅ Oui | S'applique aux produits mis sur le marché européen ; les règles d'importateur et de mandataire s'appliquent |
| Développeur open source non commercial | ❌ Non | Exclu du périmètre |
| Intendant open source / OSS commercial | ⚠️ Partiel | Des règles allégées s'appliquent aux intendants ; les obligations complètes s'appliquent en cas de commercialisation |
| Entreprise utilisant un logiciel en interne | ❌ Non | Non qualifié de fabricant |
PME du logiciel hors UE : Le CRA s'applique selon la mise sur le marché. Un logiciel proposé aux clients européens entre dans le périmètre quelle que soit la localisation du siège social. Les éditeurs non européens devront désigner un importateur ou un mandataire établi dans l'UE pour décembre 2027.
La position de l'open source
Le CRA exclut les logiciels open source développés et fournis en dehors d'une activité commerciale.
L'assujettissement dépend de l'activité commerciale et non de la licence open source. Les indicateurs d'activité commerciale incluent :
- La facturation du logiciel, du support ou des versions hébergées
- La commercialisation d'éditions entreprise payantes aux côtés d'offres gratuites
- La distribution de composants logiciels au sein de produits commerciaux
- L'emploi de développeurs pour maintenir des logiciels aux fins commerciales de l'entreprise
Le texte crée le statut d' intendant de logiciel open source pour les fondations soutenant le développement open source sans commercialisation directe. Les intendants suivent des règles adaptées axées sur les politiques de sécurité et la coopération réglementaire.
Les fabricants de produits commerciaux assument la responsabilité des composants open source intégrés. Les mainteneurs amont ne portent pas la responsabilité du fabricant. Pour les logiciels utilisant des modèles d'IA, consultez notre guide sur les outils de conformité à l'AI Act .
Classes de risque et voies de conformité
Le CRA classe les produits par niveau de risque pour définir les procédures d'évaluation de conformité de décembre 2027. Les obligations de signalement du 11 septembre 2026 s'appliquent de manière uniforme à toutes les classes.
| Classe | Exemples | Voie de conformité |
|---|---|---|
| Défaut (majorité des produits) | Logiciels professionnels, applications grand public, IoT généraliste | Auto-évaluation |
| Important classe I | Navigateurs, gestionnaires de mots de passe, VPN, gestion de réseau, domotique de sécurité | Auto-évaluation sur normes harmonisées, ou évaluation tierce |
| Important classe II | Systèmes d'exploitation, pare-feu, contrôle industriel, microprocesseurs | Évaluation de conformité par tierce partie obligatoire |
| Critique | Modules matériels de sécurité, cartes à puce, éléments sécurisés | Schéma européen de certification de cybersécurité |
La plupart des PME du logiciel relèvent de la classe par défaut et peuvent auto-évaluer leur conformité. Les éditeurs d'outils liés à la sécurité, comme la gestion d'identités ou la protection réseau, doivent vérifier les critères des classes I et II afin d'anticiper les coûts d'audit externe.
Sanctions
| Manquement | Sanction maximale |
|---|---|
| Exigences essentielles de cybersécurité ou obligations du fabricant | 15 M€ ou 2,5 % du chiffre d'affaires mondial annuel, le montant le plus élevé étant retenu |
| Autres obligations réglementaires | 10 M€ ou 2 % du chiffre d'affaires mondial annuel |
| Fourniture d'informations inexactes, incomplètes ou trompeuses aux autorités | 5 M€ ou 1 % du chiffre d'affaires mondial annuel |
Transmettre des signalements inexacts sous la pression crée des risques réglementaires au même titre qu'un retard. Mettez en place des processus opérationnels garantissant des notifications rapides et fiables.
Éditeurs des pays candidats à l'adhésion
Balkans occidentaux, Ukraine, Moldavie, Géorgie : Les pays candidats alignent leurs cadres de cybersécurité sous les chapitres d'adhésion 10 (Société de l'information et médias) et 1 (Libre circulation des marchandises).
Alignement actuel : Aucun pays candidat n'a transposé le CRA, bien que plusieurs consultent sur des cadres de cybersécurité alignés sur NIS2.
Obligation immédiate : Le CRA s'applique dès la mise d'un produit sur le marché européen. Les éditeurs situés à Belgrade, Podgorica, Kyiv ou Tirana distribuant des logiciels à des clients européens doivent respecter les règles de signalement du 11 septembre 2026 dans les mêmes conditions que les entreprises de l'UE.
Impact opérationnel : Les éditeurs exportateurs régionaux doivent déployer les mêmes flux de signalement d'incidents que les vendeurs européens. Mettre en place les pratiques SBOM et de tri des vulnérabilités dès maintenant évite les ajustements d'urgence pendant les incidents. Consultez les orientations de l' ENISA ou d'autorités nationales comme l' ANSSI .
Plan d'action sous 6 semaines
- Confirmez votre statut par écrit. Documentez si votre entreprise entre dans la catégorie des fabricants mettant des produits numériques sur le marché de l'UE.
-
Publiez un contact de sécurité et une politique de divulgation.
Déployez un fichier
security.txtet surveillez l'adresse indiquée. - Définissez le circuit de tri et d'escalade. Nommez des personnes responsables de l'évaluation des alertes et de l'autorisation des notifications réglementaires.
- Générez des SBOM pour les versions supportées. Automatisez la création au format SPDX ou CycloneDX dans votre pipeline.
- Connectez vos SBOM à des flux de vulnérabilités. Surveillez les graphes de dépendances en continu face aux nouvelles CVE.
- Auditez les dépendances en fin de vie. Choisissez des stratégies de remplacement ou de maintien pour les composants non suivis.
- Enregistrez-vous sur la plateforme ENISA. Validez les accès utilisateur avant la survenance d'un incident réel.
- Réalisez un exercice de simulation. Testez la réactivité de l'équipe face au délai d'alerte précoce de 24 heures.
Questions fréquentes
Quelles règles du CRA s'appliquent le 11 septembre 2026 ?
L'obligation de septembre 2026 vise-t-elle les logiciels déjà sur le marché ?
Ai-je besoin d'une SBOM d'ici septembre 2026 ?
Le Cyber Resilience Act s'applique-t-il aux logiciels open source ?
Le CRA s'applique-t-il aux éditeurs de logiciels établis hors de l'Union européenne ?
Cet article est fourni à titre informatif uniquement et ne constitue pas un conseil juridique. Pour un conseil adapté à votre situation, consultez un professionnel juridique qualifié.
Themio.ai cartographie vos obligations au titre du Cyber Resilience Act par produit et par classe de risque, et identifie ce qui doit être en place avant le 11 septembre 2026 (en moins de 2 minutes), chaque constat étant traçable jusqu'à l'article dont il découle. Découvrez comment →