Microsoft Entraのアカウント回復を“パスキー＋生体”で再設計へ——公開プレビューが示す運用と脅威モデルの転換点です

今日の深掘りポイント

• 公開プレビューで、Microsoft Entra IDのアカウント回復にFIDOベースのパスキーと生体認証を使えるようにする動きが始まりました。回復フローの成功率・体験を大幅に引き上げる狙いです。
• これは「ログイン強化」ではなく「回復フローの再設計」です。従来の“最弱リンク”だったSMS/メール依存の手段を、フィッシング耐性の高い手段に置き換える方向性を示します。
• 同期パスキーは利便性が高い一方で、「同期先」「境界（個人／企業）」「方法の追加」という新たな管理ドメインが生じます。高権限と一般ユーザーで使い分けを設計する必要があります。
• 回復・再登録・初期ブートストラップの入口（SSPR、デバイス紛失時の再取得、ヘルプデスク例外）を一つの認証強度ポリシーで統合管理する設計が肝になります。
• フィッシングやAiTMの効き目を弱める反面、「方法の悪用による横取り（Account Manipulation）」や「回復フローの例外の濫用」という新しい攻撃仮説に備える必要があります。
• 現場では年末〜Q1のパイロットで、Conditional AccessのAuthentication Strengthsや“方法の追加”監査、SMS/メール回復の段階的停止を計画し、ヘルプデスク運用を同時に更新するのが現実的です。
• 公開プレビューゆえ仕様変動の可能性は高いですが、短期での実装可能性と運用効果は高く、規制や社内監査の観点でも早期の設計方針確立が有効です。

はじめに

MicrosoftがEntra IDで「同期パスキー」と「生体認証」を用いたアカウント回復を公開プレビューに進めました。これは単なるMFAの追加ではなく、長年の弱点だった回復フロー（忘却・紛失・端末交換などのライフサイクルイベント）を、パスワードやSMS/メールからFIDOベースへと置き換える試みです。回復の成功率やユーザー体験の改善はもちろん、フィッシング耐性の向上というセキュリティ上の質的な転換点でもあります。

一方で、回復は例外経路になりがちで、条件付きアクセスやアイデンティティ保護の網から外れやすい領域です。今回の動きは、その「例外を例外のまま放置しない」方向に進める好機です。公開プレビュー段階であることを前提に、脅威モデルの更新と運用設計の再点検を並走させることが重要です。

参考（報道）:

• Microsoft Entra: Synced passkeys, biometric account recovery reach public preview（Biometric Update）

深掘り詳細

事実関係（公開情報の整理）

• Microsoft Entra IDのアカウント回復に対し、FIDOベースの多要素認証を使える公開プレビューが開始されています。ユーザーは端末のPIN、生体（顔・指紋）などと組み合わせて回復を完了できる構成です。
• 認証強度の高い手段を回復フローに持ち込むことで、従来手段より回復の成功率・利便性が大きく改善する、という主旨が報じられています。
• 「同期パスキー」はエンドユーザーの利用体験を底上げする方向性で、複数デバイスを跨いだ回復・再認証の円滑化にフォーカスしていると読み取れます。
• 上記は公開プレビューの段階であり、仕様やサポート対象、制御可能なポリシーの粒度が今後変化する可能性がある前提です。
• 出所はいずれも上記報道に基づくもので、公式ドキュメントやGA発表に先立つフェーズの情報です。

出典: 前掲のBiometric Update記事

インサイト（運用・アーキテクチャの示唆）

• 回復フローの再設計は「例外の標準化」です。登録・回復・再登録（紛失・機種変更時）・ヘルプデスク例外の全入口を、Authentication Strengths（FIDO/パスキー優先）で統一し、SMS/メールを段階的に閉じる設計が鍵になります。これにより、攻撃者が狙いやすい弱い回復チャネルが残置されるリスクを最小化できます。
• 同期パスキーは「利便性と境界管理のトレードオフ」です。複数デバイスでの回復成功率やSaaS横断の体験は改善しますが、企業境界の外（個人領域や別アカウント）に同期の足場があると、ポリシーが及ばない領域が生じうる懸念があります。高権限ロールは「デバイスに束縛されたFIDO2（セキュリティキーや端末内蔵でのデバイスバウンド）」を原則とし、一般ユーザーには同期パスキーの利便を許容する、といった差分ポリシーが現実的です。
• 「方法の追加」が新たな要注意点です。回復に成功したアクター（正規・不正を問わず）が、別デバイスのパスキーを追加して将来的な乗っ取りの足場を作る、というシナリオに備えて、再登録・方法追加には高強度のステップアップを強制し、監査・アラートを必須化するのが望ましいです。
• フィッシング耐性の改善は運用面でも波及します。AiTMやOTP疲労（プッシュ通知攻撃）への曝露は相対的に下がるため、ヘルプデスクの負荷・ユーザーの混乱・誤認可を低減できます。逆に、端末紛失・共有端末・カスケード同期（個人→業務）のガバナンス課題は前景化します。
• 公開プレビューの間に「ブートストラップ戦略」を見直すべきです。初回登録・再取得・回復の各フェーズで、暫定コードや一時的手段をどこまで許容し、どの時点までにFIDO/パスキーへ“昇格”させるのかを、ポリシーで明文化し自動化する準備が重要です。

脅威シナリオと影響

以下は公開プレビュー情報を踏まえた仮説ベースの脅威モデルです。MITRE ATT&CKのIDは代表例であり、実装詳細や運用によって変動します。

• シナリオ1：回復フローの例外からの横取り

  • 仮説: 依然として残る弱い回復手段（SMS/メール等）が一部ユーザーやロールで許可されている場合、攻撃者がそこを足掛かりにパスキーを新規追加して持続化を確立。
  • ATT&CK: T1098 Account Manipulation（認証方法の追加/変更）、T1078 Valid Accounts、T1111 Two-Factor Authentication Interception（弱い二要素の悪用）
  • 影響: フィッシング耐性が高いパスキー環境でも、回復の例外が残っていれば全体の安全性は下振れします。

• シナリオ2：端末盗難・一時的占有からの「方法追加」

  • 仮説: 署名済みのセッションやロック解除済み端末の短時間占有で、攻撃者が回復・再登録フローへ進みパスキーを追加。
  • ATT&CK: T1098 Account Manipulation、T1078 Valid Accounts
  • 影響: 端末側ローカルの生体/PINゲートと、再登録に求める組織側のステップアップ強度の両輪が必要です。

• シナリオ3：同期パスキーの境界逸脱

  • 仮説: 同期の前提となるアカウントやストアの境界が個人/業務で混在し、業務アカウントの回復要素が管理外デバイスへ波及。
  • ATT&CK: T1555 Credentials from Password Stores（ストア/同期の悪用、概念的）、T1562 Impair Defenses（管理境界の回避）
  • 影響: BYODやハイブリッド勤務で、資産境界・台帳・オフボーディング手順の重要性が増します。

• シナリオ4：ヘルプデスク例外の濫用

  • 仮説: 本人確認が曖昧なヘルプデスクの例外プロセスで、攻撃者が暫定手段を取得し、その後パスキーを登録して持続化。
  • ATT&CK: T1098 Account Manipulation、T1136 Create Account（場合によっては新規アカウント付与）
  • 影響: オンボーディング/回復/例外の審査強度を統一し、ロールベースで罰則付きの逸脱抑止を敷く必要があります。

• シナリオ5：AiTMを困難化する正の側面

  • 仮説: パスキー/生体を回復フローに持ち込むことで、T1557 Man-in-the-Middle（AiTM）やOTP疲労の効き目が低下。
  • 影響: フィッシング由来の侵害確率を下げられる一方、攻撃者は「方法の追加」や「境界の混線」に戦術をシフトする可能性が高いです。

総じて、攻撃者は「回復・再登録」というシステム最小公倍数の入口へ寄ってきます。フィッシング耐性の獲得による利得は大きい一方、その利得を打ち消す“例外経路”を残さない設計と監査がカギになります。

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

公開プレビュー段階であっても、設計原則の確立とパイロットは進められます。以下は実務を前提とした推奨アクションです。

• ガバナンスとポリシー

  • 回復・再登録・初回登録の各フローに対し、Authentication StrengthsでFIDO/パスキー優先を明文化し、SMS/メールなど弱い手段は段階的に無効化します。
  • 高権限ロール（特権管理者、開発者、高価値ターゲット）は「デバイスバウンドFIDO2」を原則化し、同期パスキーは原則不可も検討します。
  • 「方法の追加/削除」は常に高強度ステップアップを要求し、業務時間外・ジオロケーション・デバイスコンプライアンスで制約します。

• 運用と監査

  • 監査ログで「認証方法の追加・更新・削除」「回復フロー開始/完了」「登録キャンペーン進捗」を継続監視し、しきい値超過で自動アラートを発火します。
  • ヘルプデスクの例外発行はチケット必須・二名承認・期限付き・最小権限で統制し、例外後は必ずパスキーへ昇格させる再登録ウィンドウを設けます。
  • 端末紛失・盗難の標準手順（リモートワイプ、セッション無効化、方法の強制再登録）をユーザー教育とセットで定着させます。

• 技術的コントロール

  • 条件付きアクセスで回復・登録ポータルを対象に強制ポリシーを適用し、例外のバイパスを禁じます。
  • ハイリスクユーザー/サインインには回復・登録へのアクセス自体を一時停止するガードレールを設定します。
  • ブレイクグラスアカウントを最小数で用意し、保管・利用手順と監査を厳格化します（通常運用での使用禁止、定期演習）。

• 人とプロセス

  • 通信手段の切替（SMS/メール回復の停止）に伴うユーザー教育を前倒しで実施し、端末のロックスクリーン強化（PIN/生体）を徹底します。
  • 回復成功後に必ず「方法の棚卸し（不要な方法の削除）」を促すナッジを実装し、長期的な方法スプロールを防止します。
  • レッドチーム/テーブルトップ演習で「方法追加の悪用」「ヘルプデスク例外の突破」「端末占有時の再登録」シナリオを検証します。

• ロードマップ（例）

  • 0〜30日: パイロットテナントで公開プレビューを検証、ログ観測とアラート設計、ヘルプデスク手順のドラフト化。
  • 30〜90日: 一般ユーザーの限定グループへ展開、SMS/メール回復の段階的停止を開始、特権ロールはデバイスバウンドへ切替。
  • 90日以降: 全社展開と監査定着、方法のライフサイクル（追加・棚卸し・撤去）を運用KPIに組み込みます。

参考情報

• Microsoft Entra: Synced passkeys, biometric account recovery reach public preview（Biometric Update）

注: 本稿は公開プレビュー段階の報道に基づく分析です。実装範囲やポリシー制御は正式リリースで変更される可能性があるため、最新ドキュメントでの確認を前提に設計・評価を進めることを推奨します。