O certificado Microsoft Windows Production PCA 2011, a autoridade que valida a assinatura do boot loader do Windows em todo equipamento com UEFI Secure Boot ativo, expira em 19 de outubro de 2026. A data encerra o calendário de renovação que a Microsoft iniciou em junho e alcança qualquer máquina que ainda confie apenas nas autoridades de 2011 gravadas na firmware. O parque afetado não para de funcionar no dia seguinte, mas perde a capacidade de absorver atualizações de segurança do processo de inicialização — e é essa perda silenciosa que transforma uma tarefa de manutenção em tema de defesa. A ação prioritária das equipes é inventariar o parque, aplicar as autoridades certificadoras de 2023 e documentar as exceções.
O que vence em outubro
A Microsoft detalhou o calendário completo na documentação oficial sobre a expiração dos certificados do Secure Boot. São quatro substituições programadas para 2026, três delas com datas já vencidas desde junho. O quadro resume o que sai de cena e o que entra no lugar:
| Certificado antigo | Vencimento | Sucessor |
|---|---|---|
| Microsoft Corporation KEK CA 2011 | 24 de junho de 2026 | Microsoft Corporation KEK 2K CA 2023 |
| Microsoft UEFI CA 2011 | 27 de junho de 2026 | Microsoft UEFI CA 2023 e Microsoft Option ROM UEFI CA 2023 |
| Microsoft Windows Production PCA 2011 | 19 de outubro de 2026 | Windows UEFI CA 2023 |
O Secure Boot autentica firmware, bootloaders e option ROMs antes de o sistema operacional iniciar. A confiança segue uma hierarquia: a Platform Key, do fabricante do hardware; a Key Enrollment Key (KEK), que autoriza mudanças nos bancos de assinatura; e os bancos DB e DBX, que definem o que pode e o que não pode executar no ambiente UEFI. O certificado de outubro assina o próprio boot loader do Windows, e o sucessor, o Windows UEFI CA 2023, precisa estar presente no DB antes da data-limite. Sem o KEK renovado, a firmware não aceita futuras alterações no DB e no DBX — e é justamente pelo DBX que a Microsoft distribui revogações contra bootkits descobertos.
O risco silencioso do atraso
A consequência do atraso não é uma tela preta. Segundo a Microsoft, equipamentos que não receberam os certificados de 2023 continuam ligando normalmente e seguem instalando atualizações comuns do Windows. O corte é mais profundo: esses sistemas deixam de receber proteções de segurança para o boot inicial, incluindo atualizações do Windows Boot Manager, alterações nas bases DB e DBX e novas listas de revogação. O preço do atraso, portanto, não aparece no dia 20 de outubro; ele aparece meses depois, quando a próxima vulnerabilidade de boot descoberta não puder ser mitigada no seu parque.
A própria documentação alerta que cenários que dependem da confiança do Secure Boot, como o endurecimento do BitLocker e bootloaders de terceiros, podem ser afetados ao longo do tempo. Isso muda a natureza da tarefa para o time de defesa: não é um incidente com exploração pública em andamento, e sim uma degradação gradual e permanente da postura de segurança. Para ordenar o trabalho, serve o mesmo critério de priorização de correções por risco aplicado a vulnerabilidades: impacto, exposição e esforço de remediação.
O ciclo de vida criptográfico também não é um problema só da Microsoft. O GitHub, por exemplo, substituiu chaves RSA SSH e adotou criptografia pós-quântica justamente porque credenciais longevas viram passivo de segurança. A diferença no Secure Boot é que a troca atravessa a firmware do equipamento, o que coloca o fabricante do hardware no meio do caminho e torna servidores antigos o ponto mais crítico do inventário.
Como auditar cada servidor
Clientes Windows 11 conectados ao Windows Update tendem a receber as novas autoridades automaticamente, mas servidores e máquinas com firmware antiga são o ponto cego clássico. O guia de diagnóstico da Microsoft para Windows Server define o ponto de partida: examinar a chave de registro HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot, onde a migração termina quando aparece UEFICA2023Status = Updated indicando sucesso. Qualquer outro resultado exige ação, e a presença do valor UEFICA2023Error na subchave Servicing revela que houve falha no encaminhamento.
- Confirmar se o Secure Boot está ativo com o comando Confirm-SecureBootUEFI.
- Consultar o banco DB e procurar a cadeia Windows UEFI CA 2023 na saída de Get-SecureBootUEFI.
- Conferir o valor de UEFICA2023Status na chave de registro SecureBoot.
- Filtrar o log de eventos System pelos identificadores 1800, 1801, 1803, 1795 e 1808.
- Levantar quais famílias de hardware têm firmware com suporte confirmado às novas autoridades.
Eventos que revelam falhas
| Evento | Leitura | Ação recomendada |
|---|---|---|
| 1808 | Migração concluída | Nenhuma; registrar evidência |
| 1800 | Reinício pendente | Reiniciar e reconferir |
| 1801 | Atualização incompleta | Reiniciar o servidor |
| 1803 | KEK ausente | Verificar suporte da firmware com o fabricante |
| 1795 | Erro de firmware | Aplicar atualização de firmware do fabricante |
A Microsoft classifica como cenários de maior risco servidores com hardware antigo, firmware sem suporte às autoridades atualizadas e implantações que falharam ou ficaram incompletas. Nesses casos, a documentação avisa que a validação do Secure Boot pode falhar e a inicialização pode ser comprometida — motivo pelo qual a firmware fica no topo da fila de remediação, antes de qualquer tentativa de forçar a atualização.
Roteiro de migração em ondas
Com o inventário na mão, a implantação rende melhor em ondas, começando por uma amostra com hardware variado antes de chegar aos controladores de domínio.
P1 — até 19 de outubro:
- Inventariar servidores e estações com Secure Boot ativo e status diferente de Updated.
- Aplicar as atualizações cumulativas pendentes, que carregam as novas autoridades certificadoras.
- Reiniciar e reconferir registro e eventos em pelo menos uma máquina de cada família de hardware.
- Isolar e tratar primeiro os casos com evento 1795, atualizando a firmware do fabricante.
P2 — depois da data, para exceções:
- Documentar cada máquina sem suporte do fabricante como exceção formal, com risco registrado e data de revisão.
- Testar mídias de recuperação e PXE assinadas com as autoridades antigas antes de precisar delas numa crise.
- Reavaliar a permanência em produção de hardware que não receberá mais atualizações de boot.
Em parques com BitLocker, uma recomendação operacional: confirme que as chaves de recuperação estão arquivadas e acessíveis antes de qualquer mudança que toque o boot loader, e mantenha acesso fora de banda — iLO, iDRAC ou IPMI — disponível nos servidores físicos. O custo de um reinício que pede recuperação sem chave à mão supera em muito o do inventário prévio.