Microsoft Entra の「Conditional Access authentication strengths（条件付きアクセスの認証強度）」は、ユーザーに単にMFAを求めるだけでなく、どの認証方法ならアクセスを許可するかをアプリ、場所、リスク、ユーザー種別ごとに制御するための仕組みです。重要なのは、「MFAを有効にしているから安全」と考えるのではなく、管理者・機密アプリ・外部ユーザー・現場担当者などに応じて、フィッシング耐性のある認証方法やパスワードレス認証を使い分けることです。
指定されている Overview ページ自体の Microsoft Learn 上の最終更新日は 2025年10月24日と表示されています。一方、同じ認証強度に関連する「カスタム認証強度」および「QRコード認証」の公式ページは 2026年6月26日に更新されています。本記事では、Overview の内容を軸に、2026年6月26日時点で管理者が確認すべき関連更新、影響範囲、設定変更、移行・運用上の注意点を整理します。(Microsoft Learn)
Microsoft Entra の認証強度とは
Microsoft Entra の認証強度は、条件付きアクセスの許可制御の一つです。通常の「多要素認証を要求する」制御より一段細かく、ユーザーがリソースへアクセスするときに利用できる認証方法の組み合わせを指定できます。
たとえば、一般的な社内ポータルには「パスワード＋Microsoft Authenticator のプッシュ通知」を許可し、管理ポータルや財務データには「FIDO2 セキュリティキー」「Windows Hello for Business」「証明書ベース認証」などのフィッシング耐性がある方法だけを許可する、といった使い分けができます。
Microsoft Learn では、認証強度は Microsoft Entra Conditional Access の制御であり、リソースへアクセスする際にユーザーが使える認証方法の組み合わせを指定するものと説明されています。また、認証方法ポリシーを土台にしながら、機密リソース、ユーザーリスク、場所などのシナリオごとに追加の制御を行える点が特徴です。(Microsoft Learn)
2026年6月26日時点で確認すべき更新ポイント
今回確認すべきポイントは、「認証強度」という概念そのものが新しくなったというより、認証方法ポリシー、カスタム認証強度、パスキー、QRコード認証、外部ユーザー制御を組み合わせて設計する必要性が高まっている点です。
| 確認項目 | 実務上の意味 | 管理者が取るべき対応 |
|---|---|---|
| 組み込み認証強度 | MFA、パスワードレス MFA、フィッシング耐性 MFA の3種類を選べる | アプリの重要度ごとに、どの認証強度を使うか分類する |
| カスタム認証強度 | 組み込みだけでは足りない場合、最大15個まで独自の認証強度を作成できる | 管理者、開発者、現場担当者、外部ユーザーなどの用途別に設計する |
| パスキー・FIDO2 の詳細制御 | AAGUID を使い、特定のセキュリティキーやパスキー提供元に限定できる | 認定済みデバイス・支給済みキーだけを許可したい場合に使う |
| 証明書ベース認証の詳細制御 | 証明書の発行者やポリシー OID によってアクセス先を制御できる | スマートカードや証明書を部門・機密区分ごとに使い分ける |
| QRコード認証 | 主にフロントラインワーカー向け。カスタム認証強度で特定リソースに要求できる | 全社展開ではなく、対象グループ・対象アプリ・ネットワーク条件を絞る |
| 旧来の MFA/SSPR ポリシー | 2025年9月30日以降、旧来ポリシーでの認証方法管理は非推奨・制限対象 | Authentication methods policy への移行状態を確認する |
カスタム認証強度は、Microsoft Entra 管理センターの Entra ID > Authentication methods > Authentication strengths から作成できます。公式ドキュメントでは、管理者は最大15個のカスタム認証強度を作成でき、FIDO2 の AAGUID や証明書の発行者・ポリシー OID による制限も可能とされています。(Microsoft Learn)
組み込み認証強度の違い
Microsoft Entra には、あらかじめ定義された組み込み認証強度があります。これらは Microsoft が管理するため、管理者側で中身を編集することはできません。新しい認証方法が利用可能になると、Microsoft 側で組み込み認証強度が更新される場合があります。(Microsoft Learn)
| 認証強度 | 代表的な認証方法 | 向いている用途 | 注意点 |
|---|---|---|---|
| Multifactor authentication strength | パスワード＋SMS、音声、プッシュ通知、OATH トークンなど | 一般的なMFA要求、低〜中リスクの業務アプリ | SMSや音声を含むため、高リスク用途では過信しない |
| Passwordless MFA strength | FIDO2、Windows Hello for Business、証明書ベース認証、Microsoft Authenticator の電話サインインなど | パスワード入力を減らしたい業務環境 | 利用者の登録状況と端末対応が前提 |
| Phishing-resistant MFA strength | FIDO2、Windows Hello for Business または platform credential、証明書ベース認証など | 管理者、特権操作、機密データ、ゼロトラスト強化 | 事前登録、端末準備、例外運用の設計が必要 |
実務では、すべてのユーザーにいきなりフィッシング耐性 MFA を強制するよりも、まず管理者、経理・人事、開発者、外部公開データに触れる担当者などから段階的に適用する方が失敗しにくくなります。
影響範囲：どのユーザーとアプリに関係するか
認証強度の影響は、条件付きアクセス ポリシーで対象にしたユーザー、グループ、アプリ、操作、場所、デバイス条件に及びます。特に影響が大きいのは、次のような環境です。
管理者と特権ロール
Global Administrator、Privileged Role Administrator、Security Administrator などの特権ロールを持つユーザーには、フィッシング耐性 MFA を優先して適用する価値があります。パスワード＋SMS のような方式では、認証情報の窃取や中間者攻撃に対する耐性が十分とは言えないためです。
ただし、特権管理者に強い認証を要求する場合は、緊急用アカウント、代替認証方法、登録手順、端末紛失時の復旧手順を必ず用意しておく必要があります。認証強度だけを先に強制すると、管理者自身が管理ポータルへ入れなくなるリスクがあります。
機密性の高いアプリ
SharePoint の機密サイト、財務システム、人事データ、DLP 対象データ、管理ポータル、開発基盤などは、通常の MFA ではなく、パスワードレス MFA やフィッシング耐性 MFA の候補になります。
条件付きアクセスの認証コンテキストと組み合わせると、アプリ全体ではなく、アプリ内の重要な操作や機密データへのアクセス時だけ強い認証を要求できます。Overview でも、機密リソースへのアクセス、アプリ内の機密操作、企業ネットワーク外からのアクセス、高リスクユーザー、外部ユーザーといったシナリオが挙げられています。(Microsoft Learn)
外部ユーザー・ゲストユーザー
B2B コラボレーションなどで外部ユーザーに機密リソースを共有している場合、認証強度は特に重要です。外部ユーザーのホームテナントで満たした MFA を信頼するか、リソーステナント側で再度 MFA を要求するかによって、ユーザー体験とセキュリティが変わります。
Microsoft Learn では、外部ユーザーに対する認証強度ポリシーは、クロステナントアクセス設定の MFA trust settings と連動して評価されると説明されています。MFA 信頼が有効な場合はホームテナントの認証セッションを確認し、要件を満たさない場合は追加の MFA チャレンジが発生します。(Microsoft Learn)
フロントラインワーカーと共有端末
2026年6月26日に更新された QRコード認証のドキュメントでは、QRコード認証は主にフロントラインワーカー向けのシンプルな認証方法として説明されています。QRコードと数値 PIN を組み合わせ、バッジなどに QRコードを添付して利用する想定です。(Microsoft Learn)
ただし、QRコード認証は情報ワーカー向けの標準認証として広く使うものではありません。公式ドキュメントでも、フロントラインワーカー向けであり、情報ワーカーにはフィッシング耐性認証または MFA が推奨されています。また、テナント全体ではなく対象ユーザーに限定し、準拠デバイス、ネットワーク、対象アプリ、共有デバイスモードなどの条件付きアクセスと組み合わせることが推奨されています。(Microsoft Learn)
管理者が確認すべき設定変更
認証強度を安全に導入するには、条件付きアクセスの画面だけを見ても不十分です。認証強度は、認証方法ポリシー、ユーザーの登録状態、条件付きアクセス ポリシー、対象アプリ、端末条件がそろって初めて正しく機能します。
認証方法ポリシーを確認する
最初に確認する場所は、Entra ID > Authentication methods > Policies です。ここで、FIDO2、Microsoft Authenticator、Temporary Access Pass、証明書ベース認証、SMS、音声通話などの認証方法が、対象ユーザーやグループに対して有効になっているかを確認します。
認証強度で FIDO2 を要求しても、対象ユーザーに FIDO2 の登録や利用が許可されていなければサインインは成功しません。Microsoft Learn でも、認証強度を満たすには、方法が許可され、ユーザーに登録され、条件付きアクセス ポリシーの要件を満たす必要があると説明されています。(Microsoft Learn)
旧来の MFA/SSPR ポリシーの移行状態を確認する
Microsoft は、旧来の MFA および SSPR ポリシーで認証方法を管理する方式の廃止を案内しており、2025年9月30日以降、これらの旧来ポリシーで認証方法を管理できないと説明しています。認証強度を本格的に使う前に、Authentication methods policy へ移行済みか、設定の不一致が残っていないかを確認してください。(Microsoft Learn)
特に注意したいのは、旧来ポリシーではテナント全体で許可されていた方法が、Authentication methods policy では特定グループにしか許可されていないケースです。この状態で認証強度を適用すると、一部ユーザーだけが想定外にサインインできなくなることがあります。
カスタム認証強度を作成する
組み込み認証強度で足りない場合は、カスタム認証強度を作成します。たとえば、次のような設計が考えられます。
| カスタム認証強度の例 | 許可する認証方法 | 想定用途 |
|---|---|---|
AS-Admin-PhishingResistant | FIDO2、Windows Hello for Business、証明書ベース認証 | 管理者・特権ロール |
AS-Finance-CBA-High | 特定の証明書発行者またはポリシー OID の証明書 | 財務・監査・機密部門 |
AS-Developer-FIDO2-ManagedKeys | AAGUID で限定した FIDO2 セキュリティキー | DevOps、GitHub、Azure 管理 |
AS-FLW-QR-StoreOnly | QRコード認証 | 店舗・工場・共有端末の現場担当者 |
AS-Passwordless-Standard | Authenticator phone sign-in、FIDO2、Windows Hello for Business | 一般ユーザーのパスワードレス化 |
カスタム認証強度を作る際は、名前に対象ユーザー、用途、強度を含めると運用しやすくなります。たとえば AS-Admin-PhishingResistant のようにしておくと、条件付きアクセス ポリシーのレビュー時に意図を判断しやすくなります。
条件付きアクセスで認証強度を要求する
認証強度を実際に使うには、条件付きアクセス ポリシーの Grant controls で Require authentication strength を選び、組み込みまたはカスタムの認証強度を指定します。
基本的な設定の流れは次の通りです。
| 手順 | 確認内容 |
|---|---|
| 対象ユーザーを決める | 管理者、部門、外部ユーザー、現場担当者など |
| 対象リソースを決める | すべてのリソースではなく、まず機密アプリや重要操作から始める |
| 条件を決める | 場所、デバイス準拠状態、ユーザーリスク、サインインリスクなど |
| Grant controls を設定する | Require authentication strength を選択する |
| レポート専用で検証する | いきなり有効化せず、サインインログで影響を確認する |
| 段階展開する | パイロットグループ、本番グループ、全体展開の順に進める |
同じ条件付きアクセス ポリシー内で Require multifactor authentication と Require authentication strength を同時に使うことはできません。Microsoft Learn では、組み込みの Multifactor authentication strength が Require multifactor authentication と同等であるため、同じポリシー内で併用できないと説明されています。(Microsoft Learn)
パスキーを使う場合の注意点
パスキーを Microsoft Entra で強制したい場合は、まず Authentication methods policy でパスキーを登録・サインインに使えるようにし、その後で条件付きアクセスの認証強度を使って機密リソースへのアクセス時に要求します。Microsoft Learn でも、Authenticator のパスキーを有効化した後、条件付きアクセスの認証強度ポリシーで機密リソースへのパスキーサインインを強制できると説明されています。(Microsoft Learn)
実務上の落とし穴は、パスキー登録前のユーザーに対して、すべてのリソースでパスキーを必須にしてしまうことです。Microsoft Learn では、Authenticator にパスキーを追加しようとする際に、すべてのクラウドアプリに対してパスキーを要求する条件付きアクセス ポリシーがあるとループが発生する可能性があると説明されています。対策として、対象アプリを絞る、モバイル OS とデスクトップ OS でポリシーを分ける、Temporary Access Pass を使うといった方法が示されています。(Microsoft Learn)
パスキー展開では、次の順番を守ると失敗しにくくなります。
| フェーズ | やること |
|---|---|
| 準備 | 対象ユーザー、対応端末、ブラウザ、OS、Authenticator 利用可否を確認する |
| 登録 | パスキー登録キャンペーンや Temporary Access Pass を使い、先に登録を完了させる |
| 検証 | レポート専用の条件付きアクセスで、誰が失敗するかを確認する |
| 強制 | 管理者や機密アプリから段階的に認証強度を有効化する |
| 運用 | 端末交換、紛失、UPN変更、退職時の削除手順を整備する |
QRコード認証を使う場合の注意点
QRコード認証は、フロントラインワーカーや共有端末のシナリオでは有効です。たとえば、店舗スタッフが共有端末で業務アプリにサインインする、工場や現場で個人スマートフォンを使わずに業務アプリへ入る、といった用途です。
ただし、QRコード認証はデフォルトで無効です。利用するには Authentication methods policy で対象ユーザーに対して有効化し、必要に応じてカスタム認証強度で QRコードを含め、条件付きアクセスで対象リソースに適用します。公式ドキュメントでは、QRコード認証はデフォルトで無効であり、PIN 長は8〜20桁、標準 QRコードの有効期間は1〜395日、既定値は365日とされています。(Microsoft Learn)
QRコード認証を導入する場合は、次の点を必ず確認してください。
| 注意点 | 理由 | 対応策 |
|---|---|---|
| テナント全体に有効化しない | 情報ワーカー向けの標準認証ではない | フロントラインワーカー用グループに限定する |
| ネットワーク条件なしで使わない | QRコードと PIN の漏えい時にリスクが高まる | 店舗・拠点ネットワーク、準拠デバイス、対象アプリで制限する |
| 紛失時の再発行手順を決める | バッジ紛失時に不正利用される可能性がある | QRコード削除、再発行、PIN変更の手順を用意する |
| デスクトップアプリ用途に使わない | 現行リリースでは非対応シナリオがある | Webサインインや対応アプリに用途を限定する |
| 初回サインインを考慮する | QRコード有効化後、初回は既存方法でのサインインが必要 | 初回登録日を設け、ヘルプデスク対応を準備する |
Microsoft Learn では、QRコード認証はデスクトップアプリやデスクトップブラウザーでは動作しないこと、ユーザーの自己サービス PIN リセットや一括プロビジョニングなどが現行リリースで未対応であることも示されています。(Microsoft Learn)
外部 MFA やサードパーティ認証を使っている場合
外部 MFA プロバイダーを利用している組織では、認証強度との関係に注意が必要です。Microsoft Learn では、外部 MFA メソッドは Microsoft Entra MFA 要件を満たすことができますが、組み込み MFA strength を含む認証強度ベースの Grant controls は外部 MFA メソッドでは満たされないため、ポリシーは Require multifactor authentication を使うべきと説明されています。(Microsoft Learn)
つまり、サードパーティ MFA を使っている環境で、単純に Require authentication strength へ置き換えると、想定していた認証が満たされずアクセス失敗につながる可能性があります。外部 MFA から Microsoft Entra のネイティブな認証方法へ移行する場合は、並行ポリシーを作り、対象ユーザーを分けて検証するのが安全です。
よくある失敗パターン
認証強度だけ作って、認証方法ポリシーを有効化していない
カスタム認証強度で FIDO2 や証明書ベース認証を許可しても、対象ユーザーがその認証方法を使えるように設定されていなければ意味がありません。認証強度は「使ってよい方法の絞り込み」であり、「認証方法の有効化」そのものではありません。
すべてのアプリに一気に適用する
All resources や広すぎる対象に対して強い認証強度を適用すると、ユーザー登録、Authenticator、セキュリティ情報登録、ヘルプデスク用アプリまで影響を受けます。最初は管理ポータル、機密アプリ、特定グループなどに絞り、レポート専用モードで影響を確認してください。
Windows Hello for Business の動作を誤解する
Overview では、ユーザーが Windows Hello for Business をプライマリ認証方法として使った場合は認証強度を満たせますが、パスワードなど別の方法で最初にサインインした後に Windows Hello for Business を要求しても、その場で促されない場合があると説明されています。その場合、ユーザーはセッションをやり直し、サインイン オプションから必要な方法を選ぶ必要があります。(Microsoft Learn)
Email one-time pass を認証強度に含められると思い込む
Overview では、Email one-time pass（Guest）は利用可能な組み合わせでは現在サポートされていないとされています。外部ユーザー向けにメール OTP を使っている場合、認証強度で同じ制御ができるとは限らないため、B2B アクセスの設計を別途確認してください。(Microsoft Learn)
サインイン頻度との関係を見落とす
認証強度とサインイン頻度を同時に使う場合、ユーザーが認証強度を満たしたタイミングと、サインイン頻度を満たしたタイミングが異なることがあります。Microsoft Learn では、過去にパスキーでサインインしたセッションが認証強度を満たし、当日の Windows Hello for Business によるデバイス解除がサインイン頻度を満たす例が示されています。(Microsoft Learn)
移行期限と今後の確認ポイント
認証強度の Overview および関連ドキュメントを確認する限り、2026年6月26日の関連更新によって、認証強度そのものに新しい一律の移行期限が追加されたわけではありません。管理者が確認すべき期限として重要なのは、旧来の MFA/SSPR ポリシーから Authentication methods policy への移行です。
Microsoft Learn では、2025年9月30日以降、旧来の MFA および SSPR ポリシーでは認証方法を管理できないと説明されています。2026年時点でまだ設定状態を見直していない場合は、認証強度の導入以前に、Authentication methods policy が現在のサインイン要件と一致しているかを確認する必要があります。(Microsoft Learn)
確認すべき順番は次の通りです。
| 優先度 | 確認項目 | 確認理由 |
|---|---|---|
| 高 | Authentication methods policy の有効化状況 | 認証強度で要求する方法が使えないとサインインに失敗する |
| 高 | 管理者・緊急用アカウントの認証方法 | 強制適用後のロックアウトを避ける |
| 高 | 条件付きアクセス ポリシーの対象範囲 | All resources の過剰適用を防ぐ |
| 中 | 外部ユーザーと MFA trust settings | B2B ユーザーの追加認証や失敗を予測する |
| 中 | パスキー・FIDO2 の登録状況 | フィッシング耐性 MFA の展開可否を判断する |
| 中 | QRコード認証の対象グループ | 現場担当者以外への過剰展開を防ぐ |
| 低 | サインイン頻度やセッション制御との組み合わせ | ユーザー体験とセキュリティのバランスを調整する |
実務でのおすすめ設計
Microsoft Entra の認証強度は、単に「強い認証をオンにする」機能ではありません。実務では、リソースの重要度とユーザーの働き方に合わせて段階的に設計することが重要です。
まず、管理者と高リスク業務にはフィッシング耐性 MFA を検討します。次に、一般ユーザーにはパスワードレス MFA を広げ、SMS や音声通話は例外用途に縮小します。フロントラインワーカーには QRコード認証を検討できますが、ネットワーク、デバイス、対象アプリを絞って使うべきです。外部ユーザーには、MFA trust settings と認証強度の関係を確認し、ホームテナント側の認証をどこまで信頼するかを明確にします。
次に取るべき行動は、既存の MFA 設定を棚卸しし、Authentication methods policy と条件付きアクセス ポリシーの対応関係を表にすることです。そのうえで、管理者向け、機密アプリ向け、現場担当者向けの3種類程度から認証強度を設計し、レポート専用モードで影響を確認してから段階的に有効化してください。
コメント