パスキー（FIDO2）はフィッシングに強く、パスワードの使い回しやリスト型攻撃を根本から無効化できる認証方式です。しかし導入時に見落とされがちなのが「パスキーを失ったときにどう復旧するか」という設計です。復旧経路の設計が甘いと、そこが認証全体の最も弱い環（weakest link）になり、せっかくのフィッシング耐性が台無しになりかねません。本記事では、個人利用と企業利用の両面から、安全なパスキー復旧設計の考え方を整理します。
なぜ「復旧設計」が重要なのか
認証の強度は、最も弱い経路に引きずられます。どれだけ強力なパスキーを使っていても、「機種変更でログインできなくなった」ときの復旧手段がSMSワンタイムコードや秘密の質問だけなら、攻撃者はその弱い経路を狙います。実際、アカウント乗っ取りの多くは正規の認証ではなく復旧（リカバリー）フローの悪用を突破口にします。復旧は「例外処理」ではなく、認証設計の中核として扱う必要があります。
パスキーを失う典型的なケース
- スマートフォンの紛失・故障・初期化
- 機種変更時にパスキーが新端末へ引き継がれなかった
- 物理セキュリティキー（USB/NFC）の紛失・破損
- クラウド同期アカウント（Apple ID／Googleアカウント）自体を失う
- 退職者の端末回収により、業務アカウントのパスキーが利用不能になる
復旧手段の選択肢と特徴
1. 同期パスキー（クラウド同期型）
iCloudキーチェーンやGoogleパスワードマネージャーが提供する同期パスキーは、同じクラウドアカウントにログインした新端末へ自動的に引き継がれます。個人利用では最も現実的な復旧手段ですが、復旧の安全性はクラウドアカウント自体の保護に依存します。クラウドアカウントに強力な多要素認証を設定しておくことが前提です。
2. 複数デバイス・複数認証器の登録
1つのアカウントに複数のパスキー（例：スマホ＋PC＋物理キー）をあらかじめ登録しておけば、1つを失っても別の認証器でログインし、失った分を削除・再登録できます。企業利用ではこの「バックアップ認証器」方式が堅実です。少なくとも2つの認証器の登録を推奨します。
3. 物理セキュリティキーの予備
デバイス非依存で管理したい場合は、FIDO2物理キーをプライマリと予備の2本用意し、予備は金庫等に保管します。高い保証レベルが求められる管理者アカウントに向いた方式です。
4. 管理者によるリカバリー（企業利用）
従業員がすべての認証器を失った場合に備え、IT部門が本人確認のうえで一時的な再登録を許可する管理者リカバリーの手順が必要です。ここが手薄だと、ヘルプデスクへのソーシャルエンジニアリングで突破される恐れがあります。本人確認の厳格化と操作の記録（証跡）が欠かせません。
復旧経路を「弱点」にしない設計原則
- フォールバックを弱くしない：復旧手段としてSMSワンタイムコードや秘密の質問のみに頼らない。これらはフィッシング・SIMスワップに弱い。
- 最低2つの認証器：登録時に必ずバックアップ認証器も登録させる運用にする。
- 復旧時こそ厳格な本人確認：管理者リカバリーは、対面・ビデオ・既存の強い要素など多層で本人性を確認する。
- すべて記録する：誰が・いつ・どの経路で復旧したかを証跡として残し、異常を検知できるようにする。
企業でパスキー復旧を運用するには
従業員数が増えるほど、パスキーの登録・失効・復旧は「都度対応」では回らなくなります。入社時のプロビジョニング、機種変更時の再登録、退職時の失効までを、IDライフサイクルの一部として一元的に管理することが重要です。IdP（Microsoft Entra ID等）やアカウント管理基盤と連携し、誰にどの認証器が紐づいているかを常に把握できる状態を保つと、復旧対応の属人化とセキュリティホールを同時に防げます。
まとめ
パスキーはフィッシング耐性の高い優れた認証方式ですが、その価値は「失ったときにどう安全に戻すか」の設計まで含めて初めて実現します。SMSや秘密の質問といった弱いフォールバックに逃げず、複数認証器の登録・厳格な本人確認・証跡の3点を軸に復旧を設計しましょう。そして、登録から失効・復旧までを組織全体で一貫して管理できる仕組みを整えることが、パスワードレス化を「導入して終わり」にしない鍵になります。認証情報のライフサイクルを一元的に統制できる基盤を土台に据えることで、安全性と運用性を両立できます。