Durante anos, o acesso a uma conta seguiu um padrão conhecido: e-mail, senha e, quando o risco justificava, um segundo código. As passkeys mudam essa lógica. Em vez de pedir que a pessoa memorize um segredo compartilhado com o site, usam credenciais criptográficas administradas pelo dispositivo, navegador e um autenticador compatível.
A publicação do Web Authentication Level 3 como Candidate Recommendation Snapshot em 26 de maio de 2026 é relevante para equipes web. A questão já não é se a autenticação sem senha existe, mas como incorporá-la sem criar novos bloqueios para usuários ou para a operação.
Uma autenticação mais forte só se torna uma melhoria completa quando a pessoa consegue entrar, recuperar o acesso e entender o que acontece sem depender de atendimento improvisado.
O que uma passkey realmente muda
Na web, as passkeys usam WebAuthn. O site não recebe nem armazena um equivalente da senha: no cadastro, é criada uma credencial de chave pública para a relying party, normalmente o domínio do serviço. No login, o servidor apresenta um desafio e o autenticador produz uma resposta assinada que o servidor pode verificar.
Isso traz uma propriedade importante: a credencial fica limitada ao site para o qual foi criada. A especificação do W3C explica que o navegador media esse acesso e que os scripts da página não recebem as credenciais diretamente. Isso não elimina todos os riscos, mas substitui o padrão de senha reutilizável por outro modelo.
O WebAuthn também está amplamente disponível em navegadores modernos e requer HTTPS, segundo a documentação do MDN Web Docs. Isso reduz uma barreira técnica, mas não resolve sozinho toda a experiência.
A novidade não é apenas o padrão: é o momento de revisar o acesso
Para um site institucional sem contas, passkeys provavelmente não são prioridade. Para uma plataforma de clientes, portal de fornecedores, área de membros, intranet ou aplicação com dados sensíveis, podem justificar uma análise séria.
O motivo não é seguir uma tecnologia da moda. O login concentra problemas que afetam conversão, suporte e segurança: senhas esquecidas, tentativas de phishing, códigos que não chegam, novos dispositivos e contas compartilhadas sem regras claras.
Navegadores e gerenciadores de credenciais também reduzem a fricção de adoção. Por exemplo, em maio de 2025, o Chrome documentou uma opção para solicitar a criação automática de uma passkey quando existe uma senha salva e usada recentemente, sem exigir a substituição imediata de outros métodos de acesso. A documentação do Chrome mostra um princípio prático: a migração pode ser gradual.
Quando vale avaliar passkeys
A decisão faz mais sentido quando o acesso é parte importante da experiência ou do risco operacional. Alguns sinais úteis são:
- A equipe recebe muitas solicitações de redefinição de senha ou desbloqueio de conta.
- Usuários retornam com frequência pelo celular e pelo computador.
- A área autenticada contém dados pessoais, documentos privados, operações ou aprovações.
- Uma conta comprometida pode gerar custo, fraude ou exposição de dados.
- Cadastro e login são relevantes para uma venda, reserva, solicitação ou serviço recorrente.
- A organização consegue manter procedimentos documentados de recuperação e atendimento.
É melhor adiar a iniciativa se os perfis de usuário ainda não estão claros, se HTTPS não foi implementado corretamente, se o domínio principal muda sem planejamento ou se ninguém consegue atender casos excepcionais. Uma passkey não compensa uma arquitetura de contas desorganizada.
Quatro decisões antes de programar
1. Definir se será alternativa ou exigência
Um caminho prudente costuma ser oferecer passkeys como alternativa após um login bem-sucedido com o método atual. Isso permite observar adoção e falhas sem excluir quem ainda precisa de senha, link de uso único ou provedor de identidade.
Tornar passkeys obrigatórias desde o primeiro dia pode ser adequado em ambientes controlados, mas exige planejamento mais rigoroso de cadastro, dispositivos e contingências.
2. Projetar recuperação sem enfraquecer o sistema
Perder um dispositivo, trocar de telefone ou usar um computador compartilhado não deve tornar a conta impossível de recuperar. Porém, um canal de recuperação fraco demais pode virar o novo ponto de ataque.
Defina quais evidências são exigidas, quem aprova exceções, quanto tempo a recuperação leva, quais notificações são enviadas e como cada alteração é registrada. O objetivo não é adicionar etapas por precaução: é impedir que um suporte improvisado desfaça o ganho de segurança.
3. Revisar domínios e jornadas reais
O WebAuthn associa credenciais a uma relying party identificada por domínio. Por isso, uma experiência dividida entre domínios, subdomínios ou marcas deve ser analisada antes do lançamento. Teste o fluxo nos navegadores e dispositivos que o público realmente utiliza, não apenas nas máquinas de desenvolvimento.
4. Medir sem transformar o login em uma caixa-preta
Não basta contar quantas passkeys foram criadas. Com respeito à privacidade, acompanhe inícios de cadastro, conclusão, logins bem-sucedidos, abandonos, uso de recuperação e contatos com suporte. Esses sinais ajudam a identificar se o problema está na interface, em um dispositivo específico ou em uma regra operacional.
Um plano de adoção sensato
- Mapeie o acesso atual. Identifique métodos de login, recuperação, domínios, provedores externos, perfis e usuários críticos.
- Escolha um caso limitado. Comece por colaboradores, clientes recorrentes ou uma área privada com um grupo conhecido.
- Mantenha uma alternativa controlada. A transição não precisa ser tudo ou nada; defina o recurso de apoio e quando ele pode ser usado.
- Escreva mensagens para pessoas reais. Explique o que é uma passkey, quando ela é criada, em qual dispositivo pode estar disponível e o que fazer ao trocar de aparelho.
- Teste exceções. Valide dispositivos novos, passkeys indisponíveis, contas com vários dispositivos, recuperação e remoção de credenciais.
- Revise resultados e suporte. Ajuste o fluxo com evidências antes de ampliar o alcance.
Conclusão: não se trata de remover um campo de senha
O WebAuthn Level 3 mostra a maturidade de uma base técnica para autenticação web forte. A oportunidade não está em anunciar suporte a passkeys, mas em reduzir fricção e exposição sem deixar pessoas sem saída quando algo muda.
O próximo passo útil é simples: reúna produto, desenvolvimento e suporte, desenhe a jornada atual de login e recuperação e identifique onde usuários desistem ou incidentes acontecem. Se uma passkey resolver uma parte concreta dessa jornada, vale planejar um piloto.
Seu site precisa de área privada, cadastro ou acesso mais seguro? Na Ideasweb desenvolvemos sites com funcionalidades alinhadas à jornada dos usuários, à operação e aos objetivos do projeto.
