Passkey existe para resolver um problema específico: eliminar o segredo compartilhável. Numa senha, o mesmo valor mora no seu cérebro e no banco de dados do serviço — e é esse valor duplicado que todo golpe de phishing rouba. Numa passkey, a chave privada nunca sai do dispositivo. Não há nada para copiar numa página falsa, porque não existe segredo em trânsito.
Por isso o mercado vende passkey como "resistente a phishing". A parte técnica dessa frase está certa. O problema é que ela descreve só metade do ciclo de vida da credencial.
O que a Microsoft documentou
Em 9 de setembro, a Microsoft publicou os detalhes de uma campanha ativa desde maio de 2026, atribuída a clusters de ameaça rastreados como Storm-3121 e Storm-3032. O método não tenta quebrar passkey nenhuma.
O ataque liga ou manda mensagem para o telefone pessoal da vítima — não o corporativo —, alegando ser o suporte de TI da própria organização. A urgência é sempre a mesma: "sua passkey, MFA ou configuração de SSO precisa ser atualizada agora, ou você perde acesso." A vítima é redirecionada, por SMS, para uma página que imita o login da Microsoft.
Ali, ninguém pede a chave privada — porque pedir não adiantaria nada. O que se pede é a aprovação de um cadastro novo: um segundo fator, uma sessão, um passo de recuperação. A vítima não entrega credencial. Ela autoriza o invasor a se tornar um segundo dono legítimo da conta.
Depois disso, o padrão observado é login incomum, seguido de método de autenticação adicionado pelo próprio invasor, volume alto de chamadas à Microsoft Graph API, download de arquivos do SharePoint e OneDrive, e coleta de e-mail via REST API. Tudo isso com credencial que o sistema considera válida — porque, tecnicamente, é.
O ponto cego tem nome: cadastro e recuperação
Toda passkey nasce de uma pergunta que a criptografia não responde: como o sistema sabe que é você pedindo a chave, na primeira vez? Esse é o problema de bootstrapping, e a maioria das implementações resolve com o mesmo mecanismo fraco que a passkey deveria substituir — telefone, e-mail, ou um agente de suporte convencido por uma boa história.
A recuperação tem o mesmo defeito, de trás para frente. Uma conta com passkey, mas com fallback de SMS ou código por e-mail ainda ativo, não é uma conta protegida por passkey. É uma conta protegida pelo elo mais fraco do fallback — e o invasor escolhe qual elo puxar.
A regra é simples de enunciar e rara de cumprir: o caminho de recuperação precisa ser tão resistente a phishing quanto o login principal. Uma porta da frente blindada com uma porta dos fundos de SMS continua sendo uma casa com uma porta de vidro. Só mudou qual porta o ladrão usa.
Cinco perguntas para fazer antes que alguém ligue
- Cadastrar uma passkey nova exige aprovação de um segundo fator já existente, ou basta responder a um SMS?
- Existe fallback de SMS ou e-mail ativo em alguma conta que já tem passkey? Se existe, a passkey não está protegendo nada — está coexistindo com a vulnerabilidade.
- O helpdesk tem instrução escrita de nunca aceitar pedido de atualização de autenticação por ligação recebida — só callback para um número já cadastrado?
- A criação de um novo método de autenticação dispara alerta de alto risco, ou é só mais uma linha de log entre milhares?
- Quantas contas privilegiadas têm um segundo dispositivo com passkey própria, para que perder um aparelho seja rotina de suporte, não uma porta de recuperação aberta?
Se a resposta a qualquer uma for "não sei", isso é o achado. Não precisa esperar o telefonema para descobrir.
O que isso tem a ver com governança
A ISO/IEC 27001:2022 trata disso no Anexo A.8.5, Autenticação Segura — e o controle já cobre entidade não humana e login sem senha, não só o campo de senha clássico. Mas nenhuma cláusula resolve isso sozinha se o cadastro do segundo fator não for auditado com o mesmo rigor que o login.
Passkey é controle técnico. Ele tira do usuário a decisão de "esse site é mesmo o Microsoft?" — decisão que, historicamente, humano erra sob pressão. Mas o cadastro e a recuperação reintroduzem exatamente essa decisão, num momento em que ninguém está olhando com a mesma atenção porque "já resolvemos isso com passkey".
Controle que depende de disciplina humana contínua não é controle. E um controle técnico com uma porta de emergência que ainda depende dela também não é.
Fontes: Microsoft Security Blog · The Hacker News · ISO 27001 Annex A.8.5