Microsoft 365／Microsoft Entra IDのメッセージセンター通知「MC678069」を見て、「Per-user MFA（ユーザー単位のMFA設定）がなくなるのでは？」と不安になる管理者は少なくありません。本記事では“廃止される部分”と“残る部分”を切り分け、Entra ID Freeでも現実的に運用を続けるための移行手順と設計ポイントを整理します。
結論：期限までに必要なのは「認証方法の管理場所の移行」。Per-user MFAのユーザー状態は別物
MC678069の文脈で語られているのは、従来の「レガシーMFA/SSPRポリシー」側で行っていた認証方法（SMS、音声通話、Authenticator など）の管理を、統合された認証方法ポリシー（Authentication methods policy）へ集約することです。Microsoft Learnでは、2025年9月30日以降はレガシーMFA/SSPRポリシーで認証方法を管理できなくなると明記されています。
一方で、ユーザーごとに「Disabled / Enabled / Enforced」を切り替えるPer-user MFAのユーザー状態（いわゆるEnforcement）は、同じ“レガシー”という言葉で括られがちですが、「認証方法の管理」とは役割が異なる機能です。Microsoft Learnには、Conditional Access が使えない（＝Entra ID Free等）場合の選択肢として、必要に応じて各アカウントをPer-user MFAで有効化する方法が掲載されています。
要点だけ先に：MC678069で“なくなる”のは「電話/SMS/Authenticatorなどの許可設定をレガシー画面で触れること」です。ユーザーごとのMFA必須/不要（Disabled/Enforcedなど）を決める仕組みは別で、Freeテナントの運用手段として現在もドキュメントに載っています。
| 混同されやすい項目 | 何を決めるもの？ | MC678069の影響 | 移行先 |
|---|---|---|---|
| Per-user MFAのユーザー状態（Disabled/Enabled/Enforced） | そのユーザーのサインインで「MFAを求めるか」をユーザー単位で制御 | 認証方法の移行とは別枠。Free環境の運用手段として現行ドキュメントに記載あり | （移行なし）必要なら継続利用 |
| Per-user MFAのService settings（検証オプション等） | 電話/SMS/Authenticator等「使える認証方法の種類」をテナント全体で定義 | 2025/9/30以降、レガシー側で認証方法を管理できなくなる | 認証方法ポリシーへ集約 |
| SSPR側の認証方法設定（Password reset settings） | パスワードリセットで使える方法（メール、SMS等） | 同上（レガシー側の認証方法管理ができなくなる） | 認証方法ポリシーへ集約（※一部例外あり） |
MC678069の「2025年9月30日までにやること」を噛み砕く
Microsoft Learnの説明では、レガシーMFA/SSPRポリシーは「テナント内の全ユーザーに対して、いくつかの認証方法をまとめて有効化する」古い管理方法であり、誰がその方法を使えるか（対象ユーザー）や、方法の使われ方を細かく制御できないとされています。そのため、認証方法の管理は認証方法ポリシーへ一本化されます。
ポイントは次の2点です。
- 期限（2025年9月30日）以降は、レガシー側で「SMSを許可する／しない」「電話を許可する／しない」といった認証方法のON/OFFができなくなる。
- ただし、認証方法を新ポリシーへ移しても、それだけで「全員にMFAを強制」にはならない。“どの方法を使えるか”と“誰にMFAを要求するか”は別設定だから。
つまり現状、Security Defaultsは無効、Per-user MFAでユーザーごとにMFAを管理、さらに工場内などの事情で全員MFA必須にしていない場合は、ユーザー単位のON/OFF運用は残しつつ、認証方法の定義だけを新ポリシーへ移すのが現実解になります。
Per-user MFAを2つに分けて理解する（運用目線の整理）
ユーザー状態（Disabled / Enabled / Enforced）＝「MFAを要求するか」
Per-user MFAのユーザー状態は、ユーザーごとにMFAの扱いを切り替える仕組みです。Microsoft Learnでは、ユーザー状態を次の3つに整理しています。
| 状態 | 意味（要約） | 管理者が気を付けたい点 |
|---|---|---|
| Disabled | 既定状態。Per-user MFAに未登録で、MFAは求められない | 例外ユーザー（工場内など）をMFA不要にする場合はここ |
| Enabled | Per-user MFAに登録させる状態。次回サインインで登録を促される | 登録完了後、自動的にEnforcedへ移行するケースがある |
| Enforced | サインイン時にMFAが必須 | レガシー認証（古いクライアント）ではアプリパスワードが絡む場合がある |
この「ユーザー状態」の考え方を押さえると、“全員MFA必須にできない”環境でも、必要なユーザーだけをEnforcedにするという運用が成立します。Microsoft Learnでも、Conditional AccessやSecurity Defaultsを使わない場合の選択肢として、Per-user MFAで各アカウントを有効化する方法が説明されています。
Service settings＝「どの認証方法を使えるか」
一方のService settings（追加のクラウドベースMFA設定など）は、アプリパスワードや検証オプションなどを扱うレガシーの設定ポータルとして位置付けられています。ここで従来は「電話/SMS/Authenticatorを許可する」といった方法のON/OFFを行ってきましたが、認証方法の管理は認証方法ポリシーへ移す流れです。
対応手順：認証方法を「認証方法ポリシー」へ移行する
ここからは、管理ポータル（Microsoft Entra管理センター）で完結する現実的な移行手順を、運用担当者の目線でまとめます。自動移行ガイド（ウィザード）を使うのが最短です。
移行に必要な権限（先に詰まりどころを潰す）
Microsoft Learnの手順では、移行ガイドの実行や認証方法ポリシーの操作は、少なくともAuthentication Policy Administrator以上のロールでサインインする前提で説明されています。Per-user MFAの状態変更も同ロールが例示されています。
移行前にやること（監査・棚卸し）
- レガシーMFAポリシー（Per-user MFAのService settings）で、有効にしている認証方法をメモする。
- SSPR（Password reset）の認証方法設定を使っている場合は、どの方法を有効化しているか／対象ユーザーは誰かをメモする。
- Per-user MFAのユーザー状態（Disabled/Enabled/Enforced）の運用一覧（例外ユーザー）を整理する。
移行ガイドはテナントのポリシー設定のみを移行し、個々のユーザー設定は移行しない点が重要です。つまり、Per-user MFAのユーザー状態そのものは、この移行操作で書き換わりません。
自動移行ガイドでの移行（推奨）
- 「Entra ID > 認証方法（Authentication methods）> ポリシー（Policies）」へ移動する（メニュー名はテナントの表示言語で多少揺れます）。
- 「移行ガイド（Migration guide）」を開き、現状のレガシー設定を監査してウィザードの推奨値を確認する。
- 旧ポリシーで有効な方法は、新ポリシーでも有効にする（ユーザー体験を変えないため）。
- 内容に問題がなければ「Migrate」を実行する。
ウィザードは、レガシーMFA/SSPRポリシーで有効だった方法を基に、認証方法ポリシーを更新します。移行が完了すると、レガシー側の認証方法はグレーアウトし、適用されなくなります。必要なら移行状態を戻してレガシー側を一時的に再有効化できる（＝移行はリバーシブル）とも説明されています。
SSPRを使っている場合の注意（移行できない設定がある）
SSPRで「秘密の質問」を使っている場合、Microsoft Learnでは秘密の質問は認証方法ポリシー側でまだ管理できないため、引き続きレガシーSSPR設定側で管理する、と説明されています。SSPRを使っているテナントは、この“移行できない領域”を前提に手順書を整備しておくと混乱が減ります。
ユーザーの再登録は必要？
運用上の一番の心配が「ユーザーが再登録を求められないか」です。一般に、旧ポリシーで許可していた認証方法を新ポリシーでも同様に有効化しておけば、登録済みの情報を使い続けられる前提で案内されています（方法を“削る”と、その方法に依存していたユーザーが詰みやすい）。移行時は、まずは旧環境で使っている方法を広めに許可し、落ち着いてから段階的に絞るのが安全です。
移行後の確認チェックリスト（事故を防ぐ最短リハーサル）
| 確認項目 | 期待値 | つまずきやすい原因 |
|---|---|---|
| 認証方法ポリシーで、従来使っていた方法がONになっている | Authenticator / SMS / 通話 などが必要に応じて利用可能 | ウィザードの推奨を“安全のため”と勘違いして方法を絞りすぎる |
| Per-user MFAがEnforcedのユーザーでサインインテスト | MFAが要求される | ユーザーが未登録（Enabledのまま）／方法が許可されていない |
| Per-user MFAがDisabledの例外ユーザーでサインインテスト | 原則MFAは要求されない | Security Defaultsを有効化していた／別ポリシーで要求されている |
| SSPRを使うユーザーのリセットテスト（使っている場合） | 従来通りリセット可能 | SSPRの対象ユーザー/方法の移し忘れ |
Entra ID FreeでのMFA運用はどうする？（選択肢の全体像）
「Entra ID Freeだけで、MFAを一部ユーザーだけに適用できるのか？」という相談は非常に多いです。Microsoft Learnの整理では、MFAを有効化する代表的な方法は次の3つで、それぞれ得意・不得意が異なります。
| 方式 | Freeで使える？ | 「一部ユーザーだけMFA」 | 管理のしやすさ | 備考 |
|---|---|---|---|---|
| Security Defaults | ○ | ×（例外ユーザーを作りにくい） | 最も簡単 | “必要に応じて”MFA。細かな条件は作れない |
| Per-user MFA（ユーザー状態） | ○（FreeでCAを使えない場合の選択肢として記載） | ○（ユーザーごとにDisabled/Enforced等） | 中（手作業だと運用が重い） | いわゆるレガシー。将来的にはCAへの移行が推奨される |
| Conditional Access（CA） | ×（P1/P2） | ○（例外・条件をルール化） | 最も柔軟 | 場所/デバイス/リスクなどでMFA要否を制御 |
今回のMC678069は、この表の「Per-user MFA」そのものをなくす話ではなく、あくまで“認証方法の管理（SMSや音声通話などの許可）”を統合ポリシーへ寄せる話です。Freeテナントで「全員MFA必須」にできない事情があるなら、まずはPer-user MFA（ユーザー状態）は維持しつつ、認証方法の管理だけを移行する方針で良いでしょう。
モバイル端末禁止ユーザーがいる場合の現実的な設計案
工場内などでスマートフォンを持ち込めない場合、「Authenticatorアプリ前提」の設計が破綻しやすいのが悩みどころです。ここでは、現場で成立しやすいパターンを“やりがちな失敗”も含めて整理します。
パターンA：例外ユーザーはPer-user MFAをDisabledのまま（最小変更）
- 一般ユーザー：Per-user MFAをEnforced（またはEnabled→Enforced）
- 工場内ユーザー：Per-user MFAはDisabled（MFAを求めない）
最も単純で、現状運用の延長です。ただし、MFA未適用ユーザーはフィッシング耐性が弱くなるため、権限を最小化する（管理者権限を持たせない）、利用アプリを絞る、サインインログ監視などの補助策をセットで考えるのが現実的です。
パターンB：スマホ不要のMFA手段を許可して、例外を減らす
認証方法ポリシーでは、Authenticator以外にも複数の認証方法が管理対象になります。SSPR側で利用されてきた方法は、新ポリシーへの対応付けが整理されています（SMS、音声通話、ソフトウェアOATH、メールOTPなど）。
| 候補 | スマホ必須？ | 向いている現場 | 注意点 |
|---|---|---|---|
| 音声通話（Voice call） | 必須ではない（固定電話でも可） | 構内で内線/固定電話がある | コールを受けられる運用が必要。共有電話は避けたい |
| SMS | 携帯電話が必要 | ガラケー等が許容される | SIM管理や紛失時対応が必要。安全性は高くない |
| ソフトウェアOATH（TOTP） | 運用次第 | PC上のTOTPや別端末で運用できる | 登録・再発行の手順が必要 |
| FIDO2セキュリティキー／パスキー | 不要 | USBキー等の持ち込みが許可される | 方式・デバイス選定、紛失時手順が必要 |
認証方法ポリシー側には、レガシーにはなかった方法（FIDO2セキュリティキー、Temporary Access Pass、証明書ベース認証など）が存在すると説明されています。スマホ禁止＝MFA不可能と決め付けず、現場で回る手段を用意できないか検討すると、例外ユーザーを減らせることがあります。
パターンC：本当は「場所・端末」でMFA要否を切り替えたい（ただしP1が必要）
工場内の固定端末だけはMFAを省略し、社外や未知の端末ではMFA必須にしたい…という要件は、本来はConditional Accessで解くのが王道です。Microsoft Learnでも、MFAを柔軟に強制する推奨手段はConditional Accessとされています。
例えば「Trusted IPs（信頼済みIP）」で工場ネットワークを例外にする設計は分かりやすいのですが、この機能はEntra ID P1が必要と明記されています。Freeのままでは“場所で例外”を作りたいときに詰まりやすいため、例外設計を今後も続けるなら、P1導入の費用対効果を一度試算しておく価値があります。
Microsoft Graph PowerShellは必要？（結論：移行は不要、運用自動化で選択肢）
移行（認証方法ポリシーへの移行）にGraphは必須ではない
認証方法ポリシーへの移行は、管理ポータルの移行ガイドで自動化できます。監査→推奨→Migrateという流れで完結するため、「移行のためにGraph PowerShellが必須」ということはありません。
ただしPer-user MFAの状態を大量に扱うなら、Graphが役立つ
ユーザー数が多いテナントでは、「誰をEnforcedにするか」を手作業で維持するのが現実的でなくなります。この点は、Microsoft LearnでもPer-user MFAの状態をMicrosoft Graph（beta）で参照・更新できる例が掲載されています。
GET /users/{id | userPrincipalName}/authentication/requirements
GET https://graph.microsoft.com/beta/users/{user}/authentication/requirements
PATCH https://graph.microsoft.com/beta/users/{user}/authentication/requirements
Content-Type: application/json
{
"perUserMfaState": "disabled" // "enabled" / "enforced" など
}運用のコツは「まずはポータルで安全に移行し、運用が重くなったらGraphで自動化」です。移行に失敗するとサインイン影響が出るため、順番を守るだけでトラブルが減ります。
よくある誤解と、管理者が押さえるべき注意点
誤解：認証方法ポリシーに移行したら、勝手に全員MFAになる
認証方法ポリシーは「どの認証方法を許可するか」を管理するポリシーであり、それ単体で“全員にMFAを強制するボタン”ではありません。MFAをいつ／誰に要求するかは、Security Defaults、Conditional Access、Per-user MFAといった別の仕組みで決まります。
誤解：MC678069＝Per-user MFA（Enforced）が使えなくなる
MC678069で明記されているのは「レガシーMFA/SSPRポリシーで認証方法を管理することができなくなる」という点です。Per-user MFAのユーザー状態を扱う方法は、別ドキュメントとして手順が掲載され続けており、ポータルUIの改善やGraphでの管理例も追記されています。
注意：管理できる認証方法の“所在”が分散している
移行期にハマりやすいのが「どこで何を設定するのか」が一時的に分かりにくい点です。実務では次の整理が役に立ちます。
| やりたいこと | 設定場所 | 補足 |
|---|---|---|
| SMSや音声通話、Authenticator等を“許可”したい | 認証方法ポリシー | 2025/9/30までにレガシーから移行が必要 |
| 特定ユーザーにMFAを“必須”にしたい（Freeで例外も作りたい） | Per-user MFA（ユーザー状態） | Disabled/Enabled/Enforcedで制御 |
| 場所・端末・リスクなど条件でMFAを出し分けたい | Conditional Access | P1/P2。Freeでは不可 |
補足：グループごとの「使える方法」制御は新ポリシーでやりやすくなる
認証方法ポリシーでは、方法ごとに有効化するユーザーグループや除外するグループを設定できるため、例えば「Authenticatorは全員」「SMS/音声通話は必要な少数グループだけ」といった設計が可能です。Microsoft Learnでも、その柔軟性（有効化・除外の両方）が明記されています。
まとめ：MC678069対応の最短ルート
- 2025年9月30日までに、レガシーMFA/SSPRポリシーで管理していた「認証方法（SMS/通話/Authenticator等）」を認証方法ポリシーへ移行する。
- Per-user MFAのユーザー状態（Disabled/Enabled/Enforced）は、認証方法の移行とは別軸。Free環境で「一部ユーザーだけMFA」運用を続けるなら、当面はここを使い続けるのが現実的。
- スマホ禁止ユーザーがいる場合は、固定電話・物理キーなど“スマホ不要”の手段を許可できないか検討し、例外ユーザーを減らす設計を目指す。
- 将来的に「場所や端末」で制御したくなったら、Conditional Access（P1）導入が王道。
コメント