Microsoft Entra IDでFIDO2セキュリティキーによるWindowsサインインを運用している組織は、2026年7月6日に更新されたMicrosoftの公式ガイダンスを確認する必要があります。
結論から言えば、今回の更新は緊急パッチや脆弱性対応の告知ではありません。FIDO2セキュリティキーの「有効化」「登録」「サインイン」に関する文書を整理し、現在のパスキープロファイルを前提とした管理方法を明確にする更新です。FIDO2を利用していない組織に、直ちに端末設定の変更が求められるものではありません。
一方、すでにWindowsサインインへ導入している組織や、管理者・高権限ユーザーへの展開を予定している組織は、Microsoft Entra ID側のパスキープロファイル、Windows側の資格情報プロバイダー、構成済み端末へのポリシー配布、アテステーションとAAGUID制限を優先して点検すべきです。(Microsoft Learn)
Microsoft Entra ID / Windows FIDO2 authenticationの更新内容
Microsoft Learnの「Enable FIDO2 security key sign-in to Windows 10 and 11 devices with Microsoft Entra ID」は、2026年7月6日付で更新されています。
MicrosoftDocsの公式GitHub履歴では、今回の変更は「Split passkey docs」とされており、FIDO2セキュリティキーの有効化・登録・サインインに関する文書の分割、新しいサインイン手順の追加、既存手順の更新が行われています。公開履歴を見る限り、サービス仕様の強制変更、テナント設定の自動変更、緊急のセキュリティ修正を通知するものではありません。(GitHub)
更新後のガイダンスで管理者が押さえるべき点は、次のとおりです。
| 確認項目 | 更新後のガイダンスで重視されている内容 | 実務への影響 |
|---|---|---|
| 文書構成 | 有効化、ユーザー登録、サインイン手順を分離 | 社内手順書やヘルプデスク資料のリンク更新が必要 |
| Microsoft Entra ID設定 | デバイスバウンドパスキー用のプロファイルを作成し、グループへ割り当てる | 単一のテナント全体設定だけで管理する運用を見直す |
| セキュリティキーの制御 | アテステーションとAAGUIDによるモデル制限 | 承認済みキーの種類をユーザーや役割ごとに制御可能 |
| Windows端末設定 | Intune、OMA-URI、プロビジョニングパッケージ、グループポリシーを使い分ける | 新規端末と既存端末で配布方法が異なる |
| 管理者による登録 | Microsoft Graphを利用した代理プロビジョニング | プレビュー機能のため、本番依存の可否を個別判断 |
特に重要なのは、Microsoft Entra IDでFIDO2を有効にする設定と、Windowsのサインイン画面にセキュリティキーを表示する設定が別であることです。さらに、機密リソースへのアクセス時にFIDO2を必須とするには、条件付きアクセスの認証強度も別途構成します。(Microsoft Learn)
FIDO2セキュリティキーで保護される範囲
FIDO2セキュリティキーは、物理的な認証器に保存されるデバイスバウンドパスキーです。秘密鍵はセキュリティキーの外へ出ないため、偽のサインイン画面へパスワードを入力させるようなリモートフィッシング攻撃に強い認証方式です。
Microsoftは、FIDO2セキュリティキーを高い規制要件がある組織や、管理者などの高権限ユーザーに適した認証方法として位置付けています。(GitHub)
対応する主な環境
公式ガイダンスでは、次のWindows環境が対象です。
| 環境 | Windowsサインイン | オンプレミスリソースへのSSO |
|---|---|---|
| Microsoft Entra参加端末 | 対応 | Microsoft Entra Kerberosの構成が必要 |
| Microsoft Entraハイブリッド参加端末 | 対応 | Microsoft Entra Kerberos、対応DC、同期属性などが必要 |
| オンプレミスAD DSのみに参加した端末 | 非対応 | 非対応 |
| Windows Serverへの直接サインイン | 非対応 | 非対応 |
公式文書にはWindows 10の最低バージョンも記載されていますが、これは機能上の最低条件です。実際の導入では、組織のOSライフサイクル方針に従い、サポート中かつ更新済みのWindowsビルドを使用してください。(Microsoft Learn)
対応しない、または制限がある用途
次の用途は、FIDO2セキュリティキーによるWindowsサインインの対象外または制限対象です。
- オンプレミスAD DSだけに参加したWindows端末
- WebAuthnリダイレクトを使用しないRDP、VDI、Citrix環境
- セキュリティキーを使ったS/MIME
- 「別のユーザーとして実行」
- Windows Serverへのセキュリティキーサインイン
そのため、仮想デスクトップ、踏み台サーバー、サーバー管理、電子署名などでスマートカードを利用している組織が、FIDO2セキュリティキーへ単純に置き換えられるとは限りません。既存業務ごとに対応可否を確認する必要があります。(Microsoft Learn)
Windowsサインインの有効化とリソース保護は別
FIDO2セキュリティキーをWindowsサインインで使えるようにしても、それだけでMicrosoft 365や業務システムへのアクセスが常にFIDO2へ限定されるわけではありません。
役割を分けると、次のようになります。
- パスキープロファイル：誰が、どの種類のセキュリティキーを登録・使用できるか
- Windows資格情報プロバイダー：Windowsのサインイン画面でセキュリティキーを選択できるか
- 条件付きアクセス：対象リソースへのアクセスでフィッシング耐性のある認証を必須にするか
- Microsoft Entra Kerberos：オンプレミスのファイルサーバーや社内WebサイトへSSOできるか
条件付きアクセスはクラウドリソースへのサインインを保護する仕組みであり、Windows端末のローカルなサインイン処理そのものへ適用されるわけではありません。(Microsoft Learn)
管理者設定は「3層＋ハイブリッド」で確認する
Microsoft Entra ID / Windows FIDO2 authenticationを安定して運用するには、設定を一つの機能として扱わず、次の4層に分けて確認するのが実務的です。
| 設定層 | 主な設定 | 設定が不足した場合の症状 |
|---|---|---|
| Microsoft Entra ID | Passkey（FIDO2）ポリシー、プロファイル、対象グループ | キーを登録できない、想定外のキーが許可される |
| Windows端末 | 資格情報プロバイダーをIntune、OMA-URI、GPOなどで有効化 | サインイン画面にセキュリティキーが表示されない |
| リソース保護 | 条件付きアクセスの認証強度 | パスワードや別のMFAでも機密リソースへアクセスできる |
| ハイブリッド連携 | Microsoft Entra Kerberos | Windowsには入れるが、ファイル共有や社内サイトで再認証を求められる |
Microsoft Entra IDでデバイスバウンドプロファイルを作成する
Microsoft Entra管理センターの認証方法ポリシーで、Passkey（FIDO2）を有効にします。そのうえで、物理セキュリティキー用のプロファイルを作成し、パスキーの種類として「Device-bound」を選択します。
プロファイルでは、主に次の項目を管理できます。
- アテステーションを必須にするか
- デバイスバウンドと同期型のどちらを許可するか
- 特定のAAGUIDを許可または拒否するか
- どのユーザーグループへ適用するか
設定には、少なくともAuthentication Policy Administrator相当の権限が必要です。(Microsoft Learn)
パスキープロファイルへオプトインすると、既存のグローバル設定はDefaultプロファイルへ移行します。現時点ではDefaultを含め最大3プロファイルがサポートされ、オプトイン後は元の方式へ戻せません。
管理者用、一般職員用、検証用など、必要な役割を事前に整理してから移行してください。(Microsoft Learn)
また、複数のパスキープロファイルが同じユーザーへ割り当てられた場合、いずれか一つのプロファイルを完全に満たせば、そのパスキーを利用できます。高権限ユーザーへ厳しいプロファイルを設定しても、同じユーザーに緩いプロファイルが重複適用されていると、意図した制限にならない可能性があります。(Microsoft Learn)
Windowsの資格情報プロバイダーを有効にする
Microsoft Entra ID側のポリシーだけでは、Windowsのサインイン画面にセキュリティキーが表示されない場合があります。Windows側でも、セキュリティキー用の資格情報プロバイダーを有効にします。
主な方法は次のとおりです。
| 管理方式 | 主な対象 |
|---|---|
| IntuneのWindows登録設定 | 今後プロビジョニングする端末 |
| IntuneのカスタムOMA-URI | すでにプロビジョニング済みの既存端末 |
| プロビジョニングパッケージ | Intuneで管理していない端末 |
| グループポリシー | Microsoft Entraハイブリッド参加端末 |
Intuneの「Windows enrollment」内にある「Use security keys for sign-in」を有効にしても、すでにプロビジョニング済みの端末には適用されません。既存端末には、次のOMA-URIを使った対象指定の構成プロファイルが必要です。
OMA-URI:
./Device/Vendor/MSFT/PassportForWork/SecurityKey/UseSecurityKeyForSignin
Data type:
Integer
Value:
1この点を見落とすと、新しくセットアップした端末では利用できるのに、既存端末ではサインインオプションが表示されないという不整合が発生します。(Microsoft Learn)
Microsoft Entraハイブリッド参加端末では、次のグループポリシーも利用できます。
コンピューターの構成
> 管理用テンプレート
> システム
> ログオン
> セキュリティキーによるサインインを有効にするWindows Hello for Businessの有効・無効と、FIDO2セキュリティキーによるサインインの有効化は独立しています。Windows Hello for Businessを展開していないことだけを理由に、セキュリティキーが利用できないわけではありません。(Microsoft Learn)
条件付きアクセスでFIDO2を必須化する
セキュリティキーを「使える状態」にするだけでは、ユーザーがパスワードや別のMFAを選択できる場合があります。
管理者や機密システムへのアクセスでFIDO2を必須にする場合は、条件付きアクセスで次のいずれかを指定します。
- 組み込みの「フィッシングに強いMFA」認証強度
- Passkey（FIDO2）を指定したカスタム認証強度
- 特定AAGUIDだけを許可するカスタム認証強度
ただし、条件付きアクセスをいきなり有効化すると、未登録ユーザーや非対応端末を締め出す可能性があります。Microsoftは、パイロットグループを作成し、レポート専用モードで影響を確認してから段階的に適用する方法を推奨しています。(Microsoft Learn)
ハイブリッド環境ではMicrosoft Entra Kerberosも確認する
Microsoft Entra参加またはハイブリッド参加端末から、オンプレミスのファイルサーバーやWindows統合認証対応サイトへSSOするには、Microsoft Entra Kerberosの構成が必要です。
Microsoft Entra IDがActive Directoryドメイン用のKerberos TGTを発行し、オンプレミスのドメインコントローラーが完全なTGTへ交換することで、クラウドとオンプレミスの両方へアクセスできるようになります。(Microsoft Learn)
ハイブリッド環境では、少なくとも次の点を確認します。
- 対応し、更新済みのドメインコントローラーがあるか
- Microsoft Entra Kerberos Serverオブジェクトが正しく作成されているか
- 必要なオンプレミス属性がMicrosoft Entra IDへ同期されているか
- Kerberos Serverオブジェクトのオンプレミス側とクラウド側でキーバージョンが一致しているか
- ファイル共有、社内Web、NTLMを利用する既存業務でSSOを確認したか
ハイブリッド同期ユーザーのパスワードが期限切れになっている場合、FIDOによるサインインもブロックされます。「パスワードレスだからパスワード期限の影響を受けない」と考えないよう注意が必要です。(Microsoft Learn)
アテステーションとAAGUIDの設定が重要な理由
更新後の公式ガイダンスでは、物理セキュリティキーをデバイスバウンドパスキーとして扱い、アテステーションとAAGUIDを利用して認証器を制御する手順が明示されています。
アテステーションはキーの真正性を確認する
アテステーションを必須にすると、Microsoft Entra IDは登録時に、セキュリティキーのメーカーやモデルを信頼済みメタデータと照合できます。
アテステーションを使用しない場合、Microsoft Entra IDは、そのパスキーが申告されたメーカーの製品であるか、同期型かデバイスバウンドかといった属性を保証できません。(Microsoft Learn)
ただし、アテステーションは登録時にのみ評価されます。
すでにアテステーションなしで登録されたセキュリティキーは、後から「Enforce attestation」を有効にしても自動的には無効化されません。高保証環境へ移行する場合は、既存登録を棚卸しし、必要に応じて削除と再登録を行う必要があります。(Microsoft Learn)
AAGUID制限は既存ユーザーを即座に止める可能性がある
AAGUIDは、認証器のメーカーやモデルを識別する128ビットの識別子です。許可リストを使えば、会社が調達した特定モデルだけを登録・使用できるようにできます。
一方、AAGUIDによるキー制限は、新規登録だけでなく認証にも影響します。これまで許可していたAAGUIDを許可リストから削除すると、そのモデルを登録済みのユーザーもサインインできなくなる可能性があります。(Microsoft Learn)
また、アテステーションを無効にしたままAAGUIDだけを制限する構成は、厳密なセキュリティ境界として扱うべきではありません。Microsoftも、アテステーションを使用しない場合のAAGUIDリストは、厳格なセキュリティ制御ではなくポリシー上の目安として扱うよう案内しています。(Microsoft Learn)
利用者別の設定判断
| 利用者・環境 | 設定の考え方 |
|---|---|
| 特権管理者、規制対象ユーザー | Device-bound、アテステーション必須、承認済みAAGUIDの許可リストを検討 |
| 一般ユーザーのパイロット | Device-boundを基本とし、調達済みキーがアテステーションへ対応するか確認 |
| 複数メーカーのキーが混在 | AAGUID制限前に登録済みモデルを棚卸しし、段階的に制限 |
| 既存FIDO2導入環境 | アテステーションなしで登録されたキーを把握し、再登録の要否を判断 |
| BYODや幅広いパスキーを許可する環境 | 高保証ユーザーとは別プロファイルに分離し、グループ重複を確認 |
監査・検知への影響
今回の公開履歴では、新しい監査ログ形式や検知機能の追加は告知されていません。ただし、管理対象がパスキープロファイル、対象グループ、アテステーション、AAGUID、端末ポリシーへ細分化されたことで、監視すべきポイントは増えています。
「FIDO2が使われたか」だけでなく、「誰が登録できる状態だったか」「どのキーが許可されていたか」「いつ設定が変更されたか」を追える監査設計が必要です。(GitHub)
監査目的ごとにログを使い分ける
| 確認したい内容 | 主な確認先 | 注意点 |
|---|---|---|
| パスキー登録状況 | Authentication Methods ActivityのRegistration | 最大36時間程度の遅延があり、リアルタイム検知には不向き |
| FIDO2の利用状況 | Authentication Methods ActivityのUsage | 主に対話型サインインが対象で、トークンクレームで満たされた処理は含まれない |
| 実際に使われた認証方法 | サインインログのAuthentication Details | 認証方法の順序、成功・失敗、理由を確認する |
| ポリシーや資格情報の変更 | Microsoft Entra監査ログ | 管理者による認証方法変更とユーザーの資格情報変更を監視する |
| FIDO2由来のトークン更新 | 非対話型ユーザーサインインログ | 対話型ログだけを検索すると見落とす可能性がある |
| Windowsのローカルサインイン・ロック解除 | Windows端末ログ、EDR、イベント収集基盤 | Microsoft Entraサインインログだけでは端末上の全操作を証明できない |
Authentication Methods Activityでは、登録済み認証方法、パスワードレス対応ユーザー、最近の登録成功・失敗、認証方法別の利用状況を確認できます。ただし、レポートはリアルタイムではなく、最大36時間程度の遅延が生じることがあります。Usage and insightsへのアクセスにはMicrosoft Entra ID P1またはP2が必要です。(Microsoft Learn)
authenticationRequirementだけで判定しない
サインインログを調査するときは、authenticationRequirementが「singleFactorAuthentication」相当になっているという理由だけで、FIDO2が使われなかったと判断してはいけません。
以前に取得したMFAクレームが再利用されると、そのサインインで新たなMFA要求が発生せず、単一要素のように見える場合があります。Authentication Detailsを開き、認証方法の順序、ルートとなる認証方法、トークンクレームによって要件が満たされたかを確認してください。(Microsoft Learn)
ログが生成された直後は、Primary authenticationなどの情報が一時的に不完全な場合もあります。インシデント調査で表示内容が矛盾する場合は、ログ集約後に再確認する必要があります。(Microsoft Learn)
対話型ログだけを監視しない
2025年4月11日以降、FIDO2キーを使って更新トークンを取得する新しいサインインは、非対話型ユーザーサインインログへ記録されます。
従来の検索条件が対話型ユーザーサインインだけを対象としていると、FIDO2を起点としたバックグラウンドのトークン処理を見落とす可能性があります。SIEMやMicrosoft Sentinelへ転送する場合も、対話型と非対話型の両方を収集対象にしてください。(Microsoft Learn)
優先して検知したいイベント
監視ルールでは、少なくとも次の変化を優先します。
- 特権管理者への予期しないFIDO2セキュリティキーの追加・削除
- Passkey（FIDO2）ポリシーの有効・無効変更
- パスキープロファイルの対象グループ変更
- アテステーションの無効化
- AAGUIDの許可・拒否リスト変更
- ポリシー変更直後に発生したFIDO2サインイン失敗の急増
- FIDO2必須ユーザーが、対象リソースへ別の認証方式でアクセスした記録
- 紛失報告後も継続する当該ユーザーのトークン利用
Microsoftは、認証方法の管理者変更やユーザー資格情報の変更を監査ログへ記録します。長期的な傾向分析や脅威ハンティングが必要な場合は、監査ログとサインインログをSIEMやAzure Monitorへ転送して保管します。(Microsoft Learn)
対応が必要かを判断する基準
| 現在の利用状況 | 対応優先度 | 優先して確認する内容 |
|---|---|---|
| FIDO2を利用しておらず、導入予定もない | 低 | 社内手順や将来の導入計画へ今回の変更を反映 |
| WebやMicrosoft 365へのFIDO2サインインだけを利用 | 中 | パスキープロファイル、アテステーション、条件付きアクセス |
| Microsoft Entra参加Windowsへのサインインで利用 | 高 | Entra側プロファイル、Windows資格情報プロバイダー、既存端末への配布 |
| Microsoft Entraハイブリッド参加環境で利用 | 高 | 上記に加え、Entra Kerberos、DC、同期属性、パスワード期限 |
| 特権管理者や規制対象ユーザーに利用 | 最優先 | アテステーション、AAGUID許可リスト、認証強度、監査、復旧手段 |
| 複数メーカーや旧型キーが混在 | 高 | 登録済みAAGUIDの棚卸し後に制限を変更 |
| Graph APIで管理者がキーを代理登録 | 中～高 | プレビュー依存、権限、監査、一般提供前の仕様変更リスク |
「高」や「最優先」は、緊急インシデント対応が必要という意味ではありません。次回の全社展開やポリシー強化を行う前に、現在の設定と公式ガイダンスの差分を確認すべき状態を示します。
管理者が優先すべき対応手順
現在の利用状況を棚卸しする
最初に、次の情報を整理します。
- FIDO2を利用しているユーザーと対象グループ
- 管理者、高権限ユーザー、一般ユーザーの区分
- 登録済みセキュリティキーのメーカー、モデル、AAGUID
- アテステーションの有無
- Microsoft Entra参加、ハイブリッド参加、オンプレミス参加の端末数
- Windowsサインイン、クラウドアプリ、オンプレミスSSOの利用範囲
- RDP、VDI、Citrix、サーバー管理などの非対応業務
現在のポリシーを記録する
変更前に、Passkey（FIDO2）ポリシー、パスキープロファイル、対象グループ、除外グループ、AAGUID、条件付きアクセス、Intune構成をエクスポートまたは記録します。
ロールバックできない設定や、既存キーを即座に利用不能にする設定が含まれるため、変更前の状態を再現できるようにしておくことが重要です。
小規模なパイロットグループを作る
いきなり全ユーザーへ適用せず、端末参加方式や職種が異なるユーザーを含むパイロットグループを作ります。
管理者だけで試すのではなく、一般ユーザー、ハイブリッド参加端末、既存端末、新規端末、社外利用端末など、実際の利用パターンを含めてください。Microsoftも、テストユーザーと早期利用者を含むグループでの検証を推奨しています。(Microsoft Learn)
既存端末への配布方法を確認する
IntuneのWindows登録設定だけを利用している場合、既存端末にはセキュリティキー用の資格情報プロバイダーが有効になっていない可能性があります。
既存端末にはカスタムOMA-URI、新規端末には登録設定、ハイブリッド参加端末には必要に応じてグループポリシーというように、端末状態ごとに配布方法を整理します。
重要な利用シーンを一通りテストする
最低限、次の動作を確認します。
- ユーザーによるセキュリティキーの初回登録
- Windowsへの初回サインイン
- Windowsのロック解除
- Microsoft 365や業務SaaSへのアクセス
- 条件付きアクセスでFIDO2が要求されること
- オンプレミスのファイル共有や社内WebへのSSO
- キー紛失時の削除、再発行、再登録
- PIN忘れやキー故障時の復旧
- AAGUID制限変更後の既存キーへの影響
条件付きアクセスをレポート専用で評価する
フィッシングに強いMFAを要求する条件付きアクセスポリシーをレポート専用モードで作成し、ブロックされるユーザー、端末、アプリケーションを確認します。
登録率だけではなく、実際のサインインが認証強度を満たしているかを確認してから、本番適用へ進めます。(Microsoft Learn)
復旧用の認証方法を準備する
Microsoftは、紛失や盗難に備え、ユーザーが少なくとも2つの認証方法を登録することを推奨しています。
例えば、FIDO2セキュリティキーに加えてWindows Hello for Businessを登録する、予備のセキュリティキーを安全に保管する、本人確認後にTemporary Access Passを発行できる手順を整えるといった方法があります。(Microsoft Learn)
高権限ユーザーに復旧用の弱い認証方法を残す場合は、FIDO2必須化の効果を損なう可能性があります。予備手段の種類、利用条件、本人確認、承認者、監査方法まで決めてください。
失敗しやすいポイント
| 失敗例 | 原因 | 対応 |
|---|---|---|
| Entra IDでは有効なのにWindowsで選べない | Windows資格情報プロバイダーが無効 | Intune、OMA-URI、GPOの適用状況を確認 |
| 新規端末だけ利用できる | Windows登録設定が既存端末へ遡及しない | 既存端末へカスタムOMA-URIを配布 |
| アテステーションを有効にしたのに旧キーが使える | アテステーションは登録時のみ評価 | 既存登録を棚卸しし、必要に応じて再登録 |
| AAGUID変更後に大量のユーザーがサインインできない | キー制限は既存キーの認証にも影響 | 変更前に登録済みAAGUIDと利用者を確認 |
| 管理者へ厳しいプロファイルを設定したのに別のキーが使える | 緩いプロファイルがグループ重複で適用 | 全グループ所属とプロファイル割り当てを確認 |
| FIDO2導入後もパスワードで機密システムへ入れる | FIDO2を利用可能にしただけで必須化していない | 条件付きアクセスの認証強度を構成 |
| Windowsには入れるがファイル共有へ接続できない | Microsoft Entra Kerberosが未構成または不整合 | Kerberos Server、DC、同期属性を確認 |
| ハイブリッドユーザーだけログインできない | オンプレミスパスワードが期限切れ | パスワード状態と同期状況を確認 |
| 監査画面に直近の登録が表示されない | Authentication Methods Activityの集計遅延 | 監査ログやサインインログを併用し、後で再確認 |
| SIEMでFIDO2利用を取りこぼす | 対話型サインインしか収集していない | 非対話型サインインログも収集 |
| RDPやサーバーでも使える前提で展開した | 公式の非対応範囲を確認していない | 対象業務を事前に分類し、代替認証を残す |
まとめ
2026年7月6日のMicrosoft Entra ID / Windows FIDO2 authenticationに関する更新は、緊急のセキュリティパッチではなく、FIDO2セキュリティキーの有効化・登録・サインイン手順を、現在のパスキープロファイルへ合わせて整理したガイダンス更新です。
ただし、既存環境では次の点を放置できません。
- Microsoft Entra ID側とWindows端末側の設定が分離している
- IntuneのWindows登録設定は既存端末へ遡及しない
- アテステーションの有効化は既存登録へ遡及しない
- AAGUID変更は既存キーを利用不能にする可能性がある
- FIDO2を必須化するには条件付きアクセスが必要
- オンプレミスSSOにはMicrosoft Entra Kerberosが必要
- 監査では対話型と非対話型の両サインインログを見る必要がある
まず登録済みキー、AAGUID、対象ユーザー、端末参加状態、現在のポリシーを棚卸ししてください。その後、パイロットグループで端末設定と認証強度を検証し、ログと復旧手順を整えたうえで段階的に展開することが、安全かつ現実的な対応です。
コメント