Como gerenciar a atualização do certificado Secure Boot em toda a sua frota

O prazo do certificado Secure Boot de junho de 2026 não é resolvido apenas com o envio de uma chave de registro. A migração para o UEFI CA 2023 é um fluxo de trabalho sequenciado com múltiplos critérios — como verificação de prontidão do dispositivo, dependências de firmware, coordenação de reinicializações e confirmação por dispositivo. Equipes que pulam etapas ou acionam a migração sem visibilidade adequada acabam com erros difíceis de rastrear e uma postura de conformidade impossível de verificar.

Este artigo aborda a ordem correta de execução, os modos de falha mais comuns, as vantagens e desvantagens dos métodos de implantação e como automatizar a atualização do certificado Secure Boot em todo o Windows em escala de frota.

A sequência de migração  

A atualização do Secure Boot requer um conjunto de pré-requisitos que devem ser seguidos antes de iniciar o processo de migração.

Inventariar e segmentar os dispositivos  

Antes de qualquer ação, é essencial entender quais dispositivos são elegíveis para essa migração:

• Dispositivos com BIOS legado e aqueles com Secure Boot desativado, pois não podem migrar

• Dispositivos que precisam de atualizações de firmware do fabricante (OEM)

• Dispositivos elegíveis e ociosos (com certificados Secure Boot 2011)

• Dispositivos que já concluíram a migração

Cada segmento requer uma ação diferente. Executar todos pelo mesmo acionamento gera falhas.

Aplicar atualizações de firmware OEM  

Um dispositivo com firmware desatualizado pode falhar no meio da migração — geralmente com erros que parecem ser do sistema operacional, mas que têm origem no firmware. Implante as atualizações OEM antes de acionar a migração em qualquer dispositivo.

Confirmar o status de ativação do Secure Boot  

Para os dispositivos no segmento elegível-e-ocioso, confirme os seguintes critérios:

• Confirm-SecureBootUEFI = True

• WindowsUEFICA2023Capable = 2

• Dados de diagnóstico do Windows no nível mínimo "Necessário"

Dispositivos que não atenderem a todos os três critérios retornam para a fila de correção.

Implantar a atualização  

Execute o seguinte em cada dispositivo de destino — o primeiro comando inicia a implantação do certificado e do gerenciador de inicialização no dispositivo. O segundo comando faz com que a tarefa que processa a chave de registro AvailableUpdates seja executada imediatamente.

reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot /v AvailableUpdates /t REG_DWORD /d 0x5944 /f
Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update"

Aguarde 48 horas e pelo menos uma reinicialização antes de verificar o status.

Gerenciar reinicializações  

Espere de uma a duas reinicializações. Após a primeira, execute novamente a tarefa Secure-Boot-Update — pode ser necessária uma segunda reinicialização para finalizar a instalação do certificado. Um dispositivo que reinicializou uma vez geralmente ainda está com status InProgress, não concluído.

Confirmar a conclusão  

A migração estará completa somente quando UEFICA2023Status = Updated e o Event ID 1808 aparecer no Log de Eventos do Sistema. Qualquer coisa aquém disso é um item em aberto.

O Event ID 1801 geralmente indica que os certificados não foram aplicados — verifique novamente os pré-requisitos. O Event ID 1795 indica erro na transferência dos certificados para o firmware, o que quase sempre aponta para um problema de firmware OEM.

Pontos de falha mais comuns  

Um padrão recorrente: a maioria das falhas tem origem em firmware OEM que não foi atualizado antes do acionamento. As etapas de inventário e firmware não são preparações opcionais — elas determinam se o acionamento será bem-sucedido.

⚠️ Aviso: Reativar o Secure Boot em um dispositivo onde ele estava desativado pode redefinir os bancos de dados de certificados para os padrões de fábrica. Em dispositivos com BitLocker ativado, isso aciona solicitações de chave de recuperação. Não ative ou desative o Secure Boot como reflexo de diagnóstico.

Opções de implantação para migração dos dispositivos  

A Microsoft sugere alguns métodos de implantação para que as organizações conduzam essa migração do Secure Boot.

• Chave de registro / PowerShell: Funciona em todas as versões compatíveis do Windows e plataformas de gerenciamento. O problema é a ausência de rastreamento de estado — após o envio da chave e o início da tarefa, o PowerShell não tem como indicar quais dispositivos a receberam, se a tarefa agendada foi executada ou se a migração foi concluída.

• Política de Grupo (Group Policy): Mapeia o AvailableUpdates para a política "Habilitar implantação de certificado Secure Boot" e é consistente em escala de domínio. Funciona apenas para dispositivos ingressados no domínio, deixando de fora trabalhadores remotos fora da VPN, máquinas fora do domínio e sistemas de grupo de trabalho. O rastreamento de estado após a atualização também é uma limitação.

• APIs do Windows Configuration System (WinCS): Um caminho via linha de comando para ambientes com requisitos de ferramentas específicas, mas o escopo está limitado a dispositivos ingressados no domínio com Windows 11 23H2 ou posterior. Qualquer dispositivo abaixo dessa versão do sistema operacional ou fora do domínio exige um método de implantação separado.

 Aviso: Não misture métodos de implantação no mesmo dispositivo. A Microsoft desaconselha explicitamente essa prática.

Automatize a migração em escala com o fluxo de trabalho pré-configurado do DEX Manager Plus da ManageEngine  

A maioria das ferramentas para na chave de registro, e os esforços manuais exigem que os comandos sejam executados individualmente em cada dispositivo. Além disso, elas não fornecem informações de status após a implantação da tarefa de migração. O DEX Manager Plus resolve o problema de execução da migração por meio do seu fluxo de trabalho de atualização do SecureBoot — uma camada de automação desenvolvida especificamente para lidar com toda a sequência de migração, não apenas o acionamento via registro.

Antes de tocar em qualquer dispositivo, o fluxo de trabalho valida a prontidão. O sensor de prontidão de firmware coleta os dados necessários para qualificar os dispositivos, garantindo que aqueles que não atendam aos pré-requisitos fiquem em uma fila separada, em vez de acionar uma migração que irá falhar.

Para os dispositivos que passam na validação, o fluxo de trabalho define a chave de registro AvailableUpdates como 0x5944 e inicia a tarefa agendada Secure-Boot-Update por meio do seu script de atualização do SecureBoot. Ele também gerencia o sequenciamento de reinicializações com confirmação do usuário e controle de atraso, garantindo que os usuários sejam informados e que os dispositivos não sejam forçados a reiniciar no meio de uma sessão sem aviso prévio. Após a primeira reinicialização, o fluxo de trabalho executa novamente a tarefa agendada para lidar com a segunda fase da implantação do certificado.

Durante toda a execução, o DEX Manager Plus monitora UEFICA2023Status e UEFICA2023Error por dispositivo, apresentando os erros com contexto em vez de deixar as equipes de TI vasculhando logs de eventos individuais. Dispositivos que ficam travados em InProgress, apresentam UEFICA2023Error ou registram o Event ID 1795 são sinalizados automaticamente para investigação, com contexto suficiente para diagnosticar a falha sem abrir uma sessão remota.

A conclusão é confirmada por dispositivo, verificando se UEFICA2023Status atingiu o estado Updated — não por inferência a partir da ausência de erros. O fluxo de trabalho é encerrado somente quando esse estado é confirmado.

O ciclo completo é executado automaticamente — validar, executar, reinicializar e confirmar. As equipes de TI podem visualizar em tempo real o status de migração de toda a frota: quantos dispositivos estão concluídos, quantos estão em progresso, quantos apresentam erros e quais são esses erros. A intervenção manual é necessária apenas nos casos excepcionais que realmente a exigem.

Essa é a diferença entre definir uma chave de registro e automatizar uma migração.

Artigo traduzido. Conteúdo original escrito por Raghav S.

Nota: Encontre a revenda da ManageEngine certa. Entre em contato com a nossa equipe de canais pelo e-mail latam-sales@manageengine.com.
Importante: a ManageEngine não trabalha com distribuidores no Brasil.