# Passkey vinculada a uma pessoa verificada: o que o vínculo prova e o que ele não prova

<https://unifokal.com/blog/passkey-vinculada-a-pessoa-verificada>

Guia · UNIFOKAL · 1 de outubro de 2026 · 8 min de leitura · Antifraude

Ligar a passkey a uma conta com identidade verificada cria uma corrente que precisa ser cuidada a vida toda: vincular, acrescentar, revogar e recuperar, pela NIST SP 800-63B-4 e pelo WebAuthn.

Uma empresa verifica a identidade do cliente no cadastro, com documento e prova de vida, e logo depois oferece a ele criar uma passkey. A partir dali, cada aprovação sensível passa pela chave. A pergunta que o time de produto costuma fazer é se isso "amarra a passkey à pessoa". A resposta honesta tem duas partes: amarra a uma conta cuja identidade foi verificada, e a força dessa amarra depende de como o vínculo é criado, acrescentado, revogado e recuperado ao longo dos anos.

Este guia parte de onde termina o texto sobre [passkey e WebAuthn no cadastro](https://unifokal.com/blog/passkeys-e-webauthn-no-cadastro), que mostra por que a chave não substitui a verificação de identidade, e trata do passo seguinte: o que a corrente pessoa verificada, conta e credencial prova, onde ela se rompe e o que a norma manda fazer em cada evento.

## O vínculo nasce no cadastro, e o registro dele é a prova

A NIST SP 800-63A-4, a norma de comprovação de identidade do NIST (National Institute of Standards and Technology, o instituto de padrões dos Estados Unidos), trata do primeiro elo no item de vinculação inicial do autenticador, dentro dos requisitos de cada nível. Uma vez criada a conta do assinante, um ou mais autenticadores podem ser vinculados a ela, e a norma recomenda incentivar o assinante a manter pelo menos dois. Nos níveis IAL1 e IAL2 (IAL, Identity Assurance Level, o nível de garantia de identidade), se o autenticador for vinculado fora de uma única sessão protegida, o provedor precisa confirmar a presença do titular por código de continuação ou por comparação com a biometria colhida na comprovação. Em linguagem de produto: a passkey nasce na mesma sessão em que a pessoa foi verificada, ou volta a passar pela pessoa.

A NIST SP 800-63B-4, a diretriz de autenticação, define na seção 4.1 o vínculo como a associação entre um autenticador específico e uma conta de assinante. A mesma seção exige que o provedor mantenha o registro de todos os autenticadores vinculados a cada conta, determine as características de cada um, como multifator ou não, e registre data e hora dos eventos significativos do ciclo de vida. Ela recomenda, sem obrigar, guardar a origem do vínculo, como endereço IP (Internet Protocol) ou identificador do aparelho. Esse registro é o que permite, meses depois, responder qual credencial aprovou um ato e quando ela passou a valer.

## O que o vínculo prova, e o que ele não prova

A asserção WebAuthn prova que quem responde controla uma credencial vinculada àquela conta, naquele domínio. Com a verificação do usuário no aparelho, por biometria ou PIN (a senha numérica local), o autenticador confirmou localmente um usuário. A especificação Web Authentication Level 3 do W3C (World Wide Web Consortium), recomendação de 25 de agosto de 2026, limita o alcance disso numa nota: a verificação do usuário não dá à parte confiante uma identificação concreta, e quando duas ou mais cerimônias com verificação do usuário foram feitas com a mesma credencial ela expressa que foi o mesmo usuário em todas, que pode não ser a mesma pessoa natural se várias pessoas tiverem acesso ao autenticador.

O apêndice B da 800-63B-4, sobre autenticadores sincronizáveis, completa o quadro:

- **A chave sincronizada é exportável por natureza.** A norma diz que sincronizar significa que a chave pode ser exportada, e por isso o autenticador sincronizável não atende o nível AAL3 (Authenticator Assurance Level), o mais alto de garantia de autenticação. No AAL2 ele pode ser aceito, sob os requisitos do apêndice.
- **Ela pode ser compartilhada.** Algumas implementações criaram meios de compartilhar chaves entre usuários diferentes, e a norma orienta as aplicações abertas ao público a supor que todo autenticador sincronizável pode ser compartilhado.
- **Os sinalizadores dizem o que a chave pode fazer, não onde ela está.** O BE (backup eligible) indica que a credencial pode ser sincronizada, o que não quer dizer que foi; o BS (backup state) indica se foi. A norma recomenda que aplicações abertas ao público não condicionem a aceitação ao BS.
- **Sem verificação do usuário, não há multifator.** O sinalizador UV (user verified) precisa ser conferido, e sem ele a norma não aceita o autenticador como multifator.

O vínculo, portanto, prova continuidade de posse numa conta cuja identidade foi verificada. Não prova que a pessoa da asserção é a mesma da selfie do cadastro, nem que a chave está num aparelho só. Também não diz qual ato foi aprovado, assunto do texto sobre [aprovar o ato, e não só a pessoa](https://unifokal.com/blog/aprovar-o-ato-e-nao-so-a-pessoa).

## Acrescentar e revogar uma chave

Quem toma uma conta quer ficar nela, e o jeito mais limpo é vincular uma passkey própria. A seção 4.1.2.1 da 800-63B-4 trata disso. O provedor precisa permitir vários autenticadores por conta, mas o vínculo de um novo exige autenticação no menor entre dois níveis: o mais alto disponível na conta e o mais alto em que o autenticador novo será usado. Além disso, o titular precisa ser avisado por um mecanismo independente da transação que fez o vínculo.

Quando o vínculo acontece em outro aparelho, a seção 4.1.2.2 exige código de vínculo gerado de forma aleatória, de pelo menos 40 bits se acompanhado de um identificador digitado pelo titular, ou 112 bits sem ele, usável uma vez, válido por no máximo 10 minutos e nunca enviado por canal inseguro, como e-mail. A mesma seção manda dar instruções claras para o caso de vínculo indevido, como um botão ou um contato que permita invalidá-lo depressa.

A seção 4.5 define invalidação como a remoção do vínculo entre o autenticador e a conta. O provedor precisa invalidar sem demora quando a conta deixa de existir, inclusive na descoberta de um assinante fraudulento, quando o titular pede, quando o autenticador é comprometido ou quando o titular deixa de cumprir os requisitos de elegibilidade. A norma registra que não invalidar um autenticador comprometido costuma custar mais que invalidar um por engano. Para perda, roubo, cópia indevida ou fator de ativação fora do controle do titular, a seção 4.3 manda suspender, invalidar ou destruir o autenticador prontamente.

Revogar acontece no registro da parte confiante, não no aparelho. O WebAuthn Level 3 oferece, na seção 5.1.10, métodos de sinalização para avisar o autenticador de que uma credencial foi revogada, mas o cliente os executa de forma oportunista, e eles não informam se a operação deu certo. A chave pode continuar no gerenciador do usuário; o que a torna inútil é o servidor não aceitá-la mais.

## Recuperar é voltar à pessoa, não ao canal

A seção 4.2 da 800-63B-4 reconhece quatro classes de recuperação de conta: códigos salvos, códigos emitidos, contatos de recuperação e comprovação de identidade repetida. A última só existe para contas comprovadas: quando a conta foi comprovada pelo menos no IAL1, a norma recomenda suportar a recuperação repetindo parte da comprovação, e exige confirmar que a identidade de quem pede é consistente com a da conta já estabelecida. Se o provedor guardou uma amostra biométrica ou cópia da evidência com qualidade suficiente, pode repetir só a etapa de verificação. Toda recuperação dispara aviso ao titular ou a quem ele designou.

É aqui que a identidade verificada no cadastro rende juros. Quem perdeu o aparelho volta por uma nova [verificação de identidade com prova de vida](https://unifokal.com/produto/identidade). Cabe ao provedor da conta conferir o resultado contra a identidade já registrada, como a seção 4.2 exige, antes de vincular uma passkey nova e invalidar as antigas. A recuperação deixa de depender de um código enviado ao canal que o golpista acabou de tomar.

## Perguntas frequentes

### Passkey sincronizada pode acabar nas mãos de outra pessoa?

Pode. O apêndice B da NIST SP 800-63B-4 registra que algumas implementações permitem compartilhar chaves entre usuários e orienta aplicações abertas ao público a supor que toda chave sincronizável pode ser compartilhada. Por isso o vínculo prova posse de credencial na conta, não presença de uma pessoa específica.

### Revogar a passkey no servidor apaga a chave do celular do cliente?

Não necessariamente. Os métodos de sinalização do WebAuthn Level 3 avisam o autenticador de forma oportunista e não confirmam o resultado. O que vale é o registro da parte confiante deixar de aceitar aquela credencial.

## Fontes citadas

- NIST SP 800-63B-4, Digital Identity Guidelines: Authentication and Authenticator Management, seções 4.1, 4.1.2.1, 4.1.2.2, 4.2, 4.3 e 4.5 e apêndice B (autenticadores sincronizáveis): [pages.nist.gov](https://pages.nist.gov/800-63-4/sp800-63b.html)
- NIST SP 800-63A-4, Digital Identity Guidelines: Identity Proofing and Enrollment, requisitos de IAL1 e IAL2, item Initial Authenticator Binding: [pages.nist.gov](https://pages.nist.gov/800-63-4/sp800-63a.html)
- W3C, Web Authentication: An API for accessing Public Key Credentials Level 3, Recommendation de 25 de agosto de 2026, definição de user verification e seção 5.1.10 (métodos de sinalização): [w3.org](https://www.w3.org/TR/webauthn-3/)