Em 6 de outubro de 2026, o blog de segurança da Microsoft publicou um texto assinado por Freddy Dezeure, Deputy CISO para a Europa, e por Sesha Mani, diretor de segurança de produto, com um recado desconfortável para quem administra ambiente corporativo. O desafio deixou de ser achar e aplicar correções com rapidez. Passou a ser decidir o que corrigir primeiro, e fazer isso sem parar a operação.
O motivo é de volume. Segundo o texto, o ciclo mensal de atualizações de setembro de 2026 bateu recorde, com perto de mil vulnerabilidades divulgadas para software Microsoft instalado no ambiente do próprio cliente. A empresa pede que esse patamar seja tratado como o novo normal dos próximos meses, e não como um mês fora da curva.
Para uma consultoria de quinze, trinta ou sessenta pessoas, o efeito prático é imediato: a fila de correções ficou maior do que a capacidade de quem cuida da TI. Este artigo trata de como montar o critério de prioridade antes que a fila decida sozinha.
O que a Microsoft comunicou em 6 de outubro
O texto separa dois mundos. Em serviços de nuvem, a maior parte das vulnerabilidades é mitigada pela própria Microsoft, sem nenhuma ação do cliente. Em software instalado no ambiente da empresa — servidor de arquivos, controlador de domínio, aplicação local, equipamento de borda —, a correção continua sendo responsabilidade de quem administra aquele ambiente.
É nesse segundo grupo que o volume cresceu. A Microsoft afirma usar modelos de IA de fronteira para varrer o próprio código, revisando cada achado quanto a validade, severidade e impacto potencial, e diz ter ampliado essa varredura para todos os seus grupos de engenharia. Mais capacidade de busca significa mais falhas encontradas e, por consequência, mais correções publicadas a cada ciclo. A relação de cada mês fica aberta no Security Update Guide da própria Microsoft.
A empresa registra ainda uma característica desses modelos que interessa a qualquer área técnica: eles não são determinísticos. Execuções diferentes, do mesmo modelo ou de modelos distintos, podem devolver resultados distintos. Na prática, a lista de achados tende a crescer e a mudar de forma, não a estabilizar.
O prazo entre a correção e o ataque encurtou
A parte mais acionável do texto é sobre horário. A Microsoft observa que componentes críticos — ela cita controladores de domínio e equipamentos de borda — tradicionalmente são atualizados quando a indisponibilidade incomoda menos: fim de semana, feriado, madrugada de domingo. E recomenda rever essa troca, porque a IA encurtou o intervalo entre a publicação da correção e a exploração da falha. A sugestão é considerar aplicar a correção nesses sistemas em até 24 horas, em vez de esperar a próxima janela de manutenção.
Vale ler com atenção o que isso significa. A recomendação não é atualizar tudo em 24 horas, o que seria irreal e arriscado. É reconhecer que um punhado de sistemas perdeu o direito de esperar, e que todo o resto precisa de uma fila organizada. A Microsoft também insiste que nem toda vulnerabilidade será corrigida em tempo, e que por isso os controles que limitam o que um invasor consegue fazer passam a pesar mais.
O que isso muda na TI para consultorias
Consultorias de gestão, de engenharia, de recursos humanos e de tecnologia carregam uma assimetria conhecida: o ambiente é pequeno, mas o conteúdo é sensível. Em poucos terabytes cabem diagnósticos de clientes, planilhas de custo, estudos de viabilidade, dados de colaboradores de terceiros e propostas em negociação. Quem invade uma consultoria não leva apenas os dados dela, leva os dados da carteira.
Ao mesmo tempo, raramente existe alguém em dedicação integral à TI. A correção compete com entregas de projeto, e perde. O resultado típico que encontramos é um ambiente razoavelmente bem equipado, com atualizações aplicadas de forma irregular: as estações seguem o ciclo automático do Windows, e o servidor, o firewall e a VPN ficam para quando houver tempo. Esses últimos são exatamente os sistemas que a Microsoft pede para tratar em 24 horas.
A TI para consultorias só fica previsível quando essa decisão sai da memória de uma pessoa e entra em uma política escrita. Não é burocracia: é o que permite responder, no meio de um projeto, se uma correção específica pode ou não esperar duas semanas.
Sem inventário não existe prioridade
A orientação de gestão de vulnerabilidades do NCSC, a agência britânica de segurança cibernética, começa por um ponto que costuma ser pulado: entender quais sistemas e softwares existem no ambiente, quem é responsável por cada um e quais vulnerabilidades estão presentes. Sem isso, prioridade é chute.
Na prática, o inventário de uma consultoria precisa responder quatro perguntas por item: onde o sistema está, se ele é acessível pela internet, o que acontece com a operação se ele parar por quatro horas e quem autoriza reiniciá-lo. É o mesmo raciocínio que aplicamos ao inventário de certificados digitais: a lista não é o objetivo, é a condição para decidir.
Ferramentas ajudam a manter essa lista viva em vez de envelhecer em uma planilha. O Microsoft Defender Vulnerability Management mantém inventário de dispositivos e software com as falhas conhecidas associadas, o que troca a pergunta "quantas correções saíram" pela pergunta mais útil: "quais delas afetam equipamento que eu tenho ligado".
Uma política de atualização em três faixas
O modelo que funciona em ambiente pequeno é simples e cabe em uma página. Três faixas, com prazo declarado e responsável nomeado:
- Faixa crítica, até 24 horas. O que está exposto à internet ou controla identidade: firewall, concentrador de VPN, controlador de domínio, servidor de acesso remoto, equipamento de borda. Aqui a janela de manutenção cede lugar ao prazo.
- Faixa relevante, até 7 dias. Servidores internos, servidor de arquivos, aplicações de negócio e banco de dados sem exposição direta. Entram em um piloto de poucos equipamentos antes de alcançar o grupo todo.
- Faixa de rotina, janela mensal. Estações de trabalho e aplicações de apoio, com atualização automática ativada e acompanhamento por exceção, ou seja, olhando apenas o que falhou.
A implantação em etapas é o que impede que uma correção ruim derrube a consultoria inteira. No Intune, isso é configurado com anéis de atualização do Windows, em que um grupo piloto recebe a atualização antes dos demais, com adiamento definido por política. O volume maior de correções não muda esse desenho: aumenta a importância de ele existir.
Uma observação sobre o que não entra na política: software que ninguém usa mais. Desinstalar é mais rápido e mais seguro que corrigir, e é a única medida que reduz a fila de forma permanente.
O que fazer quando a correção não pode entrar agora
Sempre haverá o sistema que não pode ser reiniciado nesta semana, o fornecedor que ainda não publicou a correção e a aplicação antiga que depende de uma versão específica. É para esse caso que serve a defesa em profundidade que a Microsoft enfatiza — limitar o que o invasor consegue fazer, já que a falha vai continuar lá por mais algum tempo.
As medidas que mais rendem em ambiente pequeno são conhecidas: autenticação multifator em todos os acessos administrativos, acesso remoto restrito por política em vez de aberto na internet, separação entre a conta do dia a dia e a conta administrativa, registro de eventos sendo efetivamente olhado e backup com cópias imutáveis e restauração testada. Nenhuma delas corrige a vulnerabilidade. Todas encurtam o que acontece depois.
Vale lembrar que o vetor mais comum não é sofisticado: no caso que tratamos em instaladores falsos que abrem acesso remoto, a entrada foi a instalação voluntária de uma ferramenta por alguém da equipe. Correção em dia não protege de um convite feito pela porta da frente.
Quem assume o risco de não atualizar
Esse é o ponto que o NCSC trata com mais clareza do que a maioria das políticas internas: decidir não atualizar é uma decisão de risco, e precisa ser tomada no nível adequado da organização, dentro da política de gestão de risco, não no improviso de uma terça-feira.
Em uma consultoria, isso se traduz em algo bem concreto. Toda exceção fica registrada com três campos: qual sistema, por que não pode ser atualizado agora e qual medida compensatória está no lugar enquanto isso. A lista é revisada em reunião mensal, com o sócio responsável presente. Exceção sem data de revisão deixa de ser exceção e vira configuração permanente — quase sempre esquecida.
Essa também é a conversa que define o que esperar de quem presta o serviço. Prazo de aplicação por faixa, responsabilidade por aprovar exceção e evidência de que a correção entrou são cláusulas de contrato, não gentilezas. Tratamos desse desenho em o que importa no SLA de TI, e o princípio aqui é o mesmo: prazo sem evidência não é compromisso.
Como a Diversa conduz esse processo
A mecânica de aplicar correção em escala já descrevemos em patches de segurança e atualização de sistemas. O que mudou de 2026 para cá é a quantidade, e quantidade cobra critério.
Nos ambientes que acompanhamos em serviços gerenciados de TI, o inventário é a base: são mais de 2.500 dispositivos monitorados, o que permite dizer em minutos quais clientes têm equipamento afetado por uma falha divulgada hoje. A partir disso valem o prazo por faixa, o piloto antes do grupo todo e o registro de exceção com responsável nomeado. Quando a decisão envolve exposição à internet, identidade ou dado de cliente final, ela entra na consultoria de segurança da informação, com o sócio da consultoria participando da escolha.
Nenhuma política elimina a fila. O que ela faz é garantir que, quando a correção que importa for publicada, ela não fique atrás de dezenas de outras que podiam esperar.