Microsoft responde a perguntas cruciais enquanto o prazo do Secure Boot se aproxima

Com a expiração do certificado original KEK do Microsoft Secure Boot marcada para 24 de junho de 2026, a Microsoft realizou sua segunda sessão ao vivo de “Pergunte Qualquer Coisa à Microsoft” (AMA) em 4 de junho para abordar as preocupações remanescentes de administradores de TI e clientes corporativos. Essa sessão forneceu insights mais profundos sobre as atualizações do Secure Boot, abordando implementações empresariais, compatibilidade de máquinas virtuais, cenários de inicialização PXE e mais.

O que muda em 24 de junho de 2026?

A dúvida mais urgente foi se 24 de junho marca um prazo final para o certificado Secure Boot KEK CA 2011. De acordo com Scott Shell, a data de expiração não é um prazo rigoroso que interrompe todas as funcionalidades. A expiração do certificado KEK não afeta imediatamente o processo de implantação manual baseado no registro ou as cargas de atualização existentes, que continuarão funcionando como antes.

No entanto, após 24 de junho, a Microsoft perderá a capacidade de assinar novos payloads DBX, que são essenciais para revogar bootloaders comprometidos. Dispositivos sem o certificado KEK atualizado podem perder revogações futuras, tornando-se potencialmente menos seguros ao longo do tempo. O certificado DB, no entanto, permanece válido até outubro, permitindo que a Microsoft assine gerenciadores de inicialização adicionais durante esse período provisório.

A atualização de junho amplia a cobertura de alta confiança

A atualização Patch Tuesday de junho classificará a grande maioria dos dispositivos convencionais como de alta confiança com base nos dados diagnósticos da Microsoft. Kevin Sullivan esclareceu que a classificação do dispositivo vai além dos nomes de fabricantes e modelos, incluindo a versão e data do firmware. Isso significa que até mesmo modelos idênticos podem ser classificados de forma diferente dependendo do firmware.

Para auxiliar os administradores de TI, o relatório de monitoramento do Intune fornece uma visão detalhada do status dos dispositivos, incluindo a classificação de alta confiança, status de aplicação de atualizações e dispositivos que exigem intervenção manual. O relatório é complementado por um script de remediação em PowerShell para maior flexibilidade.

Tratando dispositivos “temporariamente pausados”

Alguns clientes corporativos relataram dispositivos presos no status “temporariamente pausado”. A Microsoft explicou que isso ocorre quando problemas de compatibilidade no nível do firmware tornam as atualizações arriscadas. Nesses casos, é necessário uma atualização de firmware do OEM para resolver o problema. Assim que o firmware é atualizado, o dispositivo passa para um novo grupo de classificação.

Os administradores devem usar dados ao vivo do Intune ou o arquivo CSV do GitHub para acompanhar com precisão o status dos dispositivos, pois os grupos pausados não são atualizados retroativamente. A página de destino do Secure Boot da Microsoft inclui links para as páginas de suporte dos OEMs para localizar atualizações de firmware.

Orientações para implantações manuais

Para dispositivos que não estão no grupo de alta confiança, a Microsoft recomendou não esperar pela classificação automática. Os administradores devem iniciar implantações manuais configurando valores no registro ou usando as configurações de política do Intune. O fluxo de trabalho recomendado envolve:

1. Obter o relatório de monitoramento do Intune para identificar dispositivos não atualizados.
2. Testar o processo de atualização em dispositivos representativos para cada modelo ou variante de firmware.
3. Expandir gradualmente a implantação após testes bem-sucedidos.

A Microsoft enfatizou que atualizações manuais contribuem com dados de telemetria, aprimorando o sistema para outras organizações com dispositivos semelhantes.

Dispositivos com Secure Boot desativado

Para dispositivos com o Secure Boot desativado, as atualizações de certificados não podem ser aplicadas. Se o Secure Boot for reativado posteriormente, discrepâncias entre os bancos de dados de confiança do firmware e as assinaturas do gerenciador de inicialização podem causar falhas na inicialização. A recuperação desse problema requer a instalação manual do certificado de 2023 no firmware.

As VMs Gen 2 do Azure com inicialização segura ou confiável já possuem o certificado de 2023 configurado, enquanto as VMs Gen 1 são incompatíveis com o Secure Boot.

Critérios de classificação de alta confiança

Dispositivos mais antigos frequentemente alcançam a classificação de alta confiança mais rapidamente do que dispositivos mais novos porque suas populações menores permitem validação estatística mais rápida. Para modelos mais novos amplamente implantados, a atualização de junho deve expandir significativamente o grupo de alta confiança.

Ambientes PXE Boot exigem gerenciamento cuidadoso

Para ambientes de inicialização PXE, dispositivos com o certificado de 2011 continuarão inicializando enquanto o certificado não for revogado na lista DBX. No entanto, a transição para gerenciadores de inicialização assinados com o certificado de 2023 exige que todos os dispositivos no ambiente confiem no novo certificado. Durante a transição, é recomendável manter mídias de inicialização assinadas por ambos os certificados.

Windows 10 e versões mais antigas do sistema operacional

O mecanismo de atualização do Secure Boot é idêntico no Windows 10 (sob ESU), Windows 11 e versões mais antigas do servidor. No entanto, dispositivos mais antigos podem não ter dados de telemetria, tornando necessárias atualizações manuais.

Ferramentas de diagnóstico e recursos

Os logs de eventos, particularmente o log de eventos TPM-WMI, são críticos para diagnosticar problemas do Secure Boot. Indicadores-chave incluem:

• Erro 1803 para chaves de Plataforma inválidas ou não assinadas.
• Verificação de ambos os certificados KEK e DB para as versões de 2023.

O recurso central da Microsoft, aka.ms/GetSecureBoot, fornece um guia abrangente, scripts de diagnóstico e links de firmware OEM. Os administradores são incentivados a seguir o conselho da Microsoft de “testar um primeiro” para garantir atualizações suaves.

Em resumo, o plano de implantação gradual e as ferramentas de diagnóstico da Microsoft são projetados para minimizar interrupções enquanto garantem a conformidade com o Secure Boot. Os administradores de TI são incentivados a agir prontamente para evitar potenciais riscos de segurança à medida que o prazo de expiração do KEK se aproxima.