MFA: por que a autenticação multifator é essencial

A autenticação multifator, ou MFA, deixou de ser um recurso opcional para se tornar exigência padrão em provedores de nuvem como AWS, Azure e Google Cloud. Neste artigo, explicamos o que é MFA, por que nem todo segundo fator oferece o mesmo nível de proteção e como implantar a autenticação multifator de forma organizada, priorizando as contas críticas primeiro.

O que é MFA e por que a senha sozinha não basta

MFA (Multi-Factor Authentication, ou autenticação multifator) exige que o usuário comprove sua identidade com pelo menos dois fatores diferentes antes de acessar um sistema. Isso reduz o risco de invasão mesmo quando uma senha vaza, é reutilizada ou é adivinhada.

A Microsoft, com base em pesquisa sobre contas Entra ID/Azure AD, estima que o uso de MFA reduz o risco de comprometimento de conta em cerca de 99,22% em geral e em 98,56% mesmo quando a senha já foi exposta. Ou seja: a senha continua importante, mas não é mais suficiente como única barreira.

No Brasil, a LGPD (Lei 13.709/2018), em seu artigo 46, exige que agentes de tratamento adotem medidas técnicas e administrativas capazes de proteger dados pessoais de acessos não autorizados. A ANPD reforça esse ponto no Guia Orientativo de Segurança da Informação para Agentes de Tratamento de Pequeno Porte (v1.0, out. 2021), que recomenda MFA como medida técnica mínima para acesso a sistemas, bancos de dados e ambientes de nuvem, inclusive para pequenas organizações.

Tipos de fator: nem todo "segundo fator" é igual

De forma geral, os fatores de autenticação se dividem em três categorias:

• Algo que você sabe: senha, PIN ou resposta a uma pergunta de segurança.
• Algo que você tem: um aplicativo autenticador, um token físico, uma chave de segurança FIDO2 ou um código enviado por SMS.
• Algo que você é: biometria, como impressão digital ou reconhecimento facial.

Combinar dois fatores já é MFA, mas a robustez de cada combinação varia bastante. Um código por SMS e uma chave de segurança FIDO2 são tecnicamente "um segundo fator", mas resistem de forma muito diferente a ataques reais.

MFA resistente a phishing: FIDO2, WebAuthn e passkeys

Métodos como SMS, e-mail com código de uso único (OTP) e notificações push simples são vulneráveis a técnicas de phishing em tempo real, conhecidas como adversary-in-the-middle (AiTM), em que o atacante intercepta a sessão entre o usuário e o site legítimo. Também são alvo do chamado "MFA fatigue" ou prompt bombing, quando o atacante dispara várias solicitações de aprovação até que o usuário aceite por cansaço ou distração.

Segundo cobertura do Verizon DBIR 2025, o prompt bombing aparece em cerca de 14% dos incidentes envolvendo MFA, enquanto ataques de AiTM e troca de SIM (SIM swapping) respondem por cerca de 4%. Esses números mostram que MFA reduz o risco, mas não elimina todos os vetores de ataque quando o método escolhido é fraco.

O NIST SP 800-63B (Digital Identity Guidelines) organiza a força da autenticação em três níveis de garantia, chamados AAL1, AAL2 e AAL3. Apenas autenticadores criptográficos com vínculo de canal e de verificador (channel/verifier binding), como os baseados no padrão FIDO2/WebAuthn, incluindo passkeys e chaves de segurança físicas, são considerados resistentes a phishing e atendem ao nível mais alto, AAL3. Isso acontece porque a credencial fica vinculada à origem (domínio) do site legítimo: um site falso simplesmente não consegue completar a autenticação, mesmo que o usuário seja enganado a visitá-lo.

Senha, OTP e verificação por canal externo (como SMS) não são considerados resistentes a phishing pelo NIST. Isso não significa que devam ser descartados, especialmente em organizações menores, mas sim que devem ser tratados como um piso mínimo, não como o padrão ideal para contas sensíveis.

O que AWS, Azure e Google Cloud já exigem

Os três grandes provedores de nuvem tornaram o MFA obrigatório nos últimos dois anos, cada um com seu próprio cronograma:

• AWS: MFA é obrigatório para o usuário root em todos os tipos de conta, contas standalone e de management desde maio/junho de 2024, e contas member desde junho de 2025. A AWS suporta passkeys FIDO2 e chaves de segurança certificadas FIDO, com até oito dispositivos MFA por usuário.
• Microsoft Azure/Entra: a exigência foi dividida em duas fases. A fase 1, a partir de outubro de 2024, cobre o portal Azure, o Entra admin center, o Intune admin center e, desde fevereiro de 2025, o M365 admin center. A fase 2, a partir de 1º de outubro de 2025 (com possibilidade de adiamento até 1º de julho de 2026), passa a exigir MFA também no Azure CLI, PowerShell, aplicativo mobile, ferramentas de infraestrutura como código e chamadas de API REST para operações de criação, atualização e exclusão. Um efeito colateral importante: o fluxo legado ROPC (usuário e senha direto) deixa de funcionar quando o MFA está habilitado.
• Google Cloud: a verificação em duas etapas (2-Step Verification) passou por um rollout em três fases, concluído até o fim de 2025. A fase 2, obrigatória desde 12 de maio de 2025, já cobria o console, o gcloud CLI e o Firebase console.

Como esses prazos envolvem janelas de adiamento e podem ser ajustados pelos provedores, vale sempre checar a documentação oficial de cada plataforma na data em que você estiver planejando a implantação.

Como as normas tratam a autenticação multifator

Além da LGPD e do guia da ANPD, outras referências ajudam a definir o nível de exigência adequado:

• O NIST SP 800-63B, como já mencionado, define os níveis AAL1 a AAL3 e estabelece o que conta como autenticação resistente a phishing.
• O CIS Controls v8.1, no Controle 6 (Access Control Management), exige MFA para todo acesso administrativo em ativos empresariais e recomenda especificamente MFA resistente a phishing, como FIDO2, para usuários de alto risco.
• A ISO/IEC 27001:2022, no Anexo A, traz o controle 8.5 sobre autenticação segura, que serve como referência geral dentro de um sistema de gestão de segurança da informação certificável.

Vale um ponto de atenção: o guia da ANPD, publicado em 2021, cita SMS e tokens como exemplos aceitáveis de MFA para pequenas organizações. Isso continua válido como piso mínimo, mas as referências técnicas mais recentes, como o NIST e o CIS, e a experiência de ataques reais registrada no Verizon DBIR 2025, deixam claro que SMS é o método mais frágil disponível. Ele não deve ser tratado como equivalente a uma chave de segurança FIDO2 na proteção de contas administrativas ou de acesso a dados sensíveis.

Implantação sem atrito: passo a passo e erros comuns

Implantar MFA em toda a organização de uma vez costuma gerar resistência. Uma abordagem faseada tende a funcionar melhor:

1. Comece pelas contas de maior risco: usuários root, contas de administrador global e funções privilegiadas (como Global Admin, Security Admin ou Privileged Role Admin no Azure/Entra) devem receber MFA resistente a phishing primeiro, via políticas de acesso condicional combinadas com exigência de força de autenticação.
2. Use recursos de transição para registrar métodos fortes: no ecossistema Microsoft, o Temporary Access Pass permite que um usuário registre uma chave FIDO2 ou passkey sem depender de um segundo fator que ele ainda não possui.
3. Mantenha contas de emergência protegidas, não isentas: contas de break-glass costumam ficar fora de políticas específicas de acesso condicional para evitar bloqueios acidentais, mas ainda precisam de MFA forte, idealmente FIDO2 ou baseado em certificado, dentro da exigência geral obrigatória.
4. Migre contas de serviço e automações: em vez de tentar aplicar MFA de usuário a contas de automação, migre para identidades gerenciadas (managed identities) ou workload identities, que foram desenhadas justamente para eliminar credenciais estáticas nesses cenários.
5. Desative fluxos legados incompatíveis: revise se algum processo ainda depende de ROPC (usuário e senha direto) ou de outros fluxos que param de funcionar quando o MFA é habilitado, e ajuste antes de forçar a exigência.

Alguns erros aparecem com frequência nesse processo: excluir contas de automação da política de MFA sem migrá-las para uma identidade gerenciada, deixar fluxos legados como o ROPC ativos "por segurança", e adotar SMS como único método disponível para todos os usuários, mesmo em contas administrativas.

Conclusão

MFA não elimina todo risco, mas reduz de forma significativa a chance de uma conta ser comprometida, principalmente quando o método escolhido é resistente a phishing, como FIDO2, WebAuthn ou passkeys. Priorizar contas administrativas e root, seguir os prazos já definidos por AWS, Azure e Google Cloud, e alinhar a implantação a normas como LGPD, NIST SP 800-63B e CIS Controls ajuda a construir um ambiente de nuvem mais seguro sem travar a operação do dia a dia.

Se sua empresa ainda está organizando essa transição ou quer revisar como o MFA está configurado hoje, a equipe da Cloud Minds Trusted pode ajudar a planejar essa implantação de forma estruturada, priorizando o que importa primeiro.