監視で 「Secure_Boot_certificates_have_been_updated_but_are_not_yet_applied…」 が出ると、思わず“障害？”って身構えますよね😅💦
でもこの件は、端末（VM）がUEFI＋Secure Boot運用か／レガシーBIOS運用かで、結論がハッキリ分かれます✅✨
✅ 先に結論：設定（Legacy BIOS / Secure Boot関連）を見直すと解消するケースが多いです。
ただ、BIOS/UEFI周りは用語がややこしくて詰まりやすいので、体系的に確認したい人はこの1冊が早いです📘リンク
まず結論（最短で判断）✅🧭
✅ レガシーBIOS（非UEFI）のWindows（＝あなたのケース）🟦
- 証明書更新の“適用先（UEFIのSecure Boot変数）”が無いので、**対応不要（＝適用作業は実施不可）**でOKです🙂✅
Confirm-SecureBootUEFIが Cmdlet not supported on this platform になるのは仕様です🧠✨- やることは 「監視ノイズを止める設計」 がメインです📉🔧
✅ UEFI＋Secure Boot運用の端末/VM🟩
- 2026年6月以降の証明書失効に備えた計画対応が推奨です📅🛡️
- Microsoftは、DB/KEKなどの更新が必要になる可能性を明確に案内しています📣
そもそも何が起きる？「2026年6月」って危険？😨🧾
Microsoftの案内はざっくり言うと、Secure Bootで使われる証明書（従来のCA 2011系）が2026年6月から期限を迎えるため、継続して“安全な起動（Secure Boot）”を維持するには更新が必要になる可能性がある、という話です🛡️⏳
今回のイベント（1801）の意味🧠📣
イベント1801＝「OS側では更新が来たけど、ファームウェア（UEFI）にまだ反映できてないよ」⚠️
このイベントは、**Windows Update後などに出やすい“状態通知”**で、UEFI/Secure Boot側に反映が終わっていないことを示す文言です🟨
（そして UEFIが無い＝レガシーBIOS だと“反映しようがない”ため、出続けることがあります😅）
5分でできる確認（ここだけ押さえれば迷わない）🕔✨
① 起動モードを確認する（最重要）🧩
msinfo32を開く👀✨- BIOSモード：UEFI / レガシ（BIOS） を確認します✅
② Secure Bootの状態を確認する（UEFIのみ）🔐
管理者PowerShellで👇
Confirm-SecureBootUEFI
True：Secure Boot有効✅False：Secure Boot無効🟨Cmdlet not supported on this platform.：BIOS（非UEFI）または非対応🟦（＝あなたの状況）
【レガシーBIOS（非UEFI）】対応不要でOKな理由🟦✅
レガシーBIOS運用では、Secure Bootを構成する UEFI変数（PK/KEK/DB/DBX） がありません🙅♂️💦
つまり、イベントが言っている 「ファームウェアに適用」 は、適用する場所自体が無い状態です🧩
ここが安心ポイント🙂🌈
- ✅ “Secure Bootで守る仕組み”を使っていないため、証明書期限の影響で急に起動不能になる類とは性質が違うです👌
- ✅ 代わりに、監視が“Error”として拾って運用がザワつくのが問題になりがちです📣😅
- ✅ だから結論は 「障害対応ではなく、運用整理（ノイズ停止）」 が正解です✅✨
【重要】「いちいちメッセージを出力させない」現実解🧹🔕
ここが一番大事です💡✨
Windowsがイベントログに記録する挙動を“完全に止める”のはおすすめしません（将来UEFI化した時に困ることがあるため）😅
なので、基本は “検知（監視）側で止める” が最強です💪📉
おすすめ順に紹介します✅🧭
① 監視側で「除外（抑止）」するのが最適解📉🛠️
監視のアラート条件をこう分けるのが、いちばん事故らないです🙂✨
- ✅ 条件：イベントログ
System - ✅ Provider（ソース）：
Microsoft-Windows-TPM-WMI（※環境で差あり） - ✅ Event ID：
1801 - ✅ さらに「BIOSモード＝レガシ」の端末/VMだけ除外🟦
- 例：台帳に “BIOSモード” を持たせて対象判定する📝✨
📌 これで UEFI＋Secure Boot端末だけは正しく検知しつつ、BIOS VMのノイズだけ消せます✅🌟
② 検知スクリプト側で“判定してスキップ”する（超おすすめ）🧠🧹
あなたのように イベント検知→通知 の仕組みがあるなら、ここで止めるのが一番キレイです✨
ルール例（イメージ）🙂📌
- まず
msinfo32相当の情報で BIOSモードを判定 - レガシBIOSなら 1801は通知しない
- UEFI＋Secure Bootなら 1801は計画対応へ（通知する）
👉 これだけで「毎回通知が飛ぶ地獄」から解放されます😇📩
③ イベントビューア/WEFの“フィルタ”で見え方を整理する👀🧽
現場では、
- 運用者の画面では見えないようにする
- 集約側（WEF/ログ基盤）で落とす
という運用もアリです🧰✨
④ どうしてもOS側の動きを止めたい（※非推奨寄り）🟨⚠️
MicrosoftはSecure Boot更新の流れで、スケジュールタスクを実行する手順を案内しています🧠🛠️
代表例として、タスク名は次のように示されています👇
\Microsoft\Windows\PI\Secure-Boot-Update
📌 これを“止める（無効化する）”と、1801の発生が減る可能性はありますが、更新フローも止まるのでおすすめはしません🙅♂️💦
（特に将来UEFI化やSecure Boot必須化があるなら、ここは触らない方が安全です✅）
【UEFI＋Secure Boot運用】計画対応の基本フロー🟩📅
UEFI＋Secure Bootが有効な端末/VMは、Microsoftのガイダンスに沿って更新を進めるのが安全です🛡️✨
Microsoftは「証明書期限（2026年6月）」に向けた準備と、更新の必要性を案内しています📣
代表的な手順（管理者向け）🧰✅
① Windows更新（対象月以降）を適用する🧩⬆️
まずは対象のセキュリティ更新を入れるのが前提です✅✨
② レジストリで更新を“有効化”する🧠🔑
Microsoftの案内例として、次のようなキー設定が紹介されています👇
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot" -Name "AvailableUpdates" -Value 0x40
③ スケジュールタスクを実行する▶️🛠️
こちらもMicrosoftの案内例です👇
Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update"
④ 再起動して反映を進める🔄💻
更新は再起動を伴うため、手順に従って進めます✅✨
（運用設計的には “メンテ枠で計画的に” が安心です📅🛠️）
【VMware/ESXi】UEFI＋Secure BootのVMで詰まる時の追加ポイント🧠⚙️
UEFI＋Secure Bootを使うVMでは、NVRAM（.nvram）にSecure Boot変数が保存されます📦✨
Broadcom（VMware）のKBでは、NVRAMを削除すると、起動時にESXiが新しいNVRAMを生成し、更新済みの証明書リスト（2023証明書含む）を含める場合がある、と説明されています🛠️
📌 ただしこれは UEFI＋Secure Boot運用が前提で、実施には注意が必要です⚠️
（レガシーBIOSのVMでは関係ありません🟦）
🧰 運用をラクにするおすすめ導線（差し込み用）✨
① 監視のノイズ削減ツール📉🔔
👉【アフィリエイトリンク差し込み位置：ここ】✨
- イベントログ監視のフィルタ/抑止が柔軟な監視ツール
- SIEM/ログ集約（WEF、ログ基盤）
② メンテ作業を安全にするバックアップ💾🛟
👉【アフィリエイトリンク差し込み位置：ここ】✨
- VMバックアップ
- スナップショット運用の強化
- 復旧設計のガイド
③ セキュリティ運用の“基準づくり”📘✅
👉【アフィリエイトリンク差し込み位置：ここ】✨
- Windows/仮想基盤のハードニング本
- 監査対応のテンプレ集
FAQ（よくある質問）❓✨
Q1. レガシーBIOSのVMでも、2026年6月に起動できなくなる？😱
基本的にその心配は小さいです🙂✅
この件は UEFI＋Secure Bootで安全な起動を維持するための証明書更新が中心の話です🛡️
Q2. Confirm-SecureBootUEFI が “Cmdlet not supported…” は異常？🧩
異常ではありません🙂✨
Microsoftも BIOS（非UEFI）やSecure Boot非対応ではその表示になると明記しています✅
Q3. BIOS VMの1801を“完全に出さない”ことはできる？🔕
Windowsがイベントログへ記録する挙動を完全に止めるより、監視/検知側で抑止するのが安全でおすすめです📉✅
（将来UEFI化したときに、更新フローまで止めるのが怖いためです😅）
Q4. UEFI＋Secure Bootの端末は何をすればいい？🛡️
Microsoftのガイダンスに沿って、更新の準備・展開・監視を進めるのが安心です📅✨
まとめ：あなたのケースは「対応不要」＋「通知（監視）だけ止める」が正解✅🌈
- 🟦 レガシーBIOSのWindowsゲスト（ESXi上）なら **適用対応は不要（適用先が無い）**🙂✅
- 📉 困るのは“監視ノイズ”なので、監視/検知側で1801を抑止する設計が最適✨
- 🟩 UEFI＋Secure Boot運用の端末/VMだけ、2026年6月に向けて計画対応が安心🛡️
コメント