Période de support CRA : plancher de 5 ans (Article 13(8))

L'Article 13(8) du Règlement sur la cyberrésilience de l'UE (Règlement (UE) 2024/2847) fixe un plancher de cinq ans pour la gestion des vulnérabilités, ancré à la date de mise sur le marché de l'UE. Ce guide couvre les mécanismes de durée : quand l'horloge démarre, comment fonctionne la dérogation pour durée d'utilisation prévue plus courte, comment les portefeuilles multi-versions génèrent des obligations qui se chevauchent, et ce que les contrats d'approvisionnement en amont doivent couvrir. Pour les modalités de distribution des mises à jour, consultez les mises à jour de sécurité CRA ; pour la communication de la date de fin d'assistance aux utilisateurs, consultez la communication de fin d'assistance.

Synthèse

  • Cinq ans est le plancher. L'Article 13(8) exige la gestion des vulnérabilités pendant au moins cinq ans à compter de la date de mise sur le marché de l'UE.
  • La dérogation pour durée d'utilisation prévue plus courte est étroite. Elle doit être évaluée avant la mise sur le marché, documentée dans l'évaluation des risques de l'Annexe I, Partie I, et communiquée aux utilisateurs dans les informations de l'Annexe II avant l'achat.
  • L'horloge démarre à la mise sur le marché, pas à l'achat par le client. Un stock qui reste en entrepôt avant la vente a déjà consommé une partie de la fenêtre d'assistance.
  • Les portefeuilles multi-versions génèrent des obligations qui se chevauchent. Chaque version a sa propre horloge au titre de l'Article 13(8) ; les fabricants peuvent devoir assurer simultanément l'assistance de trois versions actives ou plus.
  • Le risque fournisseur en amont est le risque du fabricant. La fin de vie d'un composant chez un prestataire tiers ne constitue pas une défense ; les contrats d'approvisionnement doivent couvrir toute la période prévue par l'Article 13(8).
5y
Durée minimale d'assistance
Article 13(8), à compter de la mise sur le marché
Free
Mises à jour de sécurité
Article 13(8), sans facturation des correctifs
10y
Conservation du dossier technique
Article 31, à compter de la mise sur le marché
€15M / 2.5%
Amende maximale
Article 64, le montant le plus élevé

Les quatre chiffres qui définissent la période d'assistance CRA : la durée minimale, l'obligation de gratuité, le plancher de conservation de la documentation et le plafond des sanctions.

La période d'assistance débute à la mise sur le marché, et non à l'achat par le client

L'Article 13(8) ancre la période de cinq ans à la date à laquelle le produit est mis sur le marché de l'UE, c'est-à-dire la première fois qu'il est mis à disposition d'un acteur de la chaîne de distribution ou de vente. Un exemplaire qui reste en entrepôt pendant 18 mois avant qu'un client l'achète a déjà consommé 18 mois de sa période d'assistance. Ce mécanisme crée un risque lié aux stocks : les fabricants qui ne suivent pas les dates de mise sur le marché par version de produit ne peuvent pas démontrer leur conformité avec l'Article 13(8).

Ce que le CRA exige pour la période d'assistance

L'Article 13(8) du Règlement sur la cyberrésilience dispose que le fabricant « veille à ce que les vulnérabilités du produit comportant des éléments numériques soient traitées de manière efficace pendant une période correspondant à la durée d'utilisation prévue du produit comportant des éléments numériques, sans pouvoir être inférieure à cinq ans à compter de la date à laquelle le produit avec des éléments numériques est mis sur le marché, ou pendant la durée d'utilisation prévue du produit si celle-ci est inférieure à cinq ans. »

L'obligation comporte trois composantes :

Durée

Au moins cinq ans. La dérogation « durée d'utilisation prévue si elle est inférieure » est étroite et doit être documentée et communiquée avant l'achat. Un fabricant ne peut pas l'invoquer rétrospectivement. Si la documentation indique cinq ans, le fabricant est tenu de fournir cinq ans d'assistance.

Traitement

Les vulnérabilités doivent être traitées « de manière efficace » conformément à l'Annexe I, Partie II : les identifier et les documenter, les corriger sans retard injustifié, les signaler une fois traitées, et mettre en place une politique de divulgation coordonnée. Il ne s'agit pas seulement de distribuer des correctifs, mais de gérer l'ensemble du cycle de vie des vulnérabilités.

Sans frais

Les mises à jour de sécurité doivent être fournies gratuitement aux utilisateurs. Les mises à jour fonctionnelles et les niveaux d'assistance payants sont distincts. Intégrer des correctifs dans un abonnement payant ne satisfait pas à l'Article 13(8). Consultez les mises à jour de sécurité pour les modalités de distribution.

Déclenchement de la période de cinq ans

L'Article 13(8) ancre la période d'assistance à la date à laquelle le produit est « mis sur le marché ». Au sens du droit des produits de l'UE, la mise sur le marché correspond à la première fois que le produit est mis à disposition d'un acteur de la chaîne de distribution, et non à la vente au détail à l'utilisateur final.

Déclenchement : la date à laquelle le fabricant (ou un représentant autorisé) met pour la première fois le produit à disposition d'un distributeur, d'un revendeur ou d'un importateur en vue de sa distribution dans l'UE.

Absence de déclenchement : 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 :

  1. 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 fournir des mises à jour de sécurité jusqu'à au moins janvier 2033.
  2. Juin 2029. Un client achète la v1.0 auprès d'un revendeur. Le client bénéficie d'environ 3,5 ans d'assistance restante, et non de cinq ans à compter de son achat.
  3. Janvier 2033. La période d'assistance prend fin. L'obligation du fabricant de corriger la v1.0 cesse. Le client continue d'utiliser le produit à ses propres risques.

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) est suffisant au regard de l'Article 13(8).

La dérogation pour durée d'utilisation prévue plus courte

L'Article 13(8) permet de fixer une période d'assistance inférieure à cinq ans si la durée d'utilisation prévue du produit est plus courte. Cette dérogation est plus étroite qu'elle ne le paraît :

  • La « durée d'utilisation prévue » s'évalue du point de vue des attentes raisonnables des utilisateurs, compte tenu de la nature du produit, des conditions d'utilisation habituelles de produits similaires et des communications du fabricant.
  • La durée réduite doit être documentée dans l'évaluation des risques du produit (Annexe I, Partie I) et communiquée aux utilisateurs dans les informations produit de l'Annexe II avant l'achat.
  • Un fabricant ne peut pas invoquer la dérogation après la découverte d'une vulnérabilité. L'évaluation doit être réalisée avant la mise sur le marché et consignée dans le dossier technique.
  • Pour la plupart des logiciels, des appareils IoT et des équipements connectés, cinq ans constitue le minimum pratique. La dérogation s'applique aux produits dont la durée de vie utile est objectivement courte, tels que les matériels à usage unique ou à cycles limités, et non aux produits pour lesquels le fabricant préférerait simplement une obligation plus courte.

Assistance multi-versions

La plupart des fabricants commercialisent simultanément plusieurs versions d'un produit, chacune avec sa propre période d'assistance au titre de l'Article 13(8).

Des périodes d'assistance décalées génèrent des obligations qui se chevauchent :

Trois versions du produit se chevauchent pendant quatre ans au titre de l'Article 13(8) Chronologie de type Gantt. La v1.0 est prise en charge de janvier 2028 à janvier 2033. La v1.1 est prise en charge de juillet 2028 à juillet 2033. La v2.0 est prise en charge de janvier 2029 à janvier 2034. Entre janvier 2029 et janvier 2033, les trois versions sont simultanément sous assistance. Fenêtre de quatre ans : les trois versions sous assistance simultanée v1.0 v1.1 v2.0 2028 2029 2030 2031 2032 2033 2034
Chaque barre représente une période d'assistance de cinq ans au titre de l'Article 13(8), ancrée à la date de mise sur le marché de l'UE de la version concernée. La bande ombrée marque la fenêtre pendant laquelle le fabricant doit fournir simultanément des correctifs à l'ensemble du portefeuille.
Version Mise sur le marché Fin d'assistance (5 ans)
v1.0 Jan. 2028 Jan. 2033
v1.1 Juil. 2028 Juil. 2033
v2.0 Jan. 2029 Jan. 2034

De janvier 2029 à janvier 2033 (quatre ans), le fabricant doit fournir des mises à jour de sécurité aux trois versions simultanément. Chaque version a sa propre exposition aux CVE, son propre arbre de dépendances et, potentiellement, sa propre base de clients. Le rétroport des correctifs entre versions majeures est techniquement complexe et coûteux.

Stratégies pour réduire la charge multi-versions :

  1. Base de code commune. Dans la mesure du possible, maintenir un noyau unique avec correctifs de sécurité, sur lequel toutes les versions s'appuient. Un correctif de sécurité appliqué une fois se propage à toutes les versions.
  2. Incitations actives à la migration. Réduire l'écart 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.
  3. Calendrier explicite de fin de vie par version. Publier la date de fin d'assistance de chaque version dès sa mise sur le marché. Les clients qui savent que la v1.0 se termine en janvier 2033 ont le temps de planifier leur migration sans se retrouver sous pression d'urgence.

Obligations contractuelles envers les fournisseurs en amont

L'Article 13(8) fait peser l'obligation de la période d'assistance sur le fabricant. Un fabricant qui ne peut pas corriger son produit parce qu'un fournisseur de composants a mis fin à son assistance reste en violation de l'Article 13(8). Le manque contractuel en amont ne constitue pas une défense.

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 qui déclenchent l'escalade de rôle prévue à l'Article 22 (en reconfigurant substantiellement un produit sous leur propre marque) héritent de l'intégralité de l'obligation de l'Article 13(8), y compris le risque contractuel en amont. Consultez le guide des obligations des importateurs pour le processus décisionnel relatif à l'Article 22.

Planification de la fin de vie et transitions produit responsables

Lorsque la période d'assistance prévue à l'Article 13(8) prend fin, l'obligation du fabricant de corriger les vulnérabilités cesse, mais un ensemble de responsabilités subsiste.

Ce que l'Article 13(8) et les dispositions connexes exigent à la fin de l'assistance :

  • La date de fin de la période d'assistance de l'Annexe II, communiquée avant l'achat, vaut engagement. Les utilisateurs doivent en avoir été informés suffisamment à l'avance.
  • Le dossier technique doit être conservé pendant au moins 10 ans à compter de la date de mise sur le marché de l'UE (Article 31), indépendamment de la date de fin d'assistance.
  • La déclaration UE de conformité doit rester accessible aux autorités de surveillance du marché.
  • Si le fabricant a connaissance d'une vulnérabilité critique activement exploitée dans un produit dont l'assistance a pris fin et affectant un parc installé significatif, il n'est soumis à aucune obligation de signalement au titre de l'Article 14 après la fin de vie. La divulgation responsable et la notification aux utilisateurs sont fortement recommandées. Consultez le signalement des vulnérabilités pour les mécanismes de délais prévus à l'Article 14 applicables pendant la période d'assistance.

Obligations de communication à la fin de l'assistance :

Le CRA ne prévoit pas de délai de préavis légal pour la fin de l'assistance. L'exigence de l'Annexe II de communiquer la date de fin de la période d'assistance avant 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 de l'Annexe II était absente ou peu claire, un préavis de 12 mois constitue le minimum recommandé par la pratique du secteur.

Après la fin de vie : le fabricant n'est pas tenu de corriger de nouvelles vulnérabilités, mais il devrait maintenir un contact de sécurité pour la divulgation responsable des vulnérabilités, tenir la documentation produit accessible et coopérer avec toute enquête d'une autorité de surveillance du marché conduite au titre de l'Article 58.

Pour le guide opérationnel complet de fin de vie, couvrant les modèles de notification, les dispositifs de migration, les scénarios de produits acquis et le calendrier de planification sur 18 mois, consultez Planification de la fin de vie CRA : transitions produit responsables.

Erreurs courantes

Ne pas suivre les dates de mise sur le marché. Sans enregistrement de la date de mise sur le marché par version, le fabricant ne peut pas calculer quand les obligations de l'Article 13(8) commencent ou prennent fin, ne peut pas produire la date de fin de période d'assistance de l'Annexe II, et ne peut pas démontrer sa conformité aux autorités de surveillance du marché.

Ne pas anticiper la fin de vie des composants en amont. Si un fournisseur de chipset, de système d'exploitation ou d'intergiciel met fin à son assistance avant l'expiration de la période prévue à l'Article 13(8) du fabricant, celui-ci doit disposer d'un plan. La découverte tardive d'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. Intégrer les correctifs de sécurité dans des mises à jour majeures oblige les clients à accepter de nouvelles fonctionnalités et une nouvelle surface de risque pour recevoir un correctif de sécurité. L'Article 13(8) exige que les correctifs soient délivrés sans retard injustifié. Un cycle de publication de six mois ne constitue pas une livraison « sans retard injustifié » pour une vulnérabilité critique.

Foire aux questions

Quand commence la période d'assistance de cinq ans ?

L'Article 13(8) ancre la période d'assistance à la date à laquelle le produit est mis sur le marché de l'UE : la première fois que le fabricant met le produit à disposition d'un acteur de la chaîne de distribution en vue de sa distribution dans l'UE. Elle ne démarre pas à la date d'achat par le client, à l'activation ou à l'expédition d'un exemplaire spécifique. Un produit mis sur le marché en janvier 2028 doit bénéficier de mises à jour de sécurité jusqu'à au moins janvier 2033, indépendamment de la date d'achat de chaque client.

La période d'assistance peut-elle être inférieure à cinq ans ?

Oui, dans le cadre de la dérogation prévue à l'Article 13(8), si la durée d'utilisation prévue du produit est inférieure à cinq ans. Toutefois, la durée réduite doit être déterminée avant la mise sur le marché, documentée dans l'évaluation des risques (Annexe I, Partie I) et communiquée aux utilisateurs dans les informations produit de l'Annexe II avant l'achat. Un fabricant ne peut pas invoquer la dérogation après la découverte d'une vulnérabilité, et l'évaluation doit refléter les attentes raisonnables des utilisateurs, et non les préférences de coût internes. Pour la plupart des appareils IoT, des équipements connectés et des logiciels, cinq ans constitue le minimum pratique.

L'obligation de signalement au titre de l'Article 14 s'applique-t-elle après la fin de la période d'assistance ?

Non. Les obligations de signalement au titre de l'Article 14 (l'alerte précoce de 24 heures, la notification de 72 heures et le rapport final de 14 jours pour les vulnérabilités activement exploitées) s'appliquent au fabricant pendant la période d'assistance. Une fois la période d'assistance de l'Article 13(8) expirée, le fabricant n'est soumis à aucune obligation de signalement au titre de l'Article 14 pour les vulnérabilités découvertes dans cette version du produit. Les autorités de surveillance du marché conservent le pouvoir d'enquêter au titre de l'Article 58 si un produit dont l'assistance a pris fin présente un risque cybersécurité significatif, mais les obligations permanentes de gestion des vulnérabilités et de signalement prévues aux Articles 13 et 14 ont pris fin.

Que faire si un fournisseur de composants en amont met fin à son assistance avant notre période prévue à l'Article 13(8) ?

L'Article 13(8) fait peser l'obligation sur le fabricant, et non sur les fournisseurs en amont. Si un fournisseur de chipset, de système d'exploitation ou d'intergiciel met fin à l'assistance d'un composant avant l'expiration de la période de cinq ans du fabricant, celui-ci doit soit maintenir les correctifs de manière indépendante, soit se procurer un composant alternatif bénéficiant d'une assistance, soit retirer le produit du marché de l'UE. La décision d'un fournisseur en amont de mettre fin à son assistance ne constitue pas une défense contre la constatation de non-conformité à l'Article 13(8) par une autorité de surveillance du marché. Les contrats d'approvisionnement négociés lors de la conception du produit devraient préciser la durée d'engagement du fournisseur en matière de correctifs, l'accès au code source ou aux outils de correction, et les obligations de notification, en les vérifiant par rapport à la période d'assistance prévue du produit avant la mise sur le marché.

Ce qu'il faut faire avant le 11 décembre 2027

  1. Pour chaque produit comportant des éléments numériques dans votre portefeuille, enregistrez la date de mise sur le marché par version. C'est le point de départ de l'horloge de l'Article 13(8) et l'ancre de la communication de l'Annexe II. Sans cet enregistrement, vous ne pouvez ni calculer ni démontrer la date de fin de période d'assistance.
  2. Évaluez si le minimum de cinq ans s'applique ou si la dérogation pour durée d'utilisation prévue plus courte est défendable. Documentez l'évaluation dans l'évaluation des risques (Annexe I, Partie I) et consignez-la dans le dossier technique. En cas de doute, engagez-vous sur cinq ans.
  3. Auditez les dépendances en amont par rapport à la période d'assistance. Pour chaque système d'exploitation tiers, micrologiciel de chipset, intergiciel ou bibliothèque figurant dans le SBOM, vérifiez que l'engagement du fournisseur en matière de correctifs couvre toute la période prévue à l'Article 13(8). Renégociez ou identifiez des alternatives là où ce n'est pas le cas. Consultez le guide de la grappe SBOM pour le dispositif de suivi des dépendances.
  4. Planifiez les communications de fin d'assistance pour les produits dont la période prévue à l'Article 13(8) expirera dans la fenêtre 2028-2033. Les utilisateurs doivent connaître la date de fin avant l'achat ; ils doivent recevoir un préavis avant la fin de l'assistance. Consultez le guide de planification de la fin de vie pour le calendrier de communication sur 18 mois et les modèles de notification.
  5. Si la gestion des périodes d'assistance, la surveillance des dépendances et le signalement au titre de l'Article 14 pour plusieurs versions de produits dépassent les capacités de votre équipe, CRA Evidence suit les dates de mise sur le marché et les dates de fin de période d'assistance par référence, surveille les dépendances SBOM pour les CVE nouvellement divulguées sur toute la fenêtre d'assistance, et signale les obligations de signalement au titre de l'Article 14 lorsque des vulnérabilités activement exploitées sont détectées.