銀行が陥るパスキー導入の失敗トップ10

1. はじめに#

銀行セクターは、従来のパスワードやOTPからフィッシング耐性のあるパスキーへの移行という重要な岐路に立たされています。CISOやプロダクトオーナーにとって、これはフィッシングや増大するインフラコストによって推進される不可欠な課題です。しかし、銀行における導入には特有のハードルがあります。厳しい規制（例：PSD2/SCA）、レガシーインフラ、極端なデバイスの多様性などです。

このガイドは、世界中の導入事例から得られた洞察を統合したものです。パスキー導入の成功は、ユーザーの普及という「ラストマイル」をいかに攻略するかにかかっています。インフラ重視の導入はしばしば普及率1%未満で停滞しますが、プロダクト主導のアプローチであればすぐに50%以上を達成できます。

戦略的要件：

• 登録プロセスが境界線： アカウント乗っ取り（ATO）に対する主な防御策は、作成の瞬間を安全に保つことです。
• 可視性は必須： クライアント側のテレメトリがない「ブラインドロールアウト」は、原因不明のサポート急増につながります。
• コンテキストが重要： 非互換のハードウェアでの「致命的なユーザーロックアウト」を防ぐには、インテリジェントなフォールバックロジックが不可欠です。

2. 銀行におけるパスキーが異なる理由#

銀行には「素早く動いて破壊する」ような余裕はありません。不正に対するゼロトレランスと厳格な監督の下で業務を行っています。このような環境でパスキーを導入すると、他の業界にはない特有の摩擦点が生じます。

2.1 「ブラックボックス」問題#

パスワードの世界では、サーバーログがすべてを教えてくれました。ログインが失敗した理由（文字の間違い、認証情報の期限切れなど）を正確に把握できました。パスキーの場合、認証はユーザーのデバイス上で行われます。顔スキャンが失敗したり、ユーザーがプロンプトをキャンセルしたり、Bluetoothのハンドシェイクが途切れたりした場合、サーバーには一般的なエラーしか表示されません。

銀行の現実： 不正対策およびリスク管理チームは、突然認証の試みに関する「視界」を失うことになります。クライアント側で目的に合わせて構築された新しいテレメトリがなければ、ロールアウト中に目隠し飛行をしているようなもので、障害の急増が技術的なバグなのか攻撃なのかを区別できません。

2.2 「所持」コンプライアンスの頭痛の種#

規制当局（PSD2/SCA）は、知っていること/自身であること、持っていること（所持）の2つの異なる要素を要求しています。

銀行の現実： クラウドに同期されたパスキー（つまりiCloud KeychainやGoogle Password Manager）は、この境界線を曖昧にします。キーがiPad、MacBook、iPhoneに同期されている場合、ユーザーは特定のデバイスを物理的に「所持」しているのでしょうか？法務およびコンプライアンスチームは、従来のハードウェアの意味での「所持」を確認できないため、ロールアウトをブロックすることが多く、UXを損なう複雑な「デバイスバインディング」の回避策を構築せざるを得なくなります。

2.3 極端なデバイスとユーザーの断片化#

SaaS企業は古いブラウザのサポートを打ち切ることができますが、銀行はそうはいきません。顧客は、デジタルネイティブな18歳から、何年もアップデートされていない低価格のAndroidデバイスを使用している80歳まで多岐にわたります。

銀行の現実： Androidのエコシステムは地雷原です。Samsungのデバイスは多くの場合、Androidでのスムーズなパスキー作成をブロックする「Samsung Pass」がデフォルトになっています。企業の顧客は、クロスデバイス（QRコード）ログインに必要なWebSocket接続をブロックする可能性のあるファイアウォールの背後で作業しています。QA用のiPhoneで機能する「標準的な」実装は、実際の何千人もの顧客にとっては失敗に終わり、即座にサポートキューのオーバーフローにつながります。

2.4 アカウント永久ロックアウトのリスク#

Spotifyのユーザーがアカウントを失った場合、それは面倒なことですが、銀行の顧客がアクセスを失った場合、食料品を買うことができなくなります。

銀行の現実： パスキーはエコシステム（Apple/Google）に依存しています。ユーザーが自分のApple IDからロックアウトされた場合、パスキーも失われます。ID確認のような堅牢な回復パスを構築せずにパスワードを削除した場合、顧客を自分のアカウントから永久にロックアウトするリスクがあります。このシナリオへの懸念が、銀行のロールアウトにおける意思決定を麻痺させています。

3. パスキー導入における10の最大の失敗#

以下は、パスキーを導入する際に銀行が犯す、最も一般的な10の失敗の概要です。

1. 「CIAM/IdPがパスキーをサポートしていること」をゴールとして扱う - 大規模なCIAMパスキー導入で特にありがちな罠
2. パスキーの断片化（誤ったrpID戦略）
3. 「ブラインドロールアウト」（クライアント側テレメトリなし）
4. デバイスとネットワークの現実を無視する
5. アカウント設定にパスキーを隠す
6. アカウントの存在を漏らす（列挙）
7. 保護されていない登録（ATOベクトル）
8. 共有デバイスとPINのリスクを無視する
9. コンプライアンスの決定をスキップする（1FA対2FA）
10. 回復と永久ロックアウトを軽視する

3.1 失敗1：「CIAM/IdPがパスキーをサポートしていること」をゴールとして扱う#

失敗： チームがIDプロバイダー（IdP）をFIDO2をサポートするようにアップグレードし、機能フラグを有効にしてプロジェクトが完了したと考えます。パスキーをフロントエンドの製品ジャーニーではなく、バックエンドのコモディティとして扱います。

影響： ユーザーが機能を発見できなかったり理解できなかったりするため、普及率は1%未満で停滞します。ログインの大部分が従来の方法にとどまるため、銀行はSMSコストの削減や不正防止のROIを全く得られません。しかし、FIDOのデータは、パスキーによってコンバージョンが30パーセントポイント向上することを示しており、導入がなければこのROIは実現されないままです。

対策：

• ロールアウトは単なるITアップグレードではなく、製品プログラムとしてリソースを配分します。コンプライアンス、セキュリティ、製品チームのステークホルダーを早期に関与させることが不可欠です。
• IdPの前に「導入レイヤー」を構築し、ユーザー教育、登録プロンプト、エラー処理を管理します。これらのフローの設計に関するガイダンスについては、当社の製品設計および戦略ガイドを参照してください。
• 導入のKPI（例：「6ヶ月でログインの50%をパスキー経由にする」）を設定し、登録を促す通知のA/Bテストを実施します。

3.2 失敗2：パスキーの断片化（誤ったrpID戦略）#

失敗： 異なる事業部門（例：リテール、ウェルス、法人）が、統合されたアンカーなしに別々のサブドメイン（例：retail.bank.com、wealth.bank.com）でパスキーを展開します。

影響： パスキーはフィッシングを防ぐためにオリジンにバインドされます。リテール向けに作成されたパスキーはウェルス向けには機能しないため、ユーザーは同じ銀行に対して複数の認証情報を登録せざるを得なくなります。これによりUXが分断され、「フィッシング耐性」の約束が薄まります。

次の図は、銀行が通常直面する様々なRelying Party ID（rpID）の可能性を示しています。

対策：

• 単一の主要なRelying Party ID（例：bankgroup.com）を早期に定義します。
• 一元化されたリダイレクト（OIDC/SAML）を使用して、すべてのアプリがこの単一のアンカードメインに対して認証されるようにします。
• レガシードメインをすぐに統合できない場合は、Related Originsの利用を検討してください。

3.3 失敗3：「ブラインドロールアウト」（クライアント側テレメトリなし）#

失敗： クライアント側のWebAuthnイベントに対する詳細な可視性を持たずにローンチします。チームはサーバー側のログ（HTTP 200/400）に依存していますが、それではデバイス上で何が起こっているのか（ユーザーによるキャンセル、生体認証の失敗、OSエラーなど）を把握できません。

影響： 診断不可能な障害の急増。「処理が中断されました」（日本のロールアウトで見られる）のようなエラーをユーザーが報告しても、銀行はそれがSamsungのファームウェアのバグなのか、ユーザーエラーなのか、ネットワークのブロックなのかを区別できず、サポートの過負荷につながります。

プロダクショングレードのパスキー導入では、少なくとも以下のクライアント側テレメトリイベントを追跡する必要があります。

認証ファネルイベント：

エラー分類シグナル：

デバイスとオーセンティケーターのコンテキスト（イベントごとにキャプチャ）：

• OS + バージョン（例：iOS 18.2、Android 15）
• ブラウザ + バージョン
• ハードウェアブランド / モデル
• クレデンシャルマネージャー（iCloud Keychain、Google Password Manager、Samsung Pass、1Passwordなど）
• トランスポート方法（internal、hybrid、hybrid + internal）
• 完了までの時間 / エラーまでの時間

パスキー分析と認証分析に関する完全なガイドについては、専用の記事を参照してください。

対策：

• クライアントを計測する：セレモニーのすべてのステップ（プロンプト -> ユーザーアクション -> ブラウザエラーコード）を追跡します。
• コホートごとにロールアウトする：テクノロジーに詳しい社内ユーザーから始め、次に特定のOSバージョン（例：iOS 18+）へと進め、デバイスモデルごとにエラー率を監視します。

3.4 失敗4：デバイスとネットワークの現実を無視する#

失敗： 最新のiPhone/Pixelでの「ハッピーパス」向けに設計する一方で、エンタープライズのWindowsフリート、企業のプロキシ、多様なAndroid OEM（Sony、Sharp、Samsung）といった断片化された現実を無視します。

影響： 企業のプロキシは、「ハイブリッド」（QRコード）フローに必要なWebSocketトラフィックをブロックすることが多く、職場でのユーザーの利用を妨げます。Androidの断片化により、競合するクレデンシャルマネージャー（Samsung Passなど）が原因で、非Pixelデバイスでは「Conditional Create」のような機能が失敗します。

対策：

• 該当地域の市場シェアに重み付けしたデバイステストマトリックスを構築します（詳細なマトリックスについては、エンタープライズ向けパスキーテストガイドを参照してください）。
• 明示的なフォールバックを実装する：特定のOEMデバイスまたはネットワーク環境が失敗することがわかっている場合、ユーザーのフラストレーションを避けるためにパスキープロンプトを動的に抑制します。
• プロンプトを表示する前に、Passkey Intelligenceを使用してデバイスの機能を検出します。

3.5 失敗5：アカウント設定にパスキーを隠す#

失敗： メインのログインフローでユーザーが混乱することを恐れて、「設定 > セキュリティ > MFA」の奥深くに登録オプションを埋め込みます。

影響： 「1%の罠」。データは、ユーザーが自発的にセキュリティ設定を変更することはめったにないことを裏付けています。普及率はごくわずかのままで、銀行はログインの99%で引き続きSMS OTPのコストを支払い続けることになります。

対策：

• コンテキストに沿ったプロモーション： 信頼性が高いMFAチェックが成功した直後のログインフローの途中で、パスキーの作成をユーザーに促します。
• 段階的な緊急性： 12〜18か月のタイムラインで、「オプション」の通知から「推奨」、「必須」へと移行します。

3.6 失敗6：アカウントの存在を漏らす（列挙）#

失敗： ユーザーが存在する場合はすぐにパスキーを求め、存在しない場合はパスワードを求める「Identifier-First（識別子優先）」ログインフローを使用します。

影響： この動作により、攻撃者は何千ものメールアドレスに対してスクリプトによるチェックを実行し、有効な銀行顧客のリストを構築すること（アカウント列挙）が可能になり、厳格なプライバシー規制（FFIEC/Nacha）に違反します。

対策：

• Conditional UI： ブラウザの自動入力機能を使用して、アカウントの存在を明かすことなく、ユーザー名フィールド内でパスキーを提案します。
• 統合フロー： Identifier-Firstが必要な場合は、厳密なタイミングの均等化と一般的なエラー処理を実装して、バックエンドの状態を隠蔽します。

3.7 失敗7：保護されていない登録（ATOベクトル）#

失敗： 脆弱なログイン（パスワードのみなど）の後、または信頼できないデバイスでパスキーの作成を許可します。

影響： フィッシングでパスワードを入手した攻撃者が、被害者のアカウントに自分のパスキーを登録し、正規のユーザーを永久にロックアウトする可能性があります。

対策：

• 登録のためのステップアップ認証： パスキーの登録を許可する前に、新しいアウトオブバンド検証（SMS、プッシュ、自撮り）を要求します。
• デバイスの信頼： デバイスのフィンガープリントと行動シグナルを使用して、不審なデバイスや共有度の高いデバイス（インターネットカフェなど）での作成をブロックします。

3.8 失敗8：共有デバイスとPINのリスクを無視する#

失敗： 共有デバイス（配偶者、子供）や脆弱なデバイスPIN（「1234」）を考慮せずに、パスキーログインを身元の決定的な証明として扱います。

影響： 親のiPadのPINを知っている子供が取引を承認する可能性があります。プライバシーを保護するWebAuthnは、顔スキャンとPINのどちらが使用されたかを銀行には明かしません。

対策：

• 共有デバイスの検出： テレメトリを使用して、複数のユーザープロファイルがあるデバイスやアカウントの切り替えが頻繁に行われるデバイスを特定し、そこでのパスキーの使用を制限します。
• リスクベース認証： パスキーログインが有効であったとしても、デバイス環境がリスクを示している場合は、高額の取引に対してステップアップチャレンジをトリガーします。

3.9 失敗9：コンプライアンスの決定をスキップする（1FA対2FA）#

失敗： キーがクラウドにコピーされるため、同期されたパスキーが「所持＋知識/生体情報」（2FA）の要件を満たしていると法務/コンプライアンスチームがみなさないことに、後になって気づきます。

影響： 直前になってプロジェクトがブロックされたり、パスワードレスなエクスペリエンスを低下させるUXの摩擦（PayPalのような「デバイスバインディング」ステップの追加など）を強いられたりします。

核心となるのは、パスキーを1要素としてカウントするか2要素としてカウントするかという問題です。

現在の市場データ： 2025年時点で、同期型パスキーが約80%に対し、デバイスバウンド型パスキーは約20%です。オーセンティケーターの中では、約85%がiCloud KeychainまたはGoogle Password Managerを使用し、約10%がWindows Helloを、約5%がサードパーティのパスワードマネージャーを使用しています。Windowsが同期型パスキーをサポートすれば、このシェアは同期型パスキーへとさらにシフトするでしょう。

パスキーを1FAと分類する場合 - フォールバック要素の追加：

パスキーを単一の要素として扱う場合は、必要に応じて追加の要素を使用するポリシーを実装します。ネイティブアプリはサインイン状態が長く続き、ローカルの生体認証を使用できるため（追加の要素が必要なのは最初のネイティブアプリログインのみ）、これは主にWebアプリに関連します。

• 新しいデバイス / ログイン環境： パスキーログイン後、ユーザーの身元とデバイスの信頼を確認するために、1回限りのセカンダリ要素を要求します。この後、デバイスを信頼済みとしてマークできます（例：Cookieやフィンガープリントを使用）。オプションには、SMS OTP、自撮りによる生体検知、クレジットカードの数字、またはアプリのプッシュなどがあります。例：PayPalとRevolutはこのアプローチを使用しています。
• 既知の信頼されたデバイス： 追加の摩擦なしに直接パスキーログインを許可します。ユーザーは過去にデバイスの所持を証明しているため、シームレスなUXを維持できます。

このアプローチは、新しいシナリオの2FA要件を満たしつつ、日常的な使用におけるパスワードレスのエクスペリエンス（通常のデバイスを使用しているユーザーは何も変わらず、素早いパスキーログインのみ）を維持します。これは、毎回ユーザーに負担をかけることなく厳格なセキュリティ標準を満たす、ユーザーフレンドリーな妥協案です。

対策：

• 早期に決定する： 実装を開始する前にコンプライアンスチームを巻き込み、パスキーとの要素構成を決定します。これにより、最終的にパスキーのみに移行できるのか、それともPSD2コンプライアンスのために常にパスキーと別の要素を組み合わせる必要があるのかがわかります。
• 同期型パスキーをAAL2で検証しているNIST SP 800-63Bのガイダンスを参照してください。

3.10 失敗10：回復と永久ロックアウトを軽視する#

失敗： デバイスエコシステムを失ったユーザー（Apple IDのロックアウトなど）のための堅牢で自動化された回復戦略なしに、パスワードのフォールバックを削除します。

影響： ユーザーが自分の資金へのアクセスを完全に失う永久ロックアウトが発生します。これにより、高コストでストレスの多いサポートコールが発生し、回復のフォールバックが脆弱な場合（メールリセットなど）、セキュリティのバックドアが作成されます。

対策：

• スマートフォールバック： 行き止まりにならない代替手段が存在することを確認します（ハードウェアセキュリティキーなど）。
• 自動化された身元確認： コールセンターの介入なしにユーザーが安全に再登録できるように、eKYC（IDスキャン＋生体検知）によるセルフサービス回復を実装します。
• デジタルクレデンシャル： 最も安全でUXに優れた回復パスとして、検証可能なクレデンシャル（mDLなど）の準備を行います。

4. Corbadoの8ステップパスキーバンキングフレームワーク（PSD2準拠）#

上記の地雷原をナビゲートするには、構造化されたフレームワークが必要です。以下の8ステップの青写真は、PSD2に準拠した銀行の展開と大規模な回復力のために設計されています。すべての実装フェーズの包括的な概要については、エンタープライズ向けパスキー統合ガイドを参照してください。

5. Corbadoがどのようにお役に立てるか#

上記の失敗のほぼすべては、同じ根本原因を持っています。銀行は、パスキーのフローが顧客のデバイスで実際に何を行っているかを確認できず、フローが壊れるデバイスに対してフローをオフにするスイッチを持っていません。Corbado Connectは、既存のIdPの前にその両方を追加します。Ping、Okta、ForgeRockは引き続き認証情報とセッションを所有し、クライアント側の動作は測定して制御できるものになります。

5.1 クライアント側テレメトリによる失敗の防止#

失敗3のブラインドロールアウトと失敗4のデバイスの断片化は、可視性の問題です。認証のオブザーバビリティレイヤーであるCorbado Observeは、ブラウザとネイティブアプリでのすべてのセレモニーを記録し、デバイスブランド、モデル、OSバージョン、ブラウザごとにグループ化します。そのDevice Healthビューは、ハードエラー、戻ってこないセレモニー、および不明な未完了を区別して保持するため、壊れたファームウェアビルドやプロンプトを飲み込むWebViewは、チケットキューに表示されるずっと前にデバイスコホートとして表示されます。

See how Corbado Connect ships this →

さらに3つのObserveビューは、上記の失敗に直接対応しています。

• Passkey Errors は、失敗したセレモニーを具体的なWebAuthnの理由に関連付けます。これは、失敗3で求めているクライアント側のテレメトリです。
• Client Capabilities は、プラットフォームオーセンティケーターの可用性、conditionalGet、conditionalCreate、ハイブリッドトランスポート、relatedOrigins、およびシグナルメソッドの6つのWebAuthnサポートシグナルを、時間経過に伴うログインセッションの割合としてグラフ化します。各グラフは、オペレーティングシステム、タッチポイント、アプリケーションによってフィルタリングできるため、失敗2でのrpIDとチャネルの決定は、ベンダーの資料のサポートマトリックスではなく、測定されたサポートに基づきます。
• Inventory は、クレデンシャルベースを同期型パスキー、デバイスバウンド型パスキー、セキュリティキーに分割し、各AAGUIDの背後にあるモデルを特定します。セキュリティキーについてはFIDO Metadata Serviceから、iCloud Keychain、Google Password Manager、サードパーティマネージャーについてはプラットフォームオーセンティケーターカタログから取得します。これは、失敗9での1FA対2FAの議論に必要な証拠です。

5.2 ポリシーベースのロールアウト制御#

一斉のパスキー展開ではなく、Corbado ConnectのGradual Rolloutルールセットは、リクエストごとに、パスキーの作成、パスキーによるログイン、パスキーの管理を提供するかどうかを決定します。ルールは、プラットフォームとバージョン、ブラウザ、デバイスブランドとモデル、クライアントタイプ（Web、アプリ、ネイティブ、WebView）、conditional createが利用可能かどうか、IP範囲で一致し、各ルールはトラフィックのサンプリングされたシェアを許可、ブロック、または許可できます。ルールセットは公開前に過去のトラフィックに対してシミュレーションでき、識別子のホワイトリストによって最初に社内テスター向けにフローが開かれ、キルスイッチによって1ステップでフローを元に戻すことができます。これが、日本の金融機関が遭遇した「致命的なロックアウト」シナリオを、全員のロールアウトを凍結することなく展開から排除する方法です。

See how Corbado Connect ships this →

上記の失敗を読めば、「パスキーのサポート」はIdPでの少量のWebAuthn作業であり、多大な継続的な普及作業であることがわかるでしょう。ほとんどの銀行が苦戦しているのは、既存のIDプロバイダー（Ping、Okta、ForgeRock）がバックエンドを完璧に処理する一方で、「ラストマイル」（デバイスの断片化、UXの通知、クライアント側テレメトリ）のためのツールを提供していないからです。Corbado Connectはそのギャップを埋め、スタックをそのまま残します。

• 導入エンジン： 構築済みのログイン、追加、パスキーリストコンポーネントが、Passkey Intelligenceのルールとともに、通知のタイミング、抑制、A/B分割を処理します。これが、最大10倍のパスキー普及率をもたらす理由です。
• デバイスインテリジェンス： Passkey IntelligenceとGradual Rolloutは、リクエストごとにデバイスブランド、モデル、OSバージョン、ブラウザ、クライアントタイプを評価するため、パスキーの実装が壊れているモデルにはプロンプトの提示が停止されます。
• スマートフォールバック： デバイスの準備ができていない場合、フローは行き止まりになるのではなく、既存のメソッドにユーザーをルーティングします。これにより、コールセンターで失敗10が発生するのを防ぎます。
• フォレンジックテレメトリ： Observeは、1人のユーザーのログインジャーニーをステップごとに再構築するため、サポートはログインがユーザーによるキャンセル、タイムアウト、プラットフォームエラーのいずれで終了したかを知ることができます。

6. 結論#

パスキーへの移行は、単なる認証情報のアップグレードを超えて、ID保証の完全な再考へと向かう、銀行のセキュリティにおける根本的な変化を表しています。技術的な実装は最初のステップですが、成功は最終的にユーザーの普及と運用の回復力によって定義されます。

これら10の落とし穴（特に登録のセキュリティ、デバイスの可視性、回復ロジックに関するもの）を予測することで、銀行は「パイロットの停滞」を乗り越え、次の10年のデジタルファイナンスの基準となる、安全で摩擦のない顧客体験を提供することができます。

Corbadoについて

Corbadoは、大規模なconsumer認証を運用するCIAMチームのためのPasskey Intelligence Platformです。IDPのログや一般的なanalyticsツールでは見えないものを可視化します。どのデバイス、OSバージョン、ブラウザ、credential managerがpasskeyに対応しているか、なぜ登録がログインにつながらないのか、WebAuthnフローのどこで失敗するか、OSやブラウザのアップデートがいつ静かにログインを壊すか、 Okta、Auth0、Ping、Cognito、あるいは自社IDPを置き換えることなく、すべてを把握できます。2つのプロダクト：Corbado Observeは passkeyとその他あらゆるログイン方式のobservabilityを提供します。Corbado Connectは analytics内蔵のmanaged passkeyを追加します（既存のIDPと併用）。VicRoadsはCorbadoで500万人超のユーザーにpasskeyを提供しています（passkey有効化率+80%）。 Passkeyエキスパートに相談する →

よくある質問#

銀行アプリでのパスキー普及率が1%未満で停滞するのを防ぐにはどうすればよいですか？#

パスキーがログインフローの途中で提示されず、アカウント設定の奥深くに埋もれていると、普及は停滞します。銀行は、MFAチェックが成功した直後にパスキーの作成をユーザーに促し、「6ヶ月以内にパスキーによるログインを50%にする」といった明確なKPIを設定し、登録を促す通知のA/Bテストを実施する必要があります。銀行の導入調査で引用されているFIDOのデータによると、普及を積極的に推進した場合、パスキーによってコンバージョンが30パーセントポイント向上する可能性があります。

retail.bank.comやwealth.bank.comのように複数のサブドメインを持つ銀行は、パスキーにどのようなrpID設定を使用すべきですか？#

銀行は、実装を開始する前に、トップレベルドメイン（例えば「bankgroup.com」）に関連付けられた単一のRelying Party ID（rpID）を定義する必要があります。パスキーはフィッシングを防ぐためにオリジンにバインドされるように設計されているため、サブドメインが分かれていると、ユーザーは事業部門ごとに別々の認証情報を登録せざるを得ず、エクスペリエンスが分断されます。レガシードメインをすぐに統合できない場合は、Related Originsを使用することで、再登録を強制することなくこのギャップを埋めることができます。

認証情報が漏洩した後、攻撃者が被害者のアカウントに自分のパスキーを登録するのを防ぐにはどうすればよいですか？#

パスキーの登録は、新しいパスキーを登録する前にSMS、プッシュ通知、自撮りによる生体検知などの新しいアウトオブバンド検証を要求するステップアップ認証チェックの背後にゲートを設ける必要があります。このゲートがないと、フィッシングで被害者のパスワードを入手した攻撃者が自身のパスキーを登録し、正規のユーザーを永久にロックアウトする可能性があります。さらに、デバイスのフィンガープリントや行動シグナルを利用して、不審なデバイスや共有デバイスでのパスキー作成をブロックする必要があります。

銀行のパスキー導入時に、障害を診断するためにクライアント側でどのようなテレメトリイベントをキャプチャすべきですか？#

サーバー側のHTTPログでは、ユーザーによるキャンセル、生体認証のタイムアウト、Androidのファームウェアバグといったデバイスレベルの障害を把握できないため、専用のクライアント側での計測が不可欠です。少なくとも、銀行はOSバージョン、ブラウザ、ハードウェアモデル、クレデンシャルマネージャー別にセグメント化されたNotAllowedError、AbortError、UnknownErrorなどのエラーコードとともに、完全な認証ファネルを追跡する必要があります。このデータにより、チームはサポートチケットに頼ることなく、Samsungのファームウェアの問題とネットワークのブロック、あるいはユーザーのエラーを区別することができます。