セキュリティー研究者のスコット・ヘルム氏は、ウェブサイトが利用者を承認済みのデバイスやソフトウェアに限定するためにパスキーを使えるので、パスキーは避けるべきだという、広く拡散された主張に反論した。反論の中心は、WebAuthnのアテステーション（認証器の証明）の仕組みと、一般利用者向けの同期型パスキーと管理された環境で使うハードウェア認証器との違いにある。

ヘルム氏によると、一般利用者の多くがiCloudキーチェーン、Google パスワード マネージャー、1Password、Bitwardenなどのサービスに保存するパスキーは、通常、ウェブサイトにアテステーションステートメントを提供しない。サイト側がアテステーションを要求しても、同期型パスキーは通常、それを返さない。そのため、証明付きの認証情報にこだわる一般向けサービスは、既存のパスキー利用者の大半を締め出すおそれがあり、商業面でも運用面でもそのような方針の採用は難しい。

アテステーションが利用できる場合、AAGUIDを通じて認証器のメーカーとモデルが識別され、メーカーによる証明書チェーンが含まれることもあるとヘルム氏は説明する。同氏の説明では、利用者のオペレーティングシステム、ブラウザーの拡張機能、ファームウェアのバージョン、あるいはスマートフォンが改造されているかどうかは明らかにならない。その範囲は、アテステーションによってソフトウェア環境全体が承認済みであると証明されるという主張よりも狭い。

ハードウェアセキュリティーキーの存在は、この批判をさらに複雑にする。YubiKeyのようなデバイスにはメーカーのアテステーション証明書が搭載されていることがあり、組織が承認済みのハードウェアの使用を義務付けられるよう、エンタープライズアテステーションも用意されている。ハードウェアキーは引き続き強力なセキュリティー手段だが、アテステーションを回避する方法として推奨するのは、ヘルム氏が反論した警告における技術的な関係を逆に捉えていることになる。

パスキーを支持する、より大きなセキュリティー上の根拠はフィッシングへの耐性だ。パスキーは、その作成先のインターネットドメインにひも付いている。見た目を似せたサイトが、利用者を言いくるめて繰り返し使える秘密情報を入力させるという手は通じない。時間ベースのワンタイムパスワードはパスワード単独より安全性を高めるが、利用者がフィッシング用のプロキシーにパスワードとコードの両方を入力してしまう可能性は残る。そのプロキシーは両方を正規のサービスに中継し、生成されたセッションを奪うことができる。

ただし、これですべての運用方針上の懸念が解決するわけではない。組織は管理された環境でハードウェアの要件を課すことができ、認証情報の移行のしやすさは提供事業者によって異なる。将来、一般向けサービスでアテステーションを拡大しようとする動きがあれば、精査する必要がある。利用者には、信頼できるパスキーマネージャーを選び、その復旧やエクスポートの選択肢を理解することも求められる。

ヘルム氏の結論は、こうした懸念が現時点でパスキーを放棄する理由にはならないというものだ。同氏が説明する実装では、主流の同期型パスキーが利用者のデバイスに関する詳細な報告をウェブサイトに渡すことはない。一方、ドメインへのひも付けは、アカウント窃取の一般的な経路を取り除く。したがって、ここで選ぶべきなのは、欠点のない仕組みか危険な仕組みかではなく、現在存在する認証上のリスクのどれを引き受けるかということになる。