Microsoft 365のSMS認証はいつ終わるのか｜9月1日と2027年2月1日、情シスがやるべき移行準備

Microsoft 365へのログインで、SMSに届く6桁のコードを入力している会社は、認証方法の見直しが避けられません。Microsoft 365 SMS認証の基盤であるMicrosoft Entra IDでは、2026年9月1日からSMSまたは音声認証が有効なユーザーにパスキーが自動的に有効化され、さらに2027年2月1日にMicrosoftが提供するSMS・音声の通信配信そのものが終了します。ただし、9月1日に突然ログインできなくなるわけではありません。この2つの日付は意味がまったく異なるためです。本記事では、何がいつ変わるのかを整理したうえで、情シスが実際に手を動かす順番までを扱います。なお内容は2026年8月14日時点の公開情報にもとづいています。

認証方式の変更で意外と負担になりやすいのは、設定作業そのものよりも利用者への説明です。実際に約60人を対象としてMFAの認証方法を変更したときは、切り替え初日だけで「見たことのない画面が出た」「これは本当にMicrosoftの画面なのか」「今までのSMSではだめなのか」といった問い合わせが十数件発生しました。事前にメールで手順を案内していても、実際のログイン画面が変わると、不安になって操作を止める利用者は珍しくありません。

こうしたケースを見ると、認証方式の変更では技術的に正しい設定をするだけでは足りないことが分かります。「いつから何が変わるのか」「その画面が表示されたらどうすればよいのか」を、利用者の目線で先回りして伝える必要があります。今回のパスキー移行でも、9月1日の設定変更そのものより、見慣れない登録画面を見た社員から問い合わせが集中することのほうが、情シスにとって現実的な問題になりそうです。

まず押さえるのは2つの日付——9月1日は「廃止の日」ではない

今回の変更で最も避けたい誤解は、「2026年9月1日にSMS認証が使えなくなる」と受け取ってしまうことです。9月1日は、Microsoft Entra IDでSMSまたは音声認証が有効になっているユーザーに対してパスキーが自動的に有効化され、MFAのサインイン時に登録を促す画面が表示され始める日です。一方、Microsoftが提供するSMS・音声の通信配信が終了するのは、その約5か月後の2027年2月1日にあたります。

つまり9月1日は強制終了の日ではなく、移行準備が目に見える形で始まる日と捉えるのが適切です。対象ユーザーは登録を促す画面を既定で先送りできるため、当日に全社員のログインが一斉に止まることもありません。ただし、そのまま放置すれば2027年2月1日に業務影響が出ます。したがって、秋以降に段階的な移行を進める前提でスケジュールを組んでおくことが求められます。

Microsoft 365 SMS認証の終了後、社員のログインはこう変わる

情シスが社内で最も多く受ける質問は、「結局、社員の画面は何がどう変わるのか」という一点に集約されます。ここを曖昧にしたまま周知すると、かえって問い合わせが増えてしまいます。そこで、9月1日以降と2027年2月1日以降を分けて整理しておきましょう。

この差を理解しておくと、社内対応の優先順位が決めやすくなります。すなわち、9月1日に向けて必要なのは「驚かせないための説明」であり、2027年2月1日に向けて必要なのは「実際に登録を終わらせる運用」です。加えて、すでにパスキーやWindows Hello for Business、FIDO2セキュリティキーでサインインしている社員は、これまでどおりの方法を継続して利用できます。つまり、対応が本当に必要なのはSMS・音声に依存している層に限られます。

自社は対象か——「Microsoft 365を使う会社すべて」ではない

今回の変更は、Microsoft 365のアカウント基盤であるMicrosoft Entra ID（旧Azure AD）に関するものです。ここでいうテナントとは、おおまかに自社のMicrosoft 365の契約・管理単位を指します。2026年9月1日の自動有効化の対象になるのは、認証方法ポリシー（AMP）または従来のMFA設定で、SMSまたは音声を利用できるユーザーが存在している環境です。

そのため、すでに全社員をWindows Hello for BusinessやFIDO2セキュリティキー、パスキーへ移行済みで、SMSや音声を無効にしている会社であれば、実務上の影響はほとんどありません。一方で見落としやすいのが、「普段はAuthenticatorのプッシュ通知を使っているが、予備としてSMSも残している」というケースです。日常的にSMSを使っているかどうかではなく、SMSまたは音声が認証方法として有効な状態かどうかが判定基準になります。

パスキーの選び分け——同期型とデバイスバインド型で運用が変わる

利用者への説明は難しくする必要がありません。「顔や指紋、端末のPINで本人確認し、その端末に保存された鍵でログインする仕組み」と伝えれば十分です。パスワードやワンタイムコードのような「相手に渡せてしまう秘密の文字列」を使わないため、フィッシングやSIMスワップへの耐性が高まります。

一方、情シスが判断すべきなのは説明の仕方ではなく、どの種類のパスキーを社内標準にするかです。Microsoft Entra IDがサポートするパスキーは、大きく2種類に分かれます。

実務では、会社支給のWindows PCを使う一般社員にはWindows Hello for Business、業務用スマートフォンを配布している社員にはMicrosoft Authenticatorのパスキー、複数人でPCを共用する工場や店舗にはFIDO2セキュリティキー、といった割り当てが現実的です。なお、「Authenticatorを入れれば同じ」という理解は誤りです。従来のプッシュ通知型MFAと、Authenticator内に保存するパスキーは仕組みが異なります。そのため移行計画では、どちらを採用するのかを明記しておきましょう。

なぜMicrosoftはSMSをやめるのか——フィッシング耐性という理由

上司から「今まで問題なかったのに、なぜ変えるのか」と問われた場合は、SMSが無意味になったのではなく、より攻撃に強い方式へ標準を移すためと説明すると納得を得やすくなります。SMSによるMFAは、パスワード単独より安全性を高められる手段でした。しかし確認コードは、結局のところ人が読み取って別の画面に入力できる情報にすぎません。

実際、偽のMicrosoft 365ログイン画面へ誘導し、パスワードに続いてSMSの確認コードまで入力させるリアルタイム型のフィッシングは、すでに一般的な攻撃手法になっています。加えて、電話番号を不正に別のSIMへ移す「SIMスワップ」のように、番号そのものを狙う手口も存在します。これに対してパスキーやFIDO2セキュリティキーは、正しいサービスとの間で暗号学的にやり取りするため、偽サイトでは認証が成立しません。

つまり今回の対応は、単なるベンダー都合の仕様変更ではなく、フィッシング対策の強化施策として位置づけられます。この整理をしておくと、予算取りや稟議の説明もしやすくなるはずです。

影響範囲を確認する——最初にやるのは「SMSを使える人」を数えること

対応の第一歩は、全社員へパスキー登録を依頼することではありません。まずは自社の現状把握です。管理画面を利用できる担当者であれば、Microsoft Entra管理センターの［Entra ID］→［認証方法］→［アクティビティ］から、各認証方法を登録しているユーザーの概況を確認できます。ただし、利用できるレポートはライセンスや管理者ロールによって異なります。またメニュー名は2026年8月時点のものです。

1. 認証方法ポリシーを確認する：SMSと音声が、どのユーザーやグループに許可されているかを確認します。
2. 認証方法アクティビティで規模をつかむ：携帯電話などを登録しているユーザー数から、影響範囲の目安を把握します。
3. 対象者を区分ごとに分ける：一般社員、管理者、工場や店舗の現場社員、共有端末の利用者などに分類します。
4. 正確な一覧が必要なら公式スクリプトを使う：MicrosoftはSMSまたは音声が有効なユーザーを抽出するPowerShellスクリプトをGitHubで公開しています。実行にはグローバル閲覧者、認証ポリシー管理者、セキュリティ閲覧者のいずれかのロールが必要です。

注意したいのは、管理センターに表示される「登録済み認証方法」の数字と、今回の自動移行の対象者が必ずしも一致するとは限らない点です。とはいえ、非エンジニアの担当者が無理にスクリプトを実行する必要はありません。まず画面上で規模感をつかみ、正確な一覧が必要になった段階で社内SEや保守ベンダーへ「SMS・音声が有効なユーザーを抽出してほしい」と依頼する進め方でも十分です。

つまずくのはこの3パターン——スマホを使えない社員ほど先に確認する

移行で問題になりやすいのは、自分専用のPCとスマートフォンを毎日使う一般社員ではありません。むしろ、個人スマートフォンの業務利用を認めていない社員、共有端末を使う現場社員、認証に使える端末条件がそろっていない社員です。対象人数を把握したら、次は働き方ごとの代替手段を整理しましょう。

重要なのは、全社員を同じ認証方法へ統一することではありません。端末環境と働き方に応じて、複数の移行パターンを用意しておくことです。加えて、認証手段を紛失した場合に備えて予備の認証情報や復旧手順まで設計しておけば、切り替え後の問い合わせを大きく減らせます。

認証方法を棚卸しすると、「SMSを使っているのは一部だけだろう」という事前の想定と、実際の対象人数が大きくずれることがあります。実際に約120アカウントを棚卸ししたときは、日常的にSMSで認証している社員は20人ほどだったものの、予備の認証方法として携帯電話番号を残している社員まで含めると、対象は60人近くまで増えました。普段Authenticatorを使っている社員自身も、自分のアカウントにSMSが残っていることを把握しておらず、利用者への聞き取りだけでは対象者を正確に把握できませんでした。

さらに問題になったのが、工場勤務の社員です。約20人が共用PCを利用し、業務中は個人スマートフォンを持ち込めない運用だったため、「全員にAuthenticatorを登録してもらう」という方法が使えません。そこで一般社員はWindows HelloやAuthenticatorを利用し、スマートフォンを使えない現場社員にはFIDO2セキュリティキーを割り当てる形で運用を分けました。ここで分かったのは、対象者を数えるだけでは不十分で、誰がどの端末を使い、どの認証方法なら業務を止めずに運用できるかまで確認して初めて移行計画になるということです。

待つより先に動く——登録キャンペーンを自社の判断で有効化する

ここまで読んで、「9月1日を待つしかないのか」と感じた方もいるかもしれません。しかし実際には、登録キャンペーンを自社の判断で先に有効化するという選択肢があります。Microsoftも、ヘルプデスクの負荷を増やさずにユーザーを大規模に移行させる方法として、この手順を推奨しています。

手順自体は複雑ではありません。まず認証方法として「パスキー（FIDO2）」を有効にし、SMS・音声のユーザーがパスキー対応のポリシーに含まれていることを確認します。その上で認証ポリシー管理者としてMicrosoft Entra管理センターにサインインし、［Entra ID］→［認証方法］→［登録キャンペーン］で状態を「Microsoft Managed」に設定し、対象のセキュリティグループを指定します。すると対象ユーザーは、次回サインインしてMFAを完了する際にパスキーの設定を促されるようになります。

自社主導で先に有効化する利点は、タイミングを自分でコントロールできる点にあります。つまり、周知メールを出した直後や、ヘルプデスクの体制が整った週から段階的に始められるということです。逆に9月1日を待つ場合、全対象ユーザーに一斉に画面が出るため、問い合わせが集中しやすくなります。どうしても9月1日に自動有効化させたくないユーザーがいる場合は、その日より前に認証方法ポリシーからSMS・音声を外しておくという対処も可能です。ただしこの場合、代替の認証方法を先に登録させておかなければ当人がサインインできなくなる点には十分注意してください。

9月1日に間に合わない場合——一時オプトアウトは移行計画の代わりにならない

準備が間に合わない企業向けに、Microsoftはパスキーの自動有効化と登録キャンペーンを一時的にオプトアウトする仕組みを用意しています。利用できる期間は2026年9月1日から2027年2月1日までで、設定はMicrosoft Graphを通じて認証方法ポリシーの該当プロパティを変更する形になります。とはいえ、慣れないAPI操作を急いで行う必要はありません。導入・保守ベンダーへ相談し、影響範囲と設定内容を確認してもらうほうが安全です。

ただし、これはあくまで移行作業のための猶予にすぎません。2027年2月1日の提供終了と、その後のパスキー登録の強制は、この設定に関係なく適用されます。したがってオプトアウトを選ぶ場合も、「いつまでに対象者を洗い出すか」「パイロットユーザーをいつ切り替えるか」「全社員へいつ案内するか」を同時に決めておかなければ、単に問題を先送りするだけになってしまいます。

なお、規制や運用上の理由からSMS・音声を継続する必要がある企業向けには、Microsoft Security Storeを通じたカスタマーマネージド通信プロバイダーが用意されます。現行の予定では、対応事業者の情報が2026年9月18日以降に公開され、実際の選択と構成は2026年10月30日以降に可能となります。ただし通信費用は自社負担となるため、多くの企業ではまずパスキーへの移行を優先するほうが、コストと運用の両面でシンプルでしょう。

社内アナウンスは「9月1日にログインできなくなる」と書かない

周知で最も大切なのは、不必要に不安をあおらないことです。「SMS認証が廃止されます」とだけ大きく伝えると、「9月1日からMicrosoft 365に入れないのか」という問い合わせが殺到します。9月1日に起きるのは、対象ユーザーのログイン時にパスキー登録を促す画面が表示されることであり、それ以上ではありません。そのため社内通知では、「見慣れない画面が出ても障害ではない」「会社から別途案内する手順に従ってほしい」という2点を先に伝えるのが効果的です。

加えて、Microsoftは周知を「認識」「アクション」「リマインダー」の3段階に分けることを推奨しています。まず変更の事実と理由を伝え、次に端末種別ごとの具体的な登録手順を案内し、最後に未登録者へ個別にリマインドする流れです。実際、対象者を絞ったセキュリティグループ宛てに配信すれば、関係のない社員に不要な不安を与えずに済みます。エンドユーザー向けの通知テンプレートもMicrosoftから提供されているため、ゼロから文面を作る必要はありません。

まとめ：残り5か月半をどう使うか

2026年8月時点から2027年2月1日までは、およそ5か月半あります。決して長くはありませんが、段階的なテストと周知を行う時間としては十分です。むしろ9月1日を「勝手に認証が変わってしまう日」と捉えるより、2027年2月1日に向けた移行を具体的に始めるきっかけと受け止めるほうが、実務上は前に進みやすいはずです。

最後に、押さえるべき要点は3つです。第一に、SMS・音声だけに依存する社員を1人も残さないこと。第二に、スマートフォンを業務利用できない社員にも、FIDO2セキュリティキーなどの選択肢を用意しておくこと。第三に、同期パスキーとデバイスバインドパスキーのどちらを社内標準とするかを、早い段階で方針として決めておくこと。この3点さえ押さえておけば、期限直前になってログインできない社員が続出する事態は十分に避けられます。