Le règlement sur la cyberrésilience de l'UE fait de la planification de la période d'assistance une décision de lancement produit, pas un sujet à régler après coup. Le fabricant doit décider pendant combien de temps les utilisateurs peuvent attendre une gestion des vulnérabilités, publier la date de fin d'assistance au moment de l'achat et maintenir les mises à jour de sécurité disponibles pendant la durée requise. Ce guide couvre la mécanique de durée : début du compteur, fonctionnement de l'exception de durée d'utilisation plus courte, empilement des portefeuilles multi-versions et couverture attendue des contrats fournisseurs en amont. Pour la cadence de livraison, consultez les mises à jour de sécurité CRA ; pour la date de fin côté utilisateur, consultez la divulgation de fin d'assistance.
Synthèse
- Cinq ans constituent le plancher. Le CRA exige une gestion des vulnérabilités pendant au moins cinq ans, sauf si le produit est censé être utilisé pendant une durée plus courte.
- L'exception de durée d'utilisation plus courte est étroite. Elle doit être évaluée avant la mise sur le marché, documentée dans la documentation technique et communiquée aux utilisateurs avant l'achat.
- Le compteur démarre à la mise sur le marché, pas à l'achat par le client. Un stock qui dort en entrepôt avant la vente a déjà consommé une partie de la fenêtre d'assistance.
- Les portefeuilles multi-versions peuvent empiler des fenêtres qui se chevauchent. Une voie logicielle limitée permet de corriger uniquement la dernière version, mais seulement si les utilisateurs des versions précédentes peuvent migrer gratuitement et sans coûts d'environnement.
- Le risque fournisseur en amont reste le risque du fabricant. La fin de vie d'un composant n'est pas une défense ; les contrats d'approvisionnement doivent couvrir toute la période d'assistance.
Les quatre repères de la planification de l’assistance : durée minimale, coût des mises à jour, conservation documentaire et exposition aux sanctions.
Ce que le CRA exige pour la période d'assistance
La période d'assistance est la fenêtre pendant laquelle le fabricant doit maintenir actif le processus de gestion des vulnérabilités du produit. Elle couvre le produit et ses composants, démarre à la mise sur le marché UE et doit être suffisamment longue pour correspondre à l'usage que les utilisateurs peuvent raisonnablement attendre. Le fabricant doit la fixer à partir d'éléments concrets : type de produit, finalité prévue, produits comparables, règles de l'Union sur la durée de vie applicables, disponibilité de l'environnement d'exploitation, support des composants tiers essentiels et orientations ADCO ou Commission. Le résultat pratique est simple : l'assistance doit être fixée avant le lancement et maintenue pendant toute la fenêtre déclarée.
L'obligation comporte trois composantes :
| Composante | Règle opérationnelle | Éléments à conserver |
|---|---|---|
| DuréeDurée de l'assistance | Prévoir au moins cinq ans, sauf si la période d'utilisation prévue du produit est plus courte. | Justification de la période d'assistance dans la documentation technique et date de fin d'assistance claire à l'achat. |
| TraitementCe qui doit rester actif | Maintenir le cycle des vulnérabilités : documenter les constats, corriger sans délai, divulguer les problèmes corrigés, exploiter la CVD et distribuer les mises à jour de manière sécurisée. | Registres de vulnérabilités, horodatages de correction, politique CVD, preuves de distribution des mises à jour et avis aux utilisateurs. |
| Mises à jour de sécuritéCoût et disponibilité | Diffuser les mises à jour de sécurité disponibles sans délai et gratuitement, sauf exception étroite pour les produits professionnels sur mesure. | Registres de versions montrant quand les correctifs ont été mis à disposition et que les correctifs de sécurité de base n'étaient pas placés derrière des offres payantes. |
Déclenchement du compteur de cinq ans
Le compteur d'assistance démarre lorsque le produit entre sur le marché de l'UE, pas lorsque le client final l'achète. Au sens du droit des produits de l'UE, il s'agit de la première mise à disposition du produit sur le marché de l'Union en vue de sa distribution ou de son utilisation. Pour planifier l'assistance, la date de mise sur le marché est la date qui compte.
Déclenchement : la date à laquelle le produit est mis pour la première fois à disposition d'un distributeur, d'un revendeur, d'un importateur ou d'un utilisateur en vue de sa distribution ou de son utilisation sur le marché de l'UE.
Le compteur ne démarre pas à : l'achat par le client, l'activation par le client, l'expédition d'un exemplaire spécifique ou la date à laquelle un client installe le produit.
Exemple concret :
- Janvier 2028. Le produit v1.0 est mis sur le marché de l'UE. La période d'assistance de cinq ans commence. Le fabricant doit des mises à jour de sécurité au moins jusqu'en janvier 2033.
- Juin 2029. Un client achète la v1.0 auprès d'un revendeur. Il dispose d'environ 3,5 ans d'assistance restante, et non de cinq ans à compter de son achat.
- Janvier 2033. La période d'assistance prend fin. L'engagement de base de gestion des vulnérabilités pour v1.0 prend fin. Les notifications aux utilisateurs ou échanges réglementaires ultérieurs dépendent ensuite des faits.
Bonne pratique : suivre les dates de mise sur le marché par version de produit, et non par exemplaire individuel. Un seul enregistrement de la date de mise sur le marché par référence (SKU) constitue généralement la base de preuve pratique pour calculer les dates de fin d'assistance.
L'exception de durée d'utilisation plus courte
Le plancher de cinq ans ne peut être raccourci que lorsque le produit est réellement censé être utilisé pendant moins de cinq ans. Cette exception est plus étroite qu'elle ne paraît et provient de la règle sur la période d'assistance :
- La « période d'utilisation prévue du produit » s'apprécie du point de vue des attentes raisonnables des utilisateurs, en fonction de la nature du produit, de l'usage habituel de produits similaires et de ce que le fabricant communique.
- La durée plus courte doit être documentée dans la documentation technique et communiquée aux utilisateurs à l'achat, au minimum avec le mois et l'année de la date de fin d'assistance.
- Le fabricant ne peut pas invoquer l'exception après la découverte d'une vulnérabilité. L'évaluation doit être faite avant la mise sur le marché et enregistrée dans le dossier technique.
- Pour la plupart des logiciels, objets IoT et matériels connectés, cinq ans constituent le minimum pratique. L'exception vise les produits à durée utile objectivement courte, comme du matériel à usage unique ou à cycles limités, plutôt que les produits pour lesquels le fabricant préfère simplement une obligation plus courte.
Assistance multi-versions
La plupart des fabricants ont plusieurs versions de produit sur le marché en même temps. Les produits matériels et les versions logicielles maintenues indépendamment peuvent créer des fenêtres d'assistance qui se chevauchent. Les logiciels disposent aussi d'une voie limitée de dernière version uniquement pour les versions ultérieures substantiellement modifiées, mais seulement si les utilisateurs des versions précédentes peuvent passer gratuitement à la dernière version, sans coûts supplémentaires de matériel ou d'environnement logiciel.
Des périodes d'assistance décalées génèrent des obligations qui se chevauchent :
| Version | Mise sur le marché | Fin d'assistance (5 ans) |
|---|---|---|
| v1.0 | Janv. 2028 | Janv. 2033 |
| v1.1 | Juil. 2028 | Juil. 2033 |
| v2.0 | Janv. 2029 | Janv. 2034 |
De janvier 2029 à janvier 2033, pendant quatre ans, le fabricant peut devoir des mises à jour de sécurité aux trois versions simultanément, sauf si une voie logicielle éligible de dernière version uniquement s'applique. Chaque version a sa propre exposition CVE, son propre arbre de dépendances et potentiellement sa propre base de clients. Le rétroportage de correctifs entre versions majeures est techniquement complexe et coûteux.
Stratégies pour réduire la charge multi-versions :
- Base de code partagée. Dans la mesure du possible, maintenez un noyau unique avec correctifs de sécurité sur lequel toutes les versions s'appuient. Les correctifs de sécurité appliqués une seule fois se propagent à toutes les versions.
- Incitations actives à la migration. Réduire les écarts entre les clients sur d'anciennes versions diminue la matrice d'assistance active. Des tarifs de mise à niveau, des outils de migration gratuits et des crédits d'assistance accélèrent la consolidation des versions.
- Calendrier de fin de vie explicite par version. Publiez la date de fin d'assistance de chaque version dès la mise sur le marché. Les clients qui savent que v1.0 se termine en janvier 2033 ont le temps de planifier leur migration sans pression d'urgence.
- Voie « dernière version uniquement » pour les logiciels éligibles. Si vous utilisez cette voie, documentez comment les utilisateurs des versions précédentes reçoivent la dernière version gratuitement et sans coûts d'adaptation de l'environnement.
Obligations contractuelles envers les fournisseurs en amont
Le fabricant porte l'obligation de période d'assistance même lorsqu'une vulnérabilité provient d'un composant en amont. Si le produit ne peut pas être corrigé parce qu'un fournisseur de composant a arrêté son support, le fabricant doit malgré tout disposer d'une voie de remédiation. La faille contractuelle en amont n'est pas une défense au titre de la règle sur la période d'assistance.
Concrètement :
- Si un produit intègre un système d'exploitation tiers, un intergiciel ou un micrologiciel de chipset, le fabricant doit sécuriser un accord d'approvisionnement couvrant toute la période d'assistance. Un fournisseur en amont qui ne propose des correctifs de sécurité que pendant trois ans contraint le fabricant soit à maintenir lui-même les correctifs après la troisième année, soit à cesser de mettre le produit sur le marché de l'UE après la fin de vie du composant en amont.
- Le suivi des dépendances par SBOM (voir le guide de la grappe SBOM) constitue le mécanisme opérationnel : le fabricant ne peut pas surveiller les vulnérabilités en amont sans connaître la composition de son produit.
- Les contrats d'approvisionnement devraient préciser : la durée d'engagement du fournisseur en matière de correctifs, les obligations de notification pour les vulnérabilités nouvellement découvertes, l'accès au code source ou aux outils de correction si le fournisseur en amont met fin au composant, et les clauses d'indemnisation pour les vulnérabilités issues des composants tiers.
Les importateurs et distributeurs qui mettent un produit sur le marché sous leur propre nom ou marque, ou qui modifient substantiellement un produit déjà mis sur le marché, sont traités comme des fabricants et héritent des obligations du fabricant, y compris le risque contractuel en amont. Consultez le guide des obligations des importateurs pour le flux de décision de changement de rôle.
Planification de la fin de vie et transitions produit responsables
Lorsque la période d'assistance prend fin, l'engagement de base de gestion des vulnérabilités pour cette version du produit prend fin, mais un ensemble de responsabilités demeure.
Ce qui demeure à la fin de l'assistance :
- La date de fin de la période d'assistance communiquée à l'achat reste l'engagement tourné vers l'utilisateur.
- La documentation technique et la déclaration UE de conformité doivent être conservées pendant au moins 10 ans à compter de la mise sur le marché ou pendant la période d'assistance, la plus longue étant retenue.
- Les informations et instructions destinées aux utilisateurs doivent rester disponibles aux utilisateurs et aux autorités de surveillance du marché sur la même base de 10 ans ou période d'assistance, quel que soit le canal de diffusion ; lorsqu'elles sont fournies en ligne, elles doivent également rester accessibles en ligne pendant cette période.
- Dans la mesure où cela est techniquement faisable, le fabricant devrait informer les utilisateurs lorsque le produit a atteint la fin de sa période d'assistance.
- Les vulnérabilités de produits non supportés exigent malgré tout un traitement prudent. Le CRA ne prévoit pas de phrase de refuge automatique couvrant toute question de signalement d'incident à la fin de l'assistance, et les autorités de surveillance du marché peuvent encore agir lorsqu'un produit présente un risque significatif de cybersécurité. L'exposition aux sanctions est traitée dans le guide sanctions et enforcement.
Obligations de communication à la fin de l'assistance :
Le CRA ne fixe pas de délai légal de préavis pour la fin de l'assistance. La communication de la date de fin de la période d'assistance à l'achat signifie que les utilisateurs ayant acheté le produit après la mise en place de cette communication étaient déjà informés. Pour les produits dont la communication initiale était absente ou ambiguë, un préavis constitue un contrôle opérationnel du risque, pas un délai numéroté du CRA.
Après la fin de l'assistance : le fabricant devrait maintenir un contact sécurité pour la divulgation responsable des vulnérabilités, garder la documentation produit accessible et coopérer avec toute enquête d'une autorité de surveillance du marché.
Erreurs courantes
-
Ne pas suivre les dates de mise sur le marché. Sans date de mise sur le marché par version, le fabricant ne peut pas calculer le début ou la fin des obligations d'assistance, ne peut pas produire la date de fin d'assistance côté utilisateur et ne peut pas démontrer sa conformité aux autorités de surveillance du marché.
-
Ne pas anticiper la fin de vie en amont. Si un fournisseur de chipset, de système d'exploitation ou d'intergiciel arrête son support avant l'expiration de la période d'assistance du fabricant, celui-ci doit avoir un plan. Découvrir tardivement une fin de vie en amont sans accord d'approvisionnement en place est un mode d'échec courant et coûteux.
-
Coupler les correctifs de sécurité aux versions fonctionnelles. Regrouper les correctifs de sécurité dans des mises à niveau majeures oblige les clients à accepter de nouvelles fonctionnalités et une nouvelle surface de risque pour recevoir un correctif de sécurité. Les correctifs de sécurité doivent être fournis comme des correctifs de sécurité, sans imposer de niveaux payants ni de grandes mises à niveau fonctionnelles.
Foire aux questions
Quand commence la période d'assistance de cinq ans ?
Elle commence lorsque le produit est mis sur le marché de l'UE, pas lorsqu'un client l'achète ou l'active. La mise sur le marché correspond à la première mise à disposition du produit sur le marché de l'Union, de sorte que le temps passé en entrepôt ou chez un distributeur peut consommer une partie de la fenêtre d'assistance. Un produit mis sur le marché en janvier 2028 nécessite normalement une gestion des vulnérabilités au moins jusqu'en janvier 2033, même si un client l'achète plus tard.
La période d'assistance peut-elle être inférieure à cinq ans ?
Oui, mais uniquement lorsque le produit est censé être utilisé pendant moins de cinq ans. La période d'assistance doit refléter les attentes raisonnables des utilisateurs, la nature et la finalité prévue du produit, le droit de l'Union applicable, les produits comparables, la disponibilité de l'environnement d'exploitation, le support des composants tiers essentiels et les orientations ADCO ou Commission. Les informations utilisées pour la déterminer relèvent de la documentation technique, et la date de fin doit être claire à l'achat.
Le signalement s'applique-t-il après la fin de la période d'assistance ?
Ne traitez pas l'expiration de l'assistance comme un refuge général en matière de signalement d'incidents. La règle sur la période d'assistance définit la fenêtre de gestion des vulnérabilités, tandis que l'obligation de signalement d'incidents exige séparément la notification des vulnérabilités activement exploitées et des incidents graves dont le fabricant prend connaissance. Pour un produit non supporté, documentez l'analyse juridique avant de décider de ne pas signaler, et envisagez tout de même une notification aux utilisateurs lorsque le risque est matériel.
Que se passe-t-il si un fournisseur de composant en amont arrête son support plus tôt ?
Le fabricant conserve l'obligation liée à la période d'assistance. La règle sur la période d'assistance couvre les vulnérabilités du produit et de ses composants, et la règle de diligence raisonnable sur les composants impose une vigilance lors de l'intégration de composants tiers. Si un fournisseur de chipset, de système d'exploitation, d'intergiciel ou de bibliothèque se retire trop tôt, le fabricant doit trouver une autre voie : maintenir les correctifs, remplacer le composant ou cesser de mettre la configuration concernée sur le marché de l'UE.