2026年6月24日、Microsoftのオリジナルの Secure Boot 証明書のうち Microsoft Corporation KEK CA 2011 が期限切れとなった。
続いて Microsoft Corporation UEFI CA 2011 が6月27日に、Microsoft Windows Production PCA 2011 が10月19日に期限を迎える。これらは Windows 8 以降に出荷された UEFI 対応 PC のブートトラストを支えてきた証明書であり、影響は世界で10億台を超えるデバイスに及ぶ。対象は Windows 10、Windows 11、Windows Server 2012 から2025、約2012年以降のハードウェアに加え、Microsoft UEFI CA 2011 で shim に署名する Ubuntu、Fedora、Debian、RHEL などの Linux ディストリビューションを含む。後継の2023年版証明書は2038年まで有効である。修復には、2024年より前に製造されたデバイスへの OEM ファームウェア更新と、月例累積更新による Windows 証明書更新の2段階が必要となる。2025年以降に出荷された Copilot+ PC などは対応不要だ。
From: Windows Secure Boot Certificate Expired — Billions of PCs Affected Including Linux Distros
【編集部解説】
まず、この話題を innovaTopia がいま取り上げる理由からお伝えします。2026年6月という時期は、2011年に発行された Microsoft の Secure Boot 証明書が次々と有効期限を迎える、まさにその真っ只中だからです。私たちが日々押している電源ボタンの奥で、PC が「信頼してよいソフトウェアか」を判定する仕組みが、15年ぶりに世代交代しています。普段は意識されない領域であるからこそ、何が起きているのかを正確に知っておく価値があります。
そもそも Secure Boot とは何か、を一段かみ砕いておきましょう。Secure Boot は UEFI ファームウェアと連携し、認証局（CA）と呼ばれる暗号鍵を使って、ファームウェアの各モジュールが信頼できる発行元から来たものかを検証する仕組みです。これにより、Windows の起動シーケンスのごく初期段階でマルウェアが実行されるのを防ぎます。今回期限を迎えるのは、この検証の土台を担ってきた2011年版の鍵にほかなりません。
ここで、ぜひ落ち着いて受け止めていただきたい最重要ポイントがあります。「失効」は「取り消し」ではない、ということです。元記事や一部の海外メディアは「数十億台が影響を受ける」「起動不能のリスク」と強い見出しを掲げていますが、実態はもう少し冷静です。証明書の失効は取り消しではなく、すでにファームウェアが信頼している鍵はそのまま信頼され続けるため、今朝 Linux が起動するマシンは明日も起動します。失効が止めるのは、Microsoft が古い2011年版で新しい起動コンポーネントに署名できなくなることです。Fedora プロジェクトが公式記事のタイトルを「Don’t Panic（慌てるな）」とした理由が、ここにあります。
なお、一部には「UEFI 仕様上、有効期限外の署名は拒否される」との指摘もあります。しかし Fedora は、大半のシステムが証明書の期限切れをチェックしないため影響を受けないことを実機で確認しており、Red Hat も、2011年版の証明書がすでに登録済みのシステムは2026年6月27日以降も起動し続けると明言しています。現実の挙動としては起動が継続するというのが、OS ベンダー側の一致した見解です。
では、何が本当に問題になるのか。困りごとは「今日」ではなく「これから」に現れます。新規 OS インストールでは、2023年版の証明書で署名されたディストリビューションを、2011年版の鍵しか知らないファームウェアが信頼できず、Secure Boot 有効の状態ではインストーラーが起動しません。そして将来のセキュリティ更新では、配布元が2023年版で署名した shim を出し始めると、2023年版の鍵を持たないファームウェアはそれを受け付けなくなり、起動レベルの修正から取り残されていきます。つまり真の脅威は派手な「文鎮化」ではなく、静かに進む「セキュリティ負債の蓄積」なのです。
数字についても確認が必要です。元記事は影響範囲を「10億台超」とし、対象を Windows 8 以降のほぼ全 UEFI 機としていますが、ここはやや広めに捉えた表現といえます。実際には、2023年版の証明書を持つデバイスは追加対応が不要であり、2024年以降に製造された多くの Windows PC はすでに2023年版を搭載済みです。「10億台が危機」ではなく「10億台規模の母集団のうち、古い世代が順次移行を要する」という理解が正確でしょう。
Linux 側の最新状況は、元記事の刊行後にさらに前進しています。元記事は「新しい shim は2023年版でのみ署名される」と書きましたが、現時点の主要ディストリビューションは賢い回避策をとっています。Red Hat は2011年版と2023年版の両方で署名した「デュアル署名」の shim を、RHEL 9 と RHEL 10 には5月、RHEL 8 には6月に提供しました。この単一バイナリは、どちらの証明書が登録されているマシンでも起動します。Ubuntu、Debian、Fedora も同様に更新済みの shim を配布しており、「日付を過ぎた瞬間に Linux が一斉に死ぬ」という煽りは、技術的な実態とずれています。
一方で、楽観だけでは済まない領域も明確です。本当に注意すべきは、ベンダーがファームウェア更新をもう出さない、古く・サポート切れ・放置された機材です。ファームウェア更新の実績は、とくに民生機やレガシーな業務機で芳しくないことで知られています。さらに、人知れず長期間動き続ける組み込み機器や IoT デバイス —— Windows ベースのキオスク端末やデジタルサイネージなど —— も同じリスクを負います。皮肉なことに、最も更新されにくい場所こそ、最も長く稼働し続けるのです。
サーバー領域には、もう一段の注意が要ります。Windows Server は PC と異なり、制御された機能ロールアウト（CFR）を通じた自動配信の対象外であり、管理者が手動で更新を実行する必要があります。利用者が意識せずとも更新が進む Windows PC とは前提が異なり、「放置されない運用」がそのまま安全性を左右する点に、サーバー管理者は留意すべきでしょう。
セキュリティの観点から、今回の移行には前向きな副産物もあります。2011年版のもう一つの役割だった、GPU や NIC などのサードパーティ製オプション ROM への署名が、独立した2023年版の証明書へと分離されます。これは実際のセキュリティ改善であり、任意のハードウェア用オプション ROM を信頼することなく、Linux の shim だけを信頼できるようになります。信頼の粒度を細かく制御できる設計へ進化した、と捉えられます。
最後に、長期的な視点を一つ。今回の騒動が浮き彫りにしたのは、長寿命な組み込みシステムにおける「証明書という信頼の土台」のもろさです。将来の UEFI Secure Boot の実装は、複数の CA を重ねて持たせる方式や、証明書の自動更新の仕組みを取り入れ、同じ事態の再発を避ける可能性があります。15年に一度しか訪れないこの世代交代は、私たちが「信頼をどう設計し、どう引き継ぐか」という、デジタル社会の根源的な問いを静かに突きつけているのです。
【用語解説】
Secure Boot（セキュアブート）
UEFI ファームウェアに搭載された安全機能であり、PC の電源投入から OS が立ち上がるまでの間に、信頼された（署名された）ソフトウェアだけが実行されるよう検証する仕組みである。Windows 8 で初めて導入された。
UEFI（ユーフィ）
従来の BIOS に代わる、現代の PC のファームウェア規格。ハードウェアと OS の橋渡しを担い、Secure Boot の鍵のデータベースもこの中に格納される。
証明書（CA：認証局）
ソフトウェアの署名が「信頼できる発行元のものか」を保証する電子的な身分証のようなもの。Secure Boot では、この証明書を使ってブートローダーなどの正当性を検証する。有効期限が設けられている。
ブートトラスト（信頼の連鎖／トラストチェーン）
電源投入時に、ファームウェア → ブートローダー → OS という順で、各段階が一つ前の段階を暗号的に検証していく仕組み。鎖のように信頼をつないでいくため、こう呼ばれる。
PK／KEK／DB／DBX
Secure Boot の鍵の階層を構成する4要素。PK（プラットフォームキー）が最上位で KEK（キー登録鍵）を認可し、KEK が DB（許可署名データベース＝信頼する署名の一覧）と DBX（禁止署名データベース＝拒否する署名の一覧）の更新に署名する。
ブートローダー
OS 本体を起動するための、最初に読み込まれる小さなプログラム。Windows では「ブートマネージャー」がこれにあたる。
shim（シム）
Linux が Secure Boot 環境で起動するための「第一段階ブートローダー」。Microsoft が署名することで、Linux であっても Secure Boot を有効にしたまま起動できる仕組みを成立させている。
デュアル署名
一つのファイルに2011年版と2023年版という2つの証明書で署名する手法。どちらの証明書を持つマシンでも起動できるため、移行期の互換性を保つ目的で採用されている。
ブートキット／ルートキット
OS が起動するより前の段階に潜り込み、システムの深部を乗っ取る悪質なマルウェア。検出や駆除が極めて困難で、Secure Boot の DBX 失効リストは、まさにこれを起動段階でブロックするために存在する。
ファームウェアアップデート（BIOS/UEFI 更新）
マザーボードに組み込まれた基本ソフトを書き換える更新。今回の件では、古い機種が2023年版の証明書を受け入れられるようにするために必要となる。
CFR（制御された機能ロールアウト）
Microsoft が Windows の機能や更新を段階的に配信する仕組み。今回、Windows PC はこの対象だが、Windows Server は対象外であり、管理者の手動対応を要する点が異なる。
fwupd／LVFS（Linux Vendor Firmware Service）
Linux 環境でファームウェア更新を安全に配信・適用するためのサービスと、その実行ツール。今回の Linux 側の対応では、これを通じて新しい証明書を登録するのが推奨される方法である。
mokutil（モックユーティル）
Linux で Secure Boot の状態や登録済み証明書を確認・操作するためのコマンドラインツール。
【参考リンク】
Windows Secure Boot certificate expiration and CA updates – Microsoft Support（外部）
今回の証明書更新に関する Microsoft の総合案内ページ。証明書一覧や利用者が取るべき対応をまとめた一次情報の起点である。
Update Secure Boot Certificates for Windows Devices – Microsoft Learn（外部）
未更新時に何が起こるかを含め、Windows デバイスの更新手順と状態確認の方法を技術者向けに解説した公式ドキュメントである。
Secure Boot Certificate Changes in 2026: Guidance for RHEL Environments – Red Hat（外部）
Red Hat による RHEL 環境向けの公式ガイド。デュアル署名 shim の配布時期や、既存システムは起動し続ける点を明確に説明している。
What you need to know about the Microsoft Secure Boot certificate expiration: Don’t Panic! – Fedora Magazine（外部）
Fedora 公式メディアの解説記事。失効と取り消しの違いや確認用コマンドを、冷静かつ実務的に示した内容である。
Secure Boot Transition FAQ – Dell（外部）
Dell による移行 FAQ。失効後も PC は起動する点や、2024年以降は両証明書を出荷している点など、利用者目線の疑問に答えている。
HP Business PCs – Prepare for new Windows Secure Boot certificates – HP Support（外部）
HP による法人向け案内。4枚の新証明書の役割や、自動更新される証明書とそうでない証明書の区別を整理している。
【参考記事】
Secure Boot certificate changes in 2026: Guidance for RHEL environments – Red Hat Developer（外部）
デュアル署名 shim を RHEL 9・10 には5月、RHEL 8 には6月に提供と説明。どちらの証明書でも起動でき、失効が既存システムを壊さないと整理する。
Secure Boot Transition FAQ – Dell（外部）
2011年版は2026年6月から順次失効し2023年版へ置換と説明。失効後も起動するが将来更新は不可、Dell は2024年後半から両証明書を出荷と明示する。
What you need to know about the Microsoft Secure Boot certificate expiration: Don’t Panic! – Fedora Magazine（外部）
鍵が失効しても削除や DBX 取り消しがない限り起動は継続すると明言。大半のシステムは期限切れをチェックしないことも実機で確認している。
Prepare your servers for Secure Boot certificate updates – Microsoft Windows Server Blog（外部）
Windows Server は PC と異なり CFR 自動配信の対象外で、管理者の手動更新が必要と明示。2025年出荷のサーバー多くは2023年版を搭載済みとする。
Secure Boot Linux 2026: Microsoft’s Key Expires June 27 – LinuxTeck（外部）
失効は新規署名を止めるが既存鍵での起動は止めないと明快に解説。オプション ROM 署名の分離を改善と評価し、真の懸念は古い機材だと指摘する。
Countdown to June 2026: Linux Admins Must Replace Microsoft’s Secure Boot Certificate – Windows News（外部）
証明書ベースの信頼の土台のもろさを指摘し、将来の UEFI が複数 CA や自動更新を取り入れる可能性に言及する長期的視点の記事である。
【編集部後記】
証明書の「期限切れ」と聞くと、つい最悪の瞬間を思い描いてしまいます。けれど今回掘り下げてみて、私たち自身があらためて学んだのは、信頼とは一度きりの設定ではなく、誰かが地道に更新し、引き継いでいくことで保たれているという当たり前の事実でした。普段は気にも留めない鍵の世代交代の裏に、Microsoft や各ディストリビューションの開発者たちの静かな準備があります。読者のみなさんがお手元の一台に目を向けるとき、その奥で動いている見えない仕組みへ、少しだけ想像が及ぶきっかけになれば幸いです。