A Recomendação WebAuthn Level 3 do W3C, publicada em 25 de agosto de 2026, e a revisão final do guia de identidade digital do NIST de julho de 2025 formam o arcabouço normativo que equipes de IAM precisam dominar antes de escalar passkeys em produção. Quem é afetado: toda organização que ainda depende de senha combinada com OTP por SMS ou aplicativo, método que o phishing moderno contorna com retransmissão em tempo real. A ação prioritária é dupla: garantir que o provedor de identidade ofereça pelo menos uma opção de autenticação resistente a phishing no AAL2 e tratar os flags da resposta WebAuthn como dados de política de acesso, não como detalhe de implementação.
Padrão consolidado em 2026
A especificação do W3C define a API que cria e usa credenciais de chave pública fortes, com atestação e escopo por origem. O Level 3 sucedeu o Level 2, de 2021, e o próprio documento registra que não houve mudanças substantivas desde o snapshot de Candidate Recommendation de 26 de maio de 2026. Para quem desenha roadmap, a mensagem é de estabilidade: decisões de arquitetura tomadas agora não ficam obsoletas por uma revisão iminente do padrão.
Três elementos do protocolo importam na operação diária. O escopo por origem impede que a credencial registrada para o seu domínio funcione em um site falso. A atestação permite ao provedor identificar fabricante e modelo do autenticador no momento do registro. E os flags de transação informam o que aconteceu no dispositivo no instante da assinatura — é sobre eles que a política de acesso deve ser escrita.
A privacidade entre partes confiáveis também está no desenho: o padrão mantém que uma parte confiável não consegue detectar propriedades, ou mesmo a existência, de credenciais vinculadas a outra parte. Em termos práticos, o fingerprinting cruzado por credencial fica fora do modelo — um argumento útil em análise de privacidade interna.
AAL2 exige resistência a phishing
A revisão do SP 800-63B é explícita: o texto normativo do NIST determina que verificadores ofereçam ao menos uma opção resistente a phishing no AAL2 e que agências federais americanas exijam esse tipo de autenticação de funcionários, contratados e parceiros. Como verificador é o papel que a sua organização exerce ao oferecer login, a exigência recai sobre o seu IdP, não sobre o aparelho do usuário.
A mesma publicação esclarece por que OTP e códigos fora de banda não contam: a entrada manual do código não vincula a saída do autenticador à sessão específica, o que permite a um impostor retransmitir o valor e autenticar em nome da vítima. Passkeys e chaves de hardware assinam o desafio do domínio legítimo e vinculam origem e sessão — a diferença técnica que separa MFA eficaz de MFA decorativo. Kits como o EvilTokens, que driblava MFA e foi desmantelado, mostram o custo de ignorar essa distinção na prática.
O texto reconhece dois métodos de resistência a phishing: vinculação de canal e vinculação de nome do verificador. O WebAuthn implementa a segunda, ao escolher o segredo com base no domínio autenticado do verificador. A distinção importa em ambientes com TLS terminado em intermediários, nos quais a vinculação de canal exige desenho adicional.
Sincronizado ou ligado ao dispositivo
O apêndice sobre autenticadores sincronizáveis do NIST responde à dúvida mais comum do desenho de identidade. Chave sincronizada via sync fabric pode atender o AAL2 com condições: o acesso do usuário às chaves no ambiente de sincronização deve ser protegido por MFA equivalente ao AAL2, chaves exportadas precisam ficar armazenadas de forma cifrada e as operações de chave privada ocorrem sempre no dispositivo local. No AAL3 o cenário muda de figura: como o nível superior exige chave privada não exportável, autenticadores sincronizáveis ficam proibidos nesse patamar.
Isso desenha uma política de duas camadas. Passkeys sincronizados servem à população geral, com recuperação amigável entre aparelhos. Chaves ligadas ao hardware — cartões PIV ou credenciais FIDO device-bound — tornam-se obrigatórias para administradores, operação de ambientes críticos e contas com privilégio elevado.
Dois flags da resposta WebAuthn sustentam essa segmentação. O Backup Eligible indica se a credencial pode ser sincronizada; o Backup State indica se ela já foi sincronizada de fato. O NIST autoriza verificadores a usar esses flags para restringir autenticadores, mas recomenda não condicionar a aceitação ao Backup State em aplicações de uso público, pelo impacto na experiência das pessoas.
Recuperação sem virar porta
O apêndice lista as ameaças do modelo sincronizado e as mitigações esperadas: processos de recuperação consistentes com a própria publicação, vínculo de múltiplos autenticadores no AAL2 para dar suporte à recuperação, exigência de autenticação forte para adicionar novos autenticadores e notificação ao usuário diante de qualquer atividade de recuperação. O documento também recomenda restringir capacidades de recuperação por gestão de dispositivo ou conta gerenciada em cenários corporativos.
Tradução operacional: a recuperação é o novo ponto de contato preferido de atacantes. Política mínima exige segunda credencial pré-registrada antes de qualquer reset e alerta imediato ao titular quando um novo autenticador entra na conta.
Checklist de implantação
| Ação | Prioridade | Fundamento |
|---|---|---|
| Oferecer passkey como opção padrão de login | P1 | NIST exige opção resistente a phishing no AAL2 |
| Registrar flags UV, BE e BS em cada evento | P1 | Base de política de acesso e de investigação |
| Exigir credencial device-bound para administradores | P1 | AAL3 exige chave privada não exportável |
| Proteger a conta do sync fabric com MFA forte | P2 | Reduz o risco de clonagem de chaves |
| Pré-registrar segunda credencial para recuperação | P2 | Evita que o reset vire porta lateral |
| Ativar atestação em autenticadores gerenciados | P2 | Identifica origem e capacidades do dispositivo |
Sinais para detectar abuso
Adotar passkey não reduz a necessidade de monitoramento; muda o que precisa ser observado. Eventos que merecem alerta imediato: registro de nova credencial seguido da exclusão das anteriores, padrão clássico de tomada de conta; mudança do Backup State de falso para verdadeiro em conta administrativa, indicando sincronização para aparelho fora do perímetro; e sequências repetidas de autenticação sem verificação local, com o flag User Verified falso, compensadas por fator adicional.
O registro mínimo por evento inclui identificador da credencial, estado dos flags, origem da requisição e resultado da validação de atestação. Indicadores de risco previstos na própria norma — geografia inesperada ou endereço de provedor de nuvem — devem alimentar políticas de autenticação adicional sem alterar o nível de garantia da transação. Para definir retenção e cobertura, siga o padrão mínimo de visibilidade do ENISA já detalhado aqui no portal. Lembre que a revogação de credencial WebAuthn é por provedor: não existe lista de revogação central como no PKI tradicional, então o offboarding precisa desativar a credencial no IdP no mesmo dia do desligamento.
Prioridades da semana
P1: inventariar fluxos de login que ainda aceitam somente OTP e definir data de corte. P1: ativar o registro de flags no pipeline de logs e criar os dois primeiros alertas. P2: pilotar credenciais device-bound com o grupo de administradores. P2: revisar o fluxo de recuperação contra as mitigações do apêndice e ajustar o que faltar. Duas semanas de trabalho entregam uma base normativa sólida — com dois padrões maduros atrás.