Certificados Secure Boot da Microsoft a Expirar em 2026: Guia Completo de Actualização
Em 2026, os certificados Secure Boot de 2011 que assinam o processo de arranque do Windows estão a expirar. A Microsoft iniciou a substituição pelos certificados de 2023 através do Windows Update, mas o processo não é totalmente automático: servidores, dispositivos IoT, máquinas air-gapped e equipamentos com firmware específico exigem intervenção manual. Ignorar a actualização não impede o arranque — os dispositivos continuam a ligar — mas deixa o sistema sem actualizações de segurança do boot manager, criando uma janela de vulnerabilidade explorável por ataques como o Black Lotus (Microsoft Secure Boot FAQ). Este guia explica o que está a acontecer, como verificar o estado de cada dispositivo e como aplicar os novos certificados antes do prazo final de Outubro de 2026, quando a Microsoft deixa de poder assinar boot managers com o certificado de 2011.
A informação deste artigo baseia-se na sessão pública AMA (Ask Me Anything) da Microsoft de 24 de Junho de 2026 (YouTube live), com Arden White (principal security engineer), Scott Shell (principal software architect) e Richard Powell (group engineering manager), responsáveis pela equipa de Secure Boot no Windows. As fontes oficiais estão referenciadas inline ao longo do texto.
Neste artigo
- Entender o Problema: Certificados de 2011 vs 2023
- Pré-requisitos e Dispositivos Excluídos
- Passo 1 — Verificar o Estado dos Certificados com PowerShell
- Passo 2 — Aplicar os Certificados via Intune
- Passo 3 — Aplicar os Certificados via Registry ou GPO
- Passo 4 — Verificar a Actualização com Event Logs
- Passo 5 — atualizar Servidores (Sem CFR)
- Passo 6 — Gerir PXE Boot e boot.wim
- Secure Boot e BitLocker: O Que Precisa de Saber
- Erros Comuns Durante a Actualização
- Checklist Rápido de Verificação
1. Entender o Problema: Certificados de 2011 vs 2023
O Secure Boot é um mecanismo de verificação criptográfica que garante que apenas software assinado por chaves confiáveis pode executar durante o processo de arranque. Cada dispositivo UEFI contém uma base de dados (db) de certificados confiáveis, uma lista de revogações (dbx) e chaves de troca (KEK) que controlam a actualização dessas bases (Microsoft Learn — Secure Boot).
Desde 2011, os certificados Secure Boot da Microsoft — o Windows UEFI CA, o Microsoft UEFI CA e o Microsoft 3rd Party UEFI CA (CAC) — assinam todos os boot managers e componentes de arranque do Windows. Esses certificados foram emitidos com validade de 15 anos e expiram em 2026. A Microsoft gerou novos certificados em 2023 (daí a designação “certificados de 2023”) que substituem os de 2011, e está a distribuí-los através do Windows Update desde meados de 2025 (Microsoft Support — Certificates Expiration).
⚠️ Atenção
A data crítica não é a da expiração do certificado em si, mas Outubro de 2026 — mês em que a Microsoft deixa de poder assinar novos boot managers com o certificado de 2011. A partir dessa data, dispositivos que ainda não tenham os certificados de 2023 no firmware não conseguem receber actualizações de segurança do boot manager. O sistema arranca, mas fica com segurança degradada.
Existem três certificados distintos que precisam de ser atualizados:
| Certificado | Função | Estado após actualização |
|---|---|---|
| Windows UEFI CA 2023 | Assina o boot manager do Windows | Crítico — sem este, não há actualizações do boot manager |
| Microsoft UEFI CA 2023 | Assina componentes de terceiros | Necessário para hardware periférico e drivers de arranque |
| Microsoft 3rd Party UEFI CA (CAC) 2023 | Assina boot loaders de terceiros | Necessário para dual-boot (Linux, etc.) |
A Microsoft está a distribuir estes certificados em duas fases: primeiro através do CFR (Controlled Feature Rollout), um rollout faseado que selecciona dispositivos com base na compatibilidade do firmware; depois, quando há confiança alta (high confidence), através do LCU (Latest Cumulative Update) mensal. Dispositivos com firmware pouco comum, servidores e máquinas sem telemetria podem nunca chegar à fase automática — nesses casos, a actualização tem de ser manual (Microsoft Learn — Windows Security).
⚠️ Atenção
Dispositivos legacy BIOS (não UEFI) não são afectados. O Secure Boot só existe em sistemas UEFI. Se o dispositivo não tem Secure Boot capable, o update não tenta correr e nada muda.
2. Pré-requisitos e Dispositivos Excluídos
Antes de iniciar a actualização, é importante verificar quais dispositivos são elegíveis e quais exigem atenção especial.
Requisitos para actualização automática via Windows Update:
- UEFI com Secure Boot habilitado (não apenas capable — tem de estar enabled)
- Windows 10 22H2, Windows 11 23H2+ ou Windows Server 2019/2022/2025
- Dispositivo no programa de telemetria (dados de diagnóstico) — quanto mais comum o hardware, mais rápido entra no high confidence
- Firmware compatível com a actualização de certificados (algumas firmwares antigas têm bugs que impedem a escrita dos novos certificados)
Dispositivos que exigem intervenção manual:
| Tipo de dispositivo | Razão | Acção recomendada |
|---|---|---|
| Servidores | Não participam no CFR — não recebem update automático | Aplicar registry key manualmente + forçar scheduled task |
| Dispositivos IoT | Baixa telemetria, firmware específico | Inventariar e atualizar individualmente |
| Máquinas air-gapped | Sem rede, Microsoft nunca vê o estado | Aplicar via script offline |
| Hyper-V VMs | Bug conhecido no CAC update em VMs long-running | Aplicar March 2026 update no host E no guest |
| Secure Core PC | Não têm 2011 UEFI CA de terceiros — 2023 UEFI CA também não é instalado | Comportamento esperado, não é um erro |
| Legacy BIOS | Não suporta Secure Boot | Nenhuma acção necessária |
| Custom/OEM raro | Baixa população no CFR, pode nunca chegar ao LCU | Testar manualmente num dispositivo piloto |
Nota: Dispositivos com CSM (Compatibility Support Module) que liga funcionalidades legacy BIOS mas mantém UEFI + Secure Boot podem ser atualizados. O CSM não impede a actualização dos certificados, segundo Scott Shell na AMA de Junho de 2026.
3. Passo 1 — Verificar o Estado dos Certificados com PowerShell
O primeiro passo é inventariar todos os dispositivos da frota para saber quais já têm os certificados de 2023 instalados. A Microsoft mantém scripts PowerShell públicos no site aka.ms/getsecureboot, na secção “IT Pro Guidance”.
O script principal verifica a presença dos três certificados de 2023 no firmware. O cmdlet Confirm-SecureBootUEFI confirma que o Secure Boot está ativo, mas não diz quais certificados estão instalados. Para isso, é necessário inspecionar as variáveis UEFI directamente.
O seguinte script PowerShell lista o estado dos certificados Secure Boot no firmware do dispositivo:
# Requer PowerShell 5.1+ e privilégios de administrador
# Confirmar que Secure Boot está ativo
$secureBootEnabled = Confirm-SecureBootUEFI
Write-Host “Secure Boot Enabled: $secureBootEnabled”
# Listar certificados no db (variável UEFI)
$pk = Get-SecureBootPK
Write-Host “Platform Key presente: $($pk.Count -gt 0)”
# Verificar eventos de actualização no event log
Get-WinEvent -LogName “Microsoft-Windows-TPM-WMI/Operational” -MaxEvents 20 |
Where-Object { $_.Id -in @(1800, 1801) } |
Format-Table TimeCreated, Id, Message -Wrap
O Confirm-SecureBootUEFI devolve True se o Secure Boot estiver ativo. Os eventos 1800 e 1801 no log Microsoft-Windows-TPM-WMI/Operational indicam o progresso da actualização: o evento 1800 indica que os certificados foram aplicados (ou que é necessário reiniciar), e o 1801 indica que os certificados estão disponíveis mas ainda não foram aplicados.
Para um inventário de frota sem Intune, a Microsoft recomenda executar o script de inventário completo disponível em aka.ms/getsecureboot e recolher os resultados via PowerShell remoting, SCCM ou qualquer ferramenta de inventário existente. Um cliente com 400.000 dispositivos referido na AMA usou um script PowerShell personalizado, recolheu os dados e construiu um dashboard no Power BI.
Nota: A Microsoft está a atualizar os scripts PowerShell em Junho e Julho de 2026, incluindo um novo cmdlet Get-SecureBootSVN que mostra o SVN (Security Version Number) do firmware e do boot manager — facilitando a verificação do estado sem ler variáveis UEFI directamente.
4. Passo 2 — Aplicar os Certificados via Intune
Para organizações que usam Microsoft Intune, a actualização pode ser deployada via script de remediação. O Intune executa um script de detecção que verifica se os certificados estão atualizados e, se não estiverem, executa um script de remediação que aplica os certificados.
O processo no Intune segue estes passos:
- Criar um Remediation Script (Scripts > Remediation scripts)
- Definir o script de detecção que verifica os certificados de 2023
- Definir o script de remediação que força a actualização
- Atribuir a grupos de dispositivos
O script de remediação define a registry key que ativa a actualização e força a scheduled task a executar. A registry key que ativa a actualização de certificados é:
O valor 22852 nesta chave ativa a actualização dos certificados. O processo é idêntico ao que o CFR faz automaticamente, mas forçado pelo administrador.
⚠️ Atenção
Aplicar a registry key antes de testar num dispositivo piloto pode causar problemas em firmwares com bugs conhecidos. A Microsoft recomenda testar numa amostra representativa antes do deployment em massa. Se um dispositivo tem firmware que não suporta a actualização correctamente, forçar a registry key pode resultar em problemas de arranque.
Após aplicar a registry key, é necessário forçar a scheduled task que executa a actualização:
Set-ItemProperty -Path “HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\State” `
-Name “22852” -Value 1 -Type DWord
# Forçar a scheduled task de actualização de Secure Boot
Start-ScheduledTask -TaskName “\Microsoft\Windows\SecureBoot\SecureBootUpdate”
# Aguardar 30 segundos e forçar reinício
Start-Sleep -Seconds 30
Restart-Computer -Force
Após o reinício, o sistema aplica os certificados ao firmware. Dependendo do dispositivo, podem ser necessários vários reinícios — o sistema reinicia automaticamente durante o processo para selar as chaves do BitLocker e do VSM (Virtual Secure Mode) correctamente.
Para monitorizar o progresso via Intune, verifiquem os eventos no log Microsoft-Windows-TPM-WMI/Operational conforme descrito no Passo 4.
5. Passo 3 — Aplicar os Certificados via Registry ou GPO
Para organizações que não usam Intune — ou que gerem dispositivos fora do escopo do MDM — a actualização pode ser feita via registry key distribuída por GPO, SCCM, ou qualquer ferramenta de gestão de endpoints.
A registry key que ativa a actualização é a mesma usada pelo Intune. A diferença é o método de distribuição:
Via GPO (Group Policy Object):
- Abrir o Group Policy Management Editor
- Navegar para Computer Configuration > Preferences > Windows Settings > Registry
- Adicionar um novo item Registry:
- Action: Update
- Hive: HKEY_LOCAL_MACHINE
- Key Path:
SYSTEM\CurrentControlSet\Control\SecureBoot\State - Value name:
22852 - Value type: REG_DWORD
- Value data:
1
- Aplicar o GPO ao target OU
Via SCCM (Configuration Manager):
Criar um Configuration Item com a mesma registry key e deployar como Configuration Baseline. O SCCM pode verificar a conformidade e remediar automaticamente.
Via script PowerShell remoto:
$computers = @(“SRV-01”, “SRV-02”, “WS-015”, “WS-022”)
Invoke-Command -ComputerName $computers -ScriptBlock {
Set-ItemProperty -Path “HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\State” `
-Name “22852” -Value 1 -Type DWord
Start-ScheduledTask -TaskName “\Microsoft\Windows\SecureBoot\SecureBootUpdate”
}
Cada dispositivo reinicia automaticamente quando a actualização dos certificados o exige. Não é necessário suspender o BitLocker — o processo é BitLocker-aware e re-sela as chaves automaticamente (ver secção 9).
✓ Nota
A registry key 22852 foi mencionada na AMA de Junho de 2026 por um administrador que a usou com sucesso num servidor 2019 em Hyper-V. A Microsoft confirmou que este é o método suportado para forçar a actualização quando o CFR não chega ao dispositivo.
6. Passo 4 — Verificar a Actualização com Event Logs
Depois de aplicar a registry key e forçar a actualização, é essencial verificar se os certificados foram correctamente instalados no firmware. O Windows regista cada passo do processo no event log.
O log relevante é Microsoft-Windows-TPM-WMI/Operational, e os eventos-chave são:
| Event ID | Significado | Acção necessária |
|---|---|---|
| 1800 | Certificados aplicados com sucesso | Nenhuma — verifiquem com o script do Passo 1 |
| 1800 (variant) | Actualização aplicada mas precisa de reiniciar | Reiniciar o dispositivo |
| 1801 | Certificados disponíveis mas não aplicados | Verificar se falta reiniciar; se persistir, testar manualmente |
| 1801 (persistent) | Dispositivo no bucket “needs more data” do CFR | Aplicar registry key manualmente após testar |
Para consultar os eventos:
Get-WinEvent -LogName “Microsoft-Windows-TPM-WMI/Operational” -MaxEvents 50 |
Where-Object { $_.Id -in @(1800, 1801) } |
Select-Object TimeCreated, Id, LevelDisplayName, Message |
Format-Table -Wrap
Se o evento 1801 persistir após vários reinícios e a aplicação da registry key, o dispositivo pode estar num dos buckets do CFR que ainda não atingiram confiança alta. Nesse caso, a recomendação da Microsoft é: pegar num dispositivo de teste, aplicar a registry key manualmente, forçar a scheduled task e verificar se o firmware actualiza correctamente. Se funcionar, podem aplicar o mesmo método a todos os dispositivos do mesmo modelo (aka.ms/getsecureboot).
⚠️ Atenção
Se apenas 2 dos 3 certificados foram atualizados, não é necessariamente um erro. Dispositivos Secure Core PC não têm o Microsoft UEFI CA 2011 (de terceiros) instalado, por isso a Microsoft não instala o equivalente de 2023 — mantém a mesma postura de segurança. Verifiquem se o Windows UEFI CA 2023 está presente — esse é o certificado crítico para o boot manager.
7. Passo 5 — atualizar Servidores (Sem CFR)
Os servidores são o caso mais preocupante porque não participam no CFR. A Microsoft não envia actualizações automáticas de certificados Secure Boot para servidores via Controlled Feature Rollout — a actualização tem de ser manual.
⚠️ Atenção
Segundo Richard Powell (Microsoft), “server não participa em CFR. Acção manual é frequentemente necessária para servidores. Verifiquem aka.ms/securebootforserver para detalhes.” Servidores Windows Server 2019, 2022 e 2025 têm o mesmo mecanismo de actualização que os clientes, mas sem o rollout automático.
Para servidores, o processo é:
- Verificar o estado com o script PowerShell do Passo 1
- Aplicar a registry key
22852como no Passo 3 - Forçar a scheduled task e reiniciar
- Verificar os event logs no Passo 4
- Repetir para cada servidor
Caso especial — Hyper-V: Existe um bug conhecido na actualização do CAC (Microsoft 3rd Party UEFI CA) em VMs Hyper-V long-running. A correção foi lançada em Março de 2026, mas precisa de ser aplicada em dois lados:
- No host Hyper-V — actualiza a capacidade de atualizar o CAC
- No guest (VM) — instala o Hyper-V PK signed CAC que permite aplicar ao servidor
Se têm VMs Hyper-V que não estão a atualizar o CAC, verifiquem se o update de Março de 2026 está aplicado tanto no host como no guest (Microsoft Learn — Windows Server).
Windows Server 2025: Apesar de ser mais recente, o Server 2025 não tem capacidade adicional de actualização automática em comparação com o Server 2022. Usa a mesma base de dados de confiança (compliance DB) e o mesmo mecanismo manual.
8. Passo 6 — Gerir PXE Boot e boot.wim
Para organizações que usam PXE boot (SCCM, MDT, WDS), a actualização dos certificados cria um problema de compatibilidade: o boot manager no boot.wim é assinado com o certificado de 2011, mas dispositivos que já tenham os certificados de 2023 (e que eventualmente revoguem o de 2011) não conseguirão fazer PXE boot com um boot manager assinado apenas com 2011.
⚠️ Atenção
O protocolo PXE só permite enviar um boot manager por boot.wim. Não é possível ter dois boot managers (assinado com 2011 e 2023) lado a lado no mesmo boot.wim — o protocolo PXE envia apenas um.
A timeline é a seguinte:
- Agora (Junho 2026): boot.wim standard tem boot manager assinado com 2011. Dispositivos com ambos os certificados (2011 + 2023) fazem PXE boot sem problemas.
- Pós-Junho 2026: Se o boot.wim for atualizado para incluir boot manager assinado com 2023, dispositivos que não tenham os certificados de 2023 não conseguem PXE boot.
- Pós-Outubro 2026: Se o boot.wim continuar com boot manager de 2011 e os dispositivos revogarem o certificado de 2011, o PXE boot deixa de funcionar nesses dispositivos.
A solução é gerir a transição manualmente:
# Requer DISM e privilégios de administrador
# 1. Montar o boot.wim
Mount-WindowsImage -ImagePath “D:\sources\boot.wim” -Index 1 -Path “C:\Mount”
# 2. Copiar o boot manager de 2023 (de um sistema atualizado)
Copy-Item “C:\Windows\Boot\EFI\bootmgfw.efi” “C:\Mount\Windows\Boot\EFI\bootmgfw.efi” -Force
# 3. Desmontar e confirmar
Dismount-WindowsImage -Path “C:\Mount” -Save
# 4. atualizar a distribuição do PXE/SCCM
⚠️ Atenção
Se substituírem o boot manager no boot.wim por um assinado com 2023, todos os dispositivos que fazem PXE boot precisam de ter os certificados de 2023 instalados. Dispositivos sem os certificados de 2023 não conseguirão fazer PXE boot. A Microsoft recomenda monitorizar o rollout e só trocar o boot manager quando 100% dos dispositivos alvo estiverem atualizados.
9. Secure Boot e BitLocker: O Que Precisa de Saber
Uma das perguntas mais frequentes é se é necessário suspender o BitLocker durante a actualização dos certificados. A resposta é não.
Nota: Segundo Scott Shell (Microsoft): “As actualizações são BitLocker-aware. Não precisam de suspender o BitLocker. O processo de actualização re-sela as chaves do BitLocker e do VSM (Virtual Secure Mode). As coisas protegidas no Virtual Secure Mode, como o Windows Hello, continuam protegidas mesmo com o BitLocker suspenso. O processo trata de re-selar todas essas chaves sem suspender e sem perder protecção de segurança durante as actualizações.”
Isto significa que:
- Não é necessário usar
Suspend-BitLockerProtectionantes da actualização - As chaves do BitLocker são re-seladas automaticamente após a actualização dos certificados
- O VSM (Credential Guard, Device Guard, Windows Hello) também é re-selado
- O processo pode causar vários reinícios — isto é normal e esperado
⚠️ Atenção
Alguns administradores reportaram que actualizações de firmware (que aparecem como “driver updates” no Intune) pedem a chave de recuperação do BitLocker após reiniciar. Isto pode acontecer se a actualização de firmware altera a configuração do Secure Boot (especialmente o PK ou CAC). Nesses casos, a chave de recuperação deve estar disponível no Entra ID / AD / MBAM antes de aplicar a actualização. Ver BitLocker + Entra ID para como garantir backup de chaves.
10. Erros Comuns Durante a Actualização
| Problema | Causa | Solução |
|---|---|---|
| Evento 1801 persistente após reinício | Dispositivo no bucket “needs more data” do CFR | Aplicar registry key 22852 manualmente após testar num dispositivo piloto |
| Apenas 2 de 3 certificados atualizados | Dispositivo Secure Core PC sem 2011 UEFI CA de terceiros | Comportamento esperado — o Windows UEFI CA 2023 é o crítico, não o de terceiros |
| VM Hyper-V não actualiza o CAC | Bug conhecido — falta update de Março 2026 no host ou no guest | Aplicar update de Março 2026 em ambos (host + guest) |
| Servidor 2019 mostra “capable = 0” após update | Registry key legacy não é actualizada no Server 2019 | Não confiar nessa registry key específica — usar os outros registry keys documentados e os event logs |
| PXE boot falha após atualizar boot.wim | Dispositivos sem certificados de 2023 a tentar fazer PXE boot com boot manager de 2023 | Garantir que 100% dos dispositivos têm certificados de 2023 antes de trocar o boot manager |
| Secure Boot disabled — certificados não aplicam | A Microsoft não actualiza certificados com Secure Boot desactivado (comportamento inconsistente entre UEFI implementations) | ativar Secure Boot primeiro; se o dispositivo não arranca com Secure Boot on, investigar configuração (jogos como Valorant também exigem Secure Boot — há guias de troubleshooting disponíveis) |
| Dispositivo não recebe actualização via LCU | Hardware raro/customizado, pouca telemetria no CFR | Aplicar registry key manualmente após testar; considerar ligar telemetria para acelerar entrada no high confidence |
| Múltiplos reinícios após actualização | Comportamento normal — o processo escreve certificados no firmware e re-sela chaves do BitLocker/VSM | Aguardar que o sistema estabilize (tipicamente 2-3 reinícios) |
| Firmware não actualiza apesar de registry key | Firmware com bug conhecido que impede escrita de certificados | Não forçar — a Microsoft exclui dispositivos conhecidos do CFR por esta razão. Contactar o fabricante do firmware |
11. Checklist Rápido de Verificação
- [ ] Inventariar todos os dispositivos UEFI com Secure Boot ativo
- [ ] Identificar servidores, IoT e dispositivos air-gapped — estes exigem actualização manual
- [ ] Executar o script PowerShell de inventário de aka.ms/getsecureboot num dispositivo piloto
- [ ] Confirmar que o Windows UEFI CA 2023 está presente (certificado crítico para boot manager)
- [ ] Aplicar a registry key
22852num dispositivo de teste e forçar a scheduled task - [ ] Verificar os event logs (IDs 1800/1801) no log
Microsoft-Windows-TPM-WMI/Operational - [ ] Confirmar que o BitLocker não foi afectado (chave de recuperação acessível)
- [ ] Aplicar o update de Março de 2026 no host Hyper-V e nos guests se usam Hyper-V
- [ ] Para servidores: aplicar manualmente via registry key ou GPO (sem CFR)
- [ ] Para PXE boot: só trocar o boot manager no boot.wim quando 100% dos dispositivos estiverem atualizados
- [ ] Documentar dispositivos que não actualizam (firmware com bug) e excluir do rollout
- [ ] Submeter perguntas em aka.ms/ama-secureboot para a próxima AMA
