As passwords estão a perder terreno mais depressa do que a maioria das empresas percebe. A FIDO Alliance estima que existem hoje cerca de 5 mil milhões de passkeys ativas em todo o mundo, um número anunciado no World Passkey Day de 7 de maio de 2026. Ao mesmo tempo, a autenticação de dois fatores tradicional (SMS e aplicações TOTP) continua a proteger a esmagadora maioria das contas online em Portugal, da banca ao Instagram. A pergunta que chega à caixa de entrada de qualquer equipa de segurança em 2026 é simples: vale a pena trocar o 2FA que já funciona por passkeys, ou os dois métodos vão coexistir durante anos? Este artigo compara as duas abordagens com números concretos, tabelas de referência e um guia de migração para quem gere contas pessoais ou sistemas de produção.
O contexto português tem particularidades que valem a pena isolar logo no início. Portugal já usa um sistema nacional de autenticação forte, a Chave Móvel Digital, mas esse sistema continua ancorado em SMS como principal canal de entrega do código, o mesmo elo que a indústria de segurança global identifica como o mais fraco. Ao mesmo tempo, bancos e serviços públicos portugueses enfrentam pressão regulatória crescente da União Europeia para adotar autenticação resistente a phishing, o que torna esta comparação mais do que um exercício técnico: é uma decisão que vai moldar como milhões de portugueses acedem a serviços essenciais nos próximos anos.
O que são passkeys e o que é autenticação de dois fatores
Uma passkey é uma credencial baseada no standard FIDO2/WebAuthn que substitui a password por completo. Em vez de memorizar uma frase secreta, o dispositivo gera um par de chaves criptográficas: a chave privada fica guardada no telemóvel, computador ou chave de segurança física, e a chave pública fica no servidor do serviço. O login acontece com o desbloqueio biométrico do aparelho (Face ID, impressão digital ou PIN do sistema), sem que nenhum segredo viaje pela rede. É por isso que os especialistas chamam às passkeys “resistentes a phishing por design”: não há código para roubar, porque não existe código a transmitir.
A autenticação de dois fatores (2FA), pelo contrário, mantém a password como primeira camada e junta um segundo fator: um código SMS, um código gerado por uma app como Google Authenticator, ou uma notificação push. Funciona bem há mais de uma década e continua a ser o standard em bancos portugueses, na Segurança Social Direta e em serviços como o Finanças.gov.pt. O problema é que a password continua a existir algures, normalmente numa base de dados que pode ser comprometida, e o segundo fator pode ser intercetado com técnicas como SIM swapping ou kits de phishing em tempo real (adversary-in-the-middle).
A confusão entre os dois termos é comum porque as passkeys também costumam ser descritas como uma forma de “MFA” (autenticação multifator), já que combinam algo que o utilizador tem (o dispositivo) com algo que o utilizador é (a biometria) ou sabe (o PIN local). A diferença essencial é que essa combinação acontece localmente, no aparelho, e nunca é enviada pela internet, ao contrário de um código SMS que percorre a rede da operadora.
Passkeys vs autenticação de dois fatores: tabela comparativa
| Critério | Passkeys (FIDO2/WebAuthn) | 2FA com SMS | 2FA com app TOTP |
|---|---|---|---|
| Resistência a phishing | Alta (ligada à origem do site) | Baixa | Média (código ainda pode ser reencaminhado) |
| Resistência a SIM swap | Total (não depende do número) | Nenhuma | Total |
| Tempo médio de login | ≈0,9 segundos | 15-30 segundos (espera pelo SMS) | 10-15 segundos |
| Taxa de sucesso no primeiro login | ≈99,1% | Variável, falha comum por atraso na rede | Alta, mas sujeita a erro de digitação |
| Precisa de password | Não | Sim | Sim |
| Funciona offline | Sim (verificação local) | Não | Sim |
| Custo de implementação | Médio-alto (requer suporte WebAuthn) | Baixo, mas custos de SMS por envio | Baixo |
| Sincronização entre dispositivos | Sim, via iCloud Keychain, Google Password Manager ou gestor de senhas | Não aplicável | Depende da app (alguns sincronizam) |
| Suporte em sites portugueses | Ainda limitado (bancos, Google, Microsoft, Apple) | Quase universal | Amplo |
| Recuperação de conta | Requer segundo dispositivo ou passkey de recuperação | Simples via SMS | Precisa de códigos de backup |
| Adoção empresarial em 2026 | 68% das organizações a testar ou implementar | Ainda dominante como fallback | Padrão em ambientes corporativos |
Os números de login (0,9 segundos e 99,1% de sucesso) vêm de um estudo de 2026 sobre autenticação sem password que analisou fluxos de login em produção. Já os dados de adoção (5 mil milhões de passkeys ativas, 68% das organizações a implementar) são da FIDO Alliance, a organização que define o standard FIDO2/WebAuthn em conjunto com a W3C.
Como funciona o protocolo WebAuthn por baixo do capô
Para perceber porque as passkeys se comportam de forma tão diferente do 2FA tradicional, ajuda olhar para o mecanismo técnico. O WebAuthn, o standard mantido em conjunto pela FIDO Alliance e pela W3C, define três intervenientes no processo: o autenticador (o telemóvel, o computador ou a chave física), o cliente (o browser) e a parte confiável (o servidor do site). Quando um utilizador cria uma passkey, o autenticador gera localmente um par de chaves assimétricas único para aquele site específico. A chave pública é enviada ao servidor e associada à conta, mas a chave privada nunca sai do dispositivo, nem sequer é visível para o próprio sistema operativo em texto simples, porque normalmente fica guardada num enclave de segurança dedicado (o Secure Enclave da Apple ou o Titan M da Google, por exemplo).
No momento do login, o servidor envia um desafio criptográfico aleatório (challenge). O autenticador assina esse desafio com a chave privada, depois de confirmar a identidade do utilizador via biometria ou PIN local, e devolve a assinatura ao servidor, que a verifica com a chave pública já guardada. Este processo tem duas propriedades que o 2FA tradicional simplesmente não consegue replicar: a assinatura é única para cada tentativa de login (não pode ser reutilizada nem reenviada por um atacante), e o navegador só permite a assinatura se o domínio que está a pedir corresponder exatamente ao domínio registado na criação da passkey. É esta segunda propriedade, a vinculação à origem, que elimina o phishing como vetor de ataque viável.
Do ponto de vista de quem desenvolve, isto significa integrar duas chamadas de API no browser: navigator.credentials.create() para o registo e navigator.credentials.get() para a autenticação, ambas parte da Web Authentication API documentada pela Mozilla. No lado do servidor é preciso guardar a chave pública, o identificador da credencial e um contador de assinaturas por utilizador, além de validar a origem e o desafio em cada pedido. Não é trivial, mas também não é mais complexo do que integrar um fornecedor de SMS com fallback e retentativas, que é o que a maioria das equipas já mantém hoje para o 2FA tradicional.
Benchmarks: velocidade e taxa de sucesso em produção
Três fontes diferentes chegam a conclusões parecidas quando o assunto é velocidade de login. O relatório “State of Passwordless Authentication 2026” mediu que as passkeys representam já 15,7% do total de autenticações analisadas, com tempo médio de 0,9 segundos e taxa de sucesso de 99,1%. Para efeitos de comparação, um fluxo típico de SMS OTP demora entre 15 a 30 segundos quando se conta a espera pela rede da operadora, e falha com frequência em zonas de fraca cobertura, algo relevante em regiões do interior de Portugal onde a latência de SMS ainda é um problema real.
O segundo ponto de comparação vem da própria FIDO Alliance: no seu relatório State of Passkeys 2026, divulgado por ocasião do World Passkey Day (7 de maio), a organização apurou que 90% dos consumidores já reconhecem o termo “passkey”, 75% ativou pelo menos uma em alguma conta, e cerca de 49% usa-a regularmente quando está disponível. É um salto grande face aos números de dois anos antes, quando as passkeys ainda eram uma novidade técnica discutida sobretudo entre programadores.
O terceiro dado, também de 2026, aponta para um crescimento de 412% na adoção de passkeys FIDO2/WebAuthn ao longo de 2025, tornando-as o método de autenticação que mais cresceu nesse período. Nenhum destes números mede diretamente o desempenho de sistemas portugueses, mas a tendência é clara: onde a passkey está disponível, o login é mais rápido e falha menos do que o SMS.
Vale notar que velocidade não é segurança. Um código SMS que chega em 5 segundos continua vulnerável a SIM swap, enquanto uma passkey que demora 0,9 segundos está protegida porque a chave privada nunca sai do dispositivo, não porque é rápida. São propriedades diferentes que, por acaso, apontam na mesma direção.
Segurança: porque as passkeys resistem melhor ao phishing
O ataque mais comum contra 2FA tradicional em 2026 não é a força bruta, é o phishing adversary-in-the-middle (AiTM): o utilizador introduz a password e o código TOTP ou SMS num site falso, que os reenvia em tempo real para o site verdadeiro, roubando a sessão autenticada. Kits como o Tycoon2FA, que a shattered.io já noticiou a atacar contas Microsoft 365 em massa, dependem exatamente deste mecanismo. Contra este tipo de ataque, um código de seis dígitos não ajuda: o utilizador entrega-o voluntariamente ao site errado.
As passkeys fecham esta porta porque o protocolo WebAuthn liga cada credencial à origem exata do site (o domínio) no momento da criação. Se um atacante criar um clone do site do banco num domínio diferente, o browser simplesmente não apresenta a passkey como opção de login, porque a origem não corresponde. Não é o utilizador a decidir se o site parece legítimo, é o protocolo a verificar matematicamente a origem antes de sequer mostrar a opção de autenticação. É esta a razão pela qual a OWASP e o NIST, na diretriz SP 800-63B, classificam autenticadores baseados em FIDO2 como resistentes a verificador comprometido e a phishing, uma categoria que nem o SMS nem a maioria dos TOTP alcançam.
Isto não torna as passkeys imunes a tudo. Um dispositivo roubado e desbloqueado (por coação ou biometria falsificada) continua a ser um vetor de ataque, e a recuperação de conta quando se perde o único dispositivo com a passkey ainda é um ponto fraco em muitas implementações. A maioria dos fornecedores resolve isto com sincronização na nuvem (iCloud Keychain, Google Password Manager), o que desloca o risco para a segurança dessa conta na nuvem em vez de o eliminar.
Tabela de preços: quanto custa cada abordagem
Para uma equipa que decide implementar autenticação forte, o custo não é só de licença, é também de suporte, SMS e manutenção. A tabela seguinte resume ordens de grandeza típicas para 2026, com base em preços publicados por fornecedores de autenticação e relatos de custos operacionais de help desk.
| Método | Custo direto | Custo de suporte/help desk | Observações |
|---|---|---|---|
| SMS OTP | €0,01-€0,05 por SMS enviado | Alto (recuperação frequente por número trocado) | Custo escala com o número de utilizadores ativos |
| App TOTP (Google/Microsoft Authenticator) | Grátis | Médio (perda de dispositivo exige reconfiguração) | Sem custo direto, mas exige suporte a instalação |
| Chave de segurança física (YubiKey) | €25-€90 por unidade | Baixo após distribuição inicial | Investimento único por colaborador |
| Passkeys (nativas do sistema operativo) | Grátis para o utilizador final | Baixo (FIDO Alliance reporta menos tickets de “esqueci-me da password”) | Custo de implementação no lado do servidor (WebAuthn) |
| Gestor de senhas com passkeys (1Password, Bitwarden) | €2,99-€7,99/mês por utilizador | Baixo | Inclui sincronização entre plataformas e recuperação gerida |
O ponto que mais pesa na conta final costuma ser invisível: o número de pedidos de recuperação de conta que chegam ao suporte técnico. Cada reposição manual de acesso custa tempo de um técnico, e passwords esquecidas continuam a ser um dos motivos mais comuns de contacto com help desks corporativos. Ao remover a password da equação, as passkeys tendem a reduzir esse volume, ainda que a poupança exata varie muito consoante a organização.
O caso português: Chave Móvel Digital e a transição pendente
Portugal já tem um sistema de autenticação forte a nível de Estado: a Chave Móvel Digital (CMD), gerida pela Agência para a Modernização Administrativa, dá acesso a Finanças, Segurança Social Direta, SNS 24 e a vários serviços bancários e de telecomunicações com uma única credencial. O modelo atual da CMD combina um PIN escolhido na ativação com um código temporário enviado por SMS, ou, em alternativa mais recente, verificação biométrica através da app gov.pt (reconhecimento facial ou impressão digital).
Este desenho é, na prática, 2FA tradicional: password (o PIN) mais um segundo fator (SMS ou biometria via app). Funciona bem e já substituiu grande parte do uso do Cartão de Cidadão físico para autenticação online, mas mantém a dependência do SMS como principal canal de entrega do código, o mesmo elo mais fraco identificado nos benchmarks internacionais. Ainda não existe uma opção de passkey nativa para a CMD, o que significa que, por agora, mesmo os portugueses mais avançados tecnologicamente continuam limitados ao modelo SMS-mais-PIN quando lidam com serviços públicos.
No setor privado a fotografia é mista. A Google, a Microsoft e a Apple já suportam passkeys nas contas pessoais acessíveis a utilizadores portugueses, e alguns bancos a operar em Portugal começaram a testar login sem password em apps móveis. Mas a maioria dos serviços online mais usados no país, incluindo bancos, seguradoras e operadoras, continua a depender de SMS ou de apps TOTP como segundo fator, sem opção de passkey.
Password hashing: o que fica por trás da password que a passkey elimina
Mesmo com a subida das passkeys, a maior parte dos sistemas em produção em 2026 ainda guarda passwords algures, seja como método principal, seja como fallback para contas de recuperação. Por isso, para equipas de engenharia, a escolha do algoritmo de hashing continua relevante. A recomendação atual da OWASP coloca o Argon2id como escolha por omissão para projetos novos, com bcrypt aceitável em sistemas legados e scrypt reservado para ambientes onde o Argon2id não está disponível.
| Algoritmo | Parâmetros recomendados 2026 | Tempo por hash | Memória usada | Estatuto OWASP |
|---|---|---|---|---|
| Argon2id | m=64MB, t=3, p=1 | ≈150-200ms | 64-128 MB | Primeira escolha (greenfield) |
| bcrypt | cost=12-13 | ≈250-500ms | 4 KB fixo | Aceitável em legado |
| scrypt | N=2¹⁵-2¹⁷, r=8, p=1 | ≈200-265ms | 32-128 MB | Segunda escolha |
Na prática, isto significa que a decisão “passkeys vs 2FA” e a decisão “que algoritmo de hash usar” não são mutuamente exclusivas: uma empresa pode migrar utilizadores para passkeys como método principal e, ao mesmo tempo, manter Argon2id a proteger as contas que ainda usam password como alternativa. Para quem quer implementar isto em código, o artigo WebAuthn em Node.js da shattered.io detalha os 12 passos práticos.
5 exemplos reais de adoção de passkeys
- Google: tornou as passkeys a opção de login recomendada por omissão para contas pessoais, com sincronização automática via Google Password Manager entre Android, Chrome e outros dispositivos. Quem já tem conta Google vê hoje a sugestão para criar uma passkey diretamente no ecrã de segurança, à frente da opção de mudar a password.
- Apple: integrou passkeys no iCloud Keychain desde o iOS 16, com sincronização entre iPhone, iPad e Mac protegida por autenticação de dois fatores da própria Apple ID. A Apple foi também um dos membros fundadores da aliança que empurrou o standard FIDO2 para adoção em massa, junto com Google e Microsoft, numa iniciativa conjunta anunciada ainda em 2022.
- Microsoft: passou a permitir login sem password em contas Microsoft através de Windows Hello, apps autenticadoras ou chaves de segurança físicas, reduzindo a dependência de SMS. Em ambiente corporativo, o Microsoft Entra ID (antigo Azure AD) já suporta passkeys como método de autenticação primário para colaboradores, o que explica parte dos 68% de organizações que a FIDO Alliance regista a testar ou implementar o método em 2026.
- Gestores de senhas (1Password, Bitwarden): adicionaram suporte nativo para criar, guardar e sincronizar passkeys entre plataformas, resolvendo o problema de dependência exclusiva do ecossistema Apple ou Google. Esta é, na prática, a opção mais prática para quem usa Windows, Android e macOS ao mesmo tempo e não quer ficar preso a um único fornecedor de sincronização.
- Bancos e fintechs: vários bancos europeus, incluindo operadores presentes em Portugal, começaram testes piloto de login por passkey nas apps móveis em 2025-2026, mantendo SMS como fallback durante a transição. O setor financeiro tende a avançar com mais cautela porque está sujeito a exigências regulatórias específicas sobre autenticação forte de clientes, o que se explora em maior detalhe na secção seguinte.
Enquadramento regulatório: PSD2, NIS2 e o que isso muda para bancos portugueses
Para instituições financeiras a operar em Portugal, a escolha entre passkeys e 2FA tradicional não é só uma questão de conveniência, é também uma questão de conformidade. A diretiva europeia PSD2 exige “autenticação forte de cliente” (Strong Customer Authentication, SCA) para operações de pagamento online, definida como a combinação de pelo menos dois de três elementos: conhecimento (password ou PIN), posse (dispositivo ou cartão) e inerência (biometria). Uma passkey, ao combinar posse do dispositivo com inerência da biometria local, cumpre este requisito de forma nativa, sem precisar de um terceiro elemento separado como um código SMS.
A isto soma-se a diretiva NIS2, já transposta para a legislação portuguesa e que abrange milhares de entidades consideradas essenciais ou importantes, incluindo grande parte do setor financeiro e de telecomunicações. A NIS2 não obriga expressamente ao uso de passkeys, mas exige medidas de gestão de risco de cibersegurança “adequadas ao estado da arte”, uma formulação que abre espaço para reguladores e auditores passarem a questionar porque uma organização continua a depender de SMS quando existe uma alternativa mais resistente a phishing amplamente disponível e sem custo de licenciamento adicional. Para uma equipa de conformidade, isto significa que adotar passkeys deixa de ser apenas uma otimização de produto e passa a ser também um argumento defensável perante auditorias de segurança.
Há ainda a considerar o Regulamento Geral de Proteção de Dados (RGPD), que continua a ser fiscalizado em Portugal pela Comissão Nacional de Proteção de Dados (CNPD). Como as passkeys não exigem o armazenamento de um segredo partilhado (ao contrário de uma password, mesmo em formato de hash, ou de um número de telefone associado a SMS), reduzem a superfície de dados pessoais sensíveis que uma organização precisa de proteger e reportar em caso de violação. Isto não isenta a organização de cumprir o RGPD, mas simplifica o desenho do sistema de autenticação do ponto de vista de minimização de dados, um dos princípios centrais do regulamento.
Guia de migração: de password + 2FA para passkeys
Para equipas de engenharia que decidem avançar, a migração raramente é uma troca imediata. As organizações que fizeram esta transição com sucesso trataram-na como um projeto faseado, medido em meses, não como um interruptor a ligar num único deploy. Costuma seguir estas etapas:
- Auditar o suporte a WebAuthn na base de utilizadores: navegadores modernos (Chrome, Safari, Edge, Firefox) e sistemas operativos recentes já suportam o protocolo, mas versões antigas de Android ou browsers desatualizados podem não suportar.
- Manter o 2FA tradicional como fallback durante a transição, nunca removendo o SMS/TOTP no primeiro dia, isso bloquearia utilizadores sem dispositivos compatíveis.
- Implementar o registo de passkey como opção adicional no ecrã de segurança da conta, não como obrigação, para reduzir fricção inicial.
- Testar o fluxo de recuperação de conta antes de lançar: o que acontece se o utilizador perder o único dispositivo com a passkey? A resposta normal é permitir reautenticação via 2FA tradicional como rede de segurança.
- Medir a adoção com métricas simples: percentagem de logins via passkey vs password, taxa de erro em cada método, tempo médio de autenticação.
- Comunicar o benefício ao utilizador em linguagem simples (“mais rápido e mais seguro”), não em jargão técnico sobre criptografia assimétrica.
- Definir uma data para desativar SMS como opção principal (não eliminá-lo, mas deixar de o pré-selecionar), assim que a adoção de passkeys ultrapassar um limiar interno definido pela equipa de segurança.
- Rever os logs de autenticação regularmente para identificar contas que ainda dependem exclusivamente de SMS e priorizar essas para campanhas de migração dirigidas.
Casos de uso: qual método faz sentido para cada cenário
Não existe uma resposta única para “qual método é melhor”, porque o risco e o contexto de cada conta são diferentes. Uma conta de streaming de vídeo não justifica o mesmo investimento em segurança que um acesso administrativo a infraestrutura de produção. A lista seguinte organiza a escolha por cenário, priorizando sempre o método mais resistente a phishing que a plataforma em causa realmente suporta.
- Contas pessoais de email e redes sociais: passkey sempre que disponível, é o método mais rápido e com menor fricção para o utilizador comum.
- Acesso bancário e financeiro: passkey quando o banco suportar, ou app TOTP em vez de SMS, porque reduz o risco de SIM swap.
- Contas corporativas com acesso a dados sensíveis: chave de segurança física (FIDO2 hardware) para administradores e equipas de TI, complementada por passkeys para o resto da força de trabalho.
- Serviços públicos portugueses (Finanças, Segurança Social): Chave Móvel Digital com verificação biométrica via app gov.pt em vez de SMS, sempre que essa opção estiver ativada.
- Contas de recuperação e email secundário: manter 2FA tradicional como rede de segurança, mesmo depois de migrar a conta principal para passkey, para evitar bloqueio total em caso de perda de dispositivo.
- Aplicações internas legadas sem suporte a WebAuthn: app TOTP continua a ser a opção mais prática até haver orçamento para modernizar a autenticação.
Prós e contras de cada abordagem
Passkeys
Prós: resistentes a phishing por design, login mais rápido, elimina o risco de password fraca ou reutilizada, funciona offline em muitos casos, reduz tickets de suporte relacionados com passwords esquecidas.
Contras: suporte ainda incompleto entre serviços (sobretudo em Portugal), recuperação de conta mais complexa quando se perde o único dispositivo, exige atualização de sistemas legados no lado do servidor, pode confundir utilizadores menos familiarizados com tecnologia.
2FA tradicional (SMS/TOTP)
Prós: suporte quase universal, fácil de entender para qualquer utilizador, não depende de hardware específico, funciona em qualquer telemóvel com rede móvel (no caso do SMS).
Contras: vulnerável a phishing em tempo real e a SIM swap (sobretudo o SMS), ainda depende de uma password como primeira camada, login mais lento, custo operacional de envio de SMS em escala.
Chaves de segurança físicas (hardware FIDO2, como YubiKey)
Prós: mesma resistência a phishing das passkeys por software, não depende da bateria ou da rede do telemóvel, ideal para contas de administrador ou acesso privilegiado onde perder o dispositivo não deve significar perder a conta.
Contras: custo por unidade (entre €25 e €90), risco de perda física sem cópia de segurança automática, exige comprar e distribuir hardware a cada colaborador, o que só compensa em contas de risco elevado. Para uma comparação mais detalhada entre chaves físicas e apps autenticadoras, veja o artigo YubiKey vs Apps Autenticadores da shattered.io.
Erros comuns ao migrar para passkeys
A experiência de organizações que já passaram por esta migração em 2025 e 2026 aponta para um conjunto de erros que se repetem. O primeiro é remover o 2FA tradicional cedo demais, antes de a adoção de passkeys atingir uma massa crítica de utilizadores, o que gera um pico imediato de pedidos de suporte de quem fica bloqueado por não ter um dispositivo compatível. O segundo é não testar o fluxo de recuperação de conta em condições realistas: é fácil verificar que a criação de uma passkey funciona, mas poucas equipas simulam a situação de um utilizador que perdeu o único telemóvel com a passkey sincronizada e não tem acesso a nenhum backup.
O terceiro erro é subestimar a formação necessária para equipas de suporte ao cliente. Um agente de apoio habituado a “reenviar o código SMS” como resposta padrão precisa de aprender um vocabulário e um fluxo de resolução de problemas completamente diferentes quando o pedido é sobre uma passkey que não sincronizou entre dispositivos. O quarto erro, mais técnico, é implementar o WebAuthn sem suportar corretamente os chamados “autenticadores de plataforma cruzada” (cross-platform authenticators), o que impede utilizadores de usar uma chave de segurança física como YubiKey em vez de depender só da biometria do telemóvel, uma opção importante para utilizadores com necessidades de acessibilidade ou que preferem não vincular a autenticação a um único smartphone.
Por fim, há o erro de comunicação: apresentar as passkeys como “mais uma opção de segurança” em vez de explicar claramente o benefício direto para o utilizador (login mais rápido, sem necessidade de decorar nada). Os dados da FIDO Alliance mostram que a adoção acelera significativamente quando o utilizador percebe o ganho imediato de conveniência, não apenas o argumento abstrato de segurança.
O veredito: qual escolher em 2026
Os números não deixam muita margem para dúvida sobre a direção: com 5 mil milhões de passkeys ativas, 68% das organizações a implementar ou testar o método para colaboradores, e taxas de sucesso de login acima de 99%, as passkeys já não são uma experiência técnica de nicho. São o standard recomendado sempre que a plataforma o suporta. Isto não significa que o 2FA tradicional deva desaparecer amanhã, continua a ser indispensável como rede de segurança, como fallback de recuperação, e como único método disponível em muitos serviços portugueses, incluindo partes da própria Chave Móvel Digital do Estado.
A recomendação prática para 2026 é em camadas: usar passkeys sempre que disponíveis, substituir SMS por apps TOTP onde as passkeys ainda não chegaram, e reservar chaves de segurança físicas para contas de alto risco (administradores de sistema, acessos financeiros críticos). Quem gere sistemas próprios deve tratar a adoção de WebAuthn como prioridade de roadmap, não como opção secundária, porque a tendência de adoção sugere que os utilizadores vão continuar a preferir o método mais rápido e com menos fricção, à medida que mais serviços o oferecerem.
Para o leitor português em particular, o conselho mais prático é começar já a ativar passkeys nos serviços que as suportam (Google, Microsoft, Apple, e o gestor de senhas escolhido), sem esperar por uma eventual atualização da Chave Móvel Digital. Enquanto o Estado não avança com uma opção FIDO2 nativa, cada conta pessoal que passa de SMS para passkey reduz a superfície de ataque disponível a kits de phishing como o Tycoon2FA, que continuam a visar contas Microsoft 365 e serviços de email em Portugal. A mudança não precisa de ser feita de um dia para o outro: começar pelas contas mais críticas (email principal, gestor de senhas, banco) já reduz a maior parte do risco prático.
Perguntas frequentes
As passkeys substituem completamente o 2FA?
Não de imediato. As passkeys substituem a combinação password mais segundo fator por uma única credencial criptográfica, mas a maioria dos serviços mantém o 2FA tradicional como método de recuperação caso o dispositivo com a passkey se perca.
O que acontece se eu perder o telemóvel com as minhas passkeys?
Se as passkeys estiverem sincronizadas na nuvem (iCloud Keychain, Google Password Manager ou um gestor de senhas como Bitwarden), consegue recuperá-las noutro dispositivo autenticado na mesma conta. Se não estiverem sincronizadas, a recuperação depende do fallback definido pelo serviço, normalmente 2FA tradicional ou verificação de identidade manual.
As passkeys são mais seguras do que uma app autenticadora TOTP?
Sim, em relação a phishing em tempo real. Uma app TOTP gera um código que ainda pode ser reencaminhado por um atacante num ataque adversary-in-the-middle. Uma passkey está ligada criptograficamente à origem do site, pelo que não funciona num domínio falso, mesmo que o utilizador seja enganado a tentar iniciar sessão nele.
A Chave Móvel Digital portuguesa usa passkeys?
Não. A CMD atual combina um PIN com um código SMS ou verificação biométrica através da app gov.pt, um modelo de 2FA tradicional. Não existe, até à data deste artigo, uma opção de passkey FIDO2 nativa integrada na Chave Móvel Digital.
Quanto custa implementar passkeys numa aplicação?
Para o utilizador final, é grátis. Para quem desenvolve o serviço, o custo está sobretudo no trabalho de engenharia para implementar o protocolo WebAuthn no lado do servidor e nas interfaces de registo e login, não em licenciamento.
Devo desativar já o SMS como segundo fator?
Não de forma abrupta. A recomendação é deixar de o apresentar como opção pré-selecionada assim que existir alternativa melhor (passkey ou TOTP), mas mantê-lo disponível como fallback de recuperação até a adoção da alternativa estar consolidada entre os utilizadores.
Que algoritmo de hashing devo usar para as passwords que ainda restam no sistema?
A OWASP recomenda Argon2id como primeira escolha para sistemas novos, com parâmetros à volta de 64 MB de memória e três iterações. O bcrypt com custo 12 ou 13 continua aceitável em sistemas legados que não conseguem migrar de imediato.
As passkeys funcionam entre diferentes ecossistemas (Apple, Google, Microsoft)?
Sim, através do standard WebAuthn, mas a sincronização automática entre ecossistemas nem sempre é direta. Um gestor de senhas independente, como o Bitwarden ou o 1Password, resolve esse problema ao guardar e sincronizar as passkeys fora do ecossistema de um único fabricante.
As empresas em Portugal são obrigadas a oferecer passkeys por lei?
Não diretamente. Nem a PSD2 nem a NIS2 mencionam passkeys pelo nome, mas ambas exigem autenticação forte ou medidas de segurança “adequadas ao estado da arte”. Como as passkeys cumprem esses requisitos de forma mais robusta do que muitas implementações de SMS, tendem a tornar-se a escolha mais defensável perante auditorias, mesmo sem uma obrigação legal explícita a nomeá-las.
