【重要】このブログのスタンス：速報性と予防効果を最優先する理由（クリックで展開）
当サイトのトップページにも記載していますが、改めて、私たちの情報発信における最も重要なスタンスについてお話しさせてください。
トラブルシューティング手法などの一般記事は十分な精査を行った後に公開していますが、毎月のWindows Updateに関する記事においては「速報性と予防効果を最優先」してお届けしています。
なお、公開内容に錯誤などが含まれていた場合は、速やかに修正や続報の提供を行っています。この点はご了承の上、ご寛容ください。
このサイトではWindows Update情報や、Winの不具合情報などを発信する上で、完全な正確性より、速報性や予防効果に重きを置いているなどいくつかの注意点があります。
これは、単なる免責事項ではありません。読者の皆様のPCを深刻なトラブルから守るために、私たちが最も大切にしている編集方針です。
※ 6分34秒
自分で公開しておいてというところなのですが、この解説動画、少しばかりピンボケかも知れないです。技術的な事柄はなかなか平明な言葉で正確に表現ができません。できれば記事本編をお読みいただければ幸いです。
2026/02/17時点の状況というか「たぶん最終結果」
2026/02/17時点の状況というか「たぶん最終結果」です。
結論としては、「デバイスが新しい証明書なしで有効期限に達した場合でも、OSは一部の例外機能など除いてですが正常に起動して動作します。」という結果になりました。
ただし、MSの真の狙いと姿勢の推察を「重要しかし個人的な意見/見解」セクションで書いていますので、必ずお読みくださるのが良いと思います。
これは、2026/02/10に公開されていたMSサポートページの「Windows デバイスでセキュア ブート証明書の有効期限が切れた場合（元の発行日: 2026 年 2 月 10 日）」をやっと見つけ出せたことで出せた見解です。
しかしながら、これには「一部の例外機能」や「セキュリティリスクの増大」という、無視できない条件が付きます。デバイスは初期ブートプロセスの新しい保護（Windows ブート マネージャーの脆弱性修正など）を受け取れなくなるためです。
追加セクション後半の『重要しかし個人的な意見/見解』のセクションにて、この結論の裏にある「MSの真の狙い」についても考察していますので、ご一読いただけると幸いです。
たぶん最終結果：まとめ
MS公式サイトの情報に基づく解説
Microsoftが公開した最新情報（KB5079373）を、英語原文の内容も含めて噛み砕いて解説します。
（※日本語ページは機械翻訳のため、意味の通りにくい箇所を修正しています）
1. 有効期限が切れるとどうなるか？
新しい証明書への更新が間に合わなかった場合でも、PCの電源を入れ、Windowsが立ち上がることに支障はありません。
日常的なアプリ、ネット閲覧、通常のWindows Updateも引き続き利用可能です。
2. 「機能しなくなること」の真の正体
「起動するなら安心だ」と断言できない理由がここにあります。
ブートレベルの脆弱性修正が停止: 今後、WindowsブートマネージャーやセキュアブートDBに新たな脆弱性が見つかっても、古い証明書のデバイスには修正パッチを適用できなくなります。
新機能の恩恵を受けられない: セキュアブートの信頼性に依存するBitLockerの強化策などが、新しい証明書がないために機能しなくなる可能性があります。
サードパーティ製コンポーネントの影響: 新しい証明書が必要な構成（一部のブートローダー等）に更新した際、証明書が古いと整合性が取れなくなるリスクがあります。
3. ユーザーが取るべき行動
基本は「待ち」でOK: ほとんどの個人用デバイスは、Windows Updateを通じて自動で新しい証明書（2023年版）に更新されます。
OEMサイトの確認: サポート期間内のデバイスであれば、PCメーカー（OEM）から配布されるファームウェア更新に注意してください。
【厳禁】セキュアブートの無効化: 期限切れを回避するためにセキュアブートをオフにすることは、玄関の鍵を外すのと同義です。推奨されません。
重要しかし個人的な意見/見解
「ある意味では大山鳴動して…に近い結果となりました。」とは書いたのですが、実は「この記事を書いてよかったな」と個人的には思っています。
ある意味言い訳じみてはしまうのですが、次のことは再度注意喚起しておきます。
実はこの結果は、以下のように考えるべきものでもあるのです。
- MSはここまでやったよ、そしてこれが今後の方針であり対応だよ
- OSは起動するから他の不都合は感知しないよ、あとは「メーカー/ベンダー/PC利用者本人」で対応してね
- このことでのセキュリティー低下の影響で、切り捨てになっても知らないよ
今回の結果（KB5079373）を、あえて「冷徹な視点」で分析すると以下のようになります。
1. 「OSが起動する」という最大の免責
MSにとっての最優先事項は、2026年6月に数億台のPCが一斉に「起動不能（黒い画面）」になるというPR上の大惨事を避けることでした。 「起動してデスクトップが出る」という最低限の約束さえ守れば、「PCを壊した」という直接的な責任を回避できるからです。
2. 「セキュリティは自己責任」へのフェーズ移行
OSは起動しますが、ブートプロセスの脆弱性保護は「段階的に低下する」と明記されています。 これは「鍵が古くなって最新の泥棒（脆弱性）には対応できないけれど、ドアは開くからいいよね。泥棒に入られても、それは更新しなかった環境のせいだよ」と言っているに等しい状態です。
3. OEM（メーカー）へのボール投げ
「一部のデバイスではOEMによるファームウェア更新が必要」という記述は、「古いPCの面倒を見るのはメーカーの仕事であり、サポートが切れたハードウェアがどうなろうと知ったことではない」という宣言でもあります。 これにより、古いデバイスの「切り捨て」が、MSの責任ではなく「メーカーのサポート期間」の問題へと巧妙にすり替えられています。
4. ユーザーへの「究極の選択」の提示
「保護を維持したいなら、OEMに問い合わせて最新状態にしろ。できないならセキュリティ低下を受け入れろ」という、実質的な「最新PCへの買い替え促進」の側面も否定できません。
参考サイト一覧
閲覧時の留意事項：日本Microsoftのサイトは「機械翻訳」です。文脈に不自然な点がある場合は、原文（英語）の意図を汲み取る必要があります。
今回の結論に直結する重要サイト
- MS公式：Windows デバイスでセキュア ブート証明書の有効期限が切れた場合（元の発行日: 2026 年 2 月 10 日）
今回の「起動はするが、更新は止まる」という結論の根拠となる最重要ドキュメント（KB5079373）です。
留意点：「元の発行日」となっているのは、2月10日の初版公開日後に何らかの修正/改定などが行われたためと考えられます。MSももしかしたら、「Winというプラットフォーム上の多用な環境のデバイスの上での完全に正確な挙動を把握しきれてはいない」という状況を反映しているのかも知れませんね。 - KB5036210: セキュア ブート許可署名データベース (DB) への Windows UEFI CA 2023 証明書の展開
新しい「2023年版証明書」を実際にどのようにシステムへ展開していくか、その技術的なステップを解説した公式資料です。
基礎知識・検証用サイト
- MS公式：Windows 11 とセキュア ブート
Windows 11におけるセキュアブートの必須条件と、その役割を解説した初心者向けガイドです。 - 外部ブログ：Windows セキュアブート証明書のバージョン・有効期限を調べる方法
自分のPCに現在どのバージョンの証明書が入っているのかを確認する具体的な手順を紹介している、実践的なサイトです。 - 高度な技術背景
MS公式：セキュア ブート DB と DBX 変数の更新イベント
イベントログからセキュアブート関連の更新が成功したかを確認するための、管理者向け情報です。 - MS公式：CVE-2023-24932 に関連付けられているセキュア ブートの変更に対する Windows ブート マネージャー失効を管理する方法
「BlackLotus」等の脆弱性対策としてブートマネージャーを更新する際、証明書の整合性がどれほど重要かを理解するための深掘り資料です。 - 日本マイクロソフト：TPM-WMI イベント ID: 1801 について
証明書の更新に失敗した際に出るエラーメッセージの意味を、日本の技術サポートチームが解説した公式ブログです。
セキュアブート証明書DB更新問題の2026/02/12時点の状況（2026/02/17改題と一部修正）
＝＝＝以下原文のまま＝＝＝
MS Learnでの質問と回答、およびその後の追加調査を経て、本件は「確認手法による判定の乖離」という、極めて難解な事実に収束しました。本追跡記事は、現時点での「着陸地点」として、一旦の結論をまとめます。
ただし、2026年6月の期限失効時に、万が一セキュアブートの影響でOSが起動不能となる事態が発生した際には、改めて総力を挙げて記事を作成し、皆様をサポートすることをお約束します。
上記ツールを利用した筆者の判定結果画像
【結論】専門家ですら判定を誤る「確認プロセスの迷宮」
当初、PowerShell等の標準コマンドによる解析結果から「判定True（器の対応）」と「署名期限2026/06/18（中身の未更新）」の不整合を指摘してまいりましたが、多角的な検証の結果、OS側は正しく更新されていたものの、「正しく更新されたことを確認する手段自体が、極めて難解である」という結論に達しました。
「セキュアブート証明書チェッカー」による確認において、以下の太字項目（同等/相当を含む）が表示されていれば、現時点では「対応済み」と捉え、2026/06まで静観するというのが当ブログの最終的な回答です。
【Microsoft UEFI CA 2023】 – 有効期限: 2038年6月
【Microsoft Option ROM UEFI CA 2023】 – 有効期限: 2038年10月
*【Microsoft Corporation UEFI CA 2011】 – 有効期限: 2026年6月
【Microsoft Corporation KEK 2K CA 2023】 – 有効期限: 2038年3月
- 「コマンドが語る真実」の限定性： 標準的な署名確認コマンドでは、2011年版と2023年版が共存する複雑な署名構造のうち、古い情報を優先的に返してしまうケースが確認されました。
- 「ツールによる成功」の確認： 専用の検証ツールで解析した結果、筆者の環境においても2035年までの有効期限を持つ「2023年版署名」への移行が、実は物理ファイルレベルで完了していたことが判明しました。
Windows セキュアブート証明書チェッカーの信頼性について
当サイト独自の調査では、当該外部ブログの内容等より、以下の理由から信頼できるソフトと判定しました。
1. 判定ロジックの具体性と厳格性
このツールは単にOSのフラグを読み取っているだけではありません。
- 物理的な鍵の有無を確認: UEFI/NVRAM内に「Windows UEFI CA 2023」が実際に書き込まれているかを直接スキャンしています。
- ブートマネージャーの署名検証:
bootmgfw.efiの署名が2023年版に更新されているかを判定し、結果を「Boot Manager」と「証明書」の2段に分離して表示しています。 - 判定基準の更新: 以前のバージョンで発生した誤検知を修正（Ver 2.1.0.0）するなど、継続的に精度を高めている経緯があります。
2. コミュニティでの「再現性」と「裏付け」
- 標準コマンドの限界の解明: 筆者が利用した標準コマンドではCA2011の期限が優先表示されていた可能性が高い一方、ツールは「2035年（CA2023）」の存在を正しく抽出しました。
- 専門家による検証: MSコミュニティのボランティア・モデレーターであるwanisan氏も、自身の環境でこのツールを利用して検証を行っており、技術者間での「共通言語」として機能し始めています。
3. 注意すべき「信頼性の境界線」
- 非公式ツールであること: Microsoftが保証する公式ツールではなく、あくまで「自己責任」での利用が前提となります。
- 環境による動作差異: PC環境によっては正しく動作しない可能性も明記されています。
- 2026年6月の「真実」: ツールが「成功」と判定しても、最終的な起動成否は、OS・BIOS・デバイス側の全ての要素がその瞬間にどう噛み合うかにかかっています。
結論として、標準コマンドの結果に疑問を感じた際の「セカンドオピニオン」としての信頼性は極めて高いと言えます。
参考情報
読者の皆様への最終メッセージ
今回の追跡を通じて、OSとハードウェア（BIOS）が密接に絡み合う本件の難しさを改めて痛感しました。筆者自身も当初「不整合」と誤認してしまいましたが、これは「速報性と予防効果」を重視し、現場の矛盾をいち早く共有しようとした結果の「錯誤」です。速やかに訂正いたします。
現状、KB適用後に「成功」と出ている環境では、過度に不安がる必要はないかもしれません。しかし、BIOS更新が必要なケースがあることも事実です。各自、信頼できる検証手段を用いて現在の状態を把握し、2026年6月に備える「自衛」の手を緩めないでください。
この記事について
この記事は、2026年1月より本格化したセキュアブート署名DB更新（2026年問題）において、実機検証で判明した「OS上の判定」と「物理ファイル」の深刻な不整合（ゴースト適用）の真相を、リアルタイムで追跡・解説するものです。
| 項目 | 内容 |
|---|---|
| 関連KB | Win11 (23H2以降): KB5036210（セキュアブートDB更新パッチ） Win11 (25H2/24H2): KB5074109、Win10: KB5073724 |
| 最重要キーワード | 2026年問題, セキュアブート不整合, ゴースト適用, UEFI CA 2023, bootmgfw.efi署名期限 |
| リアルタイム追跡 | 2026/02/11：追跡ログ開始 ・MS Learnへの不整合報告と門前払いの実態 ・ASUS最新BIOS適用環境での不整合事象の確定 ・DELL公開コマンドによる「器」と「中身」の分離検証 2026/02/12：着陸地点の更新 ・標準コマンドの限界と「確認手法による判定の乖離」の発見 ・専用ツールを用いた「真の成功（2035年期限）」の確認 |
【時系列】不具合報告と動向（追跡ログ）
追跡ログ：2026/02/12
一応の収束をみました。標準コマンドによる判定の限界と、専用ツールによる「真の成功」の確認プロセスについては、冒頭の「セキュアブート証明書DB更新問題の現時点の着陸地点」セクションをご参照ください。
追跡ログ：2026/02/11
- Microsoft Q&Aへの技術性課題提起と現状
- MS Learn（Q&A）にて、「KB適用後の不整合：UEFI変数はTrueだがブートローダーの署名期限が2026/06/18のまま更新されない」旨の質問を投稿。
- ボランティア・モデレーターからは「ここはサポート窓口ではない」という趣旨の回答が主であり、現時点でMS公式としての技術的見解は得られていません。
- ASUSテクニカルサポートへの正式照会準備
- 「最新BIOSを適用し、Default DBがTrueであるにもかかわらず、OS側の物理ファイルが置換されない（ように見える）不整合」について、詳細な検証データを添えて照会準備を開始。
- 定例更新（2月Bリリース）での改善有無
- 本日配信の正式版KB等を適用しましたが、標準的な署名確認コマンド上では依然として「署名期限：2026/06/18」と表示され、不整合が継続しているように見える状態を実機で確認しました。
- 今後の検証ロードマップ
- メーカーより正式版BIOSが提供され次第、速やかに導入して再検証を行います。
- AM5プラットフォーム（最新世代AMD環境）等、異なる環境における「ねじれ」の有無についても多角的な実機検証を継続します。
この記事開始時点のまとめ（2026/02/11時点）
当サイトの検証で判明している「不整合」の概要
実機検証により、以下の「ねじれ現象（ゴースト適用）」を確認しています。
- 判定の乖離： UEFI変数（db/dbdefault）の判定は「True（成功）」と出るが、実際のブートローダー（bootmgfw.efi）の署名期限は「2026/06/18（旧署名）」のままである。
- ハードとソフトの断絶： ASUS等の最新BIOSにより「器（新証明書を受け入れる鍵）」は用意されたが、Windows Update側が「中身（物理ファイル）」を更新しきれていない。
🖥️ DELLの検証手法から見える「時限爆弾」の正体
読者の左沢さんより寄せられた情報に基づき、DELLが公式に提示している高度な検証手順を分析しました。
DELL公式サイト：セキュア ブート証明書を確認する方法
1. アクティブDBとデフォルトDBの比較
DELLの検証コマンドを用いると、以下の2層を個別に判定可能です。
- Active DB（アクティブ変数）： PCが今まさに起動に使用している設定。
- Default DB（デフォルト変数）： マザーボードが基盤レベルで保持している工場出荷時の標準設定。
2. 「アクティブ＝True / デフォルト＝False」が意味する危険性
初動記事にいただいた左沢さんの報告にあるこの状態は、「Windowsが無理やり鍵をねじ込んだが、マザーボードの基盤には定着していない」ことを示唆します。BIOSを工場出荷状態にリセット（Load Defaults）した瞬間、新しい鍵が消失し、2026年6月以降に突然の起動不能（Security Violation）に陥るリスクを秘めています。
4. 検証機での結果画像
🛠️ ASUSの最新BIOS対応と「置き去りにされたOSファイル」
ASUSは2025年後半より、多くのモデルに対して「2023年版証明書への更新」を含む最新BIOSを順次リリースしています。
ASUS製マザーボードでの検証結果
- 最新BIOSの効果：
dbdefaultが True になり、ハードウェア側は完全に対応済みであることが確認できました。 - 確定した不整合： ハードウェア（ASUS）は「器」を新しくしたが、OS（Microsoft）側のブートローダーが古い署名のまま居座っている不整合が、筆者の実機で確定しました。
これは、メーカー側の努力をMicrosoft側のファイル更新プロセスが台無しにしている、「連携の失敗」を物語っています。
ASUSの対応状況についての調査結果
ASUSが公式にアナウンスし、複数のモデルに対して展開している広範な対応です。
具体的には、ASUSは2025年後半から2026年2月にかけて、多くのマザーボード（特にIntel 600/700シリーズやAMD 600シリーズなど）向けに「Update the Secure Boot DB certificate to the 2023 version（セキュアブートDB証明書を2023年版に更新）」といった内容を含むBIOSを順次リリースしています。
ASUSの公式アナウンス
- メーカーとしての公式対応：ASUSは2026年6月の証明書失効を見越し、ハードウェア側で「新しい鍵（2023年版）」を恒久的に保持できるようにBIOSレベルでの対策を進めています。
資料
セキュアブートDB更新に関する記事等の資料です。
外部サイト
- MS：CVE-2023-24932 に関連付けられているセキュア ブートの変更に対する Windows ブート マネージャー失効を管理する方法
※ 2023年版DBに切り替わったときのものです。今回のDB更新にかかる公式記事はまだ存在しないようです。 - DELL：セキュア ブート移行に関するよくあるご質問(FAQ)
- ブログ：ITニュース. 2026年6月にセキュアブート証明書の有効期限切れ、企業は対策が必要な場合も
※ セイ・テクノロジーズ株式会社さんの技術ブログです。管理者の方には一読をおすすめします。 - ブログ：Windows セキュアブート証明書のバージョン・有効期限を調べる方法
※ 「Windows セキュアブート証明書チェッカー」という有用なツールの情報が紹介されています。
ブログ内記事
- 【ゴースト適用・2026年問題続報】不整合の実例も発生-今すぐバージョン確認を-WinREとセキュア ブート許可署名DB【2026/02/11】
- 【2026年問題・追跡ログ】公式判定の死角：実機検証で暴かれた「セキュアブートDB更新」の不都合な真実とは？【2026/02/11〜】
記事中の専門用語の解説
- ゴースト適用（筆者提唱）：システム上の判定（UEFI変数など）は成功（True）しているが、実際の物理ファイル（bootmgfw.efi等）の署名更新が確認できない「見かけ倒し」の状態を指します。ただし、今回の検証により、「実際には更新されているが、標準的な確認コマンドでは更新されていないように見えてしまう」という、確認手法側の問題も含まれることが判明しました。
- Active DB / Default DB：UEFIが保持する署名データベースの「現在の稼働設定（Active）」と「マザーボードの工場出荷時の標準設定（Default）」です。今回の2026年問題への対応では、両方がTrue（2023年版対応）であることが、工場出荷時リセット後も起動不能に陥らないための「完全な自衛」の条件となります。
- 2026年問題（セキュアブート）：2026年6月18日に従来のMicrosoft UEFI CA証明書が失効し、2023年版への移行がなされていないPCにおいて、OSが起動不能（Security Violation）になるリスクの通称です。
- 物理署名の確認：OS側の成否フラグではなく、ブートローダー等のファイル自体が持つ「デジタル署名の有効期限」を直接確認することです。当サイトが推奨する最も確実な検証手段ですが、CA2011とCA2023が共存する環境では、特定のツールを用いなければ正確な判定が困難であるという特性があります。
Q&A (2026/02/12更新)
Q1. コマンドで「True」と出ましたが、署名期限が「2026/06/18」のままです。大丈夫でしょうか？
A. 現時点では「確認手法による誤認」の可能性が高いです。
当初はこれを「ゴースト適用」として警告してまいりましたが、その後の検証により、標準的なPowerShellコマンドでは2011年版の期限が優先表示されてしまうケースがあることが判明しました。専用ツール（セキュアブート証明書チェッカー等）で確認し、「2035年（CA2023）」が検出されれば、物理ファイルレベルでも更新は完了しています。詳細は冒頭の「着陸地点」セクションをご覧ください。
Q2. メーカーからBIOSアップデートが出ていません。どうすればいいですか？
A. 古い機種（特に2011〜2014年頃のUEFI黎明期のモデル）では、メーカーからの更新が期待できないケースも多いです。その場合は「セキュアブートを無効化する」といった最終手段を含めた検討が必要になります。まずは本記事で紹介した検証ツールを用い、ご自身のPCがどのレベル（Active/Default DB）まで対応できているかを確認してください。
Q3. Microsoftの公式回答はどこで見られますか？
A. 残念ながら、MS Learn等の公式コミュニティでは依然として形式的な回答に留まっており、この「判定の乖離」に対する技術的な公式見解は示されていません。しかし、コミュニティ内の有志（ボランティア・モデレーター）との間では、実機データに基づいた活発な検証が行われており、専用ツールの有効性が確認されるなどの進展がありました。
付録：この記事の作成プロセス（AI協働メモ）
1. この記事の目的と役割
この記事は、2026年最初の定例更新に伴う仕様変更に加え、実機検証で発覚した「セキュアブート署名DBの不整合（ゴースト適用）」の真相を究明し、読者に共有することを目的としています。公式判定が「成功」と出ても残る不整合の懸念から、最終的に判明した「確認手法による判定の乖離」という死角までを網羅的にカバーします。
2. 筆者の関連経験・専門性
この記事の執筆にあたり、筆者の以下の経験が活かされています。
- 20年以上にわたるWindows環境のトラブルシューティングおよびUpdate管理経験。
- UEFI/NVRAM上の変数（db/dbdefault）の直接解析、および各メーカー（ASUS/DELL等）の独自仕様の検証実績。
- PowerShellを用いた「Active/Default DB」の比較および「物理ファイル署名期限」のクロスチェック検証。
- MS Learn（公式コミュニティ）等での技術的議論を通じた、メーカー・OSベンダー側の最新動向の追跡。
3. AIとの協働内容（調査・議論のポイント）
記事作成の過程で、AI（Google Gemini）とは主に以下の点について精査を行いました。
- 不整合（ねじれ）の論理的検証： 「UEFI変数がTrueなのにファイル署名が古い」という事象が、確認手法（コマンド）の出力特性に起因する可能性についての技術的推論。
- 外部情報の統合解析： 読者や有志より寄せられた検証ツールのロジック解析と、それがなぜ標準コマンドの結果と食い違うのかという構造的理由の整理。
- コミュニティ対応の分析： 公式フォーラムでのボランティア・モデレーターとの対話を通じた、実機データの再現性と「技術的な着陸地点」の策定。
4. 主な参照情報・検証方法
以下の情報源および手法を用いて内容を検証しました。
- DELLサポートナレッジ（KB000385747）： セキュアブート証明書の詳細確認手順の解析。
- ASUS公式BIOS更新ログ： 2026年問題に対応した「2023年版証明書」の実装状況の調査。
- 実機物理検証：
Get-AuthenticodeSignatureコマンドおよびサードパーティ製検証ツールによる、物理ファイルの有効期限クロスチェック。 - 確認手法の限界に関する考察： 複数の署名が共存する環境において、OSの判定フラグと実機の物理的状態がどう「見えてしまうか」に関する技術的検討。
この記事中の広告リンクについて
この記事中の広告リンク一覧です。
記事本文中の広告リンク
このブログは、広告収入によって運営されていますが、この記事の本文中に個別の広告リンクは含まれていません。
サイドバーやヘッダー部分などの広告
広告が表示されています。
業者名や商品名など
この記事では明示的にプロモーションとして取り扱っているものはありません。
ただし、過去のプロモーションなどで取り扱った商品名や企業名などがプロモーション目的ではなくとも記載されている場合があります。
過去のプロモーションなどで取り扱った企業名は、できる限りステマ規制に関する表示についてのアフィリエイト等関連業者名一覧の項で記載していますので、お手数ですがそちらでご確認ください。
コメント
以前執筆された「Windows セキュアブート証明書のバージョン・有効期限を調べる方法」の記事にコメントさせていただき、学ばせてもらった者です。
最新の記事「記事最終更新日時：2026/02/17」を読ませていただき、さらに理解が深まりました。筆者の責任ある執筆姿勢に敬意を表します。
さて、私の古いPC環境からの情報提供となります。(2013年製 LAVIE PC-LL850msr-j)
「Windows セキュアブート証明書チェッカー」では、筆者の判定結果と全く同じ画像が表示されます。しかし、「アクティブ＝True / デフォルト＝False」の状況に変化はなく、「Windowsが鍵をねじ込もうとしたが、マザーボードの基盤には定着していない」状態が続いています。このことは、イベントビューアーのID1808の後に記録されるようになったID1033(NEC独自のシステムファイルの脆弱性を検出→DBXリストの更新を延期)からも明らかです。
「ツールが「成功」と判定しても、最終的な起動成否は、OS・BIOS・デバイス側の全ての要素がその瞬間にどう噛み合うか」と記事にありますが、その通りなのではないでしょうか。取り敢えず、起動への影響はなさそうとのことですので安心しました。