パスキーはフィッシング耐性MFAの本命――導入で減る攻撃、残る攻撃、現場が今やるべきことです

なぜ重要か

• パスキーはWebAuthn/CTAPに基づく公開鍵認証で、チャレンジがオリジン（RP ID）に暗号的に結び付くため、中間者型フィッシング（AiTM）や資格情報詐取を本質的に困難にします。米CISAも「フィッシング耐性MFA」の代表としてFIDO2/WebAuthnを明示していますです。CISA
• Googleはパスキーが「パスワードより約40%高速」で、入力エラーも減ると公表しており、利便性と安全性の両立が見込めますです。Google
• 国内外のSaaS/プラットフォーム（Apple、Google、Microsoft、GitHubなど）が相次ぎ対応し、2024年時点で主要OS・ブラウザで実用レベルの互換性が整っていますです。Apple / Google Dev / Microsoft Entra / GitHub
• 本ニュースのスコアリングでは総合score 9.50、immediacy 9.00、actionability 9.50、probability 9.50と高評価で、短中期での導入効果が高く、実装に移しやすいテーマであることを示していますです。CISO観点では「今期のロードマップでパイロット→本番拡大」が妥当な優先度と言えますです。

メトリクスの示唆

• scale 8.50／magnitude 9.00: 組織規模を問わず広範囲に影響し、影響度も大です。ID基盤を握る企業ほど全社波及が大きく、SOC運用やヘルプデスク工数にも直結しますです。
• novelty 8.00: 標準自体は成熟（WebAuthnはW3C勧告）ですが、マルチデバイス同期パスキーの普及は比較的新しく、運用ノウハウの共有が価値を持つ段階です。W3C WebAuthn Level 3
• immediacy 9.00／actionability 9.50: 主要IdPやSDKが整備済みで、今期にパイロット可能です。まずは高リスク業務や特定ユーザー群から展開するのが現実解です。
• credibility 9.50: FIDO/W3C/NIST/CISAに裏打ちされた技術で、信頼性は高いです。FIDO / NIST SP 800-63B

詳細分析

事実（スタンダードとエコシステム）

• 標準と仕組み
  • パスキーはWebAuthn（RPとクライアント間）とCTAP（クライアントとオーセンティケータ間）に基づく公開鍵認証です。秘密鍵はデバイス側で保護され、RPには公開鍵のみ登録されますです。W3C / CTAP2
  • オリジンに結び付いたチャレンジに署名するため、フィッシングサイトやAiTMプロキシは正しいrpIdで署名を得られず、資格情報の再利用も不可能です（サーバ側は署名検証で弾けます）です。
• 対応状況
  • OS/ブラウザ: iOS/iPadOS 16+、Android 9+（Google Password Manager/Play Services）、Windows 10/11（Windows Hello）、主要ブラウザ（Chrome、Safari、Edge、Firefox）が対応していますです。Apple / Google Dev
  • サービス: Googleアカウント、Microsoft Entra、GitHub、Adobe、PayPal等が対応を公表・実装済みです。企業はIdP（Okta/Entra/ForgeRock等）の機能で段階的に導入可能です。Microsoft Entra / GitHub
• 攻撃面への効果
  • CISAはFIDO2/WebAuthnを「フィッシング耐性MFA」として推奨し、従来のSMS/OTP/プッシュより強固としていますです。CISA
  • MicrosoftはMFA全般で「アカウント侵害の99.9%を阻止」と報告しており、その中でもFIDO2はAiTMに強く、実効防御力が高い方式です（数値は全MFAの一般効果であり、FIDO2固有値ではない点に留意）です。Microsoft
• 利便性
  • Googleはパスキーがパスワード比で約40%高速と公表し、UX改善が期待できますです。これにより認証失敗率やヘルプデスク稼働の低減が見込めますです。Google

インサイト（実装・運用の勘所）

• 同期型 vs デバイス固定型
  • 同期型パスキー（Apple iCloud、Google、Microsoftのクラウド暗号化同期）は紛失・機種変更に強く、一般ユーザー向けに実運用しやすい一方、プラットフォーム固有の回復プロセス（アカウント復旧）が新たなソーシャルエンジニアリング面の弱点になり得ますです。企業は「誰のクラウドに依存するか」をリスクとして明示し、回復フローの多要素検証を設計すべきです。
  • デバイス固定（セキュリティキー/StrongBox/SE）を選ぶと強度は高い一方、紛失・予備キー配布・貸与PCなどの運用設計が不可欠です。規制業種や特権IDはこの選択を優先検討すべきです。
• フィッシング「後」の世界
  • パスキーはAiTMやスプーフィングを大幅に抑制しますが、端末側マルウェアによるセッショントークン窃取や、OAuthの「同意フィッシング」（悪性アプリへの権限委譲）は依然として有効です。MFA疲労は減る一方、Cookie/トークンの再利用、同意画面の誤認誘導が主戦場に移ると見ます（仮説）です。対応には短寿命セッション、重要操作での再認証、DPoPなどトークン再利用対策が必要です。RFC 9449 DPoP
• 「パスキー＋弱いフォールバック」は総当たりの抜け道
  • パスキー導入初期は回復や互換性のためにSMS/メールリンクなどのフォールバックを併存させがちです。攻撃者は最弱リンクを狙うため、回復フローは「本人性の強い別経路」（対面、既登録FIDO2、管理者承認＋監査）に限定し、IVRやチャットでの安易なリセットを封じるべきです。Twilio等の事例が示すように、ヘルプデスクの社会工学は依然リスクです（一般論）です。
• エンタープライズのアテステーション戦略
  • プラットフォームオーセンティケータはプライバシー理由でアテステーションを制限する場合があり、デバイス種の厳格な証明が難しいことがあります。社給端末限定でFIDO2セキュリティキーのアテステーションを必須にするか、リスク受容のもとでプラットフォーム認証を許可するか、方針を分けるべきです。WebAuthn Attestation
• ネイティブ/ハイブリッドアプリの設計
  • Webだけでなく、モバイル/デスクトップアプリもWebAuthnブリッジ（App-bound passkeyやcaBLE/hybrid transport）でパスキーを扱えます。SSOのIdP側でパスキー対応を先行するのが、SaaS横断での効果を早く出す近道です。

脅威シナリオと影響

• 成功しづらくなる攻撃
  • AiTMフィッシング（Evilginx系）: オリジンに結び付く署名検証で阻止されます。影響は高頻度の業務アカウント窃取の抑止に直結しますです。
  • パスワードスプレー/総当たり/TOTP再利用: パスワード自体が無くなり、使い回しリスクやOTP傍受の価値が低下しますです。
• 依然として有効な攻撃（対策が必要）
  • セッショントークン窃取・再利用（INFOSTEALER、ブラウザCookie盗難）: 認証後のセッションを奪取されるリスクは残ります。セッション短寿命化、重要操作での再署名、SameSite/HttpOnly/secure属性、継続検証が必要です。
  • アカウント回復フローの社会工学: ヘルプデスク/管理者に対する偽装・なりすましで回復手順を悪用される恐れがあります。通話記録、相互チャレンジ、タイムロック、4眼承認などのガードが必要です。
  • 同意フィッシング（OAuth/OIDC）: パスキーは認証を強化しますが、ユーザーが悪性アプリに権限を与えることは防げません。スコープ制限、コンセントポリシー、検疫が必要です。
  • 端末コンプロマイズ: EDR/MDMでの端末健全性評価と組み合わせない限り、ローカルマルウェアが生体認証を経てセッションを悪用する恐れがあります。
• 運用・規制面の影響
  • 監査と規制準拠: NIST SP 800-63BのAAL要件に照らして、どのフローがAAL2/AAL3相当かを文書化し、特権操作ではより強いポリシーを適用すべきです。NIST 800-63B
  • BCP: デバイス紛失時の回復とインシデント時の一括無効化（登録鍵ロールオーバー）手順は、攻撃抑止と人為ミス抑制の両面で必須です。

セキュリティ担当者のアクション

短期（0–90日）

• 方針決定: リスク許容度に応じ「同期型パスキー許容範囲」「特権IDはセキュリティキー必須」などの原則を確立します。
• 技術選定: 既存IdP（Microsoft Entra/Okta等）のパスキー対応機能を評価し、PoC対象SaaS/社内アプリを選定します。
• 実装ベースライン（WebAuthnサーバ設定）
  • userVerification=required、residentKey=required（ユーザー名不要のフローを前提に）、rpIdの固定、十分なchallenge entropy、アテステーションポリシーの明示を徹底します。W3C WebAuthn
• ログと検知
  • 認証イベントに「方式（FIDO2/パスキー/フォールバック）」「失敗理由」「デバイス種」「登録/削除の監査ログ」を追加します。フォールバック利用率の監視を開始します。
• 教育・ヘルプデスク
  • 回復フローの社会工学対策（コールバック、禁止語、セキュリティワード、録音のレビュー）を即時強化します。

中期（90–180日）

• 段階展開: 高リスク部門/特権IDから「パスキー優先（passwordless）」に移行し、成功率・所要時間・ヘルプデスク件数のKPIを可視化します。目標例（参考値・仮置き）として6カ月で対象ユーザーの登録率60%超を狙います（組織特性に依存）です。
• セッション防御の強化
  • 重要操作（送金、特権昇格、APIキー発行）での再署名（WebAuthn assertion）を導入し、セッショントークン単独では完了させない設計にします。
  • OAuth2/OIDC採用箇所でDPoPやmTLS等のトークン再利用対策を検討します。RFC 9449
• アテステーション/デバイス信頼
  • 社給端末と個人端末で許容するオーセンティケータ種を分離し、特権IDはFIDO2セキュリティキーのアテステーション必須へ（可能ならば）移行します。

長期（180日以降）

• パスワード撤廃の条件整備
  • パスワードの保険的残置を段階的に縮退させ、回復経路もFIDO2主体へ。メール/SMSベースの回復は高リスク例外に限定します。
• 継続的評価・赤チーム演習
  • AiTM対策有効性（失敗を確認する演習）と、セッション・回復フローの耐性テスト（成功・未然防止の両面）を定期化します。
• KPI運用
  • 主要指標: パスキー登録率、ユーザー名不要ログイン比率、フォールバック利用率、認証失敗率、ヘルプデスクチケット数、アカウント侵害件数、特権操作の再署名実施率。四半期ごとに改善目標を設定します。

実装の落とし穴チェックリスト

• rpIdの誤設定（サブドメイン/カスタムドメイン移行時）の検証を自動化します。
• userVerificationをpreferredのまま出荷しない（必ずrequiredに）ようコードレビューに項目化します。
• フォールバックを「暫定有効→未使用ユーザーから順次無効化」のプレイブックで確実に閉じます。
• ログインと高リスク操作の両方でWebAuthnを使い、セッション単独では重要操作が完了しないようにします。
• お客様向け（B2C）の場合、古い端末でも「QRコード経由のハイブリッド認証」を提供し、サポート負荷を抑えます。

参考情報 (リンク付き箇条書き)

• W3C Web Authentication: WebAuthn Level 3（勧告）: https://www.w3.org/TR/webauthn-3/
• FIDO Alliance: Specifications（CTAP/WebAuthn関連）: https://fidoalliance.org/specifications/
• CISA: Implementing Phishing-Resistant MFA（ガイダンス）: https://www.cisa.gov/resources-tools/resources/implementing-phishing-resistant-mfa
• NIST SP 800-63B: Digital Identity Guidelines（AAL等）: https://pages.nist.gov/800-63-3/sp800-63b.html
• Google: Passkeys are the beginning of the end of the password（約40%高速の言及）: https://blog.google/technology/safety-security/the-beginning-of-the-end-of-the-password/
• Apple Developer: Passkeys overview: https://developer.apple.com/passkeys/
• Microsoft Entra ID: Passkeys 概要: https://learn.microsoft.com/entra/identity/authentication/concept-authentication-passkeys
• GitHub: Introducing passkeys on GitHub.com: https://github.blog/2023-07-12-introducing-passkeys-on-github-com/
• IETF RFC 9449: OAuth 2.0 Demonstrating Proof-of-Possession (DPoP): https://www.rfc-editor.org/rfc/rfc9449
• Security Boulevard（本件ニュースの参照元）: https://securityboulevard.com/2025/10/using-passkeys-to-sign-in-to-websites-and-apps/

注: 一部の「将来の攻撃傾向」や「KPI目標値」は現場導入の一般的経験則に基づく提案・仮説であり、組織の業務特性やユーザープロファイルに応じて調整が必要です。現行の標準・仕様・各社実装状況はリンク先の一次情報で随時アップデートを確認してください。