まとめ
- Microsoft Entra IDでMicrosoftが提供するSMS・音声による多要素認証（MFA）は2027年2月1日に廃止され、その前段の2026年9月1日からパスキーが既定の認証方法として告知・登録案内されます。
- 移行の原則はパスキー。ただし企業利用では同期パスキーは許容せず、デバイス固定パスキーを標準にするのが安全です。また、Entraへのサインインに依存する法人向けパスワードマネージャは利用できません。
- 情シス目線でやるべきこと5項目をまとめました。
なぜ廃止か：背景と根拠
2026年7月13日、MicrosoftはEntra IDの既定の認証方法をパスキーにし、Microsoftが自ら提供するSMS・音声のMFAを廃止すると発表しました（Microsoft Security Blog, 2026/7/13 日本語訳）。確定している日付は次のとおりです。
| 日付 | 何が起きるか |
|---|---|
| 2026年9月1日 | パスキーが既定になる。SMS・音声が有効なユーザーは自動的にパスキー対象へ有効化され、次回MFA時にパスキー登録を促される（ナッジ、スキップ可） |
| 2026年9月18日 | セキュリティストア経由の通信プロバイダー（対応事業者・価格・条件）が公開予定 |
| 2026年10月30日 | 管理者が通信プロバイダーを選択・構成できるようになる |
| 2027年2月1日 | Microsoft提供のSMS・音声認証が廃止（ネイティブ提供の終了） |
| 2027年2月1日以降 | SMS・音声のみのユーザーは、サインイン時にパスキー登録を求められる（ブロック、スキップ不可）。この挙動にオプトアウトはなく全テナントに適用 |
なお、これらの日付はパブリッククラウドのみに適用され、その他の環境は別スケジュールで事前案内されます。
なぜSMS・音声を止めるのか
理由はセキュリティです。SMS・音声はワンタイムコードを、傍受・フィッシング・SIMスワップされやすいチャネルで送るため、現在のMFAの中でも脆弱な部類です。
米国NISTのSP 800-63B 第4版も、PSTN経由の帯域外認証（SMS・音声のワンタイムコード）を「制限付き認証子（restricted authenticator）」と位置づけ、フィッシング耐性がないと明記しています。
一方、パスキーが用いるWebAuthn／FIDO2は、検証者のドメイン名に基づく「検証者名バインディング」でフィッシング耐性を実現します（NIST SP 800-63B-4, §3.2.5）。
Oktaではすでに先行済み
同種の動きはOktaが先行しています。Oktaは2023年8月から新規顧客、2024年9月15日以降は更新時に既存顧客も、SMS・音声を使うなら自前の通信事業者の持ち込み（BYO Telephony）を必須化しました。
弊社もTwilioとOkta Workflowsを使う継続手順を検証・公開しています（CloudNative BLOGs）。自社提供テレフォニーの終了はOktaもすでに実施済みです。Microsoftはそれに加えて、パスキーの既定化に踏み込んでいます。
https://sec.okta.com/articles/2023/08/byo-telephony-and-future-sms-okta/
https://blog.cloudnative.co.jp/23633/
正しく理解しておきたいこと
公開情報から把握できる仕様変更のポイントは2点です。
2026年9月1日より既定認証手段をパスキーへ自動変更
SMS・音声が有効なユーザーは自動的にパスキー対象になり、登録キャンペーンも「Microsoft管理」に切り替わります。管理者が見落とすと現場から問い合わせが殺到することが予想されます。2026年9月1日から2027年2月1日までの期間に限り遅らせる一時オプトアウトはありますが（情報は2026年8月1日以降）、2027年2月1日の強制にオプトアウトはありません。
2027年2月1日よりSMS・音声認証の提供終了（Microsoft公式認証）
アカウントは無効化されませんが、多要素認証でSMS・音声しか認証手段を持たないユーザーにはパスキー登録のブロックプロンプト（スキップ不可）が出て、パスキー登録すればサインインできます。パスキーを登録できない端末（フィーチャーフォン等）しかなく、SMSプロバイダー追加契約しない場合は事実上サインインできず、実質ロックアウトとなります。
情シスがやるべきこと（全体像）
原則はSMS・音声認証を止めてパスキーへ移行することです。やるべきことを以下にまとめました。
- 対象ユーザーを把握する：SMS・音声が有効なユーザーを洗い出します
- 方針を決める：パスキー移行を前提とし、企業利用では同期パスキーを許容せずデバイス固定パスキーが推奨されます
- パスキー登録の手順を検証する：Entraでのパスキー登録には既存のMFAが前提となるため、別のMFA手段を展開しない場合は一時アクセスパス（TAP）の展開が必要です
- パスキーへ移行するための組織内展開：登録キャンペーンでユーザーをパスキーに誘導し、変更を事前に伝えます。2026年9月1日の自動切り替えを待たない選択も検討します
- 例外だけSMS継続を検討する：諸事情や端末制約で移行できないユースケースに限り、セキュリティストア経由の通信プロバイダー導入を検討します
対象ユーザーを把握する
移行計画の前に、SMS・音声が有効なユーザーを洗い出します。
PowerShell Script
Microsoft公開のPowerShellスクリプト（entra-sms-voice-usage-analyzer）で洗い出せます。実行にはグローバル閲覧者、認証ポリシー管理者、またはセキュリティ閲覧者のいずれかのロールが必要です（GitHub: microsoft/entra-sms-voice-usage-analyzer）。
Entra管理センター
Entra管理センターの画面でも確認できます。
認証方法｜アクティビティ
SMS・音声を使用しているユーザー数が0でなければ2026年9月1日以降の自動変更の対象がいると考えられます。
認証方法｜ポリシー
SMS・音声通話の有効/無効と対象グループの割り当て状況を確認します。2026年9月1日の自動有効化を先送りしたい場合は、2026年9月1日より前に当該グループから対象ユーザーを外します。
方針を決める
パスキーの種類と保存先（同期パスキーは許容しない）
パスキーには保存先の観点で分けると同期パスキーとデバイス固定パスキーの2種類ありますが、情シス部門がまず決めるべきことはシンプルです。“ユーザー個人のクラウドサービスに同期されるパスキーを許可するのか、しないのか” です。
https://www.passkeycentral.org/ja/introduction-to-passkeys/passkey-types
| 項目 | 同期パスキー | デバイス固定パスキー |
|---|---|---|
| 保存先 | クレデンシャルマネージャー（iCloudキーチェーン、Googleパスワードマネージャー、1Password、Keeperなど。私物・個人アカウントを含む） | 端末そのもの（Microsoft Authenticatorアプリ、Windows Helloのパスキー、FIDO2ハードウェアキー） |
| 保存先の統制 | できない（今回作成するパスキーは組織の管理外に作成・複製される） | しやすい（端末に固定） |
| アテステーション（提供元の検証） | 不可 | 可能 |
| 主認証基盤のパスキー保存先 | 非推奨 | 推奨 |
| 業務SaaS等のパスキー保存先 | 法人向けパスワードマネージャであれば検討価値あり | 利用可能 |
結論からいうと、組織利用では同期パスキーへの保存を禁止しデバイス固定パスキーのみへの保存が推奨となります。具体的にはMicrosoft Authenticatorアプリ上への保存（一番お勧め）か、FIDO2セキュリティキーになります。
同期パスキーは私物端末や個人アカウントのクレデンシャルマネージャーに保存・同期され、組織の認証情報が組織の管理外へ複製されます。当該クレデンシャルマネージャーの認証強度（多要素認証展開済みか等）を組織管理者が確認することはできません。一般ユーザーでも認証情報の漏洩は高リスクなので、保存先を組織が把握・統制できるデバイス固定パスキーに限定するのが安全です。
「端末ごとに登録し直すのは手間では」という意見もありますが、現在のMicrosoft Authenticatorでも、Entraアカウント（職場・学校アカウント）は復元されるのがアカウント名のみで復元後に再サインイン（登録）が必要と強度やリスクの観点からみると同等になります。
法人向けパスワードマネージャ（Keeper、1password、Bitwardenほか）を保存先にすることはできません！
なぜなら、パスワードマネージャのサインインにはSSO連携している認証基盤へのサインインが必要になりますが、認証基盤にサインインするためのパスキーをパスワードマネージャに入れてしまうと金庫を開けるための鍵が金庫に保存されている状態となってしまいます。（GWSとSSOしていてGoogleパスワードマネージャを利用している場合でも同様の問題があります）
Entraの設定
この方針に基づき実際にEntra IDの認証方法ポリシーを設定する担当者向けに詳細な情報をまとめました。まずは「同期パスキーを許可するか」「デバイス固定パスキーに限定するか」を方針として決めたうえで、パスキープロファイルの設定に落とし込みます。
「構成証明の適用」(Attestation enforcement)を有効にした上で「パスキーの種類」を「Device-bound」に指定すると、同期パスキーを除外することができます。
さらに「ターゲット特定のAAGUID」（AAGUIDの許可/ブロック）で、許可する認証器（パスキー保存先）のモデル・提供元を絞れますが、ここは必須ではないと考えています。今後ブロックリストに入れたいベンダがいれば検討するので十分でしょう。
注意点として、「構成証明の適用」は登録時にのみ効き、後から有効化しても既存ユーザーのサインインはブロックされません。一方で「パスキーの種類」や許可済みのAAGUIDを後から外すと、その方法で登録済みのユーザーはサインインできなくなります。
なお、AAGUIDはサービス単位での指定であってテナント単位ではありません。つまり、自社テナントのGoogle Workspaceアカウントに紐づくパスワードマネージャーか個人Googleアカウントに紐づくパスワードマネージャーか識別することはできません。
パスキー登録の手順を検証する
パスキー登録の“鶏卵”問題とTAPでの回避
移行で見落としがちなのが、パスキーをどう登録させるかです。デバイス固定パスキー（Microsoft Authenticatorのパスキーなど）を登録するには、Entraのパスキー登録の仕様として直近5分以内にMFAを完了している必要があります
つまり、パスキーを登録するために既存のMFAが先に要る、という卵が先か鶏が先かの関係になります。物理セキュリティキーを配布しておらず、Authenticatorのプッシュやワンタイムパスワードも別途展開したくない場合、最初のパスキーをどう登録させるかで詰まってしまいます。
回避策は一時アクセスパス（Temporary Access Pass、TAP）の利用です。管理者が期限付きのパスコード＝TAPを発行し、ユーザーはTAPの認証でMFAの前提を満たしてパスキーを登録できます。なお、手順によってはTAPを複数回利用することになるので、TAP発行時に一回限りとしないようにしてください。
Microsoft Authenticatorアプリにデバイス固定パスキーを登録する場合
Microsoft Authenticatorアプリにデバイス固定パスキーを登録する場合の手順ですが、まずMicrosoft Authenticatorアプリにアカウントを追加します。
アプリの一番上に「＋」アイコンがありますのでそこからアカウント追加画面に切り替え、「職場または学校アカウント」を選択します。（以降、画面はAndroid版です）
あとは指示に従ってサインインしてください。ここで1回目の多要素認証が発生するのでTAP利用で突破します。
ちなみに、マイアカウント画面から「Passkey in Microsoft Authenticator」を選択するとこちらの手順が案内されます。
サインインできたら当該アカウントから「パスキーの作成」を行います。ここで多要素認証が要求されるので2回目のTAPで突破します。
パスキーが作成され、デバイス固定キーとなっていることがわかります。
ハードウェアセキュリティキーに登録する場合
登録そのものは、マイサインイン（サインイン情報）画面から「サインイン方法の追加」で「Passkey」を選び、案内に従ってパスキーを追加します。
詳しい手順ガイドについてはJapan Azure Identity Support Blogの記事を見ていただいた方が良いでしょう。弊社ブログでもTAPを利用したセキュリティキーの利用方法をまとめています。
パスキーへ移行するための組織内展開
パスキー移行自体はライセンス費用なし（Entra Freeライセンスでも利用可能）で進められます。登録キャンペーンを有効にしてユーザーが次回MFA時にパスキーを登録するよう促すのが効率的です。2026年9月1日に自動で「Microsoft管理」になる前に、自社のタイミングで有効化しておくと情シス部門の負荷を抑えられます。
組織内展開を繰り上げたい場合は状態を「有効」へ変更し、対象にSMS・音声ユーザーのグループを指定。事前にパスキー（FIDO2）が有効で、対象がパスキー対応ポリシーに含まれていることを確認しておきます。
例外だけSMS継続を検討する
移行しにくいケース（フィーチャーフォン等）
パスキーは、スマートフォンの生体認証やクレデンシャルマネージャー、あるいはFIDO2ハードウェアキーを前提とします。すでにOSサポートが終了したスマートフォン（パスキーを利用するにはiOS17やAndroid14以降が必要）やフィーチャーフォン（ガラケー・ガラホ）のようにSMSしか扱えない端末しか持たないユーザーは、そのままではパスキーに移行できません。
対応としては、スマホを前提としないFIDO2ハードウェアセキュリティキーを配布するか、規制・業務上の理由があるならOATHトークン（TOTPトークン、いわゆるワンタイムパスワード）や後述のSMS継続を検討します。いずれにしても費用も時間もかかるため、ユーザーユースケースと対象ユーザー数は早めに把握するのが望ましいです。
例外としてSMS・音声を残す場合
最後に規制・業務上の正当な理由でSMS・音声を残さざるを得ないケースの検討となります。SMS・音声を残す選択肢はありますが、「今までどおり無料でMicrosoftが提供してくれる」という話ではありません。セキュリティストア経由で通信プロバイダーを契約・構成し、費用も顧客負担になります。したがって、SMS・音声の継続は原則ではなく、業務上どうしても必要な例外対応として扱うべきです。
現在の公開情報によると、セキュリティストア経由でカスタマーマネージド通信プロバイダーを契約できます。対応事業者・価格は2026年9月18日に公開予定、10月30日から構成可能で、費用はメッセージ単位の従量課金・顧客負担です。
M365管理センターの通知（MC1426371）では、2027年2月1日の少なくとも4週間前までに構成を完了することを推奨しています。
追加契約が必要・従量制・構築や設定、検証の工数が発生といった考慮事項があるので社内向けの説明・承認も考えれば2026年秋には方針が決まらないと大変です。
SMSや音声認証を残す場合も、契約して終わりにしない方がよいです。NIST SP 800-63B-4は、制限付き認証子を使う事業者に、制限付きでない代替手段の提供、リスクの利用者への明示、リスク評価への反映、そして移行計画の保持を求めています（NIST SP 800-63B-4, §3.2.9）。
SMS・音声を残す判断はあり得ますが、「恒久的に安全だから残す」のではなく「移行までの一時的な措置」と位置づけるのが推奨です。
まとめ
認証手段としてのSMS・音声の廃止は、業界全体の流れの中でMicrosoftがついに一歩踏み込んだものといえます。
情シスとしては、まず対象ユーザーを洗い出し、原則パスキー（企業利用では同期パスキーを許容せずデバイス固定パスキーが推奨）へ移行する方針を決めるのが出発点になります。
2026年9月1日に“自動で”始まる変更を見落とさないこと、パスキー登録の入口（必要ならTAP）を用意すること、そして移行しにくい層の対処方針を決定すること、焦らず着実に進めていきましょう。
（実際のところ、Microsoftはこの手の切り替えに対して猶予期間を延長する傾向があるのですが、当てにして後手に回るのもよくないですね）
