111サイトの調査で判明したFIDO2パスキー実装の共通点とばらつき
公開日
セキュリティ
パスワードに代わる強固なフィッシング耐性を持つ認証手段として、FIDO2に準拠したパスキー（Passkeys）の導入が広まっています。一方で、サービスごとに操作手順や画面設計が異なると、ユーザーに認知的負荷を与え、普及の妨げになる懸念が指摘されています。
本記事では、ブリガムヤング大学のBernhardt Ramat氏らの研究チームが発表した論文「Passkeys in the Wild: A Systematic Study of FIDO2 User Experience Consistency Across Websites」をもとに、実際のWebサイトにおけるパスキー実装の一貫性を検証した結果を紹介します。
111サイトを対象に28要因でパスキーのユーザー体験を評価した調査手法
研究チームは、1Passwordが提供する「passkeys.directory」に登録されていたサービスから、登録費用や過度な個人情報入力を要するサイトなどを除外した111サイトを分析対象としました。2025年2月から2026年2月にかけて、Windows 11のGoogle Chrome（バージョン134）およびAndroid 13端末を用いて、パスキーの探索、登録、利用、削除の全動線を検証しました。
評価にあたっては、FIDO Allianceが策定したデザインガイドラインから演繹的に抽出した23要因と、実際のユーザー動線の観察から帰納的に導出した5要因を合わせた計28要因の比較フレームワークを構築しました。各サイトの対応状況を数値化し、サイト間の実装パターンの違いを分析しています。
パスキー実装の類似度から見えた3つのWebサイト群
各Webサイトの実装がどの程度似通っているかを確かめるため、研究チームは28項目の対応状況をもとに、サイト同士を1対1で総当たり比較しました。2つのサイトの実装パターンが完全に一致していれば「0」、最もかけ離れていれば「1」となる距離指標（ユークリッド距離）を算出したところ、ペア間の平均値は0.57（中央値0.56、最頻値0.55）でした。
この数値は、Web上のパスキー実装が完全に統一されているわけではないものの、全くバラバラでもなく、ある程度共通した仕様を踏襲しながら半分程度の実装で差異が生じている状態を表しています。
図1：ペア間ユークリッド距離のヒストグラム
階層型クラスタリングにより、調査対象の111サイトは特徴的な3つのグループに分類されました。
- 標準的な実装サイト（Cluster 1：89サイト、80%）
パスキーの告知、設定画面からの登録、複数端末での利用や管理、削除機能など、幅広い要因を高水準で実装しているグループです。平均実装率は67%でした。 - 限定的な実装サイト（Cluster 2：20サイト、18%）
基本的なパスキー利用には対応しているものの、ハードウェアセキュリティキー（HSK）やクロスデバイスでの新規登録を制限しているグループです。平均実装率は54%でした。 - 実験的な実装サイト（Cluster 3：2サイト、2%）
TailscaleやLGTMなど、アカウント作成時のパスキー登録には対応しているものの、設定画面での追加や削除機能が提供されていないなど、限定的な検証段階にあるグループです。平均実装率は34%でした。
表1：クラスタ別の主な比較要因の実装率
| 要因名（要因ID） | 全体 | Cluster 1（標準） | Cluster 2（限定） | Cluster 3（実験） |
|---|---|---|---|---|
| フォールバック認証の提供（F19） | 98% | 99% | 100% | 50% |
| 設定画面での登録（F08） | 97% | 100% | 95% | 0% |
| パスキー削除機能（F24） | 97% | 99% | 100% | 0% |
| パスキー管理画面の提供（F23） | 93% | 97% | 85% | 0% |
| サインインUIの提供（F17） | 84% | 88% | 65% | 100% |
| ハードウェアキー登録（F09） | 82% | 100% | 0% | 100% |
| クロスデバイス登録（F10） | 82% | 100% | 0% | 100% |
| オートフィル機能（F18） | 42% | 40% | 60% | 0% |
| パスワードより優先表示（F02） | 36% | 36% | 35% | 50% |
| 登録時の本人確認（F13） | 30% | 31% | 25% | 50% |
| 削除時の本人確認（F26） | 30% | 33% | 15% | 0% |
| アカウント回復時の登録（F11） | 3% | 3% | 6% | 0% |
基本機能の収束とサポート機能における大きなばらつき
分析結果から、アカウント設定画面での登録（97%）や削除（97%）、複数パスキーの登録（95%）といった基本的な機能は多くのサイトで共通して提供されていることが確認されました。
一方で、ユーザーの利便性や認知に関わるサポート機能には顕著なばらつきが存在します。
認証UIにおける優先順位とオートフィルの低さ
ログイン画面や設定画面でパスキーをパスワードより上位に配置し、優先的な選択肢として提示していたサイトは全体の36%にとどまりました。また、ブラウザやパスワードマネージャーの候補をフォーム上に直接表示するオートフィル機能（WebAuthnのConditional UI）に対応していたサイトは42%でした。
登録と利用におけるサポート端末の不一致
限定的な実装サイト（Cluster 2）に属するサイトでは、登録時にハードウェアセキュリティキー（F09: 0%）や他端末を用いたクロスデバイス登録（F10: 0%）の導線が用意されていません。それにもかかわらず、ログイン時にはこれらのデバイスによる認証を受け付けている事例（F20: 80%、F21: 80%）が確認されました。
研究チームはこの原因について、認証ライブラリが生成するオプション（PublicKeyCredentialRequestOptions の allowCredentials）に依存している一方で、登録側のUIがそれに追従していない可能性を指摘しています。
Webとモバイルアプリ間の連携不足
モバイルアプリを提供しているサイトのうち、Webサイト側で作成したパスキーを用いてアプリにログインできなかった割合が21%ありました（F22の非対応）。端末をまたいだシームレスな移行を期待するユーザーにとって、認証の失敗や混乱を招く要因となり得ます。
パスキーの追加・削除時におけるライフサイクルセキュリティの課題
本研究が強調している重大なセキュリティ上の発見の1つが、パスキーのライフサイクル管理における認証の不備です。
調査対象の約70%のサイトにおいて、パスキーを追加する際（F13: 30%のみ対応）や削除する際（F26: 30%のみ対応）に、パスワードの再入力やワンタイムコードによる再認証（ステップアップ認証）が要求されませんでした。
アクティブなセッションが残っている端末に攻撃者が一時的にアクセスできた場合、再認証なしで攻撃者自身のパスキーを登録され、継続的なバックドアを作成される恐れがあります。また、既存のパスキーを削除されて正規ユーザーが締め出される危険性も存在します。
さらに、アカウント側でパスキーを削除した際に、ユーザー側の認証器（パスワードマネージャーやOSのクレデンシャルストア）からも不要になった鍵を削除するよう案内していたサイトは23%（F25）にとどまりました。
開発チームが考慮すべき設計のポイント
論文の分析結果は、Webサービスの認証設計やセキュリティ基準を検討するうえで参考になります。
- 登録導線と認証オプションの整合性を確認する
バックエンドやライブラリの既定設定によって意図しない認証オプションが露出していないか、登録可能なデバイスとログイン可能なデバイスの整合性を検証することが重要です。 - 重要なライフサイクル操作に再認証を設ける
セッションハイジャックや端末の置き去りによる不正登録・不正削除を防ぐため、パスキーの追加や削除時には適切なステップアップ認証を検討する必要があります。 - 入力負荷を減らすUIの採用
オートフィル（autocomplete="webauthn"）の導入は、パスワード入力に慣れたユーザーに対して追加の手間を感じさせずにパスキーを提示する手段として有効です。
まとめ
ブリガムヤング大学の研究チームによる111サイトの調査により、FIDO2パスキーの基本的な登録・認証機能は多くのサイトで共通のパターンに収束しつつあることが示されました。
しかし、オートフィルやモバイルアプリとの連携、設定画面での優先表示といった利便性に関わる機能や、追加・削除時の再認証といったセキュリティ機能の実装には依然として大きな隔たりがあります。
認証システムを設計・運用するチームは、基本的なWebAuthn APIの呼び出しにとどまらず、アカウントのライフサイクル全体を見据えたUI設計とセキュリティ対策を整えていくことが求められます。
Webサービスや社内のセキュリティにお困りですか？ 弊社のサービス は、開発チームが抱える課題を解決し、生産性と幸福度を向上させるためのさまざまなソリューションを提供しています。ぜひお気軽にご相談ください！
参考資料：