A Microsoft confirmou oficialmente que as atualizações de segurança de setembro de 2026 para o Windows 11 podem destruir a relação de confiança entre computadores e o domínio Active Directory, deixando utilizadores bloqueados no ecrã de início de sessão mesmo com credenciais válidas. A causa foi identificada numa funcionalidade de segurança chamada Machine Identity Isolation, ligada ao Credential Guard, e a empresa publicou entretanto uma solução provisória para os administradores de sistemas afetados, enquanto prepara uma correção definitiva numa atualização futura.
Resposta rápida: Depois de instalar a atualização KB5124008 (Windows 11 24H2/25H2) ou KB5124012 (26H1), alguns computadores com contas de máquina protegidas pelo Credential Guard perdem o canal seguro com o domínio Active Directory e os utilizadores deixam de conseguir autenticar-se. A Microsoft atribui o problema à ativação do Machine Identity Isolation em modo de imposição e recomenda desativá-lo pelo mesmo método usado para o ativar (Intune, política de grupo ou registo), reiniciar o equipamento e reparar o canal seguro com Test-ComputerSecureChannel -Repair. Organizações com parque Windows 11 ligado a Active Directory devem travar a distribuição em massa e auditar esta configuração antes de continuar.
O que a Microsoft admitiu no painel de estado das atualizações
Depois de vários dias de relatos por parte de administradores, a Microsoft acrescentou o problema à lista de incidentes conhecidos do Windows 11. Segundo a documentação da empresa, após a instalação da atualização de segurança de 8 de setembro de 2026 (KB5124008) ou de atualizações posteriores, algumas contas de máquina protegidas pelo Credential Guard podem perder o canal seguro com um domínio Active Directory local, deixando os utilizadores impossibilitados de iniciar sessão interativamente com credenciais válidas e apresentando uma mensagem a indicar que a relação de confiança entre o dispositivo e o domínio falhou.
Há dois detalhes importantes para quem está a diagnosticar o problema: o início de sessão offline com credenciais previamente colocadas em cache pode continuar a funcionar, e nem a replicação do Active Directory nem os serviços de AD nos controladores de domínio são afetados. Ou seja, o domínio não está “em baixo” — o que se quebra é a identidade da máquina cliente.
Quanto à origem, a Microsoft afirma que o problema ocorre porque o KB5124008 e as atualizações seguintes ativam a funcionalidade Machine Identity Isolation. A empresa acrescenta uma nuance relevante: a atualização não liga diretamente o modo de imposição, mas faz com que o Windows passe a respeitar configurações já existentes ou provisionadas por política que tinham esse modo ativado — redação usada na atualização do painel de estado das atualizações (release health). Este ponto explica por que razão vários administradores garantem nunca ter ativado a funcionalidade de forma consciente: em muitos casos, o valor estava herdado de linhas de base de segurança ou de políticas antigas.
Atualizações e versões afetadas
| Atualização | Versões | Notas |
|---|---|---|
KB5124008 | Windows 11 24H2 e 25H2 | Lançada a 8 de setembro de 2026; eleva o 25H2 à build 26200.9445 e o 24H2 à build 26100.9445 |
KB5124012 | Windows 11 26H1 | Também associada à ativação do modo de imposição do Machine Identity Isolation |
| Atualizações posteriores | Windows 11 24H2 / 25H2 / 26H1 | A Microsoft indica que o comportamento se mantém em atualizações lançadas após o KB5124008 |
O KB5124008 foi lançado a 8 de setembro de 2026 para todas as edições do Windows 11 24H2 e 25H2, colocando o 25H2 na build 26200.9445 e o 24H2 na build 26100.9445. As análises feitas por administradores ligaram as falhas ao Machine Identity Isolation, que passa a modo de imposição após a instalação do KB5124008 (24H2/25H2) ou do KB5124012 (26H1). Vale a pena sublinhar que se trata de uma atualização cumulativa, pelo que desinstalá-la remove também as correções de segurança de setembro — desinstalar não é, por isso, uma boa estratégia.
Porque é que esta funcionalidade parte o canal seguro
O Machine Identity Isolation não é um bug: é um mecanismo de defesa desenhado para proteger o segredo da conta de computador. Segundo a documentação da Microsoft, ativá-lo permite proteção baseada em virtualização das contas de máquina do AD, movendo as credenciais da conta de computador para o Credential Guard; todas as autenticações futuras da conta de máquina passam a ser encaminhadas pelo Credential Guard e, se este não arrancar após um reinício, o resultado é a impossibilidade de completar a autenticação de domínio, podendo exigir a intervenção de uma conta de administrador local.
A diferença entre os modos é decisiva. No modo de auditoria, a identidade da máquina é copiada para o Credential Guard e tanto a LSA como o Credential Guard mantêm acesso, o que permite validar o comportamento antes da imposição; no modo de imposição, a identidade é movida para o Credential Guard e fica acessível apenas a este. A configuração vive na política de grupo em Computer Configuration\Administrative Templates\System\Device Guard\Turn On Virtualization Based Security.
Há ainda um aviso que os administradores devem ler antes de mexer em nada: a documentação indica que, se a política estiver em modo de imposição e for depois desativada, o dispositivo tem de ser removido e novamente ligado ao domínio, porque deixa de conseguir autenticar-se; com o início de sessão em cache ativo, o acesso local continua a funcionar enquanto a cache estiver válida, mas a autenticação de domínio fica quebrada, e só a conta de administrador local pode ser usada para repetir o processo de adesão ao domínio. Não é inédito este mecanismo dar problemas: a partir da atualização de abril (KB5055523), as contas de máquina protegidas pelo Credential Guard foram temporariamente desativadas no Windows Server 2025 e no Windows 11 24H2 devido a um problema de rotação da password da máquina via Kerberos, mantendo-se desativadas até existir correção permanente.
Sinais de diagnóstico a procurar
Não estamos diante de uma vulnerabilidade explorada por atacantes, pelo que não existe CVE nem pontuação CVSS associada — é uma regressão funcional introduzida por uma atualização. Os indicadores úteis são, por isso, operacionais e não indicadores de comprometimento clássicos.
| Onde verificar | O que procurar |
|---|---|
| Registo (cliente) | MachineIdentityIsolation com valor 2 em HKLM\SYSTEM\CurrentControlSet\Control\Lsa ou em HKLM\SOFTWARE\Policies\Microsoft\Windows\DeviceGuard |
| Linha de comandos (cliente) | Resultado de nltest /sc_query com erro ERROR_NO_TRUST_LSA_SECRET (1786), segundo relatos de administradores |
| Registo de eventos (controlador de domínio) | Evento 4625 associado à conta de computador, com código 0xC000006A, segundo os mesmos relatos |
| Experiência do utilizador | Mensagem de falha da relação de confiança ou de credenciais incorretas, tipicamente após um reinício |
Os relatos técnicos recolhidos junto de administradores descrevem o comando nltest /sc_query a devolver o erro ERROR_NO_TRUST_LSA_SECRET (1786) e, do lado dos controladores de domínio, o evento 4625 para a conta de computador com o código de erro 0xC000006A. Foram observados casos com controladores Windows Server 2019 e Windows Server 2022, atualizados ou não, o que indica que o problema não está ligado a uma versão específica do Windows Server.
A solução provisória, passo a passo
A Microsoft indica que os administradores devem desativar o Machine Identity Isolation em todos os dispositivos previamente configurados para o usar e que não estejam ligados a controladores de domínio Windows Server 2025, utilizando o mesmo método de gestão que o ativou — Intune, se foi ativado por política do Intune, política de grupo, se foi ativado por GPO. Quando a configuração foi aplicada diretamente no registo, os passos documentados são os seguintes:
- Localizar
HKLM\SYSTEM\CurrentControlSet\Control\Lsa\MachineIdentityIsolationeHKLM\SOFTWARE\Policies\Microsoft\Windows\DeviceGuard\MachineIdentityIsolation; - Se o valor estiver a
2, alterá-lo para0; - Reiniciar o dispositivo;
- Reparar o canal seguro com
Test-ComputerSecureChannel -Repair -Credential (Get-Credential).
A documentação da Microsoft descreve exatamente estes caminhos de registo, a alteração do valor 2 para 0, o reinício do dispositivo e a reposição do canal seguro com o comando Test-ComputerSecureChannel -Repair -Credential (Get-Credential), indicando como passo seguinte a intenção de resolver o problema numa atualização futura do Windows, impedindo temporariamente a imposição do Machine Identity Isolation enquanto a funcionalidade é melhorada.
Um alerta prático: num equipamento cuja relação de confiança já está quebrada, a política de grupo não consegue ser atualizada, porque a máquina já não se autentica no domínio. Nesses casos, a intervenção local torna-se inevitável — e convém corrigir a GPO ou a linha de base do Intune primeiro, para não voltar a impor o valor logo após a reparação.
Cronologia do incidente
| Data | Acontecimento |
|---|---|
| 8 de setembro de 2026 | Lançamento do KB5124008 no ciclo de atualizações de segurança (Patch Tuesday) |
| Dias seguintes | Administradores relatam perda do canal seguro e falhas de início de sessão em fóruns da Microsoft e noutras plataformas |
| 14 de setembro de 2026 | A Microsoft publica atualizações fora de banda para outros problemas do mesmo ciclo |
| 16 de setembro de 2026 | O problema é adicionado à lista de incidentes conhecidos, com solução provisória documentada |
É importante notar que as atualizações de emergência publicadas a 14 de setembro não resolvem este caso concreto: a Microsoft lançou nessa data atualizações fora de banda para corrigir falhas nos Serviços de Ambiente de Trabalho Remoto, problemas de Hyper-V e problemas de áudio USB causados pelas atualizações de segurança do mês, mas o problema da relação de confiança com o domínio não parece ser abordado por essa atualização de emergência. A Microsoft afirma que planeia impedir temporariamente a imposição do Machine Identity Isolation numa atualização futura, enquanto trabalha no problema de compatibilidade.
Porque é que isto importa às organizações em Portugal
Muitas PME e organismos públicos portugueses continuam a operar Active Directory local com postos de trabalho Windows 11 — exatamente o cenário exposto. Um bloqueio simultâneo de autenticação em dezenas ou centenas de postos não é apenas um incómodo de TI: é uma interrupção de disponibilidade, com impacto direto em serviços críticos, cadeias de produção e atendimento ao público. E, quando a autenticação falha, é frequente que as equipas recorram a atalhos perigosos, como partilhar contas de administrador local ou desligar controlos de segurança em massa.
Do ponto de vista regulatório, a disponibilidade é parte integrante da segurança. O Regime Jurídico da Ciberseguranca, aprovado pelo Decreto-Lei n.º 125/2025, que transpõe a Diretiva NIS2, obriga as entidades abrangidas a gerir riscos que incluem a gestão de vulnerabilidades e de alterações, a continuidade de atividade e a recuperação em caso de incidente. Um processo de atualização sem anéis de teste, sem inventário de configurações de segurança e sem plano de recuperação local é, nesse contexto, uma fragilidade de governação e não apenas um erro operacional. O CNCS e o CERT.PT mantêm-se os pontos de contacto nacionais para apoio e notificação de incidentes relevantes.
Há também um ângulo de proteção de dados. Se a resposta ao incidente passar por reconstruir postos, recorrer a contas privilegiadas partilhadas ou desativar mecanismos de proteção de credenciais, aumenta o risco de acessos indevidos a dados pessoais — matéria que, ao abrigo do RGPD, exige medidas técnicas e organizativas adequadas e pode desencadear obrigações de notificação à CNPD caso ocorra uma violação de dados. A recomendação prática é simples: faseie a instalação, teste primeiro num anel reduzido de máquinas representativas, audite onde está configurado o Machine Identity Isolation antes de distribuir, e garanta que existe um procedimento de recuperação com credenciais de administrador local devidamente cofrado.
Perguntas frequentes
Este problema afeta computadores domésticos?
Não. O incidente afeta computadores Windows 11 ligados a um domínio Active Directory local com contas de máquina protegidas pelo Credential Guard. Equipamentos pessoais, com conta Microsoft ou apenas conta local, não dependem do canal seguro de domínio e não são atingidos por esta falha.
Devo desinstalar a atualização de setembro?
Não é aconselhável. Por ser uma atualização cumulativa, desinstalá-la remove também as correções de segurança do mês, expondo o equipamento a vulnerabilidades já corrigidas. A abordagem documentada pela Microsoft passa por desativar o Machine Identity Isolation e reparar o canal seguro, mantendo a atualização instalada.
Como sei se o meu parque está em risco antes de atualizar?
Verifique se existe o valor MachineIdentityIsolation nos caminhos de registo indicados pela Microsoft e se está definido como 2, correspondente ao modo de imposição. Confirme também as suas políticas de grupo e linhas de base de segurança do Intune, já que o valor pode ter sido aplicado por herança sem decisão explícita da equipa.
Existe risco de um atacante explorar esta falha?
Não se trata de uma vulnerabilidade explorável, pelo que não tem CVE nem pontuação CVSS. É uma regressão de compatibilidade que provoca indisponibilidade. O risco indireto está nas respostas improvisadas, como desligar proteções de credenciais em todo o parque ou partilhar contas privilegiadas para recuperar postos.
Esta informação tem caráter noticioso e baseia-se em dados divulgados publicamente pela Microsoft (painel de estado das atualizações e documentação técnica do Windows Server e do Credential Guard) e em relatos técnicos de administradores de sistemas.
