Dump de produção restaurado na máquina, você abre o /admin e o Magento pede o código do autenticador. O e-mail com o QR nunca vai chegar, porque o ambiente local não manda e-mail. Resolve na CLI — e só no local: em produção, admin sem dois fatores é convite pra tomarem o painel.
Os dois módulos têm que cair juntos
Do 2.4.6 em diante não basta derrubar o Magento_TwoFactorAuth. A Adobe separou a integração com o Adobe IMS num módulo próprio, o Magento_AdminAdobeImsTwoFactorAuth, que pede magento/module-two-factor-auth no composer.json dele. Desligar só um faz o comando abortar reclamando de dependência. Os dois no mesmo module:disable resolvem:
cd /var/www/loja
bin/magento module:disable Magento_TwoFactorAuth Magento_AdminAdobeImsTwoFactorAuth
bin/magento module:status Magento_TwoFactorAuth
bin/magento cache:flushSe a cópia está em modo production, o cache:flush não basta — o próprio comando avisa que os arquivos gerados foram limpos e manda rodar o setup:di:compile. Sem isso o admin volta com erro de classe não encontrada. Se o módulo tinha view files, o module:disable ainda aceita a flag –clear-static-content.
A armadilha do app/etc/config.php
module:disable não é configuração de ambiente: ele grava 0 na lista de módulos do app/etc/config.php, arquivo que na maioria dos projetos está versionado no Git. Commitou sem olhar e o próximo deploy leva o dois fatores desligado pra loja de verdade.
O que eu faço aqui é desligar, trabalhar e devolver o arquivo antes de subir qualquer coisa, com um git checkout app/etc/config.php. Se o time inteiro usa a mesma base, vale combinar que esse arquivo nunca entra em commit de tarefa.
Precisa manter o 2FA ligado e só perdeu o segredo de um usuário? O Magento_TwoFactorAuth expõe security:tfa:reset, security:tfa:providers e security:tfa:google:set-secret. Um bin/magento list security mostra o que a sua versão tem — dá pra resetar o provedor de um admin específico sem derrubar o módulo pra todo mundo.