Windows Hello for Business Fator MFA Autônomo Entra Outubro de 2026: A Segunda Exigência de Passkey Desaparece

Windows Hello for Business Fator MFA Autônomo Entra Outubro de 2026: O Que a Microsoft Anunciou

Windows Hello for Business fator MFA autônomo Entra outubro de 2026 é a mudança para a qual as equipes de identidade já deveriam estar se preparando. Na publicação MC1450134 do Message Center, "Microsoft Entra: Windows Hello for Business and macOS Platform SSO as standalone MFA factors" (publicada em 7 de agosto de 2026, atualizada em 18 de agosto de 2026), a Microsoft afirma que o Entra vai "reconhecer o Windows Hello for Business (WHfB) e o macOS Platform Single Sign-On (PSSO) como fatores autônomos de autenticação multifator (MFA) em cenários de autenticação suportados".

A janela de lançamento é específica. A Disponibilidade Geral (General Availability) para locatários Worldwide e GCC começa "no início de outubro de 2026, com conclusão prevista para o fim de novembro de 2026". A Microsoft marca a publicação como planForChange, com severidade normal, e afirma claramente que "nenhuma alteração de configuração é necessária".

Essa última frase é o ponto que merece atenção. Nenhuma ação do administrador é obrigatória, mas a postura de autenticação de todo locatário em que as pessoas fazem login com Windows Hello ou em um Mac muda por conta própria — incluindo quantas de suas contas o Entra passa a relatar como capazes de MFA, e a partir de quais dispositivos um usuário ainda consegue se autenticar quando algo dá errado.

O Que Realmente Muda — e o Que Já Funcionava

O Windows Hello for Business não está sendo adicionado às forças de autenticação — ele já fazia parte delas. A referência de forças de autenticação da Microsoft lista "Windows Hello for Business or platform credential" como algo que satisfaz as três forças integradas: força MFA, força MFA sem senha (Passwordless) e força MFA resistente a phishing.

O que não funcionava de forma confiável era o caminho de reautenticação. A mesma página documenta a limitação atual nas próprias palavras da Microsoft:

Essa é a lacuna que a MC1450134 fecha. Segundo a publicação do Message Center, estes são os comportamentos após o rollout:

Duas dessas linhas merecem destaque. A linha de status de capacidade de MFA significa que seu número de conformidade se move sem que um único usuário registre algo novo — se você reporta a "porcentagem de usuários capazes de MFA" para um auditor ou para a diretoria, refaça essa linha de base antes e depois do rollout para poder explicar o salto. A linha do aviso de registro significa que a rede de segurança que costumava capturar usuários com um único método simplesmente deixa de existir, sem alarde.

A Microsoft também registra um problema conhecido na mesma página de forças de autenticação, que vale a pena reler sob essa luz: quando um recurso exige tanto uma força de autenticação quanto uma frequência de login, os usuários "podem satisfazer ambas as exigências em dois momentos diferentes" — o próprio exemplo da Microsoft é um usuário que desbloqueia seu dispositivo Windows com o Windows Hello for Business para satisfazer uma frequência de login de uma hora, enquanto um login por passkey feito há 24 horas satisfaz a exigência de força.

A Pegadinha: Credenciais Vinculadas ao Dispositivo Não Viajam

A própria Microsoft sinaliza o risco na seção "Action required and recommendations" da MC1450134: "Como as credenciais WHfB e macOS PSSO são vinculadas ao dispositivo, os usuários podem não conseguir concluir desafios de MFA a partir de dispositivos em que essas credenciais não estejam disponíveis."

Isso não é uma ressalva qualquer. É a propriedade que define ambas as credenciais:

• O Windows Hello for Business é descrito pela Microsoft como "principalmente um método de login vinculado ao dispositivo, ligado à confiança do dispositivo", com a credencial "vinculada apenas à conta corporativa ou de estudante usada para registrar o dispositivo". Seu tipo de passkey é listado como vinculado ao dispositivo, não sincronizado (Passkey do Microsoft Entra no Windows).
• A Platform Credential para macOS "provisiona uma chave criptográfica vinculada a hardware, protegida pelo Secure Enclave", construída sobre a tecnologia do Windows Hello for Business (Platform Credential para macOS).

A documentação da campanha de registro da Microsoft já mostra o quão restrita é essa vinculação na prática. O aviso de passkey é avaliado por combinação de dispositivo e navegador, e a tabela de plataformas publicada mostra que uma credencial Windows Hello for Business suprime o aviso apenas no Windows, enquanto uma credencial Mac Platform SSO o suprime apenas no macOS. O próprio exemplo da Microsoft: "se um usuário tem uma credencial Windows Hello for Business e faz login no Windows com o Chrome, o aviso é suprimido. Mas se o mesmo usuário fizer login em um Mac com o Chrome, ele será avisado, porque essa credencial não se aplica a essa plataforma." A mesma página observa que usuários de Linux nunca recebem o aviso, porque passkeys FIDO2 não estão disponíveis no Linux.

Juntando as peças, a exposição fica concreta. Depois de outubro, um usuário cuja única credencial de MFA registrada seja uma credencial Windows Hello for Business passa a contar como capaz de MFA, deixa de ser avisado para adicionar algo portátil, e ainda assim não consegue concluir um desafio de MFA a partir de um celular pessoal, de um notebook emprestado, de um Mac ou de uma estação Linux. Notebook quebrado, dispositivo reinstalado, dia de viagem, resposta a incidente a partir da máquina de outra pessoa — tudo isso vira uma ligação para o helpdesk em vez de uma solicitação de segundo fator. Esse risco recai justamente sobre as contas que você menos pode se dar ao luxo de perder — por isso contas de acesso de emergência nunca deveriam depender de uma credencial vinculada a uma única máquina.

Isso também acontece junto com a desativação do MFA por SMS e voz e a mudança no registro de MFA sem senha: os fallbacks portáteis nos quais muitos locatários ainda se apoiam estão sendo removidos exatamente no momento em que o sistema deixa de pedir para o usuário registrar um substituto.

Detecção: Encontre Seus Usuários Somente com Credenciais Vinculadas ao Dispositivo Antes de Outubro

Todos os registrados em um método sem senha — FIDO2, Windows Hello for Business ou login sem senha por telefone. Este é o círculo mais externo, não a resposta:

GET https://graph.microsoft.com/v1.0/reports/authenticationMethods/userRegistrationDetails?$filter=isPasswordlessCapable eq true

Todos os que possuem um passkey FIDO2 vinculado ao dispositivo. Observe o que isso não retorna: passKeyDeviceBound é o método de passkey vinculado ao dispositivo, não o Windows Hello for Business nem o macOS PSSO — sozinho, ele não encontrará os usuários somente-WHfB desta seção:

GET https://graph.microsoft.com/v1.0/reports/authenticationMethods/userRegistrationDetails?$filter=methodsRegistered/any(x:x eq 'passKeyDeviceBound')

A Microsoft documenta methodsRegistered como filtrável com any/eq, mas não publica o conjunto completo de valores possíveis — por isso, não tente adivinhar uma string de método dentro do $filter. Extraia methodsRegistered para cada usuário e filtre localmente — é o que a exportação abaixo faz — ou consulte a coluna Methods registered no portal, onde o Windows Hello for Business aparece nomeado.

Import-Module Microsoft.Graph.Reports

# Estabelece a linha de base dos métodos registrados de cada usuário antes do início do rollout.
# Requer AuditLog.Read.All (Reports Reader, Security Reader, Security Administrator ou Global Reader).
Get-MgReportAuthenticationMethodUserRegistrationDetail |
  Select-Object UserPrincipalName, IsAdmin, IsMfaCapable, IsPasswordlessCapable,
    @{Name = "Methods"; Expression = { $_.MethodsRegistered -join ";" }} |
  Export-Csv .\entra-mfa-baseline-pre-october-2026.csv -NoTypeInformation

Remediação: O Que Fazer Antes do Início do Rollout

1. Torne um método portátil obrigatório no onboarding. Esta é a própria primeira recomendação da Microsoft na MC1450134: "Atualizar as orientações de onboarding para garantir que os usuários registrem pelo menos um método de MFA portátil." Uma credencial vinculada ao dispositivo sem mais nada é um ponto único de falha por usuário.
2. Escolha o método portátil de forma deliberada. A Microsoft sugere "um passkey sincronizado ou um passkey do Microsoft Authenticator além do WHfB ou do macOS PSSO". Note a compensação documentada pela Microsoft: "Passkeys sincronizados não suportam atestação", então um perfil com Enforce attestation definido como Yes os exclui no momento do registro — o próprio exemplo da Microsoft para contas altamente privilegiadas combina atestação obrigatória com passkeys somente vinculados ao dispositivo (habilitar passkeys (FIDO2)). Decida qual dessas duas propriedades você realmente precisa antes de publicar a orientação.
3. Audite as authentication strengths personalizadas. A MC1450134 pede que você "revise as políticas de Authentication Strength personalizadas para confirmar que o WHfB e o macOS PSSO estão permitidos onde apropriado". As três forças integradas já incluem "Windows Hello for Business or platform credential"; são as personalizadas, escritas por você mesmo, que podem agora se comportar de forma diferente do que você presumia.
4. Verifique as listas de permissão de AAGUID do seu perfil de passkey antes de pedir o registro dos usuários. Se você usa restrições de chave, a Microsoft documenta que a AAGUID 7FD635B3-2EF9-4542-8D9D-164F2C771EFC da Platform Credential do macOS precisa estar na lista permitida para desafios WebAuthn. Para passkeys do Windows Hello, as AAGUIDs documentadas são 08987058-cadc-4b81-b6e1-30de50dcbe96 (TPM de hardware), 9ddd1817-af5a-4672-a2b9-3e3dd95000a9 (hardware VBS) e 6028b017-b1d4-4c02-b4b3-afcdafc96bb2 (TPM de software) — e a Microsoft observa que um perfil direcionado a elas não pode exigir atestação.
5. Corrija primeiro as contas break-glass. Contas de acesso de emergência precisam ser acessíveis a partir de um dispositivo que não seja aquele que quebrou. Confirme que elas possuem uma credencial portátil e que continuam excluídas das políticas que, de outra forma, as deixariam presas para fora.
6. Refaça a linha de base da métrica de capacidade de MFA e avise quem a consome. O número vai mudar porque a definição mudou, não porque a cobertura melhorou. Compare seu CSV anterior ao rollout com o posterior, em vez de reportar o novo número como progresso.
7. Teste em modo somente relatório. Mudanças de política de Conditional Access feitas em resposta a isso devem ser validadas contra tráfego real antes da aplicação — a mesma disciplina que revela as lacunas de cobertura da política baseline que a maioria dos locatários carrega.
8. Atualize a documentação do helpdesk. A recomendação final da MC1450134 é explícita: usuários apenas com WHfB ou macOS PSSO "deixarão de ser automaticamente orientados a registrar um método de MFA adicional", então a orientação precisa vir de você. Uma visão mais ampla de onde isso se encaixa na higiene do locatário está no nosso guia de auditoria do Entra ID.

Como a EtcSec Detecta Isso

As verificações de Conditional Access e acesso privilegiado da EtcSec visam exatamente as condições que transformam este rollout de um não-evento em um bloqueio de acesso. O CA_NO_MFA_REQUIREMENT sinaliza locatários sem nenhuma política que realmente exija MFA, onde um número de capacidade de MFA em mudança cria uma falsa sensação de segurança. O CA_NO_BREAK_GLASS_EXCLUSION identifica contas de acesso de emergência sem um padrão de exclusão documentado — justamente as contas com maior chance de ficarem presas por uma credencial somente vinculada ao dispositivo. O PA_GLOBAL_ADMIN_NOT_MFA revela contas privilegiadas cuja aplicação de MFA não se sustenta. O CA_NO_SESSION_CONTROLS encontra locatários que dependem de uma frequência de login que o WHfB e o macOS PSSO passarão a satisfazer durante o 2FA, e o CA_POLICY_REPORT_ONLY identifica políticas que você testou para essa mudança, mas nunca chegou a aplicar de fato.