Microsoft Entra ID 外部MFAのGAは、サードパーティMFAをすでに導入している企業にとって「すぐ全面移行するべき」という意味ではありません。むしろ重要なのは、既存のMFA投資を生かしながら、条件付きアクセス、リスク評価、認証方法ポリシーを Microsoft Entra ID 側に集約しやすくなった点です。
2026年4月16日時点で確認すべき結論は明確です。External MFAは一般提供となり、従来の「external authentication methods」から「External Multifactor Authentication」に名称変更されました。これにより、組織は好みのMFAプロバイダーを使い続けながら、Microsoft Entra IDをID制御プレーンとして利用できます。一方、Custom Controlsは2026年9月30日に非推奨化される予定のため、既存のCustom Controls依存環境は移行計画が必要です。(Microsoft Learn)
Microsoft Entra ID 外部MFA GAで何が変わったのか
Microsoft Entra ID 外部MFAは、サードパーティMFAプロバイダーをMicrosoft Entra IDのMFA要件を満たす手段として利用できる仕組みです。Microsoftの説明では、外部MFAを使ってもMicrosoft Entra IDがすべてのサインインでポリシー評価、アクセス判断、リアルタイムの条件付きアクセス、サインインリスク評価を担います。(Microsoft Learn)
これは、IAMアーキテクトやセキュリティ責任者にとって大きな意味があります。従来は、サードパーティMFAを使うためにCustom Controlsや個別の認証フローに依存し、ポリシー設計が分断されやすい構成になりがちでした。外部MFAのGAにより、既存のMFAプロバイダーを残しながら、Microsoft Entra IDの認証方法ポリシーと条件付きアクセスを中心に据えた設計へ移行しやすくなります。
| 観点 | 従来のCustom Controls中心の設計 | 外部MFA GA後の設計 |
|---|---|---|
| 位置づけ | プレビュー機能としてのCustom Controlsに依存 | External MFAとして一般提供 |
| 管理場所 | 条件付きアクセス内のカスタム制御が中心 | 認証方法ポリシーで外部MFAを管理 |
| ポリシー評価 | 外部サービスへのリダイレクトを組み合わせる設計 | Entra IDがポリシー評価とアクセス判断を継続 |
| 移行リスク | Custom Controlsの廃止予定に影響される | 新規実装は外部MFAを前提に設計しやすい |
| コスト判断 | Microsoft側と外部MFA側で重複投資が見えにくい | ユーザー群ごとに外部MFA継続・縮小・置換を判断しやすい |
特に重要なのは、「サードパーティMFAを捨てるか、Microsoft MFAへ全面移行するか」という二択ではなくなったことです。外部MFAのGAにより、既存投資を残す領域とMicrosoft Entra IDネイティブ機能へ寄せる領域を分けて考えられます。
既存のサードパーティMFA投資をどう扱うべきか
外部MFA GA後の共存計画では、まず「どのユーザーに、なぜサードパーティMFAが必要なのか」を棚卸しする必要があります。契約が残っているから使い続ける、という理由だけでは弱くなります。逆に、規制対応、買収先の統合、ハードウェアトークン、特定地域の運用要件など、明確な理由があるなら外部MFAとして残す価値があります。
判断軸は次のように整理できます。
| 判断項目 | 外部MFAを残す判断になりやすいケース | EntraネイティブMFAへ寄せる判断になりやすいケース |
|---|---|---|
| 規制・監査要件 | 既存MFAプロバイダーが監査証跡や業界要件に組み込まれている | Microsoft Entra ID側のログと認証方法で監査要件を満たせる |
| ユーザー体験 | 全社で既存MFAアプリに慣れており、変更コストが高い | Microsoft Authenticatorやパスキーへの移行を進めたい |
| 契約・コスト | 長期契約、グローバル契約、M&Aでの暫定統合がある | 契約更新時にMFAライセンスを最適化したい |
| 高特権アクセス | 専用トークンや既存運用が厳格に定義されている | 認証強度、パスキー、FIDO2、証明書ベース認証を活用したい |
| 運用負荷 | 外部MFAのヘルプデスク体制が成熟している | MFA登録、復旧、条件付きアクセスをMicrosoft側に集約したい |
外部MFAは既存投資を延命するためだけの機能ではありません。複数のMFA基盤を抱えたグローバル企業が、買収先や地域会社を段階的に統合するための「移行ブリッジ」としても使えます。
外部MFAの仕組みをIAM設計の観点で理解する
外部MFAはOpenID Connect（OIDC）をベースに実装されます。ユーザーが最初の要素でMicrosoft Entra IDにサインインし、条件付きアクセスなどによって追加要素が必要と判断されると、ユーザーは外部MFAプロバイダーへリダイレクトされます。その後、外部MFAプロバイダーで認証が完了し、Microsoft Entra IDが返却されたトークンを検証してMFA要件を満たしたか判断します。(Microsoft Learn)
設計上のポイントは、外部MFAプロバイダーが「認証体験の一部」を担い、最終的なポリシー評価とアクセス判断はMicrosoft Entra IDが担うことです。これにより、外部MFAを使いながらも、条件付きアクセスを中心にしたゼロトラスト設計を維持しやすくなります。
ただし、外部MFAを導入すればすべての認証要件を満たせるわけではありません。Microsoftのドキュメントでは、外部MFAメソッドは現時点で認証強度に対応していないとされています。高特権管理者、PIM、機密アプリ、フィッシング耐性MFAを求めるポリシーでは、FIDO2セキュリティキー、パスキー、証明書ベース認証など、別の方法を組み合わせて検討する必要があります。(Microsoft Learn)
共存計画は3パターンで考える
サードパーティMFA投資がある組織では、全社一律の移行計画にすると失敗しやすくなります。ユーザー群やアプリのリスクに応じて、次の3パターンを使い分けるのが現実的です。
既存MFAを主力として残すパターン
規制、監査、ハードウェアトークン、現場運用の都合で既存MFAを継続する場合は、外部MFAを正式な認証方法として登録し、Microsoft Entra IDの条件付きアクセスでMFAを要求する設計にします。
このパターンでは、MFA体験は大きく変えず、ポリシー評価とアクセス制御をEntra ID側に寄せられます。グローバル企業で地域ごとに既存MFAが深く定着している場合や、買収直後で認証基盤を急に統一できない場合に向いています。
注意点は、外部MFAの対象グループを明確にすることです。全社に一気に有効化するのではなく、部門、地域、雇用形態、アプリ種別でスコープを分けるべきです。
外部MFAとEntraネイティブMFAを併用するパターン
一般ユーザーは既存の外部MFAを使い、高特権管理者や機密アプリはMicrosoft Entra IDネイティブの強力な認証方法を使う設計です。
たとえば、一般業務アプリは外部MFAで保護し、管理ポータル、クラウド管理者ロール、財務システムなどはフィッシング耐性のある認証方式に寄せる、といった分け方が考えられます。
このパターンは、セキュリティ強度と移行コストのバランスを取りやすい一方、ユーザーごとの認証方法が複雑になりやすい点に注意が必要です。ヘルプデスク向けに「誰がどの認証方法を使うのか」を一覧化しておかないと、障害時の切り分けに時間がかかります。
EntraネイティブMFAへ段階移行するパターン
外部MFAは移行期間のブリッジとして使い、契約更新や端末刷新のタイミングでMicrosoft Entra IDネイティブの認証方法へ段階的に寄せるパターンです。
この場合、外部MFAを有効化すること自体がゴールではありません。ユーザー群ごとに「残す」「置き換える」「一時的に併用する」を決め、コスト削減と運用簡素化の効果を測定します。
重要なのは、MFAプロバイダーのライセンス費だけで判断しないことです。登録支援、端末変更時の復旧、ヘルプデスク対応、監査ログの確認、条件付きアクセスのテスト工数まで含めて比較する必要があります。
Custom Controlsから外部MFAへ移行する実務手順
Custom Controlsは外部MFAに置き換えられる位置づけであり、新規実装では外部MFAを使うべきとMicrosoftは案内しています。既存のCustom Controlsは移行期間中は動作するものの、2026年9月30日に非推奨化される予定です。(Microsoft Learn)
移行は、次の順番で進めるとリスクを抑えられます。
| 手順 | 実施内容 | 失敗しやすいポイント |
|---|---|---|
| 現状棚卸し | Custom Controlsを使う条件付きアクセス、対象アプリ、対象グループ、除外ユーザーを洗い出す | 例外設定や緊急アクセスアカウントを見落とす |
| プロバイダー確認 | 外部MFA対応状況、OIDC設定、必要なメタデータ、サポート範囲を確認する | 「サードパーティMFAなら何でも使える」と誤解する |
| パイロット設計 | IT部門、限定部門、地域会社など小さなグループから開始する | 既存Custom Controlsと同じユーザーに重ねて適用する |
| 外部MFA登録 | Entra管理センターの認証方法ポリシーで外部MFAを追加する | 表示名やスコープ設計を後から直しにくい形にする |
| 条件付きアクセス調整 | MFA要求ポリシーと対象グループを整理する | Custom ControlsとMFA要求を同一ユーザーに二重適用する |
| 動作検証 | ブラウザー、モバイル、デスクトップアプリ、管理者操作、回復手順を確認する | 通常サインインだけ確認して本番展開する |
| 段階展開 | 部門・地域・アプリ単位で広げる | ヘルプデスクとユーザー周知が追いつかない |
| Custom Controls撤去 | 移行完了後、Custom Controls依存ポリシーを削除・無効化する | 古いポリシーが残り、予期しないリダイレクトが発生する |
Microsoft Learnでは、外部MFAを構成する際にApplication ID、Client ID、Discovery URLなどのメタデータが必要と説明されています。また、管理者同意には十分な権限が必要で、同意がない状態では外部MFAを使ったサインインが失敗します。(Microsoft Learn)
条件付きアクセス設計で避けるべき落とし穴
外部MFAのGA後も、条件付きアクセス設計を雑にするとユーザー体験とセキュリティの両方が悪化します。特に注意すべきなのは、Custom Controlsと外部MFAを同じユーザーに同時適用しないことです。
Microsoftは、外部MFAとCustom Controlsを並行運用する場合、テストグループを分けることを推奨しています。同一ユーザーが両方のポリシーに含まれると、MFAを満たしたうえでCustom Controlも満たす必要があり、外部プロバイダーへ二度リダイレクトされる可能性があります。(Microsoft Learn)
また、サインイン頻度ポリシーを厳しくしすぎると、ユーザーが頻繁なMFAプロンプトに慣れてしまい、承認疲れやフィッシング耐性の低下につながります。外部MFAを導入する際は、「どれだけ頻繁にMFAを出すか」ではなく、「どのリスク条件で再認証を求めるか」を設計することが重要です。(TECHCOMMUNITY.MICROSOFT.COM)
実務では、次のように分けると設計しやすくなります。
| 対象 | 推奨する考え方 |
|---|---|
| 一般ユーザー | 外部MFAまたはMicrosoft Authenticatorを業務要件に応じて選択 |
| 高特権管理者 | 認証強度やフィッシング耐性を優先し、外部MFAだけに依存しない |
| ゲスト・買収先ユーザー | 既存MFAを活用しつつ、段階的にEntra側ポリシーへ統合 |
| 緊急アクセスアカウント | 外部MFA障害時も含め、別管理のブレークグラス設計を維持 |
| レガシー端末・特殊端末 | OOBE、登録、端末参加など通常サインイン以外のフローを個別検証 |
Windows 10のデバイスセットアップでは、外部MFAのみのIDを使ったOut-of-Box Experienceで問題が発生する可能性があり、MicrosoftはWindows 11へのアップグレードを案内しています。端末展開やAutopilot周辺で外部MFAを使う場合は、通常のWebサインインだけでなくデバイス初期設定も検証対象に入れるべきです。(Microsoft Learn)
コスト最適化は「MFAライセンス削減」だけで判断しない
外部MFAのGAは、コスト削減のきっかけになります。ただし、単純に「Microsoft 365にMFAがあるからサードパーティMFAを解約する」と考えると失敗します。
見るべきコストは少なくとも4種類あります。
| コスト項目 | 確認すべき内容 |
|---|---|
| ライセンス費 | 外部MFAプロバイダー、Microsoft Entra ID関連ライセンス、条件付きアクセス利用条件 |
| 運用費 | ユーザー登録、端末変更、再登録、問い合わせ、監査対応 |
| 移行費 | ポリシー再設計、テスト、ユーザー教育、ヘルプデスク増員 |
| リスクコスト | 誤設定によるロックアウト、二重MFA、監査証跡不足、特権アカウント保護不足 |
コスト最適化の現実的な進め方は、全ユーザー一律ではなくユーザー群ごとの整理です。
- 標準ユーザーはMicrosoft Entra IDネイティブMFAへ寄せられるか確認する
- 特定業務、規制対象、海外拠点、買収先は外部MFAを継続する
- 高特権ユーザーは外部MFAではなく認証強度やフィッシング耐性を重視する
- 契約更新月に合わせて外部MFAの対象ユーザー数を段階的に見直す
- ヘルプデスク工数と監査対応工数を含めた総コストで比較する
外部MFAの価値は、既存MFAを残せることだけではありません。不要な二重投資を可視化し、「残すべき外部MFA」と「Microsoft Entra IDへ統合すべきMFA」を分けられる点にあります。
監査・運用で見落としやすいポイント
外部MFAを本番展開する前に、監査と運用の観点も確認が必要です。
まず、外部MFAを利用できるユーザーは、Microsoft Entra IDの認証方法登録レポートに含まれないと説明されています。つまり、既存のMFA登録状況レポートだけを見て「未登録」と判断すると、実態とずれる可能性があります。(Microsoft Learn)
次に、ユーザー体験です。システム優先MFAが有効な場合、ユーザーに複数の認証方法があると、既定の順序で別の方法が表示されることがあります。外部MFAを使わせたいユーザーに対しては、対象グループ、登録手順、案内文を整備しておかないと、「どの方法を選べばよいか分からない」という問い合わせが増えます。(Microsoft Learn)
さらに、OIDCメタデータや証明書ロールオーバーも重要です。Microsoftの外部MFAプロバイダー向けドキュメントでは、メタデータやキーがキャッシュされること、キー更新時には既存証明書と新証明書を一定期間並行して公開することが推奨されています。IAMアーキテクトは、外部MFAプロバイダー側の証明書更新手順を変更管理に組み込むべきです。(Microsoft Learn)
外部MFA移行で使えるチェックリスト
本番移行前には、次のチェックリストを使って抜け漏れを確認してください。
| チェック項目 | 確認内容 |
|---|---|
| Custom Controlsの利用有無 | 条件付きアクセスポリシー内でCustom Controlsを使っているか |
| 対象ユーザー | 部門、地域、雇用形態、ゲスト、管理者を分けて定義しているか |
| 外部MFA対応 | プロバイダーがMicrosoft Entra ID External MFAに対応しているか |
| OIDC設定 | Discovery URL、Client ID、Application ID、証明書更新手順を確認したか |
| 管理者同意 | 必要な権限を持つ管理者が同意を付与できるか |
| 条件付きアクセス | Custom Controlsと外部MFAを同一ユーザーに二重適用していないか |
| 認証強度 | 高リスク・高特権アプリで外部MFAだけに依存していないか |
| ユーザー登録 | Security infoでの登録手順、ヘルプデスク手順を用意したか |
| レポート | 外部MFA利用者の登録・利用状況をどう監査するか決めたか |
| 端末フロー | Windowsセットアップ、モバイル、VDI、レガシーアプリを検証したか |
| ロールバック | 外部MFA障害時の代替手段と緊急アクセス手順を用意したか |
| コスト | 契約更新、対象ユーザー数、運用工数を含めて比較したか |
このチェックリストで特に優先すべきなのは、Custom Controlsの棚卸し、認証強度の確認、外部MFA対象グループの分離です。ここを曖昧にしたまま進めると、移行後に二重MFA、アクセス不能、監査レポートの不整合が起きやすくなります。
セキュリティ責任者が取るべき次のアクション
セキュリティ責任者やIAMアーキテクトは、外部MFA GAを単なる新機能として扱うのではなく、MFA戦略を見直すタイミングとして使うべきです。
まず、Custom Controlsを利用している条件付きアクセスポリシーを洗い出します。次に、サードパーティMFAを使う理由を「契約」「規制」「ユーザー体験」「技術要件」「移行猶予」に分類します。そのうえで、外部MFAとして残すユーザー群、EntraネイティブMFAへ寄せるユーザー群、高保証認証へ引き上げるユーザー群を分けます。
短期的には、外部MFAを小さなパイロットグループで有効化し、既存Custom Controlsと重ならない条件付きアクセスポリシーで検証します。中期的には、2026年9月30日のCustom Controls非推奨化を見据えて、移行スケジュール、ユーザー周知、ヘルプデスク手順、ロールバック計画を整備します。
Microsoft Entra ID 外部MFAのGAは、既存のサードパーティMFA投資を無駄にしないための選択肢です。ただし、最終的な価値は「外部MFAを有効化したか」ではなく、MFAの共存、移行、コスト最適化をどこまで設計できたかで決まります。まずはCustom Controlsの利用状況とMFAライセンスの棚卸しから始め、対象ユーザーを分けたパイロット移行に進むのが現実的です。
コメント