Entra ID Passwordless MFA Registro: O Que a Microsoft Simplificou e Por Que Isso Importa Para o Rollout

Entra ID Passwordless MFA Registro, Explicado

Durante anos, o Microsoft Entra ID forçou novos usuários por um caminho de onboarding do tipo "método mais fraco primeiro": antes de registrar uma passkey, uma chave de segurança FIDO2, o Windows Hello for Business, o macOS Platform SSO ou o login passwordless do Microsoft Authenticator, era necessário primeiro configurar um método básico de MFA — normalmente SMS ou chamada de voz. Esse sequenciamento tornava métodos vulneráveis a phishing e SIM swap a porta de entrada padrão para toda nova identidade, mesmo em tenants que queriam passkeys em todo lugar. Este Entra ID Passwordless MFA Registro que a Microsoft está agora implementando remove essa exigência.

De acordo com o rastreamento do Message Center do Microsoft 365 (MC1450133, resumido por PUPUWEB e OurCloudNetwork, e discutido esta semana na comunidade em r/AZURE e r/entra), usuários elegíveis poderão registrar uma passkey sincronizada, uma passkey do Microsoft Entra no Windows ou uma chave de segurança FIDO2 como seu primeiríssimo método de autenticação — sem precisar passar por SMS ou chamada de voz.

Segundo as mesmas fontes de rastreamento, o rollout ocorre em fases:

• Fase 1 — passkeys sincronizadas, passkeys do Microsoft Entra no Windows e chaves de segurança FIDO2 — começa a ser implementada globalmente e em tenants GCC em meados de outubro de 2026, com conclusão prevista para meados de novembro de 2026.
• Fase 2 — expandindo o registro passwordless de primeiro fator para Windows Hello for Business, macOS Platform SSO e o login passwordless por telefone do Microsoft Authenticator — vem na sequência.

Os administradores não estão perdendo o controle: a política de métodos de autenticação já existente e o Conditional Access continuam determinando quais métodos estão realmente disponíveis e para quem. A mudança reduz o atrito no registro, mas não ativa passkeys silenciosamente para tenants que não ligaram o método.

Como Funciona

O registro passwordless-first utiliza infraestrutura que já existe no Entra ID: a política de métodos de autenticação (quais métodos de autenticação estão habilitados em todo o tenant, incluindo FIDO2/passkey com "Permitir configuração self-service") e o recurso de registration campaign, que incentiva usuários já autenticados a adotar um método-alvo depois de concluírem o MFA.

De acordo com a documentação da registration campaign no Microsoft Learn, a campanha é configurada através do bloco registrationEnforcement.authenticationMethodsRegistrationCampaign da política de métodos de autenticação (legível/gravável via Microsoft Graph em GET/PATCH https://graph.microsoft.com/v1.0/policies/authenticationmethodspolicy), com as seguintes propriedades:

Quando o estado "gerenciado pela Microsoft" é usado, a Microsoft já está deslocando gradualmente o alvo de Authenticator para fido2 (passkeys) e reduzindo o intervalo de snooze para 1 dia — mas também desativando o limite de "forçar registro após 3 adiamentos", de modo que os lembretes ficam mais frequentes enquanto o registro forçado permanece desligado para tenants que não definiram valores explícitos — vale saber isso antes de presumir que o alvo atual da sua campanha ainda é o que você configurou meses atrás.

Detecção: O Que Verificar no Seu Tenant

Antes que a Fase 1 chegue, confirme o que seu tenant realmente está configurado para permitir e quem está de fato se registrando:

Remediação: Preparando-se Para o Rollout

1. Habilite o método passkey (FIDO2) com configuração self-service, caso ainda não tenha feito isso — este é o pré-requisito para que os usuários se beneficiem do registro passwordless-first.
2. Decida agora o alvo da sua registration campaign. Se você quer que novos usuários caiam em passkeys em vez de push do Authenticator, defina targetedAuthenticationMethod explicitamente como fido2, em vez de depender dos padrões gerenciados pela Microsoft, que mudam no cronograma da Microsoft, não no seu.
3. Revise o Conditional Access para "Register security information". Se o registro deve ocorrer apenas a partir de dispositivos gerenciados ou redes confiáveis, confirme que essa política ainda se aplica quando o passwordless se tornar a opção de primeiro contato, não apenas um upgrade posterior — veja lacunas comuns em nosso guia de lacunas do Conditional Access.
4. Faça um piloto antes que a Fase 1 seja concluída na sua região. Os lembretes de passkey são avaliados por combinação de dispositivo e navegador, não por usuário — teste a experiência em toda a sua frota real de dispositivos (Windows/Chrome, macOS/Safari, mobile) em vez de presumir um comportamento uniforme.
5. Verifique novamente o MC1450133 diretamente no Message Center do seu Microsoft 365 admin center mais próximo da janela de rollout — o próprio texto de cronograma da Fase 2 da Microsoft é inconsistente, e o Message Center é a fonte da verdade específica do seu tenant para sua onda de rollout.
6. Não pare na ordem de registro. O registro passwordless-first fecha apenas parte da lacuna — veja por que o MFA sozinho não é suficiente para saber quais controles de Conditional Access e Security Defaults ainda precisam estar em vigor.

Como a EtcSec Detecta Isso

A EtcSec sinaliza tenants onde métodos passwordless não estão disponíveis ou aplicados através das verificações MFA_NO_PASSWORDLESS e MFA_NO_FIDO2 (passkey/FIDO2 não habilitado ou não configurado para self-service), MFA_NO_STRONG_METHOD (nenhum método resistente a phishing configurado), MFA_PHONE_ONLY (usuários limitados a MFA baseado em telefone — exatamente o padrão que esta mudança da Microsoft busca eliminar) e CA_NO_MFA_REQUIREMENT (nenhuma política de Conditional Access exige MFA, o que compromete qualquer melhoria na ordem de registro).