Secure Boot 証明書期限切れ対策で最初に押さえるべき点はシンプルです。2026年6月以降に未更新でも、すぐに Windows や Windows Server が起動不能になるとは限りません。 ただし、未更新のままだと Secure Boot が担う「起動直後の保護」に関する新しいセキュリティ更新を受け取れなくなります。個人ユーザーは Windows Update を止めずに Secure Boot がオンか確認し、企業や学校はファームウェア検証と段階展開を今のうちに始めるのが現実的な対策です。 (マイクロソフトサポート)
このテーマが再注目されているのは、Microsoft が 2026年3月26日に IT 管理者へ「今すぐ準備を進めるべき」と案内し、さらに 2026年4月以降は Windows セキュリティ アプリで Secure Boot 証明書の状態が見えるようになったからです。つまり、今は「知らないうちに期限切れを迎える」よりも、「警告や状態表示で気づく」フェーズに入っています。 (Microsoft Learn)
Secure Boot 証明書期限切れ対策で、まず理解したいこと
今回の更新は、アプリの証明書を1枚差し替える話ではありません。UEFI の Secure Boot が信頼する証明書群を、2011年版から2023年版へ移行する話です。Microsoft の案内では、少なくとも KEK と DB の更新が関わります。 (マイクロソフトサポート)
更新対象の中心は次の3系統です。
Microsoft Corporation KEK CA 2011→Microsoft Corporation KEK 2K CA 2023。有効期限の節目は 2026年6月で、Secure Boot の DB / DBX 更新の署名に使われます。 (マイクロソフトサポート)Microsoft Windows Production PCA 2011→Windows UEFI CA 2023。有効期限の節目は 2026年10月で、Windows ブートローダーの署名に使われます。 (マイクロソフトサポート)Microsoft UEFI CA 2011→Microsoft UEFI CA 2023/Microsoft Option ROM UEFI CA 2023。有効期限の節目は 2026年6月で、サードパーティ製ブートローダーや Option ROM の信頼に関わります。 (マイクロソフトサポート)
つまり本質は、Windows 本体だけでなく、起動前に「何を信頼するか」を決める土台を更新することです。ここを理解すると、「普通の Windows Update なのに、なぜファームウェアや OEM の話が出てくるのか」が腑に落ちます。 (マイクロソフトサポート)
なお、すべての機種で同じ証明書を一律に適用するわけではありません。Microsoft は、Microsoft UEFI CA 2011 を持つデバイスに対してのみ追加で必要になる 2023 証明書があると案内しています。情シスが「全機種共通の手順」で一気に進めると、ここでつまずきやすいです。 (マイクロソフトサポート)
自分の PC やサーバーが対象かを、最短で見分ける
次のどれかに当てはまるなら、基本的にこの話題は無関係ではありません。
- 個人利用の Windows 10 / 11 Home・Pro・Education で、Microsoft から自動更新を受けている PC。多くは通常の Windows Update 経由で 2023 証明書が配信されます。 (マイクロソフトサポート)
- 企業・学校・自治体などの IT 管理端末。こちらは「自動で何とかなる」前提ではなく、Microsoft も Intune、GPO、レジストリ、WinCS など複数の展開方式を案内しています。 (Microsoft Learn)
- Windows Server。Microsoft の適用対象には Windows Server 2012 ESU / 2012 R2 ESU / 2016 / 2019 / 2022 / 2025 が含まれます。 (マイクロソフトサポート)
Secure Bootがオフの端末。更新手順はそのままでは適用対象外なので、まず有効状態を確認し、無効ならメーカーの案内を見てから設定変更を考える必要があります。 (マイクロソフトサポート)- Windows 10 を継続利用している端末。Windows 10 の通常サポートは 2025年10月14日に終了しており、2026年以降も Secure Boot を含むセキュリティ更新を受けたいなら ESU か Windows 11 への移行を前提に考える必要があります。 (マイクロソフトサポート)
迷いやすいのは、「自分は Windows 11 だから大丈夫」と思い込むケースです。実際には OS バージョンだけでなく、Secure Boot がオンか、更新が止まっていないか、機種側のファームウェアが追従できるかまで見ないと判断を誤ります。 (マイクロソフトサポート)
Windows に出る Secure Boot 警告の意味
2026年4月以降、Windows セキュリティ アプリの デバイスのセキュリティ > セキュア ブート に、Secure Boot 証明書更新の状態が表示されるようになりました。2026年5月以降は、システム通知やトレイアイコンへの反映も強化されています。 (マイクロソフトサポート)
見方は、おおむね次の理解で十分です。
- 緑: 完全に更新済みです。必要な証明書更新と更新済みブートマネージャーが入り、追加対応は不要です。 (マイクロソフトサポート)
- 黄: まだ未更新、または自動更新を妨げる要因があります。単なる反映待ちのこともあれば、ハードウェアやファームウェアの制限で自動更新が進まないケースもあります。まず最新更新と再起動を確認し、残るならメーカーや社内管理側で追加確認します。 (マイクロソフトサポート)
- 赤: 現在のブート構成では処理できない脆弱性や重大な問題がある状態です。警告を隠すのではなく、次の対処に進む必要があります。 (マイクロソフトサポート)
重要なのは、黄色と赤を同じ重さで見ないことです。黄色は「要確認」、赤は「要対応」に近い認識で考えると判断しやすくなります。 (マイクロソフトサポート)
また、更新がまだ届いていない状態で警告だけを無視するのは推奨されていません。Microsoft も、古い Secure Boot 証明書とブートローダーのままだと、Windows スタートアップ プロセスを保護する将来の更新を受けられない可能性があると案内しています。 (マイクロソフトサポート)
放置リスクは「すぐ壊れること」より「起動保護が古いまま固定されること」
Secure Boot 証明書期限切れで誤解されやすいのは、「その日を過ぎたら全部の PC が起動しなくなる」というイメージです。Microsoft の FAQ では、新しい 2023 証明書が入っていないデバイスでも、しばらくは正常に起動し、標準の Windows 更新も入り続けると案内されています。 (マイクロソフトサポート)
本当に怖いのはその先です。未更新端末は、Windows ブートマネージャー、Secure Boot データベース、失効リスト、ブートレベル脆弱性への緩和策といった「起動前後の保護」に関する新しい更新を受けられなくなります。時間がたつほど、BitLocker 強化やサードパーティ製ブートローダー、Option ROM、将来の OS・ファームウェア・ハードウェアとの互換性に影響が広がる可能性があります。 (マイクロソフトサポート)
この問題は、“壊れる日” の話ではなく “守れなくなる日” の話だと捉えると、優先度を判断しやすくなります。 (マイクロソフトサポート)
個人ユーザーが 2026年6月までにやること
まずはこの 5 つで十分です
- Windows のサポート状態を確認する
winverか設定 > システム > バージョン情報で、使っている Windows の世代とエディションを確認します。Windows 10 は通常サポートが終了しているため、2026年時点では ESU 未加入なら「Secure Boot だけ守る」は難しく、OS 側の整理が先です。 (マイクロソフトサポート) - Windows Update を止めず、最新状態まで入れる
更新の一時停止を解除し、最新の累積更新を適用して再起動します。個人向け端末の多くは Windows Update 経由で自動更新されるため、ここを止めていると話が進みません。 (マイクロソフトサポート) - Secure Boot がオンか確認する
Win + R→msinfo32→セキュア ブートの状態を見てオンなら第一関門はクリアです。もしオフなら、先に BIOS / UEFI で切り替えるのではなく、メーカーが最新の Secure Boot 構成に追従しているかを確認してください。 (マイクロソフトサポート) - Windows セキュリティ アプリの状態を見る
Windows セキュリティ > デバイスのセキュリティ > セキュア ブートで、緑・黄・赤のどれかを確認します。緑なら基本的に完了、黄色なら更新や再起動の確認、赤なら次の対処が必要です。 (マイクロソフトサポート) - BitLocker 回復キーを先に確保する
Microsoft は、一部ケースで起動不能や BitLocker 回復が発生する可能性を案内しています。Secure Boot やファームウェア周りを触る前に、回復キーを取り出せる状態にしておくと、トラブル時の詰みを避けやすいです。 (マイクロソフトサポート)
やってはいけないこと
- 警告が出たからといって、意味を確認せずに「無視」だけ押す。 (マイクロソフトサポート)
- Secure Boot をよく分からないまま BIOS / UEFI でオン・オフする。特にオフだった端末は、先にメーカー情報を確認すべきです。 (マイクロソフトサポート)
- Windows Update を一時停止したまま「そのうち直る」と放置する。自動更新前提の端末では、これが一番分かりやすい失敗です。 (マイクロソフトサポート)
企業・情シス・サーバー管理者が優先すべきこと
Microsoft は 2026年3月26日のメッセージセンターで、Secure Boot 証明書は 2026年6月から期限切れが始まり、IT 管理者は今すぐ行動すべきだと案内しました。しかも展開方式ごとの新資料まで追加されています。企業では「夏前に考える」では遅く、春のうちに棚卸しと試験展開を始めるのが基本線です。 (Microsoft Learn)
サーバーと管理端末は、ポップアップ待ちにしない
Windows Server 2019 / 2022 / 2025 には Windows セキュリティ アプリ自体はありますが、サーバーでは通知サービスが自動起動せず、状態チェックも自動では走りません。さらに、IT 管理端末や Windows Server では Secure Boot 状態の新しい視覚表示が既定で無効です。つまり、「ユーザーに警告が出たら対応する」運用はサーバーや企業端末では成立しません。 (マイクロソフトサポート)
棚卸しは「メーカー・型番・BIOS 単位」で切る
Microsoft は、広範囲展開の前に、メーカー、モデル番号、ファームウェア版、BaseBoard 版などで代表サンプルを作り、先に更新テストするよう案内しています。しかも、一意なカテゴリごとに 4台以上 のサンプルで試す推奨まで示しています。PC 台数ではなく、機種の種類数 で難易度が決まると考えると、計画しやすくなります。 (マイクロソフトサポート)
Secure Boot の有効状態は、GUI なら Windows セキュリティ > デバイスのセキュリティ、コマンドなら Confirm-SecureBootUEFI で確認できます。大規模環境では Intune など管理基盤から確認し、Secure Boot がオフの端末はこの更新手順の対象外として先に切り分けるべきです。 (マイクロソフトサポート)
展開方法は混ぜず、段階的に広げる
Microsoft は、レジストリ、GPO、WinCS、Intune / Configuration Manager など複数の展開方式を案内していますが、同じ端末で方式を混在させない よう明記しています。小さなサブセットから始め、結果を見て次のグループへ広げる段階展開が推奨です。 (マイクロソフトサポート)
運用上は、次の順番が失敗しにくいです。
- 最重要サーバーや停止コストが高い端末群を先に分類する。 (マイクロソフトサポート)
- 代表機で証明書更新と再起動後の正常性を確認する。 (マイクロソフトサポート)
- 同一メーカー・同一モデル・同一 BIOS 群へ横展開する。 (マイクロソフトサポート)
- 問題が出た型番は OEM 確認待ちに回し、全体展開から切り離す。 (マイクロソフトサポート)
反映には時間がかかる前提で監視する
IT 向けガイダンスでは、対象化した端末ではスケジュールタスクが 12時間ごと に動き、DB への証明書追加、必要な UEFI CA / Option ROM CA の追加、KEK 更新、最後に 2023 署名の Windows ブートマネージャー更新という順で進むと説明されています。最後のブートマネージャー反映には自然な再起動が必要です。 (マイクロソフトサポート)
そのため、「昨日対象化したのにまだ緑にならない」は即失敗ではありません。Microsoft は、更新完了まで 48時間と 1回以上の再起動 を見積もるよう案内しています。月例更新の適用直後だけを見て「失敗した」と判断しないことが重要です。 (マイクロソフトサポート)
監視ポイントは最低限この3つです。
- イベント ID 1801: 更新済み証明書がデバイスに適用されていないことを示すエラー系イベント。 (マイクロソフトサポート)
- イベント ID 1808: 必要な新しい Secure Boot 証明書がファームウェアへ適用されたことを示す情報イベント。 (マイクロソフトサポート)
- イベント ID 1795: DB / KEK 更新時のファームウェアエラー。OEM のファームウェア更新確認が必要になる代表例です。 (マイクロソフトサポート)
仮想化環境はホスト側も忘れない
仮想環境では、仮想化基盤側が新証明書入りの仮想ファームウェアを提供する場合があります。また、長期稼働中の VM でも、仮想ファームウェアが対応していれば Windows 経由で更新できると案内されています。 (マイクロソフトサポート)
Hyper-V では、イベント ID 1795 で KEK 更新に失敗する既知問題がありましたが、Microsoft は 2026年3月10日以降の更新で解決済みとしています。ただし修正を効かせるには、ゲストだけでなくホストにも更新が必要 です。仮想デスクトップや検証基盤でここを見落とすと、再発しやすいポイントです。 (マイクロソフトサポート)
古い機種は「直す」より「替える」が正解のこともある
Microsoft は、製造元サポートが終わった古いデバイスでは、ファームウェアが更新処理を正しく実行しない場合があるため、必要なら置き換えも検討すべきだと案内しています。セキュア ブート証明書更新は、端末更新計画の棚卸し材料にもなります。 (マイクロソフトサポート)
よくある誤解
- 「期限切れ当日に全部起動不能になる」
これは誤解です。未更新でもしばらくは通常起動し、標準の Windows 更新も続きます。問題は、起動保護の新しい更新を受けられなくなることです。 (マイクロソフトサポート) - 「Windows Update が入っていれば、企業も放置でよい」
これも危険です。企業向けはファームウェア検証、段階展開、イベント監視まで含めた運用が前提です。Microsoft 自身が複数の展開方式と段階展開戦略を案内しています。 (Microsoft Learn) - 「サーバーでも PC と同じように警告が出る」
サーバーはそうとは限りません。Windows Server では通知サービスが自動起動せず、状態表示も既定で頼れないため、管理側の監視が必要です。 (マイクロソフトサポート) - 「新しい PC なら何もしなくてよい」
これも早計です。Microsoft は、過去 1〜2 年の新しいデバイスでも、更新済み証明書は入っていても 2023 署名ブートマネージャーの適用が最後まで終わっていない場合があると案内しています。 (マイクロソフトサポート)
迷ったら、この順番で進めれば大きく外さない
個人ユーザーなら、まず Windows のサポート状態確認 → Windows Update 適用 → msinfo32 で Secure Boot 確認 → Windows セキュリティ アプリの色確認 の順で進めれば十分です。黄色や赤が残る、あるいは Secure Boot がオフなら、メーカー情報と Microsoft の最新案内を確認してください。 (マイクロソフトサポート)
企業・学校・サーバー管理者なら、棚卸し → 代表機テスト → 段階展開 → イベント監視 → OEM / 仮想化基盤確認 の順です。特に、サーバーや仮想環境は「ユーザー画面に警告が出たら対応」で間に合わないので、今のうちに管理基盤側で可視化しておく価値があります。 (Microsoft Learn)
Secure Boot 証明書期限切れ対策は、2026年6月に PC が壊れるかどうかの話ではありません。その日までに、起動時の信頼基盤を新しい世代へ切り替えられるか の話です。個人は今日、企業は今月、この確認だけでも始めておくと後手に回りにくくなります。 (マイクロソフトサポート)
コメント