Tem muito parque Windows que ainda roda com certificados de Secure Boot emitidos em 2011. Isso não quer dizer que todas as máquinas vão morrer em junho de 2026. O problema real é outro: sem a atualização para os certificados de 2023, essas máquinas podem continuar ligando normalmente, mas ficar sem proteção futura nas partes mais sensíveis do boot.
É por isso que esse assunto saiu do canto da documentação e virou pauta de operação. Quando o ambiente está mais antigo, com firmware atrasado e BitLocker ativo, a correção mal planejada pode abrir espaço para prompt de recuperação, loop chato de boot e time de suporte apagando incêndio onde achou que só ia aplicar rotina.
Para quem cuida de Windows em empresa, o recado da Microsoft é bem direto: não é update para empurrar no escuro.
O que vence em junho de 2026 de verdade
A Microsoft publicou um alerta específico para dispositivos Windows que ainda usam certificados de Secure Boot emitidos em 2011. Esses certificados expiram em junho de 2026.
O ponto mais importante aqui é a nuance. Segundo a própria Microsoft, a máquina pode continuar iniciando e recebendo updates normais do Windows mesmo sem a correção. Só que ela pode deixar de receber proteções futuras de Secure Boot para componentes de inicialização, como boot manager e outros elementos de pré-boot.
Ou seja: não é um “seu Windows para de funcionar amanhã”. É pior de um jeito mais silencioso. Você continua rodando, mas vai ficando descoberto justamente na camada que deveria proteger a largada do sistema.
Quem precisa se preocupar mais
Nem todo ambiente vai sentir isso do mesmo jeito. O risco sobe quando aparecem algumas combinações bem conhecidas:
- notebooks e desktops mais antigos
- firmware OEM desatualizado
- parque misturado entre vários fabricantes e gerações
- BitLocker habilitado em volume grande
- pouca visibilidade de inventário sobre estado de boot e firmware
A própria Microsoft cita cenários de maior risco quando a atualização de certificados não encaixa bem no firmware do equipamento. Nesses casos, podem aparecer erros de validação do Secure Boot, travamentos na inicialização, falha de boot e prompt repetido de recuperação do BitLocker.
É o tipo de problema que parece pequeno no anúncio e vira grande quando bate numa frota heterogênea.
Como perceber se seu parque está atrasado
A Microsoft sugere olhar para alguns sinais objetivos, não só para feeling de time:
- status do certificado de Secure Boot indicando que o dispositivo não foi atualizado
- Event ID 1801 no log do sistema
- Event ID 1795
- valor de registro UEFICA2023Status sem o estado Updated
Esse detalhe importa porque muita empresa ainda trata Secure Boot como “ligado ou desligado”, quando o problema agora é mais específico: estar com a cadeia antiga e sem a remediação aplicada.
Se você não tem inventário disso hoje, já é um sinal operacional ruim. Vai ser difícil decidir rollout, piloto e contenção sem saber quantas máquinas estão realmente expostas. É o mesmo tipo de dívida que aparece tarde demais quando o sistema cai, mas o problema começou muito antes do incidente.
O que fazer antes de sair atualizando tudo
O caminho mais saudável não é correr para a massa. É reduzir chance de surpresa.
A ordem sugerida pela Microsoft faz sentido prático:
1. Revisar o parque
Mapeie quais dispositivos ainda usam certificados de 2011 e quais têm sinais de incompatibilidade.
2. Atualizar firmware OEM antes
Esse ponto vale ouro. A documentação fala explicitamente para verificar e aplicar atualização de firmware, especialmente em modelos mais antigos. Firmware melhor reduz incompatibilidade e corta parte do risco de falha na atualização dos certificados.
3. Fazer piloto de verdade
Não é piloto com três máquinas “boas”. O recado é testar com:
- múltiplos OEMs
- versões diferentes de firmware
- dispositivos com BitLocker habilitado
E confirmar três coisas:
- status de atualização aplicado com sucesso
- nenhuma quebra de boot
- nenhum prompt inesperado de recuperação do BitLocker
4. Só depois pensar em rollout
A Microsoft cita deployment por Intune, chaves de registro, CSP e Group Policy. Mas o canal de entrega vem depois da validação. Se a base está torta, automatizar só acelera o problema.
Por que o BitLocker entra nessa conversa tão rápido
Quem já passou por incidente de boot sabe que BitLocker não é o vilão da história. Ele só reage quando enxerga mudança relevante no que protege a confiança de inicialização.
Na documentação de recovery, a Microsoft lembra que o BitLocker pode pedir recuperação em situações como:
- mudança no boot manager
- upgrade crítico de BIOS ou UEFI
- alteração em componentes de startup
- mudanças nos registros de medição usados pelo TPM
Por isso esse tema assusta tanto time de suporte. Quando o ambiente já tem firmware velho, TPM sensível e pouca padronização, uma mudança que mexe com a camada de boot pode transbordar para recovery. E aí o custo não é só técnico. Vira fila de atendimento, usuário travado e operação tentando achar chave de recuperação na pressa. No fundo, é outra forma de trabalho invisível e dependência operacional mal distribuída — bem na linha do que apareceu em quando o sysadmin sai, a empresa descobre o preço do trabalho invisível.
O resumo que interessa para esta semana
Se você administra Windows em empresa, o melhor movimento agora é simples:
- descobrir se ainda existem dispositivos com certificados de 2011
- validar firmware OEM nos modelos mais antigos
- separar um piloto com máquinas reais do parque
- testar especialmente os equipamentos com BitLocker
- só então decidir rollout em escala
O erro seria tratar isso como barulho de documentação ou, no extremo oposto, como catástrofe generalizada. Não é nem uma coisa nem outra. É uma dívida operacional bem concreta, com prazo, que pode ficar invisível até o dia em que o boot resolve cobrar.
Se o seu parque tem cara de colcha de retalhos, vale mexer nisso antes de junho — enquanto ainda dá para errar em ambiente controlado.
