L'Article 13(8) du Règlement sur la cyberrésilience de l'UE (Règlement (UE) 2024/2847) impose aux fabricants de fournir des mises à jour de sécurité gratuitement et sans retard injustifié pendant toute la période d'assistance. Cette page traite des mécanismes de distribution des mises à jour pour les architectures embarquées, autonomes, SaaS et hybrides. Pour les mécanismes de durée, consultez la période d'assistance CRA ; pour la communication pré-achat, consultez la divulgation de fin d'assistance.
Synthèse
- Les mises à jour de sécurité ne sont pas des mises à jour fonctionnelles. Un changement qui corrige une vulnérabilité est soumis aux règles de coût et de cadence de l'Article 13(8) ; un changement qui ajoute une nouvelle fonctionnalité ne l'est pas.
- Gratuité en vertu de l'Article 13(8). Les fabricants ne peuvent pas regrouper les correctifs de sécurité dans des abonnements payants, des niveaux premium ou des mises à niveau de version majeure.
- Automatique lorsque c'est possible, en vertu de l'Annexe I Partie II. Le point 7) exige des mécanismes de distribution sécurisés avec livraison automatique lorsque c'est applicable ; le point 8) exige la diffusion sans délai.
- « Sans retard injustifié » varie selon la gravité. Les attentes du secteur sont : quelques jours pour les problèmes critiques activement exploités, 30 jours pour les vulnérabilités de gravité élevée, 90 jours pour les vulnérabilités moyennes, et le prochain cycle régulier pour les faibles.
- L'architecture détermine le modèle de distribution. Les micrologiciels embarqués, les logiciels autonomes, les SaaS et les produits hybrides ont chacun des mécanismes de mise à jour distincts que le dossier technique doit documenter.
- L'Article 14 sur le signalement interagit avec le cycle de vie des mises à jour. Lorsqu'une vulnérabilité activement exploitée est détectée, l'alerte précoce ENISA de 24 heures se déroule en parallèle du processus de correction ; le mécanisme de mise à jour doit être connecté au flux de signalement.
Les quatre piliers de la conformité CRA en matière de mises à jour de sécurité : la règle de gratuité, la préférence de distribution, l'attente de cadence et le plafond des sanctions.
Facturer les mises à jour de sécurité constitue l'une des voies les plus directes vers un constat de non-conformité. Si un correctif qui traite une vulnérabilité n'est accessible qu'aux clients disposant d'un niveau d'assistance payant, d'un abonnement premium, ou intégré dans une mise à niveau de version majeure facturée comme une nouvelle version, cet arrangement ne satisfait pas à l'Article 13(8). Les correctifs de sécurité de base doivent être disponibles pour tous les utilisateurs du produit tel que mis sur le marché, sans coût supplémentaire, pendant toute la durée de la période d'assistance. Les versions fonctionnelles, les services professionnels et les fonctionnalités optionnelles peuvent toujours être facturés. La ligne de démarcation est de savoir si le changement traite une vulnérabilité.
Ce qui constitue une mise à jour de sécurité
L'Article 13(2) du Règlement sur la cyberrésilience exige des fabricants qu'ils conçoivent et produisent des produits « sécurisés par défaut » garantissant « la confidentialité, l'intégrité et la disponibilité des données ». L'Article 13(8) exige ensuite que les vulnérabilités découvertes après la mise sur le marché soient traitées pendant toute la durée de la période d'assistance.
Une mise à jour de sécurité au sens du CRA est un changement qui traite une vulnérabilité, c'est-à-dire une faiblesse du produit susceptible d'être exploitée pour compromettre la confidentialité, l'intégrité ou la disponibilité. La distinction avec une mise à jour fonctionnelle est importante pour deux raisons : les mises à jour de sécurité doivent être gratuites et doivent être fournies sans retard injustifié, alors que les mises à jour fonctionnelles ne sont soumises à aucune de ces obligations.
| Type de mise à jour | Obligation au titre de l'Article 13(8) | Peut être facturée ? |
|---|---|---|
| Correctif traitant un CVE connu | Oui (mise à jour de sécurité) | Non |
| Renforcement réduisant la surface d'attaque | Oui (mise à jour de sécurité) | Non |
| Nouvelle fonctionnalité sans rapport avec la sécurité | Non | Oui |
| Version majeure avec nouvelles fonctionnalités | Non (sauf si elle inclut des correctifs de sécurité) | Oui |
| Mise à jour de dépendance pour éliminer une vulnérabilité connue | Oui (mise à jour de sécurité) | Non |
| Changement de configuration pour combler une faille de sécurité | Oui (mise à jour de sécurité) | Non |
« Sans retard injustifié » n'est pas défini numériquement dans le règlement, mais l'attente générale des autorités de surveillance du marché et des orientations de l'ENISA s'aligne sur la pratique du secteur. Le diagramme ci-dessous illustre la fenêtre de correction par niveau de gravité, mesurée à partir du moment où la vulnérabilité est divulguée (T0) :
| Gravité | Attente normative du secteur |
|---|---|
| Critique (activement exploitée) | Quelques jours, pas des semaines |
| Élevée (facilement exploitable à distance) | Sous 30 jours |
| Moyenne | Sous 90 jours |
| Faible | Incluse dans le prochain cycle de mise à jour régulier |
Ces délais ne sont pas imposés par le CRA, mais constituent le standard à l'aune duquel « sans retard injustifié » sera évalué lors des procédures de mise en conformité.
Comment distribuer les mises à jour de sécurité CRA
Mises à jour automatiques
Lorsque c'est techniquement faisable et approprié, l'Article 13(8) et l'Annexe I Partie II favorisent les mises à jour de sécurité automatiques. Le produit doit être en mesure de recevoir et d'appliquer des mises à jour sans que l'utilisateur ait à prendre une action manuelle.
Exigences pour un mécanisme de mise à jour automatique conforme :
- Canal de téléchargement sécurisé (TLS, paquets signés)
- Vérification de l'intégrité avant l'installation
- Capacité de retour arrière en cas d'échec d'une mise à jour
- Gestion gracieuse des problèmes de connectivité
- Visibilité de l'utilisateur sur le statut de la mise à jour
L'utilisateur doit conserver la possibilité de refuser les mises à jour automatiques, avec un avertissement clair sur les conséquences pour la sécurité. Pour les mises à jour de sécurité critiques, le fabricant peut concevoir le système pour appliquer la mise à jour sans possibilité de report. L'Article 13(8) autorise cette approche lorsque le risque le justifie.
Mises à jour manuelles
Les produits ne pouvant pas recevoir de mises à jour automatiques (systèmes industriels isolés du réseau, appareils embarqués sans connectivité, certains équipements médicaux ou à sécurité critique) nécessitent un processus de distribution manuel des mises à jour :
- Paquets de mise à jour téléchargeables avec un versionnage clair
- Signatures cryptographiques et clés publiques publiées pour la vérification
- Documentation d'installation
- Notification via tous les canaux disponibles (e-mail, portail web, interface produit, avis physique si nécessaire)
Embarqué et SaaS : des modèles de mise à jour différents
Le mécanisme de distribution des mises à jour varie sensiblement selon l'architecture du produit :
| Type de produit | Modèle de mise à jour | Considération CRA clé |
|---|---|---|
| Micrologiciel embarqué (IoT, industriel) | Le fabricant pousse le micrologiciel signé ; le client l'applique | Doit disposer d'une capacité OTA ou d'un processus manuel documenté ; les longues durées de vie des appareils peuvent rapprocher la période d'utilisation prévue de cinq ans |
| Logiciel autonome (bureau, serveur) | Le fabricant publie le paquet ; le client l'installe | Agent de mise à jour automatique préféré ; le verrouillage de version par les clients entreprise crée une charge d'assistance multi-version |
| SaaS / hébergé dans le cloud | Le fabricant contrôle l'environnement ; les mises à jour sont transparentes pour l'utilisateur | L'horloge démarre toujours à la mise sur le marché ; la période d'assistance concerne principalement les composants sur site ou hybrides ; le versionnage des API crée ses propres engagements d'assistance |
| Hybride (agent sur site + backend cloud) | Les mises à jour de l'agent sont contrôlées par le fabricant ; les mises à jour du backend sont transparentes | Chaque composant a sa propre horloge de période d'assistance ; l'agent est le produit comportant des éléments numériques et c'est son horloge qui fait foi |
Pour la gestion des vulnérabilités au sens large de l'Annexe I Partie II au-delà de la distribution des mises à jour (politique de divulgation coordonnée, divulgation publique, signalement par des tiers), consultez le guide de gestion des vulnérabilités.
Obligations de signalement des vulnérabilités pendant et après la période d'assistance
L'Article 14 impose aux fabricants des obligations de signalement avec délais contraints pour les vulnérabilités activement exploitées et les incidents graves. Ces obligations s'appliquent pendant la période d'assistance.
L'interaction clé :
| Phase | Obligation de signalement au titre de l'Article 14 |
|---|---|
| Pendant la période d'assistance | L'Article 14 s'applique pleinement : alerte précoce de 24h, notification de 72h, rapport final de 14 jours pour les vulnérabilités activement exploitées ; 24h / 72h / 1 mois pour les incidents graves. Via la plateforme de signalement unique de l'ENISA. |
| Après la fin de la période d'assistance | Aucune obligation de signalement au titre de l'Article 14 pour les vulnérabilités découvertes après la fin de vie. Si le fabricant prend connaissance d'une vulnérabilité critique activement exploitée dans un produit non assisté affectant un large parc installé, il n'y a pas de signalement obligatoire. La divulgation responsable et la notification aux utilisateurs sont fortement recommandées pour des raisons de réputation et de coopération avec la surveillance du marché. |
La date de fin de la période d'assistance constitue donc également l'horizon de l'Article 14. Une fois la période d'assistance expirée, le fabricant n'a plus l'obligation d'investiguer, de corriger ou de signaler les vulnérabilités découvertes dans cette version du produit. Les autorités de surveillance du marché peuvent toujours enquêter au titre de l'Article 58 si le produit présente un risque cybersécurité significatif, mais l'obligation permanente de gestion des vulnérabilités prévue à l'Article 13(8) a pris fin.
Pour l'ensemble des mécanismes de délais de l'Article 14, notamment le contenu de chaque rapport et la différence entre les deux flux de signalement (vulnérabilités activement exploitées et incidents graves), consultez le guide de signalement des vulnérabilités.
Erreurs courantes
Ignorer les dépendances transitives. La plupart des vulnérabilités dans les produits connectés proviennent de bibliothèques et composants tiers, et non du code du fabricant. L'obligation de l'Article 13(8) couvre l'ensemble du produit, pas seulement le code écrit par le fabricant. Un SBOM est le prérequis. Consultez le guide de la grappe SBOM pour le dispositif de suivi des dépendances qui rend opérationnelle la surveillance des vulnérabilités transitives.
Facturer les mises à jour de sécurité. Regrouper les correctifs de sécurité dans un niveau d'assistance payant viole l'Article 13(8). Les correctifs de sécurité de base doivent être gratuits.
Foire aux questions
Les mises à jour de sécurité doivent-elles toujours être gratuites ?
Oui. L'Article 13(8) exige que les mises à jour de sécurité soient fournies gratuitement. Un fabricant ne peut pas regrouper un correctif de sécurité dans un abonnement payant, un niveau d'assistance premium ou une mise à niveau de version majeure et prétendre respecter l'Article 13(8). Les mises à jour fonctionnelles, les nouvelles fonctionnalités et les services professionnels payants sont distincts et peuvent être facturés normalement. L'obligation se limite aux mises à jour qui traitent des vulnérabilités : les changements qui corrigent une faiblesse de sécurité dans le produit tel que mis sur le marché.
Dans quel délai un fabricant doit-il publier une mise à jour de sécurité au titre du CRA ?
L'Article 13(8) du CRA exige que les mises à jour de sécurité soient fournies « sans retard injustifié », mais ne définit pas numériquement un délai. Les autorités de surveillance du marché et les orientations de l'ENISA s'alignent sur la pratique du secteur en fonction de la gravité : les vulnérabilités critiques activement exploitées doivent être corrigées en quelques jours, les vulnérabilités de gravité élevée sous environ 30 jours, les vulnérabilités moyennes sous 90 jours, et les faibles regroupées dans le prochain cycle de mise à jour régulier. Ces délais ne sont pas imposés par le CRA, mais constituent le standard à l'aune duquel « sans retard injustifié » sera évalué lors des procédures de mise en conformité. Les fabricants devraient suivre le temps réel de correction par CVE afin que les écarts par rapport à cette base soient visibles et défendables.
Les mises à jour automatiques sont-elles exigées par le CRA ?
Pas dans tous les cas. L'Annexe I Partie II point 7) exige des fabricants qu'ils mettent en place des mécanismes de distribution sécurisés avec livraison automatique « lorsque c'est applicable ». Pour les produits disposant d'une connectivité fiable et sans raison opérationnelle de différer, les mises à jour automatiques constituent le comportement par défaut attendu. Pour les systèmes industriels isolés du réseau, certains dispositifs médicaux ou les équipements à sécurité critique où l'installation automatique d'un correctif pourrait perturber les opérations, un processus de mise à jour manuel documenté est acceptable. Le dossier technique de l'Annexe VII doit justifier l'approche choisie. Les utilisateurs doivent conserver la possibilité de refuser les mises à jour automatiques avec des avertissements clairs sur les conséquences pour la sécurité, sauf lorsque le risque justifie un correctif critique non différable.
Un produit SaaS a-t-il une période d'assistance CRA ?
Cela dépend de si le produit SaaS entre dans le champ d'application du CRA en tant que produit comportant des éléments numériques. Les services SaaS purs, non associés à un composant matériel ou à un agent logiciel téléchargeable, sont généralement hors du champ d'application au titre de l'Article 2(1). Lorsqu'un produit SaaS comprend un agent sur site, un client téléchargeable ou une passerelle matérielle mis sur le marché de l'UE, ce composant est dans le champ d'application et son horloge de période d'assistance au titre de l'Article 13(8) démarre à la mise sur le marché. Le backend hébergé dans le cloud, lorsqu'il est sous le contrôle du fabricant et continuellement mis à jour, satisfait généralement à l'obligation de correction « sans retard injustifié » par déploiement transparent, mais le fabricant doit tout de même documenter l'engagement d'assistance dans les informations de l'Annexe II pour le composant dans le champ d'application.
Que se passe-t-il pour les mises à jour de sécurité après la fin de la période d'assistance CRA ?
Les obligations de l'Article 13(8) prennent fin avec la période d'assistance. Une fois la date de fin divulguée passée, le fabricant n'a plus d'obligation CRA d'investiguer, de corriger ou de distribuer des mises à jour de sécurité pour cette version du produit, et les obligations de signalement au titre de l'Article 14 expirent également car elles ne s'appliquent que pendant la période d'assistance. Les autorités de surveillance du marché peuvent toujours enquêter au titre de l'Article 58 si le produit présente un risque cybersécurité significatif après la fin de vie, mais l'obligation quotidienne de gestion des vulnérabilités a pris fin. Les fabricants devraient communiquer clairement la fin d'assistance aux utilisateurs à l'avance ; la divulgation de la date de fin au titre de l'Annexe II point k) est l'instrument tourné vers l'utilisateur à cet effet. Continuer à fournir des correctifs de bonne volonté après la fin de vie est autorisé mais pas obligatoire.