Segurança sem fricção: repensando a autenticação em User Account

Empresa: grande varejista de artigos esportivos (nome mantido em sigilo por NDA)
Squad: User Account
Papel: Product Designer
Duração: ~2 meses de discovery, dentro de um período de 6 meses na squad
Time: Product Manager, Engenharia, Design (eu)
Ferramentas: Figma, FigJam, Notion

O contexto

No fim de 2024, a empresa passou por um evento de crise de segurança. A resposta mais óbvia — e a mais repetida no mercado — é "implementar 2FA". Mas a squad de User Account tinha um problema mais interessante escondido atrás dessa resposta óbvia: o time de engenharia não acreditava que 2FA resolveria o problema de segurança sozinho.

Essa desconfiança inicial foi, na verdade, o ponto de partida certo. Em vez de tratar 2FA como uma tarefa de implementação, transformamos em um discovery: onde essa camada de segurança realmente compensa o atrito que ela cria? E onde ela é só teatro de segurança?

Fui responsável por conduzir a parte de produto e design desse discovery — da pesquisa de benchmarking ao desenho dos fluxos de proposta.

O problema real

Autenticação de dois fatores parece uma decisão binária (tem ou não tem), mas na prática ela se decompõe em três perguntas que a maioria das implementações erra por não fazer:

• Onde o 2FA deve ser aplicado?

• Quando ele deve ser acionado?

• Com que frequência é razoável pedir para o mesmo usuário?

E tudo isso precisava conviver com dois objetivos estratégicos da squad que, à primeira vista, competem entre si:

1. Reduzir a fricção na jornada de cadastro e login.

2. Diminuir o risco de fraude nesses mesmos processos.

Adicionar uma camada de segurança quase sempre significa adicionar atrito. O trabalho de design aqui não era "adicionar 2FA" — era encontrar os pontos exatos onde a segurança ganha mais do que a fricção tira.

Por que isso importa (e não é só intuição)

É simples assim, sem exagero: colocar 2FA no lugar errado tem custo real dos dois lados.

• Autenticação em dois fatores reduz drasticamente takeovers de conta — é uma das intervenções de segurança mais custo-efetivas que existem quando bem direcionada.

• Mas fricção de login e cadastro tem custo direto em conversão: processos de autenticação mal desenhados estão entre as principais causas de abandono em fluxos sensíveis, especialmente no mobile.

• No Brasil, o canal de envio do código muda tudo: SMS tradicional tem boa cobertura mas está sujeito a filtros de operadora e falhas de entrega; canais como WhatsApp tendem a converter melhor em mercados com alta penetração do app, como o brasileiro, quando usados como fallback ou canal primário.

Ou seja: a pergunta não era "2FA sim ou não", era "2FA onde, com qual canal, e com qual frequência isso paga o atrito que cria".

A escolha do piloto: por que alteração cadastral

Existia uma pressão natural para começar pelo cadastro ou pelo login — são os fluxos mais visíveis e mais "óbvios" para segurança. Decidimos não começar por aí.

Alteração de dados cadastrais foi escolhida como piloto porque é um fluxo de menor risco de negócio: já é um usuário autenticado, alterando dados sobre si mesmo, fora do funil de conversão. Se o 2FA gerasse fricção demais ali, o custo era muito menor do que testar direto no login ou no cadastro — e ainda assim geraria aprendizados replicáveis para os fluxos mais críticos depois.

Essa lógica de "validar no fluxo de menor risco antes de expandir para o mais crítico" guiou toda a estratégia de rollout que propusemos.

Mapeando onde a fricção compensa

Um dos exercícios mais reveladores do processo foi passar campo por campo dentro de "alteração de dados cadastrais" e decidir, um a um, se ele merecia 2FA:

Esse mapeamento é o coração do case: não é sobre proteger tudo igualmente, é sobre calibrar a proteção pelo risco real de cada dado. Colocar 2FA em "alterar nome" só para parecer seguro seria fricção pura, sem ganho de segurança proporcional.

Desenhando os fluxos

A partir desse mapeamento, desenhei as propostas de userflow para os três pontos de maior risco — alteração de e-mail e senha, tanto em mobile quanto em web — considerando variações de canal (SMS, e-mail) e cenários de erro (código expirado, reenvio, usuário sem acesso ao canal cadastrado).

"Ideação de fluxo para 2FA" (mapa geral: alteração de dados cadastrais, cadastro, senha, casos [LATER]/[KEEP]) e "Proposta Userflow 2FA [Detalhado]" (visão consolidada de celular, e-mail e cadastro lado a lado). Essas duas imagens funcionam bem como abertura da seção — mostram o raciocínio antes de entrar no detalhe.

A tela "Alteração de dados cadastrais" com o badge "1", mostrando campo a campo (dados de acesso x dados pessoais) e a decisão de validar ou não por SMS/e-mail. Essa é a melhor ilustração para a tabela de mapeamento logo acima — pode entrar como uma imagem de apoio dentro ou logo depois da tabela, em vez de aqui.

O par "Confirmação de dado alterado _ CELULAR" e "Confirmação de dado alterado _ EMAIL": a sequência de tela para escolher o canal, aguardar/inserir o código e ver a confirmação de sucesso. Entra aqui, logo abaixo deste parágrafo, como o primeiro exemplo concreto do fluxo ponta a ponta.

O par "Verificação de identidade _ POR EMAIL" (para alterar celular) e "Verificação de identidade _ POR SMS" (para alterar e-mail): a etapa de confirmar identidade pelo canal cruzado antes de liberar a edição do dado. Entra logo depois da Imagem 3, já que representa o passo anterior no fluxo (verificar identidade → só depois alterar o dado → depois confirmar).

Juntas, essas duas últimas telas mostram bem a lógica de canal cruzado que ficou registrada como boa prática: pedir confirmação por um canal diferente do dado que está sendo alterado (ex.: confirmar por SMS quando o e-mail é o dado sendo trocado, e vice-versa) — isso evita que, se um único canal for comprometido, o atacante consiga trocar todos os dados de recuperação de uma vez.

Alguns cuidados de UX que ficaram registrados como boas práticas para qualquer expansão futura do 2FA na plataforma:

• Sempre que possível, oferecer mais de uma opção de canal para o código (não travar o usuário em um único caminho).

• Mostrar parte do número de telefone ou e-mail para o qual o código foi enviado, para gerar confiança de que é o canal certo.

• Prever explicitamente o fluxo de "não recebi o código" e o de recuperação quando o usuário perde acesso ao canal cadastrado — um cenário de erro que é fácil de esquecer no desenho, mas custa caro em chamados de suporte quando ignorado.

Um insight que foi além do escopo original

Durante o discovery, surgiu um problema conectado que não estava no briefing inicial: o uso de vale-troca ficava bloqueado quando o cliente tentava usá-lo em um endereço de entrega diferente do original — uma trava de segurança que gerava um volume relevante de bloqueios e, consequentemente, de chamados no atendimento.

Levantamos a hipótese de que o 2FA poderia substituir essa trava rígida por uma validação pontual, mais segura e menos punitiva para o cliente legítimo. Não desenvolvemos essa solução dentro do escopo do piloto — ficou registrada como uma oportunidade de expansão modular do 2FA, já que a squad de User Account não é dona dessa jornada e a solução precisaria ser pensada de forma plataformizada, reaproveitável em outros pontos do produto.

Prós e contras que colocamos na mesa

Nenhuma decisão de segurança é isenta de trade-off, e parte do meu papel foi deixar isso explícito para a squad decidir com clareza — não só apresentar uma solução "pronta".

A favor do 2FA nesses pontos

• Reduz de forma significativa o risco de account takeover nos dados mais sensíveis (e-mail e senha).

• Cria uma base de dados real de comportamento (taxa de abandono, canal preferido, tempo de conclusão) para embasar decisões em fluxos mais críticos, como cadastro e login.

• Cada camada adicionada aumenta a confiança do cliente na plataforma — especialmente relevante logo após um incidente de segurança.

Contra (ou pontos de atenção)

• Fricção adicional em um fluxo que, por natureza, o usuário só acessa quando já quer resolver algo rápido — todo passo extra é uma chance de abandono.

• 2FA sozinho não resolve todos os vetores de fraude — o próprio time de engenharia estava certo em desconfiar de que fosse "a" solução, e isso precisava ficar claro para não criar uma falsa sensação de segurança.

• Custo de manutenção e de canal (envio de SMS tem custo direto e depende de operadoras).

• Risco de aumentar chamados no SAC no curto prazo, com usuários que perdem acesso ao canal de validação — um cenário de erro que precisava de um plano de contingência antes de qualquer implementação.

O que ficou como aprendizado

Este projeto não chegou a ir a produção durante o meu período na squad — a priorização foi movida para o fim do trimestre seguinte, como costuma acontecer com iniciativas estratégicas que exigem negociação entre segurança, produto e engenharia. Mas o discovery deixou três coisas de valor para a squad:

1. Um framework claro de decisão (onde / quando / com que frequência) que pode ser reaplicado em qualquer novo ponto de fricção de segurança, não só 2FA.

2. Um piloto desenhado deliberadamente para ser de baixo risco e alto aprendizado, evitando a armadilha comum de testar segurança direto no fluxo mais crítico do negócio.

3. Um insight de expansão (vale-troca) que nasceu do processo, não do briefing — prova de que dar espaço para discovery de verdade gera valor além do escopo original.

Se eu fosse continuar esse projeto hoje, o próximo passo seria validar esse framework com dados reais do piloto antes de propor a expansão para cadastro e login — e provavelmente medir mais de perto a preferência de canal (SMS vs. e-mail vs. WhatsApp) direto com os usuários da base, já que a decisão de canal muda bastante o resultado no mercado brasileiro.

Por conta de NDA, o nome da empresa, nomes de colegas de time e números internos exatos não são citados aqui. As imagens usadas neste case são materiais de ideação e proposta produzidos por mim durante o projeto.