MFA obrigatório no painel: como exigir segundo fator sem trancar a equipe

Quase todo painel administrativo nasce com a autenticação multifator, o MFA, como item opcional no perfil. Um dia a decisão muda, por exigência de cliente ou susto interno, e ele passa a ser obrigatório para todo mundo.

A parte difícil não é a criptografia, é a transição: ela mexe na porta de entrada de quem já depende do sistema para trabalhar. O erro mais comum tem assinatura reconhecível: alguém liga a exigência para todas as contas de uma vez, no fim do expediente, e na manhã seguinte boa parte da equipe não entra. Não é bug, é consequência de ligar uma exigência antes de existir caminho para cumpri-la.

O laço de redirecionamento que tranca a equipe

O modo de falha clássico é este. A conta é marcada como "exige segundo fator" e nunca cadastrou nenhum. A tela de login valida a senha e pede o código; o usuário não tem código, porque não tem fator. Ele tenta a tela de cadastro do fator, e essa tela exige estar autenticado. Como a autenticação parou no meio, o guardião de rota o devolve ao login, que volta a pedir o código. Ele fica em um laço de redirecionamento entre duas telas, cada uma esperando que a outra resolva o problema.

A raiz é modelar autenticação como booleano: com dois estados apenas, anônimo e autenticado, não há onde colocar quem já provou a senha e ainda não tem fator. O desenho correto tem três: anônimo, autenticado por senha e pendente de fator, e plenamente autenticado. A sessão pendente é real, com identidade conhecida e poder mínimo: alcança o cadastro do primeiro fator e o encerramento de sessão, mais nada.

Daí a regra que ordena o resto: a exigência só pode ser ligada depois que existir um caminho de primeiro cadastro acessível a quem ainda não tem fator, e esse caminho é um passo obrigatório depois da senha e antes do painel, nunca um bloqueio pedindo para procurar um administrador. O passo termina verificando um código gerado pelo fator recém-cadastrado, senão um erro de leitura do QR code vira conta trancada. O NIST SP 800-63B, na revisão 4, dá a régua exata desse vínculo: cadastrar um autenticador novo exige autenticação no menor entre dois níveis de garantia, o maior já disponível na conta e aquele em que o autenticador novo vai ser usado. O próprio texto dá o exemplo: vincular um autenticador de segundo fator exige autenticação de segundo fator, a menos que a conta ainda só disponha de fator único. É essa regra que sustenta a sessão pendente como desenho legítimo.

A sequência de implantação que funciona

Ligar a chave é o último ato. A sequência que atravessa sem incidente tem cinco etapas: disponibilizar o cadastro voluntário e testá-lo com uma conta sem fator nenhum; medir a adesão por papel, porque um número geral confortável pode esconder que nenhum administrador aderiu; avisar com prazo e data explícita, por um canal que não seja o próprio painel; ligar a exigência primeiro para os papéis de maior poder, quem cria chave de API, altera webhook ou vê dado sensível; e só então estender a todos.

Quem ainda não aderiu precisa ficar visível: lista consultável pelo administrador e aviso persistente para o usuário. Medir por papel só é possível onde os papéis existem, como no desenho descrito no artigo sobre controle de acesso ao painel. Duas cautelas fecham o pacote: virar em horário com gente disponível para atender, nunca em véspera de fim de semana, e manter um interruptor que adie a exigência, com registro de quem acionou.

Escolha do fator: piso, degrau seguinte e elo fraco

O piso razoável é o aplicativo autenticador com senha de uso único baseada em tempo, o TOTP, definido pela RFC 6238 (2011), que estende o algoritmo baseado em contador da RFC 4226 trocando o contador por uma janela de tempo, com intervalo padrão de 30 segundos. Como o código depende do relógio, vale prever tolerância de janela e orientar a sincronizar a hora do aparelho.

O degrau seguinte é a chave de segurança ou passkey, pela especificação Web Authentication do W3C, cuja versão Level 3 é Recomendação de 25 de agosto de 2026. A credencial de chave pública é vinculada à origem, o que a torna resistente a phishing: um site clonado não consegue usá-la.

O elo mais fraco é a mensagem de texto. O NIST SP 800-63B, revisão 4 (julho de 2025), classifica o uso da rede telefônica pública para autenticação fora de banda como restrito e recomenda que o verificador considere indicadores de risco como troca de aparelho, troca de chip e portabilidade recente antes de usar o canal. Restrito não é proibido, mas explica por que o SMS não deve ser o único fator de uma conta administrativa, ponto que o artigo sobre o limite do SMS diante da troca de chip desenvolve. Aceitar dois fatores por conta reduz a demanda por recuperação.

Recuperação: o caminho mais perigoso do produto

E quando o aparelho quebra, é trocado ou é roubado? Há duas respostas, e as duas precisam existir.

A primeira são os códigos de recuperação salvos: emitidos no cadastro, exibidos uma única vez, guardados como hash, cada código valendo um uso só. O lugar de guardá-los é fora do sistema, em gerenciador de senhas ou cofre, nunca no canal do time nem no painel que eles destrancariam. O NIST SP 800-63B, revisão 4, é específico sobre eles: são feitos para ficar fora de linha com o usuário, o hash precisa vir de função de mão única aprovada, e a verificação deles entra no mesmo limite de tentativas do resto da autenticação. E manda o que quase todo produto esquece: usado um código, o provedor invalida aquele e emite um novo no lugar.

A segunda é o processo assistido por administrador, o caminho mais perigoso do produto, porque é o que o atacante tenta acionar por engenharia social, com a encenação de urgência descrita no artigo sobre ataques contra o atendimento. Quatro controles o sustentam: comprovação de identidade fora do canal do pedido, retornando o contato por telefone ou e-mail cadastrado antes, não pelo que veio no chamado; aprovação por uma segunda pessoa, para que nenhum administrador sozinho destranque conta alheia; registro na trilha de quem pediu, quem aprovou e quando; e notificação ao dono da conta e aos demais administradores no instante da remoção do fator.

Administrador único e prestador externo

Dois cenários travam a operação inteira. O primeiro é o administrador único: se a única conta com poder total perde o fator, ninguém na empresa consegue restaurá-la. O antídoto é garantir, antes de ligar a exigência, duas contas de administração com fatores próprios e códigos guardados em lugares distintos.

O segundo é o prestador externo, consultoria, contabilidade ou integrador. Se ele opera por conta compartilhada, a exigência quebra o acesso da equipe dele inteira, porque um fator só não acompanha várias pessoas. A resposta não é abrir exceção, é dar conta nominal a cada pessoa, com fator próprio e revogação amarrada ao fim do contrato, junto da rotação das chaves e do segredo de webhook que ele manuseou.

O que medir e o que registrar

Quatro números descrevem a saúde da virada: a adesão por papel; as tentativas falhas de segundo fator, que separam problema de relógio, concentrado em poucos usuários, de força bruta, distribuída e que exige limite de tentativas; o uso do caminho de recuperação, que deve ser raro e cujo crescimento súbito é sinal de ataque; e o tempo até o primeiro cadastro, que diz se o passo pós-senha está claro.

Na trilha de auditoria, o registro mínimo é quem ligou a exigência e quando, quem cadastrou ou removeu fator em qual conta, e quem executou e quem aprovou cada recuperação assistida. Essa é a evidência que a Lei Geral de Proteção de Dados, a Lei 13.709/2018, cobra no artigo 46 ao exigir medidas técnicas e administrativas aptas a proteger o dado pessoal de acessos não autorizados.

Segundo fator obrigatório é projeto de caminho de entrada, não chave de configuração. Quem constrói o caminho primeiro liga a chave sem drama; quem liga a chave primeiro descobre o caminho pelo suporte, com a equipe do lado de fora.

Fontes citadas

• NIST SP 800-63B revisão 4, Digital Identity Guidelines: Authentication and Authenticator Management, julho de 2025, seções 3.1.3.3, 3.2.9, 4.1.2.1 e 4.2.1.1: pages.nist.gov
• RFC 6238, TOTP: Time-Based One-Time Password Algorithm, 2011: rfc-editor.org
• RFC 4226, HOTP: An HMAC-Based One-Time Password Algorithm, 2005: rfc-editor.org
• Web Authentication Level 3, Recomendação do W3C de 25 de agosto de 2026: w3.org
• Lei 13.709/2018, Lei Geral de Proteção de Dados, artigo 46: planalto.gov.br