Durante anos, muita empresa brasileira repetiu a mesma frase: “temos MFA, então estamos protegidos”. O problema é que os ataques evoluíram mais rápido que essa confiança. Nos últimos meses, discussões em comunidades técnicas no Reddit voltaram a expor um incômodo real: equipes que ativaram MFA tradicional (SMS, push sem controle, OTP por app) continuam sofrendo sequestro de sessão, fadiga de notificação e phishing com proxy reverso. A lição não é abandonar o MFA; é amadurecer para MFA resistente a phishing. Este artigo mostra, sem fantasia, como fazer essa migração com impacto operacional mínimo e ganho de segurança mensurável.
O que o Reddit está sinalizando (e por que isso importa)
O gatilho desta pauta veio de debates em r/cybersecurity, especialmente threads sobre “Phishing Resistant MFA” e proteção prática contra AiTM. O padrão das respostas é revelador: quase ninguém discute mais “se” deve migrar, e sim “como” fazer sem quebrar acesso de usuários, fornecedores e times de campo. Esse detalhe é importante porque desloca o tema do plano estratégico para a execução.
Quando profissionais que operam ambiente real convergem para o mesmo ponto de dor, vale prestar atenção. As perguntas recorrentes foram: como lidar com legados que não suportam FIDO2? Como substituir push notification sem gerar avalanche de chamados? Como controlar contas privilegiadas antes de migrar toda a base? Em vez de teoria, a comunidade fala de rollout por grupos, janela de convivência e métricas de adoção. É exatamente esse pragmatismo que falta em muitos programas de IAM.
O Reddit não é fonte normativa, mas é um ótimo sensor de fricção operacional. Use como radar: se dezenas de times com maturidade diferente relatam o mesmo vetor de ataque e o mesmo tipo de falha de processo, isso merece entrar no seu backlog com prioridade alta.
Por que MFA tradicional falha contra ataques modernos
Existe uma confusão comum: achar que qualquer segundo fator é equivalente em proteção. Não é. Métodos baseados em código interceptável (SMS, TOTP em cenário de phishing ativo) e aprovação cega de push podem ser contornados por atacantes que operam no meio da sessão. É aqui que entra o modelo AiTM (adversary-in-the-middle): o usuário acha que está no login legítimo, mas está em uma réplica intermediária que captura credenciais e token de sessão em tempo real.
Relatos recentes de mercado reforçam que plataformas de phishing-as-a-service reduziram a barreira técnica para esse tipo de ataque. Em linguagem direta: não é mais tática exclusiva de grupo muito sofisticado. Se a sua defesa de identidade depende de o usuário “perceber” um detalhe no navegador, você já está apostando contra probabilidade.
Além disso, há o problema da fadiga de MFA por push. Quando o usuário recebe múltiplas solicitações, a chance de aprovação acidental ou por pressão aumenta. CISA já recomenda explicitamente MFA resistente a phishing como prioridade e, quando não for possível no curto prazo, número de correspondência como mitigação intermediária. O recado é claro: push sem salvaguarda deixou de ser nível aceitável para contas críticas.
O que dizem as fontes de referência (CISA, NIST e casos reais)
As fontes técnicas convergem em três pontos. Primeiro: autenticação deve reduzir exposição a phishing e sequestro de sessão, não apenas adicionar uma etapa. Segundo: métodos com prova criptográfica vinculada à origem (como FIDO2/WebAuthn) são mais robustos porque não entregam segredo reutilizável ao atacante. Terceiro: migração bem-sucedida depende de arquitetura e governança, não só de ferramenta.
A CISA, em alertas e materiais sobre MFA, insiste em duas direções: adoção de métodos resistentes a phishing e uso de controles de transição (como number matching) para quem ainda está no meio do caminho. O caso público do USDA é útil porque mostra vida real: milhares de usuários em contextos não triviais, com limitação de credencial física tradicional, e ainda assim avanço por desenho incremental com FIDO.
Do lado normativo, o NIST SP 800-63B reforça que níveis maiores de garantia exigem autenticação mais forte e menor suscetibilidade a roubo de credencial. Mesmo que sua empresa não seja obrigada a seguir NIST formalmente, o documento funciona como régua técnica para separar percepção de controle de efetividade real.
Diagnóstico rápido: onde sua identidade está realmente exposta
Antes de comprar chave física para todo mundo, faça um diagnóstico orientado a risco. O erro clássico é iniciar por volume de usuários, quando deveria iniciar por superfície de impacto. Um recorte útil em 10 dias:
- Contas privilegiadas: admins de cloud, diretório, VPN, e-mail corporativo e ferramentas de código.
- Aplicações críticas: folha de pagamento, financeiro, ERP, CRM, painéis de operação.
- Métodos atuais por grupo: SMS, TOTP, push, token físico, passkey, FIDO2.
- Exceções sem dono: contas de serviço “temporárias” e acessos compartilhados.
- Incidentes dos últimos 12 meses: tentativas de phishing, aprovações indevidas, reset suspeito.
Com esse mapa, você define prioridade por impacto, não por conforto político. Se uma conta comprometida pode liberar pagamento, baixar base de cliente ou desativar proteção, ela entra na primeira onda. Não espere “projeto completo” para agir: segurança de identidade melhora em degraus.
Plano de migração em 4 fases (com baixo atrito operacional)
Fase 1 — Blindagem imediata (2 a 4 semanas): imponha number matching em push onde suportado, bloqueie MFA por SMS para contas privilegiadas, reduza janela de sessão, revise políticas de acesso condicional por risco e localização. Não resolve tudo, mas derruba ataque oportunista.
Fase 2 — Núcleo resistente a phishing (30 a 60 dias): migre administradores, SOC, finanças e liderança para passkeys/FIDO2. Exija pelo menos dois autenticadores registrados por pessoa (um principal, um backup) para evitar lockout em viagem ou troca de dispositivo.
Fase 3 — Escala por jornada (60 a 120 dias): avance por departamentos com suporte dedicado, comunicação simples e janela de coexistência curta. Treine service desk para os cinco problemas mais prováveis e prepare roteiro de autoatendimento.
Fase 4 — Limpeza de legado (contínua): desative métodos fracos gradualmente, elimine exceções sem SLA, atualize runbooks de incidente e auditoria. O ganho real aparece quando “atalho inseguro” deixa de existir tecnicamente, não quando vira recomendação no PDF.
O segredo desta sequência é reduzir atrito cognitivo. Usuário não precisa entender criptografia; precisa de instrução curta, fluxo previsível e suporte que resolve rápido. Quando a experiência é boa, a resistência cai.
Decisões difíceis que normalmente travam o projeto
“E os sistemas legados?” Alguns não suportam método moderno nativamente. Nesse caso, use camada de federação, proxy de identidade ou virtualização de acesso. O pior caminho é manter autenticação fraca indefinidamente “porque o sistema é antigo”.
“E quem não pode usar smartphone?” Tenha trilha com chave FIDO2 física corporativa, política de custódia e reposição. Inclusão operacional não significa reduzir segurança; significa oferecer alternativa segura equivalente.
“E terceiros e fornecedores?” Trate como população de alto risco por padrão. Acesso temporário com expiração automática, segmentação forte e exigência do mesmo nível de MFA para sistemas críticos.
“E custo?” O custo de rollout costuma ser visível. O custo de incidente de identidade raramente entra completo na conta (parada operacional, investigação, dano reputacional, horas improdutivas). Projetos maduros mostram ROI quando conectam custo de controle com redução de exposição material.
Editorialmente, este é o ponto: empresa que encara MFA resistente a phishing só como compra de token fracassa. É programa de mudança operacional com governança de identidade.
Checklist prático para executar nas próximas 6 semanas
- Classificar contas por criticidade e obrigar MFA resistente a phishing no grupo Tier 0/Tier 1.
- Habilitar number matching em métodos de push enquanto a migração completa não termina.
- Bloquear SMS e voz para contas administrativas e financeiras.
- Implementar política de dois autenticadores por usuário crítico (principal + contingência).
- Criar fluxo de recuperação de conta com verificação forte e trilha de auditoria.
- Revisar sessão e refresh token: reduzir persistência excessiva e exigir reautenticação por risco.
- Definir indicadores semanais: adesão, falhas de login, chamados de suporte e tentativas bloqueadas.
- Executar simulação de phishing para medir comportamento antes/depois da migração.
- Estabelecer prazo para desativar métodos legados por grupo, com responsável nomeado.
- Atualizar playbook de resposta a incidente focado em roubo de sessão e abuso de token.
Se você fizer apenas metade dessa lista com disciplina, já terá ganho concreto. O pior cenário é “iniciar tudo” e não concluir nada.
Métricas que mostram maturidade de verdade (não só conformidade)
Relatório bonito de compliance não basta. Você precisa de métricas que conversem com risco. Quatro métricas úteis:
- Cobertura resistente a phishing: percentual de contas críticas realmente migradas.
- Tempo de recuperação seguro: quanto tempo para restaurar acesso sem burlar política.
- Taxa de exceção ativa: quantas contas seguem em método fraco e por quanto tempo.
- Incidentes de identidade por trimestre: tendência após cada fase do rollout.
Inclua também um indicador de fricção: taxa de abandono no fluxo de registro do autenticador. Segurança que ninguém consegue usar vira desvio operacional em poucos dias. A métrica certa antecipa esse desvio.
Um trade-off explícito que equipes maduras assumem: no curto prazo, suporte aumenta; no médio prazo, incidentes e retrabalho caem. Ignorar esse vale de transição é o que mata o projeto na metade.
FAQ — dúvidas comuns na migração para MFA resistente a phishing
1) Passkey substitui senha imediatamente?
Depende do ecossistema e da política adotada. Em muitos ambientes, a transição é gradual, mantendo fallback controlado por período curto.
2) FIDO2 físico é obrigatório para todos?
Não necessariamente. Para perfis de alto risco, é altamente recomendado. Para demais usuários, passkeys em dispositivo gerenciado podem ser suficientes, conforme avaliação de risco.
3) Number matching resolve o problema sozinho?
Não. É mitigação intermediária útil contra fadiga de push, mas não substitui MFA resistente a phishing.
4) Como tratar contas de serviço?
Contas não humanas exigem estratégia própria: segredo rotativo, identidade de workload, escopo mínimo e monitoramento contínuo. Não misture com política de usuário humano.
5) Dá para migrar sem aumentar chamados?
Aumentar um pouco é normal. O objetivo é controlar o pico com comunicação clara, piloto bem escolhido e suporte preparado para casos recorrentes.
6) Qual o maior erro?
Adiar desativação do método legado “por mais um mês”. Sem data de corte, o projeto nunca termina.
Conclusão: identidade virou fronteira principal, trate como produto
O debate no Reddit acerta ao tirar o tema do discurso e trazer para a operação. MFA resistente a phishing não é luxo de empresa grande nem moda de fornecedor; é resposta prática a um tipo de ataque que já se popularizou. Quem continuar preso em MFA fraco vai manter a sensação de controle e a exposição real ao mesmo tempo.
A decisão madura é simples de enunciar e trabalhosa de executar: proteger primeiro quem, se comprometido, derruba o negócio. Comece por contas críticas, meça fricção e risco em paralelo, e elimine legado com prazo claro. Em segurança de identidade, a diferença entre “temos política” e “temos proteção” está na disciplina de rollout.
Referências
- Reddit r/cybersecurity — “Phishing Resistant MFA”: https://www.reddit.com/r/cybersecurity/comments/1h75q07/phishing_resistant_mfa/
- Reddit r/cybersecurity — “Practical ways to protect against AiTM phishing”: https://www.reddit.com/r/cybersecurity/comments/1h75rqp/practical_ways_to_protect_against_aitm_phishing/
- CISA — Alerta sobre MFA resistente a phishing e number matching (2022): https://www.cisa.gov/news-events/alerts/2022/10/31/cisa-releases-guidance-phishing-resistant-and-numbers-matching-multifactor-authentication
- CISA — Fact sheet “Implementing Phishing-Resistant MFA”: https://www.cisa.gov/sites/default/files/publications/fact-sheet-implementing-phishing-resistant-mfa-508c.pdf
- CISA — Caso USDA com FIDO: https://www.cisa.gov/resources-tools/resources/phishing-resistant-multi-factor-authentication-mfa-success-story-usdas-fast-identity-online-fido
- NIST SP 800-63B (Digital Identity Guidelines): https://pages.nist.gov/800-63-4/sp800-63b.html
- Proofpoint — Evolução de ataques AiTM em Microsoft 365 (2025): https://www.proofpoint.com/us/blog/email-and-cloud-threats/aitm-phishing-attacks-evolving-threat-microsoft-365