終了するのは「マイクロソフトが提供するSMS/音声配信」である
SMS認証が使えなくなるというのは、正しい表現ではない。正確には、2027年2月1日以降、Entra IDが提供する、通信事業者経由の音声・SMS配信が終了するということであり、（当然だが）世の中のSMS認証のサービスがすべて使えなくなるわけではない。Entra IDのログイン（MFA）にSMS認証しか使っていないシステムやユーザーは、マイクロソフトが推奨するAuthenticator、Passkey、FIDO2といった認証方式を設定する必要がある。
どうしてもEntra IDのサインインでSMS・音声を残す必要がある場合、正規の方法はMicrosoft Security Storeで通信事業者を選定・設定することだ。事業者情報の公開は2026年9月18日、Security Storeでの設定開始は同年10月30日が予定されている。
なお、今回の退役対象は認証方式ポリシー上のSMS・音声に限られ、外部認証方式（EAM）によるサードパーティMFA連携は対象外だ。理屈のうえでは、自社でキャリア網を使ったOTP配信基盤を用意し、外部認証方式としてEntra IDに接続する構成も考えられる。ただし開発・運用の負担に見合うかは慎重な検討が必要で、フィッシング耐性が得られない点は変わらない。
クラウドシステムのログインや、オンプレミスの業務システムとの認証連携に、すでにAuthenticator、Passkey、FIDO2、Windows Hello for Businessといった仕組みを導入しているなら、あらためて大掛かりな移行プランは必要ないかもしれないが、SMS対応終了に伴う処理や対策については、後半で改めて整理する。
なぜ終了するのか──2Gから引きずる構造的な弱点
そもそも、なぜSMSや音声によるワンタイムパスワードや認証を終了させるのだろうか。もちろん背景にはセキュリティ対策がある。
SMSは2Gの時代に発明された。パケットフォーマットのうちシグナリング（制御信号）用チャネルの空き領域にテキストデータを入れてやれば、音声を使わないメッセージ交換ができるというアイデアから始まった。シンプルだが効率よく機能したため、すぐに広がった。
2G（GSM）にも暗号化やSIMによる加入者認証の仕組みはあったが、通信事業者同士のローミングの認証（SS7プロトコル）に脆弱性があった。4G、5Gとプロトコルの高度化とモバイルネットワーク機器の強化によって、5GのSEPP、SS7はDiameterへの置き換えなどの対策が進んだ。しかし、SMSは古いネットワークを経由することが多く、事業者ごとの対応のばらつきもあり、ローミングの脆弱性は完全には解消されていない。
4G/5Gの時代になってもSMS認証には以下の脆弱性があると言われている。
・ローミング脆弱性の悪用
・SIMスワップ／電話番号乗っ取り
・SMS転送
・フィッシングによるコード窃取
・リアルタイム・フィッシングによるMFA突破
SMS認証が危険とされるのは、フィッシング詐欺や偽サイトを使った中間者攻撃への耐性が全くと言っていいほどないからだ。SMSを使ったワンタイムパスワードは、企業側はローコストでユーザーも使い勝手がよいため根絶は難しい。だが、NIST SP800-63Bにおいて、認証プロセスの保証レベルが規定され、パスワードやSMS・音声によるワンタイムパスワードは制限付きで利用が認められるという位置づけになった。
NIST SP 800-63B の改訂第4版では、PSTN（SMS・音声）経由のワンタイムパスワードが唯一の『制限付き認証子』に分類された。禁止ではないが、リスク評価と移行計画の策定が前提となる。同時にAAL2ではフィッシング耐性のある選択肢の提供が求められ、AAL3ではフィッシング耐性が必須要件となった。この改訂がSMS認証離れの流れを決定づけたと言っていい。
パスワードレスへの流れと、企業が押さえるべきタイムライン
フィッシングによるID情報の窃取・漏洩がなくならないのは、そもそもパスワードなりコードを人間に入力させているからだ。そのため近年では、デバイスと暗号鍵をベースとした認証に移行が進んでいる。パスワードレス認証やパスキーなどと呼ばれている技術だ。
マイクロソフトも当然この方向で、ID基盤を整備しつつある。Entra IDにおけるSMS認証の提供停止はこのような背景がある。マイクロソフトは、2026年9月1日からEntra IDでSMS/音声認証を有効にしているユーザーを対象に、自動的にPasskeyを有効にして登録を促す措置を開始している。
以上を踏まえると、各企業が押さえるべきタイムラインは以下のように整理できるだろう。
🔳現在：リソース・アセットの棚卸
Entra IDのログインにSMS/音声認証を使っているユーザーの把握。特にそれしか使っていない、対応できないユーザーを洗い出す
🔳2026年9月～：Passkey（他）への移行促進
各社のポリシーやシステム環境に応じて、デフォルトの認証をPasskeyやFIDO2に設定させる。Authenticator（認証アプリ）はパスキーモードにする
🔳2027年2月1日～：マイクロソフトのSMS/音声認証配信が終了
原則としてSMS/音声認証の移行完了
セキュリティ対策を考えると、これを機会としてSMS認証の廃止を徹底させたい。事前に準備している企業の中には、業務システムの認証機構を統合・強化する取り組みまで踏み込んでいるところもあるだろう。
誰にどの方式を割り当てるか──棚卸と移行後の検証
以下の表は、移行に際して誰がどのような認証方式を設定すればいいのかの目安を示したものだ。必ずしもこの設定にこだわる必要はないが、リソースの棚卸や設定状況の確認をするときの参考にするといい。
SMS認証しか設定していないユーザーの属性によって、上記表の推奨対応を参照して認証方式を決める。
認証方法を決めるときに、もうひとつ注意すべきなのは、移行後に実際のSMS認証なしでログインができるかのテストをしっかり行うことだ。ユーザーによっては、MFAのときに入力しているキーがショートメッセージなのかメールなのか、システムのプッシュ通知なのか正確に把握していない可能性を考慮すると、自己申告だけでSMS認証のみのユーザーを識別するのは得策ではない。
設定画面での確認方法を正しく周知するとともに、事後のログイン検証も欠かせない。
また、システム管理者などは、移行のタイミングを利用して、スマートフォンを紛失した場合、PCからログインできない状態でもログインできるかどうかのテストと、アカウントの復旧作業を確認しておくとよいだろう。
オンプレミス／クラウド、環境別に見た影響範囲
業務システムがオンプレミスシステムやAzureプライベートクラウドで完結している場合、今回のSMS認証移行にあたって大規模な作業は発生しない。Windows Hello（Windows Hello for Business含む）、Active Directoryの中で、指紋や顔認証、Active Directoryによるシングルサインオン、Entra IDとの認証連携を変えるものではない。Entra IDの認証時にSMSでしか対応できないユーザーのみを移行させればよい。
平均的な企業はパブリッククラウドや各種クラウドサービスを業務に活用しているだろう。今回のEntra IDのSMS/音声認証の配信サービス終了は、これらのサービスとは関係ない。そのまま使うことができる。
しかし、それらのアカウントIDがマイクロソフトアカウントや企業システムのアカウントと共有している場合、できればあわせてSMS認証からFIDO2やAuthenticatorによる認証に移行させたほうが安全だといえる。他社システム、外部サービスを含めて認証基盤を統合する場合、それらのシステムがSAMLまたはOIDCに対応しており、認証情報やセッション情報を共有できるかどうかを確認する必要がある。
サービス事業者がMFAにSMSしか用意していない場合は、事業者にフィッシング耐性のあるMFA（FIDO2セキュリティキー／パスキー）への対応を依頼するか、別の事業者やサービスを考える。業務でパスワード、SMS認証しか対応していないシステムを使うべきではないからだ。
SMSサービスを終了させる本来の目的は、フィッシング耐性を高めるためのPasskey・FIDO2への移行にあることを認識しておきたい。
