Microsoft 365／Azure（Microsoft Entra ID）で「2 要素認証（2FA／MFA）の強制」が段階的に広がっています。本記事は“いつ・どこで・誰に”必須になるのかを最新の公式情報に基づいて整理し、現場でそのまま使える準備計画、ポリシー設計、移行チェックリスト、トラブル対処までを一気通貫で解説します。特に自動化・スクリプト・サービスアカウントの影響が大きいため、早めの設計見直しが肝要です。
目次
Microsoft 365／Azure における 2FA／MFA 強制適用ポリシー：要点サマリ
| ポイント | 内容 |
|---|---|
| 適用フェーズ | Phase 1（管理ポータル）： 2024 年 10 月以降、Azure portal／Entra 管理センター／Intune 管理センターのサインインに MFA が段階的に必須化。 Microsoft 365 管理センターは 2025 年 2 月以降段階的に必須化。 Phase 2（CLI・API・自動化）： 2025 年 10 月 1 日以降、Azure CLI／Azure PowerShell／Azure モバイルアプリ／IaC ツール／REST API／SDK からの作成・更新・削除（CRUD）操作に MFA が順次必須化。読み取り（Read）のみは対象外。 |
| 誰が対象か | 上記アプリケーションで対象操作を行うすべてのユーザー（管理者・一般ユーザー・B2B ゲストを含む）。 Workload identity（マネージド ID／サービスプリンシパル等）は対象外。 |
| 強制時の挙動 | 未登録ユーザーはサインイン時に MFA 登録や「ステップアップ（claims challenge）」を求められ、完了するまで対象操作は実行できない（クライアントにより登録プロンプト or エラーのみの挙動あり）。 |
| 無効のまま維持できるか | 不可。テナントの条件付きアクセス例外や除外設定よりも強制適用が優先される。 |
| 猶予（延期） | Phase 1：テナント単位で2025 年 9 月 30 日まで開始時期を延期可能。 Phase 2：テナント単位で最長 2026 年 7 月 1 日まで開始時期を延期可能。 いずれも Entra 管理者が Azure ポータルの専用画面から申請・適用できる（後述）。 |
| 既に MFA 有効なアカウント | そのまま利用可。追加作業は基本不要。 |
| 推奨認証方法 | Microsoft Authenticator、Passkey（FIDO2）、証明書ベース認証（CBA）など。SMS／音声通話も可だが、可能ならなりすまし耐性（フィッシング耐性）の高い方法へ移行。 |
上記フェーズ・適用範囲は Microsoft Learn／公式ブログにて明示されています。特に Phase 2 は Azure Resource Manager 層の CRUD 操作が焦点で、読み取り専用は除外、Portal 以外のクライアント（CLI／PowerShell／API／IaC）へ拡張されます。Microsoft 365 管理センターの必須化は 2025 年 2 月から段階的に開始されています。
「よくある質問」への結論
| 質問 | 回答 |
|---|---|
| 2FA がすべてのアカウントで必須になるのか？ | 対象アプリ（Azure 管理ポータル群、Microsoft 365 管理センター、Azure CLI／PowerShell／REST API など）にサインインして対象操作（特に CRUD）を行うすべてのユーザーに必須。B2B ゲストも含まれる。Workload identity（マネージド ID／サービスプリンシパルなど）は対象外。 |
| 現在 2FA を無効にしているアカウントはどうなるのか？ | 強制適用後は登録／ステップアップが求められ、完了まで対象操作は不可。クライアントによっては登録プロンプトではなくエラーのみを返すため、事前に条件付きアクセスやセキュリティ既定値で MFA を満たす運用にしておくのが安全。 |
| 管理者が 2FA を無効のまま維持できるのか？ | 維持できない。強制適用はテナントの条件付きアクセスの除外・例外より優先される。緊急用（Break glass）アカウントも MFA 対応（Passkey／CBA など）が必要。 |
期限と延期（Grace）を正しく理解する
標準スケジュール（公式）
- Phase 1（2024 年 10 月〜）：Azure／Entra／Intune 管理センターのサインインで MFA 必須（世界中のテナントへ段階展開）。
Microsoft 365 管理センターは2025 年 2 月〜段階展開。 - Phase 2（2025 年 10 月 1 日〜）：Azure CLI／PowerShell／モバイルアプリ／IaC／REST API／SDK を介したCRUDに MFA を要求。Read のみは対象外。
延期（ポストポーン）オプション
- Phase 1：テナント単位で2025/09/30まで延期可（Azure ポータルの専用画面からグローバル管理者が設定）。
- Phase 2：テナント単位で2026/07/01まで延期可（同様に専用画面で設定）。
いずれも大規模・複雑環境や技術的制約がある場合の暫定措置であり、延期はリスクを伴います。できるだけ早期に自社側で MFA を「自主管理」できる体制（条件付きアクセス／セキュリティ既定値／認証強度）に寄せておくことが、ユーザー体験と監査の両面で有利です。
実務での影響ポイント（Azure／Microsoft 365）
対象アプリと開始時期
| アプリ／クライアント | 開始 | メモ |
|---|---|---|
| Azure portal／Entra／Intune 管理センター | 2024 年後半〜（段階展開） | Portal サインインで MFA 必須（CRUD）。 |
| Microsoft 365 管理センター | 2025 年 2 月〜（段階展開） | 管理ポータルへのアクセスに MFA 必須。 |
| Azure CLI／PowerShell／IaC／REST API／SDK | 2025 年 10 月 1 日〜 | CRUD 操作が対象。Read は非対象。クライアントによりプロンプト or エラーのみ。 |
アカウント種別の扱い
- ユーザー（人）アカウント：対象操作を行う場合は MFA 必須。B2B ゲストにも適用。
- Workload identity（マネージド ID／サービスプリンシパル）：対象外。自動化はユーザーアカウントからの移行推奨。
- Break glass（緊急）アカウント：MFA 対応必須。Passkey（FIDO2）や CBAの設定を推奨。
設計原則（ゼロトラスト観点）
- 「例外」前提ではなく「強度」前提：条件付きアクセスの「認証強度」を活用し、一般ユーザーは「MFA 強度」、管理系は「フィッシング耐性 MFA 強度」へ段階移行。
- ポータルも CLI も同一方針：Phase 2 では CLI／API 操作も強制対象。自動化は Workload identity 前提へ。
- 登録 UX の先回り：登録プロンプトや claims challenge による業務中断を避けるため、セキュリティ既定値や登録キャンペーンで事前に方法をセットアップさせる。
90 日ロードマップ（社内展開テンプレート）
Day 0–14：現状把握と最初の安全網
- Entra ID のサインインログで管理系アプリ（Azure／Entra／Intune／Microsoft 365 管理センター）へのアクセス主体と MFA 実施率を可視化。
- テナントのセキュリティ既定値を検討（小規模・シンプル環境向け）。既に条件付きアクセスがある場合は重複や競合を棚卸し。
- 緊急用アカウントに Passkey（FIDO2）／CBA を設定、復旧 Runbookに手順を追記。
Day 15–45：ポリシー設計と先行適用
- 条件付きアクセスで「管理プレーン（Azure 管理）」を対象に フィッシング耐性 MFA 強度を要求（対象：管理者＋運用担当、場所：社内外、除外：当面なし）。
- 一般ユーザーには「MFA 強度」を要求しつつ、登録を促すコミュニケーション（社内ポータル、メール、FAQ、動画）。
- パイロットグループでポータル／CLI／PowerShell／IaC 操作の互換性を検証。Azure CLI は 2.76 以上、Az PowerShell は 14.3 以上を推奨。
Day 46–75：自動化の近代化（最優先）
- ユーザー型サービスアカウントの廃止計画を立案。ワークロード ID（マネージド ID／サービスプリンシパル）へ移行。
- ROPC（ユーザー名＋パスワード直渡し）を使うコードを全面棚卸し。MSAL／Azure Identity の
UsernamePasswordCredential系は非推奨・互換に注意。 - Terraform／Bicep／GitHub Actions／Azure DevOps などのパイプラインでManaged IdentityやFederated Credentialを採用。
Day 76–90：全社展開とモニタリング
- 対象ユーザー範囲を全社へ拡大。ポータルと CLI 双方で「強制有効化後」の UX を実地確認。
- サインインログの「要求元」にアプリ側で MFA を強制した記録が残ることを監査で確認。
- ヘルプデスク用に「よくある失敗」と「一次切り分けフロー」を整備（下記参照）。
設定ガイド（代表例）
条件付きアクセス（管理プレーンを最優先に保護）
- 対象ユーザー：管理者ロール＋運用担当グループ（のちに全ユーザーへ拡大）
- 対象クラウドアプリ：Microsoft Azure 管理（ポータル／ARM 操作）
- アクセス制御：認証強度 = フィッシング耐性 MFA（FIDO2／WHfB／CBA 等）
- セッション：必要に応じてサインイン頻度（短め）／デバイス準拠チェックを併用
登録体験（中断を最小化）
- 登録はサインイン時に割り込み（Interrupt）で促される。事前周知と手順書で“その場完了”を狙う。
- 登録ウィザードは CA の要求（認証強度）に影響されるため、運用と UX が一致するよう一貫した設計に。
自動化・スクリプトの移行（重要）
Phase 2 の肝は「人が操作するポータル以外」の管理手段です。人ユーザーで az login／Connect-AzAccount し、そのままスクリプトを流す運用は原則不可に。以下の順で置き換えましょう。
- Managed Identity（最優先）：Azure リソース上の自動化は
az login --identity／Connect-AzAccount -Identityに切替。 - サービスプリンシパル：必要に応じてフェデレーション資格情報を利用し、シークレットレス運用へ。
- ユーザー名＋パスワード（ROPC）：MFA と非互換。MSAL／Azure Identity の UsernamePassword 系 API は非推奨・互換注意。発見したら即撤去。
トラブル対処・非常時対応
- 「登録できず業務停止」時の一時回避：グローバル管理者は Azure ポータルの専用画面からPhase 1／Phase 2 の開始日を一時延期できる（ただしリスク増）。再発防止として登録ガイドや端末整備を同時に進める。
- 「CLI／PowerShell が通らない」：推奨バージョン（CLI 2.76／Az 14.3 以上）へ更新。サインインがエラーのみで終わるクライアントもあるため、先に CA／既定値で MFA を満たす運用に。
- 「誰が強制したか分からない」：サインインログにアプリ側が MFA を要求した旨が出る。監査で根拠提示が可能。
ユーザー教育・コミュニケーション素材（使い回し OK）
- なぜ必要か：MFA はアカウント乗っ取りの 99% 超を防ぐ有効策。攻撃は「人」を狙う（押し売り承認／セッション乗っ取り等）。
- 何を準備するか：スマホに Microsoft Authenticator、可能なら FIDO2 パスキー（セキュリティキー）も配布。
- 登録の流れ：社内ポータルの「登録手順」ページ→サインイン→プロンプトに従い 2 種類以上を登録（紛失時の冗長化）。
- 困ったとき：デバイス故障はヘルプデスクで「一時アクセス パス（TAP）」や代替要素で復旧。
よくある落とし穴と回避策
- Per-user MFA と CA の併用ミス：古いユーザー単位の有効化が残ると UX が不安定に。条件付きアクセス＋認証強度に統一。
- 例外だらけ：Phase 以降は例外よりも強制が上位。最小化の原則で設計。
- ROPC の取り残し：アプリ／スクリプトに潜む
UsernamePassword系の資格情報は早期駆逐。 - Break glass の未対応：いざという時ほど MFA 必須。FIDO2／CBA を必ず登録。
「延長申請」は最後の手段――しかし手順は知っておく
緊急時は、グローバル管理者が Azure ポータルの専用画面（Phase 1：開始日選択、Phase 2：開始日選択）から延期を適用できます。Phase 1 は 2025/09/30 まで、Phase 2 は 2026/07/01 まで延長可能です。延期はセキュリティリスクが増すため、監査上の根拠（影響分析・改善計画・期限）を残し、可能な限り短期での収束を。
技術詳細メモ（開発・運用チーム向け）
- 認証強度：組み込み「MFA」「Passwordless MFA」「Phishing-resistant MFA」。高リスク資産は上位強度で保護。
- SDK／ライブラリ：ROPC 非互換。MSAL／Azure Identity の UsernamePassword 系 API は非推奨となっており、パスワード直渡しパターンは撤廃。
- クライアント相性：一部クライアントは claims challenge 表示のみ（自動プロンプトなし）。事前に CA／既定値で満たす設計が安定。
まとめ：MFA は「スイッチ」ではなく「プロジェクト」
今回の必須化は、単なる「ON／OFF 切替」ではなく、ID と運用のアップグレードを促すプロジェクトです。設計（認証強度）→登録（UX）→移行（Workload identity）→運用（監査・Runbook）の順で進めれば、Phase 2 までに“止まらない”安全な環境を実現できます。迷ったら、まずは管理プレーンの保護と自動化の近代化から着手しましょう。
付録：実装チェックリスト
- 管理プレーン（Azure 管理）に 認証強度：フィッシング耐性 MFA を要求した CA ポリシーがある
- 一般ユーザーに MFA 強度 を要求（登録キャンペーン／既定値で事前登録）
- Break glass に FIDO2／CBA を登録し、定期的に検証している
- ユーザー型サービスアカウントの洗い出し・停止計画・Workload identity への移行計画がある
- ROPC／UsernamePassword 系 API の撤廃が完了している（ソース検索・CI でゲート）
- Azure CLI／Az PowerShell の推奨バージョンで標準化されている
- ヘルプデスク向け Runbook（登録喪失・端末紛失・TAP 発行・延長手続き）を整備済み
- サインインログで「MFA 要求元（アプリ）」を監査できるビューを用意している
コメント