監視で 「Secure_Boot_certificates_have_been_updated_but_are_not_yet_applied…」 が出ると、思わず“障害？”って身構えますよね😅💦
でもこの件は、端末（VM）がUEFI＋Secure Boot運用か／レガシーBIOS運用かで、結論がハッキリ分かれます✅✨
✅ 先に結論：設定（Legacy BIOS / Secure Boot関連）を見直すと解消するケースが多いです。
ただ、BIOS/UEFI周りは用語がややこしくて詰まりやすいので、体系的に確認したい人はこの1冊が早いです📘リンク
Confirm-SecureBootUEFI が Cmdlet not supported on this platform になるのは仕様です🧠✨Microsoftの案内はざっくり言うと、Secure Bootで使われる証明書（従来のCA 2011系）が2026年6月から期限を迎えるため、継続して“安全な起動（Secure Boot）”を維持するには更新が必要になる可能性がある、という話です🛡️⏳
このイベントは、**Windows Update後などに出やすい“状態通知”**で、UEFI/Secure Boot側に反映が終わっていないことを示す文言です🟨
（そして UEFIが無い＝レガシーBIOS だと“反映しようがない”ため、出続けることがあります😅）
msinfo32 を開く👀✨ 管理者PowerShellで👇
Confirm-SecureBootUEFI
True：Secure Boot有効✅False：Secure Boot無効🟨Cmdlet not supported on this platform.：BIOS（非UEFI）または非対応🟦（＝あなたの状況）レガシーBIOS運用では、Secure Bootを構成する UEFI変数（PK/KEK/DB/DBX） がありません🙅♂️💦
つまり、イベントが言っている 「ファームウェアに適用」 は、適用する場所自体が無い状態です🧩
ここが一番大事です💡✨
Windowsがイベントログに記録する挙動を“完全に止める”のはおすすめしません（将来UEFI化した時に困ることがあるため）😅
なので、基本は “検知（監視）側で止める” が最強です💪📉
監視のアラート条件をこう分けるのが、いちばん事故らないです🙂✨
SystemMicrosoft-Windows-TPM-WMI（※環境で差あり）1801📌 これで UEFI＋Secure Boot端末だけは正しく検知しつつ、BIOS VMのノイズだけ消せます✅🌟
あなたのように イベント検知→通知 の仕組みがあるなら、ここで止めるのが一番キレイです✨
ルール例（イメージ）🙂📌
msinfo32 相当の情報で BIOSモードを判定👉 これだけで「毎回通知が飛ぶ地獄」から解放されます😇📩
現場では、
MicrosoftはSecure Boot更新の流れで、スケジュールタスクを実行する手順を案内しています🧠🛠️
代表例として、タスク名は次のように示されています👇
\Microsoft\Windows\PI\Secure-Boot-Update📌 これを“止める（無効化する）”と、1801の発生が減る可能性はありますが、更新フローも止まるのでおすすめはしません🙅♂️💦
（特に将来UEFI化やSecure Boot必須化があるなら、ここは触らない方が安全です✅）
UEFI＋Secure Bootが有効な端末/VMは、Microsoftのガイダンスに沿って更新を進めるのが安全です🛡️✨
Microsoftは「証明書期限（2026年6月）」に向けた準備と、更新の必要性を案内しています📣
まずは対象のセキュリティ更新を入れるのが前提です✅✨
Microsoftの案内例として、次のようなキー設定が紹介されています👇
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot" -Name "AvailableUpdates" -Value 0x40
こちらもMicrosoftの案内例です👇
Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update"
更新は再起動を伴うため、手順に従って進めます✅✨
（運用設計的には “メンテ枠で計画的に” が安心です📅🛠️）
UEFI＋Secure Bootを使うVMでは、NVRAM（.nvram）にSecure Boot変数が保存されます📦✨
Broadcom（VMware）のKBでは、NVRAMを削除すると、起動時にESXiが新しいNVRAMを生成し、更新済みの証明書リスト（2023証明書含む）を含める場合がある、と説明されています🛠️
📌 ただしこれは UEFI＋Secure Boot運用が前提で、実施には注意が必要です⚠️
（レガシーBIOSのVMでは関係ありません🟦）
👉【アフィリエイトリンク差し込み位置：ここ】✨
👉【アフィリエイトリンク差し込み位置：ここ】✨
👉【アフィリエイトリンク差し込み位置：ここ】✨
基本的にその心配は小さいです🙂✅
この件は UEFI＋Secure Bootで安全な起動を維持するための証明書更新が中心の話です🛡️
Confirm-SecureBootUEFI が “Cmdlet not supported…” は異常？🧩異常ではありません🙂✨
Microsoftも BIOS（非UEFI）やSecure Boot非対応ではその表示になると明記しています✅
Windowsがイベントログへ記録する挙動を完全に止めるより、監視/検知側で抑止するのが安全でおすすめです📉✅
（将来UEFI化したときに、更新フローまで止めるのが怖いためです😅）
Microsoftのガイダンスに沿って、更新の準備・展開・監視を進めるのが安心です📅✨
イラスト1枚から、テクスチャ付…