# Passkey e WebAuthn no cadastro: por que a chave não substitui o KYC Guia · UNIFOKAL · 12 de setembro de 2026 · Atualizado em 1 de outubro de 2026 · 8 min de leitura · Produto e integração Uma asserção WebAuthn prova posse de uma chave ligada a uma conta, não identidade civil. O que a especificação do W3C e o NIST SP 800-63B dizem sobre o lugar da passkey no onboarding. A adoção de passkey costuma ser anunciada como um salto de segurança no cadastro, e é. O problema aparece na frase seguinte, quando alguém conclui que, com passkey, a verificação de identidade virou dispensável. As duas coisas resolvem problemas diferentes, e trocar uma pela outra produz um cadastro com autenticação forte apoiada numa identidade que ninguém conferiu. A afirmação precisa é esta: uma asserção WebAuthn prova que quem está na sessão controla a chave privada registrada naquela conta, naquele domínio. Não prova nome, não prova CPF, não prova que existe uma pessoa por trás do cadastro. Passkey substitui a senha. Ela não substitui a etapa em que a identidade foi estabelecida, e o interessante é que a norma do W3C, o World Wide Web Consortium, e o guia de identidade digital do NIST, o instituto de padrões dos Estados Unidos, dizem isso com todas as letras. ## O que uma passkey prova, na letra da especificação A Web Authentication API está definida na recomendação [Web Authentication Level 3](https://www.w3.org/TR/webauthn-3/) do W3C, publicada em 25 de agosto de 2026. Ela descreve duas cerimônias. Na de registro, uma credencial de chave pública é criada no autenticador e fica escopada a uma parte confiante, a Relying Party, associada à conta do usuário presente. Na de autenticação, a parte confiante recebe uma asserção que prova a presença e o consentimento do usuário que registrou aquela credencial. O ponto que separa este artigo de qualquer material de marketing está numa nota da própria especificação, na definição de user verification, o desbloqueio local do autenticador por biometria ou PIN. A norma diz que a user verification não dá à parte confiante uma identificação concreta do usuário; o que ela expressa, quando duas ou mais cerimônias foram feitas com aquela credencial, é que foi o mesmo usuário que realizou todas elas. E acrescenta que esse mesmo usuário pode não ser sempre a mesma pessoa natural, caso mais de uma pessoa tenha acesso ao autenticador, por exemplo por terem cadastrado impressões digitais diferentes no mesmo aparelho. Continuidade não é identidade. A passkey garante que quem volta é quem registrou. Quem registrou continua sendo a pergunta em aberto. ## A conta já existia: onde a passkey entra no fluxo O caso de uso de consumidor descrito pela própria especificação deixa a ordem explícita. O usuário navega até o site e entra numa conta existente usando o método que vinha usando, possivelmente um método legado como senha, ou cria uma conta nova. Só então o aparelho pergunta se ele quer criar uma passkey para aquele domínio. O registro da chave pressupõe uma conta. O guia do NIST organiza a mesma separação em volumes distintos. A publicação [SP 800-63B](https://pages.nist.gov/800-63-4/sp800-63b.html), sobre autenticação e ciclo de vida do autenticador, define autenticação como o processo de determinar a validade dos autenticadores usados para reivindicar uma identidade digital, estabelecendo que o sujeito está no controle dos segredos usados para autenticar. A vinculação de um autenticador, no vocabulário do documento, é a associação entre um autenticador específico e uma conta de assinante, e a vinculação feita no momento do cadastramento está tratada no volume vizinho, o SP 800-63A, que cuida de comprovação de identidade. A consequência prática é direta. Uma passkey vale exatamente o que valia a conta a que ela foi vinculada. Vincule uma passkey a uma conta aberta com [CPF de terceiro](https://unifokal.com/blog/fraude-com-cpf-de-terceiro) e o resultado é um fraudador com autenticação resistente a phishing. Nada no protocolo corrige isso, porque não é esse o problema que ele resolve. O que estabelece a identidade continua sendo a camada descrita em [o que a lei brasileira exige de verdade num KYC](https://unifokal.com/blog/o-que-e-kyc), a sigla em inglês para conheça seu cliente. ## Onde a passkey ganha da senha e do código digitado O SP 800-63B define resistência a phishing como a capacidade do protocolo de impedir a revelação de segredos e de saídas válidas do autenticador a um verificador impostor, sem depender da vigilância do usuário. E é categórico na outra direção: autenticadores que envolvem digitação manual da saída, como os de canal fora de banda e os de senha de uso único, não são resistentes a phishing, porque a digitação manual não vincula a saída à sessão específica que está sendo autenticada. O documento cita o WebAuthn como exemplo de padrão que obtém resistência a phishing por vinculação ao nome do verificador, escolhendo o segredo do autenticador com base no nome de domínio autenticado. Essa é a diferença material em relação ao código digitado: uma [página de verificação falsa](https://unifokal.com/blog/pagina-de-verificacao-falsa) não consegue induzir o autenticador a assinar para o domínio verdadeiro, enquanto consegue, sem esforço, pedir que a vítima digite um código. ## O que a parte confiante precisa decidir Adotar WebAuthn não é ligar uma chave, e num pagamento inclui [amarrar o ato à aprovação](https://unifokal.com/blog/aprovar-o-ato-e-nao-so-a-pessoa). A especificação define dois sinalizadores que a parte confiante recebe em cada cerimônia. O BE, de backup eligibility, indica se a credencial pode ser copiada para outros aparelhos, é fixado na criação e não muda. O BS, de backup state, indica se ela está de fato copiada no momento, e pode mudar. A norma recomenda guardar o valor mais recente dos dois junto da conta: credencial com BE igual a zero é de aparelho único e não sobrevive à perda do aparelho, caso em que a parte confiante deve garantir outros autenticadores registrados ou um processo de recuperação; quando o BS muda de um para zero, a orientação é conduzir o usuário a validar seus outros fatores. Dois detalhes entram no desenho desde o começo. O primeiro é o user handle, o identificador da conta enviado ao autenticador: a especificação determina que a parte confiante não inclua nele informação que identifique a pessoa, como e-mail ou nome de usuário, e recomenda usar 64 bytes aleatórios guardados na conta. O segundo é a atestação: quando o autenticador usa autoatestação ou nenhuma atestação, não há informação de procedência para a parte confiante basear uma decisão de confiança. Na UNIFOKAL, por exemplo, a equipe do cliente entra no painel só com a passkey desde setembro de 2026; sem a verificação do usuário no aparelho, o SP 800-63B a trata como fator único e a entrada pede a senha junto. Cada passkey vinculada gera aviso por e-mail, como exige a seção 4.1.2.1. ## A recuperação de conta é onde o KYC volta O teste final do desenho não é o login feliz, é a perda do aparelho. E aqui o SP 800-63B fecha o raciocínio. Quando a conta foi comprovada em identidade, a partir do nível IAL1, a orientação é que a recuperação seja suportada repetindo parte do processo de comprovação, em passos consistentes com o nível inicial, confirmando que a identidade do requerente é a mesma da conta previamente estabelecida. Se a organização guardou uma amostra biométrica ou uma cópia da evidência original, com qualidade suficiente, pode repetir apenas a parte de verificação. Quando a conta nunca foi comprovada em identidade, o documento é direto: a opção de repetir a comprovação não existe, e a recuperação passa a depender exclusivamente de código de recuperação salvo, código emitido ou contato de recuperação. Quem pulou a [verificação de identidade da pessoa](https://unifokal.com/produto/identidade) na entrada troca uma etapa única de onboarding por uma dependência permanente de canais frágeis, que são exatamente os que a [engenharia social contra o atendimento](https://unifokal.com/blog/engenharia-social-contra-atendimento) ataca. Passkey e verificação de identidade não competem. A verificação responde quem é o titular; a passkey responde se quem voltou é o mesmo. ## Perguntas frequentes ### Passkey substitui a verificação de identidade no cadastro? Não. A especificação WebAuthn diz que a user verification não dá à parte confiante uma identificação concreta do usuário, apenas a evidência de que foi o mesmo usuário em cerimônias sucessivas com aquela credencial. A passkey substitui a senha depois que a identidade já foi estabelecida por outra camada. ### WebAuthn é considerado resistente a phishing? Sim, pelo critério do NIST SP 800-63B, que o cita como exemplo de padrão que obtém resistência a phishing por vinculação ao nome do verificador, e afirma que autenticadores baseados em digitação manual de código não são. ### Passkey sincronizada entre aparelhos vale menos? Depende do nível exigido. O NIST trata autenticadores sincronizáveis em anexo normativo próprio, aponta que suas chaves são inerentemente exportáveis e determina que não sejam usados no nível AAL3, o mais alto dos três níveis de garantia de autenticação. Nos níveis abaixo eles são aceitos. ## Fontes citadas - W3C, Web Authentication: An API for accessing Public Key Credentials Level 3, Recommendation de 25 de agosto de 2026, seções 1, 4 (user verification), 6.1.3 (sinalizadores BE e BS), 6.5 (atestação) e 14.6.1 (user handle): [w3.org](https://www.w3.org/TR/webauthn-3/) - NIST SP 800-63B, Digital Identity Guidelines: Authentication and Authenticator Management, seções 1, 2.2.1 e apêndice B (sem verificação do usuário, a passkey é fator único), 3.2.5 (resistência a phishing), 4.1 e 4.1.2.1 (vinculação e aviso de autenticador novo) e 4.2 (recuperação de conta): [pages.nist.gov](https://pages.nist.gov/800-63-4/sp800-63b.html) - NIST SP 800-63A, Digital Identity Guidelines: Identity Proofing and Enrollment, o volume do mesmo guia que trata da comprovação de identidade: [pages.nist.gov](https://pages.nist.gov/800-63-4/sp800-63a.html)