La « .NET » : que se passera-t-il lorsque .NET 8 et .NET 9 ne bénéficieront plus de correctifs ?

La version courte

Une seule date. Deux frameworks. Aucun correctif par la suite.

Le 10 novembre 2026, Microsoft mettra fin, le même jour, au support d’ .NET 8 (la version actuelle à support à long terme) et d’ .NET 9 (la version actuelle à support standard). Il ne s’agit pas d’une coïncidence de calendrier que vous pouvez ignorer. C’est la date à laquelle les deux cycles de mise à jour prendront fin, de manière définitive, pour toutes les applications qui fonctionnent encore sous ces versions.

‍

Si votre entreprise utilise .NET 8 ou .NET 9 en environnement de production, ce guide vous explique en détail ce que la « fin du support » implique concrètement, pourquoi les équipes soumises à une réglementation ont tendance à en ressentir les effets en premier lieu au niveau de la conformité et des assurances plutôt qu’à la suite d’une faille de sécurité, ainsi que les deux options réalistes qui s’offrent à vous : migrer vers .NET 10 ou combler cette lacune grâce à un support de sécurité continu.

‍

Ce guide aborde les thèmes suivants : ce que la « fin du support » implique réellement, pourquoi les risques liés à la conformité et aux assurances apparaissent généralement avant même qu’une violation ne se produise, comment un seul framework non mis à jour aggrave les risques pour l’ensemble des systèmes qui s’appuient sur lui, et les deux voies pour éviter le précipice, y compris un plan en 90 jours.

• 10 novembre 2026 : dernier jour où Microsoft publiera des correctifs de sécurité pour .NET 8 et .NET 9
• Deux frameworks dont la prise en charge prend fin le même jour : une version LTS et une version STS simultanément
• 56 vulnérabilités CVE ont été révélées après la fin du support d'.NET 6 et ont été corrigées dans NES pour .NET 6

‍

Pourquoi ce délai est inhabituel

Les versions LTS et STS n'arrivent généralement pas à expiration en même temps.

Le calendrier de publication des versions de l'.NET de Microsoft est conçu pour répartir les risques : les versions à support à long terme (LTS), comme .NET 8, bénéficient de trois ans de correctifs, tandis que les versions à support standard (STS), comme .NET 9, en bénéficient pendant 18 mois ; ainsi, une version STS cessait d'être prise en charge six mois avant la version LTS qui l'avait précédée.

‍

Le 10 novembre 2026 marque la première date à laquelle ce décalage disparaît. .NET 8 (commercialisé en novembre 2023) et .NET 9 (commercialisé en novembre 2024) atteignent tous deux la fin de leur prise en charge le même jour calendaire, car Microsoft a prolongé la durée de la prise en charge STS de 18 à 24 mois en septembre 2025, à compter d’ .NET 9. La fin du support d’ .NET 9 a ainsi été repoussée du 12 mai 2026 à la date à laquelle la période de trois ans d’ .NET 8 prendra fin.

‍

Concrètement, cela signifie que les équipes qui répartissent les risques en utilisant à la fois les deux dernières versions (une stratégie courante et jusqu’alors raisonnable) ne bénéficient d’aucun avantage lié à l’échelonnement au cours de ce cycle. Quelle que soit la composition actuelle de votre parc .NET 8/.NET 9, l’ensemble doit faire l’objet d’un plan pour cette même date. Et ce ne sera pas la dernière fois non plus. Conformément à la politique de 24 mois, la prochaine version STS, .NET 11, devrait voir son support prendre fin en même temps que celui d’ .NET 10, en novembre 2028.

‍

La fin du support n’est pas un phénomène nouveau en soi : .NET 6 a atteint la fin de son support le 12 novembre 2024, six mois après .NET 7. Les équipes qui ont considéré cette date comme une échéance « souple », en partant du principe que Microsoft ou l’écosystème la prolongeraient, ou que les vulnérabilités (CVE) non corrigées sur un environnement d’exécution en fin de vie ne retiendraient pas l’attention, ont passé l’année suivante à expliquer ce risque non corrigé aux auditeurs, aux assureurs et, dans certains cas, aux clients. Le 10 novembre 2026 marque cette même date butoir, avec une surface d'exposition deux fois plus importante.

Ce que la « fin du support » ne signifie pas

Cela ne signifie pas pour autant que .NET 8 ou .NET 9 cessent de fonctionner. Les applications continuent de s'exécuter exactement comme la veille. C'est ce qui fait qu'il est facile, en interne, de sous-estimer l'importance de cette échéance : rien ne semble ne plus fonctionner le 11 novembre. Les changements sont plus discrets, mais, pour la plupart des organismes soumis à une réglementation, ils ont des conséquences plus importantes. Nous aborderons ce sujet dans la suite de cet article.

‍

Qu'est-ce qui va réellement changer le 10 novembre ?

Les mises à jour cessent. Les failles, elles, persistent.

Les chercheurs en sécurité et les pirates ne cessent de rechercher des vulnérabilités dans « .NET » (les versions en fin de vie) simplement parce que Microsoft a cessé de les corriger. De nouveaux CVE affectant les chemins de code d’ .NET 8 et d’ .NET 9 continueront d’être découverts. La seule chose qui change, c’est qu’il n’y a plus de correctif officiel. Le 10 novembre est un « Patch Tuesday » (mardi de correctifs), et Microsoft publie généralement une dernière version d’un produit en fin de vie lors de son dernier « Patch Tuesday ». Toute vulnérabilité divulguée après cette date ne bénéficiera d’aucun correctif de la part de Microsoft. L’équipe de sécurité de HeroDevs appelle cela le « problème de l’éternité » : une fois qu’un environnement d’exécution arrive en fin de vie, aucune vulnérabilité nouvellement divulguée le concernant ne pourra être corrigée.

‍

Le flux de correctifs ne se limite pas au runtime. Une installation d’ .NET 8 ou d’ .NET 9 se compose de quatre éléments, qui ne bénéficieront plus de correctifs : le runtime .NET , le framework partagé ASP.NET Core, le runtime Windows Desktop pour WPF et Windows Forms, ainsi que le SDK .NET , y compris MSBuild. .NET 6 montre à quoi cela ressemble après la fin du support. Les correctifs fournis par HeroDevs dans NES pour .NET 6 ont été intégrés à chacune de ces composantes : un déni de service par décompression WebSocket et une exposition du socket de diagnostic Linux dans le runtime (6.0.44), un déni de service du flux de contrôle HTTP/3 dans Kestrel (6.0.45), des écritures hors limites de la mémoire dynamique dans le rendu des polices et des glyphes WPF (6.0.44), ainsi qu’un correctif de l’usurpation de nom de fichier de téléchargement MSBuild et une vérification de l’origine des observateurs dotnet dans le SDK (6.0.45 et 6.0.46).

Quatre conséquences concrètes

• Les outils de détection des vulnérabilités continuent de vous signaler des problèmes, indéfiniment. Vos outils SCA et de gestion des vulnérabilités continueront de mettre en évidence des CVE affectant les versions 8 et 9 d’ .NET , et contrairement à un environnement d’exécution pris en charge, aucune d’entre elles ne passera jamais à l’état « corrigée ». Chaque analyse effectuée après le 10 novembre vient s’ajouter à un arriéré qui ne cesse de s’accumuler.
• Les scanners peuvent également passer à côté de véritables vulnérabilités. Microsoft ne publie pas de CVE ni de correctifs pour les versions en fin de vie d’ .NET; ainsi, un nouveau CVE ne répertorie que les versions prises en charge comme étant concernées, et un scanner effectuant une comparaison avec cet enregistrement n’aura rien à signaler concernant .NET 8 ou .NET 9. Le CVE-2025-55315, la faille de « request smuggling » notée 9,9 dans le serveur Kestrel d’ASP.NET Core et divulguée le 14 octobre 2025, en est un exemple : .NET 6 était vulnérable, le CVE ne le mentionnait pas et Microsoft n’a pas publié de correctif. HeroDevs a fourni le correctif dans NES pour .NET 6.0.39 trois jours plus tard.
• Les scores de gravité ne sont pas figés. Une vulnérabilité CVE qui semblait de faible priorité selon un score CVSS de 4 ou 5 peut devenir urgente du jour au lendemain si elle est ajoutée au catalogue des vulnérabilités connues pour être exploitées (KEV) de la CISA ou si son score EPSS de probabilité d’exploitation grimpe en flèche, et cette reclassification peut intervenir des années après la divulgation initiale. Sur un environnement d’exécution pris en charge, cela déclenche simplement un cycle de correctifs. Sur un environnement d'exécution en fin de vie (EOL), il n'y a pas de correctif à appliquer.
• Les vulnérabilités de faible gravité peuvent en entraîner d'autres de gravité élevée. Un problème mineur au niveau d'un composant peut devenir le chaînon manquant d'une chaîne d'attaque en plusieurs étapes lorsqu'il est combiné à un autre élément de votre infrastructure. Le score CVSS individuel ne reflète jamais cette combinaison ; seule votre propre analyse des risques le fait, et les auditeurs s'attendent de plus en plus à ce que cette analyse soit documentée.

Ce phénomène n'est pas propre à .NET. Chaque écosystème open source comporte une longue liste de paquets dont le cycle de vie est déjà terminé, qui présentent des vulnérabilités CVE connues et pour lesquels aucun correctif n'est prévu en amont. .NET 8 et .NET 9 s'apprêtent à ajouter deux environnements d'exécution très répandus à cette liste, le même jour, à l'échelle de l'entreprise.

‍

C'est là que ça fait vraiment mal

C'est généralement lors d'un audit ou d'un renouvellement que la facture arrive, et non à la suite d'une violation.

La plupart des équipes perçoivent le risque lié à la fin de vie (EOL) comme une menace du type « on risque de se faire pirater ». Pour les organisations soumises à une réglementation, le risque le plus immédiat réside dans le fait que l'utilisation de logiciels dont le support a pris fin vous met discrètement en situation de non-conformité par rapport aux cadres réglementaires auxquels vous devez déjà vous conformer, et ce, à un moment que vous ne maîtrisez pas.

L'assurance cyber suit la même logique

Les assureurs ont directement intégré ce risque dans leurs tarifs. Le rapport 2023 de Coalition sur les sinistres liés aux cyberattaques a révélé que les organisations utilisant des logiciels en fin de vie avaient trois fois plus de risques d’être victimes d’un incident de sécurité, quelle que soit la taille de l’entreprise, et que les assurés présentant ne serait-ce qu’une seule vulnérabilité critique non corrigée avaient 33 % plus de chances de déposer une demande d’indemnisation.

‍

Les assureurs peuvent refuser ou limiter les demandes d’indemnisation liées à des logiciels en fin de vie (EOL) par plusieurs moyens : des exclusions expresses qui s’appliquent indépendamment de toute négligence, la résiliation du contrat si la demande d’assurance comportait des informations erronées concernant les contrôles de sécurité, et des clauses de garantie qui annulent la couverture lorsqu’une violation implique un composant qui n’est plus pris en charge. De nombreuses polices ne couvrent par ailleurs la restauration que dans l’état antérieur à l’incident, et non une mise à niveau ; ainsi, la stratégie consistant à dire « nous réparerons les dégâts après la violation » n’est pas prise en charge par l’assurance.

‍

La solution pour sortir de cette impasse

Les auditeurs et les souscripteurs n'exigent pas que vous soyez à jour. Ils exigent que vous disposiez d'un soutien.

Voici le détail qui échappe à la plupart des équipes sous la pression des délais : aucun des frameworks cités ci-dessus n'impose en réalité d'utiliser « la dernière version ». Ils exigent simplement que vous puissiez prouver que le fournisseur assure le support et s'engage à fournir des correctifs pour la version que vous utilisez. Il s'agit là d'un critère moins contraignant qu'une migration complète, et c'est précisément ce critère que le support étendu, garanti par le fournisseur, est conçu pour satisfaire.

‍

Ce que les assureurs et les auditeurs acceptent généralement :

• Un contrat de support signé précisant le composant et la version concernés
• Un compte rendu documenté et daté des mesures correctives apportées au CVE pour cette version
• Une lettre d'attestation du fournisseur confirmant l'étendue et la fréquence de cette assistance

En d’autres termes, les risques liés à la conformité et à l’assurance décrits ci-dessus ne sont pas résolus simplement en achevant une migration avant le 10 novembre. Ils sont résolus en disposant d’un cycle de correctifs pris en charge, quel que soit le système que vous utilisez et quel que soit le calendrier que vous avez prévu. Le véritable choix consiste à migrer selon un calendrier réaliste et, dans l’intervalle, à transformer cette période de transition en une relation de support documentée et vérifiable.

‍

Vos options réalistes

Passer à .NET e 10, à Bridge avec prise en charge étendue, ou aux deux.

Toute organisation utilisant .NET 8 ou .NET 9 en production doit actuellement choisir entre ces deux voies, que ce choix ait été formulé explicitement ou non. La plupart des entreprises finissent par adopter les deux approches : migrer les applications qui peuvent réellement l'être et mettre en place des solutions de transition pour celles qui ne le peuvent pas.

Option A : Migration vers Windows 10 ( .NET )

.NET La version 10 est la version LTS actuelle et constitue la destination à long terme prévue pour tout ce qui fonctionne encore sous .NET 8 ou .NET 9. Les notes de mise à jour de Microsoft mentionnent des améliorations des performances JIT et d’exécution, une prise en charge étendue de la cryptographie post-quantique, le protocole TLS 1.3 moderne sur toutes les principales plateformes, la possibilité pour les applications console de créer nativement des images de conteneurs sans Dockerfile, ainsi que des mises à jour d’Entity Framework Core 10, notamment la recherche vectorielle et la prise en charge native du format JSON. Ces fonctionnalités justifient à elles seules la mise à niveau, qu’il y ait une date butoir ou non. Les mises à niveau des applications d’entreprise prennent encore systématiquement plus de temps que ce que les équipes avaient initialement prévu, en particulier lorsque les dépendances transitives, la compatibilité des bibliothèques tierces et les tests de régression entrent en ligne de compte. Si la migration est réalisable dans les délais fixés par votre politique de conformité, il s’agit là de la bonne voie à suivre. Si ce n’est pas le cas, la voie B propose une alternative.

Parcours B : Pont avec « Never-Ending Support (NES) » pour .NET

NES pour .NET est une solution de remplacement sécurisée et prête à l'emploi pour le runtime .NET 6, 8 ou 9, qui n'est plus pris en charge. Aucune modification du code n'est nécessaire. Elle rétablit le flux de correctifs pris en charge que recherchent les auditeurs et les assureurs, tout en vous permettant de mener votre migration selon un calendrier que vous contrôlez vous-même, plutôt que selon celui imposé par Microsoft.

• Une visibilité directe sur le processus de sécurité de l’ .NET . HeroDevs est un sponsor de la Fondation .NET et participe au groupe de sécurité .NET aux côtés de Microsoft, Red Hat, IBM et Canonical, groupe chargé de coordonner la publication des correctifs avant leur divulgation publique et la publication simultanée des versions d’ .NET . Les membres reçoivent les correctifs source environ une semaine avant leur divulgation publique ; ainsi, les versions NES pour .NET sont publiées le même « Patch Tuesday » que celles de Microsoft.
• Sa capacité à mener à bien cette tâche a déjà été démontrée. NES ( .NET ) a publié des correctifs pour 62 vulnérabilités CVE réparties sur neuf versions d’ .NET 6, dont 56 ont été révélées après que Microsoft a cessé de publier des correctifs pour .NET 6.
• Aucune migration vers une nouvelle plateforme n'est nécessaire. Le comportement d'exécution et le modèle de déploiement restent identiques, tant sous Windows que sous Linux. La seule différence, c'est que les correctifs continuent d'être publiés.
• Déclarations OpenVEX lisibles par vos scanners. HeroDevs publie des déclarations OpenVEX avec NES pour les versions « .NET » ; ainsi, les scanners indiquent quelles vulnérabilités CVE sont corrigées par une version et lesquelles ne sont pas concernées, au lieu de fournir une liste illimitée de résultats concernant un environnement d'exécution en fin de vie.
• Soutenu par des investissements continus dans l’écosystème. Le « Open Source Sustainability Fund » de HeroDevs, doté de 20 millions de dollars, soutient les responsables de maintenance au sein des différents écosystèmes open source, notamment .NET.

‍

En faire un plan

Un calendrier réaliste jusqu'au 10 novembre.

Les équipes qui gèrent bien cette situation n'attendent pas qu'une décision unique de « migration ou de passerelle » soit prise pour l'ensemble du portefeuille. Elles procèdent à un triage application par application, selon un calendrier court et précis. Voici une structure viable, quelle que soit la marge de manœuvre dont vous disposez au moment de vous lancer.

Étape 1 : État des lieux (semaines 1 à 2)

• Répertoriez toutes les applications de production fonctionnant sous « .NET 8 » ou « .NET 9 », y compris les outils internes et les systèmes fournis par des fournisseurs.
• Indiquez celles qui traitent des données réglementées (informations médicales protégées, données des titulaires de carte, informations d'identification personnelles) ou qui relèvent du périmètre d'audit SOC 2/ISO 27001
• Remarque : celles qui ont déjà mis en place un plan de migration vers .NET e 10, avec un personnel dédié

Étape 2 : Prendre une décision pour chaque candidature (semaines 3 à 4)

• Procéder à la migration si le projet de mise en conformité avec l'.NET e 10 est clairement défini, dispose des ressources nécessaires et peut raisonnablement être mené à bien avant la date limite.
• Prévoir une solution de transition avec la NES si le calendrier de migration s'étend au-delà du 10 novembre, si l'application est susceptible d'être mise hors service plutôt que réécrite, ou s'il est nécessaire de garantir dès maintenant la conformité tandis que les travaux de migration se poursuivent en parallèle

Étape 3 : Mise en œuvre et documentation (jusqu'au 10 novembre)

• Pour les candidats à la migration : délimitez le périmètre, désignez les responsables et assurez le suivi par rapport à l'échéance, comme pour tout autre projet axé sur la conformité.
• À l'attention des candidats au programme « Bridge » : veillez à mettre en place un accord de soutien signé et un relevé des mesures correctives CVE avant le 10 novembre, et non après. Il s'agit du document qui vous sera demandé lors de votre prochain audit ou du renouvellement de votre politique.
• Informez brièvement les services chargés de la conformité et de la sécurité, ainsi que, le cas échéant, votre courtier en cyberassurance, du plan prévu pour chaque application, et pas seulement pour celles qui ont déjà été migrées.

Étape 4 : Après le 10 novembre

• Vérifiez que toutes les applications .NET 8/9 restantes ont soit été migrées, soit font l'objet d'un contrat de support en vigueur. Il n'existe aucune autre situation susceptible de satisfaire un auditeur.
• Poursuivre les travaux de migration des applications reliées par une solution de transition selon le calendrier initialement prévu pour cette solution, plutôt que de laisser la mention « pris en charge » devenir une solution définitive.

‍

La place de HeroDevs

Si une candidature ne respecte pas la date limite, c'est là qu'intervient le programme NES « .NET ».

Vous n'avez pas besoin d'avoir tout mis au point avant de nous contacter. La plupart des échanges commencent par une seule application ou quelques-unes : celles pour lesquelles la migration ne sera manifestement pas terminée à temps, ou pour lesquelles un contrat d'assistance signé doit être en place avant votre prochain audit ou le renouvellement de votre police d'assurance, selon la première de ces deux échéances.

Discutez avec HeroDevs de la NES pour .NET

Correctifs sécurisés et prêts à l'emploi pour .NET s 6, 8 et 9. Aucune modification du code, aucune migration vers une autre plateforme, et développés par une équipe ayant une visibilité directe sur le processus de divulgation du groupe de sécurité d’ .NET .

‍

Obtenir un devis personnalisé

‍

Sources et méthodologie

Ce guide est fourni à titre d'information générale et ne constitue en aucun cas un conseil juridique ou en matière de conformité. Les organisations soumises aux normes PCI DSS, HIPAA, SOC 2, ISO 27001 ou à d'autres cadres réglementaires doivent vérifier leurs obligations spécifiques, y compris les détails des exigences en vigueur et leurs dates d'entrée en vigueur, auprès de leurs propres équipes chargées de la conformité, des affaires juridiques et de l'audit avant de se fier à ce guide.

• Microsoft, « Annonce d’ .NET s 10 », «.NET 8 et .NET 9 arriveront en fin de support le 10 novembre 2026 », «.NET : les versions STS sont prises en charge pendant 24 mois » (16 septembre 2025) et « Annonce du groupe de sécurité .NET » (14 octobre 2025), blog.NET .
• Coalition, Inc., Rapport 2023 sur les sinistres liés à la cybersécurité, tel que publié de manière indépendante par Businesswire (mai 2023) : les organisations présentant des vulnérabilités critiques non corrigées auraient 33 % plus de risques de faire l'objet d'un sinistre lié à la cybersécurité ; l'utilisation de logiciels en fin de vie serait associée à un risque d'incident trois fois plus élevé.
• Ministère américain de la Santé et des Services sociaux, règle de sécurité HIPAA, 45 CFR §164.308(a)(1)(ii)(A) et (B).
• ISO/IEC 27001:2022, annexe A, mesure de contrôle 8.8 (Gestion des vulnérabilités techniques).
• Catalogue des vulnérabilités connues exploitées (KEV) de la CISA; système de notation des prédictions d'exploitation (EPSS) de FIRST.org.
• HeroDevs, « HeroDevs rejoint la Fondation .NET pour sécuriser et développer l'écosystème open source » et la rubrique « Sponsor Spotlight » de la Fondation .NET (dotnetfoundation.org) : Fonds de pérennité de l'open source de 20 millions de dollars et participation au groupe de sécurité « .NET ».
• Notes de mise à jour de HeroDevs NES pour .NET 6.0.x: 62 vulnérabilités CVE corrigées entre les versions 6.0.38 (4 juin 2025) et 6.0.46 (9 septembre 2026), dont 56 ont été révélées après la fin du support d'.NET 6.
• HeroDevs, « FAQ sur le CVE-2025-55315, le CVE noté 9,9 dans ASP.NET Core » (5 novembre 2025).

‍