Ativar MFA já não basta: os erros de configuração que continuam abrindo a porta para invasores

O discurso de segurança adora tratar MFA como ponto final. Ligou, resolveu. Na prática, não é assim que os incidentes acontecem. O gatilho desta pauta veio de uma discussão recente no Reddit sobre o relatório anual da Talos, que voltou a destacar bypass de MFA, phishing interno e ataques de identidade em escala. Quando isso se cruza com um alerta mais frio e menos marketeiro da CISA e da NSA, a conclusão fica desconfortável: muita organização madura ainda perde no básico operacional. E o problema raramente é “falta de ferramenta”. É desenho ruim, exceção demais e pouca visibilidade.

O problema não é a ideia da MFA; é a implementação frouxa

Autenticação multifator continua sendo essencial. O erro é tratá-la como selo de conformidade. A própria CISA, em conjunto com a NSA, colocou métodos fracos ou mal configurados de MFA entre as dez misconfigurações mais comuns encontradas em avaliações de segurança em mais de mil ambientes. Isso importa porque tira a discussão do terreno da opinião: não estamos falando de um detalhe raro, mas de um padrão recorrente.

Na vida real, “ter MFA” pode significar coisas muito diferentes. Pode ser uma política rigorosa para contas privilegiadas, com autenticação resistente a phishing e cobertura de exceções. Ou pode ser apenas um push no celular, cheio de bypass, legado tolerado e fluxos alternativos esquecidos. Essas duas realidades aparecem igual no slide do board, mas se comportam de forma muito diferente quando um atacante começa a pressionar a operação.

Por que identidade virou o caminho mais curto para o ataque

Atacantes gostam de atalhos. Explorar uma cadeia técnica complexa é caro, barulhento e nem sempre reproduzível. Convencer um usuário, abusar de um fluxo de login mal protegido ou capturar uma sessão válida costuma ser mais barato. É por isso que campanhas modernas insistem tanto em roubo de credenciais, fadiga de notificações, engenharia social contra help desk e abuso de fluxos legítimos de autenticação.

O efeito colateral é perigoso: equipes que investiram pesado em EDR, firewall e patching às vezes continuam expostas porque a superfície de identidade ficou desorganizada. O ambiente parece endurecido, mas o invasor entra pela porta que ainda atende “exceções temporárias” há meses.

O que normalmente dá errado, mesmo em ambientes razoavelmente maduros

Há um conjunto de falhas que se repete. A primeira é a convivência entre políticas modernas e legados tolerados sem prazo real para desativação. A segunda é a separação ruim entre conta administrativa e conta de uso diário. A terceira é deixar o help desk resolver urgências operacionais sem controles fortes para redefinição de senha, re-registro de fator ou recuperação de acesso.

Também pesa a cobertura desigual. MFA forte para diretoria e TI, enquanto terceiros, contas de serviço, acessos de integração e usuários “temporariamente isentos” ficam fora do radar. O atacante não precisa vencer a melhor política da empresa; basta encontrar a pior.

Push notification sozinha virou defesa frágil demais

A autenticação por push ainda é melhor do que senha isolada, mas seu limite ficou claro. Em ataques de fadiga, o usuário recebe sucessivas solicitações até aprovar por cansaço, confusão ou medo de interromper algum serviço legítimo. Em cenários de suporte falso, o invasor liga ou envia mensagem, cria urgência e orienta a vítima a “confirmar o acesso para corrigir um erro”.

Esse tipo de ataque funciona porque transforma o fator adicional em simples clique de aprovação. Quando a experiência do usuário é “aceitar ou bloquear” sem contexto suficiente, a margem para erro humano continua alta. Não é coincidência que a CISA recomende MFA resistente a phishing para contas privilegiadas e que o mercado esteja migrando para chaves FIDO2, passkeys e números de correspondência.

O ponto cego mais caro: recuperação de conta e suporte

Muita organização endurece o login e esquece o que acontece quando a pessoa perde o aparelho, troca de número ou é bloqueada. É aí que o help desk vira alvo. Se o processo de recuperação depende de validações fracas, dados fáceis de obter ou pressão operacional para “resolver rápido”, a defesa inteira perde consistência.

Na prática, o fluxo de recuperação precisa ser tratado como ativo crítico. Não adianta exigir segundo fator no login se um atacante consegue registrar um novo autenticador após responder perguntas previsíveis ou convencer um atendente com informações públicas do LinkedIn.

MFA sem telemetria vira aposta, não controle

Outro erro comum é medir adoção, mas não medir abuso. O dashboard mostra percentual de usuários com MFA habilitada, porém quase ninguém acompanha rejeições sucessivas, picos de prompts, pedidos de reset de fator, novos registros de autenticador e mudanças fora de padrão geográfico ou temporal.

Isso conversa diretamente com outro alerta da CISA/NSA: monitoramento interno insuficiente segue entre as misconfigurações mais comuns. Em identidade, essa falta de telemetria custa caro. Sem logs bons e sem correlação mínima, o time percebe o ataque tarde demais — normalmente quando a sessão já foi validada e o movimento lateral começou.

O que fazer na prática para sair do teatro de segurança

Não existe bala de prata, mas existe ordem de prioridade. A recomendação mais sensata hoje é tratar MFA como parte de uma arquitetura de identidade, não como item isolado de checklist.

• Priorize MFA resistente a phishing para administradores, acesso remoto, e-mail corporativo e consoles críticas.
• Revise exceções ativas e coloque prazo real para cada uma. Exceção sem vencimento vira regra escondida.
• Separe contas administrativas de contas de produtividade. Admin não deve navegar, ler e-mail e operar rotina comum.
• Endureça recuperação de conta com múltiplas validações, registro auditável e regras específicas para help desk.
• Monitore eventos de identidade: rejeições em massa, múltiplos prompts, resets, novas inscrições de fator e alterações de método.
• Reduza fluxos legados e autenticações alternativas pouco usadas. Todo caminho paralelo precisa justificar sua existência.
• Faça simulações realistas de social engineering voltadas a suporte e usuários privilegiados, não só phishing genérico.

Onde a liderança erra na leitura do risco

Há um vício de governança aí: investir em tecnologia visível e subestimar fricções operacionais. MFA forte costuma perder orçamento ou patrocínio quando incomoda jornada de acesso, onboarding de terceiros ou plantão do suporte. O custo aparece na hora; o benefício, só quando o incidente não acontece. Isso empurra decisões ruins para debaixo do tapete.

O resultado é uma arquitetura remendada: políticas boas no papel, exceções herdadas, suporte pressionado e pouca coragem para desligar o que já deveria ter morrido. É um risco silencioso porque não gera alarme diário. Só explode quando coincide com campanha ativa de engenharia social.

Checklist prático para revisar sua MFA nos próximos 30 dias

• Mapeie quais métodos de MFA estão realmente em uso e quais ainda aceitam aprovação simples por push.
• Liste todas as exceções por usuário, grupo, aplicação e integração.
• Confirme se contas privilegiadas usam método resistente a phishing.
• Revise o processo de reset de senha, re-registro de autenticador e recuperação de conta.
• Audite quem pode aprovar exceções e por quanto tempo elas permanecem válidas.
• Ative alertas para rajadas de prompts, múltiplas rejeições e novas inscrições de fator.
• Teste um cenário de engenharia social contra help desk com observação formal de falhas.
• Desative ou coloque em cronograma claro os fluxos legados que ainda escapam das políticas principais.

FAQ

MFA ainda vale a pena se pode ser burlada?
Sim. O problema não é usar MFA, e sim achar que qualquer MFA entrega o mesmo nível de proteção. Métodos resistentes a phishing continuam elevando muito o custo do ataque.

Push notification deve ser abandonada de vez?
Nem sempre, mas ela não deveria ser sua defesa mais crítica sem camadas extras, como number matching, contexto de login, políticas condicionais e monitoramento.

Pequenas e médias empresas também precisam se preocupar com isso?
Sim. PMEs tendem a sofrer ainda mais com exceções improvisadas, suporte sobrecarregado e pouca visibilidade. Justamente por isso, simplificar a arquitetura de identidade é ainda mais importante.

O foco deve ficar só em usuários internos?
Não. Terceiros, parceiros, prestadores e contas administrativas terceirizadas costumam concentrar exceções perigosas e precisam entrar na revisão.

Conclusão

A lição incômoda de 2026 é simples: ativar MFA continua necessário, mas já não basta para sustentar uma narrativa de maturidade. Quando o desenho é frouxo, o fator adicional vira ritual de confirmação — não barreira. Se a sua organização ainda mede sucesso apenas por “percentual com MFA habilitada”, provavelmente está olhando para o indicador errado. O que separa ambiente maduro de teatro de segurança é governança das exceções, recuperação de conta forte, telemetria e coragem para eliminar legados convenientes.

Referências

• Reddit / r/cybersecurity — discussão recente sobre o relatório anual da Cisco Talos, destacando bypass de MFA, phishing interno e ataques de identidade.
• CISA + NSA — Top Ten Cybersecurity Misconfigurations: https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-278a
• CISA — Implementing Phishing-Resistant MFA: https://www.cisa.gov/resources-tools/resources/implementing-phishing-resistant-mfa