Autenticação sem senha deixou de ser promessa. A tecnologia está madura, os sistemas operacionais e navegadores dão suporte, e os grandes provedores de identidade já entregam a funcionalidade pronta.
O que ainda derruba projeto de passkey em empresa não é técnico. É operacional: ninguém pensou no dia em que o funcionário troca de celular, e o piloto morre na mesa do suporte.
Escrevi sobre o conceito em Passkey: a Evolução da Autenticação Digital. Aqui trato da implantação.
Por que passkey resolve um problema que MFA por SMS não resolve
A diferença central é que a credencial nunca sai do dispositivo. Não existe segredo compartilhado para o servidor guardar, e não existe código para o usuário digitar em uma página falsa.
Isso mata de uma vez a classe de ataque mais rentável contra empresa brasileira: a página de phishing que captura senha e, na sequência, pede o código do segundo fator. Com passkey, a assinatura é vinculada ao domínio de origem. O site falso simplesmente não recebe credencial válida, ainda que o usuário queira entregar.
É a contramedida direta ao cenário que descrevi em Spear Phishing em 2025.
Antes do piloto: três decisões
Onde a chave vive. Passkey sincronizada, guardada no chaveiro da conta pessoal do usuário, tem adoção fácil e recuperação simples. Passkey vinculada ao dispositivo ou a uma chave física é mais forte e mais rígida. Para a maioria das empresas, sincronizada nos usuários comuns e chave física nos administradores é o equilíbrio correto.
Quem entra primeiro. Não comece pela diretoria. Comece por um grupo tecnicamente confortável e com apetite para reportar problema, tipicamente TI e desenvolvimento.
O que acontece com a senha antiga. Esta é a decisão que define se o projeto reduz risco ou apenas adiciona conveniência. Passkey convivendo com senha ativa deixa a senha como caminho alternativo, e o atacante vai usar o caminho fraco. A meta precisa ser desativar a senha ao final, não só oferecer alternativa.
Fase 1: piloto, de duas a quatro semanas
- Ative o suporte a passkey no seu provedor de identidade, sem tornar obrigatório.
- Cadastre o grupo piloto, exigindo dois autenticadores por pessoa desde o início. Um só é o que gera o chamado de recuperação depois.
- Documente o procedimento de cadastro com capturas de tela reais do seu ambiente, não do material do fornecedor.
- Meça: tempo médio de login, chamados abertos, tentativas de login que falharam.
Fase 2: o que vai quebrar
Vale antecipar, porque acontece em praticamente toda implantação.
| Problema | Causa | Como tratar |
|---|---|---|
| Aplicação antiga não suporta | Sistema legado que só aceita usuário e senha | Colocar atrás do provedor de identidade, ou manter exceção documentada com prazo |
| Cliente de e-mail reclama | Protocolos antigos não falam o padrão moderno | Migrar para cliente que usa autenticação moderna e desativar os protocolos legados |
| Usuário troca de celular | Autenticador único registrado | Exigir dois autenticadores no cadastro, sempre |
| Computador compartilhado | Chave sincronizada em conta pessoal não serve | Chave física por turno, ou crachá com certificado |
| Suporte vira alvo | Atacante liga pedindo reset de autenticador | Procedimento de verificação de identidade fora de banda, obrigatório e auditado |
Esse último item merece destaque. Quando você fecha a porta da frente, o atacante bate na porta de serviço, e a porta de serviço é o atendimento humano. Um processo de recuperação frouxo anula toda a implantação.
Fase 3: adoção ampla
Expanda por grupo, nunca de uma vez. A cada grupo, repita a mesma sequência: comunicar antes, cadastrar com acompanhamento, medir por duas semanas, só então avançar.
Comunicação importa mais do que parece. A mensagem que funciona não é “vamos aumentar a segurança”. É “você vai parar de digitar senha”. O ganho percebido pelo usuário é conveniência, e é isso que gera adesão voluntária.
Fase 4: desligar a senha
É a fase que dá o retorno, e a que mais gente adia até nunca acontecer.
Faça em três degraus: primeiro a senha deixa de ser oferecida na tela de login, embora ainda exista. Depois ela é bloqueada para o grupo já migrado. Por fim, é removida.
Entre um degrau e outro, olhe os registros de autenticação. Se ainda há login por senha acontecendo, existe um caminho que você não mapeou, e é exatamente ali que o atacante vai entrar.
O que medir para saber se deu certo
- Cobertura: percentual de contas com pelo menos dois autenticadores registrados.
- Uso real: percentual de autenticações por passkey sobre o total. Cobertura alta com uso baixo significa que a senha continua sendo o caminho preferido.
- Chamados de recuperação: por mil usuários por mês. Se subir e não cair, o procedimento de cadastro está mal explicado.
- Contas ainda com senha ativa: a meta é zero, e enquanto não for, o número precisa estar caindo.
Um alerta final
Passkey protege a autenticação, não a sessão. Depois que o usuário entra, o que vale é o cookie de sessão, e roubo de sessão continua funcionando contra qualquer método de login.
Portanto, implante passkey e mantenha o que já protege depois do login: expiração razoável de sessão, verificação de dispositivo e monitoramento de comportamento anômalo, do jeito que tratei em Monitoramento Avançado com XDR no SOC. Trocar a fechadura não adianta se a janela fica aberta.