Já conduzi implantações de MFA suficientes para conhecer o padrão. Passamos um ano empurrando notificações push e códigos TOTP, declaramos vitória, e dezoito meses depois o relatório de incidente diz que um agente de help desk aprovou uma redefinição para alguém com um sotaque convincente e um perfil no LinkedIn. O controle não falhou porque as pessoas são burras. Falhou porque o controle ainda depende de um segredo que um humano pode ser persuadido a entregar.

Esse é o argumento completo a favor das passkeys, e acho que vale ser direto: senha mais um código não é resistente a phishing, e os atacantes descobriram isso muito antes de a maioria dos nossos roadmaps perceber. Então vamos falar sobre o que realmente muda, o que não muda, e como colocar do seu lado as pessoas que assinam os cheques e as que clicam nos botões.

Qual controle falhou, exatamente

Uma senha, um código SMS, um código TOTP e um prompt de push compartilham uma propriedade: a prova de identidade é um valor que pode ser retransmitido. Um proxy adversário no meio (Evilginx e seus derivados) fica entre o usuário e a página de login real, repassa tudo em tempo real e sai com uma sessão. A CISA disse isso claramente em seu fact sheet de 2022 sobre implementação de MFA resistente a phishing: códigos baseados em aplicativo e push são melhores do que nada, mas apenas métodos FIDO/WebAuthn e baseados em PKI se qualificam como resistentes a phishing. O NIST SP 800-63B diz o mesmo em linguagem mais formal e reserva seus níveis de garantia mais elevados para autenticadores que verificam a origem.

As passkeys são a embalagem amigável ao consumidor desse modelo. A credencial é um par de chaves pública/privada. A chave privada nunca sai do autenticador (um telefone, um laptop, uma chave de segurança). Durante o login, o navegador vincula a assinatura ao relying party ID, que é o seu domínio. Se o usuário estiver em evil.example em vez de login.yourcompany.com, o autenticador não tem nenhuma chave correspondente e simplesmente não assina. Não há código para digitar na caixa errada. O próprio write-up da Cloudflare sobre a campanha de phishing de 2022 que atingiu a Twilio e outras empresas é a melhor evidência de campo que conheço: mesmo engodo, mesmos atacantes, e os usuários com chave de hardware não foram comprometidos porque a verificação de origem fez seu trabalho.

Então, quando alguém me pergunta por que estamos fazendo isso de novo depois de "já termos feito MFA", minha resposta é que fizemos MFA, apenas a versão em que o atacante também pode participar.

Preparando a infraestrutura

Antes de tocar nos usuários, faça um inventário dos relying parties. Todo lugar onde um usuário digita uma senha hoje fica atrás do seu IdP ou não fica. Os que ficam atrás do IdP recebem passkeys no dia em que você habilitar WebAuthn como método de autenticação. Os que não ficam são o seu projeto de verdade. A boa notícia é que essa lista costuma ser mais curta e mais embaraçosa do que o esperado, o que é motivador à sua maneira.

Depois, tome três decisões de arquitetura e as documente:

• Sincronizada ou vinculada ao dispositivo. Apple, Google e Microsoft já sincronizam passkeys por meio de suas contas na nuvem. O suplemento de 2024 do NIST ao 800-63B aceita autenticadores sincronizáveis no AAL2, então isso não é heresia, mas significa que a passkey é tão forte quanto a recuperação de conta do iCloud ou do Google do usuário. Para administradores e funções privilegiadas, exija credenciais vinculadas ao dispositivo em chaves de hardware e aplique isso com attestation onde o seu IdP oferecer suporte.
• Recuperação. É aqui que todo programa passwordless silenciosamente reintroduz uma senha. Decida agora o que acontece quando o telefone cai no fundo do mar. Idealmente a resposta é "uma segunda passkey registrada" e, caso contrário, um fluxo de comprovação de identidade verificada, não uma conversa amigável com o service desk.
• Fallback e sunset. Mantenha push ou TOTP como fallback apenas por uma janela fixa, registre cada uso em log e revise esse log semanalmente. Se um usuário tem uma passkey e ainda recebe um prompt de push, algo está errado e provavelmente é um atacante.

No lado de engenharia, ative a conditional UI (o autofill do navegador para passkeys) para que o formulário de login não precise de um botão separado que ninguém clica, e teste o login entre dispositivos pelo fluxo de QR code, porque muitos dos seus usuários de desktop vão autenticar com o telefone no bolso.

Conquistando os usuários

Este é o teste decisivo: se sua implantação precisar de um vídeo de treinamento, você já perdeu. As passkeys são o primeiro controle de segurança na minha carreira que é genuinamente mais fácil do que aquilo que substitui. Face ID, pronto. Sem código, sem aplicativo para abrir, sem "você recebeu a mensagem?" Comece por aí, e registre a passkey em um momento em que o usuário já está autenticado e levemente entediado, como logo após um login bem sucedido. Não force o enrollment numa manhã de segunda antes do café; você está competindo com a caixa de entrada dele, e a caixa de entrada vai ganhar.

Meça e publique dois números: tempo mediano de login e tickets de help desk por bloqueio de conta. Quando ambos caírem, e vão cair, conte para as pessoas. Usuários toleram security theater; eles gostam ativamente de coisas que lhes devolvem trinta segundos por dia.

Conquistando os executivos

Executivos não compram criptografia de chave pública. Eles compram três coisas: probabilidade reduzida de violação, custo reduzido de help desk e não ter o próprio nome na manchete. O DBIR da Verizon coloca credenciais roubadas no topo ou próximo ao topo dos vetores de acesso inicial ano após ano, então a narrativa de risco se escreve sozinha. A Microsoft argumenta há anos que o MFA bloqueia a esmagadora maioria das tentativas de comprometimento de conta, e agora os atacantes migraram para a parte que o MFA não cobre. Enquadre as passkeys como o fechamento dessa lacuna, não como mais uma novidade brilhante do time de segurança.

Depois, faça o piloto com os próprios executivos. Dê uma passkey ao CFO antes de dar uma para a engenharia. É o capital político mais barato que você vai ganhar na vida, e se o CFO consegue fazer login com o polegar, ninguém na empresa pode alegar que é difícil demais.

As passkeys não vão consertar seu processo de joiner mover leaver, suas contas de serviço obsoletas nem sua política de redefinição do helpdesk. Elas corrigem uma falha específica e bem compreendida: o segredo retransmissível. Isso é algo raro neste setor, um controle que é ao mesmo tempo mais forte e mais agradável. Aproveite a vitória.