Em 10 de novembro de 2026, a Microsoft deixa de enviar atualizações de segurança para duas versões do .NET no mesmo dia: .NET 8 e .NET 9. Depois dessa data, nenhuma vulnerabilidade descoberta na plataforma será corrigida em nenhuma das duas versões. Se o seu sistema contábil, ponto de venda ou ERP foi construído sobre uma delas — e no mercado saudita muitos foram —, você tem menos de dois meses para decidir para onde vai. Para a maioria das empresas, o destino certo é o .NET 10, com suporte até 14 de novembro de 2028, e não o .NET 11, cujo primeiro release candidate saiu há apenas dois dias.

O que aconteceu em 8 de setembro

Em 8 de setembro de 2026, a Microsoft anunciou que o .NET 11 chegou ao Release Candidate 1, com uma licença de suporte go-live — ou seja, a Microsoft apoia oficialmente seu uso em produção real antes do lançamento da versão final. No mesmo dia, saíram as atualizações de manutenção de rotina para o .NET 10, o .NET 9 e o .NET 8.

Essa é a notícia técnica. A notícia que importa para o dono de uma empresa está em uma página totalmente diferente: a página oficial da política de suporte, atualizada no mesmo dia, que diz com todas as letras que o .NET 8 e o .NET 9 saem do suporte em 10 de novembro de 2026. O anúncio vistoso do lançamento leva a atenção; a linha que custa dinheiro de verdade está escrita em uma tabela sem graça.

Por que uma versão de "suporte de longo prazo" fica sem suporte

A Microsoft lança uma versão principal do .NET todo mês de novembro. As versões pares são de suporte de longo prazo e recebem três anos de correções gratuitas; as ímpares são de suporte padrão e recebem dois.

O .NET 8 foi lançado em 14 de novembro de 2023, então seus três anos vencem em novembro de 2026. O .NET 9 foi lançado em 12 de novembro de 2024, então seus dois anos vencem praticamente no mesmo momento. É por isso que os dois caem em 10 de novembro. É aqui que as equipes são pegas de surpresa: "suporte de longo prazo" não significa suporte para sempre. Significa três anos contados a partir do dia do lançamento, e boa parte desse relógio já correu enquanto ninguém prestava atenção.

O destino certo é o .NET 10, não o .NET 11

A reação automática a uma notícia assim é "então vamos atualizar para a mais nova". Para a maioria dos sistemas empresariais essa é a decisão errada, e o motivo está na mesma tabela de suporte.

O .NET 10 foi lançado em 11 de novembro de 2025, é uma versão de suporte de longo prazo e tem suporte até 14 de novembro de 2028. Uma única atualização garante pouco mais de dois anos de estabilidade sem reabrir o assunto. O .NET 11 é uma versão ímpar, portanto tem apenas dois anos de suporte padrão e ficará sem suporte antes do .NET 10, apesar de ser mais novo. Atualizar para uma versão mais nova que expira antes não é uma atualização — é um adiamento com uma fatura extra anexada.

Há uma segunda consideração. O próprio release candidate do .NET 11 tem suporte apenas até 13 de outubro de 2026, porque é uma build de transição da qual se espera que você saia — para o próximo candidate e depois para a versão de novembro. Quem lê "go-live" como um convite para instalar um release candidate em um sistema contábil e deixá-lo lá se inscreveu em um ciclo mensal de atualizações em vez de escapar de um.

A regra prática para uma empresa que usa software contábil ou operacional: mire sempre na versão par de suporte de longo prazo. Deixe as ímpares para equipes de produto que atualizam continuamente e querem os recursos antes.

O que o .NET 11 realmente traz

Para que a decisão se baseie em conhecimento e não em evasão, eis o que o release candidate traz. No C#, a versão 15 estabilizou os union types — uma forma mais clara de expressar um valor que pode assumir mais de uma forma, como uma operação que ou dá certo ou falha por um motivo específico. Nas ferramentas, o comando de testes melhorou o tratamento de aplicativos móveis e ganhou controles no nível da execução.

Na publicação de contêineres, a geração de imagens agora é reproduzível e deixa de reenviar camadas que já existem, o que reduz o tempo de implantação e facilita auditar o que você entregou. No gerenciamento de pacotes, atualizar pacotes com vulnerabilidades conhecidas agora funciona mesmo quando avisos são tratados como erros — um velho entrave que obrigava as equipes a desativar a verificação de segurança só para fazer uma build passar. No ASP.NET Core, as APIs de renovação de autenticação do SignalR foram finalizadas, e os circuitos do Blazor Server agora atualizam seu estado após uma renovação, em vez de manter uma identidade desatualizada. Os relatórios de falhas em processo chegaram aos sistemas Unix, o que significa diagnósticos melhores quando um servidor cai às três da manhã.

São melhorias reais. Nenhuma delas compensa o risco de rodar um sistema financeiro em uma versão que expira antes da alternativa.

Por que isso é uma questão de conformidade, e não técnica

Rodar uma plataforma que não recebe mais correções de segurança não é uma questão de preferência de engenharia. A Lei de Proteção de Dados Pessoais (PDPL) obriga toda organização que lida com dados de clientes a aplicar medidas de proteção adequadas, e qualquer revisão de segurança séria vai perguntar qual versão da plataforma você usa e quando o suporte dela termina. "Estamos em uma versão que saiu do suporte há oito meses" não é uma resposta que você consiga defender diante de um auditor, de um cliente corporativo que envia um questionário de segurança antes de assinar ou de uma seguradora de riscos cibernéticos.

O mesmo vale para sistemas de faturamento eletrônico conectados à plataforma Fatoora. Um sistema que assina faturas digitalmente e as transmite a uma autoridade governamental precisa estar em uma plataforma que ainda receba correções criptográficas. Isso não é um detalhe interno — faz parte da cadeia de confiança em que sua fatura se apoia.

Um plano de ação daqui até novembro

  • Esta semana — descubra onde você está. Peça ao seu fornecedor ou à sua equipe técnica um inventário da versão do .NET por trás de cada sistema que você usa, incluindo as pequenas ferramentas internas e os serviços em segundo plano em que ninguém pensa. Em um servidor, dotnet --list-runtimes mostra isso; no próprio projeto, é a entrada do framework de destino no arquivo do projeto.
  • Semana que vem — faça a triagem. Marque tudo o que está em .NET 8 ou anterior e tudo o que está em .NET 9. O que já está em .NET 10 está seguro até 2028. O que está em .NET 6 ou 7 está sem suporte há anos e precisa de tratamento urgente, não de um cronograma.
  • Em até duas semanas — leia as breaking changes. A Microsoft publica uma lista de breaking changes para cada versão. Migrar de 8 para 10 costuma ser tranquilo, mas ler antes de começar economiza dias.
  • Em até um mês — atualize primeiro o ambiente de testes. Troque o framework de destino, compile, rode os testes e depois rode o sistema com uma cópia de dados reais antes de qualquer outra coisa.
  • Antes de novembro — implante. Deixe pelo menos duas semanas de margem de segurança antes de 10 de novembro, e não implante durante um fechamento de mês nem em plena temporada de pico de vendas.
  • Uma vez, para sempre. Coloque 14 de novembro de 2028 no calendário da empresa hoje e defina uma regra: toda atualização vai para a próxima versão par. Isso transforma o assunto de uma surpresa anual em uma linha de orçamento conhecida.

Se o sistema veio de um fornecedor

Muitas empresas não são donas do código-fonte; compram um sistema pronto de um fornecedor. Nesse caso, o único e-mail que você envia hoje pergunta três coisas: em qual versão do .NET o sistema roda, quando vocês vão entregar uma versão em .NET 10 e se a atualização está coberta pelo nosso contrato de suporte ou é cobrada à parte. A forma como seu fornecedor responde diz mais sobre o produto do que qualquer apresentação. E o fornecedor que não sabe a resposta, ou enrola, é o mesmo para quem você vai ligar em 11 de novembro.

Fontes

  • Microsoft — Announcing .NET 11 Release Candidate 1, 8 de setembro de 2026: devblogs.microsoft.com
  • Microsoft — política oficial de suporte do .NET e datas de fim de suporte: dotnet.microsoft.com
  • Microsoft — Breaking changes no .NET 11: learn.microsoft.com
  • Autoridade Saudita de Dados e Inteligência Artificial (SDAIA) — Lei de Proteção de Dados Pessoais (PDPL): sdaia.gov.sa