Na segunda-feira, 19 de outubro, caducou um certificado cuja existência quase ninguém no parque informático conhece. Nenhuma máquina deixou de arrancar. Nenhum pedido de suporte foi aberto.
É esse silêncio que merece atenção. O certificado protege a fase mais precoce do arranque, antes de o Windows, o antivírus ou qualquer agente começarem a correr.
A pergunta para a equipa de TI não é “o que avariou?”. É “quais dos nossos postos de trabalho ainda dependem do certificado antigo, e quem vai tratar de cada um?”.
O que caducou e o que continua a funcionar
O Secure Boot verifica se o código que é carregado antes do sistema foi assinado por uma autoridade de confiança. A Microsoft informa que os certificados emitidos em 2011 começam a caducar em junho de 2026 e estão a ser substituídos por um conjunto de 2023. Fonte: Microsoft Support, 2026.
O último deles, o Windows Production PCA 2011, que assina o gestor de arranque do Windows, caducou a 19 de outubro de 2026. O substituto é o Windows UEFI CA 2023. Fonte: Windows Latest, 17/10/2026.
Segundo a Microsoft, o PC com o certificado caducado continua a arrancar e a instalar as atualizações normais do Windows. O que deixa de receber são as novas proteções da fase inicial: atualizações do gestor de arranque, das bases de dados do Secure Boot e das listas de revogação.
Ou seja, a máquina funciona e fica parada no tempo precisamente na camada para a qual ninguém olha. A própria Microsoft afirma que o Secure Boot não deve ser desativado para contornar a caducidade: isso reduz a proteção em vez de resolver o problema.
O que 500 mil dispositivos ensinam
A Microsoft descreveu como fez a substituição no seu próprio parque, de cerca de 500 mil dispositivos Windows. Um piloto com cerca de 35 mil teve 95% de sucesso. Em 70 dias, a conformidade chegou aos 86%. Hoje está nos 97%, com falhas abaixo de 1%. Fonte: Microsoft Inside Track, 13/08/2026.
O que ficou para trás, segundo o texto, foram os casos-limite, entre eles salas de reunião e máquinas virtuais.
Convém ler este dado com cuidado. Trata-se do próprio emissor do certificado, com telemetria própria e uma equipa dedicada, e mesmo assim sobrou uma cauda. Num parque de banca, indústria ou saúde, com delegações e equipamentos a que ninguém chama PC, a cauda tende a ser a parte difícil.
Porque é que o Windows Update sozinho não chega
A distribuição dos novos certificados é feita por fases, e a Microsoft informa que, na maioria dos PCs que os recebem pelo Windows Update, em muitos casos não é preciso fazer nada. Esse “em muitos casos” é onde a equipa de TI trabalha. Três grupos costumam ficar de fora:
- Máquinas à espera de firmware do fabricante. Alguns modelos precisam de uma atualização da BIOS antes de aceitarem o certificado novo.
- PCs com Windows 10 sem ESU. Segundo a Microsoft, só recebem os certificados novos com inscrição no ESU.
- Equipamento que não é tratado como PC. Terminal de atendimento, máquina de laboratório, posto de sala de reuniões, máquina virtual.
Sobre a decisão do Windows 10, vale a pena ler o que já escrevemos sobre decidir o ESU máquina a máquina. A caducidade do certificado é mais uma razão para essa lista existir por posto de trabalho, e não por média.
A parte que cabe à rede interna
Identificado o grupo de risco, falta chegar às máquinas. Numa rede grande e segmentada, a pergunta passa a ser de logística: quando, por que ligação e por que ordem.
Uma delegação com uma ligação estreita não aguenta uma distribuição em horário de expediente. Uma máquina de atendimento não pode reiniciar a meio do dia. O servidor crítico entra depois dos de teste.
Por isso a ordem importa. Começar pelo grupo de baixo risco, verificar e só então avançar para o crítico é o que a própria Microsoft descreve no piloto. O que a equipa de TI precisa de guardar é o registo de cada etapa: quem recebeu, quem falhou, quem ficou para depois.
E tudo isto tem de acontecer sem que os dados do parque tenham de sair da rede para serem planeados noutro lugar.
Como o Trauma Zer0 trata o assunto
Há dois módulos envolvidos. O Tz0 Inventory usa um agente em cada posto de trabalho para levantar o hardware, os programas instalados, o sistema operativo e a data da BIOS, e envia tudo para o servidor Tz0, instalado na infraestrutura do cliente. Os equipamentos desligados ou fora da rede entram no retrato quando voltam.
Assim, a lista de quem pode estar parado no certificado antigo sai do parque real: hardware, sistema e idade da BIOS, em vez de uma folha de cálculo de património.
O Tz0 Deploy trata do caminho até à máquina: instala e atualiza sem interação do utilizador, com janela por destino, limite de largura de banda, retoma automática se a ligação cair e verificação de quem instalou, quem falhou e o que foi reagendado. Tudo corre na rede da empresa, através da consola web.
Há um limite que tem de ficar claro. As páginas dos dois módulos não dizem que o Trauma Zer0 lê o estado do certificado do Secure Boot nem que aplica a atualização de certificado ou de firmware. O que o módulo oferece é a lista de máquinas por hardware e BIOS e o circuito para distribuir os pacotes que a sua equipa aprovar. A atualização em si vem da Microsoft e do fabricante.
Uma lista que deveria conseguir imprimir
Antes de a próxima auditoria perguntar, convém conseguir responder com um documento, e não com uma estimativa:
- que postos de trabalho têm uma BIOS antiga e dependem de firmware do fabricante;
- que PCs ainda estão no Windows 10 e se têm ESU;
- que equipamentos não-PC estão no mesmo inventário;
- quem é o responsável por cada exceção e até quando.
Um certificado caducado não aciona o piquete. Só a lista o faz.
Se hoje a resposta é “teríamos de verificar”, o problema não é o certificado. É a visibilidade do parque. Para ver o Tz0 Inventory a funcionar na sua rede, peça uma avaliação.