Microsoft Entraで多要素認証（MFA）を有効化する場合、最初に押さえるべき結論は「条件付きアクセスを使って、対象ユーザー・対象アプリ・適用条件を段階的に制御する」ことです。単に全ユーザーへ一括適用すると、管理者アカウント、Azure CLIやPowerShellを使う運用、古い認証方式を使う業務アプリでサインイン障害が起きる可能性があります。
特に2026年時点では、Microsoft Entra IDのMFAは「任意の追加設定」ではなく、Azure portal、Microsoft Entra管理センター、Microsoft 365管理センター、Azure CLI、Azure PowerShell、REST API経由の管理操作にも関わる重要な前提になっています。この記事では、公式ドキュメント「Enable Microsoft Entra multifactor authentication」の内容をもとに、変更点、影響範囲、管理者・開発者が確認すべき設定、移行・展開時の注意点を実務向けに整理します。なお、指定されたMicrosoft Learnのチュートリアルページ自体は、公式ページ上で最終更新日が2025年3月4日として表示されています。本稿では、関連する2026年時点の公式情報もあわせて扱います。(Microsoft Learn)
Microsoft EntraのMFA有効化で変わること
Microsoft Entra multifactor authenticationは、ユーザーがサインインするときに、パスワード以外の追加確認を求める仕組みです。たとえば、Microsoft Authenticatorでの承認、確認コード、電話、証明書ベース認証、FIDO2パスキーなどを組み合わせることで、パスワード漏えいだけではアカウントを突破されにくくします。Microsoftの公式ドキュメントでは、MFAがアカウント侵害攻撃の99.2%超をブロックできると説明されています。(Microsoft Learn)
ただし、今回のポイントは「MFAを有効にする手順」だけではありません。実務上は、次の3点を同時に確認する必要があります。
| 確認項目 | 管理者が見るべきポイント | 放置した場合のリスク |
|---|---|---|
| MFAの適用方式 | 条件付きアクセス、セキュリティ既定値、ユーザーごとのMFAのどれを使うか | ポリシーが重複し、想定外のMFA要求や例外漏れが起きる |
| 影響を受けるアプリ | 管理ポータル、Azure CLI、PowerShell、REST API、IaCツールなど | 自動化スクリプトや管理作業が停止する |
| 認証方法の管理 | Authentication methods policyへ移行できているか | 旧MFA/SSPRポリシーの設定が残り、認証方法の制御が複雑化する |
Microsoftのチュートリアルでは、選択したグループに対して条件付きアクセス ポリシーを作成し、特定のサインインイベントでMFAを要求する流れが示されています。条件付きアクセスは、ユーザー、グループ、クラウドアプリ、アクセス制御を組み合わせてMFAを適用できるため、Microsoft Entra MFAの推奨される有効化方法として扱われています。(Microsoft Learn)
管理者がまず理解すべきMFAの3つの有効化方式
Microsoft EntraでMFAを有効化する方法は、大きく分けて3つあります。どれでも同じ結果になるわけではありません。
| 方式 | 向いている環境 | 主な特徴 |
|---|---|---|
| 条件付きアクセス | Microsoft Entra ID P1 / P2を利用している組織 | ユーザー、アプリ、場所、リスク、デバイス条件などで細かく制御できる |
| セキュリティ既定値 | Microsoft Entra ID Freeや小規模環境 | 基本的な保護を簡単に有効化できるが、細かな例外や条件指定はできない |
| ユーザーごとのMFA | 条件付きアクセスもセキュリティ既定値も使わない限定的なケース | ユーザー単位でMFA状態を変更する旧来型の管理方法 |
実務では、Microsoft Entra ID P1またはP2を利用できるなら、条件付きアクセスを第一候補にします。条件付きアクセスを使うと、「管理者が管理ポータルへアクセスするときだけMFAを要求する」「社外ネットワークからのサインインでMFAを求める」「リスクの高いサインインだけ追加認証する」といった制御ができます。(Microsoft Learn)
一方、ユーザーごとのMFAは慎重に扱うべきです。Microsoftの公式ドキュメントでは、条件付きアクセスまたはセキュリティ既定値を使っている場合、ユーザーごとのMFAを有効化・強制しないよう明記されています。条件付きアクセスでMFAを要求しても、ユーザーごとのMFA状態は「Disabled」のまま表示されることがありますが、これは異常ではありません。(Microsoft Learn)
「Disabled」と表示されていてもMFAが無効とは限らない
管理者がよく誤解するのが、ユーザーごとのMFA画面に表示される状態です。
| 表示状態 | 意味 | 注意点 |
|---|---|---|
| Disabled | ユーザーごとのMFAでは有効化されていない | 条件付きアクセスやセキュリティ既定値でMFAが求められる場合がある |
| Enabled | ユーザーごとのMFAに登録されている | 登録完了前はレガシー認証の影響が残る場合がある |
| Enforced | ユーザーごとのMFAが強制されている | 古いアプリではアプリパスワードが必要になる場合がある |
「MFAを有効にしたはずなのに、ユーザー状態がDisabledのまま」という問い合わせは珍しくありません。条件付きアクセス方式では、ユーザーごとのMFA状態を変更しないためです。確認すべき場所は、ユーザーごとのMFA画面ではなく、条件付きアクセス ポリシー、サインインログ、Authentication Detailsです。
影響範囲：管理ポータルだけでなくCLI・PowerShell・APIも確認する
Microsoft Entra MFAの影響範囲は、ブラウザーからの管理ポータル利用だけに限られません。Microsoftの必須MFAに関する公式ドキュメントでは、段階的な適用範囲が示されています。
| フェーズ | 対象 | 主な影響 |
|---|---|---|
| フェーズ1 | Azure portal、Microsoft Entra管理センター、Microsoft Intune管理センター、Microsoft 365管理センター | 管理者や運用担当者のポータルサインインにMFAが必要 |
| フェーズ2 | Azure CLI、Azure PowerShell、Azureモバイルアプリ、IaCツール、REST API、Azure SDK | Azureリソースの作成・更新・削除操作でMFA対応が必要 |
フェーズ2では、Azure CLI、Azure PowerShell、IaCツール、REST APIエンドポイントを使った作成・更新・削除操作が対象になります。読み取り操作はMFA要求の対象外とされていますが、運用スクリプトがリソース作成や設定変更を行う場合は影響を受けます。(Microsoft Learn)
特に注意したいのは、ユーザーアカウントをサービスアカウントのように使っているケースです。Microsoftは、ユーザーIDを自動化用途に使うことを推奨しておらず、マネージドIDやサービスプリンシパルなどのワークロードIDへ移行することを推奨しています。(Microsoft Learn)
管理者が確認すべき設定
Microsoft Entra MFAを展開する前に、次の設定を確認します。重要なのは、いきなり「全ユーザー」「全アプリ」に適用しないことです。
条件付きアクセス ポリシー
Microsoftのチュートリアルでは、Microsoft Entra管理センターで条件付きアクセス ポリシーを作成し、テスト用グループに対してMFAを要求する流れが示されています。基本の構成は次のとおりです。(Microsoft Learn)
| 設定箇所 | 推奨される確認内容 |
|---|---|
| Users or workload identities | 最初はテストグループを対象にする |
| Target resources / Cloud apps | 管理ポータルや対象アプリを明確に選ぶ |
| Grant | Require multifactor authenticationを指定する |
| Enable policy | 本番前はReport-onlyで影響を確認する |
| Exclude | 緊急アクセス用アカウントや例外が必要なアカウントを慎重に設計する |
本番展開前は、Report-onlyモードでサインインログを確認します。Microsoftの公式ドキュメントでも、ロックアウトを避けるためにReport-onlyで影響を把握することが推奨されています。(Microsoft Learn)
認証方法ポリシー
MFAを有効にするだけでは不十分です。ユーザーがどの認証方法を使えるかも管理する必要があります。
Microsoft Entraでは、認証方法をAuthentication methods policyで一元管理する流れになっています。旧来のMFAポリシーやSSPRポリシーでは、誰がどの方法を使えるか、どの用途で使えるかを細かく制御しにくいという問題があります。さらに、Microsoftは旧MFA/SSPRポリシーでの認証方法管理について、2025年9月30日以降は管理できなくなると案内しています。(Microsoft Learn)
確認すべきポイントは次のとおりです。
| 確認項目 | 実務上の判断基準 |
|---|---|
| Microsoft Authenticator | 基本のMFA方法として優先的に展開する |
| SMS / 音声通話 | 利便性は高いが、フィッシング耐性や運用リスクを考慮する |
| FIDO2 / パスキー / 証明書ベース認証 | 管理者や高権限ユーザーに優先導入する |
| Temporary Access Pass | 初回登録、端末紛失、認証方法再登録の支援に使う |
| SSPRとの整合性 | パスワードリセット用の方法とMFA用の方法が矛盾しないようにする |
Microsoftは、Windows Hello for Business、パスキー（FIDO2）、FIDO2セキュリティキー、証明書ベース認証などのフィッシング耐性のある認証方法を、より安全なサインイン体験として推奨しています。(Microsoft Learn)
信頼済みIPと名前付き場所
社内ネットワークからのサインインを例外扱いしたい場合は、信頼済みIPや名前付き場所を確認します。ただし、MFAを単純にバイパスする設定は慎重に扱うべきです。
Microsoft EntraのMFAサービス設定では、信頼済みIP、確認方法、信頼されたデバイスでのMFA記憶などを管理できます。ただし、この画面はレガシーポータルとして扱われています。条件付きアクセスを使う環境では、Named locationsを使って場所ベースの制御を設計するほうが管理しやすくなります。(Microsoft Learn)
たとえば、次のように使い分けます。
| シナリオ | 推奨される考え方 |
|---|---|
| 本社固定IPからのアクセス | Named locationsに登録し、条件付きアクセスで制御 |
| VPN経由のアクセス | VPN出口IPだけでなく、端末状態やリスクも組み合わせる |
| 管理者アクセス | 社内IPでもMFAを省略しすぎない |
| 海外拠点・出張 | 国/地域条件だけに頼らず、認証強度やデバイス準拠も併用する |
「社内からなら安全」と考えてMFAを広く除外すると、VPNアカウント侵害や内部不正への耐性が下がります。例外は最小限にし、管理者や高権限操作には強い認証を残す設計が現実的です。
開発者が確認すべきポイント
MFA有効化は、管理者だけの作業ではありません。Azure CLI、PowerShell、SDK、REST API、IaCツールを使う開発者やSREにも影響します。
ROPCフローを使っていないか確認する
Microsoftの公式ドキュメントでは、OAuth 2.0のResource Owner Password Credentials（ROPC）フローはMFAと互換性がないと説明されています。MFAが有効になると、ユーザー名とパスワードを直接渡してトークンを取得する実装は例外を返す可能性があります。(Microsoft Learn)
確認すべき実装例は次のとおりです。
| 技術領域 | 確認すべき実装 |
|---|---|
| MSAL | AcquireTokenByUsernamePassword系APIを使っていないか |
| Azure Identity | UsernamePasswordCredentialを使っていないか |
| 環境変数 | AZURE_USERNAMEとAZURE_PASSWORDを使った認証に依存していないか |
| CI/CD | 個人ユーザーの資格情報でAzureへログインしていないか |
| IaC | Terraform、Bicep、スクリプトがユーザー認証前提になっていないか |
対策は、ユーザー名・パスワード方式から、マネージドID、サービスプリンシパル、ワークロードIDフェデレーション、証明書ベース認証などに移行することです。個人ユーザーのMFAを回避するために例外を広げるのではなく、自動化の認証方式そのものを変えるべきです。
CLIとPowerShellはバージョンも確認する
Microsoftは、必須MFAへの互換性を高めるため、Azure CLI 2.76以降、Azure PowerShell 14.3以降の利用を案内しています。古いクライアントでは、MFAが必要な操作でエラーが出たり、MFAプロンプトが適切に表示されなかったりする可能性があります。(Microsoft Learn)
開発チームや運用チームには、次のようなチェックを依頼します。
| 対象 | 確認コマンド例 | 見るべき点 |
|---|---|---|
| Azure CLI | az version | バージョンが古すぎないか |
| Azure PowerShell | Get-Module Az -ListAvailable | Azモジュールのバージョン |
| CI/CD環境 | 実行ログ、認証方式、サービス接続 | 個人アカウント依存がないか |
| IaC | plan/apply時の認証方式 | ユーザーMFAが必要な構成になっていないか |
展開手順：小さく始めて、ログで確認しながら広げる
Microsoft Entra MFAは、段階展開が基本です。特に既存環境では、いきなり全ユーザーへ適用するより、対象を分けて検証するほうが安全です。
| フェーズ | 実施内容 | 判断基準 |
|---|---|---|
| 事前調査 | 管理者、開発者、サービスアカウント、レガシーアプリを棚卸しする | MFA要求で止まる業務が見えているか |
| パイロット | IT部門や一部ユーザーに条件付きアクセスをReport-onlyで適用 | サインインログで影響を確認できるか |
| 小規模展開 | テストグループにOnで適用 | 問い合わせ内容、登録率、失敗率を確認 |
| 対象拡大 | 部門単位・役割単位で段階的に広げる | ヘルプデスク対応が追いつくか |
| 全体最適化 | 認証方法ポリシー、SSPR、条件付きアクセスを整理 | 重複ポリシーや不要な例外が残っていないか |
Microsoftの展開ガイダンスでも、小規模なパイロットユーザーから始め、登録動作や影響を評価したうえでグループを追加する流れが示されています。(Microsoft Learn)
ユーザーへの案内も設定の一部と考える
MFA展開で失敗しやすいのは、技術設定よりもユーザー案内です。
よくある失敗は次のとおりです。
| 失敗例 | 起きる問題 | 対策 |
|---|---|---|
| 事前通知なしでMFAを有効化 | 「サインインできない」という問い合わせが急増する | 適用日、対象者、登録手順を事前案内する |
| 認証方法を1つしか登録させない | 端末紛失時にロックアウトする | 予備の認証方法を登録させる |
| SMSだけに依存する | 端末変更、電波状況、セキュリティ面で弱い | Authenticatorやパスキーを優先する |
| 管理者アカウントの例外が多い | 高権限アカウントが攻撃対象になる | 管理者ほど強いMFAを必須にする |
ユーザーには「MFAが必要です」だけでなく、「どのアプリで求められるか」「どの方法を登録すべきか」「スマートフォンを交換した場合どうするか」まで伝える必要があります。
サインインログで確認すべき項目
MFA展開後は、サインインログを確認して、期待どおりにMFAが動作しているかを見ます。Microsoft Entraのサインインログでは、どの条件付きアクセス ポリシーがMFAプロンプトを発生させたか、どの認証方法が使われたか、成功・失敗理由などを確認できます。(Microsoft Learn)
確認すべき項目は次のとおりです。
| ログ項目 | 見るべきポイント |
|---|---|
| Conditional Access | 想定したポリシーが適用されているか |
| Authentication Details | どの認証方法が使われたか |
| Result | MFA失敗が特定ユーザーや特定アプリに偏っていないか |
| Application | 管理ポータル、CLI、PowerShell、APIのどこで要求されたか |
| Location / Device | 想定外の場所や非準拠デバイスからのアクセスがないか |
ログ確認をしないまま展開すると、「一部のユーザーだけ失敗している」「特定のアプリだけMFAを通過できない」「例外設定が効きすぎている」といった問題を見逃します。
移行時の注意点
ユーザーごとのMFAから条件付きアクセスへ移行する
既存環境でユーザーごとのMFAを使っている場合は、条件付きアクセスへ移行する計画を立てます。Microsoftの展開ガイダンスでは、ユーザーごとのMFAが有効または強制されているユーザーについて、条件付きアクセスを有効化したうえで、ユーザーごとのMFAを手動で無効化することが推奨されています。(Microsoft Learn)
移行時は、次の順序が安全です。
| 順序 | 作業 |
|---|---|
| 1 | 現在のユーザーごとのMFA状態をエクスポートする |
| 2 | 条件付きアクセスで同等以上のMFAポリシーをReport-only作成する |
| 3 | サインインログで影響を確認する |
| 4 | パイロットユーザーで条件付きアクセスをOnにする |
| 5 | 問題がなければ対象を拡大する |
| 6 | ユーザーごとのMFAを段階的に無効化する |
「ユーザーごとのMFAを先に無効化してから条件付きアクセスを作る」のは避けるべきです。一時的にMFAの保護が抜ける可能性があります。
旧MFA/SSPRポリシーからAuthentication methods policyへ移行する
旧MFAポリシーとSSPRポリシーで認証方法を管理している場合、Authentication methods policyへ整理します。旧ポリシーと新ポリシーは設定が同期されないため、複数の場所で認証方法が有効になっていると、管理者の意図と異なる方法をユーザーが登録できることがあります。(Microsoft Learn)
移行時は、次の3つを記録してから進めます。
- 旧MFAポリシーで有効な方法
- SSPRポリシーで有効な方法
- Authentication methods policyで有効な方法
移行後は、「どのユーザーが、どの用途で、どの認証方法を使えるか」をAuthentication methods policyで説明できる状態にするのが理想です。
実務でおすすめのポリシー設計例
全社共通でそのまま使える唯一の正解はありませんが、多くの組織では次のような考え方が現実的です。
| 対象 | 推奨ポリシー |
|---|---|
| グローバル管理者、特権ロール保持者 | フィッシング耐性のあるMFAを必須化 |
| 一般ユーザー | Microsoft Authenticatorを基本に、必要に応じてSMSや音声を補助的に許可 |
| 開発者・運用担当者 | CLI、PowerShell、API操作を想定し、個人資格情報依存を排除 |
| 自動化・CI/CD | ユーザーアカウントではなく、マネージドIDやサービスプリンシパルへ移行 |
| 緊急アクセスアカウント | 例外ではなく、パスキーや証明書ベース認証など強いMFAを設定 |
| レガシーアプリ利用者 | 影響範囲を洗い出し、アプリ側のモダン認証対応を検討 |
重要なのは、「MFAを全員に求めるかどうか」ではなく、「どのリスクに対して、どの強度の認証を求めるか」です。管理者、高権限操作、外部ネットワーク、リスクの高いサインインには、より強い認証を求める設計が適しています。
よくある疑問
Microsoft Entra MFAを有効化すると、全アプリで毎回MFAが必要になる？
条件付きアクセスの設定次第です。対象ユーザー、対象アプリ、場所、デバイス、リスク、セッション制御によってMFA要求のタイミングを調整できます。ただし、Microsoftが必須MFAを適用する対象の管理ポータルやAzure管理操作では、組織側の例外よりも必須要件が優先される場合があります。(Microsoft Learn)
セキュリティ既定値だけで十分？
小規模環境やMicrosoft Entra ID Freeでは有効な選択肢です。ただし、特定のユーザーやアプリ、ネットワーク条件に応じた細かな制御はできません。業務アプリ、管理者ロール、開発者環境を分けて管理したい場合は、Microsoft Entra ID P1/P2と条件付きアクセスの利用を検討します。(Microsoft Learn)
SMS認証は使ってよい？
完全に禁止すべきとは限りませんが、管理者や高権限ユーザーの主要なMFA方法としては推奨しにくい選択です。SMSは利便性が高い一方、フィッシング耐性や回線・端末依存の面で課題があります。可能であれば、Microsoft Authenticator、パスキー、FIDO2セキュリティキー、証明書ベース認証へ寄せていく方針が安全です。
緊急アクセスアカウントはMFA例外にしてよい？
以前は緊急アクセス用アカウントをMFA例外にする運用もありましたが、Microsoftの必須MFAではブレークグラスアカウントもMFA対象になると説明されています。Microsoftは、これらのアカウントにパスキー（FIDO2）や証明書ベース認証を設定することを推奨しています。(Microsoft Learn)
次に取るべき行動
Microsoft EntraのMFA有効化は、単なるセキュリティ設定ではなく、管理者アクセス、ユーザー体験、開発・運用自動化に影響する認証基盤の変更です。まずは次の順序で進めると、トラブルを抑えながら展開できます。
- 現在のMFA方式を確認する
条件付きアクセス、セキュリティ既定値、ユーザーごとのMFAが混在していないか確認します。 - 管理者・開発者・自動化アカウントを棚卸しする
Azure CLI、PowerShell、REST API、IaC、CI/CDでユーザー資格情報を使っていないか確認します。 - Authentication methods policyを確認する
旧MFA/SSPRポリシーからの移行状況を確認し、認証方法の管理を一元化します。 - Report-onlyで条件付きアクセスを検証する
いきなり本番適用せず、サインインログで影響を確認します。 - パイロットから段階展開する
登録率、失敗率、問い合わせ内容を見ながら、対象グループを広げます。
Microsoft Entra MFAの展開で最も避けたいのは、「有効化したが、誰に何が起きるか分からない」状態です。設定前に影響範囲を洗い出し、条件付きアクセス、認証方法ポリシー、サインインログをセットで確認すれば、セキュリティを高めながら業務停止のリスクを抑えられます。
コメント