Windows 11 kernel driver trust policy の変更で最初に確認すべきことは、「自社端末や製品に、WHCP 署名されていない kernel-mode driver が残っていないか」です。2026年4月18日時点で確認できる Microsoft 公式情報では、Windows 11 Release Preview Build 26100.8313 / 26200.8313（KB5083631）において、従来の cross-signed drivers を既定で信頼しない方向へ Windows driver trust policy が更新されています。許可されるのは主に、Windows Hardware Compatibility Program（WHCP）で署名されたドライバーと、Microsoft が信頼済みとして扱う一部の legacy driver allow list です。(Windows Blog)
この変更は、単なる「古いドライバーが使えなくなるかもしれない」という話ではありません。Windows security admins にとっては互換性事故を防ぐための事前監査、driver teams にとっては WHCP 署名・HLK テスト・配布経路の再確認、OEM engineers にとっては出荷イメージや周辺機器ユーティリティの再検証が必要になる変更です。
Windows 11 kernel driver trust policy の最新動向
Microsoft は、Windows 11 24H2（Build 26100）と Windows 11 25H2（Build 26200）向けの Release Preview Channel 更新として、Build 26100.8313 / 26200.8313 を公開しました。この更新には「Windows Driver Policy update」が含まれ、Windows kernel が third-party drivers を信頼する方法を変更すると説明されています。Release Preview のため、組織内の全端末へ一斉適用される前に、検証リングでの確認が重要です。(Windows Blog)
今回のポイントは、cross-signed drivers が「署名済みだから大丈夫」とは言えなくなることです。Microsoft は、過去の cross-signed program はすでに非推奨で、2026年4月の更新により、これらのドライバーは既定では信頼されなくなると説明しています。(マイクロソフト サポート)
| 確認項目 | 変更前に起きがちな誤解 | 変更後に見るべき基準 |
|---|---|---|
| ドライバー署名 | 「署名済みなら読み込まれる」 | WHCP 署名済みか、Windows Driver Policy の allow list 対象か |
| 既存ドライバー | 「今まで動いていたから今後も動く」 | enforcement mode 移行後にブロックされる可能性がある |
| 障害調査 | 「デバイス故障かアプリ不具合」 | Code Integrity の Event ID 3076 / 3077 を確認する |
| 例外対応 | 「個別に許可すればよい」 | 一般的な個別 bypass は想定せず、WHCP 署名版への更新を優先する |
何がブロック対象になり得るのか
Windows Driver Policy は、kernel-mode drivers の読み込みを制御する Windows kernel のポリシーです。有効な環境では、主に次のドライバーだけが読み込みを許可されます。
- Microsoft WHCP certification process を通じて適切に署名されたドライバー
- cross-signed program 由来でも、Microsoft の Windows Driver Policy allow list に含まれる信頼済み legacy drivers
一方、WHCP 署名されておらず、allow list にも含まれない kernel-mode driver は、対象システムでブロックされる可能性があります。Microsoft は、この仕組みにより、未検証または安全性に疑問のあるドライバーによる malware、system instability、security vulnerabilities のリスクを下げると説明しています。(マイクロソフト サポート)
影響を受けやすいのは、単体のハードウェアドライバーだけではありません。実務では、次のような製品や機能も確認対象になります。
| 分類 | 例 | 優先度 |
|---|---|---|
| セキュリティ製品 | EDR、DLP、暗号化、改ざん防止、anti-cheat | 高 |
| ネットワーク系 | VPN、仮想NIC、パケットフィルター、WAN 最適化 | 高 |
| ストレージ系 | 暗号化、バックアップ、スナップショット、RAID 管理 | 高 |
| 仮想化・開発環境 | Hypervisor 補助、USB リダイレクト、デバッグ用ドライバー | 中〜高 |
| 周辺機器 | プリンター、スキャナー、GPU、オーディオ、ドック | 中 |
| OEM ユーティリティ | ファン制御、ホットキー、ファームウェア更新、診断ツール | 中〜高 |
見落としやすいのは、「普段は使わないが、特定操作時だけ読み込まれるドライバー」です。たとえば、ファームウェア更新、VPN 接続、外部ドック接続、特殊な印刷、バックアップ復元などは、通常の起動確認だけでは検出できないことがあります。
evaluation mode と enforcement mode を理解する
今回の Windows 11 kernel driver trust policy は、いきなり全ドライバーをブロックする設計ではありません。Microsoft は、Smart App Control に似た二段階のアプローチとして、まず evaluation mode（audit）で監査し、その後、条件を満たした端末で enforcement mode に移行すると説明しています。(マイクロソフト サポート)
| モード | 挙動 | 管理者がやること |
|---|---|---|
| Evaluation / Audit | ブロック対象になり得るドライバーを記録するが、読み込みは許可される | Event ID 3076 を収集し、将来のブロック候補を洗い出す |
| Enforcement | ポリシー違反のドライバーを読み込ませない | Event ID 3077 を確認し、更新・置換・ベンダー対応を行う |
Windows 11 クライアントでは、評価期間として 100時間の active use と 3回の再起動が条件に含まれます。評価中にポリシー違反となるドライバーが読み込まれると、評価カウンターがリセットされる点も重要です。(マイクロソフト サポート)
つまり、テスト端末で「1回起動して問題ない」だけでは不十分です。実際の業務に近い状態で、周辺機器接続、VPN、バックアップ、印刷、管理ツール、セキュリティ製品の更新処理まで含めて検証する必要があります。
Windows admins 向け：まず見るべきログと判断基準
端末で「ドライバーがブロックされた」「デバイスが認識されない」「アプリが起動しない」といった症状が出た場合、最初に確認するのは Code Integrity の Operational ログです。Microsoft は、Windows Driver Policy に関係する確認先として次のログを案内しています。(マイクロソフト サポート)
Applications and Services Logs > Microsoft > Windows > CodeIntegrity > Operational
特に重要なのは次の Event ID です。
| Event ID | 意味 | 実務上の扱い |
|---|---|---|
| 3076 | audit event。ポリシー適用後ならブロックされる可能性があるが、監査モードのため読み込みは許可された | 早急に棚卸しし、ベンダー更新・WHCP 署名版の有無を確認 |
| 3077 | enforcement policy によりドライバー読み込みがブロックされた | 障害対応として扱い、更新・置換・ロールバック判断を行う |
Policy GUID も確認します。
| 種類 | Policy GUID |
|---|---|
| Audit policy | {784C4414-79F4-4C32-A6A5-F0FB42A51D0D} |
| Enforce policy | {8F9CB695-5D48-48D6-A329-7202B44607E3} |
PowerShell で audit / blocked events を確認する
管理者 PowerShell で、まず次のように Code Integrity の関連イベントを抽出します。
$log = 'Microsoft-Windows-CodeIntegrity/Operational'
$policyGuids = @(
'784C4414-79F4-4C32-A6A5-F0FB42A51D0D',
'8F9CB695-5D48-48D6-A329-7202B44607E3'
)
Get-WinEvent -LogName $log -FilterXPath "*[System[(EventID=3076 or EventID=3077)]]" -ErrorAction SilentlyContinue |
Where-Object {
$message = $_.Message
$policyGuids | Where-Object { $message -like "*$_*" }
} |
ForEach-Object {
$xml = [xml]$_.ToXml()
$data = @{}
foreach ($item in $xml.Event.EventData.Data) {
$data[$item.Name] = $item.'#text'
}
[PSCustomObject]@{
TimeCreated = $_.TimeCreated
EventId = $_.Id
FileName = $data['File Name']
ProductName = $data['ProductName']
ProcessName = $data['Process Name']
}
} |
Sort-Object TimeCreated -Descending |
Format-Table -AutoSize -Wrap結果に Event ID 3076 が出ている場合は、「今は動いているが、将来 enforcement mode で止まる可能性がある」状態です。Event ID 3077 が出ている場合は、すでに読み込みがブロックされています。
端末が evaluation か enforcement かを確認する
Microsoft Support は、citool -lp -json を使って policy の状態を確認する方法を案内しています。管理者 PowerShell で次のように確認できます。(マイクロソフト サポート)
$targetPolicies = @{
'784c4414-79f4-4c32-a6a5-f0fb42a51d0d' = 'Audit'
'8f9cb695-5d48-48d6-a329-7202b44607e3' = 'Enforce'
}
(citool -lp -json | ConvertFrom-Json).Policies |
Where-Object { $targetPolicies.ContainsKey($_.PolicyID.ToLower()) } |
Select-Object `
@{Name='Mode';Expression={$targetPolicies[$_.PolicyID.ToLower()]}},
PolicyID,
IsAuthorized,
IsEnforced端末の状態確認では、単に「機能が有効か」だけでなく、audit policy と enforce policy のどちらが有効になっているかを分けて記録してください。検証リングで audit event が出ている端末を無視して本番展開すると、後日 enforcement mode で障害化する可能性があります。
ドライバー署名の棚卸し方法
Event ID だけでは、組織内に存在するすべてのリスクを把握できません。Windows admins は、イベントログの確認と並行して、ドライバー署名の棚卸しを行います。
まず、PnP ドライバーの大まかな一覧を取得します。
Get-CimInstance Win32_PnPSignedDriver |
Select-Object DeviceName, DriverProviderName, DriverVersion, IsSigned, Signer, InfName |
Sort-Object DriverProviderName, DeviceNameただし、この方法だけで判断してはいけません。kernel-mode driver には、PnP デバイスとして分かりやすく見えないフィルタードライバー、セキュリティ製品、仮想化関連ドライバー、ソフトウェア専用ドライバーもあります。最終判断は、Code Integrity ログ、SignTool による署名確認、ベンダーからの WHCP 署名情報を組み合わせて行います。
個別ファイルの署名確認には、Windows SDK に含まれる SignTool を使います。Microsoft のドキュメントでは、cross certificate chain の確認例として signtool verify /v /kp が示されています。(Microsoft Learn)
signtool verify /v /kp C:\Windows\System32\drivers\example.sysここで注意したいのは、「何らかの署名がある」ことと「今回の Windows Driver Policy で読み込みが許可される」ことは同じではない点です。ベンダーには、単に「signed driver ですか」ではなく、「WHCP signed driver ですか」「Windows 11 24H2 / 25H2 向けに Hardware Dev Center 経由で署名されていますか」と確認してください。
blocked driver と vulnerable driver blocklist を混同しない
今回の Windows 11 kernel driver trust policy と、Microsoft vulnerable driver blocklist は別の観点の防御です。
Windows Driver Policy は、kernel-mode driver の信頼ルールを見直し、cross-signed drivers の既定信頼を外す変更です。一方、Microsoft vulnerable driver blocklist は、既知の脆弱性、malware 署名、Windows Security Model を回避し得る挙動を持つドライバーをブロックするための仕組みです。Microsoft は、Windows 11 2022 Update 以降、vulnerable driver blocklist が既定で有効になっていると説明しています。(Microsoft Learn)
| 観点 | Windows Driver Policy | Microsoft vulnerable driver blocklist |
|---|---|---|
| 主な目的 | kernel driver trust の基準を上げる | 既知の脆弱・悪用可能なドライバーを防ぐ |
| 典型的な原因 | WHCP 署名なし、allow list 外の cross-signed driver | 脆弱性や悪用履歴のある driver |
| 調査の起点 | Code Integrity Event ID 3076 / 3077 と Policy GUID | Windows Security、App Control、blocklist 関連イベント |
| 実務対応 | WHCP 署名版へ更新、ベンダー対応、App Control 設計 | 修正版へ更新、該当ドライバー削除、ASR などの防御強化 |
現場では、どちらも「ドライバーが読み込まれない」という症状になります。そのため、ユーザー報告だけで判断せず、必ずイベントログと Policy GUID を確認してください。
問題が出たときの優先順位
ドライバーが audit または block された場合、対応の基本は「無効化」ではなく「更新」です。Microsoft Support も、ドライバーがブロックされた場合は、イベントログで対象を特定し、Windows Update の driver updates、メーカー公式サイト、ベンダー問い合わせで WHCP-certified version を確認する流れを案内しています。(マイクロソフト サポート)
| 優先度 | 対応 | 判断基準 |
|---|---|---|
| 1 | WHCP 署名済みの最新版へ更新 | Windows Update、OEM サイト、ISV サポートで提供あり |
| 2 | 代替ドライバーまたは代替製品へ移行 | ベンダーが WHCP 署名予定を示せない |
| 3 | 対象機能を一時停止して業務影響を回避 | VPN、印刷、診断ツールなど限定用途 |
| 4 | 展開リングを止めて検証を継続 | audit event が複数端末で発生 |
| 5 | 例外設計を検討 | 内部専用・機密・air-gapped など特殊要件のみ |
Microsoft Support は、Windows Driver Policy を無効化するとデバイスのセキュリティが低下するため、WHCP-signed drivers の入手を推奨しています。また、一般的な個別ドライバー単位の bypass は用意されていないと説明しています。(マイクロソフト サポート)
つまり、標準運用として「ポリシーを切る」は避けるべきです。どうしても業務停止を回避する必要がある場合でも、対象端末、期間、リスク承認、復旧手順、ベンダー対応期限を明確にした break-glass として扱ってください。
driver teams が今すぐ確認すべきこと
driver teams にとって、今回の変更はビルド・署名・テスト・配布の全工程を見直すきっかけになります。
Microsoft の Driver Signing Policy では、Windows 10 version 1607 以降、新しい kernel-mode drivers は Dev Portal 経由で署名されていないと読み込まれないと説明されています。Production drivers では HLK/HCK test logs を提出し、Hardware Dev Center program への登録には EV code signing certificate が必要です。(Microsoft Learn)
WHCP は、Windows で確実に動作する hardware、software、driver を提供するための互換性プログラムであり、Windows HLK は Windows 11、Windows 10、Windows Server 向けの device / driver test framework です。(Microsoft Learn)
driver teams は、少なくとも次の項目を確認してください。
| 確認項目 | 実務での確認方法 |
|---|---|
| 現行版が WHCP 署名済みか | Hardware Dev Center の submission、catalog signature、SignTool 結果を確認 |
| cross-signed driver が残っていないか | 古い .sys / .cat / INF、過去製品から流用した package を確認 |
| HLK テストが最新 OS 向けか | Windows 11 24H2 / 25H2 など対象バージョンに合う HLK を使用 |
| 静的解析を通しているか | CodeQL、Static Tools Logo Test、DVL の生成を確認 |
| 配布経路が明確か | Windows Update、OEM preload、Web 配布、企業向け配布を分けて管理 |
| ロールバックが安全か | 古い cross-signed package に戻らないよう制御 |
Kernel-mode driver submissions では、Static Tools Logo Test により CodeQL の利用が求められ、Must-Fix query への対応が WHCP 認証の重要な条件になります。特に Server 2025 Certification では CodeQL が required tool とされています。(Microsoft Learn)
ベンダー確認に使える問い合わせ文
外部ベンダーに確認する場合は、曖昧な聞き方を避けます。次のように、署名方式、対象 OS、配布方法をまとめて確認すると、やり取りが早くなります。
Subject: Confirmation required: WHCP signing status for Windows 11 kernel driver trust policy change
Please confirm whether the following driver package is signed through Microsoft WHCP / Hardware Dev Center for Windows 11 24H2 and 25H2.
Product:
Driver package name:
Driver version:
INF / SYS / CAT files:
SHA-256 hash if available:
We need to confirm whether this package depends on cross-signed kernel-mode drivers and whether a WHCP-signed version is available through Windows Update, OEM distribution, or your official support channel.
Please also provide:
- Supported Windows versions
- WHCP / HLK certification status
- Recommended upgrade path
- Known issues with Windows Driver Policy enforcement
- Expected release date if an updated package is required「署名済みです」という回答だけでは不十分です。WHCP 署名か、単なる古い cross-signing か、test signing か、attestation signing かを分けて確認してください。
OEM engineers が見落としやすい検証ポイント
OEM engineers は、単体ドライバーだけでなく、factory image、recovery image、プリインストールユーティリティ、firmware update tool、診断ツールまで含めて確認する必要があります。
特に注意すべきなのは、出荷時には問題なく見えても、ユーザーが一定期間利用した後に enforcement mode へ移行して問題化するケースです。Windows 11 クライアントでは、100時間の active use と 3回の再起動が評価条件に含まれるため、短時間の OOBE テストだけでは不十分です。(マイクロソフト サポート)
OEM 検証では、次のシナリオをテスト計画に入れてください。
| シナリオ | 確認内容 |
|---|---|
| 初回セットアップ | OOBE 後に Code Integrity 3076 が出ていないか |
| 周辺機器接続 | ドック、GPU、オーディオ、プリンター、特殊入力デバイス |
| 更新処理 | firmware update、BIOS update、driver update utility |
| 復元処理 | recovery image から戻した後に古い driver package が入らないか |
| 長時間利用 | 100時間相当の利用、複数回再起動、スリープ復帰 |
| 法人管理 | EDR、VPN、DLP、暗号化、MDM エージェントとの共存 |
出荷イメージに含まれるユーティリティが古い kernel-mode driver を内包している場合、ハードウェア本体ではなく「付属ソフト」が原因でブロックされることがあります。OEM 側では、driver package の ownership を明確にし、ISV 提供コンポーネントも含めて再署名や更新計画を立てることが重要です。
内部専用ドライバーは Custom kernel signers を検討する
機密環境、air-gapped environment、社内専用ハードウェアなど、Microsoft へ driver binaries を提出できない事情がある組織では、Custom kernel signers for App Control for Business が選択肢になります。Microsoft は、2026年4月以降、cross-signed certificate authorities が kernel mode driver signing で既定信頼されなくなる一方、Custom kernel signers により、組織の PKI で署名した kernel drivers を信頼できるようにする仕組みを説明しています。(Microsoft Learn)
ただし、これは気軽な例外許可機能ではありません。Custom kernel signers は、Secure Boot の Platform Key（PK）または Key Exchange Key（KEK）に基づく trust chain、署名済み App Control policy、UEFI firmware 変数への管理アクセスなどが必要です。Microsoft は、policy を削除・更新できなくなると Windows が起動できなくなる可能性があるため、key management と recovery procedures を慎重に計画するよう警告しています。(Microsoft Learn)
| 向いているケース | 向いていないケース |
|---|---|
| 自社が Secure Boot PK / KEK を管理している | 一般的な社内 PC に一時的な例外を入れたい |
| air-gapped / classified environment | ベンダー製品の更新待ちを回避したいだけ |
| 内部専用 driver を継続運用する必要がある | Home edition や個人端末 |
| HSM などで key management を運用できる | UEFI 復旧手順を用意できない |
Custom kernel signers は、driver team、platform security team、OEM、IT operations が共同で設計すべき領域です。通常の commercial driver は、WHCP 署名を通す方が現実的です。
展開前の実務チェックリスト
Windows 11 kernel driver trust policy の変更に備えるなら、次の順序で進めると手戻りを減らせます。
| フェーズ | チェック項目 | 完了条件 |
|---|---|---|
| 情報整理 | 対象 OS、build、driver policy の変更点を確認 | 24H2 / 25H2 / 対象リングを把握 |
| 棚卸し | 端末上の kernel-mode driver と関連製品を洗い出す | PnP 以外の driver も含めた一覧を作成 |
| 監査 | Code Integrity 3076 / 3077 を収集 | Policy GUID 付きで記録 |
| 分類 | WHCP 署名済み、allow list 可能性、要更新、不明に分ける | 不明 driver の vendor owner を特定 |
| 対応 | Windows Update、OEM、ISV から更新版を取得 | WHCP 署名版への更新手順を作成 |
| 検証 | 100時間・3再起動・実業務シナリオを含める | audit event が残らないことを確認 |
| 展開 | pilot、broad pilot、本番の順に進める | block event 発生時の停止基準を定義 |
| 継続運用 | 新規 driver 導入時の審査項目に追加 | 署名方式と Code Integrity ログ確認を標準化 |
失敗しやすいのは、「検証端末で問題がなかった」ことを理由に全社展開してしまうケースです。evaluation mode ではブロックされず、後から enforcement mode に移行して初めて障害化する可能性があります。検証期間には、実際のユーザー行動と周辺機器利用を入れてください。
よくある質問
user-mode applications も影響を受けるのか
Microsoft Support は、この機能は kernel-mode drivers のみに適用され、user-mode applications はこの policy の影響を受けないと説明しています。(マイクロソフト サポート)
ただし、アプリ本体が user-mode でも、裏側で kernel-mode driver を読み込む製品は影響を受ける可能性があります。VPN、EDR、バックアップ、仮想デバイス、ディスク管理ツールなどは、アプリ名だけで判断せず、実際に driver を含むか確認してください。
以前から動いていたドライバーが急に止まることはあるのか
あり得ます。Microsoft Support は、evaluation mode では uncertified drivers をログに記録するだけでブロックせず、評価条件を満たすと enforcement mode へ移行し、WHCP-signed ではない drivers がブロックされる可能性があると説明しています。(マイクロソフト サポート)
そのため、「昨日まで動いていたから Windows Driver Policy は関係ない」と判断しないでください。まず Code Integrity の Event ID 3077 と Policy GUID を確認します。
個別ドライバーだけ許可できるのか
一般的な端末運用では、個別ドライバーだけを簡単に許可する方法は期待しない方が安全です。Microsoft Support は、個別 driver の bypass は現在用意されておらず、機能全体を無効化するか、望ましい対応として WHCP-signed version を入手するよう説明しています。(マイクロソフト サポート)
一方で、Secure Boot PK / KEK を管理できる特殊な組織向けには Custom kernel signers という設計があります。これは通常のヘルプデスク対応ではなく、platform security と key management を含む高度な設計として扱うべきです。(Microsoft Learn)
まとめ：次にやるべきこと
Windows 11 kernel driver trust policy の変更は、Windows admins、driver teams、OEM engineers が同じチェックリストで連携すべき更新です。最初の行動は明確です。
まず、検証リングの Windows 11 24H2 / 25H2 端末で Code Integrity の Event ID 3076 / 3077 を収集します。次に、対象ドライバーが WHCP 署名済みか、vendor が更新版を提供しているかを確認します。driver teams は HLK、CodeQL、Hardware Dev Center submission を見直し、OEM engineers は factory image と周辺ユーティリティまで含めて長時間検証を行います。
「署名済みだから大丈夫」「今まで動いていたから大丈夫」「問題が出たら無効化すればよい」という判断は、今回の変更では危険です。Windows Driver Policy の enforcement を前提に、ログ、署名、配布経路、ベンダー責任範囲を今のうちに整理しておくことが、互換性事故を避けながら Windows kernel の攻撃面を減らす最短ルートです。
コメント