3行まとめ
このテーマをもう少し広げて見るなら、Windows 11 Release Preview 26100.8728/26200.8728：Point-in-time Restore、Widgets静音化、IPP既定化の確認ポイント と Microsoft Edge 152から2週間リリースへ：Stable、Extended Stable、管理者の確認ポイント も合わせて確認してください。Secure Boot証明書更新を運用面で追う読者に、Windowsの復元、更新、既定設定変更も合わせて確認してもらうため
2011年発行のMicrosoft証明書は、2026年6月24日、6月27日、10月19日に順次期限を迎えます。
Microsoftは2023年証明書への更新を進めており、多くの端末ではWindows Update経由で配布されます。
Windows SecurityアプリのDevice security内Secure Bootで、証明書更新の状態を確認します。
Autopatchレポート、Certificate status、trust configuration、Confidence levelを合わせて判断します。
期限切れを即起動不可と読むのではなく、起動時の信頼チェーンを継続して更新できるかを確認します。
- Windows Secure Bootで使われてきた2011年発行のMicrosoft証明書は、2026年6月24日、6月27日、10月19日に順次期限を迎えます。確認対象は、KEK、DB、Windows boot loader、サードパーティboot loaderやOption ROMに関わる証明書です。
- Microsoftは2023年証明書への更新を進めており、個人やMicrosoft管理更新の対象端末では多くの場合Windows Update経由で配布されます。Windows Securityアプリには、2026年4月以降、Device security内Secure Bootの状態表示が追加されています。
- 企業管理端末では、Windows AutopatchのSecure Boot status report、Certificate status、Secure Boot trust configuration、Confidence level、再起動後の反映待ち、OEMファームウェア制約を分けて見ます。期限切れを「即起動不可」と読まないことが重要です。
MicrosoftのSecure Boot証明書更新は、Windowsの新機能追加というより、Windows端末が起動時の信頼チェーンを保ち続けるための基盤更新です。対象は一般ユーザーにも関係しますが、実務上の重みが大きいのは、Intune、Windows Autopatch、Configuration Manager、OEMファームウェア、BitLocker、PXEやWinPEを組み合わせている組織です。
2026年6月4日のMicrosoft Tech Community AMAでも、Secure Boot証明書更新、AutopatchやIntuneでの展開、WinPEやPXE、Event ID、OEM BIOSの扱いに質問が集まっています。ただし、本記事で事実として扱うのはMicrosoft SupportとMicrosoft Learnで確認できる内容に限定します。Microsoft Watch JapanはMicrosoftおよび関係会社と提携していない独立サイトです。
2026年に期限を迎えるSecure Boot証明書は何か
- 2026年6月24日
Microsoft Corporation KEK CA 2011は、Microsoft Corporation KEK 2K CA 2023へ更新され、KEKでDBとDBXの更新署名に関わります。
- 2026年6月27日
Microsoft UEFI CA 2011は、Microsoft UEFI CA 2023へ更新され、DBでサードパーティboot loaderとEFI applicationsの署名に関わります。
- 2026年6月27日
Microsoft UEFI CA 2011は、Microsoft Option ROM UEFI CA 2023へ更新され、DBでサードパーティOption ROMの署名に関わります。
- 2026年10月19日
Microsoft Windows Production PCA 2011は、Windows UEFI CA 2023へ更新され、DBでWindows boot loaderの署名に関わります。
古い証明書のままでも通常の起動やWindows Updateが直ちに止まる話ではありませんが、新しい早期ブート保護を受け続けられるかが確認点です。
まず押さえるべき点は、期限を迎えるのがSecure Bootという機能そのものではなく、Secure Bootの信頼判断で使われるMicrosoft証明書だということです。Microsoft SupportのKB5062710では、2011年に発行されたSecure Boot関連証明書が2026年に期限を迎え、2023年証明書へ更新されることが説明されています。
Microsoftは、古い証明書のままでも端末は引き続き起動し、通常のWindows Updateもインストールされると説明しています。一方で、2023年証明書を受け取っていない端末は、Windows Boot Manager、Secure Boot database、revocation list、boot level vulnerability mitigationなど、早期ブート領域の新しい保護を受けられなくなる可能性があります。
2011年証明書と2023年証明書の対応表
KB5062710で示されている主な対応関係は次の通りです。管理者は、単に「2023 CAがあるか」だけでなく、どの証明書がどの場所に入り、何を署名するのかを分けて確認する必要があります。
| 旧証明書 | 期限 | 新証明書 | 保存先 | 用途 |
|---|---|---|---|---|
| Microsoft Corporation KEK CA 2011 | 2026年6月24日 | Microsoft Corporation KEK 2K CA 2023 | KEK | DBとDBXの更新署名 |
| Microsoft Windows Production PCA 2011 | 2026年10月19日 | Windows UEFI CA 2023 | DB | Windows boot loaderの署名 |
| Microsoft UEFI CA 2011 | 2026年6月27日 | Microsoft UEFI CA 2023 | DB | サードパーティboot loaderとEFI applicationsの署名 |
| Microsoft UEFI CA 2011 | 2026年6月27日 | Microsoft Option ROM UEFI CA 2023 | DB | サードパーティOption ROMの署名 |
根拠として見る場所
この表はMicrosoft Supportの「Windows Secure Boot certificate expiration and CA updates」にある証明書一覧をもとにしています。同ページの変更履歴では、2026年5月18日に証明書表へ日付の「日」が追加されたことも示されています。日付が近い更新なので、展開計画や社内資料に転記する場合は、記事の公開後も元ページで再確認するのが安全です。
期限切れ後に起きることと、起きないこと
ここを誤ると、必要以上に不安をあおる記事になります。Microsoftの説明では、2023年証明書を受け取っていない端末でも、期限日を迎えた瞬間にWindowsが起動しなくなる、通常のWindows Updateが全部止まる、とはされていません。
問題は、早期ブート領域の保護を将来にわたって更新できるかどうかです。たとえば、Windows Boot Managerの更新、Secure Boot databaseや失効リストの更新、新たに見つかったboot level vulnerabilityへの緩和策などは、古い証明書のままでは受けられなくなる可能性があります。BitLocker hardeningやサードパーティbootloaderなど、Secure Bootの信頼に依存するシナリオにも時間差で影響が出る可能性があります。
注意点
「2026年6月でWindowsが使えなくなる」と読むのは行き過ぎです。正確には、2011年証明書の期限が始まり、2023年証明書を受け取っていない端末では、Secure Bootまわりの新しい保護と互換性に制約が出る可能性がある、という話です。
2023 CA更新はどこに入るのか
- 1UEFI firmware
起動前のコードを信頼できるかどうかをSecure Bootの情報で判断します。
- 2KEK
DBとDBXを更新するための署名に関わり、Microsoft Corporation KEK 2K CA 2023が入ります。
- 3DB
信頼する署名や証明書を保持し、Windows UEFI CA 2023、Microsoft UEFI CA 2023、Microsoft Option ROM UEFI CA 2023が関係します。
- 4DBX
失効した署名や既知の危険なイメージを拒否するためのリストです。
- 5端末構成
Microsoft署名だけを信頼する端末と、サードパーティboot loaderやOption ROMも使う端末では確認範囲が変わります。
Windows boot loaderだけを見る場合と、サードパーティboot loaderやOption ROMを含める場合で、確認すべき2023証明書が異なります。
Secure Bootは、UEFI firmwareが起動前のコードを信頼できるかどうかを判断する仕組みです。Microsoft Supportの説明では、PK、KEK、DB、DBXという階層で信頼を管理します。この記事では細かな仕様まで踏み込みませんが、更新判断に必要な用語だけは押さえておきます。
KEK、DB、DBXを最小限の言葉で整理する
KEKはKey Enrollment Keyで、DBとDBXを更新するための署名に関わります。DBはAllowed Signature Databaseで、起動前に信頼する署名や証明書を保持します。DBXはDisallowed Signature Databaseで、失効した署名や既知の危険なイメージを拒否するためのリストです。
今回の更新では、Microsoft Corporation KEK 2K CA 2023がKEKに入り、Windows UEFI CA 2023やMicrosoft UEFI CA 2023、Microsoft Option ROM UEFI CA 2023がDBに入る、という見方になります。Windows boot loaderだけを見るならWindows UEFI CA 2023が中心ですが、サードパーティboot loaderやOption ROMがある環境では、DBに入る他の2023証明書も関係します。
根拠
用語と期限の根拠はMicrosoft SupportのKB5062710です。OEMや新しいWindows 11デバイスの構成要件については、Microsoft Learnの「Windows Secure Boot Key Creation and Management Guidance」が補助情報になります。同ガイダンスでは、Windows 11 version 25H2以降のプリロード端末向けに、Microsoft Corporation KEK 2K CA 2023、Windows UEFI CA 2023、最新DBX packageを含む構成が示されています。
Microsoft署名だけを信頼する端末と、サードパーティも信頼する端末
Windows AutopatchのSecure Boot status reportでは、Secure Boot trust configurationという列が用意されています。これは、端末がMicrosoft署名コンポーネントだけを信頼する構成なのか、Microsoft以外のfirmware componentsも信頼する構成なのかを判断するための情報です。
Microsoft署名だけを信頼する端末では、非Microsoft firmware components向けの証明書がなくても、端末のboot configurationとしては更新済みと見なされる場合があります。逆に、Linuxとの併用、サードパーティboot loader、特殊なOption ROM、業務用周辺機器などが関係する端末では、DB内のMicrosoft UEFI CA 2023やMicrosoft Option ROM UEFI CA 2023を含めて見る必要があります。
確認項目
管理者は、機種名だけで一律に判断しない方がよいです。同じメーカー、同じOSバージョンでも、firmware trust configuration、周辺機器、ブート構成、仮想化基盤、起動メディアの使い方によって必要な証明書の見方が変わります。Microsoft LearnのAutopatchレポート説明でも、証明書の有無だけではなく、端末のアクティブなtrust configurationを考慮する必要があるとされています。
Windowsの端末側の変化を大きな文脈で追うなら、Build 2026でのWindowsプラットフォーム更新を整理したWindowsはBuild 2026でAIエージェント開発基盤へも参考になります。今回の記事はAI機能ではなく、同じWindows端末基盤のセキュリティ更新を扱っています。
個人ユーザーはWindows Securityアプリで何を見るか
追加対応は不要です。
Windows Updateを適用し、再起動要求があれば再起動します。
Microsoftとパートナーの解決を待ち、解決後の自動再開を確認します。
公式案内を確認し、追加検証が必要かを見ます。
自動更新できない場合は、デバイスメーカーの情報を確認します。
公式案内を確認し、メーカーまたは管理者判断へ進みます。
Secure Bootが無効という警告と、Secure Boot証明書更新の警告は同じではありません。表示文を分けて読みます。
個人ユーザーや小規模事業者は、最初にWindows Securityアプリを見ます。Microsoft SupportのKB5087130では、2026年4月以降、Windows SecurityアプリがSecure Boot certificate updatesの追加情報を表示すると説明されています。場所はWindows SecurityのDevice security内にあるSecure Bootです。
表示場所と対象時期
Windows Securityアプリでは、Secure Bootのアイコンに緑、黄、赤のバッジが付き、状態に応じた説明文が表示されます。以前はSecure Bootが有効か無効かを中心に表示していましたが、現在は証明書更新の状態も反映されます。
ただし、緑のチェックマークだけで「2023証明書が適用済み」と判断しない方がよいです。Microsoftは、証明書更新が完了している場合の文言として、必要なSecure Boot certificate updatesがすべて適用済みで、追加の証明書変更が不要であることを確認する説明文を示しています。アイコンと本文の両方を見るのが安全です。
根拠
KB5087130では、2026年4月からSecure Boot certificate update statusがWindows Securityアプリに表示され、2026年5月からは追加の通知やアプリ内ガイダンスが拡充されると説明されています。公式スクリーンショットはMicrosoft Support側で確認できますが、本記事では転載せず、状態の意味だけを整理します。
表示メッセージ別の行動
Windows Securityアプリの表示は、読者の行動に置き換えると次のように読めます。
| 状態の要約 | 読者の行動 |
|---|---|
| 必要な証明書更新が適用済み | 追加対応は不要 |
| 古いboot trust configurationを使用中 | Windows Updateを適用し、再起動要求があれば再起動する |
| 既知問題により更新が一時停止 | Microsoftとパートナーの解決を待つ。更新は解決後に自動再開される扱い |
| 自動更新に必要な分類データが不足 | 公式案内を確認し、追加検証が必要かを見る |
| ハードウェアまたはファームウェア制約で自動更新不可 | デバイスメーカーに確認する |
| 期限後も古い証明書のまま | 公式案内を確認し、メーカーまたは管理者判断へ進む |
多くの個人用端末では、Windows Update経由で更新されます。Microsoft管理更新の対象となるWindows 10またはWindows 11のHome、Pro、Education端末で、自動更新を受け取っている場合、Microsoftは多くのユーザーに追加対応は不要と説明しています。必要なのは、サポート対象のWindowsを使うこと、Windows Updateを止めないこと、Secure Bootが有効であることです。
Windows 10利用者の注意点
Microsoft SupportのMicrosoft管理更新向けページでは、Windows 10のサポートが2025年10月14日に終了したことにも触れています。Windows 10でセキュリティ更新を受け続けるには、Windows 10 Extended Security Updates Programなどの条件を確認する必要があります。Secure Boot証明書更新だけを切り出して「Windows 10でも何もしなくてよい」とは読まない方が安全です。
Secure Bootの警告と証明書更新の警告を混同しない
Secure Boot欄には、証明書更新以外の状態も表示されます。たとえばSecure Bootがオフになっている場合の警告は、証明書期限とは別の問題です。黄色や赤の表示を見たら、まず本文を読み、証明書更新なのか、Secure Boot無効化なのか、ハードウェアまたはファームウェア制約なのかを分けてください。
家庭や小規模事業者の最小手順
難しい確認を始める前に、Windows Updateを最新にする、再起動を完了する、Windows SecurityアプリのDevice security内Secure Bootを確認する、メーカー提供のBIOSまたはUEFI firmware更新がないか見る。この順番で十分なケースが多いです。手動でSecure Bootの鍵を入れ替える作業は、公式案内やメーカー案内なしに行うべきではありません。
組織管理デバイスはAutopatchレポートでどう分けるか
UnknownやNot applicableは、ただちに失敗とは限りません。診断データ、再起動、反映待ち、非アクティブ端末を確認します。
組織管理デバイスでは、個々のユーザーにWindows Securityアプリの警告を見てもらうだけでは運用できません。Microsoft Learnの「Secure Boot status report in Windows Autopatch」では、Windows Autopatch管理デバイスのSecure Boot postureを確認するレポートが説明されています。
レポートは、Intune admin centerからReports、Windows Autopatch、Windows quality updates、Reports tab、Secure Boot statusの順に確認します。ここで見るべき問いは、Secure Bootが有効か、Secure Boot有効デバイスの証明書は最新か、更新が必要な端末はどれか、の3つです。
Secure Boot enabledとCertificate statusを先に見る
Autopatchレポートでは、まずSecure Boot enabledを見ます。Secure Bootが有効な端末で証明書更新の状態を見るのが基本です。Certificate statusには、証明書がUp to dateか、Not up to dateか、Not applicableかといった状態が表示されます。
ただし、Certificate statusだけで終わらせないでください。Secure Boot trust configurationも合わせて見ます。Microsoft署名だけを信頼する端末では、非Microsoft firmware componentsに関する証明書が適用対象外になることがあります。証明書の存在だけを機械的に比較すると、更新済み端末を未更新と誤判定する可能性があります。
評価基準
Up to dateであれば、レポート上は追加対応不要です。Not up to dateであれば、2023 certificatesへの更新が必要な候補として扱います。UnknownやNot applicableは、ただちに失敗とは限りません。診断データ、更新後の再起動、レポート反映待ち、非アクティブ端末を確認します。
Confidence levelで自動展開と手動展開を分ける
AutopatchレポートにはConfidence levelも表示されます。これは、Microsoftが同種の端末やfirmware構成で観測した結果をもとに、Secure Boot certificate updatesを安全に適用できるかを示す分類です。
| Confidence level | 管理者の読み方 |
|---|---|
| High confidence | Microsoftが同種デバイスで更新成功を観測している分類。自動展開の候補 |
| High confidenceかつ自動展開ポリシーでブロック | 端末分類は高信頼でも、管理者側で手動展開が必要 |
| Under Observation – More Data Needed | まだ高信頼に分類するだけのデータが足りない。検証や段階展開の候補 |
| No Data Observed – Action Required | Microsoftがそのデバイス種別を観測できていない。管理者のテストと展開計画が必要 |
| Temporarily Paused | 既知問題のため一時停止。OEM firmwareやMicrosoft guidanceを確認 |
| Not Supported – Known Limitation | 自動更新パスに対応しない制約。例外として文書化する対象 |
High confidenceでも、High confidence deployment policyが自動展開を許可していなければ、手動展開が必要です。逆に、Under ObservationやNo Data Observedは、必ず危険という意味ではありません。まだ自動で安全と判定する材料が足りない状態として読みます。
レポート反映の待ち時間
Microsoft Learnでは、Secure Boot certificatesが更新され、端末が再起動した後、Secure Boot status reportに反映されるまで最大12時間かかる場合があると説明されています。また、必要なWindows diagnostic dataが送信されていない端末はUnknownやNot applicableに見える可能性があります。28日を超えて非アクティブな端末も、最近のSecure Boot診断データがないためUnknownになることがあります。
IntuneやEntra IDを含む管理対象デバイスの大きな文脈は、Project SolaraはBuild 2026で初公開でも整理しています。今回のSecure Boot更新はAIエージェント端末の話ではありませんが、IntuneやEntra IDで端末をどう管理対象として見るか、という運用視点は近いものがあります。
IT管理デバイスの展開判断とレジストリキー
- 1対象端末を分ける
Microsoft管理更新を待てる端末と、管理者が明示的に展開を制御する端末を分けます。
- 2MicrosoftUpdateManagedOptIn
Microsoftによる自動展開へ明示的に参加する設定で、既定ではopt outとして扱われます。
- 3HighConfidenceOptOut
高信頼デバイスに対する自動更新を拒否する設定で、キーがない、または0の場合はopt in、1の場合はopt outです。
- 4AvailableUpdates
Secure Boot update actionsを制御するbitfieldで、企業展開では0x5944が必要な証明書追加、KEK更新、boot manager更新に関わります。
- 5Scheduled taskと再起動
Secure-Boot-Update scheduled taskと再起動後の反映を確認します。
- 6パイロット検証
ファームウェア制約、BitLocker recovery、WinPEやPXE、特殊なboot configurationを考慮して段階展開します。
レジストリキーは管理者操作に直結します。実際の変更は公式手順、変更管理、バックアップ、BitLocker recovery key、OEM firmware情報を確認してから行います。
IT管理下のWindows端末では、Microsoft管理更新の自動展開を待つだけでよい端末と、管理者が明示的に展開を制御する端末が分かれます。ここで焦って全端末へ一括適用すると、ファームウェア制約、BitLocker recovery、WinPEやPXE、特殊なboot configurationで詰まる可能性があります。
展開支援のopt inとopt out
Microsoft SupportのKB5068202では、IT管理デバイス向けにSecure Boot update関連のレジストリキーが説明されています。AvailableUpdatesは、Secure Boot update actionsを制御するbitfieldで、企業展開では0x5944を設定することで、必要な証明書の追加、KEK更新、PCA2023署名のboot manager更新を実行する値として説明されています。
同じページでは、HighConfidenceOptOutとMicrosoftUpdateManagedOptInも説明されています。HighConfidenceOptOutは、高信頼デバイスに対する自動更新を拒否するための設定です。キーがない、または0の場合はopt in、1の場合はopt outという扱いです。MicrosoftUpdateManagedOptInは、Microsoftによる自動展開へ明示的に参加する設定で、既定ではopt outです。利用には、公式ガイドで示される診断データ要件も確認します。
根拠
レジストリキーは管理者操作に直結します。この記事では値の意味を紹介するだけに留め、実際のコマンド実行はKB5068202の最新手順、組織の変更管理、対象端末のバックアップ、BitLocker recovery key、OEM firmware情報を確認してから行ってください。AvailableUpdatesPolicyはGroup PolicyやIntuneがWindowsへSecure Boot関連アクションを伝えるための参照キーであり、レジストリから直接更新しないものとして説明されています。
Secure-Boot-Update scheduled taskと再起動を見る
Autopatchレポートの追加要件では、Secure-Boot-Update scheduled taskがSecure Boot certificate updatesの適用に必要とされています。このタスクが無効または削除されていると、証明書更新は進まず、端末は古い、または不完全な状態を報告し続ける可能性があります。
KB5068202では、タスクが通常12時間ごとに処理を実行すること、boot manager更新は再起動後になる場合があること、展開開始自体が再起動を強制するものではないことも説明されています。管理者は、更新を開始した時点、再起動が完了した時点、レポート反映が完了した時点を分けて記録した方がよいです。
パイロットの条件
代表機種、firmware version、Secure Boot trust configuration、BitLockerの状態、PXEやWinPE利用、仮想マシン、特殊な周辺機器を含む端末を先に抽出します。2026年6月4日のMicrosoft Tech Community AMAでも、WinPE、PXE、Event ID 1796、OEM BIOS、AVD、Surface Hubなどの質問が見られます。ただし、この記事ではAMAを需要シグナルとして扱い、具体的な対処手順はMicrosoft SupportまたはMicrosoft Learnで確認できる範囲に限定します。
管理者向けチェックリスト
UnknownやNot applicableが多い場合は、更新失敗の前に診断データ未送信、再起動待ち、反映待ち、非アクティブ状態を確認します。
管理者が最初に作るべきものは、端末ごとの結論ではなく、判断に必要な列を持った台帳です。Secure Boot証明書更新は、OS更新、firmware、診断データ、再起動、Autopatch分類、ポリシー設定が絡みます。1つの列だけで判定しない構造にします。
端末側で確認する項目
| 確認項目 | 見る場所 | 問題があるときの次の行動 | 根拠 |
|---|---|---|---|
| Secure Bootが有効か | Windows Security、System Information、管理ツール | 無効なら証明書更新以前の問題としてメーカー手順を確認 | KB5087130、KB5062711 |
| Windows Updateが最新か | Windows Update、更新管理ツール | 更新停止、再起動待ち、ポリシー停止を確認 | KB5062711 |
| Windows SecurityのSecure Boot表示 | Device security内Secure Boot | 状態文を読み、証明書更新か別のSecure Boot警告かを分ける | KB5087130 |
| 2023証明書が必要な構成か | Autopatch、firmware trust configuration、台帳 | Microsoft onlyかMicrosoft and non-Microsoftかを分ける | Autopatch Learn |
| OEM firmware更新の有無 | メーカー配布情報、管理ツール | ハードウェアまたはファームウェア制約ならメーカー確認 | KB5087130、Autopatch Learn |
個人ユーザー向けの簡易確認
個人利用では、まずサポート対象のWindowsを使っているか、Windows Updateが止まっていないか、Secure Bootが有効かを確認します。Windows Securityアプリの表示が「必要な証明書更新が適用済み」を示していれば追加対応は不要です。黄色や赤の表示が出る場合は、公式案内やメーカー案内を確認します。
管理コンソールで確認する項目
| 確認項目 | 見る列または設定 | 判断 |
|---|---|---|
| 対象端末 | Device name、Microsoft Entra device ID、Device model | 台帳と突合する |
| OSと更新状態 | OS version、Date last reported | 古いOSや長期非アクティブを切り分ける |
| Secure Boot有効化 | Secure Boot enabled | 無効端末は証明書更新の対象判定から分ける |
| 証明書状態 | Certificate status | Up to date、Not up to date、Unknownを分類する |
| 信頼構成 | Secure Boot trust configuration | Microsoft onlyかMicrosoft and non-Microsoftかを見る |
| 展開判断 | Confidence level、policy設定 | 自動展開、手動展開、観測待ち、例外を分ける |
評価基準
UnknownやNot applicableが出たら、すぐ失敗扱いにしないでください。更新と再起動後に最大12時間の反映待ちがあり、必須診断データや非アクティブ状態も関係します。Not up to dateの端末は優先して見ますが、trust configurationやConfidence levelも合わせて判断します。
誤解しやすいポイント
古い証明書のままでも端末は起動し、通常のWindows Updateも続くと説明されています。
新たな早期ブート保護やSecure Boot関連更新を継続的に受けられるかが問題です。
Microsoft署名だけを信頼する端末と、サードパーティboot loaderやOption ROMを使う端末では確認範囲が違います。
診断データ未送信、再起動待ち、反映待ち、28日超の非アクティブ端末が原因の場合があります。
Windows Securityの表示とAutopatchレポートは、対象読者と判断目的が異なります。
家庭用端末と企業管理端末では、見るべき場所と責任範囲が違います。条件を分けて確認します。
Secure Boot証明書更新は、見出しだけで読むと過剰に怖く見えます。反対に、自動更新されるから完全に放置してよいと読むのも危険です。家庭用端末と企業管理端末では、見るべき場所と責任範囲が違います。
期限切れは即停止ではない
期限日を迎えたらWindowsが即座に起動しなくなる、という話ではありません。Microsoftの一次情報では、古い証明書のままでも端末は起動し、通常のWindows Updateも続くと説明されています。問題は、新たな早期ブート保護やSecure Boot関連更新を継続的に受けられるかどうかです。
ただし軽視もしない
早期ブート領域は、OSが完全に立ち上がる前の保護に関わります。bootkitやboot level vulnerabilityへの対策、Windows Boot Manager、Secure Boot database、revocation listの更新が関係するため、単なる表示上の警告として放置するのはよくありません。
更新済みかどうかは端末構成で見方が変わる
「この証明書がないから未更新」とだけ判定すると、端末構成によっては誤判定になります。Autopatchの説明では、Secure Boot certificate readinessはdevice manufacturerだけではなく、firmware trust configurationで評価されます。Microsoft署名だけを信頼する端末と、Microsoft以外のfirmware componentsも信頼する端末では、必要な証明書の範囲が変わります。
下振れ
レポートでUnknownやNot applicableが多い場合、更新失敗ではなく、診断データ未送信、再起動待ち、反映待ち、28日超の非アクティブ端末が原因かもしれません。まずレポート条件を確認し、その後に更新失敗やファームウェア制約を疑います。
管理者通知とユーザー通知は同じではない
Windows Securityアプリの証明書状態表示は、家庭用や小規模利用では便利です。一方、企業管理のWindows 10、Windows 11 client devices、Windows Serverでは、Secure Boot証明書更新インジケーターが既定で無効化される扱いが示されています。Microsoftは、IT管理者が中央管理する前提で、HideSecureBootStatesというポリシーも説明しています。
運用上の判断
全社員のWindows Securityアプリに警告を出すか、管理者側のAutopatchやIntuneレポートで集約して判断するかは、組織の運用次第です。セキュリティ更新の話なので、ユーザー通知を増やす前に、ヘルプデスクの案内、BitLocker recovery keyの確認、OEM firmware配布方針、例外端末の扱いを決めておく方が実務的です。
次に読むなら
参照した主な情報源
- Microsoft Support, "Windows Secure Boot certificate expiration and CA updates"（確認日: 2026年6月10日JST）
https://support.microsoft.com/en-us/topic/windows-secure-boot-certificate-expiration-and-ca-updates-7ff40d33-95dc-4c3c-8725-a9b95457578e
- Microsoft Support, "Secure Boot certificate update status in the Windows Security app"（確認日: 2026年6月10日JST）
https://support.microsoft.com/en-us/topic/secure-boot-certificate-update-status-in-the-windows-security-app-5ce39986-7dd2-4852-8c21-ef30dd04f046
- Microsoft Learn, "Secure Boot status report in Windows Autopatch"（確認日: 2026年6月10日JST）
https://learn.microsoft.com/en-us/windows/deployment/windows-autopatch/monitor/secure-boot-status-report
- Microsoft Support, "Windows devices for home users, businesses, and schools with Microsoft-managed updates"（確認日: 2026年6月10日JST）
https://support.microsoft.com/en-us/topic/windows-devices-for-home-users-businesses-and-schools-with-microsoft-managed-updates-29bfd847-5855-49f1-bb94-e18497fe2315
- Microsoft Support, "Registry key updates for Secure Boot: Windows devices with IT-managed updates"（確認日: 2026年6月10日JST）
https://support.microsoft.com/en-us/topic/registry-key-updates-for-secure-boot-windows-devices-with-it-managed-updates-a7be69c9-4634-42e1-9ca1-df06f43f360d
- Microsoft Learn, "Windows Secure Boot Key Creation and Management Guidance"（確認日: 2026年6月10日JST）
https://learn.microsoft.com/en-us/windows-hardware/manufacture/desktop/windows-secure-boot-key-creation-and-management-guidance?view=windows-11
- Microsoft Tech Community, "Ask Microsoft Anything: Secure Boot – June 4, 2026"（需要シグナルとして確認、確認日: 2026年6月10日JST）
https://techcommunity.microsoft.com/event/windowsevents/ask-microsoft-anything-secure-boot—june-2026/4522056
更新履歴: 2026年6月10日JSTに初稿を作成。Microsoft SupportのKB5062710、KB5087130、KB5062711、KB5068202、Microsoft LearnのWindows Autopatch Secure Boot status report、Windows Secure Boot Key Creation and Management Guidanceを確認しました。Microsoft Tech Community AMAは需要シグナルとしてのみ扱い、本文の事実認定には使っていません。