2026年6月のSecure Boot証明書失効に備える：Intuneレポートでの確認と、配布が失敗する場合の現実的な回避策

Windows管理の文脈で「Secure Bootの証明書更新」は、ふだん意識しにくいのに、期限が来ると急に“組織課題”に変わるタイプのテーマです。2026年6月以降、古いブート関連証明書の失効が始まるため、更新が入っていない端末は「起動はできるのに、将来の保護が受けられない」状態になり得ます。
本記事では、Intuneで状態を可視化する手順、更新しない場合の影響、そして「ポリシー配布が失敗する」ケースで実務的にどう前へ進めるかを、現場目線で整理します。

2026年6月のSecure Boot証明書失効に備える：Intuneレポートでの確認と、配布が失敗する場合の現実的な回避策

Secure Boot証明書の失効で何が起きるのか（“今は動く”が落とし穴）

今回のポイントは、失効が始まっても多くの端末は当面「普通に起動して動作する」ことです。Windows Updateも通常どおり入るケースが多く、利用者側から見ると問題が見えづらい。
しかし、更新が未適用の端末は、早期ブート（起動のかなり手前の段階）に関する新しい防御を受け取りにくくなります。具体的には、Windows Boot Manager周辺やSecure Bootのデータベース、失効リスト、起動レベルの新規脆弱性に対する緩和策など、「守りの根っこ」に当たる部分の更新が難しくなる、という性質があります。

この“遅れて効いてくる影響”が厄介です。短期的に障害が出ないぶん後回しにされ、気づいた頃には「特定の要件（暗号化の強化、ブートチェーンの信頼、特定のブートローダー運用など）に支障が出る」状態になりやすい。だからこそ、期限の前に「状態の棚卸し」と「更新経路の確保」が重要になります。

IntuneでSecure Bootの状態を確認する（見える化の第一歩）

まずは現状把握です。IntuneではSecure Bootの状態をレポートで確認できます。管理画面の導線は次のイメージです。

Intune 管理センター
→ Reports
→ Windows quality updates（配下のレポート）
→ Secure Boot status

ここで端末ごとに状態が表示され、「Not up to date」のような結果が出ることがあります。オフライン期間が長い端末、更新が滞りがちな端末は、想定どおり未更新として出やすいです。
重要なのは、ここで未更新が見えたら「更新を流す段取りが組めるか」をすぐ検証すること。可視化だけで満足してしまうと、結局期限直前に詰まります。

“Enable Secureboot Certificate Updates”が失敗することがある理由

実務でつまずきやすいのが、Intuneから構成プロファイル（例：Enable Secureboot Certificate Updates）を配布したのに失敗するパターンです。
失敗時に見えるエラーとして、「ライセンスが原因でポリシーが拒否された」旨のメッセージが出ることがあります（端末側でポリシーが弾かれる挙動）。

この手のトラブルは、端末が Windows 11 Pro から Windows 11 Enterprise にアップグレードされた経緯を持つ場合に表面化しやすい、という報告が見られます。管理者の体感としては「配布はできているのに、端末が受け取らない」「同じ設定でも端末ごとに成否が割れる」になりやすく、原因の切り分けに時間を取られがちです。

ここで大事なのは、失敗の事実そのものよりも、次の一手を用意しておくことです。つまり「そのポリシーで通らない端末が一定数いる前提」で、別ルートでも更新を進められる体制にしておく、ということです。

回避策：ポリシーにこだわらず“レジストリで更新を強制”する考え方

回避策として現実的なのが、Intuneの構成プロファイルを使わず、端末のレジストリキーを設定して更新処理を起動させる方法です。考え方としてはシンプルで、ポリシーが内部的に設定するのと同等のキーを、別の配布手段で入れてしまうというアプローチです。

このやり方の利点は2つあります。

ライセンス由来でポリシーが拒否される端末でも前に進める余地がある
Intune運用の枠内で、スクリプト配布やリメディエーションとして実装しやすい

一方で注意点もあります。

レジストリ操作は影響範囲が大きいので、**小規模リング（検証→限定展開→全体）**で進める
実行ログ／成功判定（更新済みフラグなど）を設計し、「やったつもり」を防ぐ
端末が再起動や特定の更新状態を要求する場合があるため、**ユーザー影響（再起動通知・メンテ時間）**をセットで計画する

「ポリシーが失敗したら終わり」ではなく、「同じゴールに行ける別ルートを持つ」のが、期限付き案件では最も効きます。

進め方のおすすめ：期限までに詰まらない運用設計

最後に、期限（2026年6月）までに慌てないための、実務向けチェックリストです。

1. 可視化：Intuneレポートで未更新端末を抽出（オフライン端末も含めて洗い出し）
2. 端末分類：
- 通常端末（ポリシーで通る）
- 問題端末（ライセンス拒否などで通らない）
- 長期オフライン端末（回収・ネット接続計画が必要）
3. 更新経路を二段構えに：
- 第一選択：Intuneの構成プロファイル
- 第二選択：レジストリ設定を用いた強制更新（スクリプト/リメディエーション）
4. 成功判定を必ず設計：更新“実行”ではなく更新“完了”をゴールにする（端末側の状態で判定）
5. 例外処理：どうしても適用できない端末は、用途やリスクに応じて「交換・再展開・隔離」を判断

Secure Bootは「トラブルが起きてから」追いかけると、原因がファームウェア、ブートチェーン、証明書、ライセンス、管理経路…と広がりやすい領域です。だからこそ、今の段階で“見える化”と“二段構えの更新ルート”を整備しておくことが、結果的に一番コストを下げます。

期限が来るまでに、未更新がゼロにならなくても構いません。重要なのは、未更新端末が残ったときに「どれが、なぜ残っていて、どう処理するか」を説明できる状態にしておくことです。これができるだけで、6月前後の火消しは大幅に減ります。