Problemas do Dia 2 das Chaves de Acesso: 5 Riscos após o Lançamento

1. Introdução: Riscos das chaves de acesso após o lançamento#

Não implemente chaves de acesso.

Pelo menos não a qualquer custo e não se você não tiver os recursos para fazê-lo adequadamente.

Sim, as chaves de acesso são a melhor coisa que aconteceu com a autenticação de consumidores em uma década. Sim, elas acabam com o phishing. Sim, elas podem melhorar massivamente a experiência do usuário (UX). Mas as chaves de acesso mal implementadas também podem causar muitos danos.

A implementação de um servidor WebAuthn não é muito complexa. O verdadeiro desafio é tudo o que o envolve. Operar chaves de acesso com eficiência e em escala exige planejamento antecipado. Você precisa pensar em todos os problemas do "Dia 2" — as realidades operacionais que só surgem após o início da implementação das chaves de acesso.

Este artigo aborda os cinco problemas do Dia 2 que invariavelmente destroem projetos de chaves de acesso. Se você não consegue resolver todos eles, não está pronto para lançar as chaves de acesso. Se você conseguir, construirá uma autenticação que é, ao mesmo tempo, mais segura e mais utilizável do que qualquer coisa que as senhas poderiam oferecer.

2. O que são os problemas do Dia 2 das chaves de acesso?#

Na engenharia, o "Dia 1" é quando você constrói e lança. O "Dia 2" é quando você opera, mantém e escala o que lançou. Para as chaves de acesso, o Dia 1 pode ser simples:

• integrar um servidor WebAuthn à sua pilha corporativa
• adicionar os fluxos de frontend e lançar.

A maioria das equipes consegue colocar uma implementação básica de chaves de acesso em funcionamento em poucos dias ou semanas.

O Dia 2 é onde os projetos falham. É o momento em que usuários reais, em dispositivos reais, com casos extremos reais, interagem com o seu sistema de chaves de acesso. É quando você descobre que aquela demonstração brilhante, que funcionou perfeitamente no seu MacBook, quebra em um laptop Windows executando o Chrome atrás de um proxy corporativo. É quando a sua equipe de suporte é inundada com tickets dizendo "não consigo mais fazer login".

A distância entre uma demonstração funcional de chaves de acesso e uma implantação de chaves de acesso em nível de produção é enorme. Já abordamos as armadilhas de implementação técnica e os motivos estratégicos pelos quais os projetos de chaves de acesso falham. Este artigo concentra-se especificamente no que acontece depois que você entra em produção, a partir de uma perspectiva operacional.

3. Problema 1: A recuperação e o fallback são difíceis de proteger#

Se você não projetar a recuperação e o fallback adequadamente, ou você bloqueará os usuários em grande escala ou reintroduzirá silenciosamente os mesmos fluxos propensos a phishing que queria eliminar.

3.1 Risco de bloqueio de conta em grande escala#

Considere um usuário que registra uma chave de acesso em seu iPhone e depois perde esse iPhone. Geralmente, grande parte desses casos de recuperação é agora tratada pelo gerenciador de credenciais (provavelmente as Senhas do iCloud nos iPhones). Desde que o usuário tenha acesso à sua conta da Apple, ele terá chaves de acesso sincronizadas disponíveis para fazer login em um novo dispositivo. Mas e se eles não tiverem mais acesso a essa conta na nuvem? É aqui que o seu caminho de recuperação normal entra em ação.

Digamos que você assuma que a chave privada ainda está disponível no dispositivo de onde o usuário tenta fazer login, então você inicia a cerimônia de login do WebAuthn. Isso resultará em um modal do SO/navegador pedindo ao usuário para "fazer login com sua chave de acesso em outro dispositivo". Basicamente, o usuário está agora bloqueado em sua conta. Não há outro dispositivo onde a chave de acesso esteja armazenada. O usuário fica extremamente confuso. Multiplique isso por milhares de usuários e você terá uma crise de suporte.

A reação comum é adicionar redefinições de conta baseadas em e-mail como um fallback. Mas isso anula o propósito das chaves de acesso: você acabou de reintroduzir um canal de recuperação vulnerável a phishing. Um invasor que possa comprometer o e-mail de um usuário agora pode contornar totalmente a sua implementação de chaves de acesso resistente a phishing.

3.2 Projetando fallback sem reintroduzir o phishing#

Em nossa opinião, a abordagem correta é uma recuperação em camadas:

1. Chaves de acesso sincronizadas como a estratégia principal: certifique-se de que os usuários criem chaves de acesso sincronizadas (através das Senhas do iCloud, Gerenciador de Senhas do Google ou um provedor de chaves de acesso terceirizado) para que a perda do dispositivo não signifique perda de credenciais
2. Autenticação entre dispositivos como uma segunda camada: permita que os usuários se autentiquem a partir de outro dispositivo onde outra chave de acesso esteja disponível, digitalizando um código QR
3. Verificação de identidade (IDV) como a terceira camada: ofereça IDV automatizada com testes de vivacidade em vez de retroceder para senhas/OTPs.
4. Credenciais digitais verificáveis como a quarta camada: é a versão mais segura, que preserva a privacidade e é mais fácil de usar para a recuperação de contas. Isso permite que o usuário use suas credenciais digitais verificáveis (por exemplo, identidade nacional digital ou mDL) para verificar sua identidade usando APIs padrão (por exemplo, Digital Credentials API). Essa tecnologia é relativamente nova e a adoção não é alta, mas desempenhará um papel importante nos próximos meses e anos.

Em geral, você precisa decidir quais camadas de recuperação de contas podem ser justificadas a partir de uma perspectiva de custo/atrito. Por exemplo, no varejo / e-commerce, você pode oferecer apenas as duas primeiras camadas e aceitar o risco de phishing por razões financeiras. Em outros setores, onde a segurança é mais importante, você avança para a camada 3 e 4.

Cada camada adiciona complexidade. Você precisa decidir quais camadas o seu caso de uso exige, construí-las, testá-las em todas as combinações de dispositivos e monitorar o seu uso. Isso é significativamente mais trabalho do que a integração inicial do WebAuthn.

3.3 O que a maioria das equipes faz de errado#

A maioria das equipes simplifica demais a recuperação (voltando a usar senhas ou SMS OTP) ou complica demais (por exemplo, exigindo chaves de segurança de hardware para toda recuperação). O equilíbrio correto depende do seu modelo de ameaças, base de usuários e requisitos regulatórios. Fazer isso da forma errada significa minar sua postura de segurança ou criar tanto atrito que os usuários abandonam o fluxo.

4. Problema 2: Casos extremos entre dispositivos e ecossistemas quebram os fluxos de chaves de acesso#

Seus usuários não vivem em um mundo limpo e exclusivo da Apple. Eles trocam de dispositivo, misturam o Windows com o iOS, usam navegadores diferentes e trabalham em configurações gerenciadas por corporações. É aí que os fluxos de chaves de acesso falham se você não os planejou.

4.1 A fragmentação do ecossistema é real#

O ecossistema das chaves de acesso abrange três plataformas principais (Apple, Google e Microsoft), vários navegadores (Chrome, Safari, Firefox e Edge), dezenas de provedores de chaves de acesso / gerenciadores de credenciais (como 1Password, Bitwarden, Dashlane e outros) e inúmeras combinações de SO/navegador/dispositivo. Cada combinação pode se comportar de maneira ligeiramente diferente, por exemplo:

• A Apple sincroniza as chaves de acesso por padrão via Senhas do iCloud em todo o iOS, iPadOS e macOS, mas não para o Windows ou Android
• O Google sincroniza através do Gerenciador de Senhas do Google pelo Android e Chrome, mas a experiência no iOS é diferente (você precisa configurá-lo manualmente)
• O Windows tem seu próprio comportamento para chaves de acesso que difere significativamente de outras plataformas
• Cada gerenciador de senhas lida com a criação e seleção de chaves de acesso de forma diferente, por vezes entrando em conflito com os avisos nativos da plataforma

4.2 Fluxos de autenticação entre dispositivos#

Quando um usuário cria uma chave de acesso em seu iPhone, mas deseja fazer login em um laptop Windows, ele pode usar a autenticação entre dispositivos (geralmente via código QR e Bluetooth). Esse fluxo funciona, mas é frágil:

• Exige que o Bluetooth esteja ativado em ambos os dispositivos
• Os firewalls corporativos e as políticas de MDM podem interferir, pois há um túnel configurado em segundo plano
• A UX varia drasticamente entre os navegadores
• Os usuários geralmente não entendem o que está acontecendo ou por que estão lendo um código QR

Vimos esses casos extremos em primeira mão em milhares de combinações de dispositivos. Se você está criando chaves de acesso internamente, você precisará testar e lidar com cada uma delas. Se não puder, seus usuários encontrarão erros que sua equipe de suporte não consegue explicar.

4.3 Inconsistências de navegador e sistema operacional#

Mesmo no mesmo dispositivo, navegadores diferentes se comportam de maneira diferente. O Chrome no macOS mostra modais de chaves de acesso diferentes dos do Safari no macOS. O Firefox tem o seu próprio comportamento. Dicas ao cliente e a detecção de user agent tornam-se essenciais para fornecer os fluxos certos para o usuário certo, mas analisá-los corretamente em todas as combinações é um fardo de manutenção que nunca termina.

5. Problema 3: Aplicativos nativos multiplicam a complexidade das chaves de acesso#

O teste e o QA de chaves de acesso já são um desafio para os aplicativos web (abordamos isso em detalhes no Problema 5: Mudanças de plataforma). Mas se o seu produto também possui aplicativos nativos para iOS e Android, a complexidade se multiplica devido às decisões de arquitetura e ao comportamento específico da plataforma que as equipes focadas apenas na web nunca enfrentam.

5.1 Decisões nativas versus WebView#

A primeira decisão é se as chaves de acesso serão implementadas nativamente ou através de um WebView. Cada abordagem tem concessões:

Somente no iOS, você pode escolher entre WKWebView, SFSafariViewController, SFAuthenticationSession e ASWebAuthenticationSession - cada um com diferentes características de suporte a chaves de acesso. No Android, as Chrome Custom Tabs se comportam de forma diferente dos WebViews padrão. Estas são decisões que as equipes focadas apenas na web nunca precisam tomar, e cada escolha cria a sua própria superfície de manutenção.

5.2 Comportamento específico da plataforma em aplicativos nativos#

Além da decisão arquitetônica, o iOS e o Android lidam com chaves de acesso de forma diferente no nível do sistema operacional:

• O iOS integra profundamente as chaves de acesso no gerenciador de credenciais do sistema, com comportamentos específicos de preenchimento automático que podem mudar a cada versão do iOS
• O Android roteia as solicitações de chaves de acesso através da API do Credential Manager, que interage com vários provedores de chaves de acesso simultaneamente
• Os estados de erro, os comportamentos de tempo limite e os prompts de usuário são diferentes entre as plataformas. O mesmo usuário que cancela aparece como NotAllowedError na web, mas como SimpleAuthenticationServices.AuthorizationError no iOS e User cancelled the operation no Credential Manager do Android - consulte os erros do WebAuthn em produção para um mapeamento completo de erros entre plataformas
• Os ciclos de revisão das lojas de aplicativos adicionam atrasos quando você precisa lançar correções urgentes para regressões de chaves de acesso

5.3 Superfície de QA triplicada#

Se você operar um aplicativo da web e aplicativos nativos, não estará apenas duplicando o esforço de controle de qualidade, mas sim triplicando-o. A web, o iOS e o Android comportam-se como ambientes de chaves de acesso separados que precisam de testes de ponta a ponta independentes e de monitoramento. E ao contrário da web, onde você pode implantar uma correção instantaneamente, as correções de aplicativos nativos são limitadas pelos ciclos de revisão das lojas de aplicativos.

6. Problema 4: A adoção é um problema de produto, não um problema de tecnologia#

"Suporte a chaves de acesso" não significa "uso de chaves de acesso". Se você não tiver uma estratégia e uma medição de lançamento, a adoção irá decepcionar e o projeto será rotulado como um fracasso internamente.

6.1 Por que a baixa adoção mata o seu projeto#

Cobrimos isso de forma abrangente em nosso artigo sobre por que as implementações de chaves de acesso falham: se os usuários não migrarem para as chaves de acesso, o projeto já terá falhado. As senhas continuam dominantes, os custos do SMS OTP permanecem elevados, os riscos de phishing persistem e a sua organização não tem retorno sobre um investimento significativo em engenharia.

O argumento de negócios para a adoção das chaves de acesso é forte, mas apenas se a adoção realmente acontecer. Vimos empresas lançarem chaves de acesso com ótimas implementações técnicas, mas que alcançaram menos de 5% de adoção porque ninguém pensou na estratégia de implementação e adoção.

6.2 A adoção exige um trabalho deliberado de produto#

Impulsionar a adoção das chaves de acesso é um desafio de produto que exige:

• Inscrição progressiva: incentivar os usuários a criar chaves de acesso nos momentos certos (por exemplo, após um login bem-sucedido, durante análises de segurança da conta)
• Comunicação clara com o usuário: explicar o que são chaves de acesso e por que elas são melhores, em linguagem que usuários não técnicos entendam
• Avisos com reconhecimento do dispositivo: oferecer a criação de chaves de acesso apenas quando o dispositivo do usuário realmente suportá-la bem, evitando experiências frustrantes em configurações não suportadas
• Infraestrutura de medição: rastrear as taxas de criação de chaves de acesso, as taxas de sucesso do login, as taxas de fallback e as taxas de abandono para identificar e corrigir gargalos

6.3 Como se parece uma "boa" adoção#

Com base em nossa experiência com implantações de chaves de acesso em grande escala, eis o que as empresas devem almejar:

Se os seus números de adoção se parecerem com os da coluna "fraca" após três meses, o projeto está em apuros. Sem as análises para medir isso, você nem mesmo saberá.

7. Problema 5: As mudanças na plataforma quebram as chaves de acesso silenciosamente#

As atualizações no sistema operacional e no navegador alteram os prompts, o comportamento de preenchimento automático e os fluxos de fallback. Se não houver monitoramento contínuo, você terá regressões e tickets de suporte sem nenhum aviso prévio.

Acabamos de publicar uma visão geral abrangente dos erros do WebAuthn que ocorreram em produção.

7.1 Por que as chaves de acesso são afetadas exclusivamente pelas alterações da plataforma#

Diferentemente das senhas (que são apenas cadeias de caracteres validadas por seu servidor), as chaves de acesso dependem de uma profunda integração com o sistema operacional, o navegador e o gerenciador de credenciais. Quando a Apple lança uma nova versão do iOS, os prompts de criação da chave de acesso podem parecer diferentes. Quando o Chrome atualiza a sua lógica de preenchimento automático, o fluxo de login pode falhar. Quando um gerenciador de senhas lança uma nova versão, ele pode começar a interceptar as solicitações de chaves de acesso de maneiras que você não previu.

Um exemplo recente é o bug do iOS 26.2 onde isUserVerifyingPlatformAuthenticatorAvailable() retorna false em todos os navegadores que não sejam o Safari (Chrome, Edge, Firefox), o que exige o uso de uma lógica de detecção com reconhecimento de plataforma por meio de getClientCapabilities() como uma solução alternativa.

7.2 O monitoramento não é opcional#

Para garantir que você tome conhecimento de todos os possíveis bugs e acompanhe a adoção, você precisa configurar a sua pilha de observabilidade de autenticação. Recomendamos que você tenha pelo menos o seguinte em funcionamento:

• Análise de autenticação em tempo real: rastreie as taxas de sucesso e falha por combinação de SO, navegador e provedor de chaves de acesso
• Monitoramento ciente das versões: detecte quando uma nova versão de um SO ou navegador causa um pico de erros ou fallbacks. Diferencie entre erros esperados (usuário aborta, exibidos como NotAllowedError) e erros inesperados (picos de AbortError provenientes de bugs de concorrência ou novos erros de chave de acesso no Credential Manager após uma atualização do Android)
• Alertas: seja notificado antes que os seus usuários comecem a registrar tickets de suporte
• Capacidade de resposta rápida: a capacidade de implementar correções ou desativar rapidamente as chaves de acesso para as combinações de dispositivos afetadas

Esse é o tipo de infraestrutura de análise de autenticação que a maioria das equipes não constrói até que já tenham tido um incidente. Até lá, o dano à confiança do usuário e à credibilidade do projeto interno já foi feito.

7.3 Custo contínuo de manutenção#

O verdadeiro custo da implementação das chaves de acesso não é a construção inicial. É a manutenção contínua:

• Monitorar as alterações de plataforma no iOS, Android, Windows, macOS e em todos os principais navegadores
• Testar as regressões a cada atualização
• Atualizar seu SDK de frontend quando as APIs do navegador mudam
• Manter a compatibilidade com um ecossistema crescente de provedores de chaves de acesso
• Documentar e comunicar as alterações à sua equipe de suporte

8. Quando você (não) deve lançar as chaves de acesso#

Tendo em vista esses problemas do Dia 2, apresentamos uma avaliação honesta de quando você deve e não deve lançar chaves de acesso.

8.1 Não lance chaves de acesso se#

• Você não tiver uma estratégia clara de fallback e recuperação
• Você não tiver testado em todas as combinações de dispositivos que seus usuários realmente usam
• Você tiver aplicativos nativos, mas nenhum plano para testes contínuos específicos da plataforma (QA)
• Você não tiver infraestrutura analítica para medir a adoção
• Você não puder comprometer os recursos de engenharia na manutenção contínua
• Você estiver implementando as chaves de acesso apenas como uma caixa de seleção de conformidade e sem o planejamento adequado

Ir a fundo por razões regulatórias, sem um planejamento adequado, pode aumentar consideravelmente os custos. Um sistema de chaves de acesso mal implementado é pior do que nenhum sistema de chaves de acesso: ele corrói a confiança do usuário, gera custos de suporte e dá às partes interessadas internas motivos para cancelar o projeto.

8.2 Lançar chaves de acesso se#

• Você tiver se planejado para todos os cinco problemas do Dia 2 descritos acima
• Você tiver os recursos de produto, engenharia, segurança e análise para apoiar a implementação em andamento
• Você tiver orçado a manutenção contínua e não apenas a construção inicial
• Você tiver uma estratégia de implementação em fases com metas de adoção bem claras
• Você trabalhar com um parceiro como o Corbado, que lida com a complexidade operacional para você

8.3 A decisão entre construir ou comprar#

Os problemas do Dia 2 descritos neste artigo são exatamente os motivos pelos quais muitas empresas optam por comprar a sua infraestrutura de chaves de acesso, em vez de construí-la. Construir um servidor WebAuthn é a parte fácil. A operação de um sistema de chaves de acesso a nível de produção em milhares de combinações de dispositivos, com recuperação adequada, monitoramento e análises de adoção, é o que separa uma demonstração de uma implantação real.

9. Como a Corbado resolve os problemas do Dia 2 das chaves de acesso#

O Corbado existe especificamente porque os problemas do Dia 2 são difíceis. A nossa plataforma lida com a complexidade operacional para que você não precise construí-la e mantê-la.

9.1 Recuperação e fallback#

O Corbado fornece fluxos de recuperação prontos para uso, com níveis de segurança adaptáveis. Desde estratégias de chaves de acesso sincronizadas até a autenticação entre dispositivos e a verificação automatizada de identidade. A lógica de recuperação é integrada e continuamente atualizada.

9.2 Compatibilidade entre dispositivos#

Os nossos SDKs de frontend são pré-testados em milhares de combinações de SO, navegador e provedores de chaves de acesso. A detecção de dispositivos, o manuseio de interfaces de usuário condicionais e o roteamento de fallback ocorrem automaticamente. Quando uma nova versão do navegador quebra alguma coisa, nós a consertamos em nosso SDK antes que seus usuários percebam.

9.3 Suporte nativo a aplicativos#

O Corbado é compatível tanto com implementações nativas quanto com chaves de acesso do tipo WebView, com SDKs que abstraem as diferenças entre plataformas. Você se concentra na UX do seu aplicativo, enquanto nós cuidamos de toda a infraestrutura da chave de acesso no iOS e Android.

9.4 Análise de adoção#

O nosso painel de análises rastreia todas as métricas importantes: taxas de criação de chaves de acesso, taxas de sucesso no login, taxas de fallback e os detalhamentos a nível de dispositivo. Você obtém insights práticos para promover a adoção e não apenas dados brutos.

9.5 Monitoramento das mudanças na plataforma#

O Corbado monitora continuamente as mudanças nos SO e navegadores que afetam as chaves de acesso. Nossos SDKs são atualizados de forma proativa. O seu ambiente de chaves de acesso permanece estável, mesmo com as mudanças no cenário da plataforma.

10. Conclusão#

As chaves de acesso são o padrão ouro da autenticação. Isto não está em questão. Mas o caminho entre "chaves de acesso suportadas" e "chaves de acesso funcionando de forma confiável e em escala" é pavimentado com os problemas do Dia 2, que a maioria das equipes subestima.

Os cinco problemas que abordamos (recuperação, casos extremos entre dispositivos, complexidade dos aplicativos nativos, adoção e alterações na plataforma) não são raros. São os principais desafios operacionais de qualquer implantação de chaves de acesso em produção. O fato de os ignorarmos não faz com que desapareçam. Significa apenas que os seus usuários os descobrem primeiro.

A minha recomendação honesta: se não tem o conhecimento e os recursos necessários para criar as chaves de acesso de forma correta, não as lance. Invista nas capacidades (produto, engenharia, segurança e análise) ou trabalhe com um parceiro que já tenha resolvido esses problemas. O pior resultado é a implantação de uma chave de acesso incompleta que é revertida, pois ninguém fez um plano para o Dia 2.

Sobre a Corbado

Corbado é a Passkey Intelligence Platform para times de CIAM que rodam autenticação consumer em escala. Mostramos o que logs de IDP e ferramentas genéricas de analytics não enxergam: quais dispositivos, versões de SO, navegadores e gerenciadores de credenciais suportam passkeys, por que os registros não viram logins, onde o fluxo WebAuthn falha e quando uma atualização de SO ou navegador quebra silenciosamente o login — tudo sem substituir Okta, Auth0, Ping, Cognito ou seu IDP interno. Dois produtos: Corbado Observe adiciona observabilidade para passkeys e qualquer outro método de login. Corbado Connect entrega passkeys gerenciados com analytics integrado (junto ao seu IDP). VicRoads roda passkeys para mais de 5M de usuários com Corbado (+80% de ativação de passkey). Fale com um especialista em Passkeys →

Perguntas frequentes#

Quais são os 5 problemas do Dia 2 que fazem com que os projetos de chaves de acesso falhem após o lançamento?#

Os cinco problemas operacionais são fluxos de recuperação e fallback inseguros, casos extremos do ecossistema entre dispositivos, complexidade de aplicativos nativos, baixa adoção pelos usuários e regressões silenciosas de atualizações de sistemas operacionais e navegadores. A maioria das equipes se concentra na integração inicial do WebAuthn e subestima esses desafios pós-lançamento, e é por isso que muitos projetos de chaves de acesso são revertidos ou discretamente abandonados internamente.

Como lidar com a autenticação de chaves de acesso entre dispositivos para usuários corporativos no Windows que se registraram no iPhone?#

Os usuários podem se autenticar por meio de um código QR e fluxo de dispositivos cruzados via Bluetooth, mas isso exige que o Bluetooth esteja ativado em ambos os dispositivos e pode ser bloqueado por políticas de MDM e firewalls corporativos. A experiência do usuário varia significativamente entre os navegadores e, muitas vezes, os usuários não entendem por que estão lendo um código QR, tornando o roteamento de fallback com reconhecimento de dispositivo e a comunicação clara fundamentais para implantações corporativas.

Quais métricas de adoção de chaves de acesso devo definir como meta e acompanhar após o lançamento?#

Uma forte adoção significa uma taxa de criação de chaves de acesso superior a 60% dos usuários elegíveis e uma taxa de login com chave de acesso superior a 40% de todos os logins. Taxas abaixo de 10% de criação e abaixo de 5% de login após três meses sinalizam um lançamento fracassado. Medir isso exige uma infraestrutura dedicada que monitore as taxas de criação, taxas de sucesso de login, taxas de fallback e abandono detalhadas por combinação de dispositivo e sistema operacional.

Devo criar chaves de acesso nativamente em meu aplicativo móvel ou usar um WebView?#

A implementação nativa oferece a melhor UX da categoria, mas requer bases de código separadas para iOS e Android com tratamento de API específico da plataforma e pipelines de controle de qualidade independentes. As abordagens com WebView compartilham a lógica da web, mas introduzem inconsistências no suporte a chaves de acesso, dependendo do tipo de WebView. Somente no iOS, a escolha entre WKWebView, SFSafariViewController e ASWebAuthenticationSession tem características diferentes de suporte a chaves de acesso que devem ser avaliadas antes de se comprometer com uma arquitetura.

Por que a recuperação de contas com chaves de acesso é mais difícil do que parece e qual é a abordagem correta?#

Uma recuperação simplificada, como redefinições baseadas em e-mail, reintroduz canais vulneráveis a phishing, enquanto uma recuperação excessivamente rígida, como o uso obrigatório de chaves de segurança de hardware, gera abandono. A abordagem recomendada ocorre em camadas: chaves de acesso sincronizadas como estratégia principal, autenticação entre dispositivos com código QR como segunda camada, verificação de identidade automatizada com testes de vivacidade como terceira e credenciais verificáveis digitais como quarta. Quais camadas implementar depende do seu modelo de ameaças, base de usuários e requisitos regulatórios.