2026年7月6日、Microsoftは、Microsoft Entra IDでMicrosoft Authenticatorのパスキーを展開するための公式ドキュメントを更新しました。結論から言えば、今回の更新は緊急パッチやテナント設定の自動変更ではありません。ただし、すでにパスキーを試験導入している組織や、条件付きアクセスでフィッシング耐性のある認証を必須化している組織は、設定を見直す必要があります。
特に確認したいのは、パスキープロファイルの対象グループ、Microsoft AuthenticatorのAAGUID、アテステーションの扱い、条件付きアクセスによる登録ループ、監査ログの確認方法です。単に「パスキーを有効にした」だけでは、重要なクラウドサービスがパスキーで保護されるとは限りません。
この記事では、Microsoft Authenticatorのパスキー展開・サポート指針更新の内容を整理し、影響を受ける環境、管理者が確認すべき設定、監査・検知への影響、優先的に実施したい対応を具体的に解説します。
Microsoft Authenticatorのパスキー展開・サポート指針更新とは
2026年7月6日の更新では、Microsoft Authenticatorのパスキーを有効化する手順と、登録時に発生しやすい問題への対処方法が一つのガイドに整理されました。
MicrosoftのGitHub上の更新履歴では、従来の「パスキーのサポート」に関する記事を廃止し、その内容を有効化ガイドへ統合したことが示されています。つまり、新しい認証方式が突然追加されたというより、現在のパスキープロファイルを前提とした展開方法とサポート情報が再構成された更新です。該当ページや変更履歴には、既存テナントの設定が自動的に変更されるとの案内はありません。(Microsoft Learn)
| 観点 | 更新後の整理 |
|---|---|
| ドキュメント構成 | 有効化、登録、サインイン、トラブル対応を関連付けて整理 |
| 管理単位 | パスキープロファイルを作成し、ユーザーやグループ単位で対象化 |
| Authenticatorの指定 | デバイスバウンド型とAAGUIDを組み合わせて制御 |
| 信頼性の確認 | Apple App AttestやGoogle Play Integrityなどによるアテステーションを選択可能 |
| サポート上の重点 | 条件付きアクセス、モバイルアプリ保護、Bluetooth、Androidプロファイルなどの注意点を明確化 |
今回の更新は「対応不要な単なる文章修正」とも言い切れません。従来のテナント全体を中心としたFIDO2設定から、対象者やパスキーの種類を分けるプロファイル型の運用へ移行する際に、設計ミスが起きやすいためです。
対応が必要かを環境別に判断する
Microsoft Authenticatorのパスキーを利用していない組織では、今回の更新だけを理由に緊急作業を行う必要はありません。一方、すでにFIDO2やパスキーを有効化している場合は、対象グループと条件付きアクセスの確認を優先します。
| 現在の環境 | 対応の優先度 | 確認すべきこと |
|---|---|---|
| パスキーを有効化していない | 低 | 導入予定、ライセンス、対象ユーザーを整理 |
| 一部ユーザーで試験導入している | 高 | パスキープロファイル、AAGUID、登録方法を確認 |
| 全ユーザーにFIDO2を許可している | 高 | 広範なプロファイルが管理者向けの厳格な設定を弱めていないか確認 |
| 条件付きアクセスでフィッシング耐性を必須化している | 最優先 | Authenticator自身が登録を妨げるループがないか確認 |
| 全クラウドリソースにアプリ保護ポリシーを要求している | 最優先 | Authenticatorからのパスキー登録が遮断されないか確認 |
| 特権管理者にパスキーを要求している | 最優先 | デバイスバウンド、アテステーション、失効手順、代替登録手段を確認 |
| BYODやAndroid Work Profileを利用している | 高 | プロファイルごとの登録、端末交換時の再登録を確認 |
特に、Microsoft Authenticatorのパスキーを有効化済みであっても、条件付きアクセスで対象リソースを指定していなければ、パスワードや別の多要素認証が引き続き利用される可能性があります。
パスキーを有効にしただけではクラウドサービスは保護されない
Microsoft Entra IDにおけるパスキーの設定は、次の3層に分けて考える必要があります。
| 設定層 | 制御する内容 | 制御しない内容 |
|---|---|---|
| 認証方法ポリシー | パスキーを利用できるユーザー | どのアプリで必須にするか |
| パスキープロファイル | 許可するパスキーの種類、AAGUID、アテステーション | 対象リソースへのアクセス条件 |
| 条件付きアクセス | どのユーザーが、どのリソースで、どの認証強度を満たすか | パスキーの登録そのもの |
認証方法ポリシーは「パスキーを登録・使用できる人」を決めます。条件付きアクセスは「特定のリソースへアクセスするときに、パスキーなどの強い認証を要求するか」を決めます。
そのため、Microsoft 365、Azure管理ポータル、業務アプリなどを実際に保護するには、条件付きアクセスの対象リソース、ユーザー、デバイス条件、認証強度を別途設計する必要があります。条件付きアクセスで認証強度を利用するには、Microsoft Entra ID P1以上が必要です。(Microsoft Learn)
「フィッシング耐性のあるMFA」と「Authenticator限定」は異なる
Microsoft Entra IDには、組み込みの「フィッシング耐性のあるMFA」という認証強度があります。ただし、この認証強度にはMicrosoft Authenticatorのパスキーだけでなく、FIDO2セキュリティキー、Windows Hello for Business、証明書ベース認証なども含まれます。
Microsoft Authenticatorのパスキーだけを許可したい場合は、対象となるAAGUIDを指定したカスタム認証強度を作成する必要があります。逆に、複数のフィッシング耐性認証を許容できる組織では、組み込み認証強度の方が管理しやすい場合があります。(Microsoft Learn)
管理者が確認すべきパスキープロファイルの設定
現在のFIDO2設定を記録してからプロファイルを変更する
パスキープロファイルを有効化すると、既存のグローバルなFIDO2設定は「Default」プロファイルへ引き継がれます。公式ドキュメントでは、プロファイル方式を有効化した後は元の方式へ戻せないこと、作成できるプロファイル数に上限があることも案内されています。
変更前に、少なくとも次の情報を画面キャプチャやMicrosoft Graphなどで記録しておきます。
- 現在パスキーを許可しているユーザーとグループ
- アテステーションの有効・無効
- 許可または拒否しているAAGUID
- セルフサービス登録の設定
- 関連する条件付きアクセスポリシー
- 既存のFIDO2セキュリティキー利用者
プロファイルを有効化しただけで既存の設定が消えるわけではありませんが、Defaultプロファイルへの移行後に対象グループを変更すると、既存ユーザーの登録やサインインに影響する可能性があります。(Microsoft Learn)
Microsoft Authenticator用プロファイルの基本設定
Microsoft Entra管理センターでは、原則として「Entra ID」から「Authentication methods」を開き、「Passkey（FIDO2）」の設定を行います。
Microsoft Authenticator専用のパスキープロファイルを作る場合、基本的な設定は次のとおりです。
| 項目 | 推奨する初期設定 | 判断ポイント |
|---|---|---|
| プロファイル名 | Authenticator Passkeysなど | 対象と目的が分かる名前にする |
| Passkey types | Device-bound | Authenticatorのパスキーは端末に紐づく |
| Key restriction | Allow | 指定したAuthenticatorのAAGUIDを許可 |
| Attestation | リスクに応じて選択 | 特権ユーザーでは有効化を優先 |
| 対象 | 専用のパイロットグループ | 最初から全ユーザーに展開しない |
| 除外 | 慎重に設定 | 除外は他の許可プロファイルより優先される |
Microsoft AuthenticatorのAAGUIDは、2026年7月6日時点で次の値が案内されています。
| プラットフォーム | AAGUID |
|---|---|
| Android | de1e552d-db1d-4423-a619-566b625cdc84 |
| iOS | 90a3ccdf-635c-4729-a248-9b709135078f |
許可リストからAAGUIDを削除すると、そのAAGUIDで登録済みのパスキーもサインインに利用できなくなります。Microsoft Graphでポリシーを更新する場合も、既存のAAGUIDを更新データへ含め忘れないようにします。(Microsoft Learn)
複数のプロファイルでは「厳しい設定が優先」とは限らない
パスキープロファイル設計で最も見落としやすいのが、複数プロファイルに所属するユーザーの評価方法です。
ユーザーが複数のプロファイルの対象になっている場合、Microsoft Entra IDは、いずれか一つのプロファイルを完全に満たすパスキーを許可します。プロファイルに優先順位はなく、最も厳しい設定が自動的に適用されるわけではありません。
例えば、管理者が次の2グループに所属しているとします。
- 全社員向け：同期型とデバイスバウンド型を許可
- 特権管理者向け：アテステーション済みのデバイスバウンド型だけを許可
この場合、全社員向けプロファイルを満たすパスキーが利用できる可能性があります。特権管理者向けプロファイルを追加しただけでは、必ずしも制限が強化されません。
一方、除外グループは許可より優先されます。除外対象にすると、他のプロファイルで許可されていても、FIDO2パスキーの登録や利用がブロックされます。対象グループは「追加する」だけでなく、重複所属まで確認する必要があります。(Microsoft Learn)
アテステーションを有効にするか判断する
アテステーションを有効にすると、Microsoft Entra IDは、パスキーが正規のMicrosoft Authenticatorによって作成されたことを検証します。
iOSではApple App Attest、AndroidではGoogle Play IntegrityやAndroid Key Attestationが利用されます。これにより、特権ユーザーや高機密情報へアクセスするユーザーについて、登録元の信頼性を高められます。(Microsoft Learn)
| 利用シーン | アテステーション | 理由 |
|---|---|---|
| グローバル管理者などの特権ユーザー | 有効を優先 | 登録元と端末内鍵の信頼性を重視 |
| 規制対象データを扱うユーザー | 有効を検討 | 監査時に厳格な登録条件を説明しやすい |
| 一般社員向けの初期パイロット | 要件に応じて選択 | 登録成功率とセキュリティのバランスを確認 |
| 多様なBYOD端末を利用 | 事前検証が必要 | 端末やOS、Google・Appleサービスへの接続に依存 |
| クロスデバイスで登録したい | 無効化を含めて検討 | アテステーション有効時はクロスデバイス登録を利用できない |
アテステーション有効化時の注意点
アテステーションを有効にすると、パスキーはMicrosoft Authenticatorアプリ内から直接登録する必要があります。PCに表示したQRコードをスマートフォンで読み取るクロスデバイス登録は利用できません。
また、AppleやGoogleのアテステーション関連サービスに障害や高負荷が発生した場合、登録が一時的に失敗する可能性があります。サインインだけでなく、新規登録が止まった場合のヘルプデスク手順も用意しておく必要があります。(Microsoft Learn)
後から有効化しても既存パスキーは自動的に厳格化されない
アテステーションは登録時に評価されます。アテステーションを無効にして登録したパスキーが存在する状態で、後から設定を有効にしても、既存の未アテステーションパスキーが自動的に利用不可になるわけではありません。
厳格な運用へ切り替える場合は、既存パスキーの登録状況を確認し、必要に応じて削除と再登録を実施します。
また、アテステーションを無効にした状態では、AAGUIDによる制限を「正規製品であることの強い証明」として扱うべきではありません。Microsoftも、アテステーションがない場合のAAGUID制限は、厳密なセキュリティ保証というよりポリシー上の指針として扱うよう説明しています。(Microsoft Learn)
条件付きアクセスで発生しやすい登録ループ
Authenticator自身にパスキーを要求すると登録できない
条件付きアクセスで次のようなポリシーを設定すると、登録ループが発生することがあります。
- すべてのクラウドリソースを対象にする
- Microsoft Authenticatorのパスキーを必須にする
- パスキーをまだ持っていないユーザーがAuthenticatorを開く
- Authenticatorへのアクセス時点でパスキーを要求される
- パスキーを登録するためにパスキーが必要になる
この状態では、新規ユーザーが最初のパスキーを登録できません。
対策として、次のいずれかを組み合わせます。
- 導入期間中は対象アプリを絞る
- アプリケーションフィルターで登録に必要なリソースを調整する
- デスクトップとモバイルで条件付きアクセスポリシーを分ける
- モバイル側ではTemporary Access Passまたは既存パスキーを許可する
- 本番強制前に登録キャンペーンを実施する
- 「セキュリティ情報の登録」を対象とする条件付きアクセスも同時に確認する
パスキー登録時には、ユーザーが直近に多要素認証を完了していることが求められる場合があります。初回登録や端末紛失時には、Temporary Access Passを利用したブートストラップ手順を用意すると運用しやすくなります。(Microsoft Learn)
アプリ保護ポリシーを全リソースに要求している場合
条件付きアクセスで、すべてのクラウドリソースに次の許可制御を要求している環境では注意が必要です。
- 承認済みクライアントアプリを必須にする
- アプリ保護ポリシーを必須にする
Microsoft Authenticatorは、AndroidとiOSにおけるこれらの許可制御をサポートしていないため、パスキー登録がブロックされる可能性があります。
Microsoftは、対象アプリをフィルターで限定する、MDMで管理された準拠デバイスを利用する、補完的な対策を設けたうえで一時的な除外を行う、といった方法を案内しています。全リソースを一律に対象化する前に、Authenticatorからの登録テストを行うことが重要です。(Microsoft Learn)
端末・ネットワーク側で確認すべき条件
2026年7月6日時点の公式ガイドでは、Microsoft Authenticatorのパスキーに、Android 14以降またはiOS 17以降が必要とされています。
クロスデバイス登録やクロスデバイス認証では、PCとスマートフォンの両方でBluetoothとインターネット接続が必要です。Bluetoothは端末間が近くにあることを確認するために使用されます。(Microsoft Learn)
ファイアウォールやプロキシで許可する接続先
| プラットフォーム | 接続先 |
|---|---|
| Android | cable.ua5v.com |
| iOS | cable.auth.com |
| iOS | app-site-association.cdn-apple.com |
| iOS | app-site-association.networking.apple |
これらの通信先がプロキシ、DNSフィルタリング、SSLインスペクション、ファイアウォールなどで遮断されていると、QRコードを使った登録や認証が途中で失敗する可能性があります。社外ネットワークでは成功し、社内ネットワークだけ失敗する場合は、通信制御を優先して確認します。(Microsoft Learn)
AndroidのWork Profileと個人用プロファイルは別管理
Androidでは、Work Profileと個人用プロファイルの認証情報が分離されています。両方のプロファイルでMicrosoft Authenticatorを利用する場合は、それぞれのプロファイルでパスキーを作成する必要があります。
「同じスマートフォンだから一つのパスキーでよい」と考えると、個人用プロファイルではサインインできるが、Work Profileではパスキーが表示されない、といった問い合わせにつながります。BYODを許可している組織では、利用者向け手順書にプロファイルの違いを明記します。(Microsoft Learn)
端末交換・紛失時の再登録手順を準備する
Microsoft Authenticatorのパスキーはデバイスバウンド型であり、別端末へ同期したり、バックアップから復元したりできません。端末交換、故障、紛失時には、古いパスキーを失効させ、新しい端末で登録し直す必要があります。
パスキーには自動的な有効期限がないため、退職、異動、端末廃棄、管理者権限の変更時に、登録済みパスキーを確認する運用が必要です。(Microsoft Learn)
監査・検知への影響
今回の更新の主眼は、展開手順とサポート上の注意点です。新しいログ形式や専用イベントIDの追加が案内されたわけではありません。
ただし、パスキープロファイルを使い分けるようになると、従来の「FIDO2が登録されているか」だけでは監査が不十分になります。AAGUID、デバイスバウンドか同期型か、アテステーションの状態、登録日時まで確認する必要があります。
| 情報源 | 確認できること | 注意点 |
|---|---|---|
| Authentication Methods Activity | 登録者数、利用状況、成功・失敗の傾向 | 最大36時間程度の遅延があり、リアルタイム検知には不向き |
| サインインログ | 実際に使われた認証方法、成功・失敗、条件付きアクセス結果 | 認証詳細とポリシー評価を合わせて確認する |
| 監査ログ | セキュリティ情報の登録、削除、登録失敗 | 表示名がパスキー専用ではなく、認証方法全般のイベントになる場合がある |
| Microsoft Graph | AAGUID、登録日時、モデル、パスキー種別、アテステーション状態 | API権限と定期的な棚卸し処理が必要 |
Authentication Methods Activityの利用状況や分析機能には、Microsoft Entra ID P1またはP2が必要です。また、表示データには最大36時間程度の遅延があるため、SOCやインシデント対応ではサインインログ、監査ログ、Microsoft Graphによるインベントリを併用します。(Microsoft Learn)
Microsoft Graphのfido2AuthenticationMethodでは、主に次の情報を取得できます。
aaGuidattestationLevelcreatedDateTimedisplayNamemodelpasskeyType
Microsoft Authenticator専用のプロファイルを運用する場合は、想定したAAGUIDであること、passkeyTypeがdeviceBoundであること、必要なユーザーでアテステーションが確認できることを棚卸し項目にします。(Microsoft Learn)
優先して検知したい事象
監査やアラートでは、少なくとも次の事象を確認します。
- パスキー登録失敗の急増
アテステーション、条件付きアクセス、ネットワーク制御を変更した直後に増えていないか確認します。 - 特権ユーザーの登録不足
対象グループに所属しているのに、デバイスバウンド型パスキーが登録されていないユーザーを検出します。 - 想定外のAAGUIDやパスキー種別
Microsoft Authenticator限定のはずなのに、別のAAGUIDや同期型パスキーが登録されていないか確認します。 - AAGUID変更後のサインイン失敗
許可リストからAAGUIDを削除した後、既存利用者の認証失敗が増えていないか確認します。 - 退職者や端末交換者の古いパスキー
自動失効しないパスキーが残っていないか、定期的に棚卸しします。
Microsoftは、パスキーの作成と利用状況を、監査ログ、サインインログ、ユーザー通知などで追跡することを案内しています。(Microsoft Learn)
優先すべき管理者対応
今回の更新を受けて、Microsoft Entra ID管理者が優先したい対応は次のとおりです。
| 優先度 | 対応 | 完了の判断基準 |
|---|---|---|
| 最優先 | 現在のFIDO2・パスキーポリシーを記録 | 対象グループ、AAGUID、アテステーション、除外を一覧化できている |
| 最優先 | プロファイルの重複所属を確認 | 厳格な管理者用設定が一般社員用プロファイルで緩和されない |
| 最優先 | 条件付きアクセスの登録ループを確認 | パスキー未登録者が初回登録を完了できる |
| 高 | アテステーション方針を決定 | 対象者、登録方法、既存パスキーの扱いが決まっている |
| 高 | iOS・Androidでパイロット実施 | 直接登録、同一端末認証、クロスデバイス認証が成功する |
| 高 | 紛失・交換時の復旧手順を作成 | TAP発行、旧パスキー削除、再登録まで実施できる |
| 中 | 監査方法を整備 | 登録数、AAGUID、種別、失敗状況を確認できる |
| 中 | ヘルプデスク手順を更新 | Bluetooth、通信先、Work Profileの切り分けができる |
本番展開前に実施するテスト
パイロットでは、単に一度サインインできたことだけで完了としないことが重要です。次の一連のシナリオを確認します。
- Authenticatorアプリ内からパスキーを直接登録できる
- PCからQRコードを使ったクロスデバイス認証ができる
- 対象リソースで要求した認証強度が適用される
- 許可していない認証方法へフォールバックできない
- Android Work Profileでも正しいパスキーが表示される
- 非準拠デバイスに対する条件付きアクセスが想定どおり動作する
- 端末紛失を想定し、管理者がパスキーを失効できる
- Temporary Access Passを使って新端末へ再登録できる
- 登録、削除、サインインの記録をログで確認できる
Microsoft Authenticatorのパスキー更新でよくある疑問
今回の更新だけでサインイン方法が変わるのか
該当ドキュメントと変更履歴には、今回の更新によってテナント設定や既存ユーザーの認証方法が自動変更されるとの記載はありません。管理者がパスキープロファイルや条件付きアクセスを変更しない限り、文書更新だけで認証方法が切り替わるものではありません。(Microsoft Learn)
パスキーを有効にすればパスワードを完全に廃止できるのか
パスキーを有効化しただけでは、パスワードや他の多要素認証が自動的に禁止されるわけではありません。保護対象のリソースでパスキーを必須にするには、条件付きアクセスと認証強度を設計します。
また、初回登録、端末交換、障害時の復旧経路も必要です。パスワードを残すかどうかだけでなく、Temporary Access Passや緊急時のアカウント回復を含めて判断します。
AAGUIDを指定すればMicrosoft Authenticatorだけに限定できるのか
AAGUIDによる許可リストは重要ですが、アテステーションを無効にした状態では、正規のMicrosoft Authenticatorであることを強く保証する手段にはなりません。
高い保証レベルが必要な対象では、AAGUID、デバイスバウンド型、アテステーション、条件付きアクセスのカスタム認証強度を組み合わせます。
一般社員と管理者で同じプロファイルを使ってよいか
技術的には可能ですが、推奨される認証要件が異なる場合は分けた方が管理しやすくなります。
一般社員では利便性や端末の多様性を考慮し、特権管理者ではデバイスバウンド型とアテステーションを優先する、といった設計が考えられます。ただし、両方のプロファイルへ所属すると、いずれか一つを満たせば許可される点に注意が必要です。
まず対象グループと条件付きアクセスから確認する
Microsoft Authenticatorのパスキー展開・サポート指針更新は、緊急の脆弱性対応ではありません。しかし、パスキープロファイル、AAGUID、アテステーション、条件付きアクセスを組み合わせる現在の展開方法では、設定の重複や初回登録ループが運用上の大きなリスクになります。
最初に行うべきことは、新しいポリシーを追加することではありません。現在のFIDO2設定、対象グループ、AAGUID、除外、条件付きアクセスポリシーを記録し、誰がどのプロファイルに所属しているかを確認します。
そのうえで、専用のパイロットグループを作成し、登録、サインイン、端末交換、失効、監査まで一連の動作を検証してください。パスキーは有効化するだけでなく、対象リソースへの強制、初回登録の導線、端末紛失時の復旧、ログによる確認まで設計して初めて実用的な認証基盤になります。
コメント