- Um passkey substitui a senha por um par de chaves criptográficas: a chave privada nunca sai do dispositivo, o que significa que não há como phishing, vazamentos ou força bruta roubarem suas credenciais.
- O FIDO2 elimina phishing de credenciais de forma arquitetural. Os desafios de autenticação são vinculados à origem, então um site falso nunca recebe uma resposta válida.
- Senhas continuam falhando: 81% das violações de dados envolvem credenciais, mais de 15 bilhões de credenciais estão à venda em mercados da dark web, e as gerações mais jovens os reutilizam mais, não menos.
- A implantação empresarial requer planejamento de recuperação de conta, gerenciamento de dispositivos e uma estratégia híbrida para sistemas legados que não suportam WebAuthn.
- Microsoft, Apple e Google oferecem suporte nativo a passkeys. Chaves de hardware FIDO2 como YubiKey funcionam onde sincronização de plataforma não é viável.
O que é um passkey
Um passkey é uma credencial criptográfica que substitui uma senha. Quando você cria um passkey para um serviço, seu dispositivo gera um par de chaves: uma chave pública, enviada ao servidor, e uma chave privada, armazenada com segurança no seu dispositivo. Para autenticar, o servidor envia um desafio que seu dispositivo assina com a chave privada. O servidor verifica a assinatura com a chave pública.
A chave privada nunca sai do dispositivo. O servidor nunca a vê. Não há segredo compartilhado que possa ser roubado de um banco de dados, não há senha que possa ser phishing, não há string de texto que possa ser adivinhada. A autenticação é verificação de que você possui o dispositivo com a chave privada, confirmada por biometria ou PIN do dispositivo.
Passkeys de plataforma (armazenados no iOS Keychain, Windows Hello ou Android) sincronizam pelo ecossistema do fornecedor do SO, tornando-os portáteis entre dispositivos. Passkeys vinculados a dispositivos (em chaves de segurança de hardware como YubiKey) não sincronizam.
Por que as senhas continuam falhando
O MFA padrão, que envia um código de seis dígitos por SMS ou aplicativo, é melhor do que nenhuma proteção, mas não é à prova de phishing. Um atacante que direciona um usuário para uma página de login falsa pode capturar a senha e o código OTP em tempo real e reproduzi-los antes que o código expire. Esse ataque é amplamente documentado e ativo. Os kits de phishing que o automatizam são baratos e amplamente disponíveis.
O FIDO2 resolve isso estruturalmente. O desafio de autenticação inclui a origem (o domínio do site). Quando seu dispositivo assina o desafio, a assinatura é vinculada a essa origem específica. Um site de phishing em um domínio diferente recebe uma assinatura que não pode ser usada no site legítimo. O ataque não falha porque o usuário detecta a tentativa de phishing; falha porque o protocolo não produz uma resposta reutilizável.
Suporte de plataforma
Microsoft
Windows Hello suporta autenticação passkey para contas Microsoft e, via Microsoft Authenticator, para contas Entra ID. O Microsoft Authenticator no iOS e Android armazena passkeys de plataforma e pode servir como autenticador FIDO2 para serviços que suportam WebAuthn. A Autenticação Resistente a Phishing do Entra ID refere-se ao uso de FIDO2 ou autenticação baseada em certificado.
Apple
O iCloud Keychain sincroniza passkeys entre dispositivos Apple via Face ID ou Touch ID. Passkeys criados em um iPhone estão disponíveis no Mac e iPad do mesmo Apple ID. Para implantação empresarial, o Gerenciamento de Dispositivos Móveis (MDM) pode gerenciar passkeys em dispositivos registrados.
O Google Password Manager sincroniza passkeys entre dispositivos Android e Chrome. Passkeys do Google Workspace suportam login sem senha em serviços Google e terceiros. A chave de segurança avançada do Android pode funcionar como autenticador de hardware vinculado ao dispositivo via Bluetooth para outros dispositivos.
Chaves de hardware
YubiKey, chaves de segurança da Google e dispositivos similares compatíveis com FIDO2 funcionam como autenticadores externos. A chave privada nunca sai da chave de hardware, tornando-as adequadas para usuários com acesso privilegiado, trabalho de alta segurança ou em ambientes onde sincronização de plataforma não é viável.
Implantação empresarial
Mapeie seus sistemas contra o suporte WebAuthn
Antes de qualquer rollout, catalogue os sistemas que seus funcionários usam e identifique quais suportam autenticação WebAuthn. Aplique o Microsoft Entra ID ou Okta como seu provedor de identidade central se ainda não o fez. Sistemas que suportam SSO herdam o suporte a passkeys do provedor de identidade, mesmo que não suportem WebAuthn diretamente.
Planeje a recuperação de conta
A perda de dispositivo é o principal caso extremo de passkeys que requer planejamento antes do rollout. Defina o processo: qual é o procedimento de verificação de identidade? Quem pode provisionar um novo passkey? Quanto tempo leva? Para funcionários com acesso privilegiado, considere exigir verificação presencial antes de provisionar novas credenciais após perda de dispositivo.
Gerencie a heterogeneidade de dispositivos
Ambientes corporativos mistos (Windows, Mac, iOS, Android, Linux) têm diferentes capacidades de passkey. Windows Hello funciona em dispositivos gerenciados. Dispositivos pessoais usados para trabalho (BYOD) precisam de uma estratégia separada: ou o Microsoft Authenticator ou Google Password Manager como autenticador de plataforma, ou chaves de hardware para usuários com acesso mais sensível.
Execute um piloto antes da implantação ampla
Implante para 20 a 50 usuários representando diferentes departamentos, tipos de dispositivo e padrões de trabalho. Colete feedback sobre o que funcionou e onde as pessoas encontraram dificuldades. Ajuste sua documentação e processo de suporte antes da implantação ampla.
Acesso Condicional e aplicação de passkeys
No Microsoft Entra ID, o Acesso Condicional pode exigir métodos de autenticação resistentes a phishing (FIDO2 ou certificado) para recursos específicos. Defina políticas que exijam passkeys para acesso a dados de alta sensibilidade, como ambientes de administração, repositórios de dados financeiros e sistemas de RH. Isso permite uma abordagem gradual: passkeys obrigatórios onde o risco é mais alto, com MFA padrão aceito em outros lugares enquanto o rollout avança.
Monitore os logs de autenticação para ver onde os usuários estão usando passkeys versus métodos mais antigos. Isso identifica candidatos para o próximo estágio do rollout e mostra se as políticas de Acesso Condicional estão funcionando conforme esperado.
Cinco passos para iniciar
- Audite seu provedor de identidade. Se você usa Entra ID, Okta ou Ping, verifique se a autenticação FIDO2 está habilitada e qual nível de suporte a passkeys de plataforma e hardware está disponível. Isso define o teto técnico do seu rollout.
- Mapeie os sistemas de alto valor primeiro. Identifique os 10 a 20 sistemas que apresentam o maior risco se comprometidos. Esses são os candidatos para autenticação resistente a phishing obrigatória na sua primeira fase.
- Defina seu plano de recuperação de conta antes do rollout. Documente o processo de verificação de identidade para reemissão de credenciais. Certifique-se de que o helpdesk compreende o processo e tem as ferramentas para executá-lo antes de habilitar passkeys para qualquer usuário.
- Execute um piloto com usuários representativos. Escolha usuários em diferentes departamentos, funções e tipos de dispositivo. Execute o piloto por quatro a seis semanas. Documente o que funcionou, o que não funcionou e quais perguntas os usuários fizeram com mais frequência.
- Defina um roteiro de fim de vida para senhas. Passkeys por si só não eliminam senhas se as senhas ainda são aceitas como fallback. Defina uma data alvo para desabilitar a autenticação baseada em senha para cada sistema de alto valor. O roteiro mantém o momentum e dá à equipe uma meta a trabalhar.
Ryland lidera programas de cibersegurança, conformidade e gestão de TI para organizações regulamentadas no Brasil, Reino Unido e Países Baixos há mais de 20 anos, com cargos sênior na Microsoft, ING, IPsoft, PPHE e mais. Perfil completo