メインコンテンツまでスキップ

金融機関の認証設計：パスキー導入と復旧条件

文書番号：2601.00005

要旨​

銀行、証券、保険を含む金融業界では、フィッシングやクレデンシャルスタッフィング等を起点とする不正アクセスが継続的に増加し、 特に「リアルタイムフィッシング（中間者型）」により、従来のID/パスワード＋OTP（SMS/メール等）を組み合わせた多要素認証（MFA）でも突破される状況が顕在化しているのだ。 （出典：1、2）

本レポートは、日本および米国の金融業界における、(1) 不正アクセス対策、(2) パスキー（FIDO2/WebAuthn）導入、 (3) 電話認証（顧客が電話をかける形）の現状と見通しを、技術担当者向けの観点と、経営層向けの観点に分離して整理するのだ。 規制・指針として、日本は金融庁（FSA）発信文書、米国はFFIECガイダンスおよびNISTデジタルIDガイドラインを根拠に含め、先進事例として国内証券のパスキー必須化等を具体例として提示するのだ。 （出典：1、3、4、5）

1. 序論​

1.1. 問題意識​

認証は、不正アクセスの主要な侵入経路であり、金融機関における損失（補償、取引停止、ブランド毀損）を左右するのだ。 他方、利用者層が広く、チャネルも多様（Web、モバイルアプリ、コールセンター等）であるため、強固な認証を一律適用しにくいのだ。 その結果、「最弱の例外」が攻撃経路になるリスクが高いのだ。

1.2. 本レポートの範囲​

  • 対象業態：銀行、 証券、 保険
  • 対象地域：日本、 米国
  • 主要テーマ： 不正アクセス対策（認証、 取引時防御、 検知）、 パスキー、 電話認証（顧客発信）

1.3. 調査方法​

公的機関・規制当局・標準（金融庁、FFIEC、NIST）と、金融機関の公開資料（導入告知、FAQ、プレスリリース）を中心に、2024〜2026年初頭時点の公開情報を整理したのだ。 （出典：1、3、4）

2. 脅威動向​

2.1. リアルタイムフィッシングによる「OTP突破」​

リアルタイムフィッシングは、利用者が偽サイトに入力した認証情報・OTPを、攻撃者が正規サイトに中継して即時に悪用するのだ。 これにより、「OTPを入力させる」タイプのMFAは、利用者が騙される限り、原理的に突破されうるのだ。 （出典：2、4）

2.2. 規制当局のメッセージの変化​

金融庁の注意喚起では、多要素認証の設定に加え、パスキー等のフィッシング耐性のあるMFAの導入が進んでいる旨が明記され、提供開始時には速やかな設定を促しているのだ。 （出典：1）

米国でも、FFIECは「認証とアクセス」を、リスク管理、多層防御（layered security）、監視、インシデント対応まで含めて扱うガイダンスを提示しているのだ。 （出典：3、6）

NISTのデジタルIDガイドライン（SP 800-63-4）は、フィッシング耐性（phishing-resistant）の概念を整理し、 AAL2等でフィッシング耐性認証に限定する選択肢を示すなど、「認証の質」を前提とする方向性を明確化しているのだ。 （出典：4、7）

3. 現状整理（日本）​

3.1. 不正アクセス対策の実装傾向​

金融庁の注意喚起は、(1) リンクを開かない、(2) 正規URLをブックマークする、(3) ログイン時・取引時・出金時等で多要素認証や通知を有効化する、という行動レベルの推奨を具体的に列挙しているのだ。 （出典：1）

実務的には、ログイン防御に加え、「重要操作（送金、出金、出金先変更、証券取引等）」で追加の防御を重ねる設計が主流になりやすいのだ。 （出典：1）

3.2. パスキー導入：証券が先行​

野村證券：2025年11月29日からパスキー認証を必須化​

野村證券は、オンラインサービスおよびアプリにおいて、2025年11月29日からパスキー認証を必須化した旨を案内しているのだ。 （出典：5）

併せて、一部端末での登録・認証エラーの発生と対策（調査中、確認事項）を案内しており、金融業界でも「端末差・実装差がUX課題になる」ことを示す具体例であるのだ。 （出典：8）

SBI証券：2025年10月25日にログイン時MFAとして導入​

SBI証券は、2025年10月25日から、ログイン時の多要素認証としてパスキー認証を導入した旨を案内しているのだ。 （出典：9）

グループ側の発表でも、FIDO2パスキーソリューション導入完了（2025年10月25日）として整理されているのだ。 （出典：10）

楽天証券：2025年10月26日から全チャネルログインに導入​

楽天証券は、FIDO2パスキー認証を全チャネルログインに導入する旨をプレスリリースで公表しているのだ。 （出典：11）

一方で、一部端末での作成・認証不具合、QR読み取りの推奨等、運用・サポート観点の論点もFAQとして明示しているのだ。 （出典：12、13）

国内証券の追加事例と確認時点​

以下は2026年9月18日に公式ページを確認した補足なのだ。前節の2024〜2026年初頭の調査と、告知日・適用日・今回の確認日を混同しないのだ。

対象公表された内容・時点読む際の条件と一次資料
マネックス証券2026-01-20の告知で、1月末以降のログイン時パスキー必須化を順次適用初回ログインと既存利用者、任意設定期間を分けているのだ。https://info.monex.co.jp/news/2026/20260120_03.html
SMBC日興証券パスキー認証の案内でOS・ブラウザ・保存先の条件を掲載名称だけで利用可否を判断せず、利用端末の条件を確認するのだ。https://www.smbcnikko.co.jp/security/passkey.html
三菱UFJモルガン・スタンレー証券2026-05-11のログイン認証切替と、6月以降の出金時パスキー利用を案内初回登録の本人確認、端末、復旧の条件を分けるのだ。https://www.sc.mufg.jp/trade/passkey/index.html
三菱UFJ eスマート証券2025-10-28に2026年春の導入予定を告知この発表だけで導入完了や全利用者への必須化を断定しないのだ。https://kabu.com/company/pressrelease/20251028_2.html

導入例の列挙より、ログイン・出金・登録・復旧のどこに適用されるかを比較するのだ。銀行や関連サービスの一般的な認証案内、eKYCの告知、古いFIDO関連発表を、そのまま現在のパスキー導入実績として数えないのだ。

金融サービス、認証器、運用条件の関係

図は認証器、サービス、回復と移行の関係を示す概念図なのだ。端末内に限らず同期型の鍵管理もあり、各社の導入状況や実装を個別に証明する図ではないのだ。

3.3. 電話認証（顧客発信）の位置づけ​

電話発信型（着信電話認証）は、「登録済み電話番号から所定番号へ発信し、発信者番号の一致で認証する」方式として整理され、 SMS/メールより手間が少なく、固定電話等も含む幅広い利用者に適用しうるのだ。 （出典：14）

国内のパスキー導入事例でも、パスキー利用が困難な場合の代替として、電話による認証・手続を案内する例が見られるのだ。 （出典：5）

ここで重要なのは、電話認証が「パスキーの代替」ではなく、例外利用者の受け皿、または高リスク操作の補助線として機能し、例外ルートを最小化する設計に位置づけることなのだ。

4. 現状整理（米国）​

4.1. FFIEC：認証を単体ではなくリスク管理として扱う​

FFIECガイダンスは、認証・アクセス管理を、リスク評価、制御の選択、監視、インシデント対応まで含む統合的プログラムとして扱い、 「特定方式の採用」よりも、脅威に対して有効な管理を継続的に適用する姿勢を求めているのだ。 （出典：3）

4.2. NIST：フィッシング耐性の概念を標準化​

NIST SP 800-63-4は、認証プロトコルが、攻撃者（偽の認証サーバ等）へのシークレット漏洩を防ぐ性質として、フィッシング耐性を整理しているのだ。 （出典：4）

この整理は、金融機関が「OTP導入済み」だけで満足せず、フィッシング耐性の有無を軸に、認証刷新を設計する根拠となるのだ。

4.3. 先進事例：保険でのパスキー活用（Aflac）​

Aflacは、パスキーによるパスワードレス施策（“Quackcess Granted”）により、セキュリティと顧客体験（CX）改善、サポートコスト削減を掲げ、2024年のCSO Award受賞として紹介されているのだ。 （出典：15、16）

5. 技術観点（セキュリティ担当向け）​

5.1. 設計原則​

5.1.1. 「ログイン」＋「重要操作」の二段構え​

  • ログイン： 可能な限りフィッシング耐性のある認証（例：パスキー）を第一選択とするのだ。 （出典：4）
  • 重要操作： 取引の性質に応じて、 追加防御（追加認証、 通知、 取引制限、 リスク判定）を重ねるのだ。 （出典：1、3）

5.1.2. 例外ルートは「攻撃経路」になりやすい​

パスキー非対応端末、移行未完了ユーザー向けのフォールバックは必要になりやすいが、例外ルートが残るほど攻撃は集中するのだ。 したがって、例外ルートには、より強い制限（上限、遅延、チャネル限定、追加確認）を設計上あらかじめ付与するのだ。

5.2. パスキー導入の実装・運用論点​

5.2.1. 相互運用と端末差​

  • 端末差（OS、 ブラウザ、 生体認証、 端末内保護領域）により、 登録・認証の失敗パターンが分散するのだ。
  • その結果、 画面・FAQ・コールセンターの運用設計がセキュリティ成否を左右するのだ。 （出典：8、12）

5.2.2. パスキー管理基盤の違い（iCloud、Google等）​

利用者は、iCloudキーチェーン、Google Password Manager等の「認証情報マネージャ」により、パスキーを保存・同期するのだ。 金融機関側は、利用者の管理基盤を前提にしない設計（複数デバイス登録、復旧手段、説明責任）を用意する必要があるのだ。

Appleは、アカウント作成、既存ユーザーの自動アップグレード等を支援するAPIを整理し、パスキー移行の摩擦低減を強調しているのだ。 （出典：17）

補足として、WWDC 2025の文脈で、同期・失効通知等の運用課題を軽減するAPIの整理が解説されているのだ。 （出典：18）

5.3. 電話認証（顧客発信）の設計論点​

電話発信型認証は、「顧客が自発的に発信する」点で、受電型のソーシャルエンジニアリング（なりすまし）を避けやすいのだ。 （出典：14）

一方、電話番号変更、転送設定、VoIP等を含む運用論点があり、登録・更新・失効の統制を厳格に設計することが前提となるのだ。

6. 経営観点（経営層向け）​

6.1. 規制・ガイダンスを投資根拠に変換する​

金融庁の注意喚起は、顧客対応としての実務項目だけでなく、「パスキー等の導入が進んでいる」点まで明記しているのだ。 これは、認証刷新を、経営判断（投資、例外方針、サポート体制）に落とし込む根拠となるのだ。 （出典：1）

米国でも、FFIECガイダンスは、認証をリスク管理として継続評価することを求めており、監査・検査対応のみならず、ステークホルダー説明（取締役会、顧客、監督当局）に資するのだ。 （出典：3）

6.2. 被害コストとサポートコストの二重性​

不正アクセスは、直接損失に加え、顧客補償、問い合わせ急増、システム改修、信用毀損を同時に誘発するのだ。 そのため、認証刷新は「セキュリティ投資」であると同時に、「運用コストの構造改革」であるのだ。

パスキーは、フィッシング耐性の観点で攻撃成功率を下げることが期待され、同時にパスワードリセット等の問い合わせ削減にもつながりうる、という整理が提示されているのだ。 （出典：19、15）

6.3. ロードマップと例外戦略​

  • 短期： 証券等の高リスク領域から導入、 ログインをパスキー優先に寄せるのだ。 （出典：5、9、11）
  • 中期： 重要操作の追加防御（通知、 上限、 遅延、 リスクベース評価）を高度化し、 例外ルートを縮退させるのだ。 （出典：3）
  • 長期： パスワード依存を極小化し、 顧客層に応じた代替（電話発信、 店頭）を整備しつつ、 例外の統制を強化するのだ。

7. 今後の見通し​

7.1. パスキー主流化は進むが、摩擦は残る​

金融分野でもパスキー導入が進展していること、および銀行がパスキー採用を進めるべきという業界向け論考が提示されているのだ。 （出典：19）

一方で、端末差・エコシステム差に起因する移行摩擦は、短期では残存し、サポート体制（FAQ、問い合わせ導線、復旧手順）が競争力になるのだ。 （出典：8、12）

7.2. 電話認証は「補完」に留めるのが合理的​

電話発信型認証は、スマホ非保有層や固定電話中心の層を支える補完策として有用であるのだ。 （出典：14）

しかし、主軸はフィッシング耐性のある認証（パスキー等）に置き、電話認証は例外・補助線として統制する、という位置づけが整合的であるのだ。

8. 提言​

8.1. 技術（セキュリティ担当）向け​

  • ログインはフィッシング耐性を前提に再設計し、 OTP中心の設計を「例外」に押し込むのだ。 （出典：4、1）
  • 重要操作は、 追加防御（通知、 上限、 リスク判定）を標準化し、 例外ルートを監視・縮退させるのだ。 （出典：3）
  • 端末差を前提に、 失敗パターン別の運用（FAQ、 ログ観測、 コールセンター手順）を設計するのだ。 （出典：8、12）

8.2. 経営層向け​

  • 金融庁・FFIEC等の発信を、 認証刷新の投資根拠として明文化し、 例外方針を含むロードマップを承認するのだ。 （出典：1、3）
  • 「被害コスト」と「サポートコスト」の両面で投資効果を評価し、 利用者移行の摩擦（問い合わせ、 離脱）を吸収する体制を確保するのだ。 （出典：15）

参考資料（出典）​

Footnotes​

  1. 金融庁, 「インターネット取引サービスへの不正アクセス・不正取引による被害が急増しています」(2025-04-03 公表)。多要素認証、通知、およびパスキー等のフィッシング耐性MFAへの言及を含む。 https://www.fsa.go.jp/ordinary/chuui/chuui_phishing.html ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10

  2. PwC Japan, 「単なる多要素認証では防げない脅威：リアルタイム・フィッシングの脅威と求められる対応」(2025-09-16)。不正アクセス動向、リアルタイムフィッシングの説明。 https://www.pwc.com/jp/ja/knowledge/column/awareness-cyber-security/digital-identity09.html ↩ ↩2

  3. FFIEC, Authentication and Access to Financial Institution Services and Systems (2021-08-11)。認証とアクセス管理のリスク管理原則、多層防御、監視等。 https://www.ffiec.gov/press/pdf/Authentication-and-Access-to-Financial-Institution-Services-and-Systems.pdf ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9

  4. NIST, Digital Identity Guidelines (NIST SP 800-63-4) (2025-07)。フィッシング耐性の整理、AAL2でフィッシング耐性に限定する選択肢等。 https://csrc.nist.gov/pubs/sp/800/63/4/final ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7

  5. 野村證券, 「パスキーの登録」（お客様サポート）。2025-11-29よりパスキー認証必須化の案内を含む。 https://www.nomura.co.jp/support/procedure/online/passkey/ ↩ ↩2 ↩3 ↩4

  6. FDIC, Financial Institution Letter FIL-55-2021, FFIEC guidanceの告知（2021-08-11）。 https://www.fdic.gov/news/financial-institution-letters/2021/fil21055.html ↩

  7. NIST, SP 800-63-4 Web版。同期型パスキー（syncable authenticators）等の記載。 https://pages.nist.gov/800-63-4/ ↩

  8. 野村證券, 「【重要】パスキー認証機能が使えない事象が発生している機種の傾向と対策について」(2025-11-04, 2025-12-05更新)。端末差による登録・認証エラーの案内。 https://www.nomura.co.jp/introduc/news/2025/20251104_2.html ↩ ↩2 ↩3 ↩4

  9. SBI証券, 「パスキー認証」。2025-10-25よりログイン時MFAとして導入の案内。 https://www.sbisec.co.jp/ETGate/?OutSide=on&_ActionID=DefaultAID&_ControlID=WPLETmgR001Control&_DataStoreID=DSWPLETmgR001Control&_PageID=WPLETmgR001Mdtl20&burl=search_home&cat1=home&cat2=none&dir=service&file=home_security_passkey_authentication.html&getFlg=on ↩ ↩2

  10. SBIホールディングス, 「SBI証券に次世代認証『パスキー認証（FIDO2）』を導入」(2025-11-26)。導入完了日（2025-10-25）等。 https://www.sbigroup.co.jp/news/pr/2025/1126_15917.html ↩

  11. 楽天証券, 「FIDO2『パスキー認証』全チャネルログインに導入」(プレスリリース, 2025-09-29)。提供開始予定（2025-10-26）等。 https://www.rakuten-sec.co.jp/web/company/newsrelease/pdf/press20250929.pdf ↩ ↩2

  12. 楽天証券, 「パスキー認証（FIDO2）」FAQ。QR読み取り、一部端末での不具合、一時的ログイン手段等の案内。 https://www.rakuten-sec.co.jp/web/security/passkey/ ↩ ↩2 ↩3 ↩4

  13. 楽天証券, 「【重要】一部の端末でパスキーの作成、ログインが正常に行えない事象」(2025-10-28)。 https://www.rakuten-sec.co.jp/web/info/info20251028-02.html ↩

  14. アクル, 「着信電話認証とは｜基礎知識」(2024-10-24)。顧客発信型の電話認証の整理。 https://akuru-inc.com/knowledge/call-verification-2024-10-24 ↩ ↩2 ↩3

  15. Transmit Security, Aflac Wins CSO Award for Improving Security & CX with Passkeys and Transmit Security (2024-09-30)。パスキー導入によるCXとサポートコストの言及。 https://transmitsecurity.com/blog/aflac-wins-cso-award-for-improving-security-cx-with-passkeys-and-transmit-security ↩ ↩2 ↩3

  16. Business Wire, Transmit Security Powers Aflac’s 2024 CSO Award Win for “Quackcess Granted” Passkey Authentication Initiative (2024-10-30)。外部報道としての補強。 https://www.businesswire.com/news/home/20241030184182/en/Transmit-Security-Powers-Aflacs-2024-CSO-Award-Win-for-Quackcess-Granted-Passkey-Authentication-Initiative ↩

  17. Apple Developer, Passkeys Overview。Account Creation API、automatic passkey upgrades等の概要。 https://developer.apple.com/passkeys/ ↩

  18. Authsignal Blog, Apple's WWDC25 Passkey Updates: Fast Forwarding The Journey To Passwordless (2025-06-19)。運用課題（同期、失効等）を扱うAPI整理の解説。 https://www.authsignal.com/blog/articles/apples-wwdc25-passkey-updates-fast-forwarding-the-journey-to-passwordless ↩

  19. FIDO Alliance, 「American Banker: BankThink Banks need to adopt passkeys as a safer alternative to passwords」(2025-12-29)。銀行によるパスキー採用の提言。 https://fidoalliance.org/american-banker-bankthink-banks-need-to-adopt-passkeys-as-a-safer-alternative-to-passwords/ ↩ ↩2