Windows Updateで要注意 甘く見るとPCの起動も認証も止まる「3つのセキュリティ移行」：Microsoft MVP胡田のWindowsダイアリー（7）

2026年、Windowsではセキュア ブート証明書の世代交代など、複数のセキュリティ仕様の移行が同時に進んでいます。対象は端末の起動や認証、周辺機器とさまざまですが、いずれもWindows Updateを通じて段階的に進められています。更新後に突然ログインできなくなったり、周辺機器や業務アプリケーションが動かなくなったりしないように、自社がどの仕様変更の影響を受けるのかを把握することが大切です。皆さんの組織は、今どの変更が進み、それにどう備えるのかを説明できるでしょうか。

[胡田昌彦，＠IT]

連載目次

　Microsoftは「Windows」のセキュリティ仕様を強化し続けています。ただし互換性のために維持してきた証明書や暗号方式、ドライバ署名などの仕組みを一度に変更してしまうと、古い端末（PCやサーバなど）や業務システムが動かなくなる恐れがあります。そこで同社は、情報公開から最終的な強制までに複数の段階を設けて、数カ月から数年をかけてWindowsのセキュリティ仕様を新しい仕様に切り替えています（図1）。

図1　Windowsのセキュリティ仕様の移行は「予告」「監査」「既定値変更」「移行期間」「最終強制」という段階を踏む（筆者作成）《クリックで拡大》

「何も起きていない」は、本当に大丈夫なのか

　この慎重さはWindowsを使う組織にとってありがたい一方、ある錯覚も生みます。組織がWindowsの更新を「Windows Update」に任せていれば、特に意識しなくてもセキュリティ仕様の移行が進みます。その間、目立った障害が起きなければ、深く検証しないまま「何が変わったのかがよく分からないけれど、問題はなかった」「今回のセキュリティ仕様の移行でも、特に何も心配しなくてよい」と受け止めてしまうのです。

　同じセキュリティ更新プログラムの適用でも、「Windowsのセキュリティ仕様に関する最新情報を追い、影響を受ける対象を棚卸しして、しっかりと検証している組織」と、「何が変わったのかを把握していない組織」とでは、抱えるリスクが全く違います。その違いが表面化するのは、セキュリティ仕様移行後のWindowsで、古い機器や設定がこれまで通り利用できなくなったときです。そのときに初めて原因や影響範囲を調べ始めるのでは、Microsoftが用意した長い移行期間を生かせません。

Windows Updateは「修正プログラムの配達」だけではない

　Windows Updateと聞くと、見つかった脆弱（ぜいじゃく）性を毎月修正するセキュリティ更新プログラムを思い浮かべるかもしれません。現在のWindows Updateはそれに加えて、Windowsのセキュリティ仕様を新しい仕様へと段階的に移行する仕組みでもあります。

　一般的な仕様移行の流れは次の通りです。MicrosoftはWindows Updateを通じて、まず監査機能や移行に必要な機能を追加します。続いて新しい仕様を既定にして、問題があれば一時的に元に戻せる期間を設けた後、古い仕様を終了します。この仕様移行に伴う一連の変更は、複数回の累積更新プログラムを通じて段階的に実施します。

　Microsoftの立場で考えると、Windowsのセキュリティを強化するだけではなく、世界中の膨大なハードウェアやアプリケーション、周辺機器との互換性も維持しなければなりません。時間をかけて段階的に仕様を移行することは、セキュリティ強化と互換性維持を両立させるための現実的な方法だと考えられます。筆者は、このような長期的な取り組みを高く評価しています。

　ただしMicrosoftが用意できるのは、仕様移行の仕組みと移行期間までです。組織内のどこに古い設定や機器、システムが残っているのかを把握し、新しい仕様に移行するために必要な対策を検討して、移行に伴う業務への影響を検証するのは、Windowsを運用する組織の役割です。

　IT担当者は、まずはWindowsでどのようなセキュリティ仕様の移行が進んでいるのかを把握することが大切です。ここからは、2026年に進んでいる、3つのWindowsセキュリティ仕様の移行を順番に見ていきます（図2）。

移行1．15年ぶりに入れ替わる「セキュア ブート証明書」

図2　2026年はセキュア ブート証明書やKerberosのRC4、ドライバの移行が並行して進んでいる（Microsoftのサポート情報サイト「Microsoft Support」および技術文書サイト「Microsoft Learn」の2026年7月20日時点での内容を基に筆者作成）《クリックで拡大》

　1つ目は「セキュア ブート」（Secure Boot）で利用する証明書（以下、セキュア ブート証明書）の移行です。セキュア ブートは、端末の起動時に信頼されたソフトウェアだけを実行する仕組みを指します。

　セキュア ブート証明書は、2011年版から2023年版に移行しています。Microsoftが2011年に発行したセキュア ブート証明書は、15年を経た2026年に順次、期限を迎えています。期限は2026年6月24日、同月27日、同年10月19日の3段階です（Microsoft Supportの情報「Windows セキュア ブート証明書の有効期限と CA の更新」）。

　最新のセキュア ブート証明書に移行していない端末が、期限の翌日に一斉に起動不能になるわけではありません。通常の起動やWindows Updateによる更新プログラムの適用は継続します。一方で未移行の端末は、将来の「Windows Boot Manager」（Windowsの起動を管理するプログラム）や、起動を許可および禁止するソフトウェアのリストなど、セキュア ブートに関連する要素の更新を受けられません。そうした端末は、起動前のセキュリティ機能を最新の状態に保てなくなります。

　＠ITには既に、セキュア ブート証明書の仕組みから、端末に適用されているセキュア ブート証明書の確認方法、セキュア ブート証明書を手動で更新する手順、更新後に端末が起動しなくなった場合の復旧方法まで詳しく解説した記事があります（＠IT記事「【最終案内】2026年6月にWindows 11が起動不能に？　『セキュアブート証明書』の期限切れリスクと対策、起動しなくなった場合の対応策」）。

　本稿で注目するのは、このセキュア ブート証明書の移行が、MicrosoftによるWindowsの段階的な仕様移行の典型例になっていることです。

　Microsoftは、検証を通じて安全に適用できることを確認した端末から、Windows Updateを通じて、最新のセキュア ブート証明書に自動的に更新します。それでも自動更新できない端末には、ベンダーによるファームウェアの更新や、組織内での手動更新などが必要になります。IT担当者に求められるのは、端末のベンダーや機種に加えて、BIOS／UEFI（端末の起動を制御するソフトウェアおよびファームウェア）やセキュア ブート、セキュア ブート証明書の状態を把握し、「セキュア ブート証明書が自動的に更新されているはず」だと思い込まないことです。

　MicrosoftはWindows Updateを通じて、新しい仕様へと自動的に移行できる端末やシステムから段階的に移行を進めます。それ以外は、組織が移行作業を進めなければなりません。IT担当者に求められるのは「Windows Updateによって新しい仕様への移行は自動的に完了しているはず」と考えるのではなく、自社で利用している端末やシステムが新しい仕様に移行できているかどうかを確認することです。

移行2．2026年7月に最終フェーズに入ったKerberosの「RC4」

　2つ目は、ディレクトリサービス「Active Directory」で利用する認証方式「Kerberos」の仕様変更です。Microsoftは2026年にWindows Updateを通じて、Kerberosがサービスチケット（SMBやHTTPなどのサービスへの接続に利用する認証チケット）を発行する際の暗号方式について、「RC4」を前提とする設定から、現在広く利用されている「AES」を前提とする設定へと段階的に変更しました（Microsoft Supportの情報「How to manage Kerberos KDC usage of RC4 for service account ticket issuance changes related to CVE-2026-20833」）。

　RC4は古いシステムとの互換性に優れる一方で、現在では安全性が低い暗号方式だと見なされています。例えばRC4で暗号化されたサービスチケットを解析して、パスワードの取得を試みる攻撃手法「Kerberoasting」が知られています。Kerberosで既定の暗号方式をRC4からAESに移行する目的は、こうしたリスクを減らすことです。

　2026年1月13日提供のセキュリティ更新プログラムでMicrosoftは、ドメインコントローラー（Active Directoryの認証を担うサーバ）がサービスチケットの暗号方式としてRC4を利用した場合、そのことをイベントログに記録する監査機能を追加しました。同年4月14日には、Kerberosがサービスチケットを発行する際の既定の暗号方式を、RC4からAESに切り替える「Enforcement（強制適用）モード」を開始しました。この段階では、問題があれば一時的に、RC4によるサービスチケットの発行を許可しながら、その利用状況をイベントログに記録する「監査モード」に戻せました。そして同年7月14日に提供したセキュリティ更新プログラムで最終フェーズに入り、監査モードに戻すための設定を廃止し、監査モードそのものも終了しました。

　これによってRC4が全面的に利用できなくなったわけではありません。終了したのは、暗号方式を指定していない場合にRC4を利用する既定の動作と、旧動作に戻せる移行期間です。サービスチケットの暗号方式としてRC4を利用することを明示的に設定した場合は、引き続きRC4を利用できます。

　Microsoftは、RC4に依存するアカウントや機器を移行期間中に洗い出せるように、複数の監査機能や検出方法を用意していました。2026年1月以降のセキュリティ更新プログラムを適用し続けている組織は、RC4の利用状況を記録する監査イベント（イベントID：201〜209）を監視し、RC4に依存するアカウントや機器を事前に特定できました。Microsoftは、Windowsセキュリティログに記録されるKerberos認証イベント（イベントID：4768、4769）を利用してRC4への依存状況を確認する方法も公開しています（Microsoft Learnの情報「Kerberos での RC4 の使用状況を検出して修復する」）。一方で2026年7月のセキュリティ更新プログラムをドメインコントローラーに適用してから初めて調査を始める組織は、既定の暗号方式がAESに切り替わった後に、RC4に依存していたアカウントや機器で認証エラーやサービス停止が発生してから、その原因調査を進めることになります。

　ちなみに2026年のRC4移行は2026年1〜7月の約半年でしたが、Kerberos関連の変更としてはむしろ短い部類です。例えばKerberosのサービスチケットに含まれる権限情報（PAC）の署名を検証する機能では、2022年11月の初期展開から2023年10月の完全強制まで約11カ月かけて移行しました（Microsoft Supportの情報「KB5020805: CVE-2022-37967 に関連する Kerberos プロトコルの変更を管理する方法」）。

　証明書とActive Directoryアカウントの対応付け（マッピング）を厳密化する「強力なマッピング」では、段階的な移行を可能にするために、2022年5月に従来の認証方式も利用できる「互換モード」を導入しました。その後、約3年4カ月の移行期間を経て、2025年9月に互換モードを終了しました（Microsoft Supportの情報「KB5014754: Windows ドメイン コントローラーでの証明書ベースの認証の変更」）。認証のように互換性への影響が大きい機能では、監査機能の追加や一時的なロールバック期間を設けながら、年単位で段階的に仕様を移行することもあるのです。

移行3．既定では信頼されなくなる「古いドライバ」

　3つ目は、Windowsの中核部分（カーネル）で動作するドライバに関する仕様変更です。Microsoftは新しいドライバについて、Windows向け認証制度「Windows ハードウェア互換性プログラム（WHCP）」に基づく電子署名を求めています。一方でWindowsは互換性を維持するために、「クロス署名方式」で署名された古いドライバも読み込めるようにしてきました。クロス署名方式は、WHCPを利用せずにドライバに電子署名する従来の方式であり、新しいドライバには利用できません。2026年4月のセキュリティ更新プログラムで導入した「Windows Driver Policy」は、こうした古いドライバを信頼する既定の動作を段階的に変更します（Microsoft Supportの情報「Windows ドライバー ポリシー」）。

　Windows Driver Policyを適用した端末は、いきなり古いドライバをブロックするのではなく、まず古いドライバの利用状況を確認する「評価モード」に入ります。この間は、今後ブロック対象となるドライバについて、イベントログ（コード整合性のイベントログ、イベントID：3076）に記録しながら、実際の読み込みは許可します。評価モードの間に、今後ブロック対象となるドライバを検出しなければ、自動的に「強制モード」に移行します。強制モードでは、Windowsは新しい署名要件を満たさないドライバをブロックするので、古い周辺機器を認識しなくなったり、特定のドライバを必要とするアプリケーションが起動しなくなったりする可能性があります。

　この移行の流れも、古いドライバの利用状況を確認してから、新しい署名要件を適用するという点で、セキュア ブート証明書やRC4の移行と同じです。ただし古いドライバの利用状況によって、評価モードから強制モードに移行する時期は端末ごとに異なります。そのためWindows Updateを適用しただけでは、全ての端末が強制モードに移行しているとは限りません。IT担当者はイベントID：3076として記録されたイベントを確認して、古いドライバを新しい署名済みバージョンに更新するか、それとも周辺機器ごと更新するかを判断しなければなりません。

それでも、Windows Update自体が無事故とは限らない

　ここまで読むと「Windows Updateを止めずにセキュリティ更新プログラムを適用し続ければ、それだけで十分だ」と聞こえるかもしれません。しかし更新プログラムが、予期しない不具合を引き起こすこともあります。その点を無視して、単に更新プログラムを適用すればよいと考えるのは適切ではありません。

　例えば2024年7月9日提供のWindows 11向けセキュリティ更新プログラム（KB5040442）では、起動時に端末がドライブ暗号化機能「BitLocker」の回復画面を表示し、回復キー（BitLockerを解除するためのキー）の入力を求める既知の問題が発生しました（Microsoft Supportの情報「2024 年 7 月 9 日 - KB5040442 (OS ビルド 22621.3880 および 22631.3880)」）。2025年5月提供のWindows 10向け更新プログラム（KB5058379）でも、セキュリティ機能「Intel Trusted Execution Technology」（Intel TXT）が有効な端末で、Windowsの認証を担うプロセス「lsass.exe」が異常終了し、自動修復時にBitLocker回復キーの入力を求める問題が確認されました（Microsoft Supportの情報「2025 年 5 月 13 日 - KB5058379 (OS ビルド 19044.5854 および 19045.5854) - EXPIRED」）。

　更新プログラムにまつわるトラブルは、過去の話ではありません。2026年4月提供のWindows Server向けセキュリティ更新プログラムでは、複数のActive Directoryドメインをまとめて管理するフォレストで、特権アクセス管理機能「Privileged Access Management」（PAM）を利用しているドメインコントローラーのlsass.exeが応答しなくなりました。その結果、ドメインコントローラーが再起動を繰り返し、認証やディレクトリサービスを利用できなくなる問題が発生しました（Microsoft Supportの情報「2026 年 4 月 19 日 ? KB5091157 (OS ビルド 26100.32698) 帯域外」）。

　2026年6月23日提供のWindows 11プレビュー更新プログラムでは、一部のDell Technologies製端末で、端末の電力管理や性能制御を担う「Intel Innovation Platform Framework」（Intel IPF）ドライバに関する互換性問題が発生しました。Microsoftは対象端末への同年7月のセキュリティ更新プログラムの配信を一時停止し、同月18日に定例外更新プログラム（定例配信とは別に公開する更新プログラム）を公開しました（Microsoft Supportの情報「July 18, 2026-KB5121767 (OS Builds 26200.8894 and 26100.8894) Out-of-band」）。

　これは「だから更新プログラムを適用しない方が安全だ」という話ではありません。むしろ更新プログラムを適用する運用と、更新プログラムによってトラブルが発生した場合に迅速に復旧できる運用を、一体で用意すべきだという話です。

　BitLocker回復キーは、MicrosoftのID・アクセス管理サービス「Microsoft Entra ID」やActive Directoryに確実に保管しておきます。代表的な端末から段階的に更新プログラムを展開し、Microsoftの公式サイトでWindowsの既知の問題を確認します（Microsoft Learnの情報「Windows のリリースの正常性」）。問題が見つかれば後続リング（次の段階で更新する端末グループ）への展開を一時停止し、定例外更新プログラムや回避策を評価します。

　更新プログラムを適用し続けるには、適用の仕組みだけではなく、トラブルが発生した際に迅速に復旧できる仕組みまで含めて設計することが重要です。

更新を止めると、長い移行期間を自ら捨てることになる

　筆者はこれまで、更新プログラムを長らく適用していなかった端末が、大きな障害のきっかけとなった事例を複数見聞きしてきました。別のトラブルをきっかけに端末を再起動すると、Windows Updateが保留していた更新プログラムを短期間に集中して適用し、不具合が重なって障害が拡大することがあったのです。

　技術的には、更新プログラムをしばらく適用していなかった端末でも、適用を再開したからといって、一気に全ての仕様変更を適用した状態に移行するわけではありません。ただし運用面では、Microsoftが数カ月かけて設けた監査期間や互換性の確認期間、一時的なロールバック期間を十分に活用できなくなります。その結果、複数のセキュリティ強化や既定値の変更が短期間に集中し、どの変更がどの機器やアプリケーションに影響したのかを切り分けることが難しくなります。

　この話は、前回取り上げたWindowsの更新管理ツール「Windows Server Update Services」（WSUS）の非推奨化にもつながります。「更新管理の仕組みを導入していること」と「組織内の全ての端末に更新プログラムを適用し続けて、その状況を把握できていること」は別です。管理対象から漏れていたり、長期間停止していたり、更新プログラムの適用に失敗し続けていたり、例外扱いのまま放置していたりする端末がないかどうか――。更新率だけを見るのではなく、「更新プログラムを適用すべきなのに、適用していない端末」を把握することが重要です。

必要なのは、更新をイベントではなく日常業務にすること

　「Windows Updateの更新プログラムを適用しましょう」と言うだけなら簡単です。全端末に一斉に適用すればよいわけでも、障害を恐れて適用を止めてよいわけでもありません。必要なのは、Microsoftが公開する更新情報や既知の問題を収集し続けて、自社への影響を判断することです。その上で、代表的な端末構成で検証し、小規模なグループから段階的に展開します。更新後も適用結果を監視し、例外を期限付きで管理するといった運用が欠かせません。BitLocker回復キーやロールバック手順、問い合わせ先を事前に整備し、問題が起きても迅速に復旧できるように準備する必要があります。

　更新プログラムを適切に管理している組織は「障害が起きていないから大丈夫」とは考えません。「今どの変更が進んでいるのか」「自社のどこが影響を受けるのか」「誰がいつまでに何をするのか」「更新プログラムの適用結果をどう確認したのか」「問題が起きたらどう復旧するのか」を説明できます。端末のイベントログを継続的に確認し、実際に何が起きているのかも把握できます。セキュア ブート証明書、KerberosのRC4、ドライバ署名の移行は、その能力を測る直近の3つの試金石です。

　Windowsでは、ある日突然仕様が変わったように見えることがあります。実際には、その前にMicrosoftが長い予告期間や移行期間を用意していることがほとんどです。同社が事前に公開する情報を受け取り、日ごろから更新プログラムの適用を続けていれば、そうした変化も計画的に受け入れられます。問題が起きてから慌てて追い付くのではなく、問題が起きる前から少しずつ進み続ける――。Windowsを長く安全に使うために最も大切なのは、そうした運用を続けることです。

筆者紹介

胡田昌彦（えびすだ・まさひこ）

日本ビジネスシステムズに勤務。幼少期からコンピュータ大好きで歴は40年以上。インフラから、クラウド、アプリ、生成AIまで幅広く取組中。2014年からMicrosoft MVPアワードを連続受賞中。Windows、Windows Server、Microsoft Azure、Microsoft 365など、Microsoftソリューションを中心に情報発信中。YouTuberとしても活動中（https://www.youtube.com/@ebibibi）。