O MFA por SMS vai ser aposentado: migre para passkeys no Microsoft Entra

O celular da Maya vibra com um código de seis dígitos. Ela digita e pronto, entrou. Esse código viajou pela rede telefônica até ela, e qualquer um que consiga se colocar nesse caminho, ou convencer a operadora a passar o número dela para outro chip, recebe o código também.

Em 1º de fevereiro de 2027, a verificação por mensagem de texto e chamada de voz entregue pela Microsoft será aposentada no Microsoft Entra ID, e as passkeys entram no lugar. Veja o que muda e quando, por que as passkeys são a substituição e os cinco passos que fizemos em um tenant de laboratório.

O que muda, e quando

• 1º de setembro de 2026: as passkeys viraram o padrão. Usuários habilitados para verificação por mensagem de texto ou voz foram habilitados automaticamente para passkeys também. Na próxima vez que fazem a autenticação multifator, eles são convidados a configurar uma passkey. Por enquanto dá para adiar o aviso, e por padrão os adiamentos são ilimitados.
• 30 de outubro de 2026: seu próprio provedor de telefonia. Organizações que precisam continuar com mensagens de texto ou chamadas podem configurar o próprio provedor pela Microsoft Security Store.
• 1º de fevereiro de 2027: a Microsoft para de entregar essas mensagens e chamadas. Usuários cujo único método multifator é texto ou voz recebem um aviso que não dá para pular: registrar uma passkey ou ficar sem acesso. Não há como optar por sair.

Administradores globais e usuários externos ganham mais tempo e mudam em 1º de julho de 2027. Convidados internos seguem a data de fevereiro. Esse calendário vale para a nuvem pública, e o Azure AD B2C não é afetado.

Por que códigos por texto e voz são fracos

Um código enviado por texto ou voz pode ser roubado sem ninguém tocar no seu celular:

• Phishing: a Maya clica em um link de um e-mail e cai em uma página idêntica à de login dela. Ela digita a senha e depois o código do celular. A página falsa repassa os dois para a verdadeira em tempo real, e o atacante entra.
• SIM swap: o atacante liga para a operadora da Maya, se passa por ela e consegue transferir o número para um chip novo. Agora os códigos chegam no celular dele.
• Reutilização: o código tem só seis dígitos, então qualquer coisa que consiga lê-lo, no caminho ou em uma tela, pode reutilizá-lo antes de expirar.

A própria orientação da Microsoft diz isso com todas as letras: deixe de usar mensagens de texto e chamadas de voz na autenticação multifator.

O que é uma passkey, de fato

Uma passkey não é um código. É um par de chaves que andam juntas:

1. Quando a Maya cria uma passkey, o dispositivo dela gera duas chaves. A chave privada fica com ela, protegida pelo rosto, pela digital ou pelo PIN. A chave pública vai para o Microsoft Entra ID.
2. Quando ela faz login, o Entra envia um desafio. O dispositivo pede para ela desbloquear, assina o desafio com a chave privada e devolve a resposta.
3. O Entra confere a resposta com a chave pública. A chave privada nunca é enviada.

Agora, a página de phishing de novo. A passkey foi criada para o endereço de login real da Microsoft. A página falsa tem outro endereço, então o dispositivo da Maya não tem nada a oferecer a ela, e sem código para digitar não há nada para roubar. Por isso as passkeys são chamadas de resistentes a phishing. Elas seguem os padrões FIDO2 e funcionam sozinhas como autenticação multifator: algo que você tem (o dispositivo) mais algo que você é ou sabe (o rosto ou o PIN).

Passkeys vinculadas ao dispositivo vs sincronizadas

• Passkeys vinculadas ao dispositivo (device-bound) nunca saem do dispositivo que as criou. O Microsoft Authenticator no iPhone e no Android guarda passkeys assim, e as chaves de segurança FIDO2, aquelas pequenas chaves USB ou NFC, também.
• Passkeys sincronizadas (synced) têm backup em um provedor de passkeys, como o app Senhas da Apple com o Chaveiro do iCloud ou o Gerenciador de Senhas do Google, e aparecem nos outros dispositivos do usuário. O Microsoft Entra ID dá suporte a elas desde março de 2026.

Os administradores escolhem quais tipos permitir, e uma configuração decide muita coisa: o atestado (attestation). Com o atestado obrigatório, o Entra confere o que criou a passkey, então só as vinculadas ao dispositivo se qualificam. Passkeys sincronizadas não têm atestado.

A orientação da Microsoft: chaves de segurança para setores muito regulados ou usuários com privilégios, e para a maioria dos usuários as passkeys sincronizadas são uma alternativa prática e barata ao MFA tradicional.

As passkeys são uma de várias opções resistentes a phishing no Entra ID. A lista completa: Windows Hello para Empresas, Platform Credential para macOS, passkeys sincronizadas, chaves de segurança FIDO2, passkeys no Microsoft Authenticator e autenticação baseada em certificado.

O que isso significa para o seu tenant

• Quem é afetado: qualquer usuário habilitado para verificação por mensagem de texto ou voz. Se ninguém no seu tenant está, não há nada a fazer.
• Saída temporária: até 1º de fevereiro, um tenant pode pausar a habilitação automática das passkeys e os avisos de registro com uma configuração do Microsoft Graph. Isso só ganha tempo; não impede a obrigatoriedade de fevereiro.
• Seu próprio provedor de telefonia: se você realmente precisa de texto ou voz, por motivos regulatórios ou operacionais, pode trazer o seu próprio provedor pela Microsoft Security Store a partir de 30 de outubro. Os primeiros provedores da versão prévia são Soprano e Telesign. Você contrata direto com eles e paga a eles.

Algumas coisas que passam despercebidas:

• A redefinição de senha self-service usa a mesma entrega por texto e voz, então também entra na aposentadoria, a não ser que você use um provedor.
• O login por SMS, em que trabalhadores da linha de frente entram só com o número de telefone e um código, também será aposentado em 1º de fevereiro de 2027, e um provedor de telefonia não o mantém.
• Convidados: o suporte a passkeys para convidados internos está sendo liberado agora, e os usuários externos vêm depois.
• Custo: as passkeys estão incluídas em todas as edições do Microsoft Entra ID, até na Free. Os relatórios de atividade e o acesso condicional que usamos abaixo exigem pelo menos o Microsoft Entra ID P1. Confira no Microsoft Learn o que o seu plano inclui.

No laboratório: cinco passos

Fizemos a migração em um tenant de laboratório com usuários de teste. As configurações abaixo foram escolhidas para a demonstração, não são requisitos.

1. Descobrir quem usa texto e voz

No centro de administração do Microsoft Entra, vá em Entra ID > Authentication methods > Policies. SMS e Voice call mostram para quem estão habilitados. No nosso laboratório, o SMS estava ligado para um grupo chamado SMS users.

Para ver as pessoas, abra Activity > User registration details e olhe Methods registered: todo mundo com Mobile phone ainda tem um número de telefone para MFA. Esse relatório exige pelo menos o Entra ID P1 e pode atrasar até 36 horas.

A Microsoft também publica um script de PowerShell no GitHub (entra-sms-voice-usage-analyzer) que lê os destinos das suas políticas de SMS e voz e o estado da sua campanha de registro. Ele mostra quais grupos estão incluídos, não usuários individuais.

2. Ligar as passkeys

De volta em Policies, abra Passkey (FIDO2). O nosso tenant já tinha aderido aos perfis de passkey (passkey profiles). Depois de aderir, não dá para voltar atrás.

• Em Configure, Allow self-service set up fica em Yes, para os usuários registrarem as próprias passkeys.
• O perfil de passkey padrão decide o que é permitido. Com Enforce attestation ligado, só passkeys vinculadas ao dispositivo são oferecidas. No laboratório, desligamos e permitimos Device-bound e Synced.
• Depois, Enable e o destino: no nosso laboratório, todos os usuários.

3. Criar uma campanha de registro

Em Authentication methods > Registration campaign, State tem três opções: Microsoft managed, Enabled e Disabled. Com Enabled, mantivemos o método em Passkey (FIDO2), colocamos 3 dias de adiamento (vai de 0 a 14), ligamos Limited number of snoozes (três adiamentos) e escolhemos o grupo SMS users.

Agora, no próximo login com MFA, esses usuários são convidados a configurar uma passkey. O aviso não aparece no Linux, e convidados não recebem o convite.

4. A Maya registra uma passkey no iPhone

Gravamos isso em um iPhone real com iOS 27. Passkeys no Authenticator exigem iOS 17 ou posterior, e no Android as telas são diferentes. Antes de gravar, instalamos o Microsoft Authenticator e o ativamos como provedor de passkeys em Ajustes > Geral > Preenchimento Automático e Senhas.

1. A Maya abre myaccount.microsoft.com no Safari, entra com a senha e confirma com um código por mensagem de texto.
2. A campanha de registro aparece: Let’s keep your account secure. Ela toca em Next e de novo em Next em Sign in faster with your face, fingerprint, or PIN.
3. O iOS oferece dois lugares para salvar a passkey: o Authenticator ou o app Senhas da Apple. O Senhas criaria uma passkey sincronizada no Chaveiro do iCloud. A Maya escolhe o Authenticator, onde as passkeys ficam vinculadas ao dispositivo, então essa fica neste iPhone.
4. O Touch ID confirma, ela dá um nome e: Passkey created.

A documentação da Microsoft recomenda criar a passkey dentro do próprio app Authenticator. Esse caminho pelo navegador só funciona com o Authenticator porque, no passo 2, desligamos o Enforce attestation. Com o atestado ligado, a Maya adicionaria a conta no Authenticator e criaria a passkey lá.

Depois testamos o login. O Safari sugeriu a passkey dela e pediu o Touch ID. A primeira tentativa terminou em “Something went wrong”; ela tocou em Try again e Use Passkey, usou o Touch ID de novo e entrou. Sem senha e sem código por texto.

5. Exigir com acesso condicional e depois desligar texto e voz

Registrar uma passkey não impede ninguém de continuar usando um código por texto. Para exigir a passkey, criamos uma política de acesso condicional:

• Usuários: o grupo piloto SMS users.
• Recursos de destino: um app para o teste, o Office 365.
• Conceder: Require authentication strength, Phishing-resistant MFA. Não dá para combinar com Require multifactor authentication na mesma política.
• Habilitar política: Report-only (somente relatório). Nesse modo, o acesso condicional avalia a política mas não a aplica, então ninguém é bloqueado enquanto você confere os resultados.

Uma armadilha citada na documentação da Microsoft: se uma política assim tiver como destino todos os recursos, os usuários podem ficar presos em um loop ao registrar uma passkey no Authenticator. Limitar a apps específicos evita isso.

Quando seus usuários já tiverem migrado, SMS e Voice call podem ser desligados, ou os grupos migrados excluídos, na mesma página Policies. No laboratório só mostramos onde e descartamos a alteração. Se você ainda usa as configurações antigas de MFA e de redefinição de senha, o Manage migration, no topo de Policies, mostra em que ponto você está. Com Migration Complete, o Entra passa a seguir só a política de métodos de autenticação.

Resumo

1. Descubra quem ainda usa texto e voz.
2. Ligue as passkeys.
3. Crie uma campanha de registro, para os usuários serem convidados a criar uma no login.
4. Teste uma política de acesso condicional que exige MFA resistente a phishing, primeiro em somente relatório.
5. Desligue texto e voz quando os usuários já tiverem migrado.

1º de fevereiro de 2027 é o prazo.

Fontes

• Aposentadoria de SMS e voz no Microsoft Entra ID e as perguntas frequentes
• Passkeys (FIDO2) no Microsoft Entra ID e como habilitá-las
• Registrar uma passkey no Microsoft Authenticator
• Campanha de registro
• Força da autenticação no acesso condicional
• Atividade dos métodos de autenticação
• Gerenciar métodos de autenticação (migração)
• Opções de autenticação por telefone