Tem muito barulho errado em cima do prazo do Secure Boot em junho de 2026. A leitura apressada parece dramática demais: como se um monte de PCs Windows fosse simplesmente parar de funcionar agora.
Não é isso que a Microsoft está dizendo.
O problema real é mais traiçoeiro. A máquina pode continuar ligando normalmente e recebendo update mensal, mas ficar sem as próximas proteções de boot se ainda estiver presa aos certificados de 2011. E, quando esse atraso encontra firmware velho, parque misto e BitLocker ativo, o assunto sai da documentação e vira problema de operação.
O que vence em junho de 2026 de verdade
A Microsoft está trocando os certificados de Secure Boot emitidos em 2011 por versões de 2023. Entre os marcos mais importantes estão:
- Microsoft Corporation KEK CA 2011: expira em 24 de junho de 2026
- Microsoft UEFI CA 2011: expira em 27 de junho de 2026
- Microsoft Windows Production PCA 2011: expira em 19 de outubro de 2026
Esses certificados fazem parte da cadeia de confiança usada antes do Windows subir. É por isso que o tema importa: não é “só mais um detalhe de update”. É a base que permite validar boot manager, bancos do Secure Boot, listas de revogação e correções futuras contra falhas de boot.
O que não acontece hoje
Esse é o ponto que mais vale fixar: o Windows não deixa de inicializar automaticamente só porque o prazo chegou.
A própria Microsoft diz que dispositivos não atualizados podem continuar iniciando normalmente e recebendo updates padrão do Windows. O que muda é outra coisa: esses dispositivos podem deixar de receber novas proteções de Secure Boot para componentes de boot.
Na prática, o PC segue vivo, mas vai ficando para trás justamente na camada que deveria proteger o começo da partida.
Onde a dor operacional aparece de verdade
Se fosse só um relógio correndo no calendário, o tema seria bem menor. O problema é que a transição não é totalmente neutra em ambientes antigos.
A documentação da Microsoft cita cenários em que firmware desatualizado ou incompatibilidades na aplicação dos certificados podem gerar:
- erro de validação do Secure Boot
- prompt de recuperação do BitLocker
- loop de recovery
- travamento na inicialização
- falha de boot
É por isso que a recomendação oficial insiste em atualizar firmware antes, testar com piloto real e não empurrar tudo no escuro.
Como saber se o seu parque ainda está atrasado
A leitura útil aqui não é “Secure Boot está ligado ou desligado?”. A Microsoft pede sinais mais específicos de prontidão:
- status do Secure Boot indicando que o dispositivo não foi atualizado
- Event ID 1801 no log do sistema
- Event ID 1795 em cenários com falha
- valor de registro UEFICA2023Status diferente de Updated
Para usuário final, o caminho mais simples é olhar o Windows Security > Device security > Secure Boot e conferir o texto do status, não só a cor do selo.
Para times de infra, a recomendação é inventariar fabricante, modelo, BIOS/firmware, status do Secure Boot e sinais de evento antes do rollout amplo.
O checklist que faz sentido nesta semana
Se você cuida de endpoints Windows, o movimento mais seguro agora é este:
1. Descobrir onde ainda existem certificados de 2011
Sem inventário, a operação vai trabalhar no escuro. O primeiro passo é saber quais máquinas ainda não fizeram a transição para a cadeia de 2023.
2. Atualizar firmware OEM antes de mexer no resto
Essa parte aparece com força nas orientações da Microsoft por um motivo simples: muito problema de transição nasce em firmware antigo.
3. Fazer piloto com parque real
Não adianta validar só nas máquinas “bonitinhas”. O piloto precisa incluir:
- fabricantes diferentes
- versões diferentes de firmware
- máquinas com BitLocker ativo
- cenários de reboot natural
4. Observar se houve reboot pendente e atualização completa
A Microsoft explica que a tarefa agendada roda em etapas e pode levar cerca de 48 horas, além de depender de reinicialização natural para concluir a troca do boot manager.
5. Só depois escalar rollout
Intune, registro, CSP e GPO entram depois. Se a base ainda tem firmware inconsistente, automatizar cedo demais só acelera o estrago.
Por que isso conversa tão rápido com BitLocker
BitLocker não entra nessa história como “culpado”. Ele entra como consequência previsível.
Quando a cadeia de boot muda, o ambiente de confiança muda junto. Se o parque já está envelhecido, heterogêneo ou mal documentado, a chance de o BitLocker pedir recuperação sobe — e aí o problema deixa de ser técnico apenas. Vira fila de suporte, usuário travado e corrida atrás de recovery key.
Por isso o tema interessa menos a quem pensa em “notícia de Windows” e mais a quem pensa em custo operacional.
O resumo honesto
O prazo do Secure Boot em junho de 2026 não é o fim do seu parque Windows. Mas também não é um detalhe para ignorar.
O risco real é continuar com máquinas que ligam normalmente, mas perdem a capacidade de acompanhar as próximas proteções de boot. E, quando a correção chega tarde num ambiente com firmware velho e BitLocker sensível, a conta costuma vir em forma de suporte, recovery e rollout quebrado.
Se o seu ambiente é misturado, antigo ou mal inventariado, esse é o tipo de assunto que vale resolver antes de virar chamado em lote.
Fontes
- Microsoft Support — Windows Secure Boot certificate expiration and CA updates
- Microsoft Learn — Update Secure Boot Certificates for Windows Devices
- Microsoft Support — Secure Boot Certificate updates: Guidance for IT professionals and organizations
- Malwarebytes — Your Windows PC has a security deadline in June 2026
