Publicado em 04 de setembro de 2026
Série: Microsoft 365 — Prepare-se para a mudança | Artigo 01/12
Microsoft Entra ID · MFA · Passkeys · FIDO2 · Conditional Access · Zero Trust · Segurança de Identidade
Introdução
Durante muitos anos, receber um código por SMS foi praticamente sinônimo de autenticação multifator.
Usuário e senha eram informados e, logo depois, chegava aquele conhecido código de seis dígitos no celular.
Esse modelo representou um avanço enorme quando comparado à autenticação baseada somente em senha.
Mas o cenário de ameaças mudou.
SIM Swap, phishing em tempo real, engenharia social, interceptação de mensagens e serviços de adversary-in-the-middle demonstraram que ter MFA não significa necessariamente possuir uma autenticação resistente a phishing.
Agora essa evolução entra em uma nova fase.
A Microsoft iniciou a transição do Microsoft Entra ID para tornar Passkeys uma experiência padrão de autenticação, enquanto SMS e chamadas de voz fornecidos pela própria Microsoft caminham para sua aposentadoria.
E as datas já estão definidas:
1º de setembro de 2026
Usuários habilitados para SMS ou voz passam a ser automaticamente habilitados e incentivados a registrar Passkeys durante autenticações MFA.
1º de fevereiro de 2027
A entrega de SMS e chamadas de voz fornecida pela Microsoft será aposentada no Microsoft Entra ID.
Portanto, isso não é mais algo para colocar no roadmap de longo prazo.
A transição já começou.
Neste artigo vamos entender o que muda, os impactos para administradores e usuários, como identificar quem ainda depende de SMS e, principalmente, como criar uma estratégia para migrar para métodos de autenticação resistentes a phishing.
1. O que exatamente a Microsoft está aposentando?
Existe uma distinção extremamente importante.
A Microsoft não está dizendo simplesmente:
“MFA por telefone deixará de existir mundialmente em fevereiro.”
A mudança é especificamente relacionada ao serviço de telecomunicações fornecido pela Microsoft para autenticação SMS e voz no Microsoft Entra ID.
A estratégia anunciada possui duas grandes etapas.
A partir de 1º de setembro de 2026
Usuários habilitados para SMS ou chamadas de voz começam a entrar no processo de migração para Passkeys.
Eles poderão receber solicitações para registrar uma Passkey em dispositivos elegíveis.
A partir de 1º de fevereiro de 2027
O serviço de entrega de SMS e chamadas de voz fornecido pela Microsoft será aposentado.
Não haverá opt-out dessa etapa.
Organizações que possuam uma necessidade comercial, técnica ou regulatória legítima para continuar utilizando SMS ou chamadas poderão recorrer ao modelo de provedores de telecomunicações gerenciados pelo cliente.
A Microsoft anunciou que o recurso Choose Your Own Telephony Provider estará disponível a partir de 30 de outubro de 2026.
Mas existe uma pergunta mais importante:
Se temos a oportunidade de modernizar a autenticação, deveríamos realmente investir para manter SMS?
Para a maioria das organizações, provavelmente não.
2. Por que o SMS deixou de ser considerado um método forte?
O problema não está necessariamente no conceito de segundo fator.
O problema está no canal utilizado para entregar esse fator.
Considere:
Usuário │ ├── Senha │ ▼Microsoft Entra ID │ ├── Solicita MFA │ ▼Operadora de telefonia │ ├── SMS │ ▼Celular
Existe uma infraestrutura de telecomunicações entre o provedor de identidade e o usuário.
Isso cria uma superfície de ataque que simplesmente não existe da mesma maneira em métodos criptográficos modernos.
Entre os principais riscos estão:
SIM Swap
Um atacante consegue transferir fraudulentamente o número da vítima para outro SIM/eSIM.
O atacante passa então a receber mensagens destinadas à vítima.
Phishing em tempo real
O atacante cria uma página falsa.
O usuário informa:
LoginSenhaCódigo SMS
O atacante utiliza imediatamente essas informações no serviço verdadeiro.
Ou seja:
MFA ocorreu.
Mas o ataque também funcionou.
Engenharia social
Atacantes podem convencer usuários a informar códigos recebidos por SMS.
Dependência da infraestrutura de telecomunicações
SMS depende de operadoras, roteamento, disponibilidade regional e outros componentes externos ao mecanismo de identidade.
É justamente por isso que o mercado está migrando para autenticação resistente a phishing.
3. MFA não significa automaticamente segurança contra phishing
Esse é provavelmente o conceito mais importante deste artigo.
Compare:
MFA
│
┌────────────┼────────────┐
│ │ │
SMS Authenticator Passkey
│ │ │
▼ ▼ ▼
MFA MFA MFA
│ │ │
▼ ▼ ▼
Phishable Depende do Resistente
método a phishing
Todos podem participar de uma autenticação multifator.
Mas isso não significa que todos oferecem o mesmo nível de proteção.
A estratégia moderna deve deixar de perguntar apenas:
“O usuário possui MFA?”
e começar a perguntar:
“Qual método de autenticação esse usuário está utilizando?”
Essa diferença é fundamental em uma arquitetura Zero Trust.
4. O destino recomendado: Passkeys e FIDO2
Passkeys utilizam criptografia de chave pública baseada nos padrões FIDO2/WebAuthn.
Simplificando:
REGISTRO
Dispositivo Microsoft Entra ID
│ │
│ cria par criptográfico │
│ │
├── Private Key │
│ permanece no dispositivo │
│ │
└──────── Public Key ──────────►│
Durante a autenticação:
Microsoft Entra ID │ │ desafio criptográfico ▼Dispositivo │ │ usuário confirma │ PIN / biometria │ ▼Private Key │ │ assina o desafio ▼Microsoft Entra ID │ ▼Autenticação validada
A chave privada não precisa ser enviada ao Microsoft Entra ID.
Além disso, a credencial é vinculada ao serviço/origem para o qual foi criada.
Esse modelo dificulta enormemente ataques tradicionais de phishing.
5. Passkey pode substituir senha e MFA
Aqui está outra mudança conceitual importante.
Passkey não precisa simplesmente ser “o segundo fator”.
Ela pode fornecer autenticação passwordless.
Em vez de:
Senha +SMS =MFA
podemos ter:
Passkey │ ├── Posse do dispositivo │ └── PIN/Biometria │ ▼ Autenticação multifator
Isso melhora simultaneamente:
Segurança
e
experiência do usuário.
Esse é um ponto importante porque historicamente segurança significava adicionar mais etapas ao login.
Com Passkeys, podemos conseguir exatamente o contrário:
aumentar a segurança reduzindo a dependência de senhas e códigos temporários.
6. Quais métodos devemos considerar?
Uma organização não precisa possuir apenas um método.
Na verdade, uma boa arquitetura normalmente possui diferentes métodos para diferentes cenários.
Passkeys
Principal estratégia moderna.
Podem ser sincronizadas ou vinculadas ao dispositivo, dependendo das políticas configuradas.
FIDO2 Security Keys
Excelente opção para administradores privilegiados, operadores de infraestrutura e ambientes altamente regulados.
Windows Hello for Business
Excelente experiência para usuários corporativos utilizando dispositivos Windows gerenciados.
Microsoft Authenticator
Continua sendo extremamente relevante.
Mas é importante distinguir autenticação baseada no Authenticator de Passkeys armazenadas no Authenticator.
Temporary Access Pass — TAP
TAP merece atenção especial.
Ele não deve ser visto como o método permanente de autenticação.
Ele funciona como um mecanismo temporário para onboarding e recuperação.
Por exemplo:
Novo funcionário │ ▼Service Desk │ ▼Temporary Access Pass │ ▼Primeiro acesso │ ▼Registro da Passkey │ ▼TAP expira
Esse fluxo é muito interessante porque resolve um problema clássico:
Como cadastrar um método passwordless se o usuário ainda não possui um método forte para realizar o primeiro acesso?
7. O papel do Conditional Access
Habilitar Passkeys não significa automaticamente que aplicações sensíveis passarão a exigir Passkeys.
É aqui que entra o Conditional Access.
Podemos pensar em três níveis.
Nível 1 — Exigir MFA
Usuário │ ▼Aplicação │ ▼Require MFA
Isso responde:
“Existe MFA?”
Nível 2 — Authentication Strength
Agora podemos responder:
“Que tipo de MFA aceitamos?”
Por exemplo:
Usuário │ ▼Azure Portal │ ▼Conditional Access │ ▼Authentication Strength │ ▼Phishing-resistant MFA
Isso permite exigir métodos específicos para recursos críticos.
8. Authentication Strength muda completamente a estratégia
Imagine uma organização com:
20.000 usuários
Talvez não seja necessário exigir FIDO2 de todos imediatamente.
Mas podemos começar por:
Global AdministratorsPrivileged Role AdministratorsSecurity AdministratorsExchange AdministratorsConditional Access AdministratorsIntune Administrators
Para essas identidades:
Conditional Access │ ▼Authentication Strength │ ▼Phishing-resistant MFA
Depois expandimos gradualmente.
Essa abordagem reduz o risco operacional.
9. Como descobrir quem ainda utiliza SMS ou chamadas?
Antes de migrar qualquer coisa, precisamos conhecer o ambiente.
No Microsoft Entra Admin Center, administradores podem utilizar os relatórios relacionados aos métodos de autenticação para entender quais métodos estão registrados e sendo utilizados.
A pergunta não deve ser apenas:
Quantos usuários têm telefone cadastrado?
Mas também:
Quantos usuários estão realmente utilizando SMS ou voz?
Essas informações devem gerar um inventário.
Algo como:
Total de usuários 20.000Passkey 1.200Windows Hello 11.500Authenticator 6.100SMS 900Voice 50
Agora existe um projeto claramente mensurável:
950 usuários │ ▼Migrar antes de01/02/2027
10. Microsoft Graph pode ajudar
Para ambientes grandes, relatórios manuais rapidamente deixam de ser suficientes.
Administradores podem utilizar Microsoft Graph e os relatórios de métodos de autenticação para automatizar inventários.
O objetivo é criar relatórios contendo informações como:
UserPrincipalNameDisplayNameMFA CapablePasswordless CapableMethods RegisteredLast Authentication Method
Com isso podemos criar grupos de migração.
Por exemplo:
MFA_SMS_Wave01MFA_SMS_Wave02MFA_SMS_Wave03MFA_SMS_ExecutivesMFA_SMS_Admins
Isso transforma uma mudança global em ondas controladas.
11. Não migre 20 mil usuários de uma vez
Esse provavelmente é um dos maiores erros que uma organização pode cometer.
Imagine habilitar uma mudança global numa sexta-feira:
20.000 usuários │ ▼Novo processo de registro │ ▼Dúvidas │ ▼Service Desk │ ▼🔥
O problema não será necessariamente tecnológico.
Será operacional.
A estratégia deve ser progressiva.
12. Estratégia recomendada de migração
Eu dividiria a implantação em aproximadamente seis fases.
Fase 1 — Discovery
Descobrir:
- quem utiliza SMS;
- quem utiliza chamadas;
- quem já possui Authenticator;
- quem possui Windows Hello;
- quem já possui Passkey;
- quais usuários possuem dispositivos compatíveis;
- quais contas são privilegiadas;
- quais cenários possuem dependência legítima de telefonia.
Objetivo:
conhecer o tamanho real do problema.
Fase 2 — Arquitetura
Definir o modelo futuro.
Exemplo:
Usuário padrão │ ├── Passkey └── Windows HelloAdministrador │ ├── FIDO2 Security Key └── Passkey device-boundOnboarding │ └── Temporary Access PassRecuperação │ └── Processo controlado
Fase 3 — Piloto
Comece com TI.
Depois:
TI ↓Security ↓Service Desk ↓Usuários técnicos ↓Usuários comuns
Um piloto entre 50 e 200 usuários normalmente revela rapidamente problemas de processo e comunicação.
Fase 4 — Authentication Strength
Depois que o método estiver funcionando:
Conditional Access │ ▼Authentication Strength │ ▼Phishing-resistant MFA
Comece pelos recursos mais sensíveis.
Por exemplo:
Azure PortalEntra Admin CenterMicrosoft 365 Admin CenterIntunePurviewDefender
Fase 5 — Migração em ondas
Exemplo:
Wave 01 — TIWave 02 — AdministradoresWave 03 — Usuários pilotoWave 04 — EscritóriosWave 05 — FiliaisWave 06 — Usuários remotos
Cada onda deve possuir métricas.
Fase 6 — Remoção da dependência
Somente depois de validar a migração:
SMS ↓redução progressiva ↓exceções documentadas ↓remoção
Nunca remova primeiro para descobrir os problemas depois.
3. O impacto para o Service Desk
Esse projeto não pertence apenas ao time de identidade.
O Service Desk será uma das áreas mais impactadas.
Precisará saber responder:
- O que é Passkey?
- Meu celular suporta?
- Troquei de celular. O que faço?
- Perdi meu celular.
- Minha biometria não funciona.
- Como cadastrar outra Passkey?
- Posso utilizar mais de um dispositivo?
- O que é TAP?
- Minha chave FIDO2 foi perdida.
- Como recuperar minha conta?
Portanto:
documentação e treinamento são controles de segurança.
oft destaca comunicação coordenada como um dos fatores mais importantes para uma migração tranquila.
Eu dividiria a comunicação em três momentos.
Conscientização
Explique:
“O método de autenticação está mudando.”
Não diga simplesmente:
“Seu MFA será bloqueado.”
Ação
Forneça instruções específicas:
WindowsAndroidiOSFIDO2
Lembrete
Comunique somente usuários que ainda não concluíram a migração.
Isso evita spam corporativo e melhora a efetividade da campanha.
15. Existe um opt-out?
Temporariamente, sim.
Existe uma possibilidade de adiar a habilitação automática relacionada ao período entre setembro de 2026 e fevereiro de 2027.
A configuração é realizada através da política de Authentication Methods utilizando Microsoft Graph e requer a permissão:
Policy.ReadWrite.AuthenticationMethod
A propriedade utilizada atualmente é:
passkeyDynamicMigration
Porém existe uma diferença importante:
O opt-out não cancela a aposentadoria de fevereiro de 2027.
Ele apenas concede tempo adicional para preparar o ambiente.
Portanto, eu não recomendaria utilizar essa opção como estratégia permanente.
Ela deve ser tratada como:
Tempo adicional │ ▼Planejamento │ ▼Migração
e não:
Tempo adicional │ ▼Ignorar mudança
16. E se minha organização realmente precisar de SMS?
Existem situações legítimas.
Por exemplo:
- usuários sem smartphones compatíveis;
- populações específicas;
- requisitos operacionais;
- restrições regionais;
- ambientes com equipamentos antigos;
- necessidades regulatórias específicas.
Para esses cenários, a Microsoft anunciou o modelo de Customer-managed telephony providers.
O modelo previsto envolve aproximadamente:
Microsoft Entra ID │ ▼Routing Function │ ▼Azure Subscription │ ▼Telephony Provider │ ▼SMS / Voice
Mas isso deve ser encarado como uma exceção arquitetural, e não como desculpa para evitar modernização.
17. Administradores devem ser os primeiros
Se existe um grupo onde SMS deveria desaparecer rapidamente, são contas administrativas.
Especialmente:
Global AdministratorPrivileged Role AdministratorAuthentication AdministratorConditional Access AdministratorSecurity AdministratorExchange AdministratorSharePoint AdministratorIntune Administrator
Essas identidades possuem impacto enorme caso sejam comprometidas.
Minha recomendação seria:
Admin │ ▼Conditional Access │ ▼Authentication Strength │ ▼Phishing-resistant MFA │ ├── Passkey ├── FIDO2 └── Windows Hello
18. Break Glass merece atenção especial
Contas de emergência precisam ser avaliadas separadamente.
Não copie automaticamente a política de usuários comuns para contas Break Glass.
Essas contas precisam possuir uma estratégia própria de autenticação, armazenamento seguro das credenciais, monitoramento e exclusões cuidadosamente documentadas.
O objetivo é evitar dois extremos:
Conta extremamente protegida, mas inutilizável durante uma emergência.
ou
Conta disponível durante uma emergência, mas tão fraca que se torna uma porta dos fundos permanente.
19. Impactos positivos da mudança
A aposentadoria do SMS não deve ser vista apenas como problema.
Ela cria uma oportunidade para melhorar significativamente a postura de segurança.
Menor exposição a phishing
Passkeys reduzem drasticamente ataques baseados na captura de credenciais.
Redução da dependência de senhas
Menos senhas significa menos:
Password ResetPassword SprayCredential StuffingPhishingHelp Desk Reset
Melhor experiência
O usuário pode autenticar utilizando biometria/PIN sem digitar senha e código SMS.
Melhor governança
Authentication Methods + Conditional Access + Authentication Strength fornecem controles muito mais granulares.
Melhor alinhamento com Zero Trust
A identidade passa a utilizar mecanismos mais adequados ao princípio:
Verify explicitly.
20. Possíveis impactos negativos se nada for feito
Agora imagine o cenário oposto.
Chega fevereiro de 2027.
Centenas ou milhares de usuários continuam dependentes de SMS.
Resultado:
Usuário tenta acessar │ ▼SMS indisponível │ ▼Registro obrigatório │ ▼Usuário não sabe como proceder │ ▼Service Desk │ ▼Volume massivo de chamados
Os principais riscos serão:
- interrupção de acesso;
- aumento de chamados;
- usuários sem dispositivo compatível;
- processos de recuperação inadequados;
- executivos impactados;
- administradores sem método alternativo;
- aplicações/processos dependentes de telefonia;
- comunicação emergencial;
- pressão para criação de exceções inseguras.
Ou seja:
O maior risco da mudança pode não ser tecnológico. Pode ser operacional.
21. Minha recomendação para os próximos 30 dias
Não espere janeiro.
Eu começaria agora.
Semana 1
Inventário dos métodos existentes.
Semana 2
Definição da arquitetura de autenticação futura.
Semana 3
Piloto de Passkeys/FIDO2.
Semana 4
Primeira política de Authentication Strength.
Depois:
Setembro ↓Discovery + PilotOutubro ↓Admins + TINovembro ↓Primeiras ondasDezembro ↓ExpansãoJaneiro ↓Remediação01/02/2027 ↓Ambiente preparado
Janeiro não deveria ser o mês da migração.
Deveria ser o mês de remediação das últimas exceções.
22. Checklist para administradores
Antes de considerar seu tenant preparado, valide:
- Inventário de usuários SMS/Voice realizado
- Authentication Methods Policy revisada
- Passkeys habilitadas
- Piloto realizado
- Windows Hello avaliado
- FIDO2 avaliado para administradores
- Temporary Access Pass configurado
- Authentication Strength criada
- Conditional Access revisado
- Contas administrativas protegidas
- Break Glass revisado
- Service Desk treinado
- Documentação publicada
- Comunicação enviada
- Processo para perda/troca de dispositivo definido
- Exceções documentadas
- Métricas de adoção criadas
- Plano para fevereiro de 2027 aprovado
23. O erro seria simplesmente trocar SMS pelo Authenticator
Essa mudança representa algo maior.
Se tratarmos o projeto simplesmente como:
SMS ↓Authenticator
estaremos perdendo uma excelente oportunidade.
A evolução deveria ser:
Password + SMS │ ▼Modern Authentication │ ▼Passwordless │ ▼Passkeys / FIDO2 │ ▼Authentication Strength │ ▼Conditional Access │ ▼Zero Trust Identity
Esse é o verdadeiro projeto.
Conclusão
Durante anos, a discussão foi:
“Sua organização possui MFA?”
Essa pergunta já não é suficiente.
A pergunta moderna é:
“Sua organização utiliza autenticação resistente a phishing?”
A aposentadoria do SMS e das chamadas de voz fornecidas pela Microsoft representa mais uma etapa dessa transformação.
A partir de setembro de 2026, a transição já começa a aparecer para usuários habilitados para SMS e voz.
Em fevereiro de 2027, a mudança deixa de ser opcional.
Organizações que começarem agora poderão utilizar os próximos meses para testar, aprender, comunicar e migrar progressivamente.
As que esperarem janeiro provavelmente transformarão um projeto de segurança em um projeto emergencial.
Portanto, talvez o melhor resumo seja:
Não estamos apenas aposentando o SMS. Estamos aposentando uma geração de autenticação baseada em credenciais facilmente transferíveis e caminhando para uma identidade baseada em criptografia e resistência a phishing.
E isso é uma excelente oportunidade para rever toda a arquitetura de identidade da organização.
Referências oficiais Microsoft
Microsoft Entra ID — Passkeys by default and retirement of Microsoft-provided SMS and voice authentication
Microsoft Learn.
Microsoft Entra ID — Frequently asked questions about SMS and voice retirement
Microsoft Learn.
Microsoft Entra ID — Passkeys (FIDO2) authentication method
Microsoft Learn.
Microsoft Entra ID — Enable Passkeys (FIDO2)
Microsoft Learn.
Microsoft Entra ID — Authentication Methods
Microsoft Learn.
Microsoft Entra ID — Authentication Strengths
Microsoft Learn.
Microsoft Entra ID — Temporary Access Pass
Microsoft Learn.
Blog do Chesley — Microsoft 365 na prática: do planejamento ao troubleshooting
chesley.com.br
Este artigo faz parte da série “Microsoft 365 — Prepare-se para a mudança”. No próximo artigo: EWS começa a ser desabilitado — como preparar suas aplicações para Microsoft Graph.