2025年頃から、Azure 管理者のもとに「Action required: Enable multifactor authentication for your tenant by 1 October 2025」というメールが届くようになりました。すでに Microsoft Authenticator などで多要素認証（MFA）を使っているのに、本当に何か対応が必要なのか――このメールの正体と、実務で確認しておくべきポイントを整理します。
結論：このメールで「今すぐ作業が必要」なケース／そうでないケース
最初に、ザックリ結論から整理します。
- すでに条件付きアクセスやセキュリティの既定値で、Azure 管理系のサインインに対して MFA を強制している
- スクリプト・自動化・バッチ処理では、ユーザー アカウント＋パスワードではなく、サービス プリンシパルやマネージド ID などのワークロード ID を使っている
上記 2 つを満たしているなら、原則として追加設定は不要です（念のため確認・棚卸しはしておく価値がありますが、「大規模な構成変更プロジェクト」が必須になるわけではありません）。
逆に、次のようなケースが 1 つでも残っている場合は、2025/10/1 までに対応を始めるべきゾーンです。
- Azure CLI / Azure PowerShell / 各種 SDK で、ユーザー名＋パスワードだけでログインしているスクリプトがある
- Windows サーバー上のタスクスケジューラやオンプレのジョブから、人間用ユーザー アカウントを「サービスアカウント代わり」に使って Azure を操作している
- アプリケーションで
UsernamePasswordCredential/ ROPC（Resource Owner Password Credentials）フローを使って ARM（Azure Resource Manager）にアクセスしている
こうした「ユーザー アカウント頼みの自動化」は、2025/10/1 以降、MFA が要求されて失敗する可能性が高いため、ワークロード ID（サービス プリンシパル／マネージド ID）への移行が必須になります。
このメールの正体：Azure 管理プレーンでの MFA 必須化（Phase 2）の周知
このメールは、Microsoft が進めている 「Azure サインインの MFA 必須化」施策の Phase 2 開始案内です。公式ドキュメントでは、Azure での MFA 必須化は次の 2 段階に分けて説明されています。
| 項目 | Phase 1（管理ポータル） | Phase 2（管理プレーン全体） |
|---|---|---|
| 主な対象アプリ | Azure ポータル、Microsoft Entra 管理センター、Intune 管理センター、Microsoft 365 管理センター | Azure CLI、Azure PowerShell、Azure モバイルアプリ、IaC ツール（Bicep/Terraform など）、ARM の REST API / SDK |
| 開始時期 | 2024 年後半にロールアウト開始。Azure ポータルへのサインイン分は 2025 年 3 月に 100% 展開完了。Microsoft 365 管理センターは 2025 年 2 月から順次。 | 2025 年 10 月 1 日から順次ロールアウト開始（テナントによって実際の有効化日は異なる）。 |
| 対象操作 | ポータル上での Create / Read / Update / Delete（CRUD）操作すべてで MFA を要求 | 管理プレーンの Create / Update / Delete（変更系）操作で MFA を要求。Read（読み取り）は対象外。 |
| 強制方法 | Azure 側で MFA を必須とし、必要に応じて Microsoft-managed CA ポリシーも利用 | Azure Policy による段階的な適用（監査モード／強制モード）＋メール・Service Health による通知。 |
今回のメールは、このうち Phase 2（管理プレーン側）の開始予告です。「2025/10/1 から、Azure CLI や Azure PowerShell、IaC などでリソースを作成・変更・削除する前に MFA が必須になりますよ」という内容を、テナントのグローバル管理者に周知するために送られています。
メール本文を読み解く：どこまでが「必須」なのか
実際のメールでは、英語で次のような趣旨の文言が書かれています（Microsoft Q&A より）。
- 2025 年 10 月 1 日以降、Azure でリソース管理アクション（resource management actions）を実行する前に、ユーザーは MFA を使ってサインインする必要がある
- セキュリティを高めるため、できるだけ早く MFA を有効化しておくことを推奨する
ここで重要なポイントを整理しておきます。
- 対象は「Azure のリソース管理操作」
具体的には、ARM（Azure Resource Manager）を通じたリソースの作成・更新・削除（VM の作成、VNet の変更、ストレージ アカウントの削除など）であり、読み取りだけの操作（一覧表示、状態確認）は MFA 強制の対象外とされています。 - Azure 上で動いているアプリケーションの「データ プレーン操作」は対象外
たとえば、既存の Web アプリが SQL Database にクエリを投げる／Storage の Blob にアクセスするといった「アプリ側の処理」は、この必須化の直接の対象ではありません（それぞれのサービス側の認証方式・アクセス制御に従います）。 - メールが届いた＝「今はルール違反」という意味ではない
公式ドキュメントには、すでに MFA を強制している組織や、より強い認証（パスワードレス／パスキーなど）を使っている組織については、今回の強制による変化は基本的にないと明示されています。
つまりこのメールは、「Azure 側での MFA 強制が 2025/10/1 から始まるので、それまでにユーザーと自動化の準備を整えてください」という「予防線」の意味合いが大きいと考えると理解しやすくなります。
なぜ、すでに MFA を使っていてもメールが届くのか
「うちのテナントは前から条件付きアクセスで MFA を強制しているのに、なぜ今さらこんなメールが……？」と思われる方も多いはずです。
これは、「対象テナントの Microsoft Entra グローバル管理者に、一律で周知メールを出す」という運用になっているためです。Azure 公式ブログでも、Phase 2 開始に合わせて、全テナントのグローバル管理者にメールと Azure Service Health 通知を送信していると説明されています。
しかも、
- 1 人の管理者が複数テナント（本番・検証・開発・お客様環境など）のグローバル管理者になっている
- テナントによっては、グローバル管理者が複数存在する
といった事情があるため、同じ人に同じメールが何通も届くことがあり、結果として「何か大問題が発生したのでは？」という心理的プレッシャーを生んでしまっています。
しかし、実態としては「あなたの環境がまだ未対応だから送っています」という意味ではなく、
- Azure 全体での大きな仕様変更であること
- 特に自動化やスクリプトでユーザー アカウントを使っている環境では、放置すると 10 月以降にジョブが止まる可能性があること
を、テナント単位で確実に届けたいという意図と考えられます。実際、Microsoft Q&A でも「MFA を使っているのになぜこのメールが来るのか？」という質問が多数寄せられており、「あくまで全体周知であり、すでに要件を満たしていれば追加の設定は不要」といった趣旨の回答が行われています。
誰が影響を受けるのか：アカウント種別別の整理
今回の必須化によって「誰が」「どの程度」影響を受けるのかを、アカウントの種類ごとに整理してみます。
| アカウント・シナリオ | 必須化の影響 | ポイント |
|---|---|---|
| グローバル管理者／各種管理者ロールを持つユーザー | Azure ポータル・Entra 管理センターなどにはすでに Phase 1 で MFA が必須。Phase 2 では CLI / PowerShell などの利用時にも引き続き MFA が必須。 | 条件付きアクセスや Microsoft-managed CA ポリシーで既に MFA を要求しているなら、大きな仕様変更はなし。 |
| 開発者・運用担当など、Azure リソースを管理する一般ユーザー | Azure CLI / PowerShell / Portal でリソースの作成・変更・削除を行うときに MFA 必須。 | これまで「普段はパスワードだけで CLI を使っていた」人は、今後 MFA が必須になる。 |
| B2B ゲスト ユーザー | ゲストでも、管理アプリにサインインしてリソース管理操作を行うなら MFA 必須。 | 自テナント側／相手先テナント側のどちらかで MFA 要件を満たしている必要あり。 |
| 「サービスアカウント代わり」に使っているユーザー アカウント | 自動化で CLI / PowerShell / SDK を実行している場合、MFA 要求に応答できずジョブが失敗するリスク。 | すみやかにサービス プリンシパルやマネージド ID などのワークロード ID へ移行推奨。 |
| サービス プリンシパル／マネージド ID（ワークロード ID） | Mandatory MFA の対象外。従来どおりクライアント資格情報フローなどで認証。 | ただし、条件付きアクセス（Workload identities 向け CA）で別途制御することは可能。 |
| Azure AD Connect / Entra Cloud Sync の同期アカウント | Mandatory MFA の対象外。 | 同期は引き続き動作するが、管理ポータルにサインインして設定変更する際は MFA 必須。 |
まとめると、「人がサインインして管理操作をするアカウント」だけが Mandatory MFA の直接の対象であり、「アプリやジョブがサインインするワークロード ID」は対象外です。ただし、「人用アカウントをサービスアカウントとして流用している」ケースは例外なく影響を受けるので、最優先で洗い出してください。
今すぐやるべき実務チェックリスト
ここからは、メールが届いたテナント管理者が「実際に何をすればよいか」を段階的に整理します。公式ドキュメントの手順をベースに、現場向きに噛み砕いたチェックリストです。
| ステップ | 目的 | 主な作業 |
|---|---|---|
| 1. MFA 強制の実効性確認 | 「MFA を必須にしているつもり」が本当に効いているか確認 | 条件付きアクセス／セキュリティの既定値／Per-user MFA の状態・サインインログを確認 |
| 2. 自動化・スクリプトの棚卸し | MFA 非対応の自動化ポイントを洗い出す | ユーザー アカウント＋パスワードで動いているジョブを全洗い出し |
| 3. Azure Policy による影響評価 | どのユーザー・どの操作が影響を受けるか可視化 | 組み込みポリシーを「監査（Audit）」で適用し、ログを確認 |
| 4. クライアントのアップデート | claims challenge（MFA 要求）に正しく対応できるようにする | Azure CLI / Azure PowerShell を推奨バージョン以上に更新 |
| 5. パイロット導入 | いきなり全社適用せず、テストしてから本番へ | テストグループに CA ポリシーや Azure Policy を適用し挙動確認 |
| 6. 間に合わない場合の施行日の延期 | どうしても準備が間に合わない場合の安全弁 | Entra 管理センターから Phase 2 の開始日を最大 2026/7/1 まで延期 |
| 7. 運用設計とユーザー周知 | 運用で迷わないようにルールを固める | サポートする MFA 手段・問い合わせフロー・非常用アカウント運用を明文化 |
MFA 強制の実効性を確認する
まずは「すでに MFA を使っているつもり」が本当に Azure の Mandatory MFA 要件を満たしているかをチェックします。Microsoft Learn にはテナントの種類ごとの確認手順がまとまっています。
- Entra ID P1 / P2 ライセンスあり
条件付きアクセスで、「Microsoft Admin Portals」「Windows Azure Service Management API」 などのクラウドアプリに対して「MFA 必須」のポリシーを作成し、最初は Report-only モードで有効化して影響を確認します。その後、本番ロールアウト時にオンへ切り替えます。 - Microsoft 365 / Entra ID Free のみ
セキュリティの既定値（Security defaults）を有効化することで、全ユーザーに MFA 登録と必要に応じた MFA を要求できます。より細かい制御が不要であれば、これだけで Mandatory MFA の要件を満たせます。 - Per-user MFA（ユーザー単位 MFA）を使っている場合
可能なら条件付きアクセスやセキュリティの既定値への移行が推奨ですが、どうしても移行できないテナントでは引き続き利用可能です。ただし、条件付きアクセスを併用する場合は per-user MFA は新規で有効にしないことが推奨されています。
また、サインインログや「ユーザー登録の詳細」レポートを使って、
- 誰がどのアプリにどの方法でサインインしているか
- MFA が要求されているのに未登録で止まっているユーザーがいないか
を確認しておくと、後続の対応計画が立てやすくなります。
自動化・スクリプトを棚卸しし、ワークロード ID へ移行する
次に、最もトラブルになりやすい自動化・スクリプト周りを棚卸しします。特に以下のようなパターンが要注意です。
- Windows タスクスケジューラや Linux の cron から、
az login -u [email protected] -p <password>のようなコマンドでログイン Connect-AzAccount -Credential (Get-Credential)のように、ユーザー名＋パスワードで Azure PowerShell に接続- アプリケーションコードで
UsernamePasswordCredentialを使って ARM にアクセス - 古い ROPC フローを使った認証（ユーザー名＋パスワードの直接 POST）
Mandatory MFA が有効になると、これらの「パスワードだけの認証」は MFA 非対応のため例外を投げる／エラーを返すようになります。公式ドキュメントでも、ROPC と UsernamePasswordCredential を使う API は MFA が有効になったテナントではエラーになるため、別の認証フローへの移行が必要と明記されています。
推奨される移行先は次のとおりです。
- バックグラウンドジョブ・サーバー側処理：サービス プリンシパル（アプリ登録）＋クライアント資格情報フロー
- Azure 上で動くリソース（VM / App Service / Functions など）：マネージド ID（System-assigned / User-assigned）
- 人が対話的に実行するスクリプト：Device code フローやブラウザを使った対話サインイン（
az loginのデバイスコードモードなど）＋ MFA
Microsoft Learn には、「ユーザー アカウントをサービスアカウントとして使っているケースを検出し、ワークロード ID へ置き換える」ためのガイドやサンプルも案内されていますので、時間をかけてでもここは確実に移行しておくことをおすすめします。
Azure Policy で影響範囲を事前に可視化する
いきなり本番環境で Mandatory MFA を待ち受けるのではなく、Azure Policy を使って自分たちのルールとして先に「MFA 必須」をシミュレーション適用しておくと安心です。
- Azure Policy の組み込み定義には、MFA を完了していないユーザーによる管理プレーン操作を監査・拒否するポリシーが用意されている
- 最初は 「Audit（監査）」モードで割り当て、どのサブスクリプション／リソースグループ／リソース種別で違反が出るかを確認する
- 問題がないことを確認したうえで、本番的に 「Deny（拒否）」 に切り替える
この手順を踏んでおくと、Microsoft 側の Mandatory MFA 強制が始まる前に、自分たちのコントロール下で「どこが止まりそうか」をあらかじめ把握できるため、移行プロジェクトのリスクを大幅に減らせます。
Azure CLI / PowerShell クライアントを更新する
MFA 強制時には、Azure 側から「claims challenge」と呼ばれる追加情報がクライアントに返され、それを解釈して MFA プロンプトを出したりエラーを表示したりします。古いクライアントではこのフローに対応しておらず、ユーザーに意味不明なエラーだけが返ってしまう可能性があります。
公式ドキュメントでは、Azure CLI は 2.76 以降、Azure PowerShell は 14.3 以降を使用することが推奨されています。
- VDI や共有サーバーなど、複数ユーザーが共用する環境では特にバージョンを統一しておく
- 開発者向けのローカル環境でも、社内の標準バージョンを決めて案内しておく
パイロット導入で「ロックアウトしない」ことを最優先する
MFA 関連の設定をいきなり本番全体に適用すると、最悪の場合 管理者自身がロックアウトされるリスクがあります。そのため、Microsoft も「まずは Report-only / Audit で影響を把握してから本番適用」することを強く推奨しています。
- テスト用のセキュリティグループ（IT 部門＋一部のパワーユーザー）を用意
- このグループを対象とした CA ポリシー／Azure Policy を Report-only / Audit で有効化
- Entra サインインログと CA insights & reporting で、どのユーザーがどのアプリに対して MFA 要求を受けているかを確認
- 問題がなさそうであれば、対象ユーザーを段階的に増やしつつ、本番ポリシーとして「オン」へ切り替え
どうしても間に合わない場合は施行開始日を延期する
レガシー システムや大規模なマルチテナント環境など、どうしても 2025/10/1 までに移行が終わらないケースもあり得ます。そのため Microsoft は、Phase 2 の強制開始日を最大 2026/7/1 まで延期できる仕組みを用意しています。
- グローバル管理者が
https://aka.ms/postponePhase2MFAまたは Azure ポータルの専用ページにアクセス - テナントごとに開始日を選択し、「適用」をクリック
- Phase 1 を延期していた場合は、基本的に同じ開始日が Phase 2 にも適用される（Phase 2 をさらに遅らせることも可能）
ただし、これはあくまで「時間を稼ぐための一時的措置」であり、完全な免除ではありません。公式にも「延期することで高価値なアカウントの攻撃リスクが高まるため、可能な限り早期に MFA を導入してほしい」と警告されています。
運用ドキュメントとユーザー周知を整える
最後に、技術的な設定だけでなく、運用ルールとユーザー向けの説明を整備しておきましょう。
- どの操作で MFA が出てくるのか
「Azure ポータルにサインインするとき」「CLI でリソースを作成・変更・削除するとき」など、ユーザーが戸惑わないように具体的に説明しておく。 - サポートする認証方法
パスワードレス（FIDO2 パスキー、Windows Hello for Business）、Microsoft Authenticator、SMS / 電話など、許可する／推奨する方式を整理する。フィッシング耐性の高い方法を優先すべきだと Microsoft も推奨しています。 - 非常用（break-glass）アカウントの運用
Break glass アカウントも Mandatory MFA の対象であり、FIDO2 パスキーや証明書ベース認証で MFA を満たすことが推奨されています。CA ポリシーでは除外しつつも、Mandatory MFA の要件は満たすように設計する必要があります。 - 「MFA が使えなくなった」ユーザー対応
端末紛失や機種変更時の再登録手順、サポート窓口、本人確認プロセスなどを事前に決めておく。
よくある勘違い・注意ポイント
「MFA を“使っている”だけでは足りない」ケースがある
管理者が自分のスマホに Authenticator を入れていても、
- 条件付きアクセスがごく一部のユーザーやアプリにしか適用されていない
- 一部の管理者ロールだけが対象で、開発者や運用担当は対象外のまま
といったケースは少なくありません。Mandatory MFA では、管理者かどうかに関係なく「対象アプリで管理操作を行うすべてのユーザー」が MFA 対象になるため、ポリシーの適用範囲を見直す必要があります。
Per-user MFA の状態が「無効」でも問題ないことがある
Entra 管理センターの「Per-user MFA」画面でユーザー状態を見ると、「無効」と表示されていて不安になることがあります。しかし、公式ドキュメントには明確に、
- 条件付きアクセスやセキュリティの既定値で MFA を有効化している場合、Per-user MFA の状態は参照・変更しない
- 条件付きアクセスで MFA を要求していても、Per-user MFA の状態は「無効」のまま変化しない
と記載されています。
つまり、「Per-user MFA の画面だけを見て、テナント全体で MFA が無効だと判断する」のは誤りです。実際の挙動は、条件付きアクセス／セキュリティの既定値／サインインログで確認しましょう。
サービス プリンシパルやマネージド ID には Mandatory MFA はかからない
ワークロード ID（サービス プリンシパル、マネージド ID）は、今回の Mandatory MFA の対象外です。
ただし、だからといって「何もしなくてよい」というわけではありません。
- クライアント シークレットや証明書の管理（有効期限・保管場所）
- Workload identities 用の条件付きアクセス（IP 制限やリソース制限など）
- 必要最小限のロール割り当て（RBAC）
といった観点で別途セキュリティ対策を行う必要があります。Mandatory MFA はあくまで人間のサインインに対する「最低限の安全ベルト」という位置付けだと捉えるとよいでしょう。
メールが来たからといって「Office 製品まで即日 MFA 必須」になるわけではない
日本語の Microsoft Q&A でも、「Microsoft 365 管理センターや Azure ポータルだけでなく、Office 製品のサインインもすべて MFA 必須になるのか？」という質問が出ています。
回答としては、
- 今回のメールはあくまで Azure のリソース管理操作 に関する Mandatory MFA の案内
- Office 製品や Microsoft 365 サービスの利用だけを行うユーザーに対して、このメールが直接「MFA 義務化」を意味するわけではない
とされています。もちろん、セキュリティの観点からは Office サインインにも MFA を適用すべきですが、それは今回の Azure Mandatory MFA とは別の設計論点になります。
シナリオ別：どこまでやれば安心か
小規模テナント（Entra ID Free＋Microsoft 365、中～小規模組織）
- 普段は Microsoft 365（Exchange Online / Teams / OneDrive など）がメインで、Azure リソースはほとんど使っていない
- 管理者がたまに Azure ポータルを開いて設定確認する程度
このようなテナントでは、
- セキュリティの既定値を有効にして 全ユーザーに MFA 登録を促す
- 管理者数を最小限にし、グローバル管理者は原則パスワードレス（FIDO2 / Windows Hello など）を利用
- Azure ポータルにサインインするときは、すでに Phase 1 により MFA が求められているはずなので、特に追加作業は少ない
というパターンが多いはずです。この場合、自動化やスクリプトで Azure 管理をしていないのであれば、今回のメールは「準備できているかの最終確認」として受け止める程度で構いません。
中～大規模 Azure 利用（本番環境で多数のリソースを運用）
サブスクリプションが複数あり、IaaS / PaaS / コンテナ環境を大規模に運用している組織では、
- 開発・運用チームで多種多様なスクリプトや IaC ツールが使われている
- 歴史が長い環境では、初期に作られたジョブがユーザー名＋パスワードで動き続けている
といった状況が起こりがちです。この場合、Mandatory MFA 対応は小さくても 1 つのプロジェクトとして扱うことをおすすめします。
- サインインログとコードリポジトリを使って「ユーザー アカウントを使った自動化」を徹底的に洗い出す
- 各チームの代表者を集め、サービス プリンシパル／マネージド ID への移行計画を立てる
- Azure Policy で Audit をかけ、本当に影響があるサブスクリプションやリソース種別を特定
- 最終的に CA ポリシーと Azure Policy を強制モードに切り替えるタイミングを決め、周知する
このプロセスを通じて、単に Mandatory MFA に「対応した」だけでなく、長年の技術的負債だった「人間アカウントによる自動化」を整理できるという副次的なメリットも生まれます。
複数テナントを管理する MSP / SIer / 開発会社
お客様テナントを含む複数の Azure テナントを管理している組織では、管理者がテナントごとに同じメールを大量に受け取ることになります。
- 自社側の管理アカウントに対しては、先述のチェックリストを自社テナントでそのまま実行
- お客様テナントについては、Mandatory MFA 対応状況の評価と、必要であれば移行支援を有償サービスとして提案
- 特に ISV や SaaS ベンダーで、お客様テナントに対して API でリソースを作成しているサービスは、ワークロード ID ベースでの認証に統一されているかを確認
この機会に、お客様との責任分界点（どこまでをテナント側、どこからをベンダー側が担うか）を文書化しておくと、強制開始後のトラブル対応でも役立ちます。
ひとことでまとめると
Azure から届いた「Action required: Enable multifactor authentication for your tenant by 1 October 2025」というメールは、
- 「2025/10/1 以降、Azure の管理プレーン（CLI / PowerShell / IaC / REST / SDK など）でリソースを作成・変更・削除する前に、ユーザー アカウントには MFA が必須になります。準備はできていますか？」
という「予告・確認」のメールです。
すでに MFA を強制しており、ユーザー アカウントを自動化に使っていないテナントであれば、基本的には大きな追加作業はありません。一方で、歴史のある環境やスクリプトが大量にある環境では、ユーザー名＋パスワードだけに頼った古いジョブが残っている可能性が高く、ワークロード ID への移行と影響評価を優先的に進める必要があります。
Mandatory MFA は、単なる「また 1 つの強制設定」ではなく、Azure 環境全体を「MFA 前提」のセキュアな状態に引き上げるための最後の一押しです。このメールをきっかけに、自分たちのテナントが本当に MFA 前提の設計になっているか、改めて棚卸ししてみてください。
コメント