Il 10 novembre 2026 Microsoft smette di rilasciare aggiornamenti di sicurezza per due versioni di .NET nello stesso giorno: .NET 8 e .NET 9. Dopo quella data, nessuna vulnerabilità scoperta nella piattaforma verrà corretta in nessuna delle due versioni. Se il tuo sistema di contabilità, il tuo punto vendita o il tuo ERP è costruito su una di esse — e nel mercato saudita molti lo sono — hai meno di due mesi per decidere dove andare. Per la maggior parte delle aziende la destinazione giusta è .NET 10, supportato fino al 14 novembre 2028, e non .NET 11, la cui prima release candidate è uscita appena due giorni fa.

Cosa è successo l'8 settembre

L'8 settembre 2026 Microsoft ha annunciato che .NET 11 ha raggiunto la Release Candidate 1, con una licenza di supporto go-live: Microsoft supporta ufficialmente il suo utilizzo in produzione reale prima dell'uscita della versione finale. Lo stesso giorno sono usciti i consueti aggiornamenti di manutenzione per .NET 10, .NET 9 e .NET 8.

Questa è la notizia tecnica. La notizia che conta per il titolare di un'azienda si trova su una pagina completamente diversa: la pagina ufficiale della politica di supporto, aggiornata lo stesso giorno, che dice chiaramente che .NET 8 e .NET 9 escono dal supporto il 10 novembre 2026. L'annuncio patinato del rilascio si prende l'attenzione; la riga che ti costa soldi veri è scritta in una tabella noiosa.

Perché una versione con "supporto a lungo termine" resta senza supporto

Microsoft rilascia una versione principale di .NET ogni novembre. Le versioni pari hanno supporto a lungo termine e ricevono tre anni di patch gratuite; le versioni dispari hanno supporto standard e ne ricevono due.

.NET 8 è uscito il 14 novembre 2023, quindi i suoi tre anni scadono a novembre 2026. .NET 9 è uscito il 12 novembre 2024, quindi i suoi due anni scadono più o meno nello stesso momento. Ecco perché entrambe cadono il 10 novembre. È qui che i team vengono colti di sorpresa: "supporto a lungo termine" non significa supporto per sempre. Significa tre anni contati dal giorno del rilascio, e buona parte di quel tempo è già trascorsa senza che nessuno ci facesse caso.

La destinazione giusta è .NET 10, non .NET 11

La reazione istintiva a una notizia del genere è "allora aggiorniamo alla più recente". Per la maggior parte dei sistemi aziendali è la scelta sbagliata, e il motivo è nella stessa tabella di supporto.

.NET 10 è uscito l'11 novembre 2025, è una versione con supporto a lungo termine ed è supportato fino al 14 novembre 2028. Un solo aggiornamento ti garantisce poco più di due anni di stabilità senza riaprire la pratica. .NET 11 è una versione dispari, quindi ha solo due anni di supporto standard e uscirà dal supporto prima di .NET 10, pur essendo più recente. Aggiornare a una versione più nuova che scade prima non è un aggiornamento: è un rinvio con una fattura in più allegata.

C'è una seconda considerazione. La stessa release candidate di .NET 11 è supportata solo fino al 13 ottobre 2026, perché è una build di transizione da cui ci si aspetta che tu passi oltre: alla candidate successiva e poi alla versione di novembre. Chi legge "go-live" come un invito a installare una release candidate in un sistema di contabilità e lasciarla lì si è iscritto a un ciclo di aggiornamenti mensile invece di sfuggirne.

La regola pratica per un'azienda che usa software contabile o operativo: punta sempre alla versione pari con supporto a lungo termine. Lascia le versioni dispari ai team di prodotto che aggiornano di continuo e vogliono le funzionalità in anticipo.

Cosa porta davvero .NET 11

Perché la decisione si basi sulla conoscenza e non sull'evitamento, ecco cosa contiene la release candidate. In C#, la versione 15 ha stabilizzato gli union type, un modo più chiaro per esprimere un valore che può assumere più di una forma, come un'operazione che riesce oppure fallisce per un motivo specifico. Negli strumenti, il comando dei test ha migliorato la gestione delle applicazioni mobili e ha aggiunto controlli a livello di esecuzione.

Nella pubblicazione dei container, la generazione delle immagini è ora riproducibile ed evita di ricaricare i layer già esistenti, il che riduce i tempi di distribuzione e rende più facile verificare ciò che hai rilasciato. Nella gestione dei pacchetti, aggiornare pacchetti con vulnerabilità note ora funziona anche quando gli avvisi sono trattati come errori: un vecchio intoppo che costringeva i team a disattivare il controllo di sicurezza solo per far passare una build. In ASP.NET Core sono state finalizzate le API di rinnovo dell'autenticazione di SignalR, e i circuiti di Blazor Server ora aggiornano il proprio stato dopo un rinnovo invece di mantenere un'identità obsoleta. Sui sistemi Unix è arrivata la segnalazione dei crash in-process, cioè diagnostica migliore quando un server cade alle tre di notte.

Sono miglioramenti reali. Nessuno di essi compensa il rischio di far girare un sistema finanziario su una versione che scade prima dell'alternativa.

Perché questa è una questione di conformità, non tecnica

Usare una piattaforma che non riceve più patch di sicurezza non è una questione di preferenze ingegneristiche. La Legge sulla protezione dei dati personali (PDPL) obbliga ogni organizzazione che tratta dati dei clienti ad applicare misure di protezione adeguate, e qualsiasi revisione di sicurezza seria chiederà quale versione della piattaforma usi e quando termina il suo supporto. "Siamo su una versione uscita dal supporto otto mesi fa" non è una risposta che puoi difendere davanti a un revisore, a un cliente aziendale che ti invia un questionario di sicurezza prima di firmare o a un assicuratore dei rischi informatici.

Lo stesso vale per i sistemi di fatturazione elettronica collegati alla piattaforma Fatoora. Un sistema che firma digitalmente le fatture e le trasmette a un'autorità governativa deve poggiare su una piattaforma che riceve ancora patch crittografiche. Non è un dettaglio interno: fa parte della catena di fiducia su cui si basa la tua fattura.

Un piano d'azione da qui a novembre

  • Questa settimana: scopri a che punto sei. Chiedi al tuo fornitore o al tuo team tecnico un inventario della versione di .NET dietro ogni sistema che usi, compresi i piccoli strumenti interni e i servizi in background a cui nessuno pensa. Su un server lo mostra dotnet --list-runtimes; nel progetto stesso è la voce del framework di destinazione nel file di progetto.
  • La prossima settimana: fai il triage. Segna tutto ciò che è su .NET 8 o precedente e tutto ciò che è su .NET 9. Ciò che è già su .NET 10 è al sicuro fino al 2028. Ciò che è su .NET 6 o 7 è fuori supporto da anni e richiede un intervento urgente, non una pianificazione.
  • Entro due settimane: leggi le breaking change. Microsoft pubblica un elenco di breaking change per ogni versione. Passare da 8 a 10 di solito è semplice, ma leggere prima di iniziare fa risparmiare giorni.
  • Entro un mese: aggiorna prima l'ambiente di test. Cambia il framework di destinazione, compila, esegui i test e poi fai girare il sistema su una copia di dati reali prima di ogni altra cosa.
  • Prima di novembre: distribuisci. Lascia almeno due settimane di margine di sicurezza prima del 10 novembre e non distribuire durante una chiusura di fine mese o in piena stagione di picco delle vendite.
  • Una volta, per sempre. Inserisci oggi il 14 novembre 2028 nel calendario aziendale e stabilisci una regola: ogni aggiornamento va alla versione pari successiva. Così questo passa da sorpresa annuale a voce di bilancio nota.

Se il sistema è stato fornito da un fornitore

Molte aziende non possiedono il codice sorgente; acquistano un sistema già pronto da un fornitore. In questo caso, l'unica email da inviare oggi chiede tre cose: su quale versione di .NET gira il sistema, quando rilascerete una build su .NET 10 e se l'aggiornamento è coperto dal nostro contratto di assistenza o fatturato a parte. Il modo in cui risponde il tuo fornitore ti dice sul prodotto più di qualsiasi presentazione. E un fornitore che non conosce la risposta, o temporeggia, è lo stesso che chiamerai l'11 novembre.

Fonti

  • Microsoft — Announcing .NET 11 Release Candidate 1, 8 settembre 2026: devblogs.microsoft.com
  • Microsoft — politica ufficiale di supporto di .NET e date di fine supporto: dotnet.microsoft.com
  • Microsoft — Breaking change in .NET 11: learn.microsoft.com
  • Autorità saudita per i dati e l'intelligenza artificiale (SDAIA) — Legge sulla protezione dei dati personali (PDPL): sdaia.gov.sa