Tem time de infra olhando para essa história de certificados do Secure Boot como se fosse só mais um detalhe de compliance. Não é.
A própria Microsoft vem repetindo que muita máquina vai continuar ligando normalmente mesmo sem receber os certificados novos de 2023. O problema é justamente esse: o parque parece saudável, continua baixando update, mas perde a capacidade de receber parte das proteções futuras da etapa mais sensível do boot.
Na prática, isso mexe com o que roda antes do Windows subir de vez — boot manager, revogações, cadeias de confiança e, em alguns cenários, o comportamento do BitLocker.
o alerta real não é “o PC vai parar”, e sim “ele pode continuar exposto sem parecer quebrado”
No artigo oficial sobre a expiração dos certificados, a Microsoft explica que os certificados de 2011 começam a vencer em junho e outubro de 2026. Os principais pontos são estes:
- o Microsoft Corporation KEK CA 2011 vence em 24 de junho de 2026;
- o Microsoft UEFI CA 2011 vence em 27 de junho de 2026;
- o Microsoft Windows Production PCA 2011 vence em 19 de outubro de 2026.
A empresa diz que máquinas sem os certificados de 2023 ainda podem iniciar normalmente e continuar recebendo updates comuns. Só que elas deixam de acompanhar novas proteções da cadeia de boot: atualização de boot manager, mudanças em DB/DBX, listas de revogação e mitigação de vulnerabilidades de pré-boot.
É o tipo de risco que passa fácil no radar, porque o sintoma não começa com tela preta. Começa com uma falsa sensação de normalidade.
onde o BitLocker entra nessa conta
A parte que mais interessa para operação é que a própria documentação da Microsoft já trata BitLocker recovery inesperado como cenário recorrente dentro do troubleshooting de Secure Boot.
O caso mais leve é o susto de uma vez só: depois da atualização do Secure Boot, o firmware ainda não reporta os valores novos na primeira reinicialização, o Windows tenta resealar o BitLocker, mede uma diferença no boot e pede a chave de recuperação. Na reinicialização seguinte, isso pode normalizar.
Mas existe o caso chato de verdade: quando a máquina entra em recuperação em todo boot. Um dos exemplos oficiais é equipamento com PXE/network boot antes do disco local. Nesse fluxo, o dispositivo mede duas cadeias de confiança diferentes na mesma partida — uma do caminho PXE e outra do boot manager local assinado em 2023 — e o BitLocker não consegue estabilizar a medição.
Em português claro: não é só “update ruim”. Às vezes é a combinação entre ordem de boot, firmware, certificados e política de TPM/PCR.
a Microsoft já teve que corrigir parte desse caminho em updates de 2026
Isso não ficou só no plano teórico.
No update de abril para Windows 11 24H2/25H2 (KB5083769), a Microsoft reconheceu um problema em que alguns dispositivos com configuração pouco recomendada de BitLocker poderiam pedir a chave de recuperação no primeiro restart. O cenário envolvia:
- BitLocker habilitado no volume do sistema;
- política com inclusão explícita de PCR7;
msinfo32mostrando Secure Boot State PCR7 Binding = Not Possible;- presença do certificado Windows UEFI CA 2023 no banco de dados do Secure Boot, mas sem o boot manager de 2023 já efetivamente em uso.
Depois, no update de junho para Windows 11 23H2 (KB5093998), a Microsoft disse que corrigiu um caso em que alguns dispositivos podiam cair em BitLocker Recovery depois da atualização dos arquivos de boot em sistemas com certos ajustes de TPM e PCR7.
Ou seja: o risco não é imaginário, e o próprio Windows já precisou ganhar proteção extra para não empurrar algumas máquinas para a tela de recuperação.
o que vale checar agora, antes da próxima surpresa
Se você administra parque Windows, esse é o tipo de pauta para atacar antes de o usuário abrir chamado com foto da tela azul do BitLocker.
1) confirme se o parque ainda está preso nos certificados de 2011
A Microsoft orienta verificar o status pelo app Windows Security e, em ambiente administrado, também por sinais de inventário, eventos e registro.
No material de troubleshooting, ela cita especialmente:
- existência e progresso de
UEFICA2023Status; - erros associados como
UEFICA2023ErroreUEFICA2023ErrorEvent; - eventos de sistema como 1801, 1795 e, em cenários de incompatibilidade, 1032.
Se você ainda não tem isso no inventário, já é um indício de que o tema está atrasado internamente.
2) atualize firmware antes de empurrar tudo por Windows Update
A Microsoft bate nessa tecla em mais de um documento: firmware antigo aumenta a chance de update não aplicar direito, entrar em retry infinito, gerar boot problemático ou pedir BitLocker recovery.
Esse é um daqueles casos em que o “depois a gente vê BIOS” costuma sair caro.
3) audite política de BitLocker e PCR7
Se sua base ainda usa política com PCR7 incluído explicitamente e há dispositivos com PCR7 Binding = Not Possible, você tem uma combinação que já apareceu em known issue oficial.
Nessa situação, empurrar atualização de boot sem revisar a política é pedir para transformar manutenção em incidente.
4) revise ordem de boot e dependência de PXE
Se a rede/PXE está antes do disco local sem necessidade real, isso pode manter a máquina presa em recovery recorrente mesmo depois de a chave ser digitada.
O troubleshooting oficial manda inverter a ordem de boot, desabilitar PXE quando não for necessário ou garantir que a infra de PXE já use boot loader assinado em 2023.
5) trate a chave de recuperação como pré-requisito operacional
Em cenário saudável, você não deveria descobrir no susto se a recovery key está acessível.
Antes de qualquer rollout maior, faz sentido validar:
- onde a chave está armazenada;
- se o fluxo de acesso pelo time funciona de verdade;
- quais grupos de máquinas ainda dependem de conta local, processo manual ou firmware mais temperamental.
o erro clássico aqui é confundir “continua funcionando” com “está resolvido”
A leitura mais importante das fontes da Microsoft é essa: o vencimento dos certificados de 2011 não significa que todo mundo vai parar de bootar no mesmo dia. O problema é mais traiçoeiro.
O dispositivo continua parecendo normal, mas pode ficar para trás justamente no pedaço que protege o boot, valida mudanças sensíveis e conversa com endurecimento de BitLocker, revogação de componentes vulneráveis e futuras correções de pré-sistema.
Para ambiente pequeno, isso já merece checagem.
Para ambiente grande, isso merece piloto, inventário, firmware e revisão de política — nessa ordem.
um checklist curto para não deixar isso virar incêndio
- mapear máquinas ainda sem evidência de certificados 2023;
- conferir se o task
\Microsoft\Windows\PI\Secure-Boot-Updateexiste e está ativo; - revisar firmware OEM pendente, principalmente em modelos mais antigos;
- auditar BitLocker + PCR7 antes do próximo ciclo maior de updates;
- validar ordem de boot e dependência de PXE;
- garantir acesso real às recovery keys;
- testar em grupo piloto antes de ampliar rollout.
Quem deixar isso para o dia em que a tela de recuperação aparecer vai descobrir tarde demais que o problema nunca foi “o Windows não subiu”. O problema era a cadeia de confiança já estar fora do trilho fazia tempo.
Fontes
- Microsoft Support — Windows Secure Boot certificate expiration and CA updates
- Microsoft Learn — Update Secure Boot Certificates for Windows Devices
- Microsoft Support — Secure Boot troubleshooting guide
- Microsoft Support — April 14, 2026—KB5083769
- Microsoft Support — June 9, 2026—KB5093998
- Microsoft Support — June 23, 2026—KB5095093 Preview
