「前は1PasswordのTOTPで入れていた azure-admin@[会社名].com が、最近はSMSしか選ばせてくれない」「ポータルで2025年9月30日までに移行しろと言われるが、何をすればいいか分からない」——この記事では、この2つのモヤモヤを一気に整理し、実務でそのまま使える設定例とチェックリストまでまとめます。
AzureマスターアカウントのMFAがTOTPからSMSに“変わった”ときにまず知っておきたいこと
まず押さえておきたいのは、次の2点です。
- TOTP（OATH-TOTP）は廃止されていない
- 「SMSしか出てこない」のはバックエンド設定やポリシーの結果であることが多い
Microsoft Entra ID（旧Azure AD）は現在も、ソフトウェア／ハードウェアのOATH-TOTPトークンを正式サポートしています。30秒や60秒ごとに変わる認証コードを生成する、いわゆる「TOTPアプリ」「ハードウェアトークン」は引き続き利用可能です。
ではなぜ、これまで1Passwordや別のOTPアプリでMFAしていた azure-admin@[会社名].com に、突然SMS画面だけが出るのでしょうか。
典型的な症状
- 以前：ユーザー名＋パスワード → TOTP入力画面が表示される
- 最近：TOTP画面に行かず、「電話番号宛のSMSコード入力」画面にリダイレクトされる
- サインインオプションからTOTPやAuthenticatorが選べない、または出てこない
この場合、原因は概ね次のどれか（または複数の組み合わせ）です。
| 現象 | 主な原因候補 | 確認／対応する場所 |
|---|---|---|
| TOTPが候補に出てこない | 認証方法ポリシーで「ソフトウェアOATHトークン」や「Microsoft Authenticator」が無効、または対象外 | Entra 管理センター → Entra ID > Authentication methods > Policies |
| SMSばかり優先される | System‑preferred MFA（システム推奨MFA）の優先順位＋登録済み方法の組み合わせ | Entra 管理センター → Entra ID > Authentication methods > Settings |
| パスワード無しで電話番号＋SMSだけで入れる | 「SMSサインイン」（パスワードレス）が有効で、そのフローに入っている | Entra 管理センター → Entra ID > Authentication methods > Policies > SMS |
逆に言えば、これらの設定を正しく整えれば、再びTOTPやAuthenticatorを主役に戻すことができます。
登録済み電話番号・MFA方法はどこで確認する？
「今、このユーザーはどのMFA方法を登録しているのか」「どの電話番号をSMSに使っているのか」は、管理者とユーザー本人で確認場所が異なります。
管理者が確認・変更する場合（Entra 管理センター）
管理者は、Microsoft Entra 管理センターで各ユーザーの認証方法を確認できます。
- Microsoft Entra 管理センターに、少なくとも Authentication Administrator 以上でサインイン
- Entra ID > Users を開く
- 対象ユーザー（例：
azure-admin@[会社名].com）を選択 - 左メニューから Authentication methods を選択
ここで次のような情報を確認・編集できます。
- SMSや音声通話に利用する電話番号（認証方法として登録した番号）
- Microsoft Authenticator（プッシュ通知／アプリコード）
- ソフトウェアOATHトークン（TOTP）
- FIDO2セキュリティキー／パスキーなど
注意点として、ユーザーの「プロフィール」にある携帯電話番号は、MFA用の電話番号とは別扱いです。公開プロフィールの電話番号ではなく、Authentication methods で登録した番号がMFAに使われます。
ユーザー本人が確認・変更する場合（My Sign‑Ins / Security info）
ユーザー自身は、ブラウザで次のURLにアクセスすることで、自分の認証方法を確認・追加・削除できます。
ここから「サインイン方法の追加」ボタンで、Authenticatorアプリや電話番号、FIDO2キーなどを追加できます。また、電話番号を変更したり、不要になった方法を削除することも可能です。
| 立場 | 画面 | 主な操作 |
|---|---|---|
| 管理者 | Entra 管理センター Entra ID > Users > 対象ユーザー > Authentication methods | 電話番号の登録／変更、AuthenticatorやTOTPの追加・削除、TAPの発行など |
| ユーザー本人 | My Sign‑Ins / Security info | 自分のMFA方法の登録・変更・削除、デフォルト方法の選択 |
「SMSしか出てこない」状態からTOTP・Authenticatorを復活させる実務ステップ
ここからは、管理者視点での「復旧・再登録」手順を、原因別に整理します。
1. 認証方法ポリシーでTOTP／Authenticatorが有効か確認
まず、テナント全体の「認証方法ポリシー」で、TOTP関連が無効化されていないか確認します。
- Entra 管理センターで Entra ID > Authentication methods > Policies を開く
- 次の方法を確認
- Microsoft Authenticator
- Software OATH tokens（ソフトウェアOATHトークン）
- それぞれのポリシーで、次を設定
- Enable：On（または Microsoft managed）
- Target：
azure-admin@[会社名].comが含まれるグループ、もしくは All users
ここで対象から外れていると、ユーザー側でTOTPを登録していても「使える方法」として提示されません。
2. System‑preferred MFA（システム推奨MFA）の影響を確認
System‑preferred MFA を有効にすると、ユーザーが登録している方法のうち「より強い」と判断されたものが自動的に優先されます。
例えば、
- SMS と Authenticator プッシュ の両方が登録されている場合 → Authenticator プッシュが優先される
- SMS しか登録されていない場合 → 結果的にSMSのみが提示される
つまり、System‑preferred MFA 自体が悪いのではなく、「登録済みの中でSMSしか残っていない」状態が問題です。
確認手順：
- Entra ID > Authentication methods > Settings を開く
- System-preferred multifactor authentication が Enabled になっているか確認
- 有効にしたまま運用する場合は、後述の「おすすめ構成」に沿って Authenticator やFIDO2を登録させ、SMSはバックアップ用途に限定する
3. SMSサインイン（電話番号＋SMSだけでのログイン）を無効にするか検討
Entra ID には、パスワードを使わず、電話番号＋SMSコードだけでサインインする「SMSサインイン」機能があります。これはフロントライン（現場）ワーカー向けの簡易サインイン手段であり、一般的な情報系ユーザーや管理者には推奨されません。
「パスワードを入れずにSMSだけで入れてしまう」「SMS画面から戻れない」といった場合は、SMSサインインポリシーを見直します。
- Entra ID > Authentication methods > Policies > SMS を開く
- Use for sign-in を Off とし、少なくとも管理者が含まれるグループを除外する
- フロントラインユーザーにのみ必要な場合は、専用グループを作り、そのグループだけを対象にする
4. ユーザーごとの認証方法を整備する（TOTP再登録を含む）
ポリシー側の設定を整えたら、ユーザーに実際の方法を登録させます。
- 管理者が対象ユーザーの Authentication methods 画面を開く
- 必要に応じて、古くなった電話番号や不要な方法を削除
- ＋ Add authentication method から、次を追加
- Microsoft Authenticator（プッシュ通知＋アプリの確認コード）
- Software OATH tokens（1Password等で使うTOTP）
- バックアップ用の SMS / Voice call
- ユーザーに My Sign‑Ins にアクセスしてもらい、ガイドに沿って登録を完了させる
ソフトウェアOATHトークン（TOTP）は、Authenticatorアプリだけでなく、1PasswordやBitwardenなど汎用OTPアプリでも利用できます。Entra側には「シークレットキー」を登録し、アプリ側で同じキーを読み込む形になります。
5. どうしてもログインできない管理者アカウントの復旧（TAP＋サポート）
もし azure-admin@[会社名].com がテナント唯一の全体管理者で、MFAを突破できない場合は、次の順番で対応を検討します。
- 他に全体管理者や緊急（ブレークグラス）アカウントがないか確認
- 他の管理者から、対象ユーザーに対して Temporary Access Pass（TAP） を発行
- TAPは、時限パスコードでサインインさせ、AuthenticatorやFIDO2などの強力な方法を再登録させるための一時的な鍵です。
- どうしても誰も入れない場合：Microsoftサポートに連絡し、MFAリセット／TAP発行などの支援を依頼
このような「全員ロックアウト」のリスクを避けるために、Microsoftは緊急用（ブレークグラス）アカウントを少なくとも2つ用意することを推奨しています。
2025年9月30日までに必須の対応：レガシーMFA/SSPRポリシーから「認証方法ポリシー」への移行
ポータルに表示される「2025年9月30日までに移行してください」という案内は、レガシーなMFA/SSPRポリシーでの“認証方法の管理”が廃止されることを指しています。
よくある誤解として、
- 「別の管理用ユーザーで2FAが有効だから、移行しなくても実質OKでは？」
というものがありますが、これはNGです。
理由：
- 廃止対象は「ユーザー単位のMFA設定」ではなく、テナント全体で認証方法を管理するプレーン（管理画面）
- 2025年9月30日以降、レガシーMFA/SSPR画面からは認証方法を管理できなくなる可能性が高い
- 移行しないまま放置すると、「どこで何が有効になっているのか」が不透明になり、トラブルシュートが困難になる
移行先：Authentication methods policy（認証方法ポリシー）
今後は、すべての認証方法を Authentication methods policy に統合して管理します。
管理画面への経路：
- Entra ID > Authentication methods > Policies
ここに「Manage migration」ウィザードがあり、レガシーMFA/SSPRの設定を棚卸しして新ポリシーへ統合できます。
移行状態の3つのモード
| モード | 概要 | 主な用途 |
|---|---|---|
| Pre-migration | 認証方法ポリシーは「サインインのみ」に使用。レガシーMFA/SSPR設定も尊重される | まだ移行を始めていないテナントの初期状態 |
| Migration in progress | 認証方法ポリシーがサインインとSSPRの両方に使用されるが、レガシー設定も併存 | 設定を新ポリシー側に移しつつ、安全に検証したい期間 |
| Migration complete | 認証方法ポリシーだけが有効。レガシーMFA/SSPRの設定は無視される | 移行が完了した本番状態。将来的に標準となる |
Microsoftは、2025年9月30日までに少なくとも Migration in progress を経て、最終的に Migration complete にすることを推奨しています。
最小変更での現実的な移行手順（概要）
- 現状の棚卸し
- レガシーMFAポリシー：Entra ID > Users > Per-user MFA > service settings
- レガシーSSPRポリシー：Entra ID > Users > Password reset > Authentication methods
- 現在の Authentication methods policy の設定
- Authentication methods policy で同等以上の設定を再現
- Authenticator、Software OATH、FIDO2、SMS/音声など必要な方法を Enabled にし、対象グループを割り当て
- 「Migration in progress」に切り替え（ウィザードから）
- 主要なシナリオで動作確認
- 管理者サインイン、一般ユーザーサインイン、SSPRの動作など
- 問題がなければ「Migration complete」に切り替えし、レガシー側は事実上無視される状態に
おすすめのMFA構成テンプレート
ここからは、実際のテナントでそのまま採用しやすい「おすすめ構成パターン」を示します。
基本方針
- 認証方法は最低2つ以上（できれば3つ）
- 強い方法を主役、SMS/音声はバックアップ
- 管理者・高リスクユーザーにはフィッシング耐性のある方法（FIDO2/パスキーなど）を要求
- TAPとブレークグラスアカウントで「復旧ルート」をあらかじめ用意
ロール別おすすめ構成
| 対象 | 主なMFA方法 | バックアップ方法 | 補足 |
|---|---|---|---|
| 一般ユーザー（情報系） | Microsoft Authenticator プッシュ（番号マッチング） ソフトウェアOATH TOTP（Authenticator/1Password等） | SMS／音声通話 | System‑preferred MFA を有効化し、プッシュ or TOTP を優先 |
| 管理者／特権ユーザー | FIDO2/パスキー Microsoft Authenticator（パスワードレス＋プッシュ） | TOTP＋SMS（強固なパスワードと組み合わせ） | CAの認証強度ポリシーで「Passwordless MFA」または「Phishing-resistant MFA」を要求 |
| フロントライン（現場）ユーザー | SMSサインイン（必要な場合のみ） Authenticatorプッシュ | 音声通話 | 情報系と混在させず、専用グループ＋専用CAポリシーで制御 |
| ブレークグラスアカウント （緊急用） | FIDO2/パスキー（推奨） または証明書ベース認証 | 非常に長く強力なパスワード | CAの対象外とし、物理的に厳重保管。四半期ごとにサインインテスト |
これらの構成はすべて、Authentication methods policy と Conditional Access（認証強度） の組み合わせで実現します。
すぐに実施するチェックリスト
ここまでの内容を踏まえ、「とりあえず今日やるべきこと」をチェックリストにまとめます。
- ユーザーの認証方法を棚卸し
- Entra 管理センターの Authentication methods で主要ユーザー（特に管理者）の方法を確認
- 電話番号・Authenticator・TOTPが正しく登録されているかチェック
- 認証方法ポリシーを整備
- Entra ID > Authentication methods > Policies で、Microsoft Authenticator／Software OATH トークン（TOTP）／FIDO2などを有効化
- 対象グループに管理者・主要ユーザーが含まれていることを確認
- System‑preferred MFA を有効化し、SMSサインインは原則無効化
- System‑preferred MFA：Enabled（強い方法を優先）
- SMSサインイン：情報系ユーザーには適用しない。必要なフロントライン用グループだけを対象にする
- レガシーMFA/SSPRからの移行状態を確認し、ウィザードを実行
- Authentication methods policy の Manage migration を開き、現在の状態を確認
- Migration in progress → 検証 → Migration complete の順で進める計画を立てる
- 締切：2025年9月30日
- Temporary Access Pass（TAP）を有効化
- Entra 管理センターで TAP ポリシーを有効にし、管理者の再登録やロックアウト復旧の手順書を作成
- 緊急用（ブレークグラス）アカウントの整備
- クラウド専用の全体管理者アカウントを最低2つ作成
- すべてのCAポリシーから除外し、強固なパスワード＋パスキー等で保護
- 四半期ごとにサインイン疎通テストを実施
「最小変更」で進めるための考え方
実案件では、「ユーザーへの影響を最小限にしながら、強度を上げたい」というニーズがほとんどです。そのための現実的な進め方の一例を挙げます。
ステップ1：まずは「見える化」と「バックアップ」から
- Authentication methods 活動レポート（Registration/Usage）で、どの方法がどれだけ使われているかを把握
- 管理者・主要部門のアカウントに、必ず2種類以上の方法（例：Authenticator＋TOTP）を登録
- ブレークグラスアカウントとTAPポリシーを先に整備し、「最悪のときの逃げ道」を確保
ステップ2：新しい強い方法を「追加」し、古い方法はすぐに切らない
- FIDO2/パスキーやパスワードレスAuthenticatorを「追加」で導入し、しばらくはSMSもバックアップとして残す
- Conditional Accessの認証強度で、重要度の高いアプリから順に Passwordless / Phishing-resistant を要求していく
- 数ヶ月運用して問題がなければ、徐々に「パスワード＋SMS」だけの組み合わせを許可しないポリシーへ移行
ステップ3：最終的にSMSは「バックアップMFA」に格下げ
- Authentication methods policy では SMS を有効のまま（完全には切らない）
- しかし、重要なアプリにアクセスするための認証強度ポリシーでは「フィッシング耐性MFAのみ許可」など、より強い組み合わせを要求
- SMSサインイン（パスワードレス）は現場専用。情報系ユーザーからは排除
こうすることで、ユーザーに急激なUIの変化を強いずにセキュリティレベルを底上げしつつ、Azureマスターアカウントのような重要IDも安全に運用できます。
用語の簡単おさらい
- 認証方法ポリシー（Authentication methods policy）
すべての認証方法（FIDO2、Authenticator、TOTP、SMSなど）を一元管理する新しいポリシー。 - System‑preferred MFA
登録済みの方法の中から、より強い方法を優先的に提示する機能。SMSよりもAuthenticatorやFIDO2を優先。 - 一時アクセス パス（Temporary Access Pass / TAP）
一時的なサインイン用コード。ロックアウト時や新しいパスワードレス方法の登録に利用。 - 認証強度（Authentication Strengths）
Conditional Accessのコントロールで、「どの組み合わせの認証方法を使わないとアクセスさせないか」を細かく指定できる仕組み。 - 緊急用（ブレークグラス）アカウント
テナントがロックアウトされないようにするための、高権限・緊急用アカウント。通常のCAポリシーから除外し、強力な認証で厳重に保護する。 - SMSサインイン
ユーザー名やパスワードを使わず、登録済み電話番号＋SMSコードだけでサインインする方法。フロントライン向けであり、一般情報系ユーザーには非推奨。
以上を踏まえれば、「TOTPが使えなくなった？」「SMSしか出てこない」「2025年9月30日までに移行って何？」という問いに対して、テナント設計レベルで筋の通った答えを出せるはずです。この記事のチェックリストとテンプレ構成を、自社テナント向けにアレンジして使ってみてください。
コメント