✓この記事でわかること
- 1TPMは鍵の保護や起動状態の測定を支援し、Secure Bootは起動前の署名を確認する
- 2Windows 11の要件にあるSecure Boot対応能力と、UEFIで有効な状態は別である
- 3証明書更新の影響はPCメーカー、UEFI実装、更新状況、BitLocker設定で変わる
Windows 11のインストール要件を確認すると、TPM 2.0やSecure Bootという言葉が出てきます。TPMは暗号鍵や起動状態を扱うためのハードウェア・セキュリティ機能で、Secure BootはPCの電源投入後に読み込むコードの署名を検証する仕組みです。
この2つは関係しますが、同じ機能ではありません。また、「PCがSecure Bootに対応している」「UEFIでSecure Bootが有効になっている」「証明書データベースが最新である」も別の状態です。この記事では、Windows 11の要件と、2026年から期限を迎えるSecure Boot証明書の話を、起動前の仕組みとして整理します。
Windows 11の要件で確認すること
Microsoftの要件では、対応するプロセッサー、メモリ、ストレージなどに加えて、TPM 2.0と、Secure Bootに対応できるUEFIファームウェアが確認項目になります。ここでのポイントは、Secure Bootが「有効になっていること」と、ファームウェアが機能を「サポートできること」を同じ言葉で扱わないことです。 MicrosoftのWindows 11要件
| 確認する状態 | 一つの確認だけでは分からないこと |
|---|---|
| TPM 2.0を利用できる | Secure Bootが有効か、証明書が更新されたか |
| Secure Bootに対応できるUEFI | 現在の有効状態と、2011年証明書の更新状態 |
| Secure Bootが有効 | 2023年証明書への更新が完了したか |
たとえばTPM 2.0を使い、Secure Bootも有効なPCでも、証明書更新状態が未確認なら三つ目の確認は残ります。これは架空の状態例で、対象PCを診断した結果ではありません。
PCが要件を満たしているかを確認するときは、Windowsのシステム情報やPC正常性チェック、UEFI設定、メーカーのサポート情報を組み合わせます。古いPCではTPMが無効になっているだけの場合もありますが、設定を変更する前に、ストレージ暗号化や回復キーの有無を確認してください。
非公式な要件回避を使うと、更新やサポート、セキュリティ機能に影響が出る可能性があります。要件を満たせないPCへ無理にインストールする手順を推奨するのではなく、MicrosoftとPCメーカーの対応状況を確認する方が安全です。
TPMとSecure Bootで確認する役割の違い
TPMは、暗号鍵を保護したり、PCの起動過程で測定された状態を扱ったりするためのセキュリティ部品です。OSや暗号化機能が、鍵を通常のストレージへそのまま置くのではなく、TPMの機能を使って保護する構成があります。
Measured Bootでは、起動時に読み込まれた部品や設定の測定値を記録し、後から起動状態を確認する材料にします。TPM 2.0が搭載されているだけで、すべての攻撃を防いだり、OS全体の安全が保証されたりするわけではありません。OS、UEFI、ドライバー、アカウント、更新を含む全体の構成が必要です。
TPMの設定を初期化したり、マザーボードを交換したりすると、暗号化されたドライブで回復を求められることがあります。TPMの有無の確認と、BitLockerの回復キー管理は別の記事で扱いますが、設定変更前に回復情報の所在を確認することは共通の注意点です。
Secure BootからTrusted Bootへ進む
Secure Bootは、UEFIからWindowsのブートローダーなどを読み込む際、信頼された署名を持つコードか確認します。信頼できない、または失効したコードを起動前に実行しにくくすることで、OSが立ち上がる前の攻撃や改ざんに対抗します。
UEFIには、信頼する署名を登録するデータベースと、実行を拒否する署名を登録する失効データベースがあります。これらの内容、PCメーカーの実装、起動するOSやドライバーの署名によって結果が変わります。
役割を整理する概念図です。Secure BootからOSへ進んだ後のWindows起動部品はTrusted Bootが検証します。図は全PCの実装や診断結果を表すものではありません。
Secure Bootが有効だと、非対応の古いブートローダーやドライバーが起動できず、OSやデバイスが起動しないことがあります。そのため、設定をオン・オフするときは、現在の構成とメーカーの手順を確認します。対応可能なPCでも、UEFIの設定で無効になっていれば、実際の起動時の保護は同じではありません。
2026年の証明書更新で何を確認するか
Microsoft Learnの「Update Secure Boot Certificates for Windows Devices」（2026年5月1日更新、2026年10月4日確認）は、2011年発行の証明書を使う一部の機器で2026年6月に期限を迎えると説明しています。確認時点ではその時期を過ぎています。
未更新でもWindowsの起動と通常更新を続ける場合がある一方、将来の起動前部品へのSecure Boot保護を受け取れない場合があります。古いファームウェアや更新の適用失敗では、検証エラー・BitLocker回復要求・起動失敗が起きる場合もあります。全PCが同じ症状になる説明ではありません。
Event ID 1801やUEFICA2023Statusなどは、同資料が挙げる更新状態の確認材料です。イベント一つから全機器の状態を断定する判定ではありません。Microsoftの証明書更新資料
UEFI設定や起動チェーンが変わると、BitLockerが起動環境の変化を検知し、回復キーの入力を求めることがあります。これはSecure Bootの証明書問題とBitLockerの暗号化問題が同じという意味ではありません。起動の信頼性確認と、ドライブの回復情報確認を分けて行います。
起動できない・回復を求められるときの考え方
設定変更や更新の後に起動できなくなった場合、電源を切って何度も設定を変える前に、画面の表示、対象PCの型番、直前に行った更新やUEFI変更を記録します。メーカーの復旧手順やMicrosoftの公式情報を別の端末で確認し、暗号化ドライブなら回復キーの所在を確認します。
回復キーが見つからない状態で初期化や再インストールを進めると、データへアクセスできなくなる可能性があります。会社や学校のPCでは、管理者が証明書やBitLockerのポリシーを管理しているため、自己判断で変更せず担当者へ相談します。
参考情報
2026年10月4日に要件・役割・証明書更新の本文を確認しました。実機のUEFI変更や回復試験は行っていません。