2024〜2025年にかけて、Microsoft は Azure や Microsoft 365 の管理ポータル／ツールに対して多要素認証（MFA）の必須化を段階的に進めています。この記事では「Security Defaults（セキュリティの既定値）を有効にしているだけで、この新しい MFA 要件を満たせるのか？」を、公式ドキュメントと最新のアナウンスをもとに整理します。
結論：Security Defaults だけで Microsoft の「MFA 必須化」要件を満たせる
結論から言うと、テナントで Security Defaults を有効化しているか、条件付きアクセスで同等以上に MFA を強制している場合、Microsoft が進めている MFA 必須化の要件は満たしています。
Microsoft 公式ドキュメント「Planning for mandatory multifactor authentication for Azure and other admin portals」は、すでに MFA を強制しているテナントについては「ユーザー側の挙動に変化はない」と明示しています。
また、Microsoft 365 管理センター向けの公式ブログでも、Security Defaults もしくは条件付きアクセスで管理センターへのサインインに MFA を要求しているテナントは「すでに要件を満たしており、追加対応は不要」と明記されています。
さらに、Microsoft Q&A の「Do security defaults meet Microsofts requirement for MFA on a tenant or is more required before October 1st 2025」という質問に対する MVP の回答でも、Security Defaults はこの MFA 必須化要件を満たすと整理されています。
つまり、質問にある「2025年10月1日までに何か追加で設定が必要か？」という点については、
- Security Defaults を有効にしている
- または、条件付きアクセスで Azure / Microsoft 365 管理系ポータルや Azure CLI / PowerShell へのアクセスに MFA を必須にしている
このどちらかを既に実施していれば、2025年10月1日までに「要件を満たすための追加設定」は不要です。
| 論点 | Security Defaults 有効テナント |
|---|---|
| Azure / Entra / Intune 管理ポータルへのサインイン | MFA 要求あり（要件クリア） |
| Microsoft 365 管理センターへのサインイン | MFA 要求あり（要件クリア） |
| Azure CLI / PowerShell / IaC / REST API での CRUD 操作 | サインイン時に MFA が必要（要件クリア） |
Microsoft の MFA 必須化スケジュールを整理する（2024〜2025年）
まず、Microsoft が進めている「MFA 必須化」の全体像を整理しておきます。公式ドキュメントでは、Azure / Entra / Intune / Microsoft 365 管理センター、そして Azure CLI / PowerShell 等を対象に、以下のようにフェーズ分けして MFA を必須化しています。
| 時期 | 対象 | 内容 |
|---|---|---|
| 2024年10月以降 （Phase 1） | Azure portal / Microsoft Entra admin center / Microsoft Intune admin center | これらの管理ポータルでいかなる CRUD 操作（作成／読み取り／更新／削除）を行う場合も MFA が必須。段階的に全テナントへ展開。 |
| 2025年2月3日以降 | Microsoft 365 管理センター | Microsoft 365 管理センターへサインインする全ユーザーに MFA を必須化。こちらもテナント単位で段階展開。 |
| 2025年10月1日以降 （Phase 2） | Azure CLI / Azure PowerShell / Azure モバイルアプリ / IaC ツール / Azure SDK / REST API（Control Plane） | リソースの作成・更新・削除（CRUD）操作を行うアカウントに MFA を必須化。 読み取り専用操作（例：リソース一覧取得など）は対象外。 |
なお、Phase 2 の日付は、公式ドキュメントの更新により「2025年10月1日開始」に変更されています（もともと 2025年9月1日と案内された時期もあり）。
また、Phase 1 / Phase 2 ともに、Azure ポータルから「 enforcement を延期する」オプションが提供されており、複雑な環境向けに最大 2026年7月1日まで延長可能とされていますが、最終的には全テナントで MFA が必須です。
Security Defaults とは何か？どこまで守ってくれるのか
Security Defaults の概要
Security Defaults（セキュリティの既定値）は、Microsoft Entra ID（旧 Azure AD）の 無料機能として提供される「最低限のセキュリティ ベースライン」です。
有効化すると、主に次のような設定が一括で適用されます。
- 全ユーザーに MFA 登録を要求
- 次回の対話的サインインから 14 日以内に MFA 登録を完了させるフローが強制される
- 登録が完了しない場合、サインイン時に登録画面が表示され続ける
- Azure Resource Manager（ARM）へのアクセスに MFA を要求
- Azure portal
- Microsoft Entra admin center
- Azure PowerShell
- Azure CLI
- レガシー認証（IMAP/POP/SMTP AUTH など）のブロック
- 旧式プロトコルを使ったサインインが原則拒否される
- 古いメーラーやコピー機のスキャン送信などに影響が出るケースがある
- 推奨 MFA メソッドの標準化
- Microsoft Authenticator アプリ（プッシュ通知）での登録・利用が基本
- OATH TOTP（汎用ワンタイムパスワードアプリ）も利用可能
- テナント全体に対してオン or オフのみ
- ユーザー単位／グループ単位の除外や細かい条件設定は不可
このように、Security Defaults は「MFA とレガシー認証ブロックをまとめて一気に有効化するスイッチ」と考えるとイメージしやすいです。
Security Defaults が今回の MFA 必須化と噛み合うポイント
今回の Microsoft による MFA 必須化と Security Defaults の関係を、もう少し具体的に見てみます。
- 管理ポータル（Azure / Entra / Intune / M365 admin center）
- Security Defaults により、これらのポータルへのアクセス時に MFA が求められる
- Microsoft 365 管理センターの公式ブログでも、「Security Defaults が有効であれば、MFA 必須化の要件を既に満たしている」と明記
- Azure CLI / PowerShell / Azure モバイルアプリ / IaC / REST API / SDK
- Security Defaults により、Azure CLI や Azure PowerShell で Azure Resource Manager にアクセスする際のサインインに MFA が必要
- Phase 2 で Microsoft が強制するのは「リソース管理 CRUD 操作時には必ず MFA クレームを要求する」ことですが、既に MFA が必須になっているアカウントであれば挙動に変化はないと公式ドキュメントが明言
- アカウントの種類
- 管理者／一般ユーザー問わず、管理ポータルや CLI で操作するユーザー アカウントは MFA 必須
- 一方、Entra Connect / Cloud Sync の同期アカウントや、ワークロード ID（Managed Identity / Service Principal）などは今回の強制 MFA の対象外であることも明示されています。
これらの点から、Security Defaults は今回の MFA 必須化の「最低条件」をすでに満たしていると言えます。
「2025年10月1日までに追加作業は必要か？」の答えと注意点
改めて整理すると、2025年10月1日時点で Security Defaults を有効にしているテナントは、以下の点において Microsoft の MFA 必須化要件を満たしています。
- Azure / Entra / Intune 管理ポータルでの操作に MFA を要求
- Microsoft 365 管理センターへのアクセスに MFA を要求（Security Defaults または CA で保護されている）
- Azure CLI / PowerShell / Azure モバイルアプリ / IaC / REST API / SDK でリソース管理操作を行う際のサインインで MFA が必須
従って、「Security Defaults を既に有効化済みである」こと自体が、MFA 必須化メールに対する回答になっています。
ただし、「技術的には満たしているが、運用として見直した方が良いポイント」はあります。ここを見落とすと、2025年秋以降に「要件は満たしているのに現場が困る」という状況になりがちです。
追加で見直しておきたい運用の観点
- 緊急用（ブレークグラス）アカウントの扱い
- Security Defaults では、特定のアカウントだけ MFA から除外することはできません
- 一方、Microsoft は「ブレークグラス アカウントも MFA 必須だが、FIDO2 パスキーや証明書ベース認証を使うべき」としています
- より柔軟な設計をしたい場合は、条件付きアクセスへ移行してポリシーで例外・代替手段を設計するのがおすすめです
- レガシー クライアント／業務機器
- POP/IMAP/SMTP AUTH を使う古いメーラー、複合機、業務アプリは Security Defaults によりブロックされます
- 代替案としては、アプリ パスワードではなく、モダン認証対応アプリ or 送信専用コネクタへの移行を検討する必要があります
- 自動化・スクリプト
- ユーザー アカウントで CLI / PowerShell を実行し、ARM に対してリソース作成・更新を行う場合、MFA のステップアップが挟まるため自動実行が難しくなります
- Microsoft は、こうした用途では Managed Identity や Service Principal 等の「ワークロード ID」への移行を推奨しています
Security Defaults と条件付きアクセスの違いと使い分け
技術的にはどちらでも要件を満たせますが、運用要件によって「Security Defaults のままで良いか」「条件付きアクセスへ移行すべきか」が変わります。
| 項目 | Security Defaults | 条件付きアクセス（CA） |
|---|---|---|
| ライセンス | 不要（Entra ID Free で利用可） | Entra ID P1 以上が必要 |
| 適用対象の柔軟性 | テナント全体のみ（除外不可） | ユーザー／グループ／ロール／アプリ／場所／リスクレベルなどで細かく制御 |
| レガシー認証ブロック | 一括でブロック | ポリシーで対象アプリ・ユーザーを限定しながらブロック |
| ブレークグラス アカウント | 除外設定不可 | ポリシーから除外しつつ、FIDO2 等で「MFA 要件」を満たす設計が可能 |
| 運用の自由度 | 低い（オン or オフ） | 高い（ステップアップ MFA や条件分岐が可能） |
| 今回の MFA 必須化要件との適合性 | 管理ポータル／ARM アクセスに MFA を要求できるため「要件を満たす」 | 適切に設計された CA ポリシーであれば「要件を満たす」 |
ポイントは、Security Defaults から条件付きアクセスへ移行する場合、「必ず Security Defaults と同等以上の保護を CA で再現する」ことです。Microsoft も、Security Defaults を無効にする際は、少なくとも「Secure foundations」カテゴリのテンプレート相当の CA ポリシーを有効化するよう推奨しています。
自動化・スクリプト・サービスアカウントへの影響とベストプラクティス
2025年10月1日以降、CLI / PowerShell / IaC / SDK / REST API を使ったリソース管理操作には MFA が必須になります。これは管理者だけでなく、開発者や DevOps チームにも直接影響します。
Security Defaults を有効にしていても、「どう設計するか」によって運用のしやすさが大きく変わります。
| シナリオ | 推奨認証方式 | MFA 必須化の影響 |
|---|---|---|
| 管理者が手動で Azure ポータルや CLI からリソースを操作 | ユーザー アカウント + MFA（Security Defaults / CA） | サインイン時に MFA が求められるだけ。既に MFA を使っていれば挙動はほぼ変わらない。 |
| 夜間バッチで PowerShell スクリプトを自動実行し、リソースを作成・更新 | Service Principal / Managed Identity（非対話認証） | ワークロード ID は MFA 必須化の対象外。 ユーザー アカウント + パスワードで自動実行している場合は設計見直し必須。 |
| Terraform / Bicep などの IaC から Azure を管理 | Service Principal / Federated Credentials / Managed Identity | ユーザーアカウントに依存しない構成に移行しておけば、MFA 強制の影響を受けにくい。 |
| Azure リソース情報を読み取るだけ（監査レポート等） | ユーザーアカウント + 読み取り専用ロール or ワークロード ID | フェーズ 2 の「強制 MFA」は CRUD のみ対象。読み取り専用操作は強制対象外だが、CA や Security Defaults の設定によってはサインイン時に MFA が必要となる場合もある。 |
自動化・スクリプト系は、「ユーザー アカウントに依存するかどうか」が重要な分かれ目です。ユーザー ベースのサービスアカウントをそのまま使っていると、MFA 必須化のタイミングで動かなくなるリスクが高く、Microsoft もワークロード ID への移行を強く推奨しています。
実務チェックリスト：今すぐ確認したい 4 つのポイント
最後に、「Security Defaults を有効化していれば要件は満たす」とはいえ、現場としてチェックしておきたいポイントを整理します。
1. Security Defaults の有効化状況
- Microsoft Entra 管理センターにグローバル管理者等でサインイン
- ID > 概要 > プロパティ > セキュリティの既定値の管理 を開く
- 「有効」になっているか確認
Microsoft 365 管理センターのブログにもある通り、「Your organization is currently using security defaults.」と表示されていれば、MFA 必須化要件は既に満たしていると判断できます。
2. ユーザーの MFA 登録状況
- Entra 管理センターの「認証方法」レポートから、
- どのユーザーがどの認証方法（Authenticator, FIDO2, SMS 等）を登録しているかを確認
- 未登録ユーザーには MFA 登録の案内を実施（メールテンプレートや社内ポータルで周知）
Security Defaults では、ユーザーが 14 日以内に MFA 登録を完了することが前提なので、「登録済みだが使っていない」のではなく「そもそも登録していない」ユーザーがいないかの確認は重要です。
3. サインインログでの実地確認
- 代表的な管理者アカウントと一般ユーザーアカウントで、Azure ポータルや Microsoft 365 管理センター、CLI などにサインインしてみる
- Microsoft Entra のサインインログで、「MFA 要求の有無」「どのアプリが MFA を要求したか」を確認する
- レガシー認証によるサインインが残っていないか（ある場合はクライアント更新や構成変更が必要）
4. 自動化ジョブ・スクリプト・サービスアカウントの棚卸し
- Azure CLI / PowerShell / DevOps パイプライン / Terraform / Bicep などを洗い出し
- それぞれがユーザー アカウントで動いているのか、ワークロード ID を使っているのかを分類
- ユーザー アカウントに依存しているものは、Phase 2 の MFA 強制までに Managed Identity / Service Principal / Federated Credentials 等への移行計画を立てる
よくある誤解と注意点
「Security Defaults だけでは Microsoft の MFA 必須化に足りない？」
いいえ、足ります。 公式ドキュメントおよび Microsoft 365 管理センターのブログ、さらに Microsoft Q&A での回答を総合すると、Security Defaults もしくは条件付きアクセスで MFA を強制しているテナントは、今回の MFA 必須化要件を満たしていると明言されています。
「ブレークグラス アカウントは MFA から除外してもよい？」
Microsoft のスタンスは明確で、ブレークグラス アカウントも MFA 必須です。ただし、Authenticator + パスワードではなく、FIDO2 パスキーや証明書ベース認証などのフィッシング耐性の高い方法を使うべきとされています。
Security Defaults のままでは除外ができないため、ブレークグラス設計をしっかり行いたい組織では、条件付きアクセスへの移行を検討すると良いでしょう。
「AD Connect の同期アカウントも MFA 対象になるのでは？」
いいえ。ディレクトリ同期アカウントは Security Defaults でも MFA 強制の対象外であり、今回の必須化でも影響を受けないと明言されています。同期処理はこれまで通り動作します。
「外部 IdP（サードパーティ MFA）なら何でも要件を満たす？」
これも注意が必要です。
- レガシーな「Conditional Access のカスタム コントロール」経由の外部 MFA では、今回の必須化要件を満たさないと明記されています
- 代わりに、External authentication methods（外部認証方法） を使って MFA クレーム（multipleauthn）を正しく送る構成にする必要があります
外部 IdP を利用している場合は、「MFA をかけているか」だけではなく、「Entra ID に MFA クレームが届いているか」を確認することが重要です。
まとめ：Security Defaults を有効にしていれば「要件はクリア」、あとは運用の磨き込み
本記事のポイントを最後に整理します。
- Security Defaults を有効にしているテナントは、Microsoft の MFA 必須化要件（2024〜2025年の Phase 1 / Phase 2）を満たしており、2025年10月1日までに追加の技術的対応は不要です。
- ただし、ブレークグラス アカウント、レガシー クライアント、自動化・スクリプト（ユーザー アカウント利用）のような運用面は、今のうちに棚卸しと設計見直しをしておくべきです。
- より柔軟な制御や例外設計が必要な場合は、条件付きアクセスへ移行しつつ、Security Defaults と同等以上のセキュリティ ベースラインを必ず維持することが重要です。
- MFA の方式については、Microsoft が推奨する パスキー（FIDO2）や証明書ベース認証などのフィッシング耐性の高い方法も併せて検討すると、「MFA 必須化」以降の世界でも安全かつ快適な運用が実現できます。
「Security Defaults をオンにしたら終わり」ではなく、必須化をきっかけに ID と認証周りの運用を棚卸しし、より安全で運用しやすい形に整えることが、2025年秋以降の Entra / Azure / Microsoft 365 環境を守る鍵になります。
コメント