---
url: 'https://www.corbado.com/ja/blog/psd2-passkeys'
title: 'PSD2とパスキー：フィッシング耐性を備えたPSD2準拠のMFA'
description: 'パスキーは、PSD2およびSCA要件に準拠した、フィッシング耐性のあるMFAの最良の形式なのでしょうか？このブログ記事では、そのすべての疑問にお答えします。'
lang: 'ja'
author: 'Vincent Delitz'
date: '2025-07-15T13:17:59.620Z'
lastModified: '2026-09-16T06:02:47.517Z'
keywords: 'PSD2, PSD2準拠, パスキー, SCA, 強力な顧客認証, フィッシング耐性'
category: 'Passkeys Strategy'
---
# PSD2とパスキー：フィッシング耐性を備えたPSD2準拠のMFA
## 1. はじめに
デジタル[バンキング](https://www.corbado.com/passkeys-for-banking)において、セキュリティとユーザーエクスペリエンスはもはや相反するものではありません。パスキーは、[PSD2](https://www.corbado.com/blog/psd2-passkeys)および[SCA](https://www.corbado.com/ja/blog/visa-passkey)要件に準拠したフィッシング耐性のある[MFA](https://www.corbado.com/ja/blog/medibank-data-breach)を導入することで、この2つの要素を融合させます。パスキーは、[金融サービス](https://www.corbado.com/passkeys-for-banking)全体で実装できる、最も安全で最もユーザーフレンドリーな認証形式です。この飛躍的な進歩は、銀行業界が欧州の銀行セクターのセキュリティと競争力を強化するために設計された規制フレームワークである\*\*決済サービス指令改訂版（[PSD2](https://www.corbado.com/blog/psd2-passkeys)）\*\*の導入に取り組んでいる重要な時期に訪れました。
このような状況において、**パスキー**は単なるコンプライアンスソリューションとしてだけでなく、**UXを損なうことなくPSD2の厳格な要件を満たす**ことを約束する、優れたイノベーションの形として登場します。このブログ記事では、[PSD2](https://www.corbado.com/blog/psd2-passkeys)の微妙な違いと、その\*\*強力な顧客認証（[SCA](https://www.corbado.com/ja/blog/visa-passkey)）\*\*の義務付けについて分析します。これにより、パスキーが銀行におけるフィッシング耐性[MFA](https://www.corbado.com/ja/blog/medibank-data-breach)の未来を代表するものであることが明らかになります。
## 2. PSD2とは？
PSD2は、欧州の決済サービスと銀行業界に革命をもたらすために欧州連合によって導入された法律です。その主な**目的は、競争を促進し、消費者保護を強化し、デジタル決済分野でのイノベーションを育成する**ことです。顧客の同意を得た上で、**承認された第三者**への顧客の金融情報への**オープンアクセス**を義務付けることで、PSD2はより統合され、効率的で、ユーザーフレンドリーな金融エコシステムへの道を開きます。しかし、大きな力には大きな責任が伴います。PSD2は、特に**認証プロトコル**という観点から**セキュリティに焦点を当てる**ことで、この問題に取り組んでいます。
> PSD2は、競争、セキュリティ、イノベーションを促進することで、EUの決済を変革することを目指す規制です。
## 3. SCAとは？
PSD2のセキュリティ対策の中心にあるのが、強力な顧客認証（[SCA](https://www.corbado.com/ja/blog/visa-passkey)）の要件です。これは、**不正行為を大幅に削減し、電子決済のセキュリティを強化する**ために設計されたプロトコルです。SCAは、電子決済は**シームレスであるだけでなく、様々な脅威に耐えられるほど安全**でなければならないという原則に基づいています。この認証フレームワークは、PSD2の管轄内で事業を行う決済サービスプロバイダー、銀行、電子決済ゲートウェイにとって**必須**です。
> SCAは、欧州の銀行セクターにおける認証基準です。
### 3.1 SCAの要件
PSD2に基づくSCAの実装は、いくつかの重要な要件によって定義されています。
#### 多要素認証（MFA）
認証には、以下のカテゴリから少なくとも2つの要素を含める必要があります。
- \*\*知識：\*\*パスワードやPINなど、ユーザーだけが知っているもの。
- \*\*所有：\*\*モバイルデバイス、スマートカード、ハードウェアトークンなど、ユーザーだけが所有しているもの。
- \*\*生体情報：\*\*指紋、顔認証、声紋など、ユーザー固有のもの。
#### 動的リンク
各取引について、取引固有の詳細（金額や受取人の口座番号など）を動的にリンクする一意の認証コードを生成する必要があります。
#### 定期的再認証
ユーザーは、オンラインバンキングサービスへのアクセスを維持するために、通常90日ごとに再認証する必要があります。ただし、この要件はセキュリティと利便性のバランスを最適化するために改訂されています。
#### 取引固有の認証
SCAはすべての電子取引に適用され、認証が金額と受取人に固有であることを保証し、すべての取引に一意の署名を作成する必要があります。
#### リスクベースの分析
決済サービスプロバイダーは、リスクベースのアプローチを使用してSCAを適用する必要があります。これにより、リスクの低い取引はSCAから免除され、セキュリティを損なうことなく決済プロセスを合理化できます（ここですでにパスキーとの関連性が見られますね？）。
#### 監査可能性
認証プロセス全体が追跡可能かつ監査可能でなければならず、SCA要件への準拠を証明するための記録を維持する必要があります。
SCAを導入することで、PSD2は銀行セクターにおける取引セキュリティの基準を大幅に引き上げました。以下では、多要素認証（[MFA](https://www.corbado.com/ja/blog/medibank-data-breach)）に関わるさまざまな要素に焦点を当てます。これらの要素は、取引固有の認証要件にも影響を与えます（詳細は後述）。
### 3.2 銀行認証の進化
以下では、銀行セクターにおける認証のさまざまな進化段階を紹介します。
#### 3.2.1 PINとTAN（1990年代以降）
銀行業界における認証の道のりは、\*\*個人識別番号（PIN）**と**取引認証番号（TAN）\*\*の使用から始まりました。顧客はTANのリストを受け取り、各TANを取引確認のために一度だけ使用しました。この方法は当時画期的でしたが、TANリストが盗まれたり悪用されたりするリスクなどの欠点がありました。
#### 3.2.2 電子TANとモバイルTAN（2000年代以降）
技術の進歩に伴い、銀行は**電子TAN（eTAN）**と**モバイルTAN（mTAN）**を導入しました。これらはTANを生成し、SMS経由で顧客のモバイルデバイスに送信するものでした。この方法はTANをデバイスにリンクさせることでセキュリティを向上させましたが、**SMS傍受のリスク**や、これらのメッセージを待って管理しなければならないという**不便さ**など、新たな脆弱性ももたらしました。パスキーが導入されるまで、SMS
OTPはUXの観点から銀行で利用できる最も快適な[2FA](https://www.corbado.com/blog/psd2-passkeys/are-passkeys-two-factor-authentication)オプションと見なされていました。
#### 3.2.3 スマートカードとトークンデバイス（2000年代以降）
セキュリティをさらに強化するため、銀行は認証用の一意のコードを生成する**スマートカード**や**トークンデバイス**を採用しました。これらのハードウェアベースのソリューションは、より高いレベルのセキュリティを提供しましたが、顧客にとっては**追加のデバイスを持ち運ぶ必要があり、複雑さと不便さ**も増しました。
#### 3.2.4 生体認証とモバイルバンキングアプリ（2010年代以降）
銀行認証の最新の進化には、[**生体認証**](https://www.corbado.com/blog/passkeys-biometric-authentication)（指紋または顔認証）や、セキュリティ機能が組み込まれた**モバイルバンキングアプリ**が含まれます。これらの方法は、ユーザー固有の生体情報とスマートフォンの普及を活用することで、セキュリティと利便性のバランスを取ることを目的としていました。しかし、これらはまた、顧客が利用する銀行ごとにアプリをダウンロードして設定するプロセスを経る必要があります。
| 認証方法 | 種類 | 説明 |
| ------------------------------- | ------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| パスワード/PIN | ユーザーが知っているもの | 簡単に実装でき、広く理解されている伝統的な秘密の知識。 |
| SMS OTP（ワンタイムパスワード） | ユーザーが持っているもの | ユーザーの電話に送信される一時的なパスコードで、所有要素を表します。 |
| ハードウェアトークン | ユーザーが持っているもの | ユーザーのためにワンタイムパスコードを生成する物理的なデバイス。銀行によるネイティブのiOS/Androidアプリが必要です。 |
| モバイルアプリOTP | ユーザーが持っているもの | 銀行または認証アプリ内で生成されるパスコードで、多くの場合デバイスバインディングで保護されています。銀行によるネイティブのiOS/Androidアプリが必要です。 |
| 生体認証 | ユーザー自身であるもの | 通常、銀行アプリ内のショートカットとして、ローカルな生体認証ロック（例：Face ID）として指紋、顔認証、虹彩スキャンを使用します。銀行によるネイティブのiOS/Androidアプリが必要です。 |
| プッシュ通知 | ユーザーが持っているもの | モバイルアプリの通知を通じて取引やログイン試行を承認します。銀行によるネイティブのiOS/Androidアプリが必要です。 |
### 3.3 現在の認証の課題と顧客の苦労
これらの進歩にもかかわらず、顧客は依然として現在の銀行認証方法に大きな不便と不満を感じており、詐欺師の標的になるリスクにさらされています。
- \*\*複雑さと不便さ：\*\*複数の認証ステップを重ねることは、セキュリティを向上させる一方で、ユーザーにとっては面倒なプロセスになることがよくあります。この複雑さは単なる些細な不便ではなく、顧客がデジタルバンキングサービスの利用をためらう原因となり、デジタルトランスフォーメーションの目的そのものを損なう可能性があります。
- \*\*デバイスとプラットフォームへの依存：\*\*モバイル認証や生体認証への移行は、ユーザーをデバイスに密接に結びつけます。この依存関係は、盗難の場合に脆弱なリンクを生み出します。また、技術的な障害によって銀行サービスが利用できなくなり、顧客が立ち往生することもあります。
- \*\*フィッシングの脆弱性：\*\*進歩にもかかわらず、認証要素のフィッシング可能性は、SCAでは対処されていない脆弱性として残っています。PIN、パスワード、SMS
OTP、メールOTPなどの従来の要素は、巧妙なフィッシング詐欺によって侵害される可能性があり、顧客のデータと資金を危険にさらします。
今日に至るまで、特に伝統的な銀行は、フィッシングの重大なリスクについて顧客に警告し続けています。
> 最も可能性の高い攻撃ベクトルは、認証情報やデバイスの盗難ではなく、顧客が自ら詐欺師に両方または最初の認証要素を渡してしまうことです。
次のセクションでは、実際の例を用いてこれがどのように機能するかを説明します。
## 4. フィッシングは銀行業界最大のセキュリティ問題
フィッシング攻撃は、人間の心理（ソーシャルエンジニアリング）と技術的な脆弱性を悪用して、機密性の高い金融情報への不正アクセスを得るため、長年にわたり銀行セクターのセキュリティにとって重大な脅威となってきました。銀行が認証を進化させるにつれて、詐欺師も適応し、セキュリティ対策を回避するための巧妙な手口を考案してきました。特にこれらの一般的に使用される認証方法の文脈でフィッシングがどのように機能するかを理解することは、**パスキーのようなフィッシング不可能な認証ソリューションの緊急性**を認識するために不可欠です。
### 4.1 フィッシング攻撃の背後にある理論
フィッシングの核心は、銀行からの正当な通信を装って、個人をだましてログイン認証情報や金融情報などの機密情報を開示させることです。これは通常、以下のステップで達成されます。
1. \*\*開始：\*\*詐欺師は、信頼できるように見えるロゴや言葉遣いを完備した、銀行の公式な通信を模倣したメッセージ（多くはメールやSMS経由）を送信します。これらのメッセージは通常、問題を解決したり口座閉鎖を防いだりするために即時の行動が必要であると主張し、切迫感を生み出します。
2. \*\*欺瞞：\*\*メッセージには、銀行の公式オンラインバンキングポータルに酷似した不正なウェブサイトへのリンクが含まれています。欺瞞に気づかない被害者は、銀行の正当なウェブサイトにアクセスしていると信じ込まされます。
3. \*\*捕捉：\*\*フィッシングサイトにアクセスすると、被害者はPINなどの認証情報を入力するか、SMSで送信されたOTPで取引を確認するように求められます。銀行とやり取りしていると信じている被害者はこれに応じ、無意識のうちに攻撃者に認証情報を渡してしまいます。
4. \*\*悪用：\*\*これらの情報を手に入れた詐欺師は、被害者の銀行口座にアクセスし、不正な取引を行ったり、個人情報を盗んだりすることができます。
### 4.2 実例：ドイツ銀行のフィッシング攻撃
ドイツ銀行の顧客が、自分の口座が無効化されるという警告のSMSを受け取るシナリオを考えてみましょう。メッセージには、URLの一部にdeutschebankを含み、一致するSSL証明書を持つ、顧客の身元を確認するためのウェブサイトへのリンクが含まれています。このサイトは、ドイツ銀行のログインページを正確に複製したもので（下のスクリーンショットで確認できます）、顧客にオンラインバンキングのPINを入力させ、その後リアルタイムでSMS
OTPを要求します（セキュリティ上の理由からスクリーンショットには表示されていません）。顧客が知らないうちに、この情報をフィッシングサイトに入力すると、攻撃者はそのドイツ銀行の口座に完全にアクセスし、多額の資金を他の口座に送金することが可能になります。
これは、銀行口座へのアクセスを回復するよう促すフィッシングSMSです（ドイツ語のスクリーンショットのみ利用可能）：
これは攻撃者によるフィッシングウェブサイトです（[https://deutschebank-hilfe.info](https://deutschebank-hilfe.info)）：
これは参考用の元のウェブサイトです（[https://meine.deutsche-bank.de](https://meine.deutsche-bank.de)）。攻撃者はこれをほぼ完璧にコピーしました（下部のフィッシング警告だけは除外しました）：
この同一のUIを通じてログインし、SMS
OTPを認証要素として使用することに慣れている顧客は、このような攻撃の被害に遭いやすいです。セキュリティ研究目的で、OAuthや銀行システムを標的とするフィッシング攻撃に焦点を当てて設計された、オープンソーススイートのかなりのエコシステムが存在します（例：[https://github.com/gophish/gophish](https://github.com/gophish/gophish)）。しかし、これらのシステムは悪意のある目的に簡単に転用される可能性があります。
\*\*銀行セクターにおけるフィッシングは、ダークウェブでのデータ漏洩のたびにますます正確になっています。\*\*通常、IBANなどの支払い情報もこれらの漏洩の一部です。この情報で直接お金を盗むことはできませんが、攻撃者が標的が実際にその銀行の顧客であることを知っているスピアフィッシングのアプローチで利用される可能性があります。
### 4.3 フィッシング不可能な認証要素の重要性
上記のシナリオにおける致命的な欠陥は、認証要素のフィッシング可能性にあります。**PINとSMS
OTPの両方が、偽りの口実のもとで顧客から簡単に引き出されてしまう**のです。この脆弱性は、ソーシャルエンジニアリングやフィッシング攻撃によって侵害されない認証方法の必要性を強調しています。
**パスキーによって可能になるような、フィッシング不可能な認証要素**は、このような手口に対する堅牢な防御を提供します。パスキーは、開示されたり、ユーザーからだまし取られたり、傍受されたりする可能性のある共有秘密に依存しないため、セキュリティの状況を根本的に変えます。パスキーを使用すると、認証プロセスには詐欺師が複製できない暗号化による身元証明が含まれるため、フィッシングにおける最も一般的な攻撃ベクトルが排除されます。
> パスキーは、登録された正確なドメイン（リライングパーティID）でのみ使用が制限されています。フィッシングドメインでそれらを使用したり、攻撃者にパスキーを送信したりすることは技術的に不可能です。
### 4.4 フィッシングとどう戦うか？
フィッシングの脅威に効果的に対抗するために、銀行セクターは以下を含む多面的なアプローチを採用する必要があります。
1. \*\*顧客教育：\*\*銀行は、フィッシングのリスクと不正な通信を認識する方法について、顧客に継続的に情報を提供する必要があります。
2. \*\*フィッシング不可能な認証の実装：\*\*勧誘されたり傍受されたりする可能性のある情報に依存しない認証方法に移行し、多くのフィッシング試行の扉を閉ざすこと。
3. \*\*不正検出システムの強化：\*\*高度な分析と機械学習を利用して、たとえフィッシャーが何らかの形の認証データを取得したとしても、不正な取引を検出・防止すること。
フィッシングは銀行セクターにとって依然として重大な脅威ですが、パスキーのようなフィッシング不可能な認証方法の採用は、詐欺師からオンラインバンキングを保護する上で重要な一歩前進となります。**認証要素のフィッシング可能性という最も弱いリンクを取り除くことで、銀行は顧客の資産と個人情報のセキュリティを大幅に強化できます。**
今日に至るまで、欧州中央銀行や各国の銀行監督当局（例：BaFin）は、[パスキー全体が2FAとして分類されるか](https://www.corbado.com/blog/psd2-passkeys/are-passkeys-two-factor-authentication)、また銀行がどのように使用すべきかについて、見解を示していません。
次のセクションでは、私たちがパスキーがPSD2に準拠していると考える理由を説明します。
## 5. パスキーはPSD2に準拠しているか？
決済、フィンテック、銀行セクターのステークホルダーとの議論の中で、繰り返し浮上する質問があります。\*\*「パスキーはPSD2に準拠しているのか、そして銀行のシナリオで唯一の認証形式として機能できるのか？」\*\*というものです。欧州連合におけるパスキーと決済サービス指令改訂版（PSD2）の関係は微妙であり、詳細な検討が必要です。明確にするために、パスキーは通常、\*\*同期パスキー（マルチデバイス）**と**非同期パスキー（シングルデバイス）\*\*の2つのタイプに分類され、それぞれがPSD2コンプライアンスに関して異なる特性を持っています。
| | 同期パスキー | 非同期パスキー |
| ------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------- |
| **デバイスの可用性** | マルチデバイス | シングルデバイス |
| **管理元** | オペレーティングシステム | 追加のソフトウェアが必要 |
| **秘密鍵** | オペレーティングシステムのクラウドアカウント
（例：iCloudキーチェーン、Googleパスワードマネージャー）またはサードパーティのパスワードマネージャー
（例：1Password、Dashlane）にアップロードされる | ユーザーのデバイス上に留まる |
| **デバイスバインディング** | なし | あり |
| **バックアップ** | あり | なし |
| **PSD2コンプライアンスに関する従来の意見** | いいえ（？） | はい |
銀行や[保険](https://www.corbado.com/passkeys-for-insurance)会社などの規制対象事業体にとって、コンプライアンスの遵守は非常に重要です。しかし、コンプライアンスに関するポリシーが変わるには長い時間がかかることがあります。パスキーの場合、**主なセキュリティ上の利点はそのフィッシング不可能性**であり、顧客が誤ってこの情報を攻撃者に開示することがない点です。
## 6. なぜ同期パスキーはリスクではないのか
パスキーはフィッシング不可能であることでセキュリティを大幅に強化しますが、リスクの一部を[Apple](https://www.corbado.com/ja/blog/how-to-enable-passkeys-macos)のiCloudキーチェーンなど、顧客のクラウドアカウントに移します。これにより、クラウドアカウントは攻撃者にとってより魅力的な標的となります。しかし、**AppleのiCloudのようなサービスには、特にパスキーをサポートする機能に対して堅牢なセキュリティ対策が施されています**。
第一に、iCloudのパスキーは、アカウントで[2要素認証（2FA）](https://www.corbado.com/blog/psd2-passkeys/are-passkeys-two-factor-authentication)が有効になっていることが条件であり、これによりセキュリティ層が追加されます。これは、たとえ攻撃者が顧客のiCloudパスワードを知っていても、[2FA](https://www.corbado.com/blog/psd2-passkeys/are-passkeys-two-factor-authentication)コードを受け取るためには信頼できるデバイスや電話番号へのアクセスが依然として必要であることを意味します。
[Apple](https://www.corbado.com/ja/blog/how-to-enable-passkeys-macos)、そして同様にGoogleも、自社のアカウントのためにこれらのクラウドサービスを保護するために多大なリソースを投資しています。クラウドでパスキーをサポートするアカウントのセキュリティプロトコルは厳格であり、**不正なユーザーが侵入することはほぼ不可能**です。この高いセキュリティ基準は、絶え間ないアップデートとセキュリティパッチによって維持されています（また、彼らは自社のアカウントにもパスキーを導入しています。こちらのブログ記事を参照してください）。
さらに、デバイスやクラウドアカウントの盗難は潜在的なリスクではありますが、銀行アプリケーションに対する最も一般的な攻撃ベクトルではありません。疑わしい取引など、セキュリティの必要性が高まった場合には、銀行は追加の要素としてSMS
OTPを引き続き使用することができます。**PIN/パスワードをパスキーに置き換えることで**、最初の認証要素がフィッシング不可能になり、フィッシング攻撃が成功するリスクを大幅に削減します。疑わしいとフラグが立てられた取引には、**第3の要素を導入**することができ、堅牢なセキュリティ体制を確保します。
> 攻撃対象領域はシフトするかもしれませんが、**全体的なセキュリティ体制は強化され**、ユーザビリティを犠牲にすることなく顧客のセキュリティを強化しようとする銀行や[保険](https://www.corbado.com/passkeys-for-insurance)会社などの規制対象事業体にとって、パスキーは魅力的な選択肢となります。
## 7. ネオバンクはどのように規制当局に行動を促すか
PSD2コンプライアンスに関する従来の（リスク回避的な）見解とは対照的に、[Finom](https://www.corbado.com/blog/finom-passkeys)と[Revolut](https://www.corbado.com/blog/revolut-passkeys)は、**顧客データの保護がより重要である**と判断し、銀行監督当局がPSD2コンプライアンスに関してパスキーをどのように扱うべきかについての欧州の公式な決定がないにもかかわらず、パスキーを使用しています。[Finom](https://www.corbado.com/blog/finom-passkeys)や[Revolut](https://www.corbado.com/blog/revolut-passkeys)のようなネオバンクやフィンテックは、現状に挑戦し、そうすることで、PSD2によって規定された認証措置に関する規制の状況に影響を与えています。
顧客データのセキュリティと完全性を優先することで、これらのフィンテックのパイオニアは、欧州当局からの明確な規制ガイダンスがない場合でもパスキーを採用しています。この積極的な姿勢は、**規制当局に、優れたセキュリティソリューションを提供する技術の進歩に照らして、コンプライアンスフレームワークを再評価する責任**を負わせます。
[Finom](https://www.corbado.com/blog/finom-passkeys)と[Revolut](https://www.corbado.com/blog/revolut-passkeys)のパスキー実装という大胆な動きは、規制コンプライアンスの重要な側面を浮き彫りにします。それは、基準に厳格に従うことではなく、むしろその基準の根底にある目標、この場合は**顧客データと取引の最大限のセキュリティ**を達成することであるべきだということです。従来のコンプライアンスモデルへの厳格な準拠よりもデータ保護を優先することを選択することで、これらのネオバンクは業界の新たな基準を打ち立てています。
> 規制当局に行動を促すことで、これらのネオバンクは、消費者の利益をより効果的に保護する新興技術と歩調を合わせてコンプライアンスが進化しなければならないというパラダイムシフトを提唱しています。
## 8. どのような規制変更が必要か？
規制の観点から、PSD2コンプライアンスの枠組み内でパスキーのような進歩に対応するためには、明確化と適応が急務です。\*\*私たちはEUに対し、パスキーについて明確な見解を示すよう強く求めます。\*\*パスキーは、デジタル決済エコシステムにおけるセキュリティを強化し、不正を削減するというPSD2の核となる目的に沿った、優れた多要素認証（MFA）の形式であると認識すべきです。
\*\*パスキーは、その設計上、ほとんどの従来のMFA方法のセキュリティ能力を上回る、堅牢でフィッシング耐性のある認証要素を提供します。\*\*これはセキュリティを強化するだけでなく、ユーザーエクスペリエンスを簡素化し、PSD2コンプライアンスの2つの重要な側面に対応します。
EUの見解は、効果的で安全な認証を構成するものを再定義する技術の進歩を反映するように進化すべきです。パスキーのようなイノベーションを受け入れ、それらを規制の枠組みに組み込むことで、EUは消費者を保護し、先進的なデジタル金融環境を育成するという両方のコミットメントを示すことができます。
金融業界が革新を続ける中、規制当局には、技術の変化に歩調を合わせるだけでなく、将来の発展を予測する明確で進歩的なガイダンスを提供する責任があります。現在、ネオバンクが先頭を切っていますが、最終的には金融セクター全体が安全かつ自信を持ってデジタルバンキングの未来に進むことができるようにするのは、規制機関の責任です。
## 9. 銀行とフィンテックへの提言
銀行およびフィンテック分野でのパスキーの採用は、セキュリティとユーザーエクスペリエンスの両方を大幅に向上させるイノベーションの代表例として際立っています。この記事を通じて、私たちはパスキーが、フィッシングなどの一般的な脅威を軽減しつつ、PSD2の厳格なセキュリティ要求に合致する先進的な認証ソリューションとしての可能性を確立しました。FinomやRevolutのようなネオバンク/フィンテックは、セキュリティフレームワークに*パスキーを統合することで先例を作り*、その有効性と顧客中心のアプローチを示しました。
伝統的な銀行のための3段階のアクションプランは次のようになります。
1. \*\*地域の規制当局との連携：\*\*伝統的な銀行は、パスキーの導入について、地域の規制機関や銀行監督当局と積極的に対話すべきです。この対話は、規制上の立場を明確にし、既存のコンプライアンス構造内でパスキーを統合する道を開くことを目的とすべきです。主導権を握ることで、銀行は革新的な認証方法をサポートする規制環境の形成に貢献できます。
2. \*\*ネオバンクのベストプラクティスから学ぶ：\*\*伝統的な銀行にとって、パスキーを成功裏に導入したネオバンクを観察し、学ぶことが不可欠です。これらのベストプラクティスを研究することで、パスキー展開の運用、技術、顧客サービスの側面に関する貴重な洞察が得られます。この知識移転は、伝統的な銀行がパスキーを採用するための戦略を練るのに役立ちます。
3. \*\*パスキーへの戦略的移行：\*\*規制の明確化とベストプラクティスの理解を得て、伝統的な銀行は顧客をパスキーベースの認証に移行させるための包括的な計画を策定できます。この計画には、パスキーの利点と使用法を説明するための顧客教育キャンペーン、スムーズな移行を保証するための段階的な展開、そしてあらゆる課題に迅速に対処するための継続的な評価が含まれるべきです。最適化された[モバイルとデスクトップのパスキー作成フロー](https://www.corbado.com/faq/optimize-passkey-creation-flows-mobile-desktop)とサインイン後のナッジ、およびインテリジェントな[パスキーログイン](https://www.corbado.com/ja/blog/passkey-login-saiyouritsu-kojo-best-practice)フローは、パスワードを段階的に廃止できる50%以上の導入率を達成するために不可欠です。
## 10. Corbadoが銀行のPSD2準拠パスキー実装をどのように支援するか
理論から実践に移行する際、銀行はPSD2/SCAの規制要件と現実のパスキー展開とのギャップを埋めるツールを必要としています。[Corbado Connect](https://www.corbado.com/connect)は、既存のアイデンティティスタックの上に配置される[パスキーインテリジェンス](https://docs.corbado.com/corbado-connect/features/passkey-intelligence)レイヤーを提供し、ユーザーの移行を必要としません。
[Video: Passkey intelligence](https://www.corbado.com/videos/connect/passkey-intelligence.mp4) ([See how Corbado Connect ships this](https://www.corbado.com/connect))
### 所持要素をめぐる問いに対する証拠
本記事でたどってきた議論は、監督当局が投げかけうる1つの問いに行き着きます。すなわち、自社のクレデンシャルのうちデバイスバウンドの割合と同期パスキーの割合はどれだけか、という問いです。[Corbado Observe](https://www.corbado.com/observe)の[Authenticator](https://www.corbado.com/glossary/authenticator)
Inventoryは、解釈ではなく自社のユーザーベースの実データからこの問いに答えます。各クレデンシャルの背後にあるオーセンティケーターを[FIDO](https://www.corbado.com/ja/blog/visa-passkey)
Metadata
Serviceで解決するため、この内訳はオーセンティケーターのモデルごとに、その認証（certification）レベルとあわせて示され、セキュリティキーを保有しているユーザーの割合も同時に確認できます。
これにより、自社のSCAに関する立場は提示できるものになります。どの解釈を主張するかは引き続き自社のリスク評価の問題ですが、その解釈が適用される母集団はもはや推計ではなくなります。
### OTPを段階的に廃止する間のロールアウトルール
銀行が認証方式を全ユーザーに対して一度に切り替えることはまれであり、PSD2の下ではそもそもそれができません。[Corbado Connect](https://www.corbado.com/connect)は、段階的ロールアウトを設定可能なルールセットとして提供します。デバイスのブランドとモデル、プラットフォームのバージョン、ブラウザ、[WebView](https://www.corbado.com/blog/native-app-passkeys)に対する条件、ルールごとのallow・block・samplingの判定、そしてパスキーのトラフィックを既存フローへ戻すキルスイッチが含まれます。
ルールセットは本番投入前に記録済みトラフィックに対してシミュレーションできます。これにより、あるルールが必要なコホートを除外してしまうことを、そのコホート自身から知らされる前に把握できます。上記のInventoryと組み合わせると、手順は「母集団を測る、ポリシーを決める、シミュレーションする、そして公開する」という順序になります。
> **PSD2/SCAおよびパスキーに関するCorbadoの見解：**
> パスキー（デバイスバウンドおよび同期のいずれも）はSCAに準拠できます。各機関は自社のSCAリスク評価に責任を持つ必要がありますが、証拠は明確です。パスキーは本質的に、所有（ハードウェアセキュリティモジュールまたはクラウドキーチェーン内の秘密鍵）+ 生体情報（指紋など）または知識（PIN）という2つのSCA要素を提供します。「所有」に関する議論は微妙ですが解決可能です。業界は以下の3つのアプローチに落ち着きつつあります：(1)
> **そのままのパスキー**（例：Revolut、Finom） - 生体情報 + 秘密鍵を持つデバイスによる所有、(2)
> **パスキー +
> Cookie/セッションバインディング**（例：[PayPal](https://www.corbado.com/blog/paypal-passkeys)、Comdirect） - 保守的な解釈のための追加の所有シグナル、(3)
> **暗号化バインディング（DBSC/DPoP）** - 所有のハードウェアバウンド証明、最も強力な保証。まだ単一の「正しい」解釈は存在しません。厳格な要素の分類ではなく、実証可能なフィッシング耐性に焦点を当てた、結果ベースのSCAへのアプローチが必要です。パスキーを使用した場合でも、決済のための[動的リンク](https://www.corbado.com/blog/dynamic-linking-passkeys-spc)は依然として別の要件として残ります。