Uma nota sobre financiamento: o CypherpunkGuide não veicula publicidade de vigilância — nada de redes de anúncios, pixels de rastreamento ou conteúdo patrocinado. O projeto se sustenta com fontes transparentes de receita: doações de leitores agora; assinatura e afiliados alinhados à linha editorial mais adiante. Respondemos aos leitores, não aos anunciantes.
No login cotidiano, as passkeys já levam vantagem. O Índice de Passkeys de 2025 da FIDO Alliance registrou 93% de sucesso no login, contra 63% com outros métodos, e tempo médio de 8,5 segundos, em vez de 31,2 segundos. Elas também resistem ao phishing: um site falso não consegue induzir você a digitar um segredo reutilizável, pois a passkey não exige que você digite segredo algum.
Na recuperação, o cenário muda. Uma credencial excelente no uso normal ainda pode deixar você dependente do número de telefone, da conta de e-mail, do provedor em nuvem, de um aparelho confiável ou de um código em papel. Em 1º de agosto de 2026, examinei 25 documentos oficiais ou fontes primárias de Google, Apple, Microsoft, GitHub, FIDO e NIST. Apliquei a cada ecossistema a mesma falha: seu celular de uso diário, seu computador e a chave física que você carrega sumiram; restaram apenas os recursos de recuperação guardados em outro lugar. O resultado não foi um único processo de recuperação de passkey, mas uma sequência de duas ou três recuperações controladas por empresas diferentes, cada uma com suas próprias condições de bloqueio permanente.
A pergunta útil, portanto, não é apenas se passkeys são mais seguras que a autenticação de dois fatores por SMS — o 2FA, uma segunda prova usada depois da senha. Contra phishing, elas são. A pergunta completa é se você consegue recuperar o provedor da passkey e a conta que a aceitou sem depender de novo do mesmo aparelho perdido. Este guia mapeia essa dependência, corrige uma confusão entre contas pessoais e contas corporativas da Microsoft que já aparece nos resultados de busca e propõe uma migração que começa pela recuperação. Não retire seu último método de login ainda funcional enquanto segue o guia.
Recuperar uma passkey envolve duas recuperações diferentes#
Recuperar uma passkey pode significar restaurar a credencial por meio do provedor ou recuperar a conta de destino e cadastrar uma credencial nova. Empresas diferentes controlam essas operações, e concluir uma delas não garante a outra.
Uma passkey (chave de acesso) é uma credencial criptográfica criada para um site ou aplicativo. O site guarda a chave pública; seu aparelho ou gerenciador de credenciais guarda a chave privada. O WebAuthn, padrão da web usado pelas passkeys, vincula essa chave ao domínio verdadeiro do site. Por isso, o NIST SP 800-63B-4 classifica o WebAuthn configurado corretamente como resistente a phishing, ao contrário dos códigos de uso único digitados manualmente.
Há dois responsáveis por trás desse login:
- O provedor de credenciais armazena ou sincroniza a passkey. Apple Passwords com iCloud Keychain, Google Password Manager, Microsoft Password Manager, um gerenciador de senhas independente, Windows Hello e uma chave física de segurança podem cumprir esse papel.
- A relying party é o site ou aplicativo que aceita a passkey — em outras palavras, o serviço de destino. O GitHub é uma relying party. Google e Microsoft podem ser, ao mesmo tempo, provedor e serviço de destino quando você armazena com eles a passkey da própria conta.
Essa divisão de papéis foi o primeiro achado da auditoria. Comparações comuns colocam Apple, Google, Microsoft e GitHub em quatro colunas equivalentes, mas as colunas não representam a mesma coisa. Nesta análise, a Apple aparece principalmente como provedora; o GitHub, principalmente como serviço de destino. A diferença se torna decisiva depois da perda.
| Credencial ou rota | Onde fica o segredo | Sobrevive à perda de um aparelho? | Se todos os aparelhos de uso diário sumirem | Principal risco |
|---|---|---|---|---|
| Passkey sincronizada | Gerenciador de credenciais com criptografia de ponta a ponta | Em geral, se outro aparelho já estiver conectado | Recuperar a conta do provedor e passar pelo controle de recuperação da chave | A conta do provedor vira a principal dependência da recuperação |
| Passkey vinculada ao dispositivo | Um celular, computador ou chave física | A passkey não; a conta pode continuar acessível por outro autenticador | Recuperar a conta de destino por outra rota e cadastrar uma passkey nova | Perda permanente da credencial |
| Código de recuperação | Papel ou armazenamento offline seguro | Sim | Digitar o código de uso único ou o código longo de recuperação | Roubo, extravio ou armazenamento junto do aparelho |
| Recuperação por e-mail ou telefone | Outra conta ou a operadora | Às vezes | Recuperar esse canal primeiro | Phishing, SIM swap ou falha compartilhada |
O documento da FIDO sobre implantação de passkeys sincronizadas é preciso nesse ponto: a sincronização aumenta a chance de sobreviver à perda de um aparelho, mas o usuário ainda pode perder o acesso ao provedor ou não conseguir passar pelo processo de restauração. “Sincronizada” quer dizer que existe uma cópia protegida. Não quer dizer que o provedor sempre conseguirá devolvê-la a você.
O que acontece se todos os aparelhos de uso diário sumirem?#
Se todos os aparelhos de uso diário sumirem, uma passkey sincronizada só volta pelo provedor de credenciais; uma passkey vinculada ao dispositivo se perde. A conta de destino só sobrevive se ainda houver uma recuperação funcional guardada em outro lugar.
Apliquei exatamente esse cenário a quatro ecossistemas e registrei as evidências na auditoria de recuperação de passkeys, disponível para download. A matriz é uma auditoria documental, não um teste com bloqueio real: não removi autenticadores de contas ativas, e você também não deve fazer isso apenas para reproduzir a análise.
As linhas abaixo se limitam a contas pessoais administradas pelo próprio titular. Contas gerenciadas por administrador ou provedor de identidade — como Google Workspace, Managed Apple Accounts, GitHub Enterprise Managed Users e identidades do Microsoft Entra — obedecem às políticas da organização e ficam fora da matriz. As datas do Entra aparecem mais adiante somente para corrigir a confusão entre o cronograma corporativo e as contas pessoais.
| Ecossistema | Papel nesta auditoria | Restauração da passkey sincronizada | Controles documentados de recuperação | Sobrevive à perda dos aparelhos de uso diário se… | Limite de falha ou bloqueio permanente |
|---|---|---|---|---|---|
| Conta pessoal Google | Provedor e relying party | Google Password Manager pela Conta Google, mais o PIN próprio ou um aparelho elegível usado anteriormente | Provedor/Conta Google: informações de recuperação; contas elegíveis podem adicionar um contato de recuperação | Pelo menos um canal ou contato de recuperação continuar acessível sem o hardware perdido | O PIN do Password Manager não puder ser recuperado e a coleção de passkeys for redefinida; cada site de destino exigirá recuperação separada |
| Conta pessoal Apple | Principalmente provedor | Recuperação segura do iCloud Keychain pelos controles da Conta Apple | Provedor/Conta Apple: recuperação padrão, contato de recuperação aceito ou a rota opcional da chave de recuperação | O número confiável puder ser recuperado, ou um contato pré-cadastrado ou a chave de 28 caracteres estiver disponível fora dos aparelhos perdidos | A chave de recuperação estiver ativa, mas não houver aparelho confiável nem chave de 28 caracteres e, quando a Proteção Avançada de Dados permitir as duas opções, nenhum contato utilizável |
| Conta pessoal Microsoft | Provedor e relying party | Gerenciador sincronizado por login no provedor; Windows Hello ou chave física podem conter uma credencial vinculada ao dispositivo | Provedor/Conta Microsoft: informação de segurança alternativa ou código de recuperação de 25 dígitos | Um canal alternativo continuar acessível ou o código de 25 dígitos tiver sido guardado offline | Verificação em duas etapas ativa e nenhum método alternativo acessível; a Microsoft diz que o suporte não pode contornar o bloqueio |
| Conta pessoal GitHub | Principalmente relying party | O provedor restaura a credencial sincronizada; o GitHub não guarda a chave privada | Conta pessoal de destino: 16 códigos de uso único, outra passkey ou chave de segurança, chave SSH, token de acesso pessoal (PAT) ou aparelho verificado | Um código offline ou autenticador guardado separadamente sobreviver; SSH, PAT e aparelho verificado só contam se o GitHub ainda os aceitar na recuperação | Não restar passkey nem método de recuperação aceito; o Suporte do GitHub não consegue restaurar o acesso |
A tabela também revela outro problema: dizer “uso uma passkey” não informa onde ela está. Uma tela do Windows pode salvar uma credencial no Windows Hello de uma máquina e outra em um gerenciador sincronizado. Um fluxo por código QR pode usar o celular só naquela sessão ou salvar a credencial nele. Antes de planejar a recuperação, abra a lista de passkeys no site e a lista de credenciais no provedor. Registre provedor e aparelho, não apenas o nome do site.
As quatro rotas de recuperação, plataforma por plataforma#
Os quatro ecossistemas permitem usar passkeys com segurança, mas não recuperam do mesmo jeito. O local de armazenamento, a recuperação da conta do provedor e um recurso guardado fora dos aparelhos de uso diário determinam se a perda vira bloqueio.
Contas pessoais Google: o PIN do Password Manager importa#
O Google Password Manager sincroniza passkeys entre Android, Chrome, iPhone e iPad. Quando alguém cria uma passkey pela primeira vez em um computador, iPhone ou iPad, o Google pode criar também um PIN separado para o Password Manager. A documentação do PIN explica que ele ajuda a liberar as passkeys em um aparelho novo e mantém os dados criptografados ilegíveis para o Google.
Adicionar uma passkey a uma Conta Google pessoal não apaga automaticamente a senha, as informações de recuperação nem os outros fatores de autenticação. O guia de passkeys para a Conta Google também informa que a passkey pode cumprir a segunda etapa do login. As duas informações precisam ficar juntas: no uso diário, uma passkey pode substituir “senha mais código”; os fatores antigos continuam disponíveis para recuperação, a menos que você os remova de propósito.
O limite aparece quando o PIN é esquecido. O Google permite redefini-lo em um aparelho não Android no qual as passkeys do Google Password Manager tenham sido usadas antes. Se todos os aparelhos elegíveis já foram tentados e o PIN ainda não pode ser recuperado, a solução documentada é redefinir as passkeys. A ação apaga todas as passkeys do Google Password Manager; ela não emite credenciais novas em cada site. Você terá de recuperar cada conta de destino e cadastrar novas passkeys.
É aqui que separei duas linhas que muitos resumos misturam. O processo de recuperação do Google pode devolver o acesso ao Gmail e à Conta Google. A recuperação do Password Manager devolve o acesso à coleção criptografada de passkeys. Recuperar a conta não prova, por si só, que você consegue descriptografar essa coleção. Em alguns bloqueios da verificação em duas etapas, o Google informa no guia de solução de problemas que a análise pode levar de 3 a 5 dias úteis. Em 2025, o Google lançou os Contatos de Recuperação para contas pessoais elegíveis; como há critérios de elegibilidade e liberação gradual, trate o recurso como reforço opcional, não como promessa universal.
Contas pessoais Apple: recuperar o iCloud Keychain exige pré-requisitos#
A Apple projetou o iCloud Keychain para sincronizar senhas e passkeys com criptografia de ponta a ponta: os servidores transferem registros criptografados sem manter cópias legíveis. O guia de Segurança da Plataforma afirma expressamente que a recuperação do chaveiro deve funcionar mesmo quando todos os aparelhos do usuário estão inacessíveis. É uma afirmação mais forte e mais precisa do que “as passkeys estão no iCloud”.
O processo, porém, tem condições. A página sobre segurança de passkeys diz que a recuperação depois de perder todos os aparelhos pode exigir a senha da Conta Apple, uma mensagem de texto enviada ao número cadastrado e o código de desbloqueio do aparelho. O serviço que mantém sob custódia o registro da recuperação criptografada permite 10 tentativas de autenticação; depois da décima falha, o registro é destruído. Portanto, existe uma rota planejada para o caso de todos os aparelhos ficarem inacessíveis, mas ela não é uma garantia sem limites.
A recuperação ainda depende da Conta Apple. O processo padrão pode usar credenciais da conta, um número de telefone confiável, códigos de desbloqueio dos aparelhos e uma espera definida pela Apple. Um contato de recuperação pode fornecer um código de seis dígitos, e a Apple permite cadastrar até cinco contatos. O contato não lê a conta; apenas ajuda na verificação da identidade.
A Apple também avisa que a recuperação da conta pode levar vários dias ou mais e que o Suporte não consegue encurtar a espera. É uma rota de último recurso, não acesso emergencial para o mesmo dia.
A chave de recuperação opcional merece um alerta claro. A documentação da chave informa que a chave de 28 caracteres desativa a recuperação padrão da conta. Com a Proteção Avançada de Dados, a Apple permite manter uma chave de recuperação e um contato de recuperação ao mesmo tempo e diz que qualquer um dos dois pode restabelecer o acesso. Se você não souber mais a senha, não tiver aparelho confiável, não puder apresentar a chave e não tiver contato configurado disponível, a Apple diz que o bloqueio pode ser permanente. A chave só aumenta sua autonomia quando fica fora da conta que protege. Guardar a única cópia no Apple Notes, iCloud Drive ou aplicativo Passwords cria um circuito fechado; a Apple recomenda expressamente não usar esses locais.
As chaves físicas de segurança da Conta Apple são um recurso separado das passkeys sincronizadas pelo iCloud Keychain. A Apple exige pelo menos duas chaves físicas e permite até seis. O guia de chaves de segurança alerta que perder todos os aparelhos confiáveis e todas as chaves cadastradas pode bloquear a conta para sempre. Uma chave reserva só ajuda se já estiver cadastrada, testada e guardada longe dos aparelhos de uso diário.
Microsoft: contas pessoais não seguem o cronograma de retirada do Entra#
A Microsoft oferece passkeys sincronizadas e vinculadas ao dispositivo. O guia para consumidores define a primeira como uma credencial recuperada pelo gerenciador e a segunda como uma credencial perdida com o aparelho, salvo quando existe outro método. O Microsoft Password Manager está sendo liberado aos poucos para perfis pessoais do Edge; Windows Hello e chaves físicas podem guardar passkeys vinculadas ao dispositivo.
Conferi na fonte a manchete “Microsoft retira o SMS em setembro de 2026”, porque ela muda a recomendação. A implantação de 1º de setembro de 2026 é uma política para tenants do Entra ID, ou seja, diretórios gerenciados por organizações: as passkeys são habilitadas automaticamente para usuários que já têm SMS ou voz habilitados, e eles recebem um aviso para cadastrá-las. O tenant pode optar temporariamente por não participar até 1º de fevereiro de 2027, quando a entrega de SMS e voz fornecida pela Microsoft para o Entra será retirada. Separadamente, a Microsoft afirma que está eliminando gradualmente os códigos por SMS das contas pessoais, mas a página para consumidores não estabelece um corte universal em setembro de 2026. Misturar os dois escopos levaria leitores com contas pessoais a remover um método por causa de um prazo falso.
A recuperação da conta pessoal tem outro limite. Se a verificação em duas etapas estiver ativa e nenhum método alternativo estiver acessível, a Microsoft diz que o suporte não consegue ajudar pelo formulário comum de recuperação. A empresa também oferece um código de recuperação de 25 dígitos. Segundo o guia desse código, mudanças nas informações de segurança com a verificação em duas etapas podem levar 30 dias. Gere e guarde o código antes da crise, não depois de perder o aparelho com a passkey.
Contas pessoais GitHub: várias opções, nenhum atalho pelo suporte#
Esta análise cobre titulares de contas pessoais que administram as próprias credenciais; a documentação do GitHub não estende esse modelo de recuperação às contas gerenciadas por empresas. Em uma conta pessoal, uma passkey pode cumprir tanto a senha quanto o segundo fator no login pelo navegador. A Apple, o Google, a Microsoft ou outro provedor que guarde a chave privada é responsável por recuperar a passkey sincronizada. A página de gerenciamento de passkeys do GitHub orienta o usuário a procurar esse provedor. Uma chave de segurança vinculada a um dispositivo não se torna recuperável só porque ainda aparece na lista do GitHub.
Do outro lado da cadeia, a documentação do GitHub é clara. Ela fornece 16 códigos de uso único nas orientações de recuperação, além de listar chaves SSH, tokens de acesso pessoal e aparelhos verificados como provas possíveis. Uma chave SSH é a chave criptográfica usada para autenticar conexões ao GitHub; um PAT é um token de acesso pessoal que pode substituir a senha em operações autorizadas. O GitHub avisa que um método pode ser recusado mesmo que tenha funcionado antes — por exemplo, uma chave SSH inativa. Verifique a elegibilidade em vez de presumir. Uma solicitação com aparelho verificado ou chave SSH que o GitHub aceite pode levar até três dias úteis.
Para essas contas pessoais, o limite final é direto: se todas as credenciais e todos os métodos de recuperação sumirem, o Suporte do GitHub não restaura uma conta com 2FA. O guia para credenciais perdidas descreve a perda como permanente. Salve os códigos offline e cadastre mais de um método antes de transformar a passkey no login cotidiano.
O paradoxo da recuperação: login forte, alternativa mais fraca#
O paradoxo da recuperação aparece quando o login resiste ao phishing, mas a alternativa usada para substituí-lo é mais fraca. O atacante pode mirar o e-mail, o telefone, o atendimento ou a conta em nuvem que tem permissão para trocar a passkey.
Isso não torna as passkeys um erro. Mostra que a recuperação faz parte da autenticação, e não é apenas uma formalidade escondida. A orientação de recuperação do NIST trata a recuperação de conta como um evento de gerenciamento de autenticadores e exige mecanismos adequados ao nível de garantia da conta. Um código de uso único é útil porque pode ser independente; ele não resiste ao phishing se você o digitar em um site falso.
| Rota de recuperação | Independe dos aparelhos perdidos? | Resiste a phishing? | Melhor uso | Como reforçar |
|---|---|---|---|---|
| Código de recuperação offline | Sim, se estiver fora dos aparelhos | Não | Acesso emergencial | Papel ou cópia offline criptografada; nunca apenas na nuvem |
| Segunda chave física | Sim, se estiver guardada em outro lugar | Sim | Contas de alto valor | Cadastre duas, teste ambas e guarde uma em outro local |
| Passkey sincronizada no mesmo provedor | Em parte | Sim no login | Conveniência diária e perda de um único aparelho | Reforce a recuperação do provedor e mantenha um método externo |
| E-mail de recuperação | Só quando for uma conta separada | Não por si só | Recuperação ampla da conta | Outro provedor, passkey e recuperação independente |
| Telefone de recuperação/SMS | Só se a linha continuar acessível | Não | Compatibilidade como último recurso | Cadastre um PIN próprio na operadora — uma senha extra exigida antes de alterar a conta ou transferir o número — e reduza a exposição com um modelo de ameaça para o número de telefone |
| Contato de recuperação | Sim, se a pessoa e o aparelho dela estiverem disponíveis | Não por si só | Recuperar Apple ou uma Conta Google elegível | Escolha com cuidado; ensaie o contato e a verificação de identidade |
A portabilidade está avançando, mas não baseie sua recuperação em uma promessa futura. Em março de 2026, a FIDO publicou o Credential Exchange Format como padrão proposto, voltado à importação e exportação seguras de credenciais. A existência do padrão não prova que seus provedores atuais transferem hoje todas as passkeys. Confira os controles de exportação e importação nos dois produtos antes de depender de uma mudança entre provedores.
A contrapartida para a privacidade também é clara. A sincronização protege contra a perda de um aparelho, mas concentra a recuperação em uma conta na nuvem. Chaves vinculadas ao dispositivo reduzem essa dependência do provedor, porém aumentam o custo da perda física. É a mesma diferença entre operar algo por conta própria e apenas deslocar a confiança para outro painel que uso na auditoria de soberania em cinco camadas. Escolha a partir de um adversário e de uma falha concretos, não de um slogan.
Faça a migração começando pela recuperação#
Uma migração segura começa pela recuperação. Liste onde cada credencial está, adicione um método fora do provedor, teste sem destruir nada e só então passe o SMS ou a senha para segundo plano.
- Anote a conta e o provedor separadamente. Escreva
GitHub — Google Password Manager, não apenasGitHub — passkey. Marque cada passkey como sincronizada, vinculada ao dispositivo ou desconhecida. Se não souber, não remova nada ainda. - Proteja primeiro a conta do provedor. Você só recupera uma passkey sincronizada se também conseguir recuperar a conta da Apple, do Google, da Microsoft ou do seu gerenciador independente. Atualize e-mail de recuperação, telefone confiável, contato de recuperação e autenticador independente. Aplique o método que começa pelo adversário usado no nosso modelo de ameaça para a era da IA.
- Crie uma recuperação fora desse provedor. Conforme o serviço, imprima códigos de recuperação, guarde uma segunda chave física em outro lugar ou use uma chave SSH somente se o serviço ainda a aceitar na recuperação. Nesse caso, mantenha a chave privada ou um backup já testado em outro aparelho. Não deixe a única cópia dentro da mesma conta em nuvem.
- Teste sem destruir o que funciona. Abra uma janela privativa ou outro perfil do navegador, inicie o login e confirme que o método reserva aparece. Prefira uma consulta de status que não altere nada, quando houver. Se o teste consumir um código de uso único, marque-o como usado e substitua-o imediatamente ou gere de novo o conjunto guardado. Não acione uma recuperação completa, apague a passkey principal, apague os dados de um aparelho nem encerre todas as sessões confiáveis apenas como exercício.
- Guarde as instruções offline. Inclua o nome do provedor, a conta de destino, o local do recurso reserva e a URL oficial de recuperação. A disciplina é a mesma do ensaio de restauração na primeira prática de autocustódia de Bitcoin: se você nunca testou um backup, apenas acredita que ele funciona; a recuperação ainda não foi comprovada.
- Reduza o papel do método antigo em uma conta por vez. Prefira a passkey no login diário. Só retire o SMS depois que a rota independente funcionar e se o serviço não exigir o número na recuperação. Confira tudo de novo ao trocar de celular, gerenciador de senhas, conta Apple/Google/Microsoft ou chave de segurança.
A ordem importa. Retirar o SMS primeiro e “adicionar a reserva depois” abre um período em que uma queda que quebre o celular, uma tela com defeito, uma chave perdida ou uma escolha errada de provedor pode causar bloqueio permanente. Segurança deve reduzir as causas que podem falhar juntas, não acrescentar mais uma.
Conclusão — devo substituir o SMS agora?#
Use passkeys no login diário, mas só retire ou deixe o SMS como opção secundária depois que outra rota passar por um teste seguro em um navegador sem sessão ativa. Busque um login resistente a phishing e uma recuperação que não dependa de um único aparelho ou provedor em nuvem.
A evidência sobre o login normal é forte: os dados da FIDO acima e o relatório de 2024 do Google, com mais de 1 bilhão de autenticações em 400 milhões de contas e logins 50% mais rápidos, medem o uso cotidiano — não a recuperação depois da perda dos aparelhos.
O caso de perda não cabe em uma única função do produto. O Google Password Manager pode exigir o PIN; a Apple pode exigir recuperação da conta, contato ou chave de recuperação; contas pessoais Microsoft têm informações alternativas e código de 25 dígitos; o GitHub depende dos códigos próprios ou de outra prova já cadastrada. A frase “está salvo na nuvem” esconde todas essas condições.
Comece pela conta cuja perda causaria mais dano. Mapeie o provedor de credenciais e o serviço de destino, guarde um método de recuperação fora dos dois, teste e só então avance para a próxima conta. É mais lento do que clicar em “usar passkey” em todo lugar numa tarde. Também é assim que você ganha proteção contra phishing sem deixar que uma bolsa perdida leve junto o acesso à sua identidade digital.
Perguntas frequentes#
Passkeys são mais seguras que a autenticação de dois fatores por SMS?#
Contra phishing, sim. Uma passkey WebAuthn fica vinculada ao domínio verdadeiro, então um site falso não consegue coletar um segredo reutilizável. Um código por SMS pode ser digitado em uma página falsa ou interceptado depois de um SIM swap. A recuperação é outro problema: se o serviço ainda aceita SMS para substituir uma passkey perdida, essa rota mantém os riscos do SMS.
O que acontece com minhas passkeys se eu perder o celular?#
Passkeys sincronizadas podem voltar quando você recuperar e desbloquear o gerenciador de credenciais em outro aparelho. Uma passkey vinculada apenas ao celular se perde. Nos dois casos, um segundo autenticador ou a recuperação oferecida pelo site decide se você retoma o acesso sem aquele celular.
Apple, Google ou Microsoft conseguem ler minhas passkeys sincronizadas?#
Os documentos das plataformas descrevem as coleções como criptografadas de ponta a ponta ou protegidas para que o provedor não receba a chave privada em formato legível. Isso não elimina a dependência: o provedor ainda opera a conta, a sincronização, as regras de recuperação e o software que controla o acesso à coleção criptografada.
Devo apagar minha senha e o número usado no SMS depois de adicionar uma passkey?#
Não de imediato. Primeiro, adicione uma recuperação independente e teste-a em um navegador sem sessão ativa, sem apagar nada. Depois, se o serviço permitir e a recuperação não depender do mesmo aparelho ou provedor, remova ou deixe os métodos mais fracos em segundo plano, uma conta por vez.
O suporte recupera minha conta se todas as passkeys e todos os códigos sumirem?#
Não conte com isso. O GitHub afirma que o Suporte não restaura uma conta com 2FA sem método de recuperação aceito. A Microsoft diz que o formulário de recuperação de conta pessoal não ajuda quando a verificação em duas etapas está ativa e nenhum método alternativo permanece acessível. Prepare o fator independente antes da perda.
Fontes#
