Fim do SMS MFA Entra ID Passkeys: o Cronograma de Migração

Fim do SMS MFA no Entra ID: o Que Está Mudando

A migração da Microsoft para o fim do SMS MFA no Entra ID em favor dos passkeys substitui a entrega própria da Microsoft de SMS e chamada de voz para autenticação multifator (MFA) por passkeys como experiência de autenticação padrão. Isso não é uma inferência de catálogo — é uma mudança de política de produto datada e publicada, documentada diretamente pela Microsoft (Passkeys por padrão e descontinuação da autenticação por SMS e voz fornecida pela Microsoft, Microsoft Learn).

Esta é uma história diferente e mais restrita do que o caso geral que apresentamos em Segurança de Identidade Azure: Quando o MFA Não Basta — aquele artigo argumenta que a presença de MFA não é suficiente por si só; este trata de um canal de entrega específico e phishável (SMS/voz fornecido pela Microsoft) sendo desligado em uma data fixa, ao lado de outros padrões legados fracos como fadiga de MFA / push bombing, que métodos resistentes a phishing como os passkeys visam eliminar.

O motivo é explícito no próprio FAQ da Microsoft: códigos por SMS e voz são phisháveis e vulneráveis a SIM-swapping, e não atendem mais ao padrão que a Microsoft deseja como opção padrão para a autenticação no Entra ID (FAQ sobre a descontinuação do SMS e voz fornecidos pela Microsoft, Microsoft Learn).

O cronograma de descontinuação

A descontinuação se aplica apenas a tenants de nuvem pública (outros ambientes de nuvem seguem um cronograma posterior, anunciado separadamente), abrange tanto o SSPR quanto o MFA de login, e não afeta o Azure AD B2C. O Microsoft Entra External ID é afetado em um cronograma separado e posterior, com seu próprio anúncio ainda por vir.

Existe um opt-out temporário para a janela de registro automático (1º de setembro de 2026 → 1º de fevereiro de 2027) — não para a aplicação em si de 1º de fevereiro — por meio da propriedade passkeyDynamicMigration na Authentication Methods Policy do tenant:

PATCH https://graph.microsoft.com/beta/policies/authenticationmethodspolicy
{
   "optOutSettings": {
     "passkeyDynamicMigration": true
   }
}

Detecção: Quem no Seu Tenant Ainda Está Exposto

Antes que isso seja implantado automaticamente no seu tenant, descubra quantos usuários ainda dependem de fato do SMS ou voz fornecido pela Microsoft — e se suas configurações atuais de Conditional Access e de campanha de registro vão interagir bem com as próprias mudanças da Microsoft de 1º de setembro. Se você não revisou sua baseline de Conditional Access recentemente, veja primeiro Acesso Condicional Azure: Riscos de Bypass de MFA.

Remediação

1. Primeiro, faça o inventário dos usuários expostos. Use o script oficial em PowerShell para listar toda conta ainda habilitada para, ou usando, SMS/voz. Qualquer resultado diferente de zero significa que o tenant está no escopo.
2. Migre os usuários para passkeys proativamente, no seu próprio cronograma. Habilite Passkey (FIDO2) como método de autenticação, coloque sua população de SMS/voz em um grupo de Authentication Methods Policy habilitado para passkey, e ative você mesmo uma Registration Campaign (Entra admin center → Authentication methods → Registration campaign → State: Microsoft Managed, restrita ao seu grupo de segurança de SMS/voz) — este é o mesmo mecanismo que a Microsoft aplicará automaticamente em 1º de setembro de 2026, mas você controla a comunicação e o momento.
3. Se algum segmento tiver uma necessidade genuína de compliance ou operacional para SMS/voz, documente agora a regulamentação ou o cenário específico, depois avalie um provedor de telecomunicações gerenciado pelo cliente através da Microsoft Security Store a partir de 18 de setembro de 2026, e configure-o a partir de 30 de outubro de 2026 — antes da virada de 1º de fevereiro de 2027.
4. Use o opt-out passkeyDynamicMigration apenas como uma ponte, não como um plano de longo prazo. Ele adia o registro automático e o push da Registration Campaign enquanto você conclui o trabalho de migração; ele não adia nem isenta da aplicação de 1º de fevereiro de 2027.
5. Comunique com antecedência. A Microsoft recomenda um plano de comunicação em fases de conscientização → ação → lembrete, e publica modelos para usuários finais para a mudança para passkeys — direcione a comunicação ao grupo de segurança criado no passo 1, para que os usuários certos sejam informados antes que o lembrete comece.
6. Reavalie o Conditional Access. Um tenant que já bloqueia autenticação legada e aplica MFA amplamente a todos os usuários, não apenas administradores, absorve essa mudança com muito menos disrupção do que um que depende de SMS/voz como um fallback silencioso. Para um guia completo, veja Como Auditar a Segurança do Microsoft Entra ID.

Como a EtcSec Detecta Isso

A auditoria Azure/Entra da EtcSec sinaliza tenants que ainda estão expostos a essa descontinuação antes que ela se torne uma migração involuntária. AUTH_METHODS_SMS_ENABLED reporta quando o SMS está habilitado como método de autenticação, de forma geral; MFA_PHONE_ONLY sinaliza contas em que métodos baseados em telefone (SMS, voz) são a única opção de MFA registrada — exatamente a população que vai enfrentar o prompt bloqueante de passkey em 1º de fevereiro de 2027. MFA_NO_PASSWORDLESS e MFA_NO_FIDO2 sinalizam tenants que não habilitaram métodos sem senha ou FIDO2/passkey, a lacuna pré-requisito que você precisa fechar antes que qualquer migração proativa possa começar.