パスキー導入の落とし穴 ─ フィッシング耐性MFAを失敗させない移行設計
パスキーはフィッシングに強い認証だが、復旧導線、共有端末、例外運用を誤ると導入後に形骸化する。FIDO2/WebAuthnを組織へ広げる前に決めるべき設計と、段階導入の実務ポイントを整理する。
パスキー移行は、認証方式ではなく業務設計の変更だ
パスキーは「パスワードをなくせる便利なログイン方法」として語られがちだ。しかし組織で導入する場合、本当に変わるのはログイン画面だけではない。ヘルプデスクの本人確認、端末紛失時の復旧、委託先アカウントの扱い、共有端末の運用、退職時の無効化まで、アイデンティティ運用全体が影響を受ける。
CISA は、多要素認証のなかでも FIDO/WebAuthn を広く利用可能なフィッシング耐性認証として位置づけている。NIST SP 800-63B でも、SMSや認証アプリのワンタイムコードのように人が手入力する方式は、攻撃者の偽サイトへ中継され得るためフィッシング耐性とはみなされない。
つまり、パスキー導入は「MFAを少し強くする」施策ではない。認証と認可の入口を、パスワード前提から公開鍵暗号前提へ移すプロジェクトだ。ここを見誤ると、導入したのに例外だらけになり、結局SMSやTOTPへ戻る。
この記事では、パスキーそのものの基本的な仕組みではなく、組織導入で失敗しやすい設計ポイントを扱う。個人利用の基本は パスキーとパスワードレス認証 を先に読むと理解しやすい。
なぜSMSやTOTPでは足りなくなったのか
SMSコードや認証アプリの6桁コードは、パスワードだけよりはずっと強い。だが、2026年の攻撃者は「コードを破る」のではなく、「ユーザーに正しいコードを入力させる」方向へ進化している。
典型が AiTM（Adversary-in-the-Middle）型のフィッシングだ。攻撃者は本物そっくりのログイン画面を用意し、ユーザーが入力したID、パスワード、TOTPコードをリアルタイムで正規サービスへ中継する。ユーザーから見るとログインできたように見えるが、裏側では攻撃者がセッションCookieを取得している。
CyberLensで取り上げた Tycoon 2FA は、この構造をサービス化した例だ。MFAを設定していても、コードを人間が入力する限り、中継型の攻撃に巻き込まれる余地が残る。
パスキーやFIDO2が違うのは、認証情報がサイトのオリジン、つまりドメインに暗号的に結びついている点だ。ユーザーが偽サイトへ誘導されても、そのサイトは正規ドメインではないため、認証プロトコル自体が成立しない。
| 認証方式 | フィッシング耐性 | 主な弱点 |
|---|---|---|
| SMS | 低い | SIMスワッピング、番号乗っ取り、コード中継 |
| TOTP | 中 | AiTMフィッシングでコードを中継され得る |
| Push通知 | 中 | MFA疲労攻撃、誤承認 |
| パスキー / FIDO2 | 高い | 端末・復旧・例外運用の設計が必要 |
ここで大事なのは、「TOTPは無意味」と切り捨てることではない。TOTPはSMSより安全な場面が多い。ただし、AIフィッシング やPaaS型フィッシングが当たり前になった環境では、最終的にフィッシング耐性MFAへ進む計画が必要になる。
失敗しやすい落とし穴：復旧導線・共有端末・例外運用
パスキー導入で最も危ないのは、技術仕様ではなく「困ったときの逃げ道」だ。攻撃者は強い認証方式そのものを破るより、復旧フローや例外申請を狙う。
落とし穴1：復旧手順がヘルプデスク任せになる
端末を紛失した社員が「急ぎなのでパスキーを再発行してください」と連絡してきたとする。ヘルプデスクがメールや電話だけで本人確認し、すぐに旧パスキーを無効化して新しい認証手段を登録できるなら、その復旧導線が新しい攻撃面になる。
Scattered Spider系の攻撃が示したように、攻撃者はITヘルプデスクや委託先を巧みに説得し、MFAリセットや端末登録を通じて正規ユーザーとして入ってくる。パスキーを導入しても、復旧が弱ければ「表玄関に鉄扉、裏口に紙の鍵」という状態になる。
落とし穴2：共有端末と現場端末を想定していない
オフィスワーカーだけなら、Windows Hello、Touch ID、スマートフォンのパスキーで進めやすい。問題は、コールセンター、店舗、工場、医療・研究現場のように、共有端末や手袋着用、端末持ち込み制限がある環境だ。
CISAが公開しているUSDAのFIDO導入事例では、季節雇用者やラボ環境など、標準的なPIVカード運用だけでは難しい利用者がいたことが導入課題として語られている。組織導入では「全員が同じ端末で同じように生体認証できる」という前提を置かない方がよい。
落とし穴3：例外アカウントが増殖する
「このSaaSはまだパスキー非対応」「この委託先はTOTPのまま」「この管理者だけSMSを残す」──こうした例外は最初は仕方ない。しかし棚卸しされない例外は、数ヶ月後に攻撃者の入口になる。
ゼロトラストアーキテクチャの観点では、認証方式はポリシーの一部だ。例外は「許可」ではなく「期限付きのリスク受容」として扱う必要がある。
多くのサービスでは、パスキーを登録してもパスワードログインを完全には無効化できない。つまり、パスキーを追加しただけでは攻撃面が消えない。パスワード、復旧メール、SMS、バックアップコードの扱いまで確認してはじめて、認証強度を評価できる。
導入前に決めるべき5つの設計
パスキー導入は、先にルールを決めてから小さく始める方が失敗しにくい。最低限、次の5点は事前に合意しておきたい。
| 設計項目 | 決めること |
|---|---|
| 対象範囲 | 全社員一斉か、高リスクアカウントから始めるか |
| 認証器 | 同期パスキー、物理セキュリティキー、端末内蔵認証器のどれを許可するか |
| 復旧 | 端末紛失・機種変更・退職・休職時の本人確認と承認フロー |
| 例外 | 非対応SaaS、共有端末、委託先、緊急アカウントの期限と管理者 |
| 監査 | 誰がどの方式でログインしているか、定期的に見える化する方法 |
特に復旧フローは、セキュリティ部門だけで決められない。人事、情報システム、ヘルプデスク、委託先管理、現場責任者を巻き込む必要がある。
高リスクアカウントから始める
最初から全社一斉に導入すると、問い合わせが集中し、例外が乱発される。まずは被害時の影響が大きいアカウントから始めたい。
- IdP / SSO 管理者
- メール管理者
- GitHub、GitLab、CI/CD管理者
- クラウド管理者
- 財務・人事など機微情報を扱う管理者
- 経営層、広報、法務などなりすまし被害が大きい利用者
これは インフォスティーラーとエージェンティックAI の問題ともつながる。攻撃者は、すべての社員を等しく狙うのではなく、クラウドキー、GitHubトークン、SSO管理権限へ近い人物を優先する。
復旧を「本人確認イベント」として設計する
パスキーの再登録は、単なるパスワードリセットより重い操作として扱う。少なくとも、高権限アカウントでは次のような条件を組み合わせたい。
- 既存の信頼済み端末からの承認
- 上長またはシステムオーナーの承認
- ヘルプデスクだけで完結しない二者承認
- 一時的な制限付きアクセス
- 再登録後の一定時間は高リスク操作を制限
「早く業務に戻す」ことは大切だが、攻撃者も同じ言葉を使う。復旧フローほど、スピードと検証のバランスを明文化しておく必要がある。
個人利用と組織利用で、パスキーのリスクは違う
個人利用では、iCloudキーチェーンやGoogle Password Managerに同期されるパスキーは非常に便利だ。スマートフォンを買い替えても復元でき、主要サービスへのログインも速い。多くの人にとって、これはパスワード再利用やSMS認証よりはるかに安全だ。
一方、組織利用では「便利に復元できる」ことがリスクになる場合がある。クラウド同期パスキーを許可するなら、従業員の個人Apple IDや個人Googleアカウントに依存していないか、退職時に企業アカウントから切り離せるか、端末紛失時にどこまで遠隔無効化できるかを確認する。
物理セキュリティキーは運用負荷があるが、高権限アカウントには今でも強い選択肢だ。紛失対策として2本配布する、保管ルールを決める、緊急時用のブレークグラスアカウントを厳格に監査する、といった運用が必要になる。
一般社員には同期パスキー、高権限アカウントには物理セキュリティキー、非対応システムには期限付きでTOTPを残す。現実的には、このような層別化が導入しやすい。大事なのは、どの層にどのリスクを許容しているかを記録することだ。
段階導入の現実解：高リスクから、例外を減らす
パスキー移行は、全社に「来月から全員パスキーです」と告知して成功するタイプの施策ではない。おすすめは、次の順番だ。
- IdP、メール、クラウド、コード管理など高価値システムを特定する
- 管理者・高リスク利用者にFIDO2/パスキーを必須化する
- ヘルプデスクの復旧フローを先に訓練する
- 一般社員へ対象を広げる
- 例外アカウントを月次で棚卸しし、期限切れをなくす
この順番なら、最初から最大のリスクを下げられる。さらに、問い合わせや復旧の失敗を小さい範囲で学習できる。
パスキー導入の目的は、ログイン体験を少し未来っぽくすることではない。ソーシャルエンジニアリングやAiTMフィッシングに対して、認証情報を「盗めない形」に変えることだ。そのためには、強い方式を追加するだけでなく、弱い復旧導線と例外を減らすところまで見なければならない。
まとめ
パスキーは、2026年時点で組織が本気で検討すべきフィッシング耐性MFAの中核だ。FIDO Alliance が説明する通り、パスキーはユーザーが端末を解除する操作でサインインでき、サービス側には公開鍵だけが保存される。NISTやCISAの整理でも、フィッシング耐性を持つ認証としてFIDO/WebAuthnは重要な位置にある。
ただし、パスキーは「登録すれば終わり」の魔法ではない。復旧、共有端末、委託先、非対応SaaS、緊急アカウントをどう扱うかを決めないまま進めると、最終的に弱い例外が残る。
まずは高リスクアカウントから始め、復旧フローを訓練し、例外を期限付きで管理する。そこまで含めて設計できたとき、パスキーは単なる便利機能ではなく、ゼロトラスト時代の入口を支える認証基盤になる。
次に読むなら、基礎として パスキーとパスワードレス認証、攻撃側の文脈として Tycoon 2FA、組織設計として ゼロトラストアーキテクチャ を合わせて確認すると、導入判断が立体的に見えてくる。
