2011年に発行されたSecure Boot証明書が、2026年6月26日をもって失効する。Microsoftは5月のPatch Tuesdayからロールオーバー（証明書の更新）を段階的に展開しているが、対応が間に合わないデバイスは翌日からセキュリティ保護が低下した状態で稼働し続けることになる。「今動いているから大丈夫」が通用しない、典型的な事例だ。

Secure Boot証明書とは何か

Secure Bootは、PCの起動プロセスにおいてブートローダーやカーネルが信頼できるコードのみを実行することを保証するUEFIの機能だ。この「信頼できるコード」を判断するための署名証明書が、今回失効対象となる。

問題は証明書そのものが失効することではなく、更新が行われないデバイスでは「信頼チェーンの起点」が機能しなくなる点にある。攻撃者はこの状態を突いて、署名されていない、または不正な署名のブートローダーを実行できるようになる可能性がある。

ロールオーバーの仕組みと注意点

Microsoftは5月のPatch Tuesdayを皮切りに、Windows Updateを通じた証明書ロールオーバーを開始した。多くのデバイスは通常のWindows Updateを適用するだけで新しい証明書が導入される。

しかし注意が必要なのは一部のデバイスでOEMファームウェアの更新が別途必要なケースだ。UEFIファームウェアレベルで証明書を管理しているデバイスでは、OSの更新だけでは完結しない。OEMが提供するBIOS/UEFIアップデートを別途適用する必要がある。

デバイスの対応可否を確認する主なポイントは次のとおり：

  • Windows Updateの適用状況（最新パッチが当たっているか）
  • OEMメーカーのサポートページで該当機種のUEFIアップデートが出ているか
  • 企業内展開ではWSUSやIntune経由での適用追跡ができているか

6月26日を過ぎると何が起きるか

6月26日以降、旧証明書で署名されたブートコンポーネントは信頼されなくなる。最悪のケースでは起動できなくなるデバイスが出る可能性もあるが、より現実的なシナリオは「Secure Bootの保護機能が実質的に機能しなくなる」状態での稼働継続だ。

特にエンタープライズ環境では、BitLockerとSecure Bootを組み合わせたブート整合性保護に依存している構成が多い。このチェーンが崩れると、物理アクセスがあれば暗号化ボリュームを迂回できるリスクが高まる。

実務への影響——日本のIT管理者がすべきこと

今週中に動け、というのが率直なアドバイスだ。

  • 資産台帳を引っ張り出す — 管理下のデバイス一覧を確認し、OEMファームウェアの更新が必要な機種を特定する。古い法人PCは特に要注意
  • Windows Updateの適用状況を確認 — Intune/WSUSのコンプライアンスレポートで5月パッチ適用率を確認し、未適用デバイスがあればリマインドをかける
  • OEM更新情報を収集 — Dell、HP、Lenovo、Fujitsu、NECなど主要OEMのサポートページで対象ファームウェアアップデートをリストアップする
  • 展開テストを先行させる — いきなり全台に展開せず、少数台でファームウェア更新後の起動確認を取る
  • BitLocker回復キーの確認 — ファームウェア更新がTPM計測値に影響する場合があるため、作業前に回復キーが手元にあることを必ず確認する

筆者の見解

Secure Bootのアーキテクチャは技術的によくできている。15年間、ルートオブトラストとして機能し続けたことはひとつの成果だ。今回のロールオーバーをMicrosoftが丁寧に段階展開しているのも評価できる。

ただし今回明らかになるのは「Windows Updateさえ当てていれば終わり」という前提の限界でもある。OEMファームウェアという更新経路が別途存在し、IT管理者はその両方を把握していなければならない。特に中堅・中小企業では「PCはIT担当が管理しているから大丈夫」と思われているが、ファームウェアの更新まで追えている組織はほとんどないのが実態だ。

「今動いているから大丈夫」は本当に通用しない。6月27日の朝、突然Secure Bootが機能しなくなっているデバイスが社内に数十台ある——そんな事態は誰も望まない。期限がハッキリしている珍しいセキュリティタスクだからこそ、今すぐカレンダーに「6月26日」を入れて、逆算で動いてほしい。あとは管理者側がOEMの更新まで含めて確実にフォローアップできるかどうかにかかっている。

出典: この記事は May 2026 Secure Boot Certificate Rollover: One Restart, Big Firmware Risk の内容をもとに、筆者の見解を加えて独自に執筆したものです。