A Microsoft retomou a distribuição da Administrator protection (proteção de administrador) no Windows 11, uma alteração profunda ao modelo de elevação de privilégios que substitui o clássico Controlo de Conta de Utilizador (UAC) por um sistema de privilégios concedidos apenas no momento em que são precisos. A funcionalidade tinha sido anunciada em 2024, chegou a ser disponibilizada em outubro de 2025 e foi depois desativada, depois de um investigador da Google Project Zero ter demonstrado nove formas distintas de a contornar. Agora, as notas de versão oficiais da Microsoft confirmam que o lançamento gradual recomeçou nas builds de pré-visualização das versões 24H2 e 25H2, ainda desativado por predefinição.
Resposta rápida: A proteção de administrador do Windows 11 deixa de manter permanentemente um token de administrador na sessão do utilizador e passa a gerar privilégios temporários a partir de uma conta oculta gerida pelo sistema, exigindo autorização explícita em cada operação. A Microsoft reativou o lançamento gradual em agosto de 2026, através da atualização KB5120998, mas a funcionalidade continua desativada por predefinição e configura-se por Política de Grupo ou Intune. Se gere um parque informático, teste a compatibilidade das aplicações antes de ativar em produção — scripts e tarefas agendadas que dependem de um token de administrador sempre ativo podem deixar de funcionar.
O que muda, em termos técnicos
O modelo tradicional do Windows assenta no chamado split token: quando um utilizador com direitos administrativos inicia sessão, o sistema cria dois tokens de acesso, um restrito para o dia a dia e outro com privilégios completos, que fica disponível na mesma sessão. É precisamente essa disponibilidade permanente que torna o UAC um alvo tão apetecível para técnicas de bypass e roubo de token.
A documentação da Microsoft descreve uma abordagem diferente. A proteção de administrador assenta no princípio do menor privilégio: ao iniciar sessão, o utilizador recebe um token desprivilegiado e, quando são necessários privilégios administrativos, o Windows pede autorização para a operação. Uma vez autorizada, o sistema usa uma conta de utilizador oculta, gerada pelo sistema e com perfil separado, para criar um token de administrador isolado, que é entregue ao processo requerente e destruído quando esse processo termina, garantindo que os privilégios não persistem.
Essa conta é internamente designada por System Managed Administrator Account (SMAA). Trata-se de uma conta de administrador local associada a uma conta de utilizador padrão específica, criada no momento da elevação caso ainda não exista, correspondendo cada SMAA a um perfil de utilizador distinto e membro do grupo Administradores. Para os programadores há um detalhe relevante: esta conta gerida pelo sistema tem um identificador de segurança (SID) diferente, o que pode partir pressupostos antigos em aplicações que assumem que o perfil elevado e o perfil do utilizador são o mesmo.
Os três pilares anunciados são claros: elevação just-in-time, com o token descartado após a utilização e recriado sempre que outra tarefa exigir privilégios; separação de perfis, para que malware ao nível do utilizador não consiga comprometer a sessão elevada; e ausência de elevações automáticas, obrigando o utilizador a autorizar interativamente cada operação administrativa. A autorização integra-se com o Windows Hello, o que significa PIN, impressão digital ou reconhecimento facial em vez do habitual clique em “Sim”.
Um lançamento acidentado: nove bypasses e uma desativação
O percurso da funcionalidade explica boa parte da confusão que se instalou entre administradores de sistemas. Depois de meses em canais Insider, a Microsoft disponibilizou a proteção de administrador na atualização opcional KB5067036, em outubro de 2025. Pouco depois, a Google Project Zero publicou os resultados de uma investigação conduzida por James Forshaw. O investigador identificou nove formas distintas de contornar a funcionalidade e obter silenciosamente privilégios de administrador; algumas correspondiam a problemas antigos do UAC com casos de teste públicos, outras resultavam de falhas de implementação da própria funcionalidade.
Segundo a Project Zero, todos os problemas reportados foram corrigidos, seja antes do lançamento oficial na atualização opcional KB5067036, seja em boletins de segurança posteriores; a mesma nota refere que, a 1 de dezembro de 2025, a Microsoft desativou a funcionalidade enquanto tratava de um problema de compatibilidade aplicacional. Num segundo artigo, o investigador detalhou a causa comum de cinco desses nove problemas, ligada à implementação do mecanismo de UI Access — um problema de longa data no UAC que, na sua análise, tem sido subvalorizado. Uma das falhas partia de um bypass público originalmente concebido para o UAC e que continuava a funcionar com a proteção de administrador, através da aplicação Quick Assist, componente opcional mas instalado por predefinição no Windows 11.
Um dos casos recebeu identificador público. De acordo com o registo da vulnerabilidade citado por publicações técnicas especializadas, a Microsoft classificou-o como CVE-2025-60718, uma fraqueza de untrusted search path com CVSS 7.8 que permitia a elevação local de privilégios por parte de um atacante autenticado, afetando o Windows 11 versão 24H2 até à build 10.0.26100.7092 e a versão 25H2 até à build 10.0.26200.7092. A Project Zero considerou a correção inicial dessa falha incompleta. Organizações que planeiem adotar a funcionalidade devem, por isso, garantir que têm as atualizações de segurança em dia antes de a ativar.
Cronologia da proteção de administrador
| Data | Acontecimento |
|---|---|
| Outubro/novembro de 2024 | Primeiras builds Insider com a funcionalidade e anúncio no âmbito da iniciativa de resiliência do Windows |
| 28 de outubro de 2025 | Disponibilização na atualização opcional KB5067036 para 24H2 e 25H2 |
| 1 de dezembro de 2025 | Microsoft desativa a funcionalidade devido a um problema de compatibilidade aplicacional |
| Janeiro e fevereiro de 2026 | Project Zero publica a investigação sobre os nove bypasses, todos entretanto corrigidos |
| 14 de agosto de 2026 | KB5120998 retoma o lançamento gradual nas builds 26100.9267 (24H2) e 26200.9267 (25H2) |
O que dizem exatamente as notas de versão da Microsoft
Este é o ponto onde convém ler a fonte primária em vez do resumo. Nas notas de versão do canal Release Preview, a Microsoft indica que a proteção de administrador visa proteger os direitos de administrador permanentemente disponíveis, permitindo executar tarefas administrativas com privilégios just-in-time; que não é classificada como uma fronteira de segurança formal, limitando-se a reforçar a segurança contra ataques de elevação de privilégios através da separação de perfis; que está desativada por predefinição e pode ser ativada via OMA-URI no Microsoft Intune ou por Política de Grupo; e que a funcionalidade, previamente divulgada em outubro de 2025 com a KB5067036, está agora a começar a ser distribuída.
Duas ressalvas merecem destaque. A primeira é que “não é uma fronteira de segurança formal” significa, na prática, que a Microsoft não se compromete a tratar todos os bypasses como vulnerabilidades de segurança com correção urgente — uma nuance importante para quem desenha modelos de ameaça. A segunda é a natureza do lançamento: por se tratar de uma distribuição faseada, dois computadores com a mesma build podem expor conjuntos de funcionalidades diferentes, o que explica que uma política seja visível no editor local enquanto o interruptor na secção de proteção da conta não aparece; a entrega de funcionalidades no Windows deixou de depender apenas da instalação da atualização cumulativa, podendo a Microsoft controlar capacidades individuais através de lançamento controlado.
Como ativar e o que testar antes
Para equipas de TI, os caminhos documentados são os seguintes:
- Política de Grupo local: através do Editor de Política de Grupo Local, em Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options, na definição relativa ao modo de aprovação de administrador com proteção de administrador.
- Microsoft Intune: por política OMA-URI personalizada, o método indicado pela Microsoft para implementações em escala.
- Aplicação Segurança do Windows: na secção de proteção da conta, colocando o interruptor em “Ativado”, com reinício necessário — disponível apenas em dispositivos onde a funcionalidade já foi libertada.
O teste de compatibilidade não é opcional. A própria Microsoft admite que algumas aplicações dependem de os direitos de administrador estarem sempre presentes e de o perfil elevado estar acessível quando executadas sem elevação, cenários que podem exigir atualizações para funcionarem com o novo modelo. A recomendação prática é direta: usar a conta local SYSTEM ou contas de serviço dedicadas para tarefas agendadas e scripts configurados para correr com privilégios máximos, redesenhando os scripts para não esperarem um token de administrador sempre disponível.
Porque é que isto importa em Portugal
A elevação de privilégios é uma etapa quase obrigatória na cadeia de ataque do ransomware e das intrusões com objetivos de espionagem: o acesso inicial obtém-se por phishing ou por uma vulnerabilidade exposta, mas é a passagem a administrador que permite desativar defesas, aceder a credenciais em memória e alastrar lateralmente pela rede. Qualquer mecanismo que dificulte esse salto tem impacto direto na probabilidade de um incidente se transformar numa paragem operacional.
Para as organizações portuguesas, o enquadramento é o Regime Jurídico da Ciberseguranca, aprovado pelo Decreto-Lei n.º 125/2025 que transpõe a Diretiva NIS2. As entidades abrangidas têm de adotar medidas técnicas e organizativas proporcionais ao risco, incluindo políticas de controlo de acessos e utilização de ativos, e a gestão de privilégios administrativos nos postos de trabalho é um dos pontos que tipicamente surge nas auditorias. O CNCS e o CERT.PT, enquanto autoridade nacional e equipa de resposta a incidentes, são os interlocutores para notificação de incidentes significativos e para orientação técnica.
Há ainda a dimensão de proteção de dados. Uma elevação de privilégios bem-sucedida costuma preceder o acesso a bases de dados de clientes ou colaboradores, com potencial de violação de dados pessoais e as consequentes obrigações de notificação à CNPD ao abrigo do RGPD. Reduzir a janela em que um token de administrador existe na memória é, nesse sentido, também uma medida de minimização de risco para os titulares dos dados.
Para as PME sem ferramentas dedicadas de gestão de privilégios, a mensagem é de expectativa realista: a funcionalidade pode vir a fechar uma lacuna histórica, mas ainda não está ativa por predefinição, depende do lançamento faseado e não substitui a boa prática mais barata de todas — trabalhar no dia a dia com uma conta de utilizador padrão e reservar a conta de administrador para quando é mesmo necessária.
Perguntas frequentes
A proteção de administrador já está ativa no meu Windows 11?
Não por predefinição. As notas de versão da Microsoft indicam que a funcionalidade está desativada por predefinição e que o lançamento é gradual, pelo que dois computadores com a mesma build podem comportar-se de forma diferente. Verifique a secção de proteção da conta na aplicação Segurança do Windows e mantenha o Windows Update atualizado.
Isto substitui o Controlo de Conta de Utilizador (UAC)?
É uma evolução do modelo. Em vez do token dividido que mantém privilégios administrativos disponíveis na sessão, o Windows passa a gerar um token isolado a partir de uma conta gerida pelo sistema, destruído no fim da operação. A Microsoft sublinha, ainda assim, que a funcionalidade não é classificada como fronteira de segurança formal.
As falhas encontradas pela Project Zero já foram corrigidas?
Segundo a Project Zero, os nove bypasses reportados foram corrigidos, antes do lançamento oficial ou em boletins de segurança posteriores. A equipa considerou, no entanto, incompleta a correção inicial de uma das falhas, pelo que aplicar todas as atualizações de segurança disponíveis continua a ser essencial.
O que devo testar antes de ativar numa organização?
Aplicações de instalação e manutenção, agentes de gestão, scripts e tarefas agendadas que correm com privilégios máximos, e qualquer software que assuma acesso ao perfil elevado. A Microsoft recomenda usar a conta SYSTEM ou contas de serviço dedicadas e redesenhar scripts que esperem um token de administrador sempre ativo.
Esta informação tem caráter noticioso e baseia-se em dados divulgados publicamente pela Microsoft, nas respetivas notas de versão e documentação técnica, e na investigação publicada pela Google Project Zero.