Microsoft、Entra IDのSMS/音声MFAを2027年2月に段階的停止——“パスキー前提”への本格移行が始まります

今日の深掘りポイント

• SMS/音声によるMFA停止は、SIMスワップとフィッシングを主な攻撃経路から外す、防御面での大きな地殻変動です。
• “パスキー中心”の設計に移ると同時に、移行フェーズのヘルプデスク悪用やTAP（Temporary Access Pass）乱用など新たなリスクが前景化します。
• 組織は「認証強度（Authentication Strength）」を用いたポリシー設計と、登録・復旧・サポートの運用を一体で再設計する必要があります。
• 重要インフラ、公共部門（GCC等を含む可能性があるという解釈が広がっていますが、適用範囲は公式告知を都度確認が必要です）では、レガシー依存の洗い出しと段階移行のロードマップ化が急務です。
• 施策は高い実行可能性と確度を持ち、早期パイロット→拡大展開→強制化という王道の変革プランで現場負荷をコントロールできます。

はじめに

Microsoftが2027年2月1日から、Entra IDのSMSおよび音声通話によるMFAを段階的に無効化すると発表しました。背景には、SIMスワップやフィッシングにSMS/音声が脆弱であるという長年の課題があり、パスキー（FIDO2/プラットフォーム認証器を含む）を軸とした“フィッシング耐性”へのシフトが世界規模で進んでいることがあります。セキュリティ部門にとっては、単なる「MFA手段の入れ替え」ではなく、アイデンティティ運用全体の刷新という重い問い直しに正面から向き合うタイミングになります。読者の現場に寄り添いながら、何を押さえ、どこから着手するかを具体的に解像度高く考えていきます。

深掘り詳細

事実関係（アナウンスの要点）

• 2027年2月1日以降、Microsoft Entra IDでのSMS/音声通話を用いた多要素認証が段階的に無効化される方針です。
• SMS/音声のみを登録しているアカウントは、最終的な電話確認を経てパスキー登録へ移行する必要があるとされています。
• Microsoftはパスキー（FIDO2セキュリティキーやプラットフォーム認証器を含む）を推奨し、フィッシング耐性の高い手段への集約を促しています。
• 影響を受けるユーザーの特定と、早期の代替手段登録・教育・サポート体制整備が推奨されます。
• 参考（セカンダリ情報）: GBHackers報道
  注: 一次情報（Microsoft公式ドキュメント/ブログ/Message Center）の確認が最終判断の拠り所になります。公共部門やソブリンクラウドの適用範囲・スケジュールは、個別の公式告知で必ず確認する必要があります。

インサイト（なぜ今、何が変わるか）

• 攻撃面の非対称性を是正する動きです。SMS/音声MFAが抱える最大の弱点は、認証コードの奪取が人とプロセス（通信事業者・ヘルプデスク・ユーザー判断）に強く依存する点です。SIMスワップやスミッシングは、技術的対策だけで塞ぎにくい「人のプロセス」の脆弱性を突きます。パスキーは公開鍵暗号を用いて、サイトの真正性と秘密鍵の非移転性で攻撃面を原理的に狭めます。
• 組織運用の主役が「方法」から「強度（Authentication Strength）」へと軸足を移します。つまり「SMS/音声か否か」ではなく「フィッシング耐性を満たすか」をポリシーで一貫して要求する設計です。Entraの条件付きアクセスと認証強度を組み合わせると、アプリやロールごとに必要な強度を段階的に引き上げることができます。
• 短期的にはサポート負荷が上がります。とくに登録・紛失・再発行・復旧（ブートストラップ）のオペレーションが新しい攻撃面にもなります。TAPやヘルプデスクによるMFAリセットをどう安全に運用するかが勝負どころです。
• 国家・重要インフラの観点では、ID基盤のフィッシング耐性向上は国家サイバーレジリエンスの底上げに直結します。メール・VPN・SaaSの最初のドアを強くすることは、侵害チェーン全体のコストを押し上げ、防御側に時間的余裕をもたらします。

運用設計の焦点（現場でハマるポイント）

• ブートストラップの安全設計です。新規・紛失時の登録は最も弱いリンクになりがちです。TAPの発行権限を絞る、発行有効期間と使用回数を最小化する、本人性確認の二経路化（人＋HR/工号/物理ID）などが鍵になります。
• 共有端末・現場端末での実装です。キオスク/ライン現場の「個人持ちスマホ非前提」環境では、ハードウェアキー配布や端末バンドルの工夫が必要です。
• レガシープロトコルの棚卸しです。POP/IMAP等は近年オフ化を済ませている組織も多いですが、アプリパスワードの残骸や例外ルールが侵入経路になり得ます。
• 役割に応じた強制化の順序設計です。まず特権ロール・機微アプリから強制、一般ユーザーは登録率を見ながら段階的に、という「強制の設計」自体をプロジェクト化するのが現実的です。

脅威シナリオと影響

以下は、移行前後に想定される代表的な攻撃シナリオの仮説で、MITRE ATT&CKに沿って整理します（テクニックIDは代表的な参照です）。

• SIMスワップとワンタイムコード搾取

  • 概要: 携帯キャリアや被害者をだまし、電話番号を乗っ取り、SMSコードを奪取してログインします。
  • ATT&CK例:
    • Reconnaissanceでの被害者情報収集（T1591）
    • フィッシング/なりすまし（T1566）
    • 正規アカウントの利用（T1078）
  • 影響: MFAが形骸化し、初期侵入から横展開の足がかりになります。SMS/音声停止はこの経路のリスクを大幅に削減します。

• 移行期のヘルプデスク悪用・TAP乱用

  • 概要: 「パスキー登録できない」ユーザーを装い、サポートにMFAリセットやTAP発行を依頼します。運用の甘さを突く社会工学です。
  • ATT&CK例:
    • フィッシング/ソーシャルエンジニアリング（T1566）
    • 認証プロセスの改変・悪用（T1556）
    • 正規アカウントの利用（T1078）
  • 影響: SMS/音声停止後も、ブートストラップ経路が弱いと迂回路になります。

• AiTMによるセッションハイジャック（MFAバイパス）

  • 概要: ログイン・フローに中間者を挟み、MFA後のセッションクッキーを奪取・再利用します。
  • ATT&CK例:
    • Adversary-in-the-Middle（T1557）
    • 代替認証素材の悪用：Webセッションクッキー（T1550.003）
  • 影響: パスキー採用でも、セッション管理が脆弱だと乗り越えられる可能性が残ります。高リスクアプリでの連続再認証やコンテキスト強化が必要です。

• OAuth同意フィッシング・不正トークンの付与

  • 概要: ユーザーや管理者に不正アプリの同意を取らせ、メール/ファイルに恒常アクセスします。
  • ATT&CK例:
    • フィッシング（T1566.002/003）
    • アプリケーショントークンの窃取・悪用（T1528）
  • 影響: 認証強化だけでは防げない領域で、同意ポリシーとアプリ審査が重要になります。

• レガシープロトコル/例外運用の残骸

  • 概要: 基本認証やアプリパスワードの取り残しが侵入口に。
  • ATT&CK例: 正規アカウントの利用（T1078）
  • 影響: 認証強化の“穴”になり得るため、完全な棚卸しと遮断が必要です。

総じて、SMS/音声停止は「人に依存する脆い認証要素」を外す効果が大きく、攻撃者のコストを底上げします。一方で、移行の過程と復旧運用が新たな攻撃面になるため、そこを守る設計が勝敗を分けます。

セキュリティ担当者のアクション

段階的・可観測・低摩擦を合言葉に、以下の順で動くとよいです。

• 可視化（0–30日）

  • 影響ユーザーの特定: 「SMS/音声のみ登録」のユーザー、実際の認証方法の使用状況をレポートで抽出します。
  • 重要資産の紐づけ: 特権ロール、機微アプリ、外部コラボユーザーをタグ付けし、強制順序を設計します。
  • 例外の洗い出し: レガシープロトコル、アプリパスワード、ヘルプデスクのMFAリセット権限を棚卸しします。

• パイロットと基盤整備（30–60日）

  • パスキーの小規模パイロットを開始し、端末種別（Windows Hello/Android/iOS、ハードキー）ごとのUXと失敗率を計測します。
  • 認証強度（Authentication Strength）を用いた条件付きアクセス（CA）を用意し、特権ロール・機微アプリに対して「フィッシング耐性必須」を適用するテストを行います。
  • ブートストラップ設計: TAPの発行者ロールを限定、発行の多要素確認、監査ログ監視を準備します。

• 拡大展開（60–120日）

  • 登録キャンペーン: 通知、ガイド、現地サポートデスク、バディ制度で登録率を上げます。登録完了ユーザーはSMS/音声を自発的に削除してもらい、併用期間を短くします。
  • ヘルプデスク手順: 本人性確認の多経路化、スクリプト化、録音/監査、なりすまし対策のトレーニングを実施します。

• 強制化とレガシー遮断（120–210日）

  • 特権・機微アプリでフィッシング耐性必須を強制し、SMS/音声を段階的に禁止します。
  • レガシープロトコル/アプリパスワードの全面遮断を実施し、監視で例外発生源を潰します。

• レジリエンス設計（並行）

  • エマージェンシーアカウント（ブレークグラス）を2つ以上、強固なパスフレーズ＋分離保管で用意し、四半期ごとにテストします。
  • セッション防御: 高リスクアプリでの短セッション/継続的アクセス評価、地理・デバイス・行動のコンテキストを強化します。
  • サプライヤ・委託先の足並み: 連携テナント・B2B/B2Eの要件整合を進め、鎖の弱い輪をなくします。

• モニタリングとKPI

  • フィッシング耐性MFA採用率、登録に要する中央値、ヘルプデスク呼量、TAP発行件数/失敗率、AiTM検知件数などを継続観測します。
  • 異常値に対しては原因を「技術/運用/教育」に切り分け、翌スプリントに改善サイクルを組み込みます。

最後に、今回の方針は「確度が高く、実務に落としやすい」一方で、「今すぐ着手しないとデッドラインに間に合わない」タイプの変革です。移行は“技術×運用×人”の総合格闘技です。現場に寄り添った導線づくりと、ブートストラップ経路を最小攻撃面に保つ工夫こそが、攻撃コストを継続的に押し上げる最短ルートです。

参考情報

• セカンダリ報道: Microsoft to Disable SMS and Voice Authentication in Entra ID (GBHackers)
• 参考ドキュメント（運用設計の一般論理解に有用）: Microsoft Entra ID の認証方法（Microsoft Learn）

注記

• 本稿のうち、公共部門やソブリンクラウドの適用範囲、最終電話確認の具体運用など一部は現時点の公知要素からの推測を含みます。最終的な適用時期・範囲・手順は、組織のテナントに配信されるMicrosoft公式告知・ドキュメントでの確認を必ず行ってください。