MENU

Microsoft Entra ID 無料版でMFA必須化に対応する方法｜セキュリティ既定値だけで足りるか解説

Azure

2025年10月1日から始まる Azure／Microsoft 365 管理ポータルへの「MFA必須化」通知を受けて、「うちは Entra ID 無料版でセキュリティ既定値だけど、本当に要件を満たせているのか？」と心配している管理者は少なくありません。本記事では、公式情報と実務の観点から、セキュリティ既定値でどこまで対応できるのかを徹底的に整理します。

目次

2025年10月1日の「MFA必須化」で何が変わるのか

まずは、Microsoft から届いている「Action required: Enable multifactor authentication for your tenant by 1 October 2025」という趣旨のメールで、何が求められているのかを整理します。

Microsoft は Azure や Microsoft 365 の管理ポータル・管理系 API に対して、段階的に「MFAを必須にする」施策（いわゆる Mandatory MFA）を展開しています。2024〜2025年にかけては、以下のような流れで強制が進んでいます。

  • フェーズ1：Azure ポータル／Entra 管理センター／Intune 管理センター／Microsoft 365 管理センターへのサインインに対して MFA を必須化
  • フェーズ2：Azure Resource Manager（ARM）レイヤーの操作（Azure CLI・Azure PowerShell・REST API・IaC ツール等によるリソース操作）にも MFA 要求を拡大（2025年10月1日開始）
  • テナント単位で開始日を少し先延ばしするオプションはあるが、最終的にはすべてのテナントで MFA が必須になる

Microsoft の公式ドキュメントでは、対象アプリケーション（Azure ポータル／Entra 管理センター／Intune 管理センター／Microsoft 365 管理センター 等）にサインインする すべてのユーザー が MFA 完了済みであることが求められ、管理者だけが対象というわけではないとはっきり書かれています。

さらに、2025年10月1日から始まるフェーズ2では、Azure Resource Manager を経由したリソース管理操作（VM・ストレージ・ネットワークなどの作成／更新／削除）を行う すべてのユーザー に、MFA 付きのサインインが求められます。

一方で、Microsoft Q&A では、2025年10月1日の MFA 必須化メールについて「ポータル側の強制に備えて、管理者が事前に MFA を有効化しているかを注意喚起する 情報提供目的 のメッセージであり、すでに MFA を構成しているテナントは心配しなくてよい」という趣旨の回答も公開されています。

つまり、このメールが意味するところは：

  • 「新しい厳格な MFA の世界に備えて、今のうちに MFA を有効化しておいてください」という事前通告
  • すでにポータルや Azure 管理操作に対して MFA を要求できる状態であれば、特別な追加作業は基本的に不要

では、Entra ID 無料版でセキュリティ既定値を有効にしているだけで、本当にこの『MFA必須化』に対応できていると言えるのか？ というのが本題です。

結論：Entra ID 無料版でも「セキュリティ既定値が有効」なら要件を満たせる

先に結論から言うと、

Microsoft Entra ID（無料プラン）のテナントで「セキュリティ既定値（Security defaults）」を有効化していれば、2025年10月1日以降の「MFA必須化」の要件を満たせます。

その理由は、Microsoft の公式ドキュメントで次のような流れが明確に示されているからです。

  • セキュリティ既定値は、Entra ID Free を含む全テナントで無料で使えるベースラインのセキュリティ設定 である
  • セキュリティ既定値を有効にすると：
    • すべてのユーザーに MFA 登録を要求
    • 管理者ロールのユーザーには、サインインのたびに MFA を要求
    • Azure ポータル／Entra 管理センター／Azure PowerShell／Azure CLI にアクセスする すべてのユーザー に MFA を要求
    • レガシー認証（POP/IMAP/SMTP など MFA 非対応プロトコル）をブロック
  • Mandatory MFA の計画文書では、「条件付きアクセスが使えない場合は セキュリティ既定値を有効化して準備せよ」と明示されている
  • すでに対象アプリケーションに対して MFA を必須にしているテナントは、「Mandatory MFA による追加の変化はほぼない」と書かれている

つまり、無料プランで条件付きアクセスが使えなくても、

  • セキュリティ既定値が有効になっており
  • 管理者・対象ユーザー全員が MFA 登録を完了していて
  • Azure ポータル／Entra 管理センターや Azure PowerShell/CLI で実際に MFA が要求されている

のであれば、Microsoft の求める「MFA必須化」の要件を事実上クリアしていると考えて問題ありません。

ライセンス別の実装パターンと「MFA必須化」の関係

構成パターンMFA制御の方法MFA必須化への適合度コメント
Entra ID Free＋セキュリティ既定値有効全ユーザー登録必須、管理者は毎回MFA、Azureポータル等は全ユーザーMFA◎ 準拠本記事の想定パターン。通知への対応として十分。
Entra ID Free＋セキュリティ既定値無効一部ユーザーにのみ従来型のMFA設定、またはMFA未設定△／× 不足の可能性大少なくとも管理ポータルにアクセスする全ユーザーに MFA が必須になるよう、設定の見直しが必要。
Entra ID P1/P2＋条件付きアクセスCA ポリシーでアプリ／場所／デバイス別に MFA を設計◎ 準拠（設計次第）より細かい制御・例外設定が可能。Mandatory MFA の要件も満たしやすい。
外部 IdP＋サードパーティ MFAフェデレーション連携で外部 MFA を利用○ 準拠可能外部 IdP から MFA のクレームを正しく送る必要あり。設計と検証のハードルは高め。

セキュリティ既定値が実際にやっていること

ここからは、「セキュリティ既定値を有効にするとテナント内部で何が起きているのか」をもう少し具体的に見ていきます。

1. 全ユーザーに対して MFA 登録を必須化

セキュリティ既定値が有効になると、テナント内のすべてのユーザー（ゲストを含む）が、次のような流れで MFA 登録を求められます。

  • サインイン時に「セキュリティ情報を設定してください」といった画面が表示される
  • Microsoft Authenticator アプリ（または OATH TOTP アプリ）を登録する必要がある
  • 2024年7月以降は、旧来の「14日間の猶予期間」が廃止され、より早い段階で登録が求められる
  • 未登録のまま放置すると、最終的には登録を完了しない限りサインインできなくなる

公式ドキュメントでは、MFA とレガシー認証のブロックを組み合わせることで、99％以上のアカウント侵害を防げるというデータも示されています。

2. 管理者ロールは「毎回のサインインでMFA必須」

セキュリティ既定値が有効な状態では、グローバル管理者・セキュリティ管理者・ユーザー管理者などの特権ロールを持ったアカウントは、登録完了後、サインインのたびに必ず MFA を求められます。

これは、Mandatory MFA の趣旨（管理用ポータルへのアクセスを守る）と完全に一致する挙動です。そのため、管理者については「毎回MFAがかかっているか」を確認しておけば、通知メールが想定しているリスクには原則として対応できています。

3. Azure ポータル／Entra 管理センター／Azure CLI などは「全ユーザーにMFA必須」

セキュリティ既定値の重要なポイントとして、Azure Resource Manager を利用するサービスへのアクセスは、管理者かどうかに関係なく、すべて MFA 必須 という点があります。

対象となる代表的なサービスは以下の通りです。

  • Azure ポータル
  • Microsoft Entra 管理センター
  • Azure PowerShell
  • Azure CLI

Mandatory MFA フェーズ2がまさにこの Azure Resource Manager レイヤーの操作に対して MFA を強制する施策であることを考えると、セキュリティ既定値はこの要件をそのまま先取りしているとも言えます。

4. レガシー認証（Basic 認証）を一括でブロック

セキュリティ既定値は、POP/IMAP/SMTP や古い Office クライアントなど、いわゆる「レガシー認証」を一律でブロックします。

レガシー認証は MFA をサポートしないため、せっかく MFA ポリシーを設けても、古いプロトコル経由であれば攻撃者に突破されてしまいかねません。セキュリティ既定値を有効にすると、この「抜け道」がまとめて塞がれるため、Mandatory MFA 時代を見据えても非常に重要な要素になります。

逆に、レガシー認証で動いている古いアプリやスクリプトが残ったままセキュリティ既定値を有効にすると、いきなり動かなくなる可能性があるので注意が必要です。

5. 「必要に応じて」一般ユーザーにも MFA を要求

管理者以外の一般ユーザーについては、Microsoft 側の判断（サインイン元の場所・デバイス・タスク等）に応じて、必要なタイミングで MFA を要求 する仕様になっています。

そのため、管理者のように「毎回必ず MFA」というわけではありませんが、少なくとも Azure ポータルや Entra 管理センターなどの高リスクな操作では確実に MFA がかかるため、Mandatory MFA の目的には合致しています。

セキュリティ既定値と条件付きアクセスの違い

項目セキュリティ既定値条件付きアクセス（Entra ID P1+）
ライセンス不要（Entra ID Free で利用可）P1 または P2 が必要
設定パターンオン or オフのみアプリ・ユーザー・場所・デバイスなど細かく定義可能
MFAの要求タイミング管理者は毎回／一般ユーザーは「必要に応じて」「常にMFA」「社外からのみMFA」など自由に設計可能
ユーザー除外基本的に不可（全ユーザー一律）ブレークグラスや特定アカウントを除外可能
運用の柔軟性シンプルだが融通は利かない大規模・複雑な環境向き

無料テナントで「とりあえず Mandatory MFA の要件を満たしたい」という目的であれば、セキュリティ既定値で十分、というのが実務的な結論になります。

実務でのポイント：この状態なら「MFA必須化OK」と言える

では、実際の運用で「うちは要件を満たしている」と自信を持って言うために、どこを確認しておくべきでしょうか。ここではチェックリスト形式で整理します。

確認項目確認場所OK の目安
セキュリティ既定値が有効かEntra 管理センター
［ID］→［概要］→［プロパティ］→［セキュリティ既定値の管理］		「セキュリティ既定値：有効」になっている
全ユーザーの MFA 登録状況Entra 管理センター
［ID］→［保護］→［認証方法］→使用状況レポート など		管理ポータルを利用するユーザーが、少なくとも 1 つの MFA 手段を登録済み
Azure ポータル等で MFA が実際に要求されているか［ID］→［監視とトラブルシューティング］→［サインインログ］対象ユーザーの Azure ポータル／Entra 管理センターのサインインで「MFA 要求」が記録されている
レガシー認証の利用有無サインインログ／セキュリティレポートPOP/IMAP/SMTP などのレガシープロトコルによるサインインが発生していない
ブレークグラスアカウントの運用ユーザー一覧＋監査ログ緊急用アカウントも MFA 登録済みで、パスワード・復旧情報の保管ルールが明確

1. セキュリティ既定値が「有効」になっているか

まずは大前提として、テナントでセキュリティ既定値が本当に有効になっているかを確認します。手順は次の通りです。

  1. Microsoft Entra 管理センター（https://entra.microsoft.com）にグローバル管理者などでサインイン
  2. 左メニューで［ID（Identity）］→［概要（Overview）］→［プロパティ（Properties）］を開く
  3. 画面下部の「セキュリティ既定値」のセクションで「有効（Enabled）」になっていることを確認

「無効」の場合は、Mandatory MFA に備えるためにも、できるだけ早く有効化し、あわせてレガシー認証の利用状況を確認することをおすすめします。

2. 全ユーザーの MFA 登録状況を洗い出す

セキュリティ既定値を有効にしただけでは、「未登録ユーザー」が残っている可能性があります。Mandatory MFA では、対象アプリケーションにサインインする すべてのユーザー が MFA を利用できることが前提です。

実務では、次のようなステップで「未登録者の洗い出し」と「登録完了」の追い込みを行うと運用しやすくなります。

  • 認証方法レポートや PowerShell（Get-MgUserAuthenticationMethod など）を使って、MFA 手段の未登録ユーザーを抽出
  • 対象ユーザーに対して、MFA 登録手順書と期限付きの案内メールを送付
  • 期限後も未登録のユーザーは、個別にフォロー（上長経由での依頼など）
  • 最終的に、「管理ポータルにアクセスするユーザーは全員 MFA 登録済み」という状態を目指す

ユーザーには、https://myprofile.microsoft.com の「セキュリティ情報」ページから登録してもらうのがもっとも分かりやすい方法です。

3. サインインログで「本当に MFA が効いているか」を検証

「設定したつもり」ではなく、実際に MFA が効いていることを確認するには、Entra のサインインログを見るのが一番確実です。Mandatory MFA のドキュメントでも、サインインログで MFA 要求元を確認することが推奨されています。

代表的な確認方法は次の通りです。

  1. Entra 管理センターで［ID］→［監視とトラブルシューティング］→［サインイン］を開く
  2. アプリケーションで「Azure portal」「Microsoft Entra admin center」などを選択してフィルター
  3. 対象ユーザーのサインインを開き、「条件付きアクセス」や「認証の詳細」タブで「MFA が要求されたか」「どのポリシー／機能が要求したか」を確認

ここで「MFA 要求元」が「Security defaults」や「Azure portal」側の強制であることが確認できれば、Mandatory MFA の要件に沿った形で MFA が動作していると判断できます。

4. レガシー認証を使う古いクライアント／スクリプトの洗い出し

セキュリティ既定値は、レガシー認証をまとめてブロックします。これはセキュリティ上は大きなメリットですが、次のようなケースでは業務影響が発生することもあります。

  • 古い MFP（複合機）が、SMTP AUTH（LOGIN/PLAIN）のみ対応でメール送信している
  • 古いスクリプトが Basic 認証で Exchange Online や SharePoint Online にアクセスしている
  • Outlook 2010 など、モダン認証非対応のクライアントが残っている

サインインログで「クライアントアプリ」や「プロトコル」が「POP/IMAP/SMTP」や「レガシー認証」となっているイベントが残っていないか確認し、もしあれば、次のような対策を検討します。

  • 複合機やアプリケーションをモダン認証対応の新しいバージョンに更新
  • アプリケーション認証を、ユーザーアカウントではなくアプリ登録＋証明書やクライアントシークレットに移行
  • どうしても移行できない場合は、専用テナント・専用メールゲートウェイの導入など、リスクを限定する設計を検討

5. ブレークグラス（非常用）アカウントの扱い

Mandatory MFA の FAQ では、ブレークグラスアカウントも原則として MFA を満たす必要があることが明記されています。

セキュリティ既定値は、特定ユーザーだけを MFA 対象外にするような除外設定ができません。そのため、ブレークグラスアカウントも他のユーザーと同様に MFA 登録が必要になります。

実務上は、次のようなルールを決めておくと安心です。

  • ブレークグラスアカウントは 2 アカウント用意し、どちらもクラウド専用アカウントにする
  • MFA は Authenticator アプリまたは FIDO2 パスキー／証明書ベース認証など、より堅牢な方法を採用
  • 資格情報（ID／パスワード／リカバリーコード）は物理的に分離して保管し、アクセス記録を残す
  • 定期的にサインインテストを行い、「いざというときに本当に使えるか」を確認

よくある誤解と注意点

「セキュリティ既定値＝毎回MFA」ではない

よくある誤解として、「セキュリティ既定値を有効にしたのに、一般ユーザーは毎回 MFA が表示されないから、MFA が効いていないのでは？」という相談があります。

実際には、

  • 管理者ロール → サインインのたびに MFA
  • 一般ユーザー → Microsoft が必要と判断したタイミングで MFA（ロケーション・デバイス・タスクなどを考慮）

という動きになっており、「毎回MFA」ではありません。毎回必ず MFA を求めたい場合は、Entra ID P1 以上を導入し、条件付きアクセスで「常にMFA」を設計する必要があります。

セキュリティ既定値 ON でも「MFAステータス：無効」に見えることがある

古い「ユーザーごとの MFA 管理画面」を見ると、セキュリティ既定値や条件付きアクセスで MFA を制御している場合でも、ステータスが「無効」のまま表示されることがあります。

これは仕様であり、セキュリティ既定値のドキュメントにも、「セキュリティ既定値や条件付きアクセスで MFA を使っている場合、ユーザーは『無効』と表示されるのが正しい」と説明されています。

したがって、MFA が効いているかどうかは、MFA ステータス画面ではなく、サインインログや認証方法レポートで確認するのが正しい見方です。

テスト用テナントでも Mandatory MFA の対象外にはならない

Mandatory MFA の FAQ では、「テスト用テナントでも MFA は必須か？」という質問に対して、「すべての Azure テナントが対象であり、テスト環境であっても例外ではない」と明記されています。

個人検証用のテナントや小規模なサンドボックス環境でも、Azure ポータルや Entra 管理センターにサインインする以上、MFA を有効にしておく必要があります。Entra ID Free＋セキュリティ既定値は、こうした小さなテナントにもフィットする現実的な選択肢です。

より厳格な制御が必要な場合は Entra ID P1 以上＋条件付きアクセス

ここまでは「無料プラン＋セキュリティ既定値で Mandatory MFA の要件を満たす」ことを前提に話してきましたが、中には次のような要件を持つ組織もあるでしょう。

  • 会社支給 PC 以外からのアクセスには常に MFA を要求したい
  • 特定アプリ（経理システムなど）は、社内ネットワークからでも必ず MFA を要求したい
  • 海外からのアクセスはブロック、または必ず強力な MFA 手段（FIDO2 など）を使わせたい

このような場合は、Entra ID P1 以上を導入し、条件付きアクセスでポリシー設計を行う必要があります。

代表的な高度化例：

  • 社外・モバイルデバイスからのサインインには常に MFA を強制
  • 特定の管理アプリに対しては、通常の MFA ではなく FIDO2 パスキーや証明書ベース認証を必須化
  • サインインリスクが高い場合は、MFA に加えてパスワードリセットを要求する（P2＋Entra ID Protection）
  • 「System-preferred MFA」を使い、最も強力な認証手段が自動的に選ばれるようにする

Mandatory MFA の要件自体は、セキュリティ既定値でも満たせますが、業務要件に合わせた「使いやすさとセキュリティのバランス調整」まで行いたい場合は、条件付きアクセスがほぼ必須になります。

小〜中規模組織向け：現実的な進め方のサンプル

最後に、従業員 50 人程度の小〜中規模組織で、Entra ID Free を使っているケースを想定した「現実的な進め方の例」を示します。

ステップ1：現状把握（1〜2週間）

  • セキュリティ既定値の状態を確認（有効／無効）
  • サインインログでレガシー認証の有無を確認
  • 管理ポータルを利用するユーザー（情シス・開発者・一部の担当者）をリストアップ
  • 既に MFA 登録済みのユーザー／未登録のユーザーを大まかに把握

ステップ2：ユーザーへの周知とガイド作成（1〜2週間）

  • 「いつから」「どこへサインインする際に」「どんな画面が出るのか」を図入りで説明した簡易マニュアルを作成
  • スマホを持たないユーザーがいる場合の代替手段（OATH TOTP アプリや FIDO2 セキュリティキーなど）を検討
  • ブレークグラスアカウントの方針（ID 名、保管方法、定期テストの頻度）を決定

ステップ3：セキュリティ既定値の有効化と登録追い込み（2〜4週間）

  • レガシー認証を使うアプリ・スクリプトの移行目処が立ったら、セキュリティ既定値を「有効」に切り替え
  • 数日〜数週間かけて、ユーザーが MFA 登録を完了できるようサポート（ヘルプデスク・FAQ・ショート動画など）
  • 登録状況をレポートや PowerShell でウォッチし、未登録ユーザーに個別フォロー

ステップ4：Mandatory MFA 開始前の最終チェック

  • Azure ポータル／Entra 管理センター／Azure CLI／Azure PowerShell を利用するユーザーについて、全員が実際に MFA 付きでサインインできるかテスト
  • サインインログで、「MFA が要求されているか」「エラーやブロックが発生していないか」を確認
  • レポートを PDF などにエクスポートしておき、「Mandatory MFA 対応状況の証跡」として保管

ここまでできていれば、2025年10月1日以降に Mandatory MFA が始まっても、大きな混乱なく乗り切れるはずです。

まとめ：無料テナントでも「やるべきこと」をやっていれば心配しすぎなくてよい

本記事のポイントを整理すると、次のようになります。

  • セキュリティ既定値が有効な Entra ID Free テナントであれば、Mandatory MFA の要件を満たすことができる。
  • セキュリティ既定値は、全ユーザーに MFA 登録を求め、管理者には毎回、Azure ポータルや Entra 管理センター／Azure PowerShell／Azure CLI には全ユーザーに MFA を要求し、レガシー認証もブロックする。
  • Microsoft 公式ドキュメントでも、「条件付きアクセスが使えない場合はセキュリティ既定値の有効化で Mandatory MFA に備えるべき」と明記されている。
  • 実務的には、「セキュリティ既定値が有効」「管理ポータル利用者が全員 MFA 登録済み」「サインインログで MFA 要求の実績が確認できる」状態になっているかをチェックすればよい。
  • より細かい制御（アプリ別・場所別・デバイス準拠など）が必要な場合のみ、Entra ID P1 以上＋条件付きアクセスへのアップグレードを検討する。

通知メールの文面だけを見ると少し不安になりますが、セキュリティ既定値をきちんと有効化し、ユーザーの MFA 登録とログでの確認まで行っていれば、無料テナントでも十分に要件を満たせます。まずは自分のテナントの状態を落ち着いて確認し、足りない部分を一つずつ埋めていきましょう。

Azure
Azure MFA Microsoft Entra ID 条件付きアクセス セキュリティ既定値

この記事を書いた人

佐藤健司のアバター 佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

関連記事

コメント

コメントする

目次