Support sécurité des produits numériques : les obligations de mises à jour du CRA

Le Cyber Résilience Act (règlement (UE) 2024/2847) ne se limite pas a imposer un niveau de sécurité au moment de la mise sur le marché. L’une de ses dispositions les plus structurantes concerné le support sécurité des produits numériques après leur commercialisation : les fabricants sont désormais tenus de fournir des mises à jour de sécurité gratuites pendant toute la durée de vie attendue du produit, avec un minimum incompressible de cinq ans. Cette obligation transformé en profondeur la relation entre fabricant et utilisateur et impose de repenser intégralement les cycles de vie des produits.

La durée du support sécurité : un minimum de cinq ans

L’article 13(8) du CRA établit le principe fondamental : le fabricant doit assurer la gestion des vulnérabilités et fournir des mises à jour de sécurité pendant la durée de vie attendue du produit (“expected product lifetime”). Cette durée ne peut en aucun cas être inférieure à cinq ans à compter de la mise sur le marché du produit, sauf si la durée de vie attendue du produit est inférieure à cinq ans – auquel cas c’est cette durée plus courte qui s’applique.

Ce plancher de cinq ans constitue une rupture majeure. Jusqu’à présent, aucun texte européen n’imposait une durée minimale de support sécurité pour les produits numériques. De nombreux fabricants, en particulier dans le secteur de l’IoT, cessaient de fournir des correctifs de sécurité quelques mois après la commercialisation, laissant les utilisateurs exposés à des vulnérabilités connues sans aucun recours. Cette lacune est d’autant plus problématique que la directive NIS2 renforcé les exigences de sécurité pour les entités utilisant ces produits.

Le fabricant ne peut pas définir cette durée de manière arbitraire. Le CRA precise qu’elle doit refléter la durée pendant laquelle le produit est raisonnablement susceptible d’être utilise, en tenant compte des attentes raisonnables des utilisateurs, de la nature du produit et du droit de l’Union applicable. Un routeur industriel conçu pour être intègre dans une infrastructure critique sera logiquement soumis à une durée de support plus longue qu’une application mobile a faible enjeu.

Qu’est-ce que la “durée de vie attendue du produit” ?

La notion de durée de vie attendue mérite un examen attentif, car elle constitue le pivot de l’ensemble du dispositif. Le CRA retient une approche fondée sur plusieurs critères cumulatifs :

• Les attentes raisonnables des utilisateurs, compte tenu de la nature et de la finalité du produit. Un système de contrôle industriel ne suscité pas les mêmes attentes qu’un objet connecté grand public.
• La durée pendant laquelle le produit est raisonnablement susceptible d’être utilise, qui tient compte de la durabilité matérielle, de la fréquence de renouvellement dans le secteur concerné et des pratiques du marché.
• La législation de l’Union applicable, notamment en matière de durabilité et de garantie légale.

En pratique, cette définition fonctionnelle signifie que le fabricant ne peut pas raccourcir artificiellement la durée de vie attendue en déclarant un produit obsolète prematurement. Les autorités de surveillance du marché disposeront d’un pouvoir d’appréciation pour contester une durée manifestement insuffisante au regard de la réalité d’utilisation du produit.

Cette approche, qui s’inscrit dans la logique du privacy by design appliquée à la sécurité, est cohérente avec la tendance législative européenne en faveur de la durabilité, illustrée par le droit à la réparation et les exigences d’ecoconception. Le CRA s’inscrit dans ce mouvement en ajoutant une dimension securitaire à la durabilité des produits numériques.

Mises à jour automatiques et mécanismes de déploiement

Le CRA impose aux fabricants de mettre en place un mécanisme de mise à jour sécurisé permettant la distribution effective des correctifs de sécurité. L’annexe I du règlement precise que les produits doivent être conçus de manière a permettre l’installation de mises à jour de sécurité, y compris, le cas échéant, par le biais de mises à jour automatiques.

Lorsqu’un mécanisme de mise à jour automatique est proposé, il doit être activé par défaut, tout en laissant à l’utilisateur la possibilité de le désactiver. Ce choix reflète un compromis entre la protection effective des utilisateurs – dont la grande majorité ne procédé pas manuellement aux mises à jour – et le respect de l’autonomie de l’utilisateur.

Le mécanisme de mise à jour doit lui-même répondre à des exigences de sécurité : authentification de l’origine des mises à jour, intégrité du contenu déployé, et confidentialité le cas échéant. Il ne suffit pas de proposer une mise à jour ; encore faut-il que le processus de déploiement ne constitue pas lui-même un vecteur d’attaque.

Séparation des mises à jour de sécurité et des mises à jour fonctionnelles

L’une des exigences les plus significatives du CRA réside dans l’obligation de séparer les mises à jour de sécurité des mises à jour fonctionnelles. L’annexe I, partie II, point 2, prévoit explicitement que les correctifs de sécurité doivent pouvoir être installés indépendamment des mises à jour de fonctionnalités.

Cette disposition met fin à une pratique courante dans l’industrie : conditionner l’installation d’un correctif de sécurité critique à l’acceptation d’une mise à jour fonctionnelle majeure, parfois accompagnée de modifications d’interface, de nouvelles conditions d’utilisation ou d’exigences matérielles accrues. Un utilisateur qui ne souhaité pas migrer vers une nouvelle version de son logiciel doit néanmoins pouvoir bénéficier des correctifs de sécurité.

Sur le plan technique, cette exigence impose une architecture de mise à jour granulaire. Les fabricants doivent être en mesure d’identifier, d’isoler et de déployer les composants strictement lies à la sécurité, indépendamment du reste de la base de code. C’est un changement de paradigme pour de nombreux éditeurs habitues à des cycles de déploiement monolithiques.

Fin de support : obligations d’information et état de sécurité final

Le CRA encadre également la fin du support sécurité. Le fabricant ne peut pas simplement cesser de fournir des mises à jour sans en informer les utilisateurs. Plusieurs obligations s’imposent à ce stade :

• Information préalable des utilisateurs : le fabricant doit informer clairement les utilisateurs de la date de fin du support sécurité, et ce des la mise sur le marché du produit. Cette information doit figurer dans la documentation technique et être accessible de manière non ambiguë.
• Notification de fin de support : à l’approche de la fin de la période de support, le fabricant doit rappeler aux utilisateurs que le produit ne bénéficiera plus de correctifs de sécurité.
• État de sécurité final : le produit doit être livré dans un état de sécurité aussi complet que possible au moment de la fin du support. Cela signifie que toutes les vulnérabilités connues au moment de la fin du support doivent avoir été corrigées.

Ces obligations sont a rapprocher de celles relatives au signalement des vulnérabilités : si une vulnérabilité activement exploitée est découverte alors que le produit est encore dans sa période de support, le fabricant est tenu de la corriger et de la signaler conformément aux procédures du CRA.

Implications pour la planification du cycle de vie des produits

Ces obligations transforment fondamentalement la manière dont les fabricants doivent concevoir leur stratégie produit. Le support sécurité n’est plus un élément optionnel ou un argument marketing : c’est une obligation légale chiffrable qui doit être intégrée dans le modèle économique du produit des sa conception.

Concrètement, un fabricant qui met un produit sur le marché en 2027 devra budgetiser le maintien d’une équipe de sécurité, d’une infrastructure de déploiement de mises à jour et d’un processus de gestion des vulnérabilités au minimum jusqu’en 2032, et potentiellement bien au-delà pour les produits a longue durée de vie. Pour les produits industriels ou les équipements de réseau dont la durée d’utilisation dépasse couramment dix ans, l’engagement financier est considérable.

Cette exigence devrait également conduire à une rationalisation des gammes de produits. Maintenir le support sécurité de dizaines de références simultanément représente un coût opérationnel significatif. Les fabricants auront un intérêt économique direct a réduire la fragmentation de leurs gammes et a standardiser les composants logiciels partagés entre produits.

Comparaison avec les pratiques actuelles de l’industrie

Le contraste entre les exigences du CRA et les pratiques actuelles de l’industrie est saisissant. Aujourd’hui, la durée de support sécurité varie considérablement selon les secteurs et les fabricants :

• Smartphones : les principaux fabricants proposent désormais 5 à 7 ans de mises à jour de sécurité, mais de nombreux modèles d’entrée de gamme ne bénéficient que de 2 à 3 ans de support.
• Objets IoT grand public : la durée de support est souvent inexistante ou non communiquée. De nombreux appareils connectés – caméras, assistants vocaux, appareils domotiques – cessent de recevoir des mises à jour sans aucune notification aux utilisateurs.
• Logiciels : les grands éditeurs suivent généralement des cycles de support structurés (Microsoft propose par exemple un support étendu de 10 ans pour Windows), mais les éditeurs de taille intermédiaire n’ont souvent aucun engagement formel.
• Équipements réseau et industriels : la durée de support est généralement contractualisee, mais fréquemment conditionnée à la souscription d’un contrat de maintenance payant.

Le CRA modifie radicalement cette situation sur un point essentiel : les mises à jour de sécurité doivent être gratuites. Le fabricant ne peut pas conditionner l’accès aux correctifs de sécurité à un abonnement ou à un contrat de service. Cette exigence de gratuité, combinee à la durée minimale de cinq ans, impose un changement de modèle économique pour de nombreux acteurs.

Se préparer des maintenant

Les fabricants doivent anticiper ces obligations sans attendre l’échéance du 11 décembre 2027, date d’application du CRA. La mise en place d’une infrastructure de gestion des mises à jour conforme, la restructuration des processus de développement pour permettre la séparation des correctifs de sécurité et des mises à jour fonctionnelles, et l’intégration du coût du support sécurité dans le prix des produits sont des chantiers qui nécessitent plusieurs années de préparation.

Le support sécurité des produits numériques n’est plus une option. C’est une obligation légale européenne dont la violation expose les fabricants aux sanctions prévues par le CRA, pouvant atteindre 15 millions d’euros ou 2,5 % du chiffre d’affaires annuel mondial. Les organisations qui prendront le sujet au sérieux des aujourd’hui disposeront d’un avantage concurrentiel décisif sur un marché européen qui va profondément se restructurer autour de la confiance numérique.