目次

• はじめに
• 3分でわかる要点
• そもそも何の話？
• 業務影響
• 確認対象リソース
• 対象判断方法
• 対応イメージ
• ゴール（更新完了条件）
• まずは該当リソースの棚卸し
• 対応詳細
• まとめ

はじめに

2026年に入り、MicrosoftからSecure Boot2023証明書への移行に関するリタイア案内を受け取った方も多いのではないでしょうか。
私自身、本件を調査した際に、下記のような印象を持ちました。

• 自社環境にどの程度影響があるのか分からない
• 何が対象なのか分かりにくい
• 個別の情報はあるものの全体像が把握しづらい
• Microsoft公式情報が複数ページに分散している

本記事では、Microsoftの公開情報や問い合わせ結果をもとに、Azure上のWindows VM運用者向けに、下記観点で出来るだけ端的に整理しつつ、この記事を読めば対応可能になっていただける状態を目指します。

• 本事象の概要
• 業務影響
• 対象リソース
• 対応方法

本記事は2026年9月時点の情報に基づいています。
なお後述の内容は、Windows  Serverだけでなく、Windows 11にも同様の観点・手順で対応可能な内容となっております。
「この記事を読めば対応可能」を目指しており、情報を本記事に集約していることから、Windows VMだけでも目次記載の通りのボリューム感です。
実はLinux VMもSecure Bootを利用していればこちらも更新対応の対象なのですが、こちらまで記載すると煩雑さも出てくるため、本記事では取り扱いません。

内容は多めですが、実際の対応に必要な情報をまとめていますので、必要な箇所からご参照いただければ幸いです。

3分でわかる要点

時間がない方向けに、まず結論だけまとめます。

業務影響

• Secure Boot 2011証明書は2026年6月に有効期限切れ（※「失効」ではない）
• 現時点で直ちにVMが起動不能になるわけではない（※将来的に失効対象となった場合、起動へ影響する可能性がある）
• 更新しない場合、今後のSecure Boot保護において脆弱性が改善されないままとなる（そのため早急な2023証明書への移行がMicrosoftより推奨されている）

Azure環境における主な対象

• Trusted Launch VM（トラステッド起動 VM）
• Confidential VM（機密 VM）
• バックアップ
• スナップショット
• カスタムイメージ

実施内容

• 対象リソースの棚卸し
• バックアップ取得
• 累積更新プログラム適用
• Secure Boot証明書更新
• 更新結果確認

対応完了条件

• UEFIに 2023 系の証明書が登録されている
• Windows Boot Manager が Windows UEFI CA 2023 で署名されている
• レジストリ値 UEFICA2023Status が Updated となっている

そもそも何の話？

「知見がないけど自社に関係あるかも…」
という方向けに概要をご説明します。

まず、Secure Bootを簡単に説明すると、「サーバー起動時に、不正なプログラムがOSより先に実行されることを防ぐ仕組み」です。
また、Secure Boot証明書とは、「起動時に実行してよいプログラムの許可リスト」と考えると分かりやすいでしょう。

近年、BlackLotusに代表されるUEFIレベルの攻撃手法が注目されるようになりました。これらの攻撃では、OSより前に動作するブートプロセスを悪用することで、セキュリティ対策の穴を突こうとします。
 Microsoftはこれらへの対策として、従来利用していた「Microsoft UEFI CA 2011」を中心とした信頼基盤から、「Microsoft UEFI CA 2023」を利用する新しい信頼基盤への移行を進めています。

なお、Secure Boot 2011証明書の有効期限到来そのものは、CVE-2023-24932への対応として新たに設定されたものではありません。2011証明書は発行当初から有効期限が定められており、その更新時期と、BlackLotus対策として進められたSecure Boot信頼基盤の刷新時期が重なったことで、現在のSecure Boot 2023証明書への移行が推進されています。

今回の証明書移行対応は、

• Secure Boot保護の強化
• 新しい信頼基盤への移行
• 将来的なセキュリティリスク低減

を目的としたものです。

業務影響

まず押さえておきたいのは、2011証明書の有効期限切れ = 即サービス停止ではない、という点です。

私も最初は「2026年6月以降にサーバーが起動しなくなるのでは？」と思いましたが、そうではありません。現時点では、2011証明書のみを利用している環境でも通常どおり起動します。
ただし、前述のようにセキュリティリスクとして移行が推奨されています。
今すぐ障害になる問題ではないが、将来に向けて対応しておくべき運用課題、と考えるのが適切でしょう。

確認対象リソース

対象となるのは、単純なVMだけではありません。  以下のリソースも確認対象になります。

• Trusted Launch（トラステッド起動） VM
• Confidential （機密）VM
• バックアップ
• スナップショット
• Azure Compute Galleryのカスタムイメージ

 また、対象は第2世代（Generation 2）VMです。 第1世代VMはTrusted Launchを利用できないため、本事象の対象外となります。

Microsoftの通知では、「2024年4月以前に作成されたVMアーティファクト」が対象とされていますが、実運用上は、Secure Bootが有効なVMを棚卸しし、実際の状態を確認する方が確実であると個人的には考えています。

対象判断方法

大まかな判断フローは以下です。

重要なのは、

• UEFI証明書
• Windows Boot Manager

の両方が更新されていることです。 どちらか片方だけでは移行完了とは言えません。

対応イメージ

As-Is（対応前）

対応前は、UEFI（OS起動前の領域）が Microsoft UEFI CA 2011 を信頼して起動しています。
UEFI側で保有している情報の更新だけでなく、OS側で保有している情報の更新が必要であることにご注意ください。

To-Be（対応後）

対応後は、UEFI側にて

• Microsoft Corporation KEK 2K CA 2023
• Microsoft UEFI CA 2023
• Windows UEFI CA 2023※
• Microsoft Option ROM UEFI CA 2023※

といった新しい証明書が利用され、OS起動時には「Microsoft UEFI CA 2023」が利用されます。
上記※がついた証明書は、環境によって存在しない場合があります。
なお、2011証明書と2023証明書が共存する状態は正常です。

ゴールイメージ（証明書更新対応の完了条件）

本対応は、以下3つをすべて満たした時点で完了と判断できます。

• UEFIに Secure Boot 2023 証明書が登録されている
• Windows Boot Manager が Windows UEFI CA 2023 で署名されている
• レジストリ値 UEFICA2023Status が Updated となっている

以降の手順では、この状態を目指して確認・更新を実施します。
Microsoftでは主に UEFICA2023Status による確認方法を案内していますが、本記事では運用者がより確実に状態を確認できるよう、UEFI証明書およびWindows Boot Managerの状態確認も実施する前提で整理しています。

まずは該当リソースの棚卸し

前述の通り、本対応はVM本体だけではなく、バックアップ、スナップショット、カスタムイメージも確認対象となります。
そのため、まずは自社環境のどのリソースが影響対象となるのかを把握しましょう。
棚卸し作業は以下5項目あり、対象候補を絞った後の特定作業に関しては、理解するまで少しややこしく感じます。（分かってしまえば単純です）

• 1. 調査候補対象VMの抽出
• 2. 対象VMの特定
  　+UEFI側、Secure Boot 2023証明書インストール状況の確認
  　+OS側、Boot Manager更新状況の確認
  　+レジストリ内、UEFICA2023Statusの確認
• 3. Azure Backupの確認
• 4. スナップショットの確認
• 5. カスタムイメージの確認

1. 調査候補対象VMの抽出

最初に、Secure Bootを利用しているVMを洗い出します。
Azure Cloud ShellをPowerShellモードで起動し、以下のコマンドを実行します。

Get-AzVM | Select-Object `
Name, ResourceGroupName, HyperVGeneration, `
@{Name="OS";Expression={$_.StorageProfile.OsDisk.OsType}}, `
@{Name="SecureBootEnabled";Expression={$_.SecurityProfile.UefiSettings.SecureBootEnabled}}, `
@{Name="vTpmEnabled";Expression={$_.SecurityProfile.UefiSettings.vTpmEnabled}}, `
@{Name="SecurityType";Expression={$_.SecurityProfile.SecurityType}} `
| Export-Csv -Path ./vm-secureboot.csv -NoTypeInformation -Encoding UTF8

出力されたCSVファイルをダウンロードし、「SecureBootEnabled」が TRUE  のVMを抽出します。

まずはこの一覧が、今回の調査候補となります。
なお、SecureBootEnabled=True のVMが全て更新対象という訳ではありません。
この時点では調査候補を抽出している状態であり、後続の手順で Secure Boot 2023 証明書および Windows Boot Manager の更新状況を確認した結果、未対応であることが判明したVMのみが対応対象となります。

2. 対象VMの特定

下記3点の確認結果を基に対応すべきVMの特定を実施します。

• UEFI側、Secure Boot 2023証明書インストール状況の確認
• OS側、Boot Manager更新状況の確認
• レジストリ内、UEFICA2023Statusの確認

上記3点が完了していることが確認出来たら、本対応が完全に完了していると判断できます。
本記事ではコマンドでの確認方法をご紹介しますが、コマンド実行結果としてFalseやUpdated以外の値が返ってきた場合、そのVMは更新対応の対象となります。
下記にて、具体的な確認方法を案内します。

■UEFI側、Secure Boot 2023証明書インストール状況の確認

調査対象VMが特定できたら、各VMでSecure Boot 2023証明書の適用状況を確認します。
まず、UEFI側の証明書のインストール状況を確認します。
環境によっては『Microsoft Corporation UEFI CA 2011』が存在しない場合もあります。
存在する場合は4コマンド、存在しない場合は2コマンド実行します。
管理者権限のPowerShellで以下を実行します。

[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Microsoft Corporation UEFI CA 2011'

実行結果が True の場合は後述Aの手順を、False の場合は後述Bの手順を実施します。

【A:実行結果が True の場合】以下の4つのコマンドを管理者権限で実行します。

[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Microsoft UEFI CA 2023'

[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Microsoft Option ROM UEFI CA 2023'

[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI kek).bytes) -match 'Microsoft Corporation KEK 2K CA 2023'

[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023'

実行結果が全てTrueの場合、UEFIにおける証明書更新は完了しています。
False の場合は、UEFIにおける2023証明書のインストールが必要です。

【B:実行結果が False の場合】以下の2つのコマンドを管理者権限で実行します。

[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI kek).bytes) -match 'Microsoft Corporation KEK 2K CA 2023'

[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023'

実行結果が全てTrueの場合、UEFIにおける証明書更新は完了しています。
False の場合は、UEFIにおける2023証明書のインストールが必要です。

■OS側、Boot Manager更新状況の確認

 Secure Boot証明書だけではなく、Windows Boot Managerが新しい証明書で署名されていることも確認する必要があります。
管理者権限のPowerShellで以下を実行します。

mountvol s: /s

(Get-PfxCertificate "S:\EFI\Microsoft\Boot\bootmgfw.efi").Issuer -match "Windows UEFI CA 2023"

mountvol s: /d

※ s: は未使用ドライブレターを指定してください。

結果がTrueであれば更新済みです。
False の場合は、OSにおけるBoot Managerの更新が必要です。

■レジストリ内、UEFICA2023Statusの確認

Microsoft から案内されているのは下記方法による確認です。前述2点に加え、こちらも確認しましょう。
管理者権限のPowerShellで以下を実行します。

Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing\" -Name UEFICA2023Status

結果が Updated となっていることを確認します。
Updated以外のステータスの場合、証明書の更新が未対応か過渡期であることを示します。

3. Azure Backupの確認

VM本体だけでなく、バックアップも確認対象です。
Recovery Servicesコンテナーからバックアップアイテムを確認し、前述「対象VMの特定」の結果を基に、対象VMに紐づくバックアップが存在するか確認します。
古いバックアップをリストアした場合、移行前の状態に戻る可能性があるためです。
対象VMのバックアップが存在する場合は、VMへのSecure Boot 2023証明書適用後に、新しいバックアップを取得することを推奨します。
また、元となるVMが存在せずバックアップのみ残っている場合も、利用予定があり、且つ証明書未更新の可能性があるバックアップアイテムは、リストアの上確認を実施するのが良いと思います。

4. スナップショットの確認

Azure Backupとは別に、スナップショットも確認対象となります。
前述「対象VMの特定」の結果を基に、Azureポータルの「スナップショット」から対象VM由来のスナップショットが存在するか確認します。
一般的には以下のような命名規則から元VMを特定できます。

<VM名>_OsDisk_<枝番>_<ランダム文字列>

対象VMのスナップショットが存在する場合は、Azure Backup同様、VM対応後にスナップショットを再取得することを推奨します。

5. カスタムイメージの確認

Azure Compute Galleryを利用している場合は、カスタムイメージも確認しましょう。
以下の条件を満たすイメージは確認対象です。

• OS種別：Windows ※
• VM世代：V2
• セキュリティの種類：Trusted Launch/Confidential

※Linuxも第2世代VMで、且つTrusted Launch/Confidentialであれば確認対象ですが、本記事では取り扱いません。

カスタムイメージ自体の証明書状態が不明な場合は、一度VMを展開し、前述の確認コマンドで証明書状態とBoot Managerの状態を確認します。
未対応のイメージを放置すると、将来そのイメージから展開したVMが再び未対応状態となる可能性があるためです。
こちらも更新対象となった場合は、VM対応後にカスタムイメージの更新を実施することを推奨します。

対応詳細

ここからは、更新対象を特定したＶＭに対して実施する手順を案内します。大きく下記4つの手順に分かれています。

• VMバックアップ取得
• 累積更新プログラム適用
• 証明書更新処理
• 更新結果確認

なお、Boot Manager独自の対応の解説に焦点を絞るため、バックアップ方法や累積更新プログラムの適用方法の詳細手順は割愛させていただきます。

① VMバックアップ取得

更新対応対象が特定出来たら次はバックアップ取得を強くお勧めします。
起動プロセスに関係する変更であるため、切り戻し手段を確保した状態で実施することを推奨します。
特に以下のサーバーは影響調査実施、検証環境がある場合は検証後に対応実施するなど、慎重に対応しましょう。

• Active Directory等の認証基盤サーバー
• 基幹業務システム
• 長期間更新していないサーバー

②累積更新プログラム適用

Microsoftは段階的にSecure Boot 2023対応機能を提供しています。
そのため、証明書更新前に累積更新プログラムを適用します。
要件の目安は以下です。

• 推奨：2026年4月以降
• 代替：2026年1月以降
• 最低ライン：2025年11月以降

③ 証明書更新処理

必ず累積更新プログラムが要件を満たしていることを確認した後に、本手順を実施してください。
※古いバージョンの場合、証明書更新処理が正常に動作しない可能性があります。

本手順では、大きく下記を実施します。

• レジストリ設定
• Secure Boot更新タスク実行
• 再起動

1. レジストリの設定

OSのPowerShellにて下記コマンドを管理者権限で実行します。

reg add HKLM\SYSTEM\CurrentControlSet\Control\Secureboot /v AvailableUpdates /t REG_DWORD /d 0x5944 /f

2. Secure Boot 証明書更新処理の実行開始

OSのPowerShellにて下記コマンドを管理者権限で実行します。

Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update"

3. 再起動実施

前述「Secure Boot 証明書更新処理の実行開始」手順実行後、10分程度待機します。
待機後、手動での再起動を実行します。

④ 更新結果確認

更新後は、前述「対象VMの特定」で実施した内容と同じ方法で以下を確認します。

• UEFIに2023系の証明書が登録されていること
• Windows Boot Manager が Windows UEFI CA 2023 で署名されていること
• UEFICA2023Status が Updated であること

上記3つ全てを満たした場合、移行完了です。

まとめ

Secure Boot 2011証明書は既に一部有効期限を迎えていますが、現時点でAzure VMが一斉に停止するような事象ではありません。
一方で、MicrosoftはSecure Boot 2023証明書を前提とした保護強化を進めており、今後のセキュリティ対策や更新プログラムへの継続的な対応を踏まえ、移行対応は実施しておくことがMicrosoft からも推奨されています。
また、VM本体だけでなく、

• バックアップ
• スナップショット
• カスタムイメージ

も確認対象であることもポイントとなります。

まずは対象リソースの棚卸しから始め、自社環境がどの状態にあるのかを把握することが、最初の一歩になるでしょう。