Microsoft Entra IDのMFAは電話／SMSも今後使える？——条件付きアクセスとの正しい設計・移行ガイド【2025年最新実務解説】

要点：Microsoft がアナウンスしている「レガシー認証方式の段階的な廃止」は、古い設定画面や分散管理のやり方を整理・統合することが主目的です。電話着信（Voice call）やSMSコードによるMFA自体は引き続き利用可能で、今後は Microsoft Entra ID > Security > Authentication methods > Policies で一元管理するのが標準になります。本稿では、なにが変わるのか／なにが変わらないのか、どう移行・運用すべきかを、現場でそのまま使える形で詳しく解説します。

結論：電話着信・SMSは引き続き使える。ただし管理の入り口が変わる

今回の移行で対象なのは、主に次のような“レガシーな管理項目”です。

• Per‑user MFA Service Settings（ユーザー単位でのMFA有効化／強制）
• Password Reset Authentication methods（SSPRの認証方法設定）

これらはAuthentication methods ポリシーに統合され、設定する場所と考え方がモダン化されます。機能面では、電話・SMSは引き続きサポートされ、Authenticatorアプリ、FIDO2/パスキー、Windows Hello などのモダン方式と並列で使えるという点は変わりません。

「レガシー認証」と「レガシー設定」の混同に注意

現場で最も多い誤解は、“レガシー認証の廃止”＝“電話/SMSの廃止”と受け取ってしまうことです。ここで言う「レガシー認証」は歴史的なプロトコル（例：旧来のBasic認証）を指す文脈が多い一方、今回のテーマはレガシーな管理UIや分散された設定手法の整理です。電話/SMSという認証方式そのものの提供停止を意味しません。

<table>
  <thead>
    <tr>
      <th>観点</th>
      <th>レガシー<strong>認証</strong>（プロトコル）</th>
      <th>レガシー<strong>設定</strong>（UI/運用）</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>意味</td>
      <td>旧来の認証プロトコル（例：Basic、一部古いPOP/IMAPなど）</td>
      <td>分散・重複した設定画面（Per-user MFA、SSPR個別設定 等）</td>
    </tr>
    <tr>
      <td>整理の目的</td>
      <td>安全性・近代化（Modern Auth への統一）</td>
      <td>管理の一元化と運用のシンプル化（<em>Authentication methods</em>に集約）</td>
    </tr>
    <tr>
      <td>電話／SMSへの影響</td>
      <td>なし（方式の可否とは別の話）</td>
      <td><strong>なし（引き続き利用可能）</strong>。設定場所が変わるだけ</td>
    </tr>
  </tbody>
</table>

なにが変わるのか：統合ポイントと運用の考え方

変更点の本質は「設定の置き場所と適用の考え方」にあります。従来はユーザー単位の有効化や、SSPRの方法を別々に管理していたため、どこで何が優先されるのかが分かりづらく、運用ミスの温床になりがちでした。今後は以下に統一されます。

• Authentication methods > Policies： 使わせたい認証方法（SMS、Voice、Authenticator、FIDO2/パスキー等）を対象グループ単位で有効化／無効化し、登録と利用の両方を制御します。
• Conditional Access（条件付きアクセス）： “いつ・どこで・だれに”MFAや特定の認証強度を要求するかをポリシーで決めます。利用する認証手段の可否そのものは原則として Authentication methods ポリシー 側の設定が参照されます。
• Authentication strengths： 条件付きアクセスから「フィッシング耐性」などの強度で要求できます。たとえば「重要アプリはパスキー/FIDO2のみ許可」といった指定が可能です。

<table>
  <thead>
    <tr>
      <th>対象</th>
      <th>主な役割</th>
      <th>電話／SMSへの影響</th>
      <th>運用の勘所</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>Authentication methods ポリシー</td>
      <td>認証手段の「登録・利用可否」を決める</td>
      <td><strong>Enabled</strong>なら利用可能。ここでOFFにすると使えない</td>
      <td>対象グループを正しく設計。来客/委託/高リスク部門などで差異を付けやすい</td>
    </tr>
    <tr>
      <td>Conditional Access</td>
      <td>いつ・どこで・誰にMFA/強度要求をかけるか</td>
      <td>CAでMFAを要求しても、許可される手段はMethods側に依存</td>
      <td>「MFA必須」と「強度（例：Phishing-resistant）」を使い分ける</td>
    </tr>
    <tr>
      <td>Authentication strengths</td>
      <td>許容する<strong>強度（例：FIDO2のみ）</strong>を指定</td>
      <td>電話/SMSは<strong>フィッシング耐性</strong>を満たさない</td>
      <td>重要資産は強度指定、汎用はMFA指定といった二層構えが実務的</td>
    </tr>
  </tbody>
</table>

やるべき対応（実務手順）

1. Authentication methods ポリシーを確認・整備
   • Security > Authentication methods > Policies で SMS と Voice call を Enabled にする（対象グループも忘れずに）。
   • 同画面で Microsoft Authenticator（番号一致）、FIDO2/パスキー も有効化し、登録を促すキャンペーン（登録必須化のスケジューリングを含む）を設計します。
   • 来訪者や委託先などの外部ID用グループは認証手段を絞るなど、対象別テンプレートを作ると運用が安定します。
2. 条件付きアクセス（CA）の見直し
   • 既存の「MFA を要求」ポリシーがある場合、Methods 側との矛盾がないか確認。
   • 重要アプリや管理者操作には Authentication strengths で Phishing-resistant（例：FIDO2/パスキー、証明書ベース）を要求。
   • 一般ユーザーの汎用アクセスは「MFA 必須」（強度は問わない）として、段階的に強度を引き上げる戦略が現実的です。
3. Per‑user MFA の整理
   • ユーザー毎の Enabled/Enforced は段階的に撤廃し、CA＋Methods に統合。
   • 移行中は二重要求や想定外のブロックが起きやすいので、パイロットグループを切って検証します。
4. ユーザーへの周知・サポート準備
   • 登録画面や文言の変更点をスクリーンショット付きで案内。
   • SMSが届かない/音声通話が取れない時のセルフヘルプ（「電波状況を確認」「再送」「通話へ切替」等）を用意。
   • 機種変更・番号変更時の手続き、回復コードや代替手段の登録ルールを明文化。
5. 非常用（Break-glass）アカウントの見直し
   • CA対象外・強力なランダムパスワード・ログ監視・利用手順の封書保管など、非常時プロセスを改めて点検。

セキュリティの観点：電話／SMSは「使える」が、重要資産には不向き

電話/SMSは依然として有効で便利な選択肢です。一方で、SIMスワップや通話転送の悪用、中間者攻撃など、攻撃者が狙える面も残ります。重要度の高いアプリや管理系操作には、フィッシング耐性を満たすパスキー（FIDO2）や証明書ベースの方式へ移行しておくと安心です。

<table>
  <thead>
    <tr>
      <th>認証方式</th>
      <th>強み</th>
      <th>主なリスク</th>
      <th>推奨用途</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>SMSコード</td>
      <td>導入容易、携帯番号だけで可</td>
      <td>SIMスワップ、スミッシング、ワンタイムコード詐取</td>
      <td>一般ユーザーの初期オンボーディング、バックアップ手段</td>
    </tr>
    <tr>
      <td>音声通話（電話着信）</td>
      <td>SMSが届かない環境でも可、固定電話も可</td>
      <td>転送設定の悪用、なりすまし通話</td>
      <td>電波やSMS事情が不安定な拠点の代替</td>
    </tr>
    <tr>
      <td>Authenticator（番号一致）</td>
      <td>プッシュの利便性、番号一致で誤承認を抑止</td>
      <td>端末紛失・マルウェア</td>
      <td>多くの一般業務、準重要アプリ</td>
    </tr>
    <tr>
      <td>パスキー / FIDO2</td>
      <td><strong>フィッシング耐性</strong>、ユーザビリティ、端末内秘匿</td>
      <td>キーの紛失・ローミング要件</td>
      <td><strong>重要資産・管理系・特権作業</strong></td>
    </tr>
  </tbody>
</table>

ライセンスと前提条件（実務の目安）

• Conditional Accessの本格活用にはMicrosoft Entra ID P1が一般的な目安。
• リスクベースの制御（サインインリスク/ユーザーリスク）を使う場合はP2相当が必要なシナリオが多い。
• FIDO2/パスキーはOS/ブラウザ/デバイスの対応が前提。企業端末では管理テンプレートやブラウザポリシーでの事前有効化を忘れない。

※正式なライセンス条件は契約や時期で変動し得ます。社内のライセンス管理担当・リセラーと最新情報をすり合わせてください。

設計テンプレート：現実解の3レイヤー構成

1. レイヤー1：組織標準（全社）
   • Authentication methods：Authenticator（番号一致）＋SMS/Voiceを有効化。登録キャンペーンで初期登録を促進。
   • CA（MFA要求）：全クラウドアプリに対してMFA必須。ただしオフライン復旧や非常口のために必要最小限の例外を定義。
2. レイヤー2：重要アプリ（財務、人事、機密データ）
   • Authentication strengths：Phishing-resistant（FIDO2/パスキー等）を必須に。
   • アプリ単位のCAポリシーで強度を要求し、場所条件やデバイス準拠性とも掛け合わせる。
3. レイヤー3：特権・管理者
   • PAW（特権用ワークステーション）＋FIDO2必須。
   • 緊急時のためのBreak-glassをCA対象外にしつつ、利用監査とアラートは厳格に。

移行チェックリスト（現場でそのまま使える）

• 棚卸し：Per-user MFA、SSPR設定、CAポリシー、認証方法の現状を可視化。
• グルーピング：正社員、派遣/委託、外部ID、管理者、来客などのグループ定義を明確化。
• ポリシー統合：Authentication methodsへ方式可否を集約。CAは要求タイミングと強度を定義。
• パイロット：代表部門で2〜4週間検証。到達率（SMS/Voice/Push）やユーザー負荷を測定。
• 段階展開：拠点単位・部門単位で展開。週次で問い合わせパターンを分析し、FAQを更新。
• 最適化：高リスクユーザーには強度引き上げ、一般部門には利便性優先など、セグメント戦略を回す。

運用FAQ（ユーザー向け想定問答）

Q. 電話着信やSMSはいつまで使えますか？ A. 現行の計画では継続利用できます。今後は管理がAuthentication methods ポリシーに統合されるだけです。

  <dt>Q. なぜパスキー（FIDO2）を勧めるのですか？</dt>
  <dd>A. <strong>フィッシング耐性</strong>があり、重要資産でのリスクを大幅に下げられるからです。スマホ内やセキュアエレメントに秘密鍵が保持され、<em>なりすましサイト</em>でも悪用されにくい特性があります。</dd>

  <dt>Q. Authenticatorの「番号一致」とは？</dt>
  <dd>A. サインイン側に表示される番号をアプリで入力して一致させる方式です。単なる「承認」よりも<strong>誤承認やプッシュ爆撃</strong>に強くなります。</dd>

  <dt>Q. SMSが届かない時は？</dt>
  <dd>A. <em>再送</em>、<em>音声通話への切替</em>、<em>電波状況の確認</em>、<em>端末のSMSブロック設定・着信制限の確認</em>を案内してください。繰り返す場合は<strong>Authenticator</strong>か<strong>パスキー</strong>の併用を推奨します。</dd>

  <dt>Q. 固定電話しかない現場があります</dt>
  <dd>A. <strong>音声通話</strong>でのコード受領を代替として許可できます。ただし誰でも出られる内線は避け、<strong>個別回線</strong>の確保と<strong>通話履歴の管理</strong>を検討してください。</dd>
</dl>

よくある落とし穴と回避策

• 「MFAを要求」だけで満足してしまう：重要資産は認証強度で指定し、電話/SMSを満たさないようにする。
• Per-user MFAが残存：CAと二重で効いて挙動が読めなくなる。計画的に撤廃し、Methodsに集約。
• 登録の詰まりが発生：初回登録ウィザードの案内不足が原因。画面キャプチャ付き手順書と、ヘルプデスクのスクリプトを用意。
• 非常口がない：Break-glass無設定は危険。最小数で用意し、強固な保護と監査をセットで。
• 海外拠点のSMS到達率：国・キャリア差がある。プッシュ or パスキーを第一候補に、SMS/Voiceはバックアップに位置付ける。

移行時のテスト計画（例）

以下の観点をテストケースに落とし込むと、現場品質が安定します。

• アカウント種別：一般、管理者、外部ID、来訪者
• デバイス種別：社給Windows、BYODスマホ、共有端末、キオスク
• 場所条件：社内ネットワーク、既知の場所、海外出張先
• 回線条件：4G/5G、Wi‑Fi、電波弱
• 代替手段：Push失敗→SMS、SMS失敗→音声、音声失敗→パスキー
• 非常時：Break-glass手順の実地演習、ログ監査の確認

管理画面の主な変更点（要約）

項目	旧来の場所	新しい場所（標準）	メモ
MFAの有効化（ユーザー単位）	Per‑user MFA Service Settings	Authentication methods > Policies（方式可否）＋CA（要求条件）	ユーザー単位のEnabled/Enforcedは原則卒業へ
SSPRの認証方法	Password Reset Authentication methods	Authentication methods > Policies	登録と利用の一元管理
強度の指定	（なし）	Authentication strengths（CAから参照）	重要アプリはPhishing-resistantに

社内周知テンプレート（そのまま使える文面例）

【重要】サインイン時の認証設定変更について（〇/〇実施）
・今回の変更は、サインイン時の安全性を高め、使える認証方法を分かりやすくするためのものです。
・電話着信・SMSによる認証は引き続き利用できます。
・あわせて「Microsoft Authenticator（番号一致）」や「パスキー（FIDO2）」の登録をお願いします。
・手順書：社内ポータル（ITヘルプ）を参照してください。
・問い合わせ：内線xxxx / メール：it-help@contoso
    

まとめ：電話／SMSは「続く」。ただし“主役”はモダン認証へ

Microsoft Entra IDにおけるMFAの将来像は明確です。電話／SMSは今後も使える一方で、設定はAuthentication methodsに統一され、条件付きアクセスと認証強度を組み合わせる設計が標準になります。セキュリティと利便性を両立する鍵は、重要資産にパスキー（FIDO2）や番号一致を優先し、電話／SMSはバックアップ手段として活かすこと。移行は大掛かりに見えますが、棚卸し → グルーピング → ポリシー統合 → パイロット → 段階展開 → 最適化の王道を踏めば、確実に前進できます。

付録：導入ロードマップ（90日プラン例）

期間	主な活動	成果物
Day 1–30	現状評価（棚卸し）、パイロット設計、Methods初期ポリシー作成、周知案内	現状レポート、テスト計画、登録手順書、FAQ（v1）
Day 31–60	パイロット実施、CA調整、強度要求の試行、到達率・UXの測定	改善版ポリシー、FAQ（v2）、展開手順
Day 61–90	部門別展開、重要アプリに強度必須化、Per-user MFA撤廃	全社展開レポート、運用Runbook、監査・アラート設計

FAQスキーマ（SEO向け構造化データ）

---