Windows Updateのセキュアブート更新は自動？確認方法

※本記事にはアフィリエイト広告（PR）を含みます。

パソコンのセキュアブートに関する証明書がそろそろ期限切れになると耳にして、「Windows Updateで何もしなくても大丈夫なのか」「自分のパソコンはちゃんと更新されているのか」と気になっている方は多いのではないでしょうか。

結論からいえば、2025年5月以降の累積更新プログラムを適用しWindows Updateを最新の状態に保っていれば、多くの個人向けパソコンでは手動作業なしでセキュアブート証明書の更新が完了することが期待されます。

ただし、更新の反映には時間差があるほか、機種によってはUEFIファームウェア側の更新が別途必要になる場合があるため、実際に更新が済んでいるかどうかは確認しておくと安心です。

この記事では、セキュアブート証明書がWindows Updateでどのように自動配信されるのかという基本から、Windowsセキュリティアプリやコマンドを使った確認方法、自動更新されない場合の手動適用の考え方までを順を追って紹介します。

証明書の更新状況を自分で確認しておきたい方や、対応が済んでいるか漠然と不安を感じている方に向けて、確認の手順を整理しています。

確認の順番さえ押さえておけば、セキュアブート証明書の更新状況は自分で落ち着いて確かめられます。

この記事でわかること

• セキュアブート証明書がWindows Updateで自動更新される仕組みと条件
• 2011年発行証明書の期限切れが起こる時期と実際の影響範囲
• Windowsセキュリティアプリ・PowerShellを使った確認手順の順番
• 自動更新されない場合の手動適用や注意すべきポイント

セキュアブート証明書はWindows Updateで自動更新される？基本は手動作業なしで完了する

セキュアブート証明書の更新は、多くの個人利用PCでは特別な操作をしなくても完了することが期待されます。
Windows Updateを通じて配信される仕組みが整っているため、普段どおりパソコンを使い、更新プログラムを適用していれば自然と切り替わっていくイメージです。
ここでは、その自動配信がどんな条件で動くのか、順番に見ていきます。

2025年5月以降の更新プログラムを適用していれば自動で配信される

今回のセキュアブート証明書の更新は、2025年5月13日以降に配信された累積更新プログラム（LCU）が土台になっているとされています。
この更新を適用したPCに対して、後続のタイミングで新しい2023証明書がUEFI内のKEKやdbへ配布される流れです。
つまり、更新プログラムを何もインストールしていない古い状態のままだと、そもそも配信の入り口に立てていないということになります。

ここで大事なのは、証明書そのものが単独のパッチとして降ってくるわけではない点です。
累積更新プログラムを継続して適用していることが、証明書更新を受け取るための前提条件になっています。
普段からWindows Updateを後回しにしがちな人は、まずこの土台部分ができているかを意識してみてください。

具体的には、設定アプリの「Windows Update」から更新履歴を開き、2025年5月以降の月例更新が入っているかをざっと確認するのが手軽な方法です。
履歴に何件も並んでいれば、証明書更新を受け取る準備自体は整っていると考えてよいでしょう。

個人利用のPCではユーザー側の追加操作は原則不要

家庭で使っているノートPCやデスクトップであれば、証明書の適用そのものはバックグラウンドで進むように設計されています。
ユーザーが行うのは、これまでどおりWindows Updateを止めずに適用し続けることくらいで、証明書専用の設定画面を開いて何かを押す、といった作業は基本的に発生しません。

この点は、他のセキュリティ更新プログラムの扱われ方と似ています。
例えば毎月配信される品質更新プログラムも、ユーザーが個別に内容を選んで適用するわけではなく、まとめて自動的に取り込まれる形です。
セキュアブート証明書の更新も、その延長線上にある処理と捉えると理解しやすいかもしれません。

• Windows Updateを有効なままにしておく
• 累積更新プログラムを保留せず適用する
• 再起動を求められたら早めに応じる

上記の3点さえ守っていれば、証明書更新に関して個人利用者が追加で気にする作業はほとんどないと言えます。
逆に、更新の一時停止機能を長期間使い続けている場合は、この自動配信のサイクルからも外れてしまう点に注意が必要です。

自動配信は段階的なため反映まで時間差が出る場合がある

証明書の配信は、全ユーザーへ一斉に届くわけではなく、段階的なロールアウト方式が取られているとされています。
そのため、同じ時期に更新プログラムを適用していても、隣のPCではもう反映済みなのに自分のPCではまだ、という時間差が生じることがあります。

この時間差は不具合ではなく、大規模な配信でトラブルを避けるための一般的な手法です。
マイクロソフト側で配信対象を少しずつ広げていく運用になっているため、数日から数週間程度は反映を待つ心構えを持っておくと安心です。
焦って何度も更新プログラムを再インストールしたり、設定を触りすぎたりする必要はありません。

もし「更新プログラムは入っているのに反映されている様子がない」と感じた場合は、次のセクションで扱うWindowsセキュリティアプリでの確認方法を使うと状況が把握しやすくなります。
まずは焦らず、通常のWindows Updateのサイクルに任せてみるのが基本的な向き合い方です。

2011年発行の証明書は2026年6月から順次期限切れを迎える

セキュアブートの仕組みを支えている2011年発行の証明書は、2026年6月ごろから順次有効期限を迎えるとされています（機種やメーカーによって時期に幅が出る可能性があります）。
これは特定の不具合やトラブルで起きることではなく、証明書そのものにあらかじめ設定された有効期間が満了に近づいているためです。
まずはどの証明書が対象になるのか、仕組みの部分から整理していきます。

期限が切れるのはKEKやDBに登録された2011 CAの証明書

セキュアブートは、UEFIファームウェアの中にある「KEK」と呼ばれる鍵交換用の証明書リストと、「DB」と呼ばれる許可された署名のリストを使って、起動時に読み込むソフトウェアが信頼できるものかどうかを判断しています。
2011年にマイクロソフトが発行したCA証明書は、このKEKとDBの両方に組み込まれている形が一般的です。

期限切れの対象になるのは、この2011年発行のCA証明書そのものであり、パソコン本体が壊れるとか、Windowsが使えなくなるといった話ではありません。
あくまで「証明書の有効期間が終わる」という、いわば期限のあるパスポートのようなものだとイメージすると分かりやすいです。

ただし、機種やメーカー、証明書の種類によって実際の期限を迎える時期には幅があるとされています。
同じ2026年でも、6月ごろから順にという表現になっているのはそのためで、すべてのPCが同じ日にいっせいに切り替わるわけではありません。

証明書の種類	登録先	役割の目安
2011 CA証明書	KEK・DB	起動時の信頼判断のもとになる証明書
2023 CA証明書	KEK・DB（順次追加）	2011証明書の後継として登場
ブートマネージャー署名	DB	起動プログラム自体の署名確認に使用

後継となる2023証明書への切り替えが進んでいる

2011年発行の証明書の期限切れに備えて、2023年に発行された新しい証明書への切り替えが進んでいる状況です。
前のセクションで触れた自動更新の仕組みは、まさにこの2023証明書をKEKやDBに追加するための処理にあたります。
証明書を新しくすることで、期限切れ後もセキュアブートの仕組み自体は継続して機能する形になります。

イメージとしては、古い会員証の有効期限が近づいたタイミングで、新しい会員証を発行してもらい、切り替えていく作業に近いものです。
古い証明書をいきなり削除するのではなく、新しい証明書を追加したうえで共存させる期間を設けているため、急激な変化にはなりにくい仕組みといえます。

この切り替えはWindows Update経由で段階的に配信されているため、更新プログラムを適用しているPCであれば、利用者が意識しないうちに2023証明書が追加されていることも珍しくありません。
とはいえ、配信のタイミングには差があるため、すべてのPCで同時に完了しているとは限らない点は覚えておくとよさそうです。

Windowsブートマネージャー側の署名証明書も入れ替わる

証明書の切り替えが必要なのは、UEFI側のKEKやDBだけではありません。
Windowsを起動する際に使われる「ブートマネージャー」というプログラム自体にも署名が付いており、こちらも2011年発行の証明書に対応したものから、2023年発行の証明書に対応したものへと入れ替わっていく流れになっています。

ブートマネージャーの署名証明書が新しくなることで、UEFI側のDBに登録された新しい証明書と組み合わさり、今後配信されるセキュリティ更新もきちんと検証・適用できる状態が保たれます。
逆にいうと、片方だけが新しくなっていても、もう片方が古いままだと将来的な更新の受け取りに支障が出る場面が考えられます。

UEFI側の証明書更新とブートマネージャーの署名更新は、どちらか一方だけで完結するものではないため、Windows Updateを継続的に適用しておくことが欠かせません。
更新を長期間止めてしまっているPCでは、この両方の切り替えが中途半端な状態になりやすく、後になって確認作業が必要になる場合があります。

次のセクション以降で紹介する確認方法を使えば、自分のPCで証明書やブートマネージャーの更新がどこまで進んでいるかを具体的に見ていくことができます。
まずは「2011年証明書から2023年証明書へ、UEFI側とブートマネージャー側の両方で切り替えが進んでいる」という全体像をおさえておくと、以降の確認作業も理解しやすくなります。

証明書が期限切れになってもPCが即座に起動不能になるわけではない

2011年証明書の期限切れと聞くと身構えてしまう人もいるかもしれませんが、今使っているWindowsがその瞬間から起動しなくなるわけではないと考えられます。
期限切れで起きるのは、あくまでブートマネージャーまわりの更新が受け取りにくくなるという話です。
ここでは何が変わり、何が変わらないのかを整理していきます。

すでに起動しているWindowsはそのまま使い続けられる

セキュアブートの証明書は、パソコンの電源を入れた直後にブートマネージャーやOSローダーの署名を確認する仕組みに使われています。
すでに正常に起動できているPCであれば、証明書の有効期限が過ぎたからといって、翌日から画面が真っ暗になるといった話ではありません。
普段どおりログインして作業を続けられる状態は変わらないと考えられる点は、まず押さえておきたいポイントです。

これはたとえるなら、身分証明書の有効期限が切れても、すでに部屋に入っている人が急に追い出されるわけではないのと似ています。
証明書の期限切れが影響するのは「これから新しく確認や更新をするとき」であって、「すでに動いているもの」ではないという点が大事です。

ただし、この状態がいつまでも問題なく続くという意味ではありません。
次のh3で触れるとおり、更新プログラムを受け取れなくなることで、少しずつ困る場面が出てくるようになります。
「今すぐ壊れるわけではない」ことと「放置してよい」ことは別物として考える必要があります。

ブートマネージャーやセキュアブート部品の更新が受け取れなくなる

証明書が期限切れになった場合の実質的な影響は、ブートマネージャーやセキュアブート関連コンポーネントに対するセキュリティ更新を、うまく受け取れなくなることに集約されます。
新しい証明書で署名された部品を、古い証明書しか持たないUEFIが正しく検証できなくなるためです。
結果として、Windows Updateの一部が正常に適用されない状態が続くことがあります。

影響が出る範囲を簡単に整理すると、次のようになります。

• 影響が出やすい部分：ブートマネージャー、ブートローダー関連のセキュリティ更新
• 影響が出にくい部分：普段のアプリ利用やファイル操作、通常のログイン動作
• 時間が経つほど広がりやすい部分：起動前の保護に関わる更新の未適用

このように、影響は「使い勝手」よりも「起動まわりの安全性を保つ更新」に偏って出てくる点が特徴です。
普段の作業では気づきにくいだけに、後述する確認方法で状況を把握しておくことが欠かせません。

更新が受け取れない状態を放置すると、後になってまとめて対応が必要になり、作業が煩雑になりやすい点にも注意が必要です。
「特に困っていないから」といって長期間そのままにしてしまうのは避けたい対応です。

ブートキットなど起動前マルウェアへの防御が弱まる

セキュアブートは、OSが立ち上がる前の段階で不正なプログラムが入り込むのを防ぐための仕組みです。
証明書まわりの更新が滞ると、この起動前チェックの精度を保つための土台が古いままになり、結果として守りの層が薄くなっていきます。

具体的には、ブートキットと呼ばれる起動前に潜り込むタイプのマルウェアに対する防御力が弱まる点が挙げられます。
ブートキットはOSが動き出す前の領域に働きかけるため、通常のウイルス対策ソフトでは検知しにくいという特徴があります。
だからこそ、起動前の署名検証をきちんと機能させておく意味は小さくありません。

とはいえ、これは「今日明日で必ず被害に遭う」という話ではなく、時間の経過とともに守りの精度が下がっていくというイメージで捉えるのが実情に近いでしょう。
慌てて特別な対応を取るよりも、通常のWindows Updateを継続的に適用し、証明書の更新状況を定期的に確認しておくことが現実的な対策になります。

次のセクションからは、実際に自分のPCで証明書やブートマネージャーの更新がどこまで進んでいるかを、Windowsセキュリティアプリの表示から具体的に確認していきます。

自分のPCの更新状態はWindowsセキュリティアプリで確認できる

証明書の更新状況は、Windowsセキュリティアプリを開くことで確認できます。
専門的な知識がなくても、画面の表示を見るだけで対応済みかどうかが分かるようになっているので、まずはここから確認するのが手順として自然です。
難しい操作は一切必要ありません。

「デバイスセキュリティ」からセキュアブートの項目を開く

Windowsセキュリティアプリは、スタートメニューの検索から「Windowsセキュリティ」と入力すればすぐに見つかります。
開いたら左側のメニューから「デバイスセキュリティ」を選び、その中にある「コア分離」や「セキュリティプロセッサ」といった項目の近くに、セキュアブートに関する情報が表示される仕組みです。

機種やWindowsのバージョンによって表示位置には多少の違いがありますが、基本的な流れは共通しています。
「デバイスセキュリティ」の詳細画面をひと通り見渡せば、セキュアブートの状態を示す項目が見つかるはずです。

ここで表示される内容は、あくまで現時点での更新状況をまとめたものです。
表示を確認する際は、画面をスクロールして見落とさないようにするのがポイントになります。

「必要なすべての証明書更新プログラムが適用されています」なら対応済み

セキュアブートの項目を開いたときに、「必要なすべての証明書更新プログラムが適用されています」という趣旨の表示が出ていれば、そのPCでは2023証明書への切り替えが済んでいる可能性があります。
この表示が出ている場合は、追加の作業をする必要はありません。

この状態は、これまでのセクションで触れてきた「自動配信によって手動作業なしで完了する」という基本形が、実際にそのPC上で実現できていることを示すものです。
表示を見るだけで確認が完結するため、日常的なチェックとしても取り入れやすい方法です。

• 表示例1:必要なすべての証明書更新プログラムが適用されています → 対応済み
• 表示例2:証明書の更新プログラムを確認しています → 反映待ちの段階
• 表示例3:警告アイコンや注意喚起の文言が出ている → 未対応の可能性

表示内容は上記のように大きく分けられますが、いずれの場合も焦って特別な操作をする必要はありません。
まずは表示された文言をそのまま確認し、次の行動を判断する材料にすることが大切です。

表示が出ない・警告が出る場合はWindows Updateを先に確認する

セキュアブートの項目が見当たらない場合や、注意を促すような警告表示が出ている場合は、まずWindows Updateの状態を確認するのが先決です。
証明書の更新プログラムそのものが配信・適用されていないと、Windowsセキュリティアプリ側にも正しい情報が反映されません。

設定アプリからWindows Updateを開き、更新プログラムの履歴や保留中の項目を確認してみましょう。
2025年5月13日以降の累積更新プログラムが適用されていない場合は、先にそちらを済ませることで表示が変わる場合があります。

ここで焦って設定を変更したり、原因が分からないまま操作を進めたりするのは避けたい対応です。
表示が出ないからといって、セキュアブート自体を無効にするといった対応を取る必要はまったくありません。

Windows Updateを最新化しても表示が変わらない場合は、より詳しい情報を得るために、管理者権限のPowerShellを使った確認に進む段階になります。
次のセクションでは、その具体的な確認方法を見ていきます。

PowerShellを使えばUEFI側に登録された証明書を直接確認できる

Windowsセキュリティアプリの表示だけでは判断がつきにくい場合、PowerShellのコマンドを使うことでUEFIファームウェア内部に登録された証明書の情報を直接照会できる可能性があります。
画面上の簡易表示とは違い、KEKやDBに実際にどのデータが書き込まれているかを確認できる点が特徴です。
少し専門的な操作にはなりますが、手順自体は難しいものではありません。

管理者権限のPowerShellでKEKとDBの内容を照会する

まず前提として、この確認作業は管理者権限で起動したPowerShellでなければ実行できません。
スタートメニューでPowerShellを検索し、右クリックから「管理者として実行」を選ぶ流れが基本です。

UEFIのセキュアブート関連情報を取得するには、Get-SecureBootUEFIというコマンドを使います。
KEK（Key Exchange Key）とDB（署名データベース）はそれぞれ別の領域に登録されているため、確認するときは対象を分けて指定する必要があります。

確認したい対象	入力するコマンド例
KEKの内容	Get-SecureBootUEFI -Name KEK
DBの内容	Get-SecureBootUEFI -Name db

実行すると、Bytesという項目に長い数値の羅列が表示されます。
この状態では人間の目で読み取れる形になっていないため、次のステップでもうひと手間加える必要があります。

2023証明書の文字列が含まれているかを見分ける

取得したバイトデータをそのまま眺めても、2011年発行の証明書と2023年発行の証明書を見分けるのは現実的ではありません。
そこで、出力結果をFormat-Hexなどのコマンドに渡して文字列情報を含めた形に変換し、その中に含まれる証明書名の一部を目視で探すという方法が使われています。

具体的には、Microsoft Corporation UEFI CA 2023といった名称の断片が出力の中に含まれているかどうかが、2023証明書が登録済みである可能性を示す目安になります。
逆にこの文字列が見当たらず、2011のみを示す表記しか確認できない場合は、まだ新しい証明書が反映されていない状態と考えられます。

ただし、この確認方法はあくまで文字列の有無を手がかりにした目視チェックであり、専門的な解析ツールのように厳密な証明書検証を行っているわけではありません。
表示が読み取りにくいと感じた場合は、無理に解読しようとせず、次の手動適用の検討に進む判断材料として使う程度でよいでしょう。

コマンドの入力ミスやコピー時の余分な文字が混ざると、正しい結果が表示されないことがあるため、公式に案内されているコマンドをそのまま使い、独自に改変しないことが大切です。

Windowsブートマネージャーの署名状態もあわせて確かめる

KEKやDBの証明書に加えて、Windowsブートマネージャー自体がどの証明書で署名されているかも、あわせて確認しておきたいポイントです。
ブートマネージャーは起動時に最初に読み込まれる重要な部品であり、その署名がどの世代の証明書に対応しているかによって、今後のセキュリティ更新の受け取りやすさが変わってきます。

署名情報の確認には、Get-AuthenticodeSignatureというコマンドを使い、ブートマネージャーの実行ファイルを指定する方法が知られています。
出力結果の中にある発行元や証明書の情報を見ることで、大まかな世代を把握する手がかりになります。

もっとも、こうした確認作業はあくまで現状把握のための手段であり、この時点で設定を書き換えたり削除したりする操作は避けるべきです。
KEKやDB、ブートマネージャーの署名に手を加える行為は、起動トラブルにつながる恐れがあるため、確認だけにとどめておくことが望ましい対応といえます。

ここまでの確認で2023証明書がまだ反映されていないと分かった場合は、次のステップとしてレジストリを使った手動適用の検討に進む流れになります。
焦らず、確認結果を踏まえたうえで次の対応を選んでいきましょう。

自動更新されない場合はレジストリのAvailableUpdatesキーで手動適用する

Windows Updateを最新にしても2023証明書が反映されない場合は、レジストリの値を1つ設定してから専用タスクを実行することで手動適用を試みることができます。
マイクロソフトが案内している方法に沿って進めれば、個人利用のPCでも対応できる範囲の作業です。
ただし手順を省略すると反映されないこともあるため、順番どおりに進めることが大切になります。

Secure Boot関連キーに0x5944を設定して更新対象を指定する

手動適用の入り口になるのが、レジストリの「HKLM\SYSTEM\CurrentControlSet\Control\Secureboot\AvailableUpdates」というキーです。
ここに公式に案内されている値を設定することで、Windowsに対して「どの証明書更新を配信対象にするか」を指定する仕組みになっています。
値を書き込む作業自体は数分で終わりますが、レジストリエディターの操作に慣れていない場合は落ち着いて一つずつ確認しながら進めたいところです。

作業を始める前には、BitLockerの回復キーを控え、重要なデータのバックアップを取っておく必要があります。
セキュアブート関連の構成を変更すると、再起動時に回復キーの入力を求められる場合があるためです。
ここを省略してしまうと、いざという時に慌てることになりかねません。

設定する値は下の表のとおりです。
ここで案内された0x5944以外の値を入力しないことを推奨します。

項目	内容
キーのパス	HKLM\SYSTEM\CurrentControlSet\Control\Secureboot\AvailableUpdates
種類	DWORD（32ビット）値
設定する値	0x5944

独自の値を入れたり他のレジストリ項目まで書き換えたりすると、未定義の動作や起動トラブルにつながる可能性があるため避けることを推奨します。
あくまで案内された値をそのまま設定するだけにとどめておくことが、安全に進めるためのコツといえます。

タスクスケジューラのSecure-Boot-Updateタスクを実行する

レジストリの値を設定しただけでは、証明書更新の処理はまだ動き出しません。
次に行うのが、タスクスケジューラに登録されている「Secure-Boot-Update」というタスクを手動で実行する作業です。
これはWindowsがもともと組み込んでいる仕組みで、条件がそろったタイミングで証明書の書き込み処理を担当しています。

タスクスケジューラを開く手順としては、次のような流れが一般的です。

• タスクスケジューラを管理者権限で起動する
• ライブラリから「Microsoft」「Windows」「PI」の順にフォルダをたどる
• 「Secure-Boot-Update」タスクを選び、右クリックから「実行」を選択する

タスクを実行すると、バックグラウンドでUEFIのKEKやDBに対する書き込み処理が進められます。
処理が終わるまで多少時間がかかることもあるため、実行直後にPCをシャットダウンしたり、強制的に再起動をかけたりするのは控えたいところです。
特に電源が不安定な環境では、ファームウェアへの書き込み中にトラブルが起きやすくなる点にも注意しておきましょう。

再起動を数回はさんで反映状況を再確認する

タスクを実行したあとは、一度の再起動だけで反映が完了するとは限りません。
UEFI側への書き込みとWindows側の状態同期には時間差が生じることがあるため、数回の再起動を挟んでから状態を確認することを推奨します。

確認方法は、これまでのセクションで触れたWindowsセキュリティアプリの表示や、管理者権限のPowerShellでのGet-SecureBootUEFIによる照会が基本になります。
再起動のたびに同じ手順で確認し、2023証明書に関する表示や文字列が現れているかをチェックしていく形です。

それでも反映が確認できない場合は、レジストリの値が正しく設定されているか、タスクがエラーなく完了しているかを見直す必要があります。
焦って再度値を書き換えたり、案内にない設定を試したりするのではなく、落ち着いて手順を最初から見直す姿勢が結果的に近道になります。

組織が管理しているPCの場合は、こうした手動作業を利用者側で行わず、管理者からの展開を待つ運用が前提になる点も、あわせて頭に入れておきたいところです。

更新の前提になるのは2025年5月13日以降の累積更新プログラムである

セキュアブート証明書の更新を受け取るための前提は、2025年5月13日以降に配信された累積更新プログラム（LCU）を適用しておくことが前提とされています。
この日付より前の更新しか入っていない環境では、証明書更新の仕組み自体がまだ組み込まれていないため、確認画面をいくら操作しても反映されません。
まずはこの土台となる更新プログラムの有無を意識しておく必要があります。

Windows 11・Windows 10ともに対象の更新が配信されている

セキュアブート証明書の更新は、特定のエディションだけの話ではありません。
Windows 11とWindows 10のどちらでも、2025年5月13日以降の累積更新プログラムに証明書更新の仕組みが組み込まれる形で配信されています。
普段の感覚では新しいOSだけの機能と思われがちですが、実際にはサポート対象のバージョンであれば両方に展開されている点は覚えておきたいところです。

とはいえ、配信されるタイミングやビルド番号は環境によって細かく異なります。
同じWindows 10でも、適用しているバージョンや更新履歴によって反映済みかどうかが変わってくるため、自分のPCがどのビルドを使っているか把握しておくと確認がスムーズです。
バージョン情報は設定画面から確認できる程度の作業なので、身構える必要はありません。

ここで注意したいのは、家庭用と法人向けエディションの違いだけで判断しないことです。
エディションよりも、実際に適用されている更新プログラムの日付が判断材料になります。
「Windows 11だから安心」「Windows 10だから対象外」といった単純な線引きはできないため注意が必要です。

2025年11月以降のセキュリティ更新でロールアウトが本格化した

証明書更新の仕組み自体は2025年5月時点で組み込まれ始めましたが、実際に多くの環境へ広く行き渡るようになったのは2025年11月以降のセキュリティ更新からだと案内されています。
段階的な配信という性質上、初期の時点ではまだ一部の環境にしか届いていなかった、という流れです。

この時間差は、大規模な変更を急に全台へ適用せず、様子を見ながら範囲を広げていく方式が取られているために生じます。
不具合が一気に広がるのを避けるための配慮ともいえ、利用者側から見ると「同じ更新プログラムを入れているはずなのに反映時期が違う」という状況が起きやすい部分です。

そのため、2025年5月時点で確認して表示がまだ出ないとなっても、それだけで異常だと判断する必要はありません。
2025年11月以降のタイミングで改めて確認すると、表示が変わっている可能性がありますので、時期を置いて再確認する姿勢が現実的です。

一方で、11月以降になっても表示が変わらない場合は、累積更新プログラム自体が最新化されていないケースを疑ったほうが良い場面です。
ロールアウトの時期を過ぎても未反映のままなら、次に説明するWindows Updateの状態そのものを見直す段階に移ります。

更新を止めているPCは先にWindows Updateを最新化する

証明書更新がいつまで経っても反映されない場合、原因の多くは操作方法よりも、そもそも累積更新プログラムが古いまま止まっていることにあります。
更新の延期設定や、通知を長期間先送りにしている環境では、証明書更新の仕組み自体がまだPCに届いていないことが珍しくありません。

レジストリ操作やPowerShellでの確認を先に試しても、土台となる累積更新プログラムが古いままでは意味がありません。
手順を複雑にする前に、まずWindows Updateの画面を開いて、更新の一時停止設定や保留中の項目がないかを確認する方が近道です。

確認の際は、以下のような順番で見直すとわかりやすくなります。

• 設定画面のWindows Updateから「更新を一時停止」の設定が有効になっていないか確認する
• 保留中の更新プログラムがあれば適用し、再起動を済ませる
• 更新プログラムの履歴から2025年5月13日以降の累積更新プログラムが適用済みか確認する

この順番で土台を整えたうえで、改めてWindowsセキュリティアプリやPowerShellでの確認に戻ると、状況が変わっていることも多いです。
焦って個別の設定をいじるよりも、更新の基本を最新に保つ運用に立ち返る方が、結果的に手間が少なく済みます。

UEFIファームウェアの更新が別途必要になる機種もある

証明書の更新がうまく進まないとき、原因はWindows側ではなくUEFIファームウェアそのものが古いことにある場合があります。
Windows Updateがいくら最新でも、ファームウェアが対応していなければ新しい証明書を書き込む土台が整いません。
このセクションでは、その見分け方と対応の流れを整理していきます。

古いUEFIでは新しい証明書を書き込めないことがある

セキュアブートの証明書は、UEFIファームウェアの中にある専用の領域に保存される仕組みです。
この領域を扱うプログラム自体が古いままだと、2023年発行の新しい証明書の形式にうまく対応できず、書き込み処理が途中で止まってしまうことがあります。
いわば、新しい鍵を収める金庫の受け皿が古いままで、鍵の形が合わない状態に近いイメージです。

特に発売から数年が経過したノートパソコンやデスクトップでは、ファームウェアの更新が長らく提供されていない機種も見受けられます。
こうした環境では、Windows Updateからの累積更新プログラムを適用しても、証明書の反映まで進まないことがあります。
Windows側の設定だけを見直しても解決しない場合は、ファームウェアの世代を疑ってみるのが近道です。

この状態を放置しても、すでに説明したとおりPCがすぐに使えなくなるわけではありません。
ただ、ブートマネージャー関連のセキュリティ更新を受け取れない期間が長引く点は意識しておきたいところです。

メーカー配布のBIOS／ファームウェア更新を適用する

ファームウェアが古い場合の対応は、PCメーカーが自機種向けに配布するBIOSやファームウェアの更新プログラムを適用することに尽きます。
汎用のツールや他機種向けのファイルを流用することは避け、必ず該当機種のサポートページから該当ファイルを入手する形になります。

更新の入手経路や手順は、メーカーごとにサポートサイトや専用ユーティリティを通じて案内されています。
たとえば富士通のFMVサポートやマウスコンピューターのアフターサポートといったメーカー窓口では、機種名や型番から該当のファームウェア更新を探せるようになっています。
詳細な手順や対象機種の一覧は、各メーカーの公式サイトで確認する流れが基本です。

作業の際に気をつけたいのが、更新中の電源断や強制終了です。
ファームウェア更新の途中で電源が切れると、起動そのものができなくなる可能性があるため注意が必要です。
ノートパソコンであれば電源アダプターを接続した状態で行い、デスクトップでも安定した電源環境を確保してから作業に入る方が安心です。

次の表は、作業前後で意識しておきたいポイントを簡単にまとめたものです。

タイミング	確認しておきたいこと
更新前	機種名・型番を正確に把握し、対応ファイルかどうか確認する
更新中	電源を安定させ、途中で操作を中断しない
更新後	再起動して正常に立ち上がるか、証明書の状態が変わったか確認する

BitLocker利用時は回復キーを控えてから作業する

BitLockerでドライブを暗号化している環境では、作業に取りかかる前に回復キーを控えておくことが欠かせません。
セキュアブート関連の構成が変わると、Windows起動時に回復キーの入力を求められる場合があるためです。

回復キーはMicrosoftアカウントのページや、企業・組織であれば管理者が管理するシステムに保存されていることがあります。
個人利用の場合は、事前にアカウントのページから回復キーを確認し、紙にメモしておくか、別の端末に控えておくと落ち着いて作業できます。

あわせて、ファームウェア更新やレジストリ操作の前には、重要なデータのバックアップを取っておく流れも忘れずに行いたいところです。
万一の再起動失敗や設定の不整合が起きても、データさえ守られていれば復旧の選択肢が広がります。

回復キーの控えとバックアップは、いわば作業前の準備運動のようなものです。
この一手間を省かずに進めることで、ファームウェア更新やその後の証明書反映作業を落ち着いて進められます。

企業や組織の管理下にあるPCは管理者主導での対応が前提になる

会社や学校などで管理されているPCについては、利用者が個人でレジストリ変更やファームウェア更新を行うのではなく、管理者側の展開を待つのが基本の対応になります。
組織のPCは、セキュリティ設定や更新の適用方法がまとめて管理されている場合が多いためです。
良かれと思って自分だけ手動作業を進めてしまうと、かえって管理側の設定と食い違いが出ることもあります。

WSUSやIntune配下では管理者が展開ポリシーを設定する

職場のPCの多くは、WSUSやIntuneといった管理の仕組みの配下に置かれています。
この場合、セキュアブート証明書の更新も、管理者が展開のタイミングやポリシーを設定したうえで、各端末に配信する流れが取られることが一般的です。

個人利用のPCであれば、Windows Updateを最新にしておけば手動作業なしで完了するのが基本形でしたが、組織管理下ではこの流れがそのまま当てはまらないことがあります。
管理者が意図的に更新の展開を遅らせていたり、段階的な展開スケジュールを組んでいたりするためです。

そのため、自分のPCで証明書の更新状況を確認して、まだ反映されていないように見えても、それ自体が問題とは限りません。
組織のPCは個人の判断で急いで手を加えない方が安全に運用できるとされています。
気になる場合は、情報システム担当の窓口に状況を尋ねてみるのが現実的な進め方です。

特に、レジストリのAvailableUpdatesキーを個人で書き換えたり、タスクスケジューラのタスクを勝手に実行したりする行為は避けたいところです。
管理側が把握していない変更が加わることで、後々の管理や監査に影響が出ることも考えられます。

Linuxとのデュアルブートやサードパーティ製ブートローダーは個別検証が必要

WindowsとLinuxを一台のPCで切り替えて使うデュアルブート環境や、サードパーティ製のブートローダーを利用している環境では、証明書更新の影響がWindows単体の場合と異なることがあります。
ブートローダー側もセキュアブートの仕組みに関わっているため、Windows側だけを見て判断するのは難しい面があります。

こうした環境は、一般的な個人利用のPCよりも構成が複雑になりがちです。
そのため、更新の適用や確認を進める前に、自分の環境がどのような構成になっているかを整理しておくことが助けになります。

• WindowsとLinuxを併用しているか
• 市販のPCメーカー製ではなく、独自にブートローダーを導入しているか
• 企業や学校の管理対象端末かどうか

これらに当てはまる場合は、一般的な手順をそのまま適用するのではなく、環境ごとの個別の検証が必要になる場面が出てきます。
構成を十分に把握しないまま作業を進めると、意図しない起動トラブルにつながる可能性があるため注意が必要です。

デュアルブート環境はshimやGRUBの更新状況もあわせて確認する

Linuxとのデュアルブート環境では、shimと呼ばれる仲介的な仕組みや、GRUBといったブートローダーの更新状況もあわせて見ておく必要があります。
これらはWindowsの証明書更新とは別に、それぞれのディストリビューションの提供元から更新が配布される仕組みになっています。

Windows側の証明書だけを更新して満足してしまうと、Linux側の起動に関わる部分が古いままになっていることがあります。
両方のバランスが取れて初めて、デュアルブート環境全体が安定して動く状態に近づきます。

具体的な更新方法は使用しているディストリビューションによって異なるため、それぞれの公式情報を確認しながら進める形になります。
以下は確認しておきたいポイントの一例として整理したものです。

確認対象	確認するポイント
Windows側の証明書	2023証明書がdb/KEKに登録されているか
shim	ディストリビューション提供元の更新に対応した版かどうか
GRUB	署名や設定がセキュアブートの仕組みと整合しているか

組織管理下のPCでこうした構成を利用している場合は、なおのこと個人判断での変更は控え、管理者へ相談しながら進める姿勢が安心につながります。

メーカー各社のサポート情報で機種固有の注意点を確認できる

セキュアブート証明書の更新状況は、使っているPCのメーカーやOSの提供元が公開している情報を確認することで、機種固有の注意点まで把握できます。
同じWindowsパソコンであっても、機種によって対応時期や手順の案内には違いが出る場合があるため、一般的な手順だけでなく、自分の環境に合わせた情報を合わせて見ておくと安心です。
ここでは代表的な確認先を整理してみます。

確認先	主な役割	確認できる内容の例
Windows セキュリティ アプリ（Microsoft）	OS標準の状態確認	証明書更新プログラムの適用有無
FMV（富士通（FMVサポート））	機種別の案内	対象となる更新プログラムの提供時期
マウス（マウスコンピューター アフターサポート）（マウスコンピューター）	個別問い合わせ対応	ドライバ提供やサポート窓口の案内

Windows セキュリティ アプリ（Microsoft）

Windows セキュリティ アプリは、OSに標準で組み込まれている確認手段として知られています。
「デバイスセキュリティ」の項目からセキュアブートの表示を開くと、証明書の更新状態がひと目でわかる仕組みになっています。

表示内容として「セキュア ブートがオンで、必要なすべての証明書更新プログラムが適用されています」と出ている場合は、追加の対応をする必要がないと案内されています。
この表示は、メーカーを問わず共通で確認できる基本情報にあたります。

一方で、この表示だけでは機種固有の細かい注意点まではわからないことがあります。
たとえば同じ表示が出ていても、ファームウェアの更新が別途必要になる機種とそうでない機種が混在しているため、次に紹介するメーカー側の情報とあわせて見る流れが実用的です。

まずはこのアプリで全体の状態を把握し、そのうえで自分のPCのメーカー情報を確認するという順番を意識しておくと、迷いにくくなります。

楽天市場で「Windows セキュリティ アプリ」を見る

FMV（富士通（FMVサポート））

富士通のFMVシリーズについては、FMVサポートのページで機種ごとの案内が用意されています。
2025年11月以降に提供されたセキュリティ更新プログラムで、セキュアブート証明書の更新に対応すると案内されている点が特徴です。

富士通のPCを使っている場合、まずはWindows Updateを最新の状態にしたうえで、FMVサポートのページから自分の機種名やシリーズ名で該当情報を検索する流れになります。
機種によって対象となる更新プログラムの提供時期に幅が出ることもあるため、一律の時期を前提にしないことが大切です。

また、古いUEFIファームウェアが搭載されている機種では、別途ファームウェア更新が案内される場合もあります。
この点は前のセクションで触れた内容と重なる部分ですが、富士通製PCについては特にFMVサポートの案内に沿って進める形が案内されています。

最新の対応状況や手順については、FMVサポートの公式ページで確認する形が確実です。

楽天市場で「FMV」を見る

マウス（マウスコンピューター アフターサポート）（マウスコンピューター）

マウスコンピューターについては、アフターサポートの窓口でセキュアブート証明書の更新や対応状況についての案内が用意されています。
ドライバやマニュアルの提供に加えて、専任スタッフへの問い合わせ対応も整っている点が特徴です。

自作PCに近い構成のモデルや、パーツ構成が細かく分かれるモデルを扱うメーカーという性質上、機種ごとにUEFIファームウェアの対応状況が異なる場合があります。
型番を確認しないまま他機種向けの手順を試すと、意図しない状態になる可能性があるため注意が必要です。

問い合わせを行う際は、型番やシリアル番号など機種を特定できる情報を手元に用意しておくと、案内がスムーズに進みやすくなります。
特にBitLockerを利用している場合や、ファームウェア更新を検討している場合は、事前の準備状況もあわせて伝えると安心です。

個人での判断が難しいと感じる場合は、無理に自己判断で進めず、マウスコンピューターアフターサポートの窓口に相談する選択肢も用意されています。
機種固有の状況を踏まえた案内を受けられる点が、メーカーサポートを活用する利点と考えられます。

「マウス（マウスコンピューター アフターサポート）」を検索して探す

まとめ

この記事のポイントをまとめます。

• セキュアブート証明書の更新は、2025年5月13日以降の累積更新プログラムを適用していれば手動作業なしで自動配信されるのが基本形である
• 2011年発行の証明書は2026年6月以降、機種や証明書の種類によって順次期限切れを迎える
• 期限切れになっても既存のWindowsがすぐ起動不能になるわけではなく、影響はブートマネージャー関連のセキュリティ更新を受けられなくなることが中心である
• 更新状況の確認は、まずWindowsセキュリティアプリの「デバイスセキュリティ」表示を見るのが手軽である
• より詳しく確認したい場合は、管理者権限のPowerShellでdbやKEKに2023証明書が含まれているかを照会できる
• 自動更新が反映されない場合は、レジストリのAvailableUpdatesキーに0x5944を設定しSecure-Boot-Updateタスクを実行する方法が案内されている
• 古いUEFIでは新しい証明書を書き込めない場合があり、メーカー配布の正規ファームウェア更新が別途必要になることがある
• 企業や学校など組織管理下のPCは、個人での作業を避けIT管理者の展開方針に従うことが前提になる
• レジストリ変更やファームウェア更新の前には、BitLocker回復キーの控えと重要データのバックアップを済ませておくと安心につながる

セキュアブート証明書の更新は、名前だけ聞くと難しそうに感じるかもしれませんが、多くの個人利用のPCではWindows Updateを最新に保つだけで自然に完了する仕組みになっています。
まずは身構えすぎず、普段どおりの更新作業を続けることが基本になります。

心配な場合は、Windowsセキュリティアプリの表示を確認するところから始めてみるとよいでしょう。
それで対応済みと表示されていれば、追加の作業を急ぐ必要はありません。

万が一、表示が出なかったり手動での対応が必要になったりした場合でも、レジストリのAvailableUpdatesキーやタスクスケジューラを使った公式な手順が用意されています。
作業の前にはバックアップと回復キーの控えを忘れないようにしてください。

会社や学校のPCを利用している場合は、個人で手を加えず、管理者からの案内を待つ姿勢が安心につながります。
焦らず、公式の情報源やメーカーのサポート情報を確認しながら、無理のない範囲で対応を進めていってください。