MFA向けSMSの終わり

TLDR

• Microsoftは2027年2月1日をもって、Entra IDにおける多要素認証向けの自社SMSおよび音声通話サービスを終了します。
• グローバル管理者と外部ゲストには2027年7月1日までの例外が適用されます。
• 2026年9月1日以降、Microsoftは対象となるユーザーに対し、登録キャンペーンの一環としてパスキーの設定を求めています。
• 対象となるのはSMSを実際に使っているユーザーだけではありません。SMSまたは音声通話が方式としてまだ許可されている、あるいは登録されているアカウントも対象です。セルフサービスパスワードリセットのような復旧プロセスも確認が必要です。
• 企業はこの必要な移行を機に、フィッシング耐性のある方式へ切り替え、残っているパスワードの必要性を体系的に減らすべきです。

出典: https://learn.microsoft.com/en-us/entra/identity/authentication/concept-sms-voice-retirement

2026年9月1日以降、Microsoftは各テナントで登録キャンペーンを有効化しており、SMSまたは音声通話によるMFAが有効になっているすべてのユーザーに対し、次回のサインイン時にパスキーの設定を求めています。ユーザーはこれを当面スキップできます。
自動の登録キャンペーンとパスキーの有効化は、一時的に回避できます。ただしMicrosoft自身のSMSおよび音声通話サービスの停止日が変わるわけではありません。

2027年2月1日をもって、一般ユーザー向けのMicrosoft自身のSMSおよび音声通話サービスがオプトアウトの余地なく終了します。追加の認証方式としてSMSまたは音声通話しか利用できないユーザーアカウントは、期日までに代替の方式が必要です。そうでなければ、対象ユーザーは強い認証を求めるサインインを完了できなくなります。

2027年7月1日には、グローバル管理者と外部ゲストについてもMicrosoftのSMS／音声が停止されます。

代替としては特にパスキー、Windows Hello for Business、FIDO2セキュリティキー、そして利用シナリオに応じたその他の適切な方式が考えられます。番号照合を使うMicrosoft AuthenticatorはSMSに比べて保護を高めますが、それ自体はフィッシング耐性がありません。

規制上または運用上の理由でSMSを維持しなければならない場合は、Microsoft Security Storeの通信事業者経由で引き続き利用できます。その場合は別途の契約となり、課金はメッセージ単位になる予定です。提供者は9月18日から表示され、設定できるのは10月30日からです。つまりMicrosoftは今後このサービスを自社では運用せず、外部の提供者に委ねます。

見落とされがちな点があります。対象はSMSを使っている人ではなく、SMSが有効になっている人だということです。何年も前からAuthenticatorアプリを使っていても、バックアップとして電話番号を登録したままの人は、これまで定期的にテキストコードを待っていた人と同じように対象になります。多くのテナントでは、歴史的にこれが明確な多数派です。もう一つ重要な点があります。この廃止はサインインだけの話ではありません。この変更はセルフサービスパスワードリセットにも及びます。SMSと音声通話は、その用途でもMicrosoft自身の検証方式としては利用できなくなります。そのため組織は、パスワードリセットとアカウント復旧にどの代替方式を用意するのかを確認しなければなりません。

なぜMicrosoftはこれを行うのか

この決定を押しつけと読むこともできます。あるいは実態どおりに読むこともできます。SMSは現代のリアルタイムフィッシングやSIMスワップ攻撃に対して、もはや十分な保護を提供しないという認識の表明である、と。

今日のMicrosoft 365アカウントへの典型的な攻撃は、もうパスワードを推測することではありません。ユーザーは本物そっくりのサインインページにたどり着き、そこで資格情報とMFAコードを入力します。攻撃者はその両方をリアルタイムでサインインに使い、セッショントークンを取得してユーザーのIDを乗っ取ります。こうした道具は、いまやスケールする攻撃サービスとしてダークネットで提供されています。自動化とAIは、信憑性のあるフィッシングキャンペーンの手間をさらに下げています。

パスキーのようなフィッシング耐性のある方式は、別の仕組みを使います。パスキーは、設定された対象のウェブアドレスと固く結びついており、偽のウェブサイトでは使えません。詐欺者がサインインを気づかれないように本物のサイトへ中継する巧妙な攻撃も空振りに終わります。ブラウザは正しいアドレスにいないことを認識し、そもそもパスキーを提示しません。仮に応答が本物のサービスに届いたとしても、そこには偽造できない形で誤ったアドレスが入っており、サービスはそれを拒否します。これにより判定は人ではなく技術の側に移り、暗号によって担保されます。ユーザーがウェブサイトの真正性を自分で見分ける必要はもうありません。この点がパスキーを、パスワードや従来型の2要素認証と分けています。 Windows Hello for Business、FIDO2セキュリティキー、Microsoft Authenticatorのパスキーも、同様のフィッシング耐性の原理を使います。ただし運用とユーザー導線の面では同一ではありません。デバイスへの束縛、同期、復旧、対応プラットフォームが異なるため、ペルソナごとに評価する必要があります。技術自体は何年も前からあります。新しいのは、Microsoftがいまそれを標準にしようとしていることです。

ちなみに銀行はこの道を数年前に通っています。長らくオンラインバンキングで最も一般的な承認方式だったSMS-TANを、大半の金融機関は自主的に廃止し、pushTAN、photoTAN、chipTANのようなデバイスや取引に紐づく方式へ置き換えました。技術的な実装は異なりますが、目的は似ています。承認を、登録済みのデバイスと個別の取引により強く結びつけることです。理由も今日と似ています。SIMスワップ、傍受されたメッセージ、そしてリアルタイムフィッシングです。

NIS2、DORA、ISO 27001の対象となる組織にとって、弱い認証方式を適切だと説明するのはますます難しくなります。ですからフィッシング耐性のある方式は、技術的な安全性だけでなく、経営、内部監査、監督機関に対する説明能力も強めます。

パスワードは廃止できるのか

移行にあたってどのみち認証方式を棚卸しし、ユーザーに周知し、新しいサインイン方式を導入するのであれば、同時にパスワードが実際にまだ必要な場所はどこかを確認すべきです。パスキーは、対応するアプリケーションではパスワードと第2要素の両方を置き換えられます。ノートPCのWindows Hello for BusinessとMicrosoft Authenticatorのパスキーを組み合わせれば、一般的なMicrosoftサービスへのパスワードレスなサインインが可能になり、適切な構成であればオンプレミスのActive Directoryリソースへのアクセスも可能です。

新しい従業員への配布も同様に設計できます。初期パスワードの代わりに、期限付きのTemporary Access Passを使えます。Entra IDはこれを正規のMFAおよびサインイン方式として認めています。これによりAutopilotで配布された端末での最初のサインインが行われます。その後、Windows Helloとパスキーを設定します。Temporary Access Passの期限が切れた後は、通常のサインインにパスワードは不要になります。

目指す姿では、従業員は通常の業務のなかで自分のパスワードを覚える必要も入力する必要もありません。これによりフィッシングのリスクとパスワードリセットの需要が大きく下がります。

実務でつまずくところ

glueckkanjaはこうした移行を日常的に支援しています。難しさが技術にあることはまれです。難しさは実装の細部にあります。

有効化は強制ではありません。パスキーを有効にしただけでは、関連するすべてのサインインでそれが使われる保証にはなりません。「System-preferred MFA」も、利用可能な最も強い方式を優先するだけで、拘束力のあるアクセス要件を強制するわけではありません。あるリソースにフィッシング耐性のある認証でのみ到達できるようにしたいなら、条件付きアクセスの適切なAuthentication Strengthで強制する必要があります。そうしなければ、より弱いフォールバック方式が引き続き提示され得ます。その場合、パスキーは「飾り」にすぎません。

現実的な進め方は4つのステップをたどります。

1. 棚卸し。誰がSMSと音声通話を有効にしているのか。誰が電話番号を登録していて、誰が最後に実際にそれを使ったのか。テナントは新しい認証方式ポリシーへ移行済みか。どのゲストユーザーがいて、彼らは自分のテナントを持っているのか。
2. ペルソナの決定。どのパスキープロファイル（デバイス束縛型か同期型か）がどのユーザーグループに合うのか、そしてどの条件付きアクセスポリシーがAuthentication Strengthでそれを拘束力をもって強制するのか。共有デバイスや外部ユーザーにはどう対処するのか。スマートフォンを持たない従業員はどうするのか。ゲストユーザーを持つパートナー企業をMFAについて信頼するのか。
3. パイロットとキャンペーン。まずパイロットグループで移行を試します。その後、周知を伴い猶予を限定した登録キャンペーンが続きます。ユーザーへの十分な準備は問い合わせを減らし、サービスデスクへの追加負荷を避けます。 例外には2027年2月1日より前の有効期限が必要です。
4. 停止。登録キャンペーンの完了後にはじめて、電話番号をMFA方式として削除し、ポリシーでSMSを無効化します。停止はMicrosoftの期日より前に意図的に行い、対象となるユーザーがもういないことを確実にできるようにします。

B2Bゲストには特有の事情があります。外部ユーザーには内部アカウントとは異なる登録モデルと信頼モデルが適用されます。ホームテナントのMFAをCross-Tenant Access Settings経由で確立できるか、そして自分のEntraテナントを持たないゲストにどの代替を用意するかを確認してください。2026年9月19日時点で、Microsoftは内部ゲストユーザー向けのパスキー対応を10月までに提供する計画です。より頻度の高い外部ゲスト（B2B）のケースは、パスキー対応の提供が後になり、日付は今後案内されます。おそらく多少の時間を稼ぐために、外部ゲスト向けのSMSと音声通話の提供は2027年7月まで延長されました。

それまでは、適切な移行方式または信頼にもとづくクロステナントのシナリオを用意する必要があります。

パスキーが解決しないこと。フィッシング耐性のあるサインインが守るのは認証の手続きであって、すでに確立されたセッションのすべてを自動的に守るわけではありません。マルウェア、侵害されたブラウザ、盗まれたセッショントークンは引き続き重要なリスクです。ですからAuthentication Strength、デバイスの準拠性、エンドポイント保護、リスクベースのアクセス判断、適切なセッション制御は、まとめて計画すべきです。そうすればリスクを下げられますし、デバイスの準拠性を必須にする場合は、アクセスを適切に管理された端末に限定できます。

当社の取り組み方

glueckkanjaでは、IDと端末を一つの統制システムとして捉えています。認証方式のポリシー、パスキープロファイル、Authentication Strength、条件付きアクセス、Intuneは、追跡可能な形で定義し、バージョン管理し、Infrastructure as Code（IaC）の原則に従って自動でロールアウトします。これにより目標状態と逸脱を文書化でき、変更をバージョン管理のうえで証明できます。ポータル上で状態を手作業で再構成することなく、運用、管理、監査のための確かな土台ができます。

この進め方は、当社のサービスであるManaged EntraとManaged Intuneの一部です。これらは技術ブループリント、継続的な調整、追跡可能な構成を組み合わせています。

まとめ

この見方に立てば、SMSの終了は厄介ごとではなく歓迎すべき契機です。とうに必要だった棚卸しを迫ります。そして、最も弱い環がもう存在しないIDへの扉を開きます。つまり、人の頭の中にあるパスワードです。

自社のテナントが現在どの位置にあるかを知りたい方には、まずアセスメントを実施することもできます。ぜひご相談ください。