CVE-2023-24932（Secure Boot 回避）対策を進めると、「2011/2023 の署名・証明書が混在する期間」が必ず発生し、PXE/WinPE が端末によって起動できたりできなかったりする事故が起こりがちです。本記事では、新規端末の受入基準から、混在期間の PXE 二系統運用、失効（revocation）を最後に回す段階導入まで、現場で破綻しない形に落とし込みます。
結論：混在期間は「二系統の起動経路」＋「失効は最後」が最短で安全
最初に方針だけ押さえると、運用はかなりラクになります。
- 新規端末は「2023 のみ」になっていると決め打ちしない（現実には 2011/2023 が併存する端末もある）。重要なのは Windows UEFI CA 2023 を信頼できる状態と、2023 署名の Boot Manager で起動できる状態であること。
- 混在期間は PXE/ブートメディアを 旧系（2011 互換）と新系（2023 対応）に分け、端末の状態に合わせて使い分ける。
- 「失効（DBX へ PCA2011 を入れる）」は最後。PXE/USB/ISO/復旧メディア/バックアップ製品など“起動に使うもの” を全部 2023 側に寄せ切ってから適用する。
CVE-2023-24932 対策で“PXE が詰む”メカニズム
Secure Boot は「UEFI ファームウェアが、起動前（Pre-OS）に実行される EFI バイナリを 署名で検証し、許可されたものだけを起動する」仕組みです。ここで重要なのが UEFI 変数の DB（許可リスト）と DBX（失効/禁止リスト）です。
| 項目 | 役割 | 現場で起きること |
|---|---|---|
| DB（Secure Boot Signature Database） | 信頼してよい証明書/ハッシュの集合 | ここに Windows UEFI CA 2023 が入っていない端末は、2023 署名のブートローダーを起動できない |
| DBX（Secure Boot Revoked/Forbidden Signature Database） | 失効させる証明書/ハッシュの集合 | ここに Microsoft Windows Production PCA 2011（PCA2011）が入ると、PCA2011 署名の Boot Manager を全面的に拒否し、古い PXE/USB が起動不能になる |
| KEK（Key Exchange Key） | DB/DBX 更新に使う鍵（署名の“親”） | 2011→2023 の更新が必要（2011 は 2026 に期限が迫る） |
このため、混在期間は次の“板挟み”が起きます。
- PXE/WinPE を新（2023）に寄せると：DB に 2023 が入っていない未対策端末が起動できない
- PXE/WinPE を旧（2011）に据え置くと：DBX に PCA2011 が入った対策済み端末が起動できない（＝再イメージ不能）
つまり「PXE を 1 本に固定したまま混在を吸収する」のは構造的に難しく、二系統の起動経路（少なくとも二つの Boot Program/Boot Loader）を用意するのが事故りにくい、という結論になります。
2011 と 2023：何が“入れ替わる”のか（証明書の全体像）
よくある誤解が「2011 証明書を削除して 2023 のみになる」というイメージです。実務では、まず 2023 を追加して起動可能にする → 次に 2011 を失効（DBX で拒否）する、という順番で進めるのが安全です。
| 旧（2011） | 新（2023） | 格納先 | 用途 | 期限の目安 |
|---|---|---|---|---|
| Microsoft Corporation KEK CA 2011 | Microsoft Corporation KEK 2K CA 2023 | KEK | DB/DBX 更新の署名 | 2011 は 2026 年 6 月頃から期限 |
| Microsoft Windows Production PCA 2011（PCA2011） | Windows UEFI CA 2023（PCA2023） | DB | Windows の Boot Loader/Boot Manager 署名 | 2011 は 2026 年 10 月頃に期限 |
| Microsoft UEFI CA 2011 | Microsoft UEFI CA 2023 / Microsoft Option ROM UEFI CA 2023 | DB | サードパーティ boot loader / Option ROM 署名 | 2011 は 2026 年 6 月頃から期限 |
ここで押さえるべきポイントは 2 つです。
- “2023 対応済み端末” とは、DB に Windows UEFI CA 2023 が入り、2023 署名の boot manager で起動できる状態を指す（単に更新プログラムを入れた、では足りない）。
- “失効（DBX に PCA2011 を入れる）” を入れた端末は、PCA2011 署名の boot manager を全面拒否するため、旧 WinPE/PXE/ISO が一気に使えなくなる。
新規端末は「2023 のみ」で出荷されるべきか？現実的な答え
結論から言うと、調達要件として「2023 のみ（2011 が無い）」を前提にするのはおすすめしません。理由はシンプルで、現場で必要なのは “証明書が 1 枚だけ” という状態ではなく、次の 2 つが満たされることだからです。
- Windows UEFI CA 2023 がファームウェア DB に存在し、2023 署名の boot manager で起動できる
- DB/DBX 更新が正常に適用できる（機種依存で失敗するケースがあるため、検証・監視が必要）
また、2011 証明書は 2026 年に期限が近づくため、新規端末が 2023 へ寄っていく流れは確実です。調達・受入では「起動できる/できない」を早期に見抜けるチェック項目を定義しておくのが勝ち筋です。
受入チェックリスト（そのまま監査項目にできる）
| チェック項目 | 合格基準 | 確認方法（例） | NG のときの打ち手 |
|---|---|---|---|
| Secure Boot 有効 | 有効（True） | Confirm-SecureBootUEFI | UEFI 設定/標準化（出荷設定確認） |
| DB に Windows UEFI CA 2023 が存在 | 存在（True） | (Get-SecureBootUEFI db) を文字列マッチ | Mitigation 1（DB へ追加）/ファーム更新 |
| bootmgfw.efi が 2023 署名 | 証明書チェーンに Windows UEFI CA 2023 | EFI パーティションからコピーして署名確認 | Mitigation 2（boot manager 更新） |
| （必要に応じて）DBX に PCA2011 が入っている | 段階導入の方針に依存 | (Get-SecureBootUEFI dbx) 文字列マッチ / イベント | 失効は最後に回す（PXE/USB 更新後） |
| PXE（新系）で WinPE が起動できる | 社内標準の新 WinPE が起動 | 実機でネットワーク起動テスト | Boot Program/Boot image の更新・二系統化 |
チェック用 PowerShell（受入時の定番）
# 1) Secure Boot が有効か
Confirm-SecureBootUEFI
# 2) DB に Windows UEFI CA 2023 が入っているか（True/False）
([System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023')
# 3) DBX に Microsoft Windows Production PCA 2011 が入っているか（失効の有無）
([System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI dbx).bytes) -match 'Microsoft Windows Production PCA 2011')混在環境の PXE/イメージ展開：選べる設計パターンと“現場での強さ”
「混在をどう捌くか」は、技術よりも “オペレーションとして事故らないか” が勝負です。代表的なパターンを整理します。
| パターン | 概要 | メリット | デメリット | 向いている現場 |
|---|---|---|---|---|
| 二系統 PXE（推奨） | 旧系 PXE と新系 PXE を物理的に分ける（サーバ/DP/ネットワーク） | 誤爆しにくい。失効後も新系が残り続ける | サーバ/構成が増える | 拠点が多い、再イメージが頻繁、停止が許されない |
| 一系統 PXE＋VLAN/スコープ切替 | 通常 VLAN は旧、リプレース/検証 VLAN は新、など | 台数が少ないなら管理が軽い | 移動/切替が手作業になりやすい | キッティングルームがあり、ネットワークを制御できる |
| 新系は USB（回復メディア）で対応 | 失効済み端末は USB から WinPE 起動 | PXE 側の複雑さを下げられる | 現地作業が増える。USB 管理が難しい | 小規模、現地対応が前提のヘルプデスク |
| Secure Boot を無効にして逃げる | イメージ展開時だけ Secure Boot Off | 一時的には動く | セキュリティ/監査に弱い。手順漏れで事故る | おすすめしない |
実務で一番強いのは、二系統 PXE（旧/新）を用意し、端末の状態に合わせて使い分ける形です。これなら「いつの間にか失効が入って PXE 不能」も、「新規端末が 2023 前提で来て詰む」も回避できます。
推奨：PXE/ブートイメージの二系統運用（Legacy / 2023）
ここからは “手順書に落とせる粒度” で、二系統運用の作り方を具体化します。
二系統の定義（名前を決めてブレを消す）
- Legacy-PXE（旧系）：未対策端末や、DB に Windows UEFI CA 2023 が無い端末のための起動経路
- PCA2023-PXE（新系）：DB に Windows UEFI CA 2023 があり、2023 署名 boot manager を前提にする起動経路（失効後の“唯一の正解”）
運用ルール（これで現場が迷わない）
| 端末の状態 | 使う起動経路 | 現場での判断材料 |
|---|---|---|
| 未対策（2023 未導入） | Legacy-PXE | 資産台帳で未対策、または DB に 2023 が無い |
| Mitigation 1/2 済（2023 capable） | 基本は PCA2023-PXE（検証しやすい） | WindowsUEFICA2023Capable = 1 or 2 |
| Mitigation 3 済（PCA2011 失効） | PCA2023-PXE のみ | DBX に PCA2011 が入っている |
「端末の状態をどう判断するか」が肝ですが、OS が起動している端末ならレジストリでかなり正確に判定できます（後述）。一方で、OS が起動しない端末（故障/初期化済み/SSD 交換など）は判定が難しいため、現場運用としては次のどちらかに寄せるのが安全です。
- キッティング時は必ず PCA2023-PXE を使う（新端末・再展開を統一）
- どうしても Legacy が必要な作業は、Legacy-PXE に繋がるネットワーク/場所/手順を限定する（誤接続を防ぐ）
端末側の対策適用：Microsoft が示す 4 つの Mitigation と順序
CVE-2023-24932 対策は「更新を入れたら終わり」ではなく、段階的に “有効化” する設計です。大枠は次の 4 つで、順序が重要です。
- Mitigation 1：DB に Windows UEFI CA 2023 を追加
- Mitigation 2：2023 署名の boot manager を適用
- Mitigation 3：DBX に PCA2011 を追加（失効）
- Mitigation 4：SVN（Secure Version Number）更新（ロールバック耐性）
AvailableUpdates の値（手順書で迷子になりがちな部分）
KB の手順では、次のレジストリ値をセットして Scheduled Task を起動し、ファームウェア DB/DBX への変更を進めます。
| 目的 | AvailableUpdates 値 | 主な結果 | 最重要リスク |
|---|---|---|---|
| Mitigation 1（DB 更新） | 0x40 | DB に Windows UEFI CA 2023 が入る | ファームによっては更新失敗があり得る |
| Mitigation 2（boot manager 更新） | 0x100 | bootmgfw.efi が 2023 署名に | 再起動タイミングで反映待ちになることがある |
| Mitigation 3（失効：DBX 更新） | 0x80 | DBX に PCA2011 が入り、2011 署名 boot manager を拒否 | 旧 PXE/USB/ISO が起動不能になる（ここで詰む） |
| Mitigation 4（SVN） | 0x200 | ロールバック耐性が上がる | 将来の SVN 増分でメディア更新が必要になる |
実行コマンド（例）
# Mitigation 1：DB に Windows UEFI CA 2023 を入れる
reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot /v AvailableUpdates /t REG_DWORD /d 0x40 /f
Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update"
# Mitigation 2：2023署名の Boot Manager を適用
reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot /v AvailableUpdates /t REG_DWORD /d 0x100 /f
Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update"
# Mitigation 3：DBX に PCA2011 を追加（失効）
reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot /v AvailableUpdates /t REG_DWORD /d 0x80 /f
Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update"
# Mitigation 4：SVN 更新
reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot /v AvailableUpdates /t REG_DWORD /d 0x200 /f
Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update"なお、Microsoft は「失効を入れると元に戻せない（Secure Boot を維持する限り）」点を強く注意しています。Mitigation 3 を入れる前に、必ず PCA2023-PXE/USB/ISO の動作確認と復旧手段を確保してください。
“どの端末が新旧どっちか”を自動判定する（SCCM/Intune/資産台帳向け）
混在期間で一番困るのは、現場が「この端末は新系 PXE でいい？旧系？」を毎回悩むことです。そこで、端末側の状態を数値で持ちます。
WindowsUEFICA2023Capable（推奨の判定キー）
KB では、Mitigation 1/2 の適用状況を次のレジストリで判定できる、と整理されています。
- キー：HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing
- 値名：WindowsUEFICA2023Capable（REG_DWORD）
- 意味：0（無い/未導入）、1（DB に 2023 あり）、2（DB に 2023 あり＋2023 署名 boot manager で起動）
この値を SCCM/MECM のハードウェアインベントリや、Intune の検出スクリプトで拾えば、コレクション分けや段階展開が現実的になります。
イベントログでの監視（“失敗している端末”を拾う）
DB/DBX 更新はファームウェア依存なので、失敗端末は必ず出ます。成功判定の例として、Mitigation の成功イベントが整理されています。
| Mitigation | イベント ID（例） | 意味 | 運用での使いどころ |
|---|---|---|---|
| DB 更新 | 1036 | PCA2023 が DB に追加された | 新系 PXE 移行の前提チェック |
| Boot Manager 更新 | 1799 | PCA2023 署名の boot manager が適用された | “2023 capable” の実証 |
| DBX 更新（失効） | 1037 | PCA2011 を拒否する DBX が適用された | 旧 PXE が使えなくなる境界の把握 |
PCA2023-PXE（新系）を作る：WinPE/Boot ファイル更新の実務
“新系 PXE” が作れない限り、失効（Mitigation 3）には進めません。ここを最優先で片付けます。
基本方針：ADK/WinPE を新しくし、WinPE を最新 CU で更新する
WinPE は「作った瞬間のまま」だと脆弱性・互換性の両面で古くなります。Microsoft は WinPE ブートイメージを最新の累積更新（CU）で更新することを推奨しており、BlackLotus（CVE-2023-24932）対応の観点でもブートイメージ更新が重要です。さらに、ADK のビルドによっては “既に対策を含む” ものがあります。
新 WinPE を用意する際のチェックポイント
- Windows ADK と WinPE アドオンのバージョン整合（混ぜない）
- PXE で配る boot.wim/WinPE の更新だけでなく、PXE の最初に呼ばれる EFI（例：wdsmgfw.efi/bootmgfw.efi）も更新される設計にする
- SCCM/MECM/MDT/WDS など、製品ごとに “どこを更新すべきか” が違うので、更新ポイントを先に棚卸しする
WDS/MDT/SCCM で「更新が必要なもの」早見表
| 用途 | 代表ファイル | 更新ポイント | 失敗すると起きること |
|---|---|---|---|
| PXE の最初の起動（UEFI） | wdsmgfw.efi / bootx64.efi | PXE サーバ側の boot program | WinPE に入る前に弾かれて何もできない |
| WinPE 本体 | boot.wim / winpe.wim | ADK の WinPE＋最新 CU | 起動後にドライバ不足やタスク失敗、署名チェーン問題 |
| タスクシーケンス媒体 | USB/ISO のブート領域 | 再生成 or スクリプトで更新 | 現地復旧が不能 |
既存メディアを“2023 起動可能”に寄せる：Make2023BootableMedia.ps1 を使う
PXE だけでなく、ISO/USB/ネットワーク共有に置いてあるインストールメディアも更新対象です。Microsoft は、Windows UEFI CA 2023 を信頼するシステムで起動できるようにメディアを更新する PowerShell スクリプト（Make2023BootableMedia.ps1）を提供しています。ISO/USB/ローカル/ネットワークパスを入力にできるため、社内標準メディアの更新作業を機械化しやすいのが利点です。
# 例：ISO を 2023 起動可能な ISO に変換
Make2023BootableMedia.ps1 -MediaPath C:\Media\Win11.iso -TargetType ISO -ISOPath C:\Media\Win11_Updated.iso
# 例：ネットワーク共有のメディアから 2023 起動可能 ISO を作成
Make2023BootableMedia.ps1 -MediaPath \\server\share\Win11_Media -TargetType ISO -ISOPath C:\Media\Win11_Updated.iso
# 例：USB を作成
Make2023BootableMedia.ps1 -MediaPath C:\Media\Win1124H2 -TargetType USB -USBDrive E:段階導入（フェーズ方式）：混在で詰まない進め方
“詰む”のは、ほぼ例外なく 失効（Mitigation 3）を入れた後に、起動メディアが古かったパターンです。そこで、フェーズを明確に分けます。
フェーズ設計（おすすめの流れ）
| フェーズ | やること | ゴール判定 | 次に進む条件 |
|---|---|---|---|
| 準備 | PCA2023-PXE（新系）の構築、USB/ISO の更新、機種別テスト計画 | 代表機種で新系 PXE/USB が起動し展開完走 | 復旧手段（USB/手順/鍵）が揃っている |
| フェーズ1（非破壊） | Mitigation 1/2 をパイロットに適用（DB 追加＋boot manager 更新） | WindowsUEFICA2023Capable が 2 になる端末が増える | ログ/イベントで失敗端末を潰せている |
| フェーズ2（移行） | 現場手順を “新系 PXE 優先” に変更、旧系は限定運用 | 再イメージ要求の大半を新系で処理可能 | 旧メディアの利用頻度が低下 |
| フェーズ3（破壊的） | Mitigation 3/4 を限定グループへ（失効＋SVN） | 失効後も PCA2023-PXE/USB で復旧可能 | 例外機種が解消、または切り離し方針が決まった |
| 収束 | 旧系 PXE/旧 WinPE/旧 USB を廃止、調達要件を 2023 前提へ | 運用手順が一本化 | 監査・BCP 含めて更新完了 |
混在期間の“代表的な事故”と、先回りで潰すコツ
BitLocker の回復キー要求
Secure Boot まわりの変更は、環境によっては BitLocker の回復キー要求につながります。対策を有効化する前に、回復キーの取得・保管・現場提示フローを整備しておくのが必須です。
ファームウェアが DB/DBX 更新に失敗する
DB/DBX 更新は OS だけでは完結せず、UEFI ファームウェア実装に依存します。Microsoft も、すべてのデバイス組み合わせをテストできないため、代表機種での事前検証を推奨しています。失敗端末は「イベントログ」「機種/BIOS バージョン」で束ね、OEM の BIOS 更新で潰すのが王道です。
過去に作った復旧 USB / バックアップ製品のリカバリメディアが死ぬ
失効後に起動できないのは PXE だけではありません。ISO/USB/ネットワークブートなど、“起動できること” を前提にしていた道具がすべて対象です。更新対象を棚卸しすると、だいたい次が漏れます。
- 社内配布している Windows インストール USB
- ベンダー製バックアップソフトの WinPE/回復メディア
- 障害対応用に保管していた古い WinPE（技術者が個人で持っている USB も含む）
- VM テンプレート（Secure Boot 有効の Gen2 VM など）
棚卸しが苦手なら、まずは「新系で起動できる標準 USB を 1 本作る」→「それで復旧できる手順に寄せる」から始めると移行が速いです。
手順書テンプレ：現場で迷わせないための最小セット
最後に、これだけ書いておけば運用が回る “骨子” を示します（自社名やシステム名だけ埋めれば完成する形）。
| 項目 | 記載する内容（例） | ポイント |
|---|---|---|
| 新規端末の受入 | Secure Boot 有効、DB に Windows UEFI CA 2023、PCA2023-PXE 起動確認 | “2023 のみ”条件にせず、起動可否で担保 |
| 再イメージ手順 | 原則 PCA2023-PXE。例外は Legacy-PXE を使う条件と場所を限定 | 例外運用を “限定” しないと誤爆が増える |
| 対策適用フロー | Mitigation 1/2 → メディア更新完了 → Mitigation 3/4 | 失効の前に“起動に使うもの”更新を完了させる |
| 監視 | WindowsUEFICA2023Capable、イベント 1036/1799/1037、失敗端末の機種別集計 | 失敗は必ず出る前提で “拾える仕組み” を先に作る |
| 緊急復旧 | 復旧 USB（2023 対応）配布、BitLocker 回復キー手順、OEM/BIOS 更新手順 | 復旧手段が無い状態で失効を入れない |
まとめ：混在を“前提”に設計すれば、詰まない
Secure Boot の証明書切り替え（2011→2023）と CVE-2023-24932 対策は、端末のセキュリティを上げる一方で、PXE/WinPE など “再展開の生命線” を簡単に止めてしまいます。そこで、混在期間は二系統の起動経路で逃げ道を確保し、Mitigation 3（失効）は最後に回す。これだけで「再イメージ不能」という最悪の事故をかなりの確率で避けられます。新規端末の受入基準も “2023 のみ”に寄せるのではなく、DB/boot manager/PXE 起動の事実で担保し、2026 の証明書期限を見据えて 2023 前提の運用へ収束させていきましょう。
コメント