Na prática, o “MFA fatigue” deixou de ser um detalhe técnico e virou um problema de operação. Em um tópico recente no Reddit, um administrador descreveu o terceiro caso no mês de usuários bombardeados por notificações de login a cada 30 segundos, até alguém clicar em “aprovar” só para o barulho parar. O relato é desconfortável porque parece comum: controles corretos no papel, mas um fluxo de autenticação desenhado para cansar gente real. Este artigo é sobre como sair desse ciclo sem cair em modismo.
O gatilho: quando o Reddit descreve exatamente o que o SOC já vê
O post em questão não traz uma “falha zero-day”. Traz algo mais relevante para times de segurança: comportamento humano previsível sob pressão. O cenário relatado é clássico. Credenciais vazadas ou capturadas por phishing alimentam tentativas de login em massa. O sistema dispara push de MFA para o usuário legítimo. O atacante insiste até que a vítima, irritada ou distraída, aprove uma requisição fraudulenta.
O valor do Reddit, aqui, não é substituir inteligência de ameaças formal. É funcionar como sensor de campo. Quando dezenas de profissionais descrevem a mesma dor — aprovação indevida, help desk sobrecarregado, gestão desconfiando de “falso positivo” — isso indica uma fricção sistêmica. O problema não é apenas “usuário mal treinado”; é uma arquitetura de autenticação que ainda delega a decisão crítica para o momento de maior cansaço cognitivo.
É nesse ponto que o debate costuma escorregar para extremos: “MFA não serve” versus “treina mais que resolve”. Nenhum dos dois sustenta operação séria. MFA continua essencial, mas alguns métodos estão mais expostos a engenharia social. A decisão madura não é abandonar MFA; é subir a barra para métodos resistentes a phishing e redesenhar o processo de resposta quando sinais de fadiga aparecem.
O que as fontes oficiais dizem (e o que isso muda no dia a dia)
A CISA vem repetindo uma mensagem objetiva: organizações devem priorizar MFA resistente a phishing; se isso ainda não for possível em toda a base, usar number matching como mitigação intermediária em apps de autenticação por push. Essa hierarquia importa porque reduz espaço para interpretações políticas do tipo “vamos manter como está até o próximo ciclo orçamentário”.
No ecossistema Microsoft Entra, por exemplo, number matching já é tratado como reforço de segurança para notificações push: o usuário não só aprova, ele precisa digitar o número exibido na tela de login. Isso derruba ataques oportunistas de clique automático e reduz aprovações por reflexo.
OWASP mantém a mesma linha estratégica, com um lembrete útil para liderança: qualquer MFA é melhor que nenhum, mas fatores diferentes têm riscos diferentes. E NIST, ao estruturar níveis de garantia de autenticação, ajuda a lembrar que não existe “controle mágico”; existe combinação de autenticador, política de sessão, recuperação de conta e proteção de canal.
Em português claro: se seu programa de identidade ainda mede sucesso por “percentual de usuários com MFA ativo”, você está olhando o indicador errado. O indicador certo é “percentual de usuários em métodos resistentes a phishing + taxa de aprovações suspeitas + tempo para contenção”.
Por que push puro virou superfície de ataque
Push MFA foi adotado em massa por três motivos: conveniência, baixo atrito de implantação e boa aceitação de usuário. Só que exatamente essa conveniência cria a brecha. A notificação chega em contexto desconectado da ação original; o usuário precisa decidir rápido, muitas vezes no celular, sem visibilidade real de risco. Sob repetição, vira ruído. Sob ruído, vira erro.
Ataques de fadiga exploram quatro pontos simultaneamente:
- Assimetria de esforço: para o atacante, disparar tentativas é barato; para a vítima, cada pop-up custa atenção.
- Ambiguidade contextual: a notificação raramente explica com clareza se o login é esperado.
- Pressão temporal: usuários em reunião, trânsito ou fim de expediente aprovam para “resolver depois”.
- Escalada social: após o bombardeio, atacante liga ou envia mensagem fingindo ser TI.
Quando a empresa insiste no discurso “o usuário precisa ser mais cuidadoso”, ela terceiriza uma falha de desenho para a ponta mais frágil. Treinamento é necessário, mas sozinho não corrige um mecanismo que foi feito para priorizar velocidade, não prova forte de presença.
Biometria, passkeys e FIDO2: promessa real, hype e limites
No tópico do Reddit, aparece a pergunta que toda diretoria faz: “então biometria resolve?”. A resposta curta: depende do modelo de implementação. Biometria sozinha, sem vínculo criptográfico forte com o serviço, pode só trocar um risco por outro. Já passkeys e autenticação baseada em padrões FIDO2/WebAuthn elevam bastante a resiliência porque usam criptografia assimétrica atrelada ao domínio legítimo, dificultando phishing clássico.
A FIDO Alliance reforça esse ponto ao tratar passkeys como credenciais resistentes a phishing. O ganho não é só segurança: há impacto operacional em taxa de sucesso de login e redução de reset de senha. O Google, ao empurrar passkeys como padrão para contas pessoais, sinaliza que a tecnologia saiu da fase “laboratório corporativo” e entrou em escala de consumo.
Mas há limites práticos que o discurso comercial costuma esconder:
- Ambientes legados (VPN antiga, apps internos, integrações on-prem) nem sempre suportam WebAuthn sem projeto de adaptação.
- Processos de recuperação de conta podem reabrir a porta para engenharia social se não forem redesenhados.
- Governança de dispositivos precisa ser madura: passkey em dispositivo não gerenciado pode criar risco de continuidade.
- Rollout global sem segmentação gera resistência e queda de produtividade.
Ou seja: passkeys não são bala de prata, mas hoje representam o caminho mais consistente para reduzir MFA fatigue sem jogar a experiência do usuário no lixo.
Plano de migração em 90 dias (sem paralisar o negócio)
O erro comum é tentar “virar a chave” para toda a empresa em um anúncio único. Segurança de identidade funciona melhor em ondas, com métricas claras por fase. Um roteiro realista de 90 dias pode seguir esta lógica:
Dias 1–15: diagnóstico operacional. Mapear métodos de autenticação por aplicação, identificar populações de alto risco (admin, finanças, RH, suporte), levantar taxa de prompts negados e aprovações fora de padrão de horário/local.
Dias 16–30: endurecimento imediato. Ativar number matching onde houver push, reduzir janela de aprovação, limitar tentativas consecutivas, reforçar telemetria de risco e gatilhos automáticos para reset de credencial após padrão anômalo.
Dias 31–60: piloto resistente a phishing. Selecionar 1 ou 2 unidades de negócio para adoção de passkeys/FIDO2. Medir falha de login, chamados no service desk, tempo de onboarding e satisfação de usuário.
Dias 61–90: expansão por criticidade. Priorizar contas privilegiadas e sistemas críticos. Publicar política de exceção com prazo, dono e contramedidas temporárias. Exceção sem prazo vira dívida permanente.
Esse plano evita dois riscos: a paralisia por perfeccionismo e a implantação apressada que quebra operação. Segurança madura é progressiva, mas irreversível na direção certa.
Como convencer liderança sem cair no argumento do medo
Board e C-level reagem melhor a risco traduzido em impacto de negócio do que a jargão técnico. Em vez de apresentar “MFA fatigue” como moda de threat intel, conecte com três métricas que a diretoria entende:
- Risco financeiro: probabilidade de comprometimento de conta com acesso a pagamento, folha ou dados regulados.
- Risco operacional: horas perdidas em incidentes de credencial, bloqueios e revalidações emergenciais.
- Risco reputacional/compliance: exposição pública de acesso indevido por falha evitável de autenticação.
Em paralelo, leve trade-offs transparentes. Exemplo: “migração para passkeys pode elevar chamados na primeira semana, mas tende a reduzir reset de senha e incidentes de aprovação indevida no trimestre”. Liderança confia mais quando vê custo de transição explicitado, não escondido.
Outro ponto decisivo: tratar identidade como programa de produto, não como projeto pontual. Dono definido, backlog, métricas mensais e revisão executiva curta. Sem isso, a organização troca ferramenta, mas mantém o mesmo risco estrutural.
Checklist prático para reduzir MFA fatigue agora
- Ative number matching em todos os fluxos push compatíveis.
- Desative SMS como fallback padrão para perfis críticos; use apenas com política de exceção.
- Aplique política diferente para contas privilegiadas (método resistente a phishing obrigatório).
- Configure detecção de “push storm” (múltiplos prompts em curto intervalo) com bloqueio automático.
- Force reset de credenciais quando houver sequência de recusas suspeitas + tentativa bem-sucedida posterior.
- Integre IAM e SOC para abrir incidente automaticamente quando padrão de fadiga for detectado.
- Reescreva o texto da notificação para contexto claro: app, local aproximado, horário e ação esperada.
- Faça tabletop exercise trimestral simulando ataque de fadiga com engenharia social por voz.
- Revise processo de recuperação de conta para evitar bypass humano sem validação forte.
- Defina meta executiva: percentual de usuários em métodos phishing-resistant por trimestre.
Erros comuns que mantêm o problema vivo
Erro 1: acreditar que campanha de conscientização resolve sozinha. Treinamento reduz risco, mas não elimina a mecânica de abuso do push.
Erro 2: medir adoção, não efetividade. “95% com MFA” pode esconder 95% em método vulnerável a fadiga.
Erro 3: permitir exceções indefinidas. Cada exceção sem data de expiração vira rota alternativa para atacante.
Erro 4: negligenciar help desk. Se o time de suporte não tiver playbook claro, incidentes de identidade viram fila e ruído.
Erro 5: ignorar UX de segurança. Quanto mais confuso o fluxo de aprovação, maior a chance de clique errado sob estresse.
Evitar esses erros custa menos do que responder incidente recorrente. E, diferente do que se imagina, melhora experiência do usuário quando bem executado.
FAQ — dúvidas diretas de quem precisa decidir rápido
MFA push deve ser abandonado imediatamente?
Não em todos os cenários de uma vez. O caminho seguro é endurecer push agora (number matching, rate limit, detecção de abuso) e migrar progressivamente para métodos resistentes a phishing, priorizando contas críticas.
Passkey substitui senha e MFA ao mesmo tempo?
Em muitos fluxos, sim: ela reduz dependência de senha e elimina o segundo fator separado, porque a autenticação já nasce com prova criptográfica forte vinculada ao dispositivo e ao serviço legítimo.
Biometria é obrigatória para passkey?
Não. Passkey pode usar biometria, PIN ou padrão do dispositivo. O elemento central é a credencial criptográfica FIDO, não o tipo de desbloqueio local.
Number matching resolve definitivamente MFA fatigue?
Não. É mitigação importante, mas ainda intermediária. Ataques mais sofisticados podem combinar engenharia social para contornar o ganho de segurança.
Qual primeiro grupo deve migrar?
Administradores, acesso a finanças, RH e contas com privilégios de suporte remoto. São perfis de alto impacto em caso de comprometimento.
Como provar retorno para a diretoria?
Acompanhe três curvas: queda de aprovações suspeitas, redução de incidentes de credencial e redução de chamados de reset/bloqueio após estabilização do rollout.
Conclusão editorial: segurança de identidade é escolha de desenho, não de discurso
O relato do Reddit incomoda porque expõe uma verdade operacional: quando o mecanismo de defesa depende de paciência infinita do usuário, ele já está quebrado. A boa notícia é que existe rota técnica e gerencial para sair disso. Começa com mitigação imediata no push, passa por governança de exceções e chega a autenticação resistente a phishing como padrão — não como projeto “premium” para poucos.
Se a sua organização ainda trata MFA fatigue como desatenção individual, você está combatendo efeito, não causa. O trabalho sério é redesenhar autenticação para o mundo real: pessoas cansam, atacantes insistem, sistemas precisam assumir essa realidade. Quem fizer essa transição agora vai gastar menos energia em incidente repetido e mais em segurança que realmente escala.
Referências
- Reddit (r/it) — “MFA fatigue attacks are getting out of control” (post de gatilho editorial).
- CISA — “CISA Releases Guidance on Phishing-Resistant and Numbers Matching Multifactor Authentication”.
- Microsoft Learn (Entra ID) — “How number matching works in MFA push notifications for Authenticator”.
- OWASP Cheat Sheet Series — “Multifactor Authentication Cheat Sheet”.
- NIST SP 800-63B — Digital Identity Guidelines (authentication assurance requirements).
- FIDO Alliance — documentação pública sobre passkeys e autenticação FIDO.
- Google Blog — “Passwordless by default: Make the switch to passkeys”.