Microsoft Entra ID で旧（レガシー）MFA/SSPR ポリシーによる認証方法管理が 2025年9月30日に廃止されます。未移行のままだと SMS や音声通話の本人確認が止まるのか、そして止めないために何をすべきかを、実務目線で整理します。
結論：SMS／音声通話は「移行しないと止まる」可能性が高い
結論から言うと、レガシー（旧）MFA/SSPR ポリシーだけで SMS／音声通話を許可している環境は、移行しない限り“止まる”リスクが高いです。理由はシンプルで、Microsoft は 2025年9月30日以降、旧ポリシーでは認証方法を管理できないため、新しい『認証方法ポリシー（Authentication methods policy）』へ移行することを推奨しているからです。
さらに Microsoft Learn の Q&A（コミュニティ回答）では、未移行の場合に2025年10月1日から SMS／音声通話の検証が止まる旨の回答が付いています。
もちろん Q&A は公式発表そのものではありませんが、公式ドキュメントでも移行状態が Migration Complete になるとレガシー設定は無視（ignored）されると明記されています。つまり、SMS/音声通話をレガシー側の許可に依存していた場合、新ポリシー側で SMS/音声通話を有効化していない限り、サインインや SSPR で詰まるのが構造的に自然です。
押さえておきたいタイムライン
| 日付 | 起きること | 実務の意味 |
|---|---|---|
| 2023年3月 | レガシー MFA/SSPR での認証方法管理の廃止が告知される | 将来的に管理の置き場を統合する前提で計画が必要 |
| 2025年9月30日 | レガシー MFA/SSPR では認証方法を管理できなくなる | 新しい認証方法ポリシーへ移行していないと、方式の継続利用が危うい |
| 2025年10月1日 | 未移行だと SMS/音声通話が止まる可能性がある（コミュニティ回答） | “10月から急に困る” を避けるなら、9月中に新ポリシーで許可を揃えておく |
まずやるべき最短アクション
- Microsoft Entra 管理センターで Entra ID > Authentication methods > Policies を開き、SMS と Voice calls（音声通話） を必要なユーザー（またはグループ）に対して有効化する
- SSPR で Mobile phone（携帯電話） を使っているなら、原則として SMS と音声通話の両方を有効化する
- Migration Complete にする前に、新ポリシー側の許可が揃っていることをテストで担保する
「期限を過ぎたけど、とりあえず今ログインできるから後で…」が一番危険です。旧設定が尊重される状態から、ある日突然 “無視される状態” に移ると、影響が一気に顕在化します。
何が廃止されるのか：旧 MFA/SSPR ポリシーと新しい「認証方法ポリシー」
旧（レガシー）の MFA/SSPR では、同じ「認証方法」でもMFA と SSPR が別々の画面・別々のロジックで管理されていました。加えて、レガシー側では「誰に使わせるか」「どう使わせるか」を細かく制御しづらいという制約があります。
この分断を解消するのが、認証方法ポリシー（Authentication methods policy）です。ユーザー/グループ単位で方式を割り当てられ、登録体験や運用の一貫性も取りやすくなります。
| 観点 | レガシー（旧）MFA/SSPR ポリシー | 認証方法ポリシー（新） |
|---|---|---|
| 管理場所 | MFA（Multifactor authentication settings）、SSPR（Password reset settings）などに分散 | Entra ID > Authentication methods > Policies に集約 |
| 有効化の単位 | 主にテナント全体・SSPR 対象範囲など | ユーザー/グループ単位で割り当て可能 |
| 期限 | 2025年9月30日以降、認証方法を管理できない | 移行ウィザード/手動移行で集約（移行は戻せる） |
| 電話系の扱い | SSPR の Mobile phone は SMS/音声通話をまとめて許可しがち | SMS と Voice calls を別々に明示制御できる |
「SMS／音声通話が使えなくなる？」が起きるメカニズム
そもそも “有効化の判定” は複数ポリシーをまたぐ
公式ドキュメントでは、ポリシー間で設定は同期されず、Microsoft Entra ID はいずれかのポリシーで有効になっていればユーザーが登録・利用できる、と説明されています。逆に言えば、Migration in Progress などの併用期間は、意図せず広い範囲に方式が使えてしまうことがあります。
移行ステータスが “レガシー設定を無視するスイッチ” になる
移行には 3 つの状態があり、特に重要なのが Migration Complete です。この状態では認証方法ポリシーのみが参照され、レガシー設定は無視されます。
| 移行ステータス | サインイン（MFA） | SSPR | レガシー設定の扱い | 運用上の意味 |
|---|---|---|---|---|
| Pre-migration | 認証方法ポリシーが参照される | 従来の SSPR 設定が中心 | 尊重される | 段階導入の準備期間 |
| Migration in Progress | 認証方法ポリシーが参照される | 認証方法ポリシーも参照される | 尊重される | 新旧併用で安全に切替テスト |
| Migration Complete | 認証方法ポリシーのみ | 認証方法ポリシーのみ | 無視される | 旧設定に頼る方式は使えなくなる |
SSPR の “Mobile phone” は SMS/音声通話をまとめて許可し得る
公式ドキュメントでは、レガシー SSPR の Mobile phone は「携帯電話へ音声通話またはテキスト（SMS）を送る」オプションで、Office phone は音声通話のみと説明されています。加えて、ポリシーが独立していることで、Mobile phone を使うユーザーは想定より広い電話系オプションを使えることがある、と注意喚起されています。
コミュニティ回答が示す “10月1日停止” は、実務上かなり現実的
Q&A の回答は「10月1日に止まる」と明言しています。
繰り返しになりますが、Migration Complete で旧設定が無視される以上、レガシーにしか許可がない方式が動かなくなるのは構造的に説明できます。したがって実務では、「Microsoft がどのタイミングで旧ポリシーを無効化/無視に寄せるか」を待つより、先回りで新ポリシーへ許可を写すほうが安全です。
影響を受けやすいユーザーと、見落としがちなパターン
「SMS/音声通話を使っている人だけが影響」と思われがちですが、実務ではもう少し広い範囲に波及します。次のどれかに当てはまる場合、移行の優先度は高いです。
- 多要素認証で SMS または 電話（音声通話） を許可している（スマホ未配布の現場、ガラケー運用など）
- SSPR で Mobile phone / Office phone を主要手段にしている
- 本人確認の “最後の砦” が電話系で、他の代替手段（Authenticator、TAP、FIDO2 など）が整っていない
- 管理者（特に Global Administrator）も電話系に寄っており、緊急用アカウント（ブレークグラス）設計が弱い
- グループ単位で方式を制御したい（拠点や雇用形態で MFA の現実が違う）
旧→新の対応関係を先に押さえる
移行で詰まりやすいのが「旧画面の名称と、新ポリシーの名称が一致しない」点です。公式の移行ガイドに、対応表が用意されています。
| 旧（レガシー MFA） | 新（認証方法ポリシー） | 補足 |
|---|---|---|
| Call to phone | Voice calls（音声通話） | 会社電話（固定）/ 携帯に通話 |
| Text message to phone | SMS | 携帯番号宛ての SMS |
| Notification through mobile app | Microsoft Authenticator | プッシュ通知など |
| Verification code from mobile app or hardware token | Third party software OATH tokens / Hardware OATH tokens / Microsoft Authenticator | 新ポリシーでは細分化 |
| 旧（レガシー SSPR） | 新（認証方法ポリシー） | 実務上の推奨 |
|---|---|---|
| Mobile phone（携帯電話） | Voice calls + SMS | “携帯電話で本人確認” を継続するなら両方を有効化し、段階的に強い方式を増やす |
| Office phone（会社電話） | Voice calls | 固定電話が主なら音声通話を有効化 |
| Email OTP | SSPR の補助としては有効だが、過信しない | |
| Security questions | （未対応） | 当面はレガシー SSPR 側で管理が必要 |
手順：SMS/音声通話を継続しつつ「認証方法ポリシー」へ移行する
事故を起こさない順番（先に新、後から旧を閉じる）
- 現状把握：旧 MFA/SSPR でどの方式を許可しているか、SSPR 対象範囲、管理者の認証手段を棚卸しする
- 新ポリシーで先に許可：SMS/音声通話を含め、必要な方式を新ポリシー側で有効化する（対象は “いきなり全員” でなくてもよい）
- Migration in Progress にして併用状態でテストする
- レガシー側の方式を段階的に外す（外す→テスト→次を外す、の繰り返し）
- 問題がなければ Migration Complete に切り替える
この順番が安全です。認証方法ポリシー側の許可が揃っていないのに Migration Complete に入ると、旧設定が無視されるため “方式が消える” 事故になりやすいです。
ウィザード（自動移行ガイド）を使う場合
公式の移行ウィザードは、レガシー MFA/SSPR で有効な方式を検出し、同等の方式を認証方法ポリシー側でも有効にする構成を提案します。確認して問題がなければ Migrate を実行し、移行後はレガシー側の設定がグレーアウトして適用されなくなります。
またウィザードは、パスキー、Temporary Access Pass、Microsoft Authenticatorなどのモダンで安全性の高い方式の有効化も推奨しています。電話系を残す事情がある場合も、並行して強い方式を増やしておくと将来の設計が楽になります。
手動移行でやる場合（日本企業で多い “段階移行” に向く）
部署や雇用形態で現実の端末事情が違う場合、手動移行が向きます。公式手順では、まず旧設定を監査（audit）し、その後 Migration in Progress を選んで新ポリシーを SSPR にも効かせる流れが示されています。
なお新規テナントは、認証方法ポリシーが “全て Off” から始まります。既存テナントでも「新ポリシーを触っていない＝電話系がオンになっていない」ことは珍しくないので、必ず新ポリシー側の On/Off を確認してください。
実務のチェックリスト（移行前）
| チェック項目 | ねらい | 具体例 |
|---|---|---|
| レガシー MFA の許可方式 | SMS/音声通話が “旧だけで許可” になっていないか確認 | レガシー MFA の service settings |
| レガシー SSPR の対象範囲 | SSPR が全社/特定グループ/無効か把握 | Password reset の Properties |
| レガシー SSPR の認証方法 | Mobile phone / Office phone の利用有無を確認 | Password reset の Authentication methods |
| 管理者の代替手段 | 切替で管理者がロックアウトしないようにする | ブレークグラス、TAP の準備、Authenticator/FIDO2 の優先 |
実務のチェックリスト（移行中〜移行後）
| フェーズ | やること | ありがちな失敗 | 回避策 |
|---|---|---|---|
| 移行中 | 認証方法ポリシーで SMS/音声通話を必要な範囲に有効化 | “一部ユーザーにだけ許可したつもり” が広がる | 併用期間は旧設定も尊重されるため、旧側の許可を併せて確認 |
| 移行中 | Migration in Progress でテストユーザーを使い、サインインと SSPR を実測 | SSPR だけ後で気づく | テストは「サインイン」「リセット」を必ず両方実施 |
| 移行後 | 段階的にレガシー側の方式を外し、最後に Migration Complete | Migration Complete にした瞬間に電話系が消える | 新側で SMS/音声通話が On、対象グループが正しいかを事前確認 |
Migration Complete は “切り替えスイッチ” だが、ロールバックも可能
公式ドキュメントでは、移行は段階的に進められ、Migration Complete にした後でも Migration in Progress に戻してレガシー設定を再度有効化できることが示されています。とはいえ、ロールバックはあくまで緊急避難として考え、基本は「新ポリシーで成立する状態」を先に作ってから切り替えるのが安全です。
Security questions を使っている場合の注意
SSPR のセキュリティの質問（Security questions）は、現時点では認証方法ポリシー側で管理できず、レガシー SSPR 側に残ります。もし運用上どうしても必要なら、レガシー SSPR で有効のままにしておき、他の方式（SMS/音声通話、Authenticator、Email OTP など）だけを先に移行するのが現実解です。
移行後も残る SSPR 側の設定がある
すべての認証方法を移行した後でも、レガシー SSPR には「リセットに必要な認証方法数（Number of methods required to reset）」や「SSPR 管理者ポリシー（SSPR administrator policy）」など、一部の要素が残ることが説明されています。移行後に SSPR の挙動が変わったと感じたら、ここも合わせて確認すると切り分けが早くなります。
トラブルシューティングは “Usable / non-usable” 表示が早い
ユーザーが「登録はできたのに使えない」「突然使えなくなった」という場合、Entra 管理センターでユーザーの認証方法を確認すると、Usable（利用可能）とnon-usable（利用不可）が分けて表示され、利用不可の理由（例：TAP の期限切れ等）が説明されることがあります。ヘルプデスク対応の一次切り分けに有効です。
よくある落とし穴：許可したのに “想定外の人が使える/使えない”
Voice calls をグループ限定で有効にしたのに、他のユーザーも使える
公式ドキュメントに、音声通話をグループに対して有効化したのに、グループ外ユーザーも音声通話でサインインできてしまう例が紹介されています。原因は、レガシー SSPR の Mobile phone やレガシー MFA の Call to phone が残っていることが多い、という説明です。
狙いどおりに制御したい場合は、旧側の許可を整理するか、最終的に Migration Complete を目指します。併用期間は “どれか1つで許可されると使える” ため、設計通りに締まりません。
認証方法ポリシーは “収束（converged）登録体験” とセットで考える
公式ドキュメントには、認証方法ポリシーを正しく認識するのは収束（converged）登録体験だけという注意書きがあります。登録体験が古いままだと「ポリシーで許可したはずの方式がユーザーに表示されない」などのズレが起き得るため、移行の現場ではここも見落としがちです。
グループを増やしすぎると登録が失敗することがある
既知の制限として、認証方法ポリシーや登録キャンペーンで多数のグループを対象にすると登録が失敗する場合がある、と説明されています。実務では「方式ごとに 1 グループへ集約する」設計に寄せると、運用が安定しやすいです。
SMS/音声通話を残すべきか？セキュリティと現場の折り合い
SMS や音声通話は「導入しやすい」一方で、フィッシングや SIM スワップなどの攻撃に弱い側面があります。Microsoft も、移行の流れの中でパスキー、Temporary Access Pass、Microsoft Authenticatorなどのモダンな方式を有効化することを推奨しています。
ただし現場の現実として、全員がすぐにアプリを入れられない/個人端末が使えない/固定電話しかない、といった事情もあります。そこでおすすめは、次の二段構えです。
- 短期：停止事故を避けるため、新ポリシーに SMS/音声通話を移し替え、ログインと SSPR を確実に動かす
- 中期：Authenticator やパスキー等を増やし、電話系は例外扱いへ寄せる（管理者や重要操作は強い方式へ）
「移行＝電話を捨てる」ではありません。まずは管理の置き場を新ポリシーへ移すことが最優先です。
まとめ：期限後は “管理できない” ではなく “使えない” に直結する
- 2025年9月30日以降、旧 MFA/SSPR ポリシーでは認証方法を管理できないため、認証方法ポリシーへ移行が推奨される
- Migration Complete ではレガシー設定が無視されるため、SMS/音声通話を新ポリシーで許可していないと詰まる
- Q&A でも「10月1日から止まる」という回答があり、未移行の放置はリスクが高い
- 併用期間は “どこかで許可されていれば使える” ため、旧側の残りが想定外の挙動を生む
参考資料（一次情報）
- Manage authentication methods – Microsoft Entra ID
- How to migrate to the Authentication methods policy – Microsoft Entra ID
- Configure Microsoft Entra multifactor authentication settings
- Enable Microsoft Entra self-service password reset
- Microsoft Q&A: Legacy authentication methods deprecation on September 30th
コメント