『Windowsが起動できなくなる』って本当？自分のPCのSecure Boot 2023移行状態をPowerShellで覗いてみた

Microsoft Windows PowerShell コンピュータ セキュリティ

Noteの方で「コンサルに『2026年にWindowsが起動できなくなる』と言われたので、本当か実機で調べてみた」という話を書きました🙂

note.com

Noteの記事では、技術的なディテールはあえてバッサリ削っているのですが、こちらを読んでいる方は「どう調べたか、何が見えたか」のほうが気になる方も多いかなと思い、PowerShellを実際にどう叩いて、何が返ってきて、どこで詰まって、どう解釈したかを中心にまとめてみます😊

正直、調べていくうちにいくつかハマりポイントもあって、自分が引っかかった経緯も含めて書いておきたかったんですよね。

⚠️ 本記事の情報は2026年5月時点のものです。Microsoftの段階展開の状況は時間とともに変わるので、最新情報は公式ドキュメントもあわせて確認してみてください。

📘 この記事は調査の経緯の流れを書いています。「先にコマンドと判定の手順をまとめて見たい」「自分のPCで実行できる完成スクリプトが欲しい」という方は、Zennのほうに手順書としてまとめてありますので、そちらを先にご覧ください。

zenn.dev

背景：2026年に何が起きるのか

背景はこんな話です。

WindowsのSecure Bootという仕組みは、起動時に「変なプログラムが紛れ込んでいないか」を証明書ベースで検証する仕組みであり、検証に使われる証明書のうち、Microsoftが2011年に発行したものが2026年に期限切れを迎えるという話となります。

証明書としてはこの3つがあります。

証明書 期限
Microsoft Corporation KEK CA 2011 2026年6月24日
Microsoft UEFI CA 2011 2026年6月27日
Microsoft Windows Production PCA 2011 2026年10月19日

ここでは、「2026年10月まで」となっているので時間があると思いがちですが、最初の期限は6月24日となるようです。

そして、Microsoftは「2023年版の後継証明書を全PCに配信して、ブートローダーも2023年版署名のものに置き換えていく」処理（Windows Updateを使用する）を行なっていきます。この処理は段階的に進行しています。

では、その段階展開が自分のPCではどこまで進んでいるのか？を実機で確認するというのが今回の内容となります🙂

1. 検証環境と前提条件

今回の検証では、自分の手持ちのIntel 12th GenノートPC（Windows 11 25H2）です。このPCのは私が自宅でメインで使っているPCで、BitLockerはOFFにしてあります（個人用なので😎）。

確認はすべて読み取り系のコマンドのみとなるので、確認の作業は安全です。ただし、EFIシステムパーティション（ESP）の一時マウントは行います。この点は注意となります。

また、作業で使用するPowerShellは管理者権限で起動します。タスクバーの【スタートボタン】を右クリックし、【ターミナル（管理者）】を選択して起動を行います。

⚠️ PowerShellのバージョンも確認しておくと良いです。後で書きますが、Windows標準のPowerShell 5.1とPowerShell 7系で挙動が違うコマンドがあるようです。

PS> $PSVersionTable.PSVersion

自分の環境では 5.1.x でした。Windows標準のものですね。ここからはPowerShell 5.1を前提に話を進めていきます。

2. Secure Bootが有効かを確認する

最初は前提条件のチェックから。

PS> Confirm-SecureBootUEFI

結果は True。Secure Bootは有効です。レガシーBIOSの機械やSecure Bootが無効化されている機械では False になったりエラーになったりするので、まずここを確認します。

ついでにOSとファームウェアの情報も。

PS> Get-ComputerInfo | Select-Object WindowsProductName, OsBuildNumber, BiosFirmwareType, BiosManufacturer, BiosVersion
WindowsProductName : Windows 10 Pro
OsBuildNumber      : 26200
BiosFirmwareType   : Uefi
BiosManufacturer   : Dynabook Inc.
BiosVersion        : DYNABO - 1072009

⚠️ ここで「あれ、Windows 10 Proって出てる？🤔」と焦ったんですが、これは Get-ComputerInfoコマンドの既知の挙動で、Windows 11上でも内部識別子の都合で「Windows 10 Pro」と返ってくることがあるそうです😅 ビルド番号が 26200 なのでWindows 11 25H2です。

これで前提条件はOK。Secure Boot有効・UEFI・対応OSというところまで確認できました。

3. UEFIに登録されている証明書を覗いてみる

UEFIには「KEK（Key Exchange Key、鍵交換鍵）」と「db（Signature Database、許可された署名のデータベース）」という領域があり、ここに証明書が格納されています。この部分を確認することで、自分のPCが新しい証明書（2023年版）を受け入れる準備ができているかがわかります。

PowerShellの Get-SecureBootUEFI というコマンドで内容を確認できます。

PS> $kek = Get-SecureBootUEFI -Name KEK
PS> $kek.Bytes.Length
4166

4166バイト返ってきました。領域に証明書は入っているようです。が

バイナリの書き出しにハマる

最初、自分は何も考えずに certutil -asn でこのバイナリを解析しようとしたんですが、出力が空でした🤔

PS> $kek.Bytes | Out-File -FilePath "$env:TEMP\kek.bin" -Encoding Byte
# → Out-File : パラメーター 'Encoding の引数を確認できません。引数 "Byte" は…

⚠️ PowerShell 5.1では Out-File -Encoding Byte が使えないのです。PowerShell 7以降だと -AsByteStream に置き換わっているそうです。

ここは [System.IO.File]::WriteAllBytes() を使うようです。

PS> [System.IO.File]::WriteAllBytes("$env:TEMP\kek.bin", $kek.Bytes)

これでエラーはなくなったのですが…

これでも certutil -asn の出力は空のまま🙄

EFI_SIGNATURE_LIST構造のパース

更に調べると、原因はGet-SecureBootUEFI が返すバイナリは、生のX.509証明書ではなく、UEFI仕様の EFI_SIGNATURE_LIST 構造体に包まれた形になっているんですね。

構造はこんな感じというわけです。

[16 byte GUID][4 byte size][4 byte size][4 byte size][...証明書本体...]
[16 byte GUID][4 byte size][...次の証明書...]
...

certutil -asn はASN.1形式（X.509そのもの）を期待しているので、先頭がGUIDで始まるこのバイナリデータでは「何これ？」となって何も返してくれないわけです🙃

ということで、自分でEFI_SIGNATURE_LISTをパースするPowerShell関数を作ります。この関数をターミナルから入力して実行しておきます。

function Show-SecureBootCertificates {
    param([ValidateSet('PK','KEK','db','dbx')][string]$VariableName)

    Write-Host ""
    Write-Host "===== $VariableName =====" -ForegroundColor Cyan
    $var = Get-SecureBootUEFI -Name $VariableName
    $bytes = $var.Bytes
    Write-Host "Total bytes: $($bytes.Length)"

    # EFI_CERT_X509_GUID を mixed-endian バイト列で
    $x509Guid = [byte[]](0xa1,0x59,0xc0,0xa5,0xe4,0x94,0xa7,0x4a,0x87,0xb5,0xab,0x15,0x5c,0x2b,0xf0,0x72)

    $offset = 0
    while ($offset + 28 -le $bytes.Length) {
        $listSize   = [BitConverter]::ToUInt32($bytes, $offset + 16)
        $headerSize = [BitConverter]::ToUInt32($bytes, $offset + 20)
        $sigSize    = [BitConverter]::ToUInt32($bytes, $offset + 24)

        $isX509 = $true
        for ($i = 0; $i -lt 16; $i++) {
            if ($bytes[$offset + $i] -ne $x509Guid[$i]) { $isX509 = $false; break }
        }

        if ($listSize -le 28 -or $listSize -gt ($bytes.Length - $offset)) { break }

        if ($isX509) {
            $cursor = $offset + 28 + $headerSize
            while ($cursor + $sigSize -le $offset + $listSize) {
                $certBytes = New-Object byte[] ($sigSize - 16)
                [Array]::Copy($bytes, $cursor + 16, $certBytes, 0, $sigSize - 16)
                try {
                    $cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2(,$certBytes)
                    Write-Host "  [Cert]" -ForegroundColor Green
                    Write-Host "    Subject  : $($cert.Subject)"
                    Write-Host "    NotBefore: $($cert.NotBefore)"
                    Write-Host "    NotAfter : $($cert.NotAfter)"
                    Write-Host "    Thumbprint: $($cert.Thumbprint)"
                } catch {
                    Write-Host "  [Cert] パース失敗" -ForegroundColor Red
                }
                $cursor += $sigSize
            }
        }
        $offset += $listSize
    }
}

EFI_CERT_X509_GUID の値はUEFI仕様書にあります。

そして、以下のコマンドを実行します。

PS> Show-SecureBootCertificates -VariableName KEK
===== KEK =====
Total bytes: 4166
  [Cert]
    Subject  : CN=Microsoft Corporation KEK CA 2011, ...
    NotBefore: 06/25/2011 05:41:29
    NotAfter : 06/25/2026 05:51:29
  [Cert]
    Subject  : CN=Dynabook Inc. KEK CA 2019, ...
    NotBefore: 01/01/2019 00:00:00
    NotAfter : 12/31/2033 23:59:59
  [Cert]
    Subject  : CN=Microsoft Corporation KEK 2K CA 2023, ...
    NotBefore: 03/03/2023 05:21:35
    NotAfter : 03/03/2038 05:31:35

おぉ、3つのKEKが入っているようです😎

よく見ると…

  • Microsoft Corporation KEK CA 2011（2026年6月期限）← これが今回問題になる古いやつ
  • Dynabook Inc. KEK CA 2019（2033年期限）← Dynabook独自のOEM証明書
  • Microsoft Corporation KEK 2K CA 2023（2038年期限）← 新しい後継証明書、もう入ってる！

つまり、KEK側は既に新旧の両方が共存している状態。後継証明書を受け入れる準備ができている、ということです✨

dbも同様に見てみます。

PS> Show-SecureBootCertificates -VariableName db
===== db =====
Total bytes: 4153
  [Cert]
    Subject  : CN=Microsoft Windows Production PCA 2011, ...
    NotAfter : 10/20/2026 03:51:42
  [Cert]
    Subject  : CN=Dynabook Inc. Utility CA 2019, ...
    NotAfter : 12/31/2033 23:59:59
  [Cert]
    Subject  : CN=Windows UEFI CA 2023, ...
    NotAfter : 06/14/2035 04:08:29

こちらも新旧並んで格納されています。Microsoft Windows Production PCA 2011（古い）とWindows UEFI CA 2023（新しい）が共存しています。

この確認作業で「新しい証明書の配信は完了している」ことが確認できました🤩

⚠️ ちなみに、Dynabook独自の証明書がKEK/db両方に入っているのは、OEMが独自にファームウェア更新ユーティリティなどに署名できるようにしている仕組みです。Dell・HP・Lenovoなど多くのOEM機で同様の構成になっているようです。

💡 「自分のPCのKEK/dbに何が入ってるか、結果別の判定はどうなるの？」という方は、Zennの手順書に4パターンの判定マトリクスを整理してあります。「2023系がない場合」「片方だけある場合」「両方ある場合」それぞれの次のアクションが一覧できます。

👉 Zenn手順書のステップ2の判定表を参照

4. Boot Manager本体の署名を確認する

証明書は受け入れ準備できているということがわかりました。次は「じゃあ実際に起動しているプログラム本体は、新しい方で署名されてるか？」を確認します。

WindowsのBoot Manager本体（bootmgfw.efi）は、EFIシステムパーティション（ESP）に置かれています。普段はマウントされていないので、mountvol で一時的にマウントします。

PS> mountvol S: /S
PS> $sig = Get-AuthenticodeSignature -FilePath "S:\EFI\Microsoft\Boot\bootmgfw.efi"
PS> mountvol S: /D
PS> $sig.SignerCertificate | Select-Object Subject, Issuer, NotBefore, NotAfter | Format-List
Subject   : CN=Microsoft Windows, ...
Issuer    : CN=Microsoft Windows Production PCA 2011, ...
NotBefore : 2025/06/20 3:11:44
NotAfter  : 2026/06/18 3:11:44

Issuerが2011のまま？🤔

つまり、現状の状態を整理するとこんな感じです：

  • ⭕️ KEK/dbには新しい2023証明書が既に入っている
  • ❌ 実際に起動に使われているbootmgfw.efiは、まだ2011系統の証明書（Microsoft Windows Production PCA 2011から派生したリーフ証明書）で署名されたまま

これは中途半端な状態では？🤷‍♂️ 「証明書は入った、でもBoot Manager本体はまだ古い系統のまま」という状態です。

最初は「あれ、なんで完全に切り替わってないの？」と思ったんですが、これはMicrosoftの意図的な処理なのかもしれません。

5. レジストリでMicrosoftの判断を読み解く

Windowsには HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing というレジストリキーがあって、ここにMicrosoftのSecure Boot移行に関する情報が記録されています。

PS> $path = "HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing"
PS> Get-ItemProperty -Path $path | Select-Object * -ExcludeProperty PS* | Format-List
WindowsUEFICA2023Capable    : 2
UEFICA2023Status            : Updated
BucketHash                  : ...（伏字）
ConfidenceLevel             : High Confidence
LastParsedBucketDataVersion : 15
ConfidenceUpdateType        : 22852
RebootRequestedDB           : 1
RebootRequestedKEK          : 1

各値の意味はMicrosoftのドキュメントを読みつつ整理するとこんな感じになります。

キー 値 意味
WindowsUEFICA2023Capable 2 参考値。値2は「Windows UEFI CA 2023 が DB にあり、2023署名 Boot Manager から起動している」状態（公式は状態確認には UEFICA2023Status を推奨）
UEFICA2023Status Updated 状態確認の正式な指標。展開完了状態
ConfidenceLevel High Confidence Microsoft が「このマシンには自動配信していい」と検証済みのバケット
ConfidenceUpdateType 22852（=0x5944） 将来実行予定のアクション種別
RebootRequestedDB 1 過去に DB 更新で再起動を要求した履歴
RebootRequestedKEK 1 過去に KEK 更新で再起動を要求した履歴

RebootRequestedBootManager というキーが存在しないことがポイントです。これは、「過去にDBとKEKについては再起動を要求したけれど、Boot Managerについては一度も要求していない」ことを意味します。

つまり、このPCに対して

  • 🙆‍♂️DBとKEKの更新は要求済み・適用済み
  • 🙅‍♂️Boot Manager本体の置換は、まだ要求をしていない

という状態になります。

⚠️ConfidenceUpdateType = 22852 ですが、10進22852 = 16進0x5944で、これは「全アクションを実行」を意味するビットマスクです。Microsoft公式のトラブルシューティング手順で、強制適用するときに AvailableUpdates = 0x5944 を設定する話があるので、同じビットマスクがあることで「将来このマシンには0x5944相当のアクションを実行する予定」なのかなと予想ができます。

💡 ConfidenceLevel には他にも Under Observation - More Data Needed や Temporarily Paused、Not Supported - Known Limitation などの値があるそうです。どの値だとB判定（経過観察）で、どの値だとC判定（要対応）になるかは、Zennの手順書で結果パターンと判定の全マトリクスとして整理しました。

👉 Zenn手順書のステップ4・結果パターンと判定

6. イベントログでアップデートの動きを追う

レジストリだけだと現時点のスナップショットしか見えないので、過去の動きを知るためにイベントログも見てみます。

PS> Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='*TPM*'} -MaxEvents 30 -ErrorAction SilentlyContinue |
    Select-Object TimeCreated, Id, ProviderName, Message |
    Format-List

そうしたら、Event ID 1808が見つかりました👀

TimeCreated  : 2026/05/24 13:08:45
Id           : 1808
ProviderName : Microsoft-Windows-TPM-WMI
Message      : このデバイスはセキュア ブート CA/キーを更新しました。
               このデバイス署名情報はここに含まれています。
               DeviceAttributes: FirmwareManufacturer:Dynabook Inc.;
                                 FirmwareVersion:Version 8.30;...
               BucketId: 9d35a6967a...
               BucketConfidenceLevel: High Confidence
               UpdateType: Windows UEFI CA 2023 (DB), 
                           Option ROM CA 2023 (DB), 
                           3P UEFI CA 2023 (DB), 
                           KEK 2023, 
                           Boot Manager (2023)

ここで一瞬「あれ、Boot Manager (2023)もUpdateTypeに入ってる？じゃあもう移行完了してるの？？」と思ったんですが、よく読むと違うんですよね。

Event 1808は「セキュアブートCA/キー更新完了」のイベントで、UpdateType フィールドは「このマシンの対象範囲としての識別タグ」を示しているっぽい。実際のBoot Manager本体の置換が完了したわけではなく、「このマシンは将来Boot Manager 2023への置換対象である」というラベル付けのようです。

Microsoft公式のEvent 1808の説明では「必要な証明書が適用され、Boot ManagerもWindows UEFI CA 2023署名版に更新された完全更新状態を示す」と書かれています。もう少し噛み砕くと、

  • UpdateType フィールドに列挙されている各項目について「対象である」または「処理した」
  • 完全更新済みなら、すべての項目が処理済み

という解釈になるのかもしれません。とはいえ実機の bootmgfw.efi 署名は2011のままだったので、現時点ではまだ完全更新は来ていないということでしょうか。

このあたりのMicrosoft公式説明と実機状態の解釈には、検証の余地があるかなと感じています（未検証）🤔

7. わかったこと（アップデートの段階展開）

整理することで見えてくるのは、MicrosoftのSecure Boot 2023移行は4段階で進めているようです。

①新しい証明書をKEKとdbに追加         ← 自分のPCは完了
　↓
②Boot Manager本体を2023署名版に置換    ← 自分のPCはまだ
　↓
③古い2011証明書をdbxで失効（任意）
　↓
④最終的に2011証明書を完全廃止

そして①と②の間に時間の間隔を空けている。アップデートを慎重に行なっているからなのかもしれません。

Boot Manager本体の置換は、起動できるかどうかに直結する。失敗したら本当に起動不能になる。 だから、まず新しい証明書をすべてのPCに行き渡らせて、受け入れ準備が完全に整ってから、後追いでBoot Manager本体を置き換える。

Microsoftの慎重さを感じます💪（そうなってくれるのが望ましいですが、どうだろうか？）

そして、ここで重要な気づきが一つ。

「Windowsが起動できる」≠「Secure Boot 2023移行が完了している」

これが大きなポイント。仮に何もしないまま2026年10月（Microsoft Windows Production PCA 2011の期限）を過ぎても、Windows自体は普通に起動し続けます。ファームウェアに既に入っている2011証明書を使って起動できるわけですから。

問題は、それ以降に新しい更新が来たとき。新版が2023で署名されていて、もしPCのファームウェアに2023が入っていなければ、検証で弾かれてしまう。これが「将来の初期ブート保護の更新を受けられなくなる」の意味になります。

なので、最終的に確認すべきは「起動できるか」ではなく「Event ID 1808が完了として記録されているか」「bootmgfw.efi のIssuerが Windows UEFI CA 2023 になっているか」ということなんでしょうね。

8. モニタリング体制を作る

ここまでの調査でわかったのは、自分のPCは段階展開の途中（証明書展開済み、Boot Manager置換待ち）ということ。これ自体は問題ない状態なので、あとはいつBoot Manager置換が来るかを観察するだけです。

毎月手動で確認するのは面倒なので、PowerShellスクリプト化してログを取るといいのかなと思います。

# secureboot_monitor.ps1
$path = "HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing"
mountvol S: /S 2>$null
$sig = Get-AuthenticodeSignature "S:\EFI\Microsoft\Boot\bootmgfw.efi"
mountvol S: /D 2>$null

$regProps = Get-ItemProperty $path -ErrorAction SilentlyContinue

$snapshot = [PSCustomObject]@{
    Date              = Get-Date -Format "yyyy-MM-dd HH:mm:ss"
    BootMgrIssuer     = $sig.SignerCertificate.Issuer.Split(',')[0]
    BootMgrNotAfter   = $sig.SignerCertificate.NotAfter.ToString("yyyy-MM-dd")
    Has2023BootMgr    = $sig.SignerCertificate.Issuer -like "*2023*"
    UEFICA2023Status  = $regProps.UEFICA2023Status
    ConfidenceLevel   = $regProps.ConfidenceLevel
    RebootBM          = $regProps.RebootRequestedBootManager
    Error             = $regProps.UEFICA2023Error
}

$logPath = "$env:USERPROFILE\Documents\secureboot_log.csv"
$snapshot | Export-Csv -Path $logPath -Append -NoTypeInformation -Encoding UTF8

$snapshot | Format-List

これで実行するたびにCSVファイル（C:\Users\<ユーザー名>\Documents\secureboot_log.csv）にスナップショットが追記されていきます。

実行結果

"Date","BootMgrIssuer","BootMgrNotAfter","Has2023BootMgr","UEFICA2023Status","ConfidenceLevel","RebootBM","Error"
"2026-05-24 21:28:47","CN=Microsoft Windows Production PCA 2011","2026-06-18","False","Updated","High Confidence",,

タスクスケジューラに登録すれば自動化もできます。

PS> $scriptPath = "$env:USERPROFILE\Scripts\secureboot_monitor.ps1"
PS> $action = New-ScheduledTaskAction `
    -Execute "PowerShell.exe" `
    -Argument "-NoProfile -ExecutionPolicy Bypass -File `"$scriptPath`""
PS> $trigger = New-ScheduledTaskTrigger -Once -At "09:00" `
    -RepetitionInterval (New-TimeSpan -Days 30)
PS> $principal = New-ScheduledTaskPrincipal `
    -UserId "$env:USERDOMAIN\$env:USERNAME" -RunLevel Highest

PS> Register-ScheduledTask `
    -TaskName "SecureBoot2023Monitor" `
    -Action $action -Trigger $trigger -Principal $principal `
    -Description "Secure Boot 2023証明書移行状態の月次モニタリング"

⚠️ New-ScheduledTaskTrigger は -Monthly オプションを直接サポートしてないので、-Once + -RepetitionInterval 30日 で代用しています。確実に毎月1日に動かしたいなら schtasks.exe を使うほうが確実かもしれません（未検証）。

これで、Has2023BootMgr = True になった日が、Boot Manager 2023移行が完了した日ということになります。観察し続けて、Microsoftが実際にいつ自分のPCにBoot Manager置換を配信してくるかを記録に残せます📝

状態遷移の予想はこんな感じでしょうか。

観測時期 Has2023BootMgr RebootBM 状態
今 False （空） 証明書展開済み・Boot Manager 置換未配信
中間 False 1 Boot Manager 置換が要求された・再起動待ち
再起動後 True 1 完全移行完了 🎉

RebootBM が 1 になる瞬間と、再起動後に Has2023BootMgr が True になる瞬間、それぞれログに残るでしょう😊

💡 「もしC判定（要対応）が出たらどう対処するの？」「強制適用 AvailableUpdates = 0x5944 の手順は？」「一括チェックスクリプト（ステップ1〜4を自動判定）はないの？」という方は、Zennの手順書にトラブルシューティングと付録スクリプトも含めて掲載しています。

👉 Zenn手順書のトラブルシューティングと一括チェックスクリプト

おわりに

今回、「Windowsが起動できなくなる」という単純な煽り文句から始まって、実機で深掘りしていったら思った以上にMicrosoftの展開方法が細かく調べるのも大変でした。

調べる前と後の理解は以下のように変わりました。

Before

2026年に証明書期限切れ → Windowsが起動できなくなる → 大変！

After

Microsoftは4段階の段階展開を進めている。多くの一般機（High Confidenceバケット）は自動配信対象で、すでに証明書受け入れ準備は完了している。Boot Manager本体の置換は、慎重に後追いで進められる。「起動できる」と「移行完了」は別。

ちなみに、この記事で触れた判定マトリクス、トラブルシューティング、強制適用の手順、一括チェックスクリプトなど、手順書として完成された版はZennのほうにまとめています。「自分のPCでも試したい」「結果別の対応を一覧で見たい」という方は、そちらのほうが使いやすいと思います。

zenn.dev

「Windowsが起動できなくなる」みたいな話を聞いたときに、慌てず、まず実機を覗いてみる。それだけで、煽りなのか本当のリスクなのかが見えてくるのかもしれません💡

この記事も間違ったことを書いている部分があるかもしれませんので、もし「ここ違うんじゃない？」というところがあれば、ぜひ教えてください🙇