2025年以降、AzureやMicrosoft 365の管理ポータルでは多要素認証（MFA）が事実上「必須」になっていきます。その一環として、テナント管理者宛てに「Action required: Enable multifactor authentication for your tenant by 1 October 2025」というメールが届き、対応が必要なのか不安になっている方も多いはずです。本記事では、とくにMicrosoft Entra ID Free（旧Azure AD Free）環境で何を確認し、どこまで対応していれば安心なのかを、実務目線で整理します。
「Enable multifactor authentication by 1 October 2025」メールで何が変わるのか
メールの背景：Azure全体での「MFA必須」化
Microsoftは、Azureや管理ポータルへのサインインに対して段階的にMFAを必須化することを発表しています。MFAを有効にすることで、アカウント乗っ取り攻撃の99％以上を防げるという自社調査結果に基づき、Azureサインインの標準を「パスワードのみ」から「MFA前提」に引き上げる方針です。
AzureのMFA必須化は、次の2フェーズで進みます。
| フェーズ | 開始時期 | 対象 | 内容 |
|---|---|---|---|
| Phase 1 | 2024年後半〜 | Azureポータル / Entra 管理センター / Intune 管理センター / Microsoft 365 管理センターなど | これらの管理ポータルにサインインするすべてのアカウントにMFAを要求 |
| Phase 2 | 2025年10月1日〜段階適用 | Azure CLI / Azure PowerShell / Azure モバイルアプリ / IaCツール / Resource Manager REST API など | リソースの作成・更新・削除などのリソース管理操作にMFAを必須化（読み取りのみは除外） |
今回のメール「Action required: Enable multifactor authentication for your tenant by 1 October 2025」は、主にこのPhase 2（Azureリソース管理操作へのMFA強制）に向けた周知メールです。Azureリソースマネージャー層でMFA非対応のままだと、2025年10月以降、「リソース管理操作を実行しようとした時点でMFA登録を求められ、処理が失敗する」状況が起こり得るため、その準備を求める内容になっています。
なお、環境によってはテナントのグローバル管理者がAzureポータルからPhase 2の強制開始を最長2026年7月1日まで延期することも可能です。
メールは「広く送られている周知」：Entra ID Freeでも届く
Microsoft Q&Aでも、今回とまったく同じメールについて多数の質問が上がっています。その中で、Microsoft MVPから次のような回答が出ています。
- このメールは多くのテナント管理者に対して一斉に送られている「情報提供」メールである。
- 今後のMFA強制によるサポート問い合わせの急増を抑えるため、早めに注意喚起している。
- すでにすべての管理者に少なくとも1つのMFA手段が登録済みなら、このメール自体への追加対応は不要。
同じくMicrosoft Q&Aでは、「Entra ID Freeプランでセキュリティの既定値（Security defaults）を有効にしているが、このメールに対して何か追加でやることがあるのか？」という問いに対し、セキュリティの既定値を有効にしていれば、新しいMandatory MFA要件はすでに満たしており追加対応は不要と複数のMVPが回答しています。
結論：Entra ID Freeで「管理者全員がMFA登録済みなら追加作業はほぼ不要」
Microsoftの公式ドキュメントでは、すでに対象アプリ（AzureポータルやAzure CLI等）へのサインインに対して組織がMFAを強制している場合、Mandatory MFAのロールアウトによる挙動の変化はほぼ起きないと明記されています。
また、「Microsoft 365 または Microsoft Entra ID Free」のテナントがMandatory MFA要件を満たす方法として、次の2つが公式に案内されています。
- セキュリティの既定値（Security defaults）を有効化する
- セキュリティの既定値を使わない場合は、ユーザー単位のMFA（Per-user MFA）で対象ユーザーにMFAを必須にする
以上を踏まえると、Entra ID Freeテナントで以下を満たしていれば、今回のメールのために特別な追加設定を行う必要は基本的にありません。
- すべての管理者アカウントに少なくとも1つのMFA手段が登録済みである
- セキュリティの既定値を有効にしている、もしくはユーザー単位のMFAで管理者にMFAを強制している
とはいえ、「本当に漏れがないか？」「サービスアカウントや自動化スクリプトは大丈夫か？」といった不安は残ります。そこで次章では、Entra ID Free環境で確認しておきたい実務的なチェックポイントを整理していきます。
Entra ID Freeテナント向け 実務チェックリスト
ここからは、Entra ID Free（旧Azure AD Free）で今回のMandatory MFA対応を確認するためのチェックリストを紹介します。ざっくり言えば、次の5点を押さえておけば安心です。
| チェック項目 | 目的 | ポイント |
|---|---|---|
| 管理者のMFA登録状況の確認 | 権限の強いアカウントの乗っ取りリスクを最小化 | グローバル管理者など、すべての管理者に少なくとも1つのMFA手段を登録させる |
| MFA強制の仕組みの確認 | MFAを「任意」ではなく「必須」にする | セキュリティの既定値の有効化、またはユーザー単位のMFAで管理者にMFAを強制 |
| 緊急時用（ブレークグラス）運用の整理 | 誤設定や障害時でもテナントへのアクセスを確保 | 強固なパスワードとMFAを備えた緊急用アカウントを2つ以上用意、利用ルールを文書化 |
| 共有・サービスアカウントの見直し | 人のサインインが必要なアカウントを減らし、MFA適用範囲を明確に | 可能な限りアプリ専用のサービスプリンシパルやマネージドIDへ移行 |
| ログによるMFA未対応ユーザーの洗い出し | 設定漏れや想定外の利用パターンを発見 | サインインログでMFA要求・失敗イベントを確認し、未対応ユーザーを是正 |
管理者アカウントにMFA手段が登録されているか
最初に確認すべきは、管理者アカウントにMFA手段が登録されているかです。とくにグローバル管理者がパスワードだけでログインできる状態は、もはや「今すぐ是正すべき危険な状態」と言えます。
対象となる代表的なロールは次のとおりです（すべてではありません）。
- 全体管理者（Global Administrator）
- セキュリティ管理者（Security Administrator）
- 条件付きアクセス管理者（Conditional Access Administrator）※Freeでは使えないが、ロールとしては存在
- 特権ロール管理者（Privileged Role Administrator）
- SharePoint / Exchange / Teams / Intune 等の各種管理者ロール
Entra 管理センターでの確認手順例（概要）は次のとおりです。
- グローバル管理者などで
https://entra.microsoft.comにサインイン。 - [ID] > [ユーザー] > [すべてのユーザー] を開きます。
- [フィルター] から「ディレクトリロール: 管理者」を選択し、管理者ロールが割り当てられているユーザーだけを抽出します。
- 各ユーザーを開き、[認証方法] または [Authentication methods]（表示によって名称は異なる）で、少なくとも1つのMFA手段が登録されていることを確認します。
MFA手段として登録できる代表的な方法は次のとおりです。
| 方式 | 例 | 特徴 | 優先度の目安 |
|---|---|---|---|
| パスキー / FIDO2 セキュリティキー | YubiKey などのFIDO2対応ハードウェアキー | フィッシング耐性が高く、パスワードレスにも対応可能 | 最優先（◎） |
| Authenticator アプリ | Microsoft Authenticator、他社TOTPアプリ | スマホを使ったワンタイムコードやプッシュ通知。運用しやすくコストも低い | 高い（○） |
| OATH ハードウェアトークン | OTPトークンデバイス | スマホ非依存。物理トークン管理の手間はかかる | 高い（○） |
| SMS / 音声電話 | ワンタイムコードをSMSまたは音声通話で受信 | 導入は容易だが、SIMスワップ攻撃などのリスクが高め | 補助的（△） |
現実的には、管理者はFIDO2＋Authenticatorアプリの二刀流、一般ユーザーはAuthenticatorアプリを基本とし、やむを得ない場合のみSMS/音声電話を許容する、といった設計がバランスの良い構成です。
MFAを「強制する仕組み」が用意されているか
MFA手段を登録しただけでは、「本人が気が向いたときにMFAを使う」状態であり、Mandatory MFAの要件は満たしません。必ず何らかの形で「MFAを強制」する必要があります。
Entra ID Freeで使える代表的な仕組みは次の2つです。
| 方式 | 概要 | メリット | デメリット | Freeテナント向けの位置づけ |
|---|---|---|---|---|
| セキュリティの既定値 (Security defaults) | Microsoftが用意した「強いセキュリティ設定のテンプレート」。全ユーザーにMFA登録を要求し、管理者には常にMFAを強制。AzureポータルやAzure CLIなどへのアクセス時もMFAを要求 | 追加ライセンス不要、オン/オフだけで利用可能。Mandatory MFA要件を満たすことが公式に明記されている | 「このアプリだけMFA緩める」といった細かい調整ができない | Freeテナントでは基本的にこれを有効化しておくのがベストプラクティス |
| ユーザー単位のMFA (Per-user MFA) | ユーザーごとにMFA必須/任意を設定 | 古くから存在する方式で、細かくユーザー単位で制御可能 | 機能としてはレガシーで、将来的には条件付きアクセスへの移行が推奨 | やむを得ずセキュリティの既定値を使えない場合の「暫定策」として利用 |
特に重要なのは、セキュリティの既定値を有効にしていれば、Mandatory MFAの要件はすでにカバーされているという点です。Microsoft Q&Aでも、「Entra ID Freeでセキュリティの既定値を有効にしているなら、Mandatory MFA要件はすでに満たしており、追加の対応は不要」と明言されています。
セキュリティの既定値の有効/無効は、Entra 管理センターの [ID] > [概要] > [プロパティ] > [セキュリティの既定値の管理] から確認・変更できます。
緊急時の運用（ブレークグラス）をどう考えるか
Mandatory MFAの導入によって、「すべての管理者がMFAなしではサインインできない」世界が当たり前になります。その結果、誤設定や障害による「テナント完全ロックアウト」リスクへの備えがより重要になります。
Microsoftは公式に、クラウドのみの緊急用（Emergency / Break-glass）アカウントを2つ以上持つことを推奨しています。これらのアカウントは通常業務では使用せず、Global Administratorロールを持つ「最後の砦」として扱います。
Mandatory MFAのドキュメントでは、ブレークグラスアカウントであっても、AzureポータルやEntra管理センターにサインインする場合にはMFAが必須になると明記されています。その上で、これらのアカウントのMFA手段としてはFIDO2パスキーまたは証明書ベース認証の利用が推奨されています。
Free＋セキュリティの既定値の環境では、Conditional AccessのようにブレークグラスアカウントだけをMFA対象から除外する、といった細かい制御はできません。そのため、次のような運用が現実的です。
- ブレークグラス用に2つ以上のクラウド専用アカウントを作成（
[email protected]形式） - 非常に長く強力なパスワード（例：32文字以上）を設定し、パスワード期限切れを起こさないようにする
- 強力なMFA手段（FIDO2キー等）を登録し、物理的に厳重管理された場所（耐火金庫など）に保管
- これらのアカウントは通常は一切使用せず、利用があった場合は必ずログを監査しパスワードを変更する運用ルールを文書化
「MFAサービス自体が停止している」といったシナリオを完全には回避できませんが、Freeテナントで取り得る現実的なベストプラクティスと言えます。
共有アカウント・サービスアカウントの見直し
Mandatory MFAの影響を最も受けやすいのが、スクリプトやバッチ処理でAzureリソースを操作している「ユーザー型サービスアカウント」です。
Mandatory MFAのドキュメントでは、Azure CLIやPowerShellスクリプトなどの自動化にユーザーアカウントを使うのは推奨されず、マネージドIDやサービスプリンシパルといった「ワークロードID」への移行が強く勧められています。
とくに、ユーザー名＋パスワード（ROPC：Resource Owner Password Credentials）でトークンを取得する方式はMFAと両立せず、Mandatory MFA環境では動作しなくなります。
Freeテナントでも、次のような方針で整理しておくとよいでしょう。
- 「人がサインインしない」アカウント（バッチ処理等）は、できるだけマネージドIDやサービスプリンシパルへ移行
- どうしてもユーザーアカウントで自動化が必要な場合は、MFA必須化後に動かない可能性が高いので、早めに代替手段（ワークロードID）を検討
- Azureポータルにログインする必要のない「メールだけの共有アカウント」は、原則としてAzure管理用途には使わないように設計
ログでMFA未対応ユーザーを洗い出す
「設定したつもりだったが、一部ユーザーだけMFAが効いていなかった」というのはありがちな落とし穴です。これを防ぐには、サインインログの確認が有効です。
Microsoft Entra IDのサインインログでは、どのアプリに対してMFAが要求され、どの認証方法が使われたかを確認できます。Mandatory MFAにより強制された場合は、「どのアプリケーションがMFAを要求したか」もログに記録されます。
確認のポイント例：
- サインインログでアプリケーション名に「Azure portal」「Microsoft Entra admin center」「Azure CLI」「Azure PowerShell」等を含むものをフィルタリング
- MFAが要求されたが失敗しているイベントを抽出し、「どのユーザーがMFA登録していないのか」を特定
- MFAが一度も要求されていない管理者アカウントがいないか確認
ここまで確認できれば、「Mandatory MFAが始まっても想定外のロックやエラーは起こりにくい」と言えます。
Entra ID FreeでのMFA運用パターン整理
ここまでを踏まえ、Entra ID Free環境で現実的な運用パターンを整理してみます。
パターンA：セキュリティの既定値（推奨）
もっともシンプルで安全なのが、セキュリティの既定値を有効化したうえで全ユーザーにMFA登録を済ませるパターンです。
- 管理者：サインイン時は常にMFA必須
- 一般ユーザー：リスクの高いサインインやAzureポータル等へのアクセス時にMFAを要求
- Azureポータル / Entra管理センター / Azure CLI / Azure PowerShell へのアクセス時は、ユーザー・管理者問わずMFAを要求
Mandatory MFAの観点から見ると、このパターンは最初から要件を満たしている状態です。
パターンB：セキュリティの既定値を無効にし、ユーザー単位MFAで管理者だけを保護
どうしてもセキュリティの既定値が運用に合わない場合、管理者アカウントだけユーザー単位のMFAで保護する構成もあり得ます。
ただしこの場合、次の点に注意が必要です。
- Azure CLI や PowerShell を使う一般ユーザーにも、Mandatory MFAによりMFA要求が発生するため、管理者以外にもMFA登録を進めておく必要がある
- どのユーザーにMFAを有効にしているかを管理者が把握しておかなければならない
- 将来的には条件付きアクセス（P1ライセンス以上）への移行が推奨される
Freeテナントで長期的に運用するのであれば、基本的にはパターンA（セキュリティの既定値）に寄せることをおすすめします。
よくある疑問と実務的な答え
Q1. このメール、本当に「無視して」いいの？
厳密には「無視」ではなく、一度テナントのMFA状況を棚卸ししたうえで、条件を満たしていれば追加対応不要というのが正確な表現です。
Microsoft Q&AでのMVPの回答では、「すべての管理者に少なくとも1つのMFA手段が登録されていれば、このメールを気にする必要はない」と明言されています。
したがって、次の2点さえ満たしていれば、実務上は「やるべきことは既にやっており、メールは周知に過ぎない」と判断できます。
- 管理者アカウントがすべてMFA登録済みである
- セキュリティの既定値、またはユーザー単位MFAで管理者にMFAが確実に強制されている
Q2. 一般ユーザーも必ずMFA必須になるの？
Mandatory MFAは、「AzureポータルやAzure CLIなど特定のアプリケーションに対するサインイン」を対象にしています。
- Azureポータル / Entra管理センター / Intune 管理センター / Azure CLI / PowerShell / IaCツールなどにアクセスするすべてのユーザーはMFAが必須
- それ以外のアプリケーション（通常の業務用SaaS等）は、それぞれのサービス側のポリシーに従う
セキュリティの既定値を有効にしている場合、一般ユーザーもサインイン時にMFA登録を求められ、「リスクが高い」と判断されたサインインやAzureへのアクセス時にはMFAが要求されます。
したがって、Mandatory MFAに備える意味でも、一般ユーザーにもMFA登録を進めておくことが結果的に楽です。
Q3. Freeプランでも本当にMandatory MFAに対応できているの？
はい、対応可能です。Microsoftの「Mandatory MFAの準備状況を確認する」ドキュメントでは、「Microsoft 365 または Microsoft Entra ID Free ライセンスの場合は、セキュリティの既定値またはユーザー単位のMFAを使うことでMandatory MFA要件を満たす」と明記されています。
さらに、セキュリティの既定値のドキュメントには、Azureポータル / Entra管理センター / Azure CLI / PowerShell へのアクセス時にはすべてのユーザーにMFAを要求する旨が記載されています。
つまり、Entra ID Freeでもセキュリティの既定値を有効化しておけば、Mandatory MFAの要件はすでにカバーされていると言えます。
Q4. 推奨されるMFA手段の優先度は？
まとめると、優先度の目安は次のようになります。
| 優先度 | 手段 | 主な用途 | コメント |
|---|---|---|---|
| 最優先 | FIDO2パスキー / セキュリティキー | ブレークグラス、重要な管理者、特権操作 | フィッシング耐性が高く、Mandatory MFAやブレークグラスの要件とも整合 |
| 高 | Microsoft Authenticator アプリ | 一般ユーザーおよび大半の管理者 | 導入・運用のバランスが良く、セキュリティの既定値とも相性が良い |
| 中 | OATH ハードウェア / 他社OTPアプリ | スマホに依存したくないユーザー | 運用コストとのバランスを見ながら採用 |
| 補助 | SMS / 音声電話 | どうしてもアプリを入れられない一部ユーザー | 利便性はあるが、セキュリティ強度は相対的に低く、あくまで例外として扱う |
Microsoft自身も、ブレークグラスアカウントのMFA手段としてFIDO2や証明書ベースの認証を推奨しており、これらが現時点で最も強力な選択肢と言えます。
今やっておくべき具体的アクションまとめ
最後に、「このメールを受け取ったEntra ID Freeテナント管理者」が今やっておくべき具体的なアクションを整理します。
ステップ1：管理者アカウントの棚卸し
- [ID] > [ロールと管理者] から全ての管理者ロールを確認
- 各ロールに割り当てられているユーザーをリストアップし、「管理者一覧」を作成
ステップ2：管理者全員にMFA手段を登録させる
- 全管理者に対して、FIDO2キーまたはMicrosoft Authenticatorの登録を必須化
- 登録後、[ユーザー] > [認証方法]で「登録済み手段」を確認し、未登録者がいないかチェック
ステップ3：セキュリティの既定値の状態を確認
- 有効になっている：Mandatory MFA要件は原則満たしているのでOK
- 無効になっている：業務上どうしても使えない理由がない限り、有効化を検討
ステップ4：ブレークグラス運用の整理
- クラウド専用の緊急用アカウントを2つ以上作成し、Global Administratorロールを付与
- 強力なパスワードとFIDO2キー等のMFA手段を登録し、安全な場所に保管
- 「何が起こったときに誰がどのように使うのか」を簡単でもよいので文書化
ステップ5：サインインログでMFA未対応の洗い出し
- Azureポータルのサインインログで、「MFAが要求されたが満たせなかったイベント」を確認
- Azureポータル / Entra / Azure CLI / PowerShellへのサインインでMFAが一度も要求されていない管理者がいないか再チェック
まとめ：今回のメールをどう受け止めるか
あらためて、Entra ID Freeテナントにおけるポイントを整理します。
- 「Action required: Enable multifactor authentication for your tenant by 1 October 2025」というメールは、Mandatory MFA強制の開始に向けた広範な周知メールであり、多くのテナント管理者に届いている。
- すでに管理者全員がMFA登録済みであり、セキュリティの既定値（またはユーザー単位MFA）で管理者にMFAを強制しているのであれば、追加の設定変更は基本的に不要。
- ただし、「本当に漏れがないか」の確認として、管理者一覧・MFA登録状況・セキュリティの既定値の有効化状態・サインインログの4点は最低限チェックしておくと安心。
- サービスアカウントや自動化スクリプトにユーザーアカウント＋パスワードを使っている場合は、マネージドIDやサービスプリンシパルへの移行を検討する。
- 緊急用（ブレークグラス）アカウントは、強力なパスワード＋FIDO2等のMFA手段を備えたクラウド専用アカウントを2つ以上用意し、通常は利用しない運用ルールを決めておく。
言い換えると、今回のメールは「新しい厳しいルールが突然押し付けられる」ものではなく、これまで推奨されてきたMFAのベストプラクティスを、Microsoft側がいよいよ本格的に標準化していくというメッセージです。
Entra ID Freeでも、セキュリティの既定値やユーザー単位MFAをうまく活用すれば、追加コストなしでMandatory MFA時代に十分対応できます。この機会に、自社テナントのMFA運用を見直し、「管理者はもちろん、Azureを触るすべてのユーザーがMFA前提である状態」を整えておきましょう。
コメント