最近「MFA を有効化してください」というメールやポータルの警告が一斉に届き、「うちはもう管理者に MFA を強制しているのに…」と戸惑っている管理者は多いと思います。本記事では、この通知の正体と 2025 年 10 月 1 日から始まる Azure Mandatory MFA の内容を整理し、「何もしなくてよいテナント」と「今すぐ対応が必要なテナント」を具体的に見分ける方法を解説します。
「MFA を有効化してください」通知の正体
問題の通知は、多くの場合「Action required: Enable multifactor authentication for your tenant by 1 October 2025」「テナントで MFA を有効にしてください」といった件名で、テナントのグローバル管理者宛てに届きます。これは、Azure での Mandatory MFA（多要素認証の必須化）を前にした一斉リマインドです。
Microsoft の公式ドキュメントでは、Azure 全体でのサインインに対し MFA を必須化する方針と、その段階的なロールアウトが明記されています。 また Microsoft Q&A では、実際にこのメールを受け取った管理者に対し、以下のような回答が出ています。
- 2025 年 10 月 1 日より、Azure CLI / Azure PowerShell / Azure モバイルアプリ / IaC ツール / Azure Resource Manager REST API などでリソースの作成・更新・削除 (CRUD) を行う操作に MFA が必須になる。
- この案内メールは 全テナントのグローバル管理者 に送られるもので、MFA 設定の有無にかかわらず届く。
- すでに管理者に対し MFA を設定済みなら、メール自体は無視しても問題ない。
つまり、この通知が届いた＝テナントで MFA が無効という意味ではありません。あくまで「Mandatory MFA 施行前に、必ず MFA 設定を確認しておいてください」という全テナント共通のリマインドです。
通知に書かれている内容と本当の意味
| 通知の文言 | 実際の意味 | 管理者がやるべきこと |
|---|---|---|
| Enable multifactor authentication for your tenant by 1 October 2025 | 2025/10/1 以降、Azure リソース管理操作に MFA が必須になるので、それまでに環境を整えておいてくださいという案内 | すでに Azure 管理に関わるユーザーへ MFA を強制しているか確認する |
| Users will be required to sign in using MFA before performing any resource management actions | Azure CLI / PowerShell / REST API などで Create/Update/Delete を行うユーザーは MFA 必須になる | これらのツールを使うユーザーやスクリプトを洗い出し、MFA またはワークロード ID へ移行する |
| If you have already set up MFA for your admin accounts, you can ignore this message | 管理者アカウントが MFA で保護されていれば、追加で「申告」する必要はない | メールはアラートとして保存しつつ、既存設定と運用を再確認する程度でよい |
結論：すでに MFA を強制しているテナントで必要な対応
まず、質問の核心部分からはっきりさせます。
- 追加で特別な設定を行う必要があるか？
→ 管理者を含め、Azure リソース管理に関わるユーザーに対し「サインイン時に MFA が必須」になっているなら、必須の追加作業はありません。 - 「MFA 対応済み」であることを Microsoft に申告する必要はあるか？
→ 申告や承認プロセスは存在しません。Microsoft 側が「実際のサインイン時に MFA が行われているか」をもとに判断します。
Microsoft のドキュメントでも、すでに MFA を強制している組織は、Mandatory MFA が始まっても動作に変化はないと明記されています。
ただし「何も確認しなくてよい」という意味ではありません。後述するチェックリストに沿って、以下は最低限行っておくのがおすすめです。
- 管理ポータル・CLI・PowerShell などで、実際に MFA を求められることをログインテストで確認する。
- Azure 管理用の自動化スクリプトでユーザーアカウントを使っていないかを洗い出し、必要に応じてサービス プリンシパルやマネージド ID へ移行する。
- 例外ユーザーや古いポリシー（per-user MFA だけが有効など）が残っていないかを棚卸しする。
Mandatory MFA 2025 の全体像を整理する
通知の意味を正しく理解するには、Microsoft が公表している 「Mandatory MFA のフェーズ構成」 を押さえておくと分かりやすくなります。
Mandatory MFA のフェーズと対象
| フェーズ | 開始時期 | 対象アプリ / ツール | MFA が必須になる操作 | 主な影響 |
|---|---|---|---|---|
| Phase 1 | 2024 年後半〜（順次展開） | Azure ポータル、Entra 管理センター、Intune 管理センター、Microsoft 365 管理センター（2025 年 2 月〜） | これらポータルでのすべての CRUD 操作（サインイン時点で MFA 必須） | 管理ポータルに入る管理者は基本的に全員 MFA が必要 |
| Phase 2 | 2025 年 10 月 1 日〜 順次展開 | Azure CLI、Azure PowerShell、Azure モバイルアプリ、IaC ツール（Bicep / Terraform 等）、ARM REST API、Azure SDK など | Azure リソースの Create / Update / Delete 操作。Read は MFA なしでも可能だが、ツールによってはエラーで促される。 | スクリプトや自動化、開発者の CLI 操作など、人間の ID を使う管理操作が MFA なしでは失敗する |
さらに、Mandatory MFA 全体の基本方針として、次の点も重要です。
- 対象は「Azure 管理アプリケーションにサインインするすべてのアカウント」（管理者ロールの有無は関係なし）。
- ワークロード ID（マネージド ID やサービス プリンシパル）は対象外。ただし、ユーザーアカウントをサービスアカウント代わりに使っている場合は対象。
- テスト用テナントも含め、すべての Azure テナントが対象で、完全に「オプトアウト」することはできない（延期は可能）。
「MFA 対応済み」かどうかを確認するチェックリスト
では、自分のテナントが Mandatory MFA に問題なく耐えられる状態か、どのように確認すればよいでしょうか。ここでは、すでにある程度 MFA を導入しているテナント向けのチェック項目をまとめます。
1. テナントレベルの MFA 強制方法を確認する
現在の Azure / Entra ID では、MFA を強制する代表的な方法は次の 3 つです。
| 方法 | 概要 | メリット | 注意点 / 向いているケース |
|---|---|---|---|
| セキュリティ既定 (Security Defaults) | 無料テナント向けの標準セキュリティ設定。すべてのユーザーに対し MFA 登録と基本的な保護を有効化。 | 設定が簡単。細かい設計をしなくても「最低限の MFA 対応」ができる。 | 柔軟な例外設定ができない。P1/P2 ライセンスがない中小テナントや検証環境向け。 |
| 条件付きアクセス ポリシー (Conditional Access) | ユーザー / グループ / アプリ / リスクに応じて MFA を要求する高度なポリシー機能。 | Azure 管理アプリだけ、特定のロールだけなど細かく制御できる。将来の Zero Trust 設計にもつなげやすい。 | 設計ミスでロックアウトのリスクがある。Entra ID P1/P2 ライセンスが必要。 |
| 外部 MFA（外部認証方法 / フェデレーション IdP 連携） | サードパーティ MFA や ADFS などからの MFA クレームを Entra ID が受け取って評価する方式。 | 既存の MFA 基盤を活かせる。特定業界向け製品との統合もしやすい。 | 正しく多要素認証クレームを送るよう IdP 側の設定が必要。古い「カスタム コントロール」だけでは Mandatory MFA を満たせないため、外部認証方法プレビューへの移行が推奨される。 |
まずは、自テナントがいずれの方式で Azure 管理アプリに対して MFA を強制しているのかを整理しましょう。
2. 管理者アカウントが本当に MFA で保護されているか確認する
通知メールの回答にもあるように、「管理者アカウントが MFA で保護されていれば、この通知は無視してよい」とされています。 しかし、「設定したつもり」になっているケースは意外と多くあります。
次のようなチェックを行うと安心です。
- グローバル管理者、特権ロール管理者、セキュリティ管理者などのロールを持つユーザー一覧を抽出する。
- それらのユーザーについて、認証方法レポート（Authentication methods activity）やサインインログで MFA が実行されているかを確認する。
- 実際に別ブラウザーや InPrivate ウィンドウからポータルにサインインし、パスワードだけで入れてしまわないかをテストする。
- 予備の MFA 方法（電話、FIDO2 セキュリティキー、別デバイスの Authenticator など）が登録されているかを確認し、「端末紛失で管理者全滅」を防ぐ。
3. Azure CLI / PowerShell / IaC / REST API の影響を洗い出す
Mandatory MFA のフェーズ 2 で最も影響が大きいのは、スクリプトや自動化で Azure を操作している部分です。公式情報では次のように整理されています。
| ツール / クライアント | MFA 必須になるケース | 主な対応方針 |
|---|---|---|
| Azure CLI / Azure PowerShell | ユーザーアカウントでログインし、リソースを Create / Update / Delete する場合 | サービス プリンシパルやマネージド ID に移行し、ユーザー ベースの自動化をやめる。インタラクティブ操作は MFA でサインインする運用へ変更。 |
| IaC ツール（Terraform, Bicep など） | バックエンドで Azure CLI / PowerShell / SDK を使って ARM へ CRUD 操作をする場合 | バックエンド認証をワークロード ID に統一する。ユーザー名＋パスワードや ROPC フローは廃止。 |
| 自作アプリ / スクリプト（Azure SDK / ARM REST API 使用） | ユーザーアカウントのトークンで ARM に対し CRUD 操作を行う場合 | Username/password ベースの認証や ROPC を廃止し、マネージド ID or サービス プリンシパル＋クライアントシークレット / 証明書に切り替える。 |
「人間が手動で Azure を操作する」部分は、MFA を求められてもさほど問題にはなりません。一方、「夜間バッチや CI/CD がユーザーアカウントで動いている」といったケースは、Mandatory MFA によって突然失敗するリスクがあるため、早めの洗い出しと移行が重要です。
まだ MFA を適用していないテナントの具体的な対応手順
もし現在のテナントが、以下のような状態であれば、2025 年 10 月 1 日までに必ず MFA を有効化する必要があります。
- グローバル管理者がパスワードだけで Azure ポータルにサインインできてしまう。
- Azure CLI / PowerShell 操作時に、パスワードのみで認証しているユーザーがいる。
- per-user MFA を一部ユーザーにしか設定しておらず、管理者等が対象外になっている。
代表的な進め方を、テナント規模別にまとめると次のようになります。
| テナント規模 / ライセンス | おすすめの MFA 導入方法 | ポイント |
|---|---|---|
| 小規模 / 無償版 Entra ID のみ | セキュリティ既定を有効化し、全ユーザーに MFA 登録を求める。 | 細かい例外は作れないが、導入スピード重視。ポータルと CLI の両方で MFA を求められるようにしておく。 |
| 中〜大規模 / Entra ID P1 以上 | 条件付きアクセスで「Azure 管理ポータル」「管理者ロール」「Azure CLI / PowerShell」などに対し MFA 必須ポリシーを作成。 | まずは管理者・特権操作を対象にし、その後一般ユーザーにも拡大する段階的なロールアウトが現実的。 |
| サードパーティ MFA 基盤を持つ企業 | 外部認証方法プレビューやフェデレーション IdP を利用して、MFA クレームを Entra ID に連携。 | 古い「Conditional Access のカスタム コントロール」だけでは Mandatory MFA の要件を満たさない可能性があるため、最新の方式への移行が推奨される。 |
いずれの方式でも共通するポイントは、少なくとも Azure 管理に関わるすべての「人間のアカウント」が MFA を突破しないと操作できない状態にしておくことです。
Microsoft に「MFA 済み」を申告する必要はない
質問でもよくあるのが、「通知メールに対して、どこかで『もう MFA 済みです』と申告する必要があるのか？」という点です。
結論としては、そのような申告フローは存在せず、何かをクリックして「完了」状態にする必要もありません。
- 通知メールは「今後の Mandatory MFA の日程と影響を周知する」ことが目的。
- Microsoft は、実際のサインイン時に MFA が実行されたかどうかをもとに強制を判断する。
- 公式 Q&A では、「すでに管理者に MFA を適用していれば、このメールは無視して問題ない」と明言されている。
一方で、準備期間を延長したい場合のみ、「延期申請」に相当する操作が用意されています。
- Phase 1 の MFA 強制は、最大 2025 年 9 月 30 日まで延期可能。
- Phase 2（CLI や PowerShell など）は、最大 2026 年 7 月 1 日まで延期可能。
- いずれも、各テナントごとにグローバル管理者がポータルの専用ページから開始日を後ろ倒しにする形式。
ただし、Microsoft 自身も「延期はリスクを増やす行為」であり、できるだけ早期に MFA を整備することを強く推奨しています。
複数テナントを管理している CSP / MSP が確認すべきポイント
パートナーとして多数のテナントを管理している場合、同じ通知が大量に届き、実務的にも精神的にも負荷が高くなります。そのような場合は、次のように整理して対応すると効率的です。
- テナント一覧と「Mandatory MFA 対応状況」の棚卸し
各テナントについて、少なくとも以下を一覧化します。- セキュリティ既定の有効 / 無効
- 条件付きアクセスの「Azure 管理向け MFA ポリシー」の有無
- 管理者ロール保有ユーザー数と、その MFA 登録率
- Azure CLI / PowerShell を利用しているユーザー / 組織（もし分かれば部署名など）
- 「今すぐ対応が必要なテナント」の優先度付け
例として、次のように優先度を付けると現場で動きやすくなります。- 優先度 高: 管理者に MFA がまったく適用されていないテナント
- 優先度 中: 管理者にのみ MFA があり、開発者や運用担当が CLI で非 MFA ログインしているテナント
- 優先度 低: すでに全ユーザーに MFA を強制しているテナント
- 共通テンプレートによるポリシー展開
条件付きアクセスや Azure Policy は、ある程度テンプレート化することで各テナントへの展開を自動化できます。
自動化スクリプトと運用手順の見直しポイント
Mandatory MFA 施行後に最もトラブルになりやすいのが、Azure Resource Manager を操作する自動化や運用スクリプトです。ニュースやブログでも、Azure Resource Manager への Create/Update/Delete 操作に MFA が必須となることが繰り返し強調されています。
次のような観点で見直しを行うとよいでしょう。
- ユーザー ID ベースの自動化を廃止する
「人間」がログインするためのユーザーアカウントを、スクリプトやジョブで使い回している場合は、マネージド ID またはサービス プリンシパルに移行します。これらは Mandatory MFA の対象外であり、適切に権限を絞ればセキュリティ面でもメリットがあります。 - ROPC（ユーザー名＋パスワード）フローの廃止
Microsoft Authentication Library (MSAL) の UsernamePassword 系 API や、環境変数 AZURE_USERNAME / AZURE_PASSWORD を使うパターンは、MFA と両立しないため、ドキュメント上でも変更が必須とされています。 - CLI / PowerShell バージョンの更新
Mandatory MFA 環境での互換性のため、Azure CLI 2.76 以上、Azure PowerShell 14.3 以上へのアップデートが推奨されています。 - Azure Policy による「セルフ強制」の活用
本番適用前に「MFA がないと CRUD をブロックする Azure Policy」を Audit モードで適用して影響範囲を確認し、その後 Enforce モードに切り替えるアプローチが推奨されています。
よくある質問への実務的な回答
Q. すでに管理者に MFA を強制しています。通知は無視して本当に大丈夫？
A. 少なくとも、管理者がポータルや CLI にサインインする際に必ず MFA が発生する状態であれば、通知自体に対して何か「応答」する必要はありません。公式 Q&A でも、管理者アカウントに MFA を設定済みならこのメールは無視してよいと回答されています。
ただし、以下のような追加チェックはしておくと安心です。
- 管理ポータルへのサインインテスト（別ブラウザーで実施）。
- Azure CLI / PowerShell で、管理者アカウントを使った CRUD 操作において MFA が要求されるかの確認。
- Automation アカウントや DevOps パイプラインが、ユーザー ID に依存していないかの確認。
Q. うちはサードパーティの MFA（SAML 連携）を使っています。Mandatory MFA を満たしますか？
A. サードパーティの MFA であっても、Entra ID に対して適切な MFA クレーム（multipleauthn など）が送信されていれば要件を満たします。
一方で、古い「Conditional Access のカスタム コントロール」ベースの連携は Mandatory MFA の要件を満たせないケースがあり、Microsoft も外部認証方法プレビューへの移行を案内しています。フェデレーション IdP（ADFS 等）と連携している場合は、IdP 側で MFA クレームが正しく構成されているか必ず確認しましょう。
Q. 「読み取り操作は MFA 不要」と書いてあるが、放置してもよい？
A. Phase 2 の説明にある通り、Read 操作は MFA がなくても実行できるため、ポータルや CLI でリソース情報を参照するだけなら一見問題なさそうに見えます。
しかし、次の理由から読取専用だからといって MFA を外すことは推奨されません。
- サインインできるということは、トークンを悪用して将来 Write 操作に利用される可能性がある。
- Mandatory MFA の対象アプリは今後さらに拡大する可能性がある。
- サインインログや監査の観点からも、重要アカウントのサインインは原則 MFA 前提で設計した方がよい。
Q. テスト用テナントや検証環境も Mandatory MFA の対象になりますか？
A. 公式 FAQ では、テスト用テナントであっても Mandatory MFA の対象になると明記されています。 したがって、検証環境だからといって MFA を無効のまま放置する運用は見直した方が安全です。
Q. 将来的に Microsoft Graph や他の SaaS も同じように MFA 必須になりますか？
A. 現時点の公式情報では、Mandatory MFA の対象は Azure 管理ポータルや Azure Resource Manager、Microsoft 365 管理センターなどにフォーカスされています。 Microsoft Graph 全体に対する同様の強制は公式にはアナウンスされていませんが、「管理ポータルと管理 API から順に MFA を標準化する」という流れは明確です。
そのため、長期的には「管理系のサインインは全て MFA（できればフィッシング耐性のある方式）」という前提で設計しておくのが現実的でしょう。
まとめ：通知に過剰反応せず、Mandatory MFA 時代に備える
最後に、本記事のポイントを整理します。
- 「MFA を有効化してください」という通知は、2025 年 10 月 1 日から始まる Mandatory MFA に向けた全テナント向けリマインドであり、届いたからといって「MFA が未設定」とは限りません。
- すでに管理者を含む Azure 管理ユーザーに対して MFA を強制しているテナントでは、追加の申告や特別な設定は不要です。ただし、サインインテストや自動化スクリプトの確認は必ず行いましょう。
- Mandatory MFA はフェーズ 1（管理ポータル）とフェーズ 2（CLI / PowerShell / ARM API の CRUD 操作）に分かれて段階的に適用されます。人間の ID を使った自動化は特に要注意です。
- まだ MFA を適用していないテナントは、セキュリティ既定や条件付きアクセス、外部 MFA 連携などを使って、少なくとも Azure 管理アプリに対して MFA を必須にする必要があります。
- Microsoft に「MFA 済み」を申告する仕組みはなく、実際のサインイン時に MFA が行われているかどうかが最終的な判断材料になります。延期申請は可能ですが、リスクも増えるため、早めの対応が推奨されます。
通知メールそのものに振り回されるのではなく、「自テナントの MFA 設定と運用が Mandatory MFA の要件に耐えられるか」を冷静に確認し、足りない部分を計画的に補っていくことが重要です。そうすることで、2025 年 10 月 1 日以降も Azure 管理業務や自動化スクリプトを安全かつ安定して継続できます。
コメント