Microsoft Entra ID で多要素認証を設計するとき、「Microsoft Authenticator の OTP（ワンタイムコード）」と「ソフトウェア OATH トークン」の扱いは非常に紛らわしく、条件付きアクセスの認証強度と組み合わせると混乱しがちです。本記事では、両者の違い・ポリシー範囲・優先関係を整理しつつ、現実的なベストプラクティス構成を具体的に解説します。
Microsoft Entra ID における OTP / OATH / Authenticator の全体像
まずは用語とレイヤー（どの設定が何をコントロールしているか）を整理します。
OTP / TOTP / OATH の基礎
Microsoft Entra ID が扱う OTP は、基本的に OATH TOTP（Time-based One-Time Password） です。OATH TOTP はワンタイムコードの生成方法を定めた標準仕様で、ソフトウェア（認証アプリ）でもハードウェアトークンでも実装できます。Entra ID は TOTP をサポートしますが、カウンター方式の HOTP はサポートしません。
Microsoft Authenticator アプリは、
- プッシュ通知（承認／拒否）
- OATH 準拠の検証コード（6 桁 TOTP）
の両方を生成できるアプリであり、Entra ID ではソフトウェアトークンとして検証コードを生成する機能もサポートされています。
「認証方法ポリシー」と「認証強度」の役割の違い
Entra 側には、OTP が使えるかどうちを決めるレイヤーが大きく二つあります。
| レイヤー | 役割 | 何を決めるか | 主な設定場所 |
|---|---|---|---|
| 認証方法ポリシー (Authentication methods policy) | 全体設定 | どのユーザー／グループが、どの認証方法を登録・利用できるか | Entra ID > Protection > Authentication methods |
| 認証強度 (Authentication strengths) | シナリオ別 | 特定アプリ・条件付きアクセスのシナリオで、どの方法（組み合わせ）を要求するか | Entra ID > Protection > Conditional Access > Authentication strengths |
公式ドキュメントでは、「認証方法ポリシーで許可された方法がテナント全体のベースラインになり、その上で認証強度によって特定シナリオにおける使用可能な方法をさらに絞り込む」という構造になっていると説明されています。
Microsoft Authenticator の OTP とソフトウェア OATH トークンの違い
同じ「6 桁のコード」でも、Entra ID では別々の認証方法として扱われる点が最重要ポイントです。
2 種類の「TOTP コード」の正体
| 認証方法 | 登録すると何が使えるか | プッシュ通知 | 6 桁コード (TOTP) | 主な用途 |
|---|---|---|---|---|
| Microsoft Authenticator（方法） ＋「Allow use of Microsoft Authenticator OTP」= Yes | 1 回の登録で ・プッシュ通知 ・Authenticator アプリ内の TOTP コード の両方が有効化される | あり | あり（ただしプッシュとセット） | 一般的な MFA（パスワード + プッシュ／コード）やパスワードレス認証など |
| ソフトウェア OATH トークン（方法） | プッシュ通知なしで、TOTP コードのみを登録・利用できる。Microsoft Authenticator を含む任意の OATH 対応アプリで登録可能。 | なし | あり（TOTP のみ） | 「コードだけを使わせたい」環境や、サードパーティ製トークンの利用など |
Microsoft の Q&A では、Microsoft Authenticator の認証方法における OTP 有効化は「プッシュ＋OTP が一体となった方法」であり、TOTP のみを使いたい場合は「ソフトウェア OATH トークン」を使うべき、と明確に説明されています。
「Allow use of Microsoft Authenticator OTP」トグルの意味
Entra 管理ポータルの Protection > Authentication methods > Microsoft Authenticator > Configure には、「Allow use of Microsoft Authenticator OTP」（Microsoft Authenticator OTP の使用を許可）という設定があります。
- Yes（有効）: Microsoft Authenticator による MFA を登録したユーザーは、プッシュ通知と OTP 両方を使用可能
- No（無効）: Microsoft Authenticator に登録していても、OTP コードは Entra の MFA としては使えない（アプリにコードは表示されても、サインイン要素としては受け付けない）
一方、同じ「Authentication methods」ブレード内にある Software OATH tokens は、TOTP コードだけを登録・利用させるための別の認証方法として定義されています。
誰が Microsoft Authenticator の OTP コードを使えるのか
ここからが本題です。「Microsoft Authenticator = 全員有効」「ソフトウェア OATH トークン = 特定グループのみ有効」という構成を想定します。
前提となるポリシー構成の例
- Microsoft Authenticator（方法）
- 対象: 全ユーザー
- Allow use of Microsoft Authenticator OTP = Yes
- Software OATH tokens（方法）
- 対象: グループ
OATH-Usersのみ
- 対象: グループ
この場合の「誰が OTP を使えるか」は、次のように整理できます。
| ユーザー種別 | 認証方法ポリシーの状態 | 登録できる内容 | サインインで使える要素 |
|---|---|---|---|
| A さん （一般ユーザー） | Microsoft Authenticator: 有効 Software OATH: 無効 | Microsoft Authenticator を 1 回登録 → プッシュ + OTP がまとめて有効化 | ・プッシュ通知 ・Authenticator の OTP コード （いずれも「Microsoft Authenticator 方法」として扱われる） |
| B さん （OATH グループに所属） | Microsoft Authenticator: 有効 Software OATH: 有効 | ・Microsoft Authenticator を登録（プッシュ + OTP） ・Software OATH として別の TOTP を登録 | ・プッシュ通知（Microsoft Authenticator） ・Authenticator の OTP（Microsoft Authenticator 方法側） ・OATH トークンの TOTP（Software OATH 方法側） |
| C さん （特殊: Authenticator をスコープ外にした場合） | Microsoft Authenticator: 無効 Software OATH: 有効 | プッシュなしで、OATH としての TOTP のみ登録 | ・TOTP コードのみ（Software OATH 方法） |
つまり、質問の前提どおりの構成では、
- Microsoft Authenticator 方法が有効な全ユーザーは、OTP トグルが ON である限り、プッシュ + OTP の両方を利用可能
- Software OATH 方法が有効なグループユーザーは、そこに追加で「OTP だけの TOTP 要素」も持てる（プッシュなし）
重要なのは、Authenticator アプリの中にコードが表示されていても、その OTP が「どの認証方法にぶら下がっているか」でポリシーのスコープが変わることです。Microsoft Authenticator 方法で登録した OTP は Microsoft Authenticator のスコープに従い、Software OATH として登録した OTP は Software OATH 方法のスコープに従います。
認証方法ポリシー vs 認証強度：どちらが何を支配するか
登録（セットアップ）段階で効いているもの
ユーザーが新しく認証要素を登録できるかどうかは、認証方法ポリシーだけで決まります。
- Microsoft Authenticator 方法が対象ユーザーに有効で、かつ「Allow use of Microsoft Authenticator OTP = Yes」になっていれば、
- 登録ウィザードはプッシュ + OTP のセットとして登録させる
- OTP だけを切り出して登録させることはできない
- Software OATH 方法が有効なユーザーは、
- OATH トークン用の TOTP コードだけを登録できる
- この登録はプッシュ通知とは一切結び付かない
どのユーザーにどのウィザードが見えるか、というユーザー体験はすべて認証方法ポリシーで制御
サインイン時に使えるかどうかを決めるもの
一方、サインイン時に
- どの方法が 候補として提示されるか
- そのサインインが 合格（ポリシーを満たした）と判定されるか
は、次の 2 つの条件を両方満たす必要があります。
- 認証方法ポリシーでその方法がユーザーに許可されている
- 適用された条件付きアクセスの認証強度で、その方法（組み合わせ）が許容されている
認証強度は、Graph API 上では allowedCombinations として定義され、たとえば password,softwareOath は「パスワードと Software OATH トークンの両方を使う」ことを意味します。
「パスワード + Authenticator」と「パスワード + ソフトウェア OATH」の重なり
代表的なカスタム認証強度の例
よくあるパターンとして、次のような 2 つの認証強度を定義するケースがあります。
- 強度A:
password + Microsoft Authenticator Push（パスワード + Authenticator プッシュ） - 強度B:
password + Software OATH（パスワード + ソフトウェア OATH トークン）
Graph の定義上、これらはそれぞれ「パスワードと特定の 2 要素を両方使ったサインイン」を要求する組み合わせです。
別々の CA ポリシーで同時に要求するとどうなるか
同一ユーザー・同一サインインに対し、
- CA ポリシー 1: 認証強度 = 強度A（Password + Microsoft Authenticator Push）
- CA ポリシー 2: 認証強度 = 強度B（Password + Software OATH）
の両方が適用されてしまうと、ユーザーは同一のサインインの中で「2 種類の 2 要素」を同時に満たす必要があります。
ところがサインイン フローは通常、「パスワード + 1 種類の 2 要素」で完結するため、
- パスワード + プッシュ を完了 → 強度A は満たすが、強度B は満たさない
- パスワード + Software OATH を完了 → 強度B は満たすが、強度A は満たさない
という状態になり、最終的にどちらのポリシーも同時に満たせずサインインがブロックされるリスクが高くなります。Microsoft の Q&A でも、「重複すると 2 種類の方法を同時に満たす必要があり、実質的にサインインができなくなる」と説明されています。
「どちらか片方でよい（OR）」にする正しい設計
「プッシュ または OTP のどちらかでよい」構成にしたい場合、
- CA ポリシーを 2 つに分けるのではなく
- 1 つのカスタム認証強度の中に、
password,microsoftAuthenticatorPushpassword,softwareOath
必要があります。こうすると、ユーザーは
- パスワード + Authenticator プッシュ
- または パスワード + Software OATH の TOTP コード
のどちらか一方を完了すれば、その認証強度の要求を満たせるようになります。
登録フェーズとサインイン フェーズの挙動をシナリオで確認
シナリオ 1：全員プッシュ + OTP、一部ユーザーだけ OATH 追加
前述の前提を再掲します。
- Microsoft Authenticator 方法: 全ユーザー / OTP 許可 = Yes
- Software OATH 方法: グループ
OATH-Usersのみ - カスタム認証強度「MFA-Standard」:
password,microsoftAuthenticatorPushpassword,softwareOath
登録フェーズ
- A さん（一般ユーザー）
- Security info から Microsoft Authenticator を登録
- ウィザードはプッシュ登録を案内し、完了後に OTP も自動的に利用可能に
- Software OATH はスコープ外のため登録画面に出てこない
- B さん（OATH グループ）
- 上記に加え、「ソフトウェア OATH トークン」の登録画面が表示される
- Authenticator アプリ等で別の TOTP を登録可能
サインイン フェーズ
- A さん
- MFA 要求がかかると、プッシュ通知がデフォルトで提示される
- 詳細オプションから「別の方法を使用」を選べば、Authenticator の OTP を入力するパスも利用できる
- どちらの方法でも、認証強度「MFA-Standard」を満たす
- B さん
- プッシュ / Authenticator OTP / Software OATH の TOTP の3 パターンいずれかでサインイン可能
- 要求される強度は 1 つだけなので、好きな 1 パターンを完了すればよい
シナリオ 2：Push は使わせず TOTP だけにしたい
コンプライアンス要件などで、「スマホプッシュは禁止、TOTP のみ」という構成を採りたい場合は、
- Microsoft Authenticator 方法
- 対象ユーザーから除外する、またはテナント全体で無効にする
- Software OATH 方法
- 対象ユーザーに対して有効化
- 認証強度
password,softwareOathのみを含むカスタム強度を定義
とするのが、シンプルで誤解の少ないパターンです。
シナリオ 3：Push を優先し、OTP は一切使わせない
逆に、「Authenticator のプッシュだけを使わせ、OTP コードはリスクとして許容しない」という構成にしたい場合は、
- Microsoft Authenticator 方法
- 対象ユーザーに有効
- Allow use of Microsoft Authenticator OTP = No
- Software OATH 方法
- 対象ユーザーはすべてスコープ外
- 認証強度
password,microsoftAuthenticatorPushのみを含むカスタム強度
この構成では、Authenticator アプリ側に OTP が表示されていても、Entra ID はそのコードをMFA の有効な要素として受け付けません。
ベストプラクティス構成パターン
ここまでの内容を踏まえ、よくある 3 パターンをもう一度整理します。
パターン A：基本はプッシュ、一部ユーザーだけ TOTP も許可
- 目的: ユーザー体験としてはプッシュを基本にしつつ、ネットワーク制限や端末制約があるユーザー向けに TOTP も使えるようにする
| 項目 | 推奨設定 |
|---|---|
| 認証方法ポリシー Microsoft Authenticator | ・対象: 全ユーザー ・Authentication mode: Any（プッシュ／パスワードレスなど） ・Allow use of Microsoft Authenticator OTP: Yes |
| 認証方法ポリシー Software OATH | ・対象: グループ OATH-Users（VPN 用ユーザーなど必要な一部）・TOTP の登録を許可 |
| 認証強度 | ・カスタム強度「MFA-Standard」 – password,microsoftAuthenticatorPush– password,softwareOathを 1 つの強度にまとめて OR 条件にする |
この構成では、ほとんどのユーザーはプッシュを選択し、一部だけが TOTP を使うという自然な運用が可能です。
パターン B：プッシュ禁止、TOTP のみ
- 目的: スマホ通知のリスクを避け、コード入力だけのシンプルな MFA を提供したいケース
| 項目 | 推奨設定 |
|---|---|
| 認証方法ポリシー Microsoft Authenticator | ・対象ユーザーをすべて除外する（またはテナントで無効） |
| 認証方法ポリシー Software OATH | ・対象: 全ユーザー or 対象グループ ・TOTP の登録を許可 |
| 認証強度 | ・password,softwareOath のみを含むカスタム強度を作成・CA ポリシーでこの強度を要求 |
パターン C：プッシュのみを強制し、OTP は不許可
- 目的: フィッシング対策などで「ユーザーがコードを手入力する経路を排除したい」ケース
| 項目 | 推奨設定 |
|---|---|
| 認証方法ポリシー Microsoft Authenticator | ・対象: 対象ユーザー ・Allow use of Microsoft Authenticator OTP: No |
| 認証方法ポリシー Software OATH | ・対象ユーザーをすべてスコープ外にする |
| 認証強度 | ・password,microsoftAuthenticatorPush のみを含むカスタム強度 |
なお、近年はパスキーや FIDO2 などフィッシング耐性の高い方法が推奨されていますので、これらも同じ認証強度に追加し、「可能なユーザーはより強い方法を使う」という設計にするのも有効です。
よくある落とし穴と回避策
落とし穴 1：別々の CA ポリシーで異なる強度を同時に要求
前述のとおり、
- 強度A = Password + Microsoft Authenticator Push
- 強度B = Password + Software OATH
を別々の CA ポリシーで同一ユーザーに適用すると、サインインが事実上不可能になるケースがあります。
対策：
「どちらかで OK」にしたい組み合わせは、必ず 1 つの認証強度にまとめること。OR 条件にしたいものを別ポリシー・別強度に分けない、というルールを徹底します。
落とし穴 2：「Authenticator の OTP を使わせたい」つもりが Software OATH を操作している
UI 上、「ソフトウェア OATH」も「Authenticator」も似たような説明があるため、
- Authenticator 方法の設定は触らず
- Software OATH のスコープだけ変更
といった操作をしてしまい、「期待したユーザーが OTP を入力できない」「逆に使ってほしくないユーザーが OTP を使えてしまう」といったズレが起こりがちです。
対策：
- 「Microsoft Authenticator の OTP」を許可したい場合は、Microsoft Authenticator 方法の中のトグルを確認する
- 「OTP だけを Authenticator で登録させたい」場合は、Software OATH を使う必要がある（Authenticator 方法単体では OTP だけの登録は不可）
落とし穴 3：レガシー MFA / SSPR ポリシーと二重管理になっている
従来は「MFA の追加設定」や旧 SSPR ポリシー側で「Verification code from mobile app or hardware token」などを設定していましたが、これらのレガシー ポリシーは 2025 年 9 月 30 日以降、認証方法の管理には使えなくなります。
対策：
- できるだけ早く Authentication methods policy に移行し、
- Authenticator / Software OATH / FIDO2 などをすべてこちらで一元管理する
落とし穴 4：ポリシーは正しいのに、現場では「使われていない」
ポリシー設計だけでは不十分で、「本当にユーザーがその認証方法を登録して使っているか」を継続的に確認することも重要です。Microsoft は認証方法の登録・利用状況を可視化するダッシュボードを提供しており、方法ごとの採用率を確認できます。
対策：
- 定期的に認証方法ダッシュボードを確認し、
- 意図した方法が十分に登録・利用されていなければ案内や CA ポリシーでの強制を検討する
運用チェックリスト
最後に、Microsoft Authenticator の OTP とソフトウェア OATH トークンを併用する際に確認しておきたいポイントをチェックリスト形式でまとめます。
- [ ] Microsoft Authenticator 方法の設定で、
- 対象ユーザー（All users / 特定グループ）が意図どおりか
- Allow use of Microsoft Authenticator OTP が ON / OFF いずれか、ポリシーに沿っているか
- [ ] Software OATH 方法のスコープが、
- 「TOTP のみを許可したいユーザー」にだけ当たっているか
- 不要なユーザーにまでスコープが広がっていないか
- [ ] 認証強度の設計が、
- 「OR にしたい組み合わせ」は 1 つの強度にまとめているか
- 別々の CA ポリシーで異なる強度を同時要求していないか
- [ ] 代表ユーザーを使って、
- 登録ウィザードが想定どおりの方法だけを提示しているか
- サインイン時のプロンプトが、設計どおりの方法だけを候補に出しているか
- サインインログの「認証詳細」で、どの方法が使われたかを確認したか
まとめ
本記事のポイントを改めて整理します。
- Microsoft Authenticator の OTP は、Microsoft Authenticator 認証方法の配下であり、「Allow use of Microsoft Authenticator OTP」を有効にすると、プッシュ＋OTP がセットで有効化されます。
- ソフトウェア OATH トークンは、プッシュなしの TOTP コードのみを扱う別の認証方法であり、Microsoft Authenticator を含む任意の OATH 対応アプリで登録できます。
- ユーザーがどの要素を登録できるかは認証方法ポリシーで、どの要素でサインイン要件を満たせるかは認証方法ポリシーと認証強度（条件付きアクセス）の両方で決まります。
- 「パスワード + Authenticator」と「パスワード + Software OATH」を別々の認証強度として複数 CA ポリシーで同時に要求すると、2 種類の 2 要素を同時に満たす必要があり、実質的にサインイン不可になる恐れがあります。OR にしたい場合は 1 つの認証強度にまとめるのが正解です。
- レガシー MFA / SSPR ポリシーは今後非推奨となり、認証方法ポリシー＋認証強度が標準となるため、早めに移行して構成をシンプルに保つことが重要です。
これらを押さえておけば、「誰がどの OTP をどの条件で使えるのか」を明確にコントロールでき、Microsoft Entra ID の多要素認証設計をより安全かつ分かりやすいものにできます。
コメント