Microsoftは2026年3月27日、2000年代初頭に導入された「クロス署名ルートプログラム（cross-signed root program）」によって署名されたカーネルドライバへの信頼を、2026年4月のWindows Updateで原則として撤廃すると発表した。対象となるのはWindows 11 24H2・25H2・26H1、およびWindows Server 2025以降のすべてのバージョンだ。証明書自体は2021年にすでに失効しているにもかかわらず、これらのドライバへの「信頼」だけが長らく温存されてきた。その事実がセキュリティ上いかに危険な状態を生み続けてきたか、今回の決定が持つ意味を見ていきたい。
クロス署名プログラムとは何だったのか
2000年代初頭のWindows環境では、サードパーティドライバのカーネルへの読み込みを制御する仕組みが整備されておらず、Microsoftはコードの整合性（Code Integrity）を確保するための手段として「クロス署名ルートプログラム」を導入した。このプログラムは、Microsoftが直接署名するのではなく、サードパーティの証明書認証局（CA）がドライバ開発者に対してWindowsが信頼できるコード署名証明書を発行する、という委任方式を採っていた。
この設計には根本的な問題が内在していた。ドライバを署名するための秘密鍵の保護は、各ドライバ開発者に一任されていた。パートナーの身元確認はある程度行われていたものの、署名されたコードのセキュリティや互換性については「ゼロの保証」しか提供されなかった、とMicrosoftは今回の発表で明確に認めている。その帰結として、秘密鍵の盗難や不正利用が相次ぎ、悪意ある行為者がそれを利用して正規証明書で署名された悪質なドライバをWindowsカーネルに送り込む、という攻撃ベクトルが長年にわたって機能し続けた。
Microsoftは2021年、こうした背景からクロス署名プログラム自体を廃止した。しかしプログラムを廃止したからといって、すでに署名済みの既存ドライバへの信頼まで自動的に失効するわけではなかった。カーネルはそれらのドライバを「歴史的な信頼」に基づいて引き続き読み込んでいたし、プリンターや古い産業用機器、レガシーなセキュリティソフト等のドライバとして実際に使用されていたケースも多い。その「信頼の残滓」を今回、ついに取り除くというのがこの発表の本質だ。
なぜ今なのか：2年間の大規模テレメトリが根拠
Microsoftが今回の変更を単なるポリシー宣言ではなく、データに裏付けられた意思決定として提示している点は見逃せない。同社によれば、Windows 11とWindows Server 2025における過去2年間にわたる「数十億件のドライバロードシグナル」をもとに方針を策定し、開発者コミュニティからのフィードバックも取り入れた、としている。
この規模のテレメトリは、「どのクロス署名ドライバが現実の環境でどれだけ使われているか」を把握するという、セキュリティポリシー策定としては異例なほど精緻なアプローチだ。信頼を一律に撤廃すれば互換性への打撃は大きい。かといってセキュリティ上の問題を放置し続けることもできない。その板挟みの中でMicrosoftが採った解決策が、データに基づく「明示的な許可リスト（allow list）」の構築だった。使用頻度が高く、評判の確立された一部のクロス署名ドライバについては、引き続き信頼するリストに残す。リストに載っていないものは、新ポリシーの下でデフォルトではブロックされる。
段階的ロールアウト：「評価モード」の仕組み
互換性への影響を最小化するため、今回の変更は「即時強制」ではなく「評価モード（evaluation mode）」から開始される。2026年4月のWindows Updateが適用されると、対象システムはまず評価フェーズに入り、Windowsカーネルがドライバの読み込み状況を継続的に監視・記録する。
新ポリシーの強制適用（enforcement）への移行は、以下の2つの評価基準を同時に満たした場合に限り行われる。
| 評価基準 | Windows 11 / Windows Server 2025 |
|---|---|
| システムの稼働時間 | 100時間以上 |
| ブートセッション回数 | Windows 11: 3回以上 / Windows Server 2025: 2回以上 |
両方の基準が満たされた後、評価期間中に読み込まれたすべてのドライバが新ポリシーを通過できると判断された場合にのみ、強制モードへ移行する。もし評価期間中に一つでも新ポリシーをパスしないクロス署名ドライバが検出された場合、評価は最初からやり直しとなり、そのドライバが使用されなくなるまで強制適用は行われない。
この設計の肝は、「特定の環境では使われるが普段は使われない」ドライバの存在を考慮している点だ。例えば、システムの起動時にのみ読み込まれるboot-startドライバと、動作中にのみ使用されるランタイムドライバは動作タイミングが異なる。2つの評価基準（時間とリスタート回数）を組み合わせることで、両方のシナリオをカバーするという設計になっている。
企業向けの「抜け道」とその厳格な条件
今回の変更が産業界に与える影響について議論する上で、「App Control for Business（旧称WDAC）ポリシー」による例外的な対応手段の存在は重要なポイントになる。Microsoftは、WHCP認証を通過できない機密性の高いドライバや社内専用ドライバに限り、この仕組みを使って新ポリシーの例外を設定できるとしている。
ただし、その条件は厳格だ。カスタムポリシーは、デバイスのUEFI Secure Bootに組み込まれたプラットフォームキー（PK）または鍵交換キー（KEK）によって署名されている必要がある。これは自社の管理下にある端末にのみポリシーが適用されることを保証するためのものであり、外部の攻撃者がこの仕組みを乗っ取ることを構造的に防いでいる。MicrosoftはこのApp Controlポリシー機能を「レガシーデバイスのサポートではなく、機密性の高い内部ドライバシナリオのため」と明示している。つまり、「古いプリンタードライバを使い続けたいから」という理由では、この抜け道を使うことは想定されていない。
WHCPという「関所」：何が変わるのか
新ポリシーの核心は、Windows Hardware Compatibility Program（WHCP）認証を事実上の唯一の正規ルートとして定義することにある。このプログラムは単なる署名手続きではない。ドライバの提出物はマルウェアスキャンを受け、Hardware Lab Kit（HLK）によるテストで現行のWindows OSおよびハードウェアとの互換性が確認される。さらに、Microsoftが直接管理・保護するコード署名証明書によって署名される仕組みだ。
かつてのクロス署名プログラムとの最大の違いは、秘密鍵の管理主体にある。クロス署名では各開発者が自らの秘密鍵を管理していたが、WHCP経由の署名では鍵の管理はMicrosoft側に集約される。これは、鍵の盗難や漏洩による不正署名というリスクを、少なくとも構造的には排除する設計だ。
ドライバ開発者の視点からすれば、WHCPの認証プロセスは負担が増す変化でもある。Hardware Dev Center（HDC）ポータルを通じた申請、HLKテストの実施、パートナー身元確認——これらのコストを負担できない零細なドライバ開発者やすでに事業を終了したベンダーのドライバは、今後のWindowsでは原則として動作しないことになる。
レガシーハードウェアユーザーへの現実的な影響
今回の変更が「一般ユーザー」に直接影響を与えるケースは、主に古いハードウェアを使用しているユーザーに集中する。ドライバの更新が長年止まっているプリンター、スキャナー、古い音声インターフェース、特定の産業用計測機器などが典型例だろう。
ただし、前述の「評価モード」と「許可リスト」の存在が、少なくとも短期的にはクッションとしての機能を果たす見込みだ。評価期間中に非対応ドライバが検出されたシステムは強制モードへ移行せず、そのまま評価モードに留まる。Microsoftがどの程度の期間この「評価モードの猶予」を維持するのかは明確ではないが、完全な強制排除が段階的に進んでいくことは避けられない。
自分の環境が影響を受けるかどうかを事前に把握しておきたい場合、デバイスマネージャーから各ドライバのプロパティを開き、「ドライバーの詳細」タブで署名者を確認するのが手早い方法だ。Microsoft以外の認証局名が表示されているドライバがあれば、クロス署名プログラム経由で署名されている可能性が高い。より詳細な調査には、イベントビューアーの「アプリケーションとサービスログ」→「Microsoft」→「Windows」→「CodeIntegrity」以下のログが参考になる。評価モードが稼働すると、ここに非適合ドライバのイベントが記録されるため、Microsoftの正式なロールアウト前にドライバの状態を把握する指標となる。
The Registerは今回の変更について「Microsoftの方向性は明確であり、最終的にはWHCP認証を通過していないあらゆるコードがカーネルで動作することを禁じる」という見通しを示している。これは一時的な移行措置ではなく、カーネルセキュリティの基準を根本的に引き上げるための長期的な取り組みの一環だ。
20年越しの「ツケ」を払う
この問題の根本にあるのは、MicrosoftがWindowsエコシステムの拡大を優先してきた歴史的な選択の積み重ねだ。2000年代初頭、Windowsはサードパーティドライバの豊富さで他のOSに対する優位性を築いた。そのためには開発者が容易に署名できる仕組みが必要で、クロス署名プログラムはその役割を確かに果たした。互換性の広さがWindowsの強みであり、「なんでも動く」という評価が購買決定を動かしてきた。
しかし、その開放性はセキュリティという観点では常に諸刃の剣だった。カーネルは実質的にOSの「神聖な領域」であり、ここに侵入できれば攻撃者はシステム全体を支配できる。近年のランサムウェア攻撃やAPT（高度持続型脅威）グループの活動では、脆弱または漏洩した署名証明書を用いたカーネルドライバの悪用が確認されており、この問題は理論上のリスクではなく現実の攻撃手法として確立されている。
Microsoftが「Secure Future Initiative（SFI）」として組織的にセキュリティ強化を打ち出してきた文脈に今回の発表を置くと、その位置付けがより鮮明になる。SFIはMicrosoftがセキュリティを製品の中心に据え直すことを宣言したもので、本件もその流れに沿う施策だ。しかし、20年以上にわたる「互換性のためのセキュリティ妥協」という歴史は、一つのポリシー変更で清算できるほど単純ではない。
WHCPへの完全移行が実現するまでの間、許可リストに載らず、かつApp Controlポリシーも使えない環境に置かれたレガシードライバは、事実上の「オルファン（孤児）」となる。その数がどの程度になるのかは、今後の評価モードのデータが示すことになる。Microsoftが示す評価基準の透明性は、少なくとも場当たり的な対応ではなく、長期的なシナリオに基づいた設計であることを示唆している。2000年代に蒔いた互換性優先という種が、四半世紀を経てセキュリティという形で代償を求めている——その現実に対してMicrosoftが下した答えが、今回の発表だ。
Sources
