Azure から「2025年10月1日までにテナントで多要素認証 (MFA) を有効化せよ」というメッセージを受け取ると、多くの管理者は「何から手を付ければいいのか」「既存スクリプトは止まらないか」「延期できるのか」が気になるところです。本記事では、この通知の正体と影響範囲、Azure Policy の監査／強制モードの使い分け、そしてどうしても間に合わないときの延期方法まで、実務レベルで整理して解説します。
Azure「2025年10月1日までに MFA を有効化」通知の正体
今回の通知は、Azure が段階的に進めている「管理操作に対する多要素認証の義務化（Mandatory MFA）」の Phase 2（第2フェーズ） に関する案内です。2025年10月1日以降、Azure リソースの作成・更新・削除といった管理 API（Azure Resource Manager）経由の操作では、ユーザーが MFA を完了していない場合、操作がブロックされるようになります。
この強制は一斉にではなく、Azure Policy を用いてテナント単位で段階的に適用されます。そのため「10月1日になった瞬間にすべて止まる」わけではありませんが、通知が届いたテナントは確実に対象と考えて準備を進める必要があります。
Phase 1 と Phase 2 の違いを整理
すでに 2024 年～2025 年にかけて、Azure ポータルなど管理ポータルへのサインインでは MFA が事実上必須になっています（Phase 1）。Phase 2 では、この対象が Azure CLI や PowerShell、IaC ツールなど「ポータル以外のあらゆる管理クライアント」に広がる点がポイントです。
| 項目 | Phase 1 | Phase 2（今回の通知） |
|---|---|---|
| 対象開始時期 | 2024 年後半〜2025 年前半 | 2025 年 10 月 1 日から段階的に適用 |
| 主な対象アプリ | Azure ポータル、Entra 管理センター、Intune 管理センター、Microsoft 365 管理センター など | Azure CLI、Azure PowerShell、Azure モバイルアプリ、IaC ツール、Azure 管理 REST API など |
| 保護する対象 | 管理ポータルへのサインイン全般（CRUD） | Azure Resource Manager 経由の Create / Update / Delete 操作 |
| 影響を受けるアカウント | 主にポータルを使う管理者・運用担当 | CLI／PowerShell／SDK／自動化スクリプトで管理操作を行うユーザー全般 |
| 自動化・サービス プリンシパル | 基本的に影響なし | マネージド ID / サービス プリンシパルは継続利用可。 ユーザー アカウントで動かしている自動化は見直し必須 |
どの操作が MFA 必須になるのか
Phase 2 では、対象クライアントから Azure Resource Manager に対して Create / Update / Delete 操作を行う際に、ユーザーが MFA を完了していなければリクエストがブロックされます。読み取り専用の Read 操作は原則として MFA 必須ではありません。
| クライアント／ツール | 例 | MFA 必須となるケース |
|---|---|---|
| Azure ポータル | ブラウザからのポータル操作 | サインイン時点で Phase 1 により基本的に MFA 必須 |
| Azure CLI | az group create、az vm delete など | リソース作成・変更・削除コマンド実行時（ユーザーでログインしている場合） |
| Azure PowerShell (Az モジュール) | New-AzResourceGroup、Remove-AzVM など | Create／Update／Delete 系コマンド実行時 |
| IaC ツール | Terraform, Bicep, ARM テンプレート など | ユーザー アカウントで az login / Connect-AzAccount して apply する場合 |
| SDK / REST API | Azure SDK (Python / .NET / Java など)、REST API 呼び出し | ユーザー認証トークンを使ってリソース変更を実行する場合 |
| モバイルアプリ | Azure モバイルアプリ | アプリからリソース作成・変更を行うとき |
ここで重要なのは、「ユーザー アカウントで自動化しているスクリプト」がすべて見直し対象になる、という点です。正式なサービス プリンシパルやマネージド ID を使っていれば、今回の MFA 強制の対象外として継続利用できますが、「昔からのバッチがユーザー ID＋パスワードで動いている」といったパターンは、必ず洗い出して移行しましょう。
対応の全体像：やるべきことは大きく 4 つ
Azure からの通知を受けてテナント管理者がやるべきことは、ざっくり次の 4 つに整理できます。
- MFA の有効化方針を決め、対象ユーザーに展開する（セキュリティ既定値 or 条件付きアクセス）
- Azure Policy の「監査モード」で影響範囲を見える化する
- ツール・スクリプトのバージョンや認証方式をアップデートする
- どうしても期限に間に合わない場合は、ポータルから一度だけ延期を申請する
以下では、それぞれを詳しく見ていきます。
MFA の有効化：セキュリティ既定値と条件付きアクセスの選び方
MFA を有効化する代表的な手段は次の 2 つです。
- セキュリティ既定値 (Security Defaults) – 無償で簡単にオンにできる一括設定
- 条件付きアクセス ポリシー – ライセンス (Entra ID P1/P2) 前提の高機能な制御
どちらを使っても、Azure の Mandatory MFA (Phase 2) 要件は満たせますが、運用や要件に応じて適切な方を選ぶ必要があります。
セキュリティ既定値の特徴
- Entra ID Free を含むすべてのテナントで利用可能
- 有効化すると、すべてのユーザーに MFA 登録と MFA 利用が求められる
- 管理者ロールに対しては、より強い基準で MFA を要求
- 細かい条件（IP アドレス、デバイス状態、アプリごとの制御など）は指定不可
「とにかくまだ MFA をまったく入れていない小規模テナント」や、「まずは全員に MFA を強制したい」という場合は、セキュリティ既定値を有効化するだけでも大きな防御力向上が期待できます。
条件付きアクセス ポリシーの特徴
- Entra ID Premium P1 以上のライセンスが必要
- 対象ユーザー／グループ、ロール、場所 (IP / 国)、デバイス状態、アプリごとにきめ細かく制御
- 「Azure 管理操作のみ MFA 必須」「特定ネットワークからのアクセスは MFA 免除」など柔軟な設計が可能
- テンプレート「Require MFA for Azure management」などを使って素早く導入できる
既に条件付きアクセスを使っている組織では、テンプレートベースのポリシーを利用して「Azure 管理操作向け MFA ポリシー」を構成するのが最もスムーズです。
選び方の目安（小～中規模組織／大規模組織）
| 組織規模・要件 | おすすめアプローチ |
|---|---|
| 小規模（〜数十ユーザー）、Entra ID Free のみ | セキュリティ既定値で全ユーザーに MFA を一括適用 |
| 中規模、管理者だけ厳格に / 社外ユーザーも混在 | 条件付きアクセスで「管理者＋開発者」向けに MFA を段階導入 |
| 大規模（数百〜数万ユーザー）、複数ネットワーク／デバイス管理あり | 条件付きアクセスで ・全ユーザー向けベースライン MFA ポリシー ・Azure 管理操作向けの専用ポリシー を分けて設計 |
Azure Policy で「監査」と「強制」を切り替える方法
Azure の MFA 強制は Azure Policy を通じて実施されるため、同じく Azure Policy を使って自分たちで先行的に監査・強制を行うことができます。Microsoft は「まず Audit（監査）モードで適用し、問題がないことを確認してから Enforce（強制）モードへ移行する」ことを推奨しています。
組み込みポリシーの例
通知メールやドキュメントでは、次のような組み込みポリシー定義を使うよう案内されています。
- Require multifactor authentication for resource management operations（リソース管理操作に MFA を要求）
- Require MFA for Azure management（条件付きアクセスと組み合わせるテンプレート）
これらのポリシーを Management Group やサブスクリプション単位で割り当てることで、テナント全体の MFA 対応状況を把握し、徐々に強制を高めていけます。
監査モード（Audit）での適用ステップ
- Azure ポータルで「Policy」を開き、「定義」から組み込みポリシーを検索
- 対象ポリシーを選び「割り当て」をクリック
- スコープとして「検証したい Management Group またはサブスクリプション」を指定
- ポリシーの効果 (Effect) を Audit に設定
- 割り当て後、ポリシーのコンプライアンス結果が集計されるのを待つ
監査モードでは、実際の操作はブロックされず、「MFA 不足の状態であれば将来ブロック対象になるリクエスト」がコンプライアンス違反としてレポートされます。
強制モード（Deny / Enforce）への移行ステップ
- 監査モードでのレポートを分析し、影響度の高いサブスクリプション／リソースグループを把握する
- 影響の小さい検証用サブスクリプションから、ポリシーを Deny（または Enforce）に切り替える
- 運用チーム・開発チームに「このサブスクリプションは MFA 未実施の操作がブロックされる」ことを周知
- 一定期間運用し、問題がなければ、徐々に本番サブスクリプションへも適用範囲を広げる
このように、Azure Policy を「予行演習」と「段階ロールアウト」の両方に活用することで、2025年10月1日の本番強制に先駆けて、テナントごとの最適なタイミングで準備を進められます。
ツール・スクリプトのバージョン要件と確認ポイント
Mandatory MFA が有効になると、古いバージョンの Azure CLI や Azure PowerShell を使っている場合、エラーメッセージが分かりづらい・MFA チャレンジが正しく処理できないなどの問題が発生する可能性があります。Microsoft は次のバージョン以上を推奨しています。
| ツール | 推奨バージョン | 確認コマンド例 |
|---|---|---|
| Azure CLI | v2.76 以上 | az version |
| Azure PowerShell (Az モジュール) | v14.3 以上 | Get-InstalledModule Az |
| PowerShell 本体 | v7.4 以上（推奨） | $PSVersionTable.PSVersion |
特に Azure CLI 2.76 未満および Az 14.3 未満では、ポリシー違反時に「RequestDisallowedByPolicy」「MFA is required」などのエラーが出るものの、どのポリシーに引っかかっているのかが分かりにくいケースがあります。推奨バージョンに上げておけば、エラーメッセージに claims challenge 情報などが含まれ、トラブルシュートが容易になります。
スクリプト・パイプラインのチェック観点
- 対話ログインを前提にしていないか（例：
az loginを手動で打つ前提のスクリプト） - ユーザー ID＋パスワードの資格情報をハードコードしていないか
- サービス プリンシパル／マネージド ID を利用しているか
- パイプライン（GitHub Actions / Azure DevOps など）が、ユーザー アカウントではなくワークロード ID を使うよう設計されているか
自動化処理は基本的に ユーザー アカウントではなく、サービス プリンシパルやマネージド ID（ワークロード ID）に移行するのが推奨です。これらのワークロード ID は、今回の Mandatory MFA の対象外として扱われます。
どうしても期限までに準備できない場合の「延期オプション」
通知メールにも記載されている通り、グローバル管理者 (Global Administrator) は、Azure ポータルから一度だけ強制適用の延期を申請できます。延期を利用すると、テナントへの MFA 強制適用を 2026 年 7 月まで延長できます。
延期申請のイメージ
具体的な UI はテナントによって多少異なりますが、おおむね次のような流れです。
- グローバル管理者で Azure ポータルにサインインする
- ポータル上部に表示される通知バナー、またはメッセージセンターの該当メッセージを開く
- 「今すぐ準備する」「後で実施する」などの選択肢の中に、延期 (Postpone) オプションが表示される
- ガイドに従って確認を行い、延期を確定する
ポイントは、延期はあくまで一時的な猶予であり、最終的にはすべてのテナントが MFA 義務化の対象になるということです。延期中に十分な検証と移行を行い、猶予期間の終了前には自前で MFA 強制を完了させておくべきです。
延期を使うべきケースと使うべきでないケース
| ケース | 延期利用の是非 |
|---|---|
| ミッションクリティカルな自動化が多数あり、影響評価・改修に数か月以上かかる | 一時的な延期を検討する価値あり。ただしすぐに移行プロジェクトを立ち上げること |
| MFA 自体はほぼ導入済みで、CLI/PowerShell ユーザーも限定的 | 延期を使う必要性は低い。監査ポリシーで確認後、そのまま本番強制へ進めるのが良い |
| MFA の導入に社内抵抗があり、なるべく後ろ倒しにしたいだけ | セキュリティ観点からおすすめできない。フィッシング等のリスクを考えると早期導入が望ましい |
実践的な移行ロードマップ例
ここからは、実際のプロジェクトとして Mandatory MFA 対応を進める際のロードマップ例を示します。小～中規模組織であれば、以下の流れで進めるのが分かりやすいでしょう。
ステップ 1：現状把握（1〜2 週間）
- MFA 登録状況レポートやサインインログを確認し、「すでに MFA を使っているユーザー」「未登録ユーザー」を把握
- Azure CLI / PowerShell / IaC ツールを利用しているユーザー・チームを洗い出す
- 自動化スクリプト／パイプラインでユーザー アカウントを使っている箇所を棚卸し
この段階で「どのチームがどれだけ影響を受けるか」が見えるようになります。
ステップ 2：設計（1〜3 週間）
- MFA 方針を決める（セキュリティ既定値か、条件付きアクセスか、または両方か）
- 「Azure 管理者ロール／開発者ロール」に対する MFA 必須ポリシーを設計
- 例外（緊急用アカウント、特定のレガシー環境など）を最小限に絞る
- Azure Policy のスコープ（どの Management Group / サブスクリプションから監査・強制を始めるか）を決める
ステップ 3：パイロット導入（2〜4 週間）
- IT 部門・Azure 管理チームを対象に、MFA を完全必須にする
- 対象サブスクリプションに Azure Policy を Audit モードで割り当て、影響をモニタリング
- CLI/PowerShell ユーザーに対し、推奨バージョンへのアップデートを案内
- 自動化スクリプトの認証方式を、マネージド ID / サービス プリンシパルに切り替え
ステップ 4：全社ロールアウト（1〜3 か月）
- 開発チーム → 一般業務ユーザーの順に MFA を必須化
- Azure Policy の Enforce モードを、影響の小さいサブスクリプションから順次拡大
- コンプライアンス結果を Power BI やメール通知で共有し、未対応ユーザーや古いツール利用者にフォローをかける
ステップ 5：運用・最適化フェーズ
- 定期的に Azure Policy のコンプライアンス レポートを確認し、新たな違反傾向がないかチェック
- 新規プロジェクト・新規サブスクリプション作成時に、最初から MFA 前提のポリシー／パイプライン設計を標準化
- フィッシング耐性の高い MFA（FIDO2 セキュリティキー、パスキー、証明書ベース認証など）の採用も検討
ベストプラクティスまとめ
段階的ロールアウトと「 scream test 」
いきなり全テナントで強制モードにするのではなく、まずは 監査モード＋一部サブスクリプションでの強制 から始めるのが安全です。Azure Policy を使って「この設定で何が止まるのか」を事前にあぶり出す、いわゆる scream test（悲鳴テスト） を行うことで、本番影響を最小限に抑えられます。
認証方法を複数用意する
- Microsoft Authenticator アプリ（プッシュ通知 / 番号一致）
- FIDO2 セキュリティキー（パスキー含む）
- 証明書ベース認証 (CBA)
- SMS / 音声通話（可能なら優先度は下げる）
特に管理者や開発者は、スマートフォン紛失・機種変更などのリスクに備えて 複数の MFA 手段を登録しておくことが重要です。
運用手順書・教育の更新
- 新入社員オンボーディング手順に「アカウント発行と同時に MFA 登録」を組み込む
- スクリプト作成ガイドラインに「ユーザー認証を前提にしない」「ワークロード ID を使う」などの標準を明記
- 障害時対応手順に「MFA デバイス紛失時のリカバリー」「緊急用アカウントでのサインインフロー」を追記
よくある質問（FAQ）
Q1. 既に管理者全員に MFA を強制している。何か追加対応は必要？
A. 管理者のポータルサインインがすでに MFA 必須でも、CLI や PowerShell、スクリプト実行時の動きは別です。Azure Policy の監査モードを使って、Azure Resource Manager レベルの Create/Update/Delete 操作が MFA でカバーされているかどうかを確認することをおすすめします。
Q2. サービス プリンシパルやマネージド ID を使った自動化は止まる？
A. いいえ、ワークロード ID（マネージド ID / サービス プリンシパル）は今回の Mandatory MFA の対象外です。ただし、ユーザー アカウントをサービスアカウント代わりに使っている場合は、そのユーザーが MFA を完了していないと管理操作が止まります。自動化は可能な限りワークロード ID に移行しましょう。
Q3. サードパーティ IdP の MFA（SAML フェデレーション）でも要件を満たせる？
A. 適切に構成されていれば、Microsoft Entra はフェデレーション先 IdP で実施した MFA を信頼し、Mandatory MFA の要件を満たすことができます。IdP 側が MFA 実施を示すクレームを正しく付与しているか、Entra 側の設定がそれを受け入れる構成になっているかを確認してください。
Q4. 必須化の日にいきなり全員がロックアウトされることはある？
A. Mandatory MFA は Azure Policy を使い、テナントごとに段階的に有効化されます。そのため「日付が変わった瞬間に全ユーザーがログイン不能になる」ような挙動は想定されていません。ただし、通知後に何も対策を取らなければ、いつかは強制適用が始まり、そのタイミングで MFA 未設定ユーザーが管理操作を実行できなくなります。
Q5. どうしても MFA を入れたくないシステムが一部にある
A. セキュリティおよび Microsoft の方針上、「管理操作には MFA を」という流れを逆行させることは非常に難しいです。どうしても意図せず止まると困る場合は、延期オプションと Azure Policy の監査モードを最大限活用しつつ、そのシステムの認証方式をワークロード ID へ移行するなど、MFA を回避するのではなく「MFA しても問題が起きない設計」に寄せるのが現実的です。
まとめ：早めの準備で「何も起きない」状態を作る
2025 年 10 月 1 日から始まる Azure の Mandatory MFA Phase 2 は、「セキュリティ強化」という点では歓迎すべき施策ですが、準備を怠ると CLI や PowerShell、IaC ツール経由のデプロイが突然止まる、といったインシデントを招きかねません。
しかしながら、やるべきことはシンプルです。
- MFA をテナント標準として導入し、管理者・開発者・運用担当に確実に行き渡らせる
- Azure Policy の監査モードで影響範囲を把握し、段階的に強制モードへ移行する
- 自動化はユーザーではなくワークロード ID に寄せ、推奨バージョンのツールを使う
- どうしても間に合わない場合は、一度だけ利用できる延期オプションで時間を稼ぐ
これらを計画的に進めておけば、2025 年 10 月 1 日を迎えても「特に何も起きない」状態を作ることができます。今のうちにテナントの現状を棚卸しし、MFA を前提とした Azure 管理運用へシフトしていきましょう。
コメント