Resumo rápido: por que usar uma chave de segurança hoje?
Uma chave de segurança é um autenticador físico que pode usar credenciais de chave pública. Os padrões FIDO e WebAuthn permitem esse tipo de autenticação, embora o funcionamento exato dependa do serviço e do dispositivo. As passkeys podem estar vinculadas a uma plataforma ou ser sincronizadas pelo ecossistema que as administra; não são necessariamente iguais a uma credencial armazenada em uma chave externa. Essa distinção importa na hora de escolher o que comprar, pois o termo “passkey” não informa, por si só, onde uma credencial fica armazenada nem como estará disponível em outro dispositivo.
Na autenticação de chave pública, o serviço usa uma chave pública associada à credencial, enquanto o autenticador conserva e usa a chave privada correspondente. WebAuthn faz parte dos mecanismos da web para acessar credenciais de chave pública. Isso não elimina a necessidade de verificar as opções e políticas de cada conta. O serviço continua determinando quais métodos de acesso aceita, e o dispositivo precisa conseguir usar o método escolhido.
Por isso, a decisão de compra não depende apenas da marca: importam os padrões e recursos aceitos pelo serviço, as conexões disponíveis nos seus dispositivos e os procedimentos de recuperação existentes. A compatibilidade precisa ser confirmada para cada combinação de conta, dispositivo e método de acesso. Uma chave registrada como contingência pode reduzir o risco de perder o acesso, desde que o serviço permita registrá-la e você conheça o processo de recuperação. Verifique essas condições antes de tratar a chave como sua única maneira prática de voltar a acessar uma conta.
Antes de comprar: verifique a compatibilidade real com suas contas
Faça um inventário das suas contas importantes e verifique o que cada uma aceita. A Apple documenta o uso de chaves de segurança de terceiros para proteger uma Conta Apple e exige o registro de pelo menos duas chaves para ativar esse recurso. O Google documenta o acesso às Contas do Google com passkeys. Não presuma que a mesma chave, conexão ou modalidade funcione da mesma maneira em todos os serviços: consulte a ajuda do fornecedor para cada conta e dispositivo que pretende usar.
Identifique os dispositivos com que costuma entrar —notebook, computador de mesa ou celular— e as conexões disponíveis em cada um. Se um serviço de trabalho exigir um método específico de verificação, confira os requisitos e pergunte se o modelo considerado os atende. Ter o conector adequado, por si só, não garante compatibilidade: o sistema operacional, o navegador, o aplicativo e as políticas do serviço também podem influenciar. Verifique o fluxo completo de acesso, não apenas a porta do dispositivo.
Se você usa um gerenciador de senhas ou acessa serviços regulamentados, confirme se eles aceitam WebAuthn ou passkeys e se permitem seu uso como segundo fator ou para iniciar sessão. Verifique também qualquer requisito de certificação antes da compra. Não basta um produto ser anunciado como certificado se a organização exigir validação de um módulo específico, do próprio produto ou de uma configuração determinada. Defina exatamente o que a conta ou organização exige e compare com a documentação do produto pertinente.
Padrões principais: FIDO2, WebAuthn e CTAP2
WebAuthn é uma API web padronizada para autenticação com credenciais de chave pública. CTAP define a comunicação entre o cliente e o autenticador; a especificação CTAP 2.2 da FIDO Alliance incluída na pesquisa tem a data de 3 de outubro de 2024. Isso não significa que você deva exigir automaticamente uma versão específica: primeiro confira quais recursos o serviço exige e quais são aceitos pelos seus dispositivos. O número da versão oferece contexto útil, mas não substitui a verificação dos requisitos concretos da configuração que será usada.
Entender o fluxo geral ajuda a avaliar os recursos sem se perder no jargão. Credenciais discoverable podem permitir o acesso sem que a pessoa digite primeiro o nome da conta, mas sua disponibilidade e utilidade dependem do serviço e da configuração da credencial. Não presuma que todos os serviços aceitam essa modalidade. Consulte as instruções do fornecedor para saber se ela é compatível com sua conta e como deve funcionar.
Se você depende de passkeys, confirme de que tipo precisa: uma credencial sincronizável de plataforma não equivale necessariamente a uma credencial armazenada em uma chave externa. USB e NFC podem ser opções práticas se seus dispositivos e serviços aceitarem esses fluxos. Em ambientes gerenciados, pergunte se há políticas de atestação ou verificação do usuário e confirme que o modelo escolhido consegue atendê-las. A escolha adequada depende dos requisitos efetivamente aplicáveis, não apenas do nome de um padrão ou recurso.
Formatos e conectividade: USB-C, USB-A, NFC e BLE
USB-C pode ser conveniente se seus dispositivos tiverem essa porta; USB-A pode ser útil em equipamentos sem USB-C. Antes de pagar, verifique as portas que você usará e as especificações do modelo. Adaptadores podem resolver diferenças de conexão, mas acrescentam outro item para transportar e cuidar. O tamanho também é uma consideração prática: o formato adequado depende de como você pretende levar e usar a chave. Pense em onde ela ficará guardada e com que frequência precisará conectá-la.
NFC permite usar uma chave compatível aproximando-a de um dispositivo móvel, mas a compatibilidade depende da chave, do celular, do sistema operacional, do aplicativo ou navegador e do serviço. Confira a combinação exata na documentação do fornecedor antes de contar com NFC como única forma de acesso. Considere também como guardar e transportar a chave para reduzir a possibilidade de perdê-la ou danificá-la. Uma conexão que parece conveniente no papel só é útil se toda a configuração for compatível.
Não escolha BLE, biometria ou um método de verificação local apenas porque aparecem na descrição comercial. Confira, modelo por modelo, quais recursos são oferecidos e se correspondem aos requisitos do serviço. Emparelhamento, bateria ou suporte de software podem impor condições adicionais; sem documentação específica do dispositivo e do serviço, não é prudente recomendá-los como requisitos gerais. Trate cada recurso como algo a verificar na sua configuração, em vez de presumir que estará sempre disponível ou será necessário.
Segurança e certificações: o que verificar
Certificações não substituem os padrões de autenticação, mas podem documentar como um componente foi avaliado. O CMVP da NIST valida módulos criptográficos conforme os requisitos aplicáveis. Common Criteria oferece uma estrutura de avaliação com requisitos e níveis de garantia definidos para o produto avaliado. Nenhum desses termos deve ser interpretado como garantia geral de que um dispositivo completo seja adequado a qualquer ambiente. O escopo da avaliação é essencial para entender o que uma certificação cobre —e o que não cobre.
Ao comparar produtos, concentre-se no escopo da certificação e em saber se ela corresponde à configuração que será realmente usada. Para uma validação FIPS, verifique o módulo e a entrada de validação pertinente. Para Common Criteria, confira o certificado, o objetivo de segurança e o perfil aplicável. Um nível EAL isolado não basta para decidir que um produto é a melhor opção para todos os usos. Compare a avaliação declarada com os requisitos do ambiente em que a chave será implementada.
Para uso pessoal ou em uma pequena empresa, priorize compatibilidade documentada, informações claras de suporte e um procedimento viável de substituição e recuperação. Em setores regulamentados, peça à organização responsável a referência exata do certificado exigido e confira-a nos registros oficiais. Avaliação criptográfica e resistência a phishing são questões diferentes: a proteção também depende do protocolo, da configuração e do serviço que aceita a chave. Portanto, considere a certificação junto com o fluxo de acesso e os requisitos reais da organização, e não como um atalho de compra independente.
Capacidade e recursos: credenciais discoverable, PIN e políticas
Credenciais discoverable podem permitir o acesso sem digitar primeiro o nome da conta, mas sua disponibilidade e capacidade dependem da chave e do serviço. Antes de comprar, confirme que a conta aceita essa modalidade e consulte a documentação do fabricante para conhecer os recursos e limites do modelo. Não presuma que todas as chaves armazenem o mesmo número de credenciais. Se a capacidade de armazenamento for importante para seu uso, procure dados do modelo específico em vez de deduzi-los da categoria do produto.
Um PIN pode fazer parte da verificação local do usuário se a chave e o serviço o aceitarem. Ele não é a senha da conta e não substitui os processos de recuperação. Siga as instruções do fabricante para configurá-lo e guardá-lo com segurança. Em um ambiente de trabalho, confirme quais métodos de verificação são permitidos e quais são exigidos pelas políticas internas. Um recurso disponível no dispositivo ainda pode ser proibido ou configurado de outra maneira pela organização.
Em dispositivos gerenciados, verifique se o sistema operacional, o navegador e o provedor de identidade aceitam as opções necessárias, incluindo políticas de atestação ou de verificação do usuário. Combinações de versões e configurações podem se comportar de maneira diferente. Um teste piloto com as contas e os equipamentos pertinentes pode revelar incompatibilidades antes de ampliar a compra; é uma recomendação operacional, não uma garantia de funcionamento futuro. Registre o que foi testado e confirme que a configuração continua atendendo aos requisitos quando dispositivos e softwares mudarem.
Plano de contingência responsável: chaves adicionais e recuperação
Para reduzir o risco de bloqueio, registre uma chave de contingência nas contas que permitirem e guarde-a separada da chave principal. A Apple exige pelo menos duas chaves para ativar a proteção da Conta Apple com chaves de segurança. Para outros serviços, verifique suas próprias regras de registro e recuperação. Não presuma que uma passkey sincronizada substitua uma chave externa de contingência: são opções diferentes, e sua disponibilidade depende do ecossistema e do serviço. Decida antecipadamente onde guardar a chave de reserva e quem poderá precisar acessá-la.
O custo total pode incluir mais de uma chave, adaptadores e substituições. Como medida prática, confira periodicamente se as chaves registradas continuam disponíveis e se você sabe revogar uma chave perdida e registrar outra. Não faça testes que possam causar um bloqueio sem antes conhecer as regras de recuperação de cada conta. Uma opção de contingência só é útil se continuar acessível e se as etapas necessárias forem conhecidas antes de ocorrer um incidente.
Documente um procedimento de emergência: como recuperar a conta, como revogar uma credencial perdida e quem deve participar quando se tratar de uma conta de trabalho. Em uma organização, coordene essas instruções com as políticas de gestão de contas e continuidade. Mantenha códigos de recuperação e outros segredos separados da chave e protegidos adequadamente. A conclusão prática é simples: verifique primeiro a compatibilidade, registre uma opção de contingência onde for possível e conheça o processo de recuperação antes de depender da chave. Um pouco de preparação torna o plano de contingência parte da implementação, em vez de algo improvisado depois que o acesso já foi perdido.