Le Cyber Resilience Act (reglement (UE) 2024/2847) ne se limite pas a imposer un niveau de securite au moment de la mise sur le marche. L’une de ses dispositions les plus structurantes concerne le support securite des produits numeriques apres leur commercialisation : les fabricants sont desormais tenus de fournir des mises a jour de securite gratuites pendant toute la duree de vie attendue du produit, avec un minimum incompressible de cinq ans. Cette obligation transforme en profondeur la relation entre fabricant et utilisateur et impose de repenser integralement les cycles de vie des produits.

La duree du support securite : un minimum de cinq ans

L’article 13(8) du CRA etablit le principe fondamental : le fabricant doit assurer la gestion des vulnerabilites et fournir des mises a jour de securite pendant la duree de vie attendue du produit (“expected product lifetime”). Cette duree ne peut en aucun cas etre inferieure a cinq ans a compter de la mise sur le marche du produit, sauf si la duree de vie attendue du produit est inferieure a cinq ans – auquel cas c’est cette duree plus courte qui s’applique.

Ce plancher de cinq ans constitue une rupture majeure. Jusqu’a present, aucun texte europeen n’imposait une duree minimale de support securite pour les produits numeriques. De nombreux fabricants, en particulier dans le secteur de l’IoT, cessaient de fournir des correctifs de securite quelques mois apres la commercialisation, laissant les utilisateurs exposes a des vulnerabilites connues sans aucun recours. Cette lacune est d’autant plus problematique que la directive NIS2 renforce les exigences de securite pour les entites utilisant ces produits.

Le fabricant ne peut pas definir cette duree de maniere arbitraire. Le CRA precise qu’elle doit refleter la duree pendant laquelle le produit est raisonnablement susceptible d’etre utilise, en tenant compte des attentes raisonnables des utilisateurs, de la nature du produit et du droit de l’Union applicable. Un routeur industriel concu pour etre integre dans une infrastructure critique sera logiquement soumis a une duree de support plus longue qu’une application mobile a faible enjeu.

Qu’est-ce que la “duree de vie attendue du produit” ?

La notion de duree de vie attendue merite un examen attentif, car elle constitue le pivot de l’ensemble du dispositif. Le CRA retient une approche fondee sur plusieurs criteres cumulatifs :

• Les attentes raisonnables des utilisateurs, compte tenu de la nature et de la finalite du produit. Un systeme de controle industriel ne suscite pas les memes attentes qu’un objet connecte grand public.
• La duree pendant laquelle le produit est raisonnablement susceptible d’etre utilise, qui tient compte de la durabilite materielle, de la frequence de renouvellement dans le secteur concerne et des pratiques du marche.
• La legislation de l’Union applicable, notamment en matiere de durabilite et de garantie legale.

En pratique, cette definition fonctionnelle signifie que le fabricant ne peut pas raccourcir artificiellement la duree de vie attendue en declarant un produit obsolete prematurement. Les autorites de surveillance du marche disposeront d’un pouvoir d’appreciation pour contester une duree manifestement insuffisante au regard de la realite d’utilisation du produit.

Cette approche, qui s’inscrit dans la logique du privacy by design appliquee a la securite, est coherente avec la tendance legislative europeenne en faveur de la durabilite, illustree par le droit a la reparation et les exigences d’ecoconception. Le CRA s’inscrit dans ce mouvement en ajoutant une dimension securitaire a la durabilite des produits numeriques.

Mises a jour automatiques et mecanismes de deploiement

Le CRA impose aux fabricants de mettre en place un mecanisme de mise a jour securise permettant la distribution effective des correctifs de securite. L’annexe I du reglement precise que les produits doivent etre concus de maniere a permettre l’installation de mises a jour de securite, y compris, le cas echeant, par le biais de mises a jour automatiques.

Lorsqu’un mecanisme de mise a jour automatique est propose, il doit etre active par defaut, tout en laissant a l’utilisateur la possibilite de le desactiver. Ce choix reflete un compromis entre la protection effective des utilisateurs – dont la grande majorite ne procede pas manuellement aux mises a jour – et le respect de l’autonomie de l’utilisateur.

Le mecanisme de mise a jour doit lui-meme repondre a des exigences de securite : authentification de l’origine des mises a jour, integrite du contenu deploye, et confidentialite le cas echeant. Il ne suffit pas de proposer une mise a jour ; encore faut-il que le processus de deploiement ne constitue pas lui-meme un vecteur d’attaque.

Separation des mises a jour de securite et des mises a jour fonctionnelles

L’une des exigences les plus significatives du CRA reside dans l’obligation de separer les mises a jour de securite des mises a jour fonctionnelles. L’annexe I, partie II, point 2, prevoit explicitement que les correctifs de securite doivent pouvoir etre installes independamment des mises a jour de fonctionnalites.

Cette disposition met fin a une pratique courante dans l’industrie : conditionner l’installation d’un correctif de securite critique a l’acceptation d’une mise a jour fonctionnelle majeure, parfois accompagnee de modifications d’interface, de nouvelles conditions d’utilisation ou d’exigences materielles accrues. Un utilisateur qui ne souhaite pas migrer vers une nouvelle version de son logiciel doit neanmoins pouvoir beneficier des correctifs de securite.

Sur le plan technique, cette exigence impose une architecture de mise a jour granulaire. Les fabricants doivent etre en mesure d’identifier, d’isoler et de deployer les composants strictement lies a la securite, independamment du reste de la base de code. C’est un changement de paradigme pour de nombreux editeurs habitues a des cycles de deploiement monolithiques.

Fin de support : obligations d’information et etat de securite final

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

• Information prealable des utilisateurs : le fabricant doit informer clairement les utilisateurs de la date de fin du support securite, et ce des la mise sur le marche du produit. Cette information doit figurer dans la documentation technique et etre accessible de maniere non ambigue.
• Notification de fin de support : a l’approche de la fin de la periode de support, le fabricant doit rappeler aux utilisateurs que le produit ne beneficiera plus de correctifs de securite.
• Etat de securite final : le produit doit etre livre dans un etat de securite aussi complet que possible au moment de la fin du support. Cela signifie que toutes les vulnerabilites connues au moment de la fin du support doivent avoir ete corrigees.

Ces obligations sont a rapprocher de celles relatives au signalement des vulnerabilites : si une vulnerabilite activement exploitee est decouverte alors que le produit est encore dans sa periode de support, le fabricant est tenu de la corriger et de la signaler conformement aux procedures du CRA.

Implications pour la planification du cycle de vie des produits

Ces obligations transforment fondamentalement la maniere dont les fabricants doivent concevoir leur strategie produit. Le support securite n’est plus un element optionnel ou un argument marketing : c’est une obligation legale chiffrable qui doit etre integree dans le modele economique du produit des sa conception.

Concretement, un fabricant qui met un produit sur le marche en 2027 devra budgetiser le maintien d’une equipe de securite, d’une infrastructure de deploiement de mises a jour et d’un processus de gestion des vulnerabilites au minimum jusqu’en 2032, et potentiellement bien au-dela pour les produits a longue duree de vie. Pour les produits industriels ou les equipements de reseau dont la duree d’utilisation depasse couramment dix ans, l’engagement financier est considerable.

Cette exigence devrait egalement conduire a une rationalisation des gammes de produits. Maintenir le support securite de dizaines de references simultanement represente un cout operationnel significatif. Les fabricants auront un interet economique direct a reduire la fragmentation de leurs gammes et a standardiser les composants logiciels partages 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 duree de support securite varie considerablement selon les secteurs et les fabricants :

• Smartphones : les principaux fabricants proposent desormais 5 a 7 ans de mises a jour de securite, mais de nombreux modeles d’entree de gamme ne beneficient que de 2 a 3 ans de support.
• Objets IoT grand public : la duree de support est souvent inexistante ou non communiquee. De nombreux appareils connectes – cameras, assistants vocaux, appareils domotiques – cessent de recevoir des mises a jour sans aucune notification aux utilisateurs.
• Logiciels : les grands editeurs suivent generalement des cycles de support structures (Microsoft propose par exemple un support etendu de 10 ans pour Windows), mais les editeurs de taille intermediaire n’ont souvent aucun engagement formel.
• Equipements reseau et industriels : la duree de support est generalement contractualisee, mais frequemment conditionnee a la souscription d’un contrat de maintenance payant.

Le CRA modifie radicalement cette situation sur un point essentiel : les mises a jour de securite doivent etre gratuites. Le fabricant ne peut pas conditionner l’acces aux correctifs de securite a un abonnement ou a un contrat de service. Cette exigence de gratuite, combinee a la duree minimale de cinq ans, impose un changement de modele economique pour de nombreux acteurs.

Se preparer des maintenant

Les fabricants doivent anticiper ces obligations sans attendre l’echeance du 11 decembre 2027, date d’application du CRA. La mise en place d’une infrastructure de gestion des mises a jour conforme, la restructuration des processus de developpement pour permettre la separation des correctifs de securite et des mises a jour fonctionnelles, et l’integration du cout du support securite dans le prix des produits sont des chantiers qui necessitent plusieurs annees de preparation.

Le support securite des produits numeriques n’est plus une option. C’est une obligation legale europeenne dont la violation expose les fabricants aux sanctions prevues 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 serieux des aujourd’hui disposeront d’un avantage concurrentiel decisif sur un marche europeen qui va profondement se restructurer autour de la confiance numerique.