Le Règlement sur la cyberrésilience de l'UE (Règlement (UE) 2024/2847) impose aux fabricants de traiter les vulnérabilités pendant la période de support et, lorsque des mises à jour de sécurité sont disponibles, de les diffuser sans délai et gratuitement. 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 de support CRA ; pour la communication pré-achat, consultez la divulgation de fin de support.
Synthèse
- Les mises à jour de sécurité ne sont pas des mises à jour fonctionnelles. Une modification qui corrige une vulnérabilité suit les obligations de mise à jour de sécurité ; une nouvelle capacité ne les déclenche pas.
- Les correctifs de sécurité ne doivent pas être réservés aux offres payantes. Les mises à jour de sécurité disponibles doivent être diffusées sans délai et gratuitement, avec des messages d'avis aux utilisateurs indiquant ce que la mise à jour corrige et les actions à prendre, sauf accord différent pour des produits sur mesure destinés à des utilisateurs professionnels.
- Automatiques lorsque c'est applicable. Les mises à jour automatiques de sécurité sont le modèle par défaut lorsqu’il est pertinent, avec des mécanismes de distribution sécurisés et des contrôles utilisateur clairs.
- Les objectifs de correction doivent suivre la gravité. Les objectifs opérationnels usuels sont quelques jours pour les vulnérabilités critiques activement exploitées, 30 jours pour une gravité élevée, 90 jours pour une gravité moyenne et le prochain cycle régulier pour une gravité faible.
- L'architecture change le modèle de distribution. Firmware embarqué, logiciel autonome, SaaS et produits hybrides ont chacun des mécanismes de mise à jour distincts que la documentation technique doit décrire.
- Le signalement interagit avec le cycle de mise à jour. Lorsqu'une vulnérabilité activement exploitée est détectée, l'alerte précoce de 24 h au CSIRT coordinateur et à l'ENISA court en parallèle du processus de correction ; le mécanisme de mise à jour doit alimenter le flux de signalement.
Les quatre repères de la conformité des mises à jour de sécurité CRA : règle de coût, préférence de distribution, disponibilité des mises à jour et modèle de sanctions.
Pour les niveaux de sanction, consultez le guide sanctions et enforcement.
Ce qui constitue une mise à jour de sécurité
L’obligation de mise à jour part de l’évaluation des risques de cybersécurité du produit et des propriétés de sécurité applicables. La configuration sécurisée par défaut, la confidentialité, l’intégrité et la disponibilité déterminent si une modification relève de la sécurité. Le fabricant doit ensuite gérer efficacement les vulnérabilités pendant la période d’assistance.
Une mise à jour de sécurité est un changement qui corrige une vulnérabilité, c'est-à-dire une faiblesse du produit exploitable pour compromettre la confidentialité, l'intégrité ou la disponibilité. La distinguer d'une mise à jour fonctionnelle compte pour deux raisons : les mises à jour de sécurité disponibles doivent être gratuites et diffusées sans délai ; les mises à jour fonctionnelles ne portent pas ces obligations.
| Type de mise à jour | Obligation de mise à jour de sécurité | Peut être facturée ? |
|---|---|---|
| Correctif d'un CVE connu | Oui (mise à jour de sécurité) | Non |
| Durcissement qui réduit la surface d'attaque | Oui (mise à jour de sécurité) | Non |
| Nouvelle fonctionnalité sans portée sécurité | Non | Oui |
| Version majeure avec nouvelles capacités | Non (sauf si elle inclut des correctifs de sécurité) | Oui |
| Mise à jour de dépendance qui élimine une vulnérabilité connue | Oui (mise à jour de sécurité) | Non |
| Changement de configuration qui ferme une faille | Oui (mise à jour de sécurité) | Non |
Sans délai n'est pas défini par un nombre de jours dans le Règlement. Les fabricants doivent tout de même fixer des objectifs opérationnels par gravité pour que les décisions de correction soient cohérentes, documentées et explicables. Le schéma ci-dessous montre une fenêtre pratique de correction par niveau de gravité, mesurée à partir du moment où le fabricant a connaissance de la vulnérabilité :
| Gravité | Objectif opérationnel pratique |
|---|---|
| Critique (activement exploitée) | Jours, pas semaines |
| Élevée (facilement exploitable à distance) | Sous 30 jours |
| Moyenne | Sous 90 jours |
| Faible | Incluse dans le prochain cycle régulier |
Ce ne sont pas des délais imposés par le CRA. Ce sont des objectifs internes qui aident le fabricant à démontrer que le délai était maîtrisé, fondé sur le risque et documenté.
Comment distribuer les mises à jour de sécurité CRA
Mises à jour automatiques
Lorsque c’est techniquement possible et approprié, les mises à jour automatiques de sécurité sont le modèle privilégié. Un modèle automatique conforme doit activer les mises à jour de sécurité par défaut, offrir un mécanisme de désactivation clair, notifier les mises à jour disponibles, permettre un report temporaire lorsque c’est approprié et distribuer les mises à jour de manière sécurisée.
Un mécanisme de mise à jour automatique robuste devrait fournir :
- Canal de téléchargement sécurisé (TLS, paquets signés)
- Vérification d'intégrité avant installation
- Possibilité de retour arrière si la mise à jour échoue
- Gestion correcte des problèmes de connectivité
- Visibilité pour l'utilisateur sur l'état de mise à jour
L'utilisateur doit conserver la possibilité de désactiver les mises à jour automatiques, avec un avertissement clair sur les conséquences de sécurité. Pour les mises à jour critiques, le fabricant doit documenter tout choix non reportable dans l'évaluation des risques et la documentation technique.
Mises à jour manuelles
Les produits qui ne peuvent pas recevoir de mises à jour automatiques (systèmes industriels isolés, équipements embarqués sans connectivité, certains dispositifs médicaux ou équipements critiques de sûreté) nécessitent un processus manuel :
- Paquets téléchargeables avec versionnement clair
- Signatures cryptographiques et clés publiques publiées pour vérification
- Documentation d'installation
- Notification par 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 diffère fortement selon l'architecture du produit :
| Type de produit | Modèle de mise à jour | Point CRA clé |
|---|---|---|
| Firmware embarqué (IoT, industriel) | Le fabricant pousse un firmware signé ; le client l'applique | OTA ou processus manuel documenté ; les longues durées d'utilisation peuvent exiger un support supérieur à cinq ans |
| Logiciel autonome (poste, serveur) | Le fabricant publie un paquet ; le client l'installe | Agent de mise à jour automatique préférable ; le gel de versions en entreprise crée une charge de support multiversion |
| SaaS / cloud | Le fabricant contrôle l'environnement ; les mises à jour sont transparentes | Vérifier d'abord si le service est dans le champ comme produit comportant des éléments numériques ou solution de traitement de données à distance |
| Hybride (agent sur site + backend cloud) | Les mises à jour d'agent sont contrôlées par le fabricant ; le backend est mis à jour de façon transparente | Chaque composant a sa propre horloge de support ; l'agent est le produit comportant des éléments numériques qui pilote cette horloge |
Pour le traitement des vulnérabilités au-delà de la distribution des mises à jour (politique CVD, divulgation publique, signalement tiers), consultez le guide de traitement des vulnérabilités.
Obligations de signalement pendant la distribution des mises à jour
Le signalement CRA impose des obligations à délai pour les vulnérabilités activement exploitées et les incidents graves affectant la sécurité du produit. Le processus de mise à jour doit collecter les faits nécessaires à ces signalements, car le rapport final doit inclure les détails de la mise à jour de sécurité ou des autres mesures correctives disponibles.
L'interaction est opérationnelle :
| Déclencheur | Devoir dans le flux de mise à jour |
|---|---|
| Vulnérabilité activement exploitée | Capturer l'heure de connaissance, les produits affectés, les faits d'exploitation, l'état d'atténuation et les détails de mise à jour pour la séquence 24 h, 72 h et rapport final. |
| Incident grave | Capturer l'impact, la cause illicite ou malveillante présumée, l'évaluation initiale, les mesures d'atténuation et les actions correctives côté utilisateurs. |
| Information des utilisateurs | Préparer des instructions claires d'atténuation et de correction pour les utilisateurs touchés et, le cas échéant, tous les utilisateurs. |
Ne traitez pas le signalement comme une tâche séparée en aval. Les informations issues du support, du PSIRT, de la télémétrie, du service client ou du déploiement doivent atteindre rapidement le responsable du signalement lorsqu’un seuil déclaratif peut être atteint.
Pour la mécanique complète des délais, y compris le contenu de chaque signalement et la différence entre les deux flux, consultez le guide de signalement des vulnérabilités.
Disponibilité des mises à jour après publication
Mettre un correctif à disposition une seule fois ne suffit pas. Chaque mise à jour de sécurité mise à disposition des utilisateurs pendant la période de support doit rester disponible pendant au moins 10 ans après sa publication, ou pendant le reste de la période de support si celle-ci est plus longue. Cette règle change l'exploitation des releases : anciens paquets, avis, signatures, empreintes et instructions d'installation doivent disposer d'un hébergement durable et d'une traçabilité de version.
Les informations publiques destinées aux utilisateurs doivent aussi indiquer le type d’assistance technique de sécurité offert et la date de fin de la période d’assistance pendant laquelle ils peuvent attendre la gestion des vulnérabilités et la réception des mises à jour. Pour le modèle de divulgation préachat, consultez divulgation de fin d’assistance.
Erreurs courantes
Ignorer les dépendances transitives. La plupart des vulnérabilités dans les produits connectés viennent de bibliothèques et composants tiers, pas du code interne. L'obligation de traitement des vulnérabilités couvre tout le produit, composants compris. Le SBOM est le prérequis. Consultez le guide du cluster SBOM pour le cadre de suivi des dépendances.
Facturer les mises à jour de sécurité. Regrouper des correctifs de sécurité dans une offre de support payante entre en conflit avec le modèle de mise à jour CRA de base, sauf exception pour les produits professionnels sur mesure. 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, les mises à jour de sécurité disponibles doivent être gratuites, sauf exception étroite pour les produits professionnels sur mesure. Un fabricant ne peut pas placer un correctif de vulnérabilité dans un abonnement payant, un niveau premium ou une mise à niveau majeure payante et traiter cela comme une conformité CRA normale. Les mises à jour fonctionnelles, nouvelles fonctionnalités et services professionnels peuvent être facturés séparément. La ligne de partage tient au fait que le changement corrige ou non un problème de sécurité identifié dans le produit.
À quelle vitesse un fabricant doit-il publier une mise à jour de sécurité au titre du CRA ?
Le CRA ne fixe pas de délai de correction chiffré. Les fabricants ont donc besoin d'objectifs documentés par gravité. Les vulnérabilités critiques activement exploitées doivent être traitées en quelques jours, les gravités élevées autour de 30 jours, les moyennes autour de 90 jours et les faibles au prochain cycle régulier, sauf justification différente par l'évaluation des risques. Suivez le temps réel jusqu'au correctif par vulnérabilité pour que le délai reste visible, fondé sur le risque et explicable.
Le CRA exige-t-il des mises à jour automatiques ?
Pas dans tous les cas. Les mises à jour automatiques de sécurité sont exigées lorsqu'elles sont applicables, et le produit doit aussi notifier les mises à jour disponibles et permettre un report temporaire. Pour les produits grand public connectés de façon fiable, elles sont généralement le modèle attendu. Pour les systèmes industriels isolés, certains dispositifs médicaux ou équipements critiques de sûreté, un processus manuel documenté peut se justifier. La documentation technique doit expliquer l'approche retenue et les instructions utilisateur doivent expliquer comment désactiver l'installation automatique.
Un produit SaaS a-t-il une période de support CRA ?
Cela dépend du champ : service couvert comme produit comportant des éléments numériques ou comme solution de traitement de données à distance. Un SaaS pur et autonome, sans matériel, logiciel téléchargeable ni traitement distant sous responsabilité du fabricant, sort généralement de ce modèle de mise à jour. Si l'offre inclut un agent sur site, un client téléchargeable, une passerelle matérielle ou un traitement distant couvert, cartographiez la période de support et le mécanisme de mise à jour du composant concerné. Les informations utilisateur doivent toujours indiquer le type de support et la date de fin.
Que deviennent les mises à jour de sécurité après la fin de la période de support CRA ?
L'obligation ordinaire de traitement des vulnérabilités est liée à la période de support, mais les mises à jour déjà publiées doivent rester disponibles. Chaque mise à jour de sécurité fournie pendant cette période doit rester disponible au moins 10 ans après sa publication ou pendant le reste de la période de support si celle-ci est plus longue. Les fabricants doivent communiquer clairement la fin du support à l'avance et maintenir les instructions utilisateur disponibles pendant la période requise. Évitez d'affirmer que le signalement peut être ignoré après la fin du support sans analyse juridique au cas par cas.