EFI Secure Boot

Signed bootloader sets

• 2011 set: signed through Microsoft Corporation UEFI CA 2011. This is the CA that firmware has used for third-party bootloaders since the introduction of Secure Boot.
• 2023 set: signed through the renewed Microsoft third-party CAs. The main loader (DcsBoot.efi) is signed through Microsoft UEFI CA 2023, while other components (DcsInt.dcs, LegacySpeaker.dcs) are signed through Microsoft Option ROM UEFI CA 2023. For this reason, the 2023 set requires both Microsoft UEFI CA 2023 and Microsoft Option ROM UEFI CA 2023 to be present in the firmware Secure Boot signature database (db).

Diagnostics

HKEY_LOCAL_MACHINE\SOFTWARE\VeraCrypt\Diagnostics\EfiBootLoader
    EfiBootLoaderResourceSet          REG_DWORD  2011 (0x7db) or 2023 (0x7e7)
    EfiBootLoaderSelectionReason      REG_SZ     human readable selection reason
    EfiBootLoaderFirmwareDbLastError  REG_DWORD  last firmware db read/parse error (0 = none)
    EfiBootLoaderFirmwareDbxLastError REG_DWORD  last firmware dbx read/parse error (0 = none)
    EfiBootLoaderSelectionTimeUtc     REG_SZ     time of the last selection
    EfiBootChainStatusKnown           REG_DWORD  db/dbx known-CA assessment is available
    EfiBootChainLastError             REG_DWORD  last incomplete-assessment error (0 = none)
    SecureBootEnabled                 REG_DWORD  Secure Boot state at the last assessment
    FirmwareDbxPresent                REG_DWORD  dbx exists (0 is valid: optional variable absent)
    VeraCryptLoaderFilesValid         REG_DWORD  installed DCS files match one embedded set
    VeraCryptLoaderKnownCaAllowed     REG_DWORD  known required CAs are in db and not in dbx
    VeraCryptLoaderKnownCaRevoked     REG_DWORD  a known required VeraCrypt CA is in dbx
    EfiBootLoaderInstalledResourceSet REG_DWORD  set identified from the actual ESP files
    EfiBootLoaderRecordedResourceSet  REG_DWORD  set recorded at the last successful refresh
    WindowsLoaderInspectionSucceeded  REG_DWORD  embedded PE signature was parsed
    WindowsLoaderPresent              REG_DWORD  bootmgfw_ms.vc was found
    WindowsLoaderSigner               REG_DWORD  0 (unknown), 2011, or 2023
    WindowsLoaderKnownCaAllowed       REG_DWORD  known signing CA is in db and not in dbx
    WindowsLoaderKnownCaRevoked       REG_DWORD  known Windows loader signing CA is in dbx
    WindowsLoaderMigrationRecommended REG_DWORD  PCA 2011 copy remains while CA 2023 is available
    EfiBootChainCheckTimeUtc          REG_SZ     time of the last attempted chain check

reg query HKLM\SOFTWARE\VeraCrypt\Diagnostics\EfiBootLoader /s

$t = [Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).Bytes)
'Microsoft Corporation UEFI CA 2011',
'Microsoft Windows Production PCA 2011',
'Windows UEFI CA 2023',
'Microsoft UEFI CA 2023',
'Microsoft Option ROM UEFI CA 2023' |
  ForEach-Object { "$_ : $($t -match [regex]::Escape($_))" }

try {
  $dbx = (Get-SecureBootUEFI dbx).Bytes
  'Windows PCA 2011 in dbx: ' +
    ([Text.Encoding]::ASCII.GetString($dbx) -match
     'Microsoft Windows Production PCA 2011')
} catch {
  'dbx is absent or could not be read; check FirmwareDbxPresent and EfiBootLoaderFirmwareDbxLastError'
}

# After mounting the EFI System Partition as S:, inspect the embedded signer.
# Do not use Get-AuthenticodeSignature here: it may report a catalog signer.
Get-PfxCertificate -FilePath S:\EFI\Microsoft\Boot\bootmgfw_ms.vc |
  Select-Object Subject,Issuer,Thumbprint

Get-WinEvent -FilterHashtable @{
  LogName='System'
  ProviderName='Microsoft-Windows-TPM-WMI'
  Id=@(1036,1037,1043,1044,1045,1797,1798,1799,1800,1801,1802,1803)
  StartTime=(Get-Date).AddDays(-30)
} | Select-Object TimeCreated,Id,LevelDisplayName,Message

The Microsoft 2023 certificate transition

• Certificate expiration does not normally stop already-installed loaders from booting. UEFI Secure Boot image verification does not normally enforce the signing certificate's validity period, so a loader signed through a 2011 CA is not rejected merely because that CA certificate has expired. Expiration is nevertheless the end of the signing ecosystem for new binaries; systems that never receive the 2023 certificates cannot continue receiving boot-chain updates signed through the replacement CAs.
• Expiration and revocation are separate. Microsoft provides a separate, deliberate mitigation that adds Microsoft Windows Production PCA 2011 to the Secure Boot forbidden signature database (dbx); once applied, every Windows Boot Manager signed through that CA is rejected. This Windows PCA revocation is not part of the 0x5944 certificate/Boot Manager migration described below. As of July 2026, Microsoft states that it has no plan to revoke Microsoft Corporation UEFI CA 2011, the third-party CA used by the VeraCrypt 2011 loader set. Nevertheless, migrating both the VeraCrypt and Windows portions of the chain to their 2023 CAs is recommended before applying any Windows PCA 2011 revocation.

New computers that trust only the 2023 CAs

Updating an existing system to the 2023 certificates

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

rem optionally run the servicing task immediately (it otherwise runs every 12 hours):
schtasks /Run /TN "\Microsoft\Windows\PI\Secure-Boot-Update"

• Update the BIOS/UEFI firmware to the latest version available from the computer manufacturer first. Failures to write the new certificates to the firmware Secure Boot database are usually caused by firmware bugs, and Microsoft recommends checking with the device manufacturer for updated firmware before applying the certificate updates.
• Create or update your VeraCrypt Rescue Disk first, and verify that it boots.
• Record the existing AvailableUpdates value and make sure the device is not already managed by another Secure Boot deployment policy. Setting 0x5944 requests authenticated firmware db/KEK writes and a boot-file replacement. Firmware defects, a missing OEM-authorized KEK, interruption during servicing, or overwriting another pending deployment value can leave the transition incomplete. Use the computer manufacturer's recovery procedure if a firmware variable update fails.
• Do not disable the VeraCrypt System Favorites service or its bootloader update function. When Windows installs a new Boot Manager at the standard ESP location, the service saves it as bootmgfw_ms.vc and restores the VeraCrypt loader. If Windows leaves the standard path unchanged, current VeraCrypt versions also inspect Windows' serviced copies under %SystemRoot%\Boot\EFI_EX and %SystemRoot%\Boot\EFI, verify the embedded signer, and atomically refresh bootmgfw_ms.vc with the best copy permitted by the known firmware CA policy.
• Hidden operating system users should not trigger the update from the hidden OS. The automatic boot-chain preservation is disabled when a hidden OS is running.
• Avoid forced power-off between the moment Windows replaces the boot manager and the next normal restart or shutdown. On most systems the VeraCrypt boot entry keeps the machine bootable during this window, but firmware that ignores the boot order could boot the plain Windows Boot Manager, which cannot start an encrypted Windows (recoverable with the Rescue Disk).
• Windows may continue reporting the transition as incomplete because the standard Windows Boot Manager location contains the VeraCrypt loader by design. Treat this as a possible servicing false negative only after the firmware db contains the required 2023 CAs, EfiBootLoaderInstalledResourceSet identifies the actual 2023 DCS files, the embedded issuer of bootmgfw_ms.vc is Windows UEFI CA 2023, and the event log contains no unresolved Secure Boot servicing failure.

Recovering from a Secure Boot boot failure

• Before the password prompt (message such as "Secure Boot Violation" or an immediate return to the firmware): the firmware policy rejects the installed VeraCrypt loader.
• After successful password entry (an explicit Secure Boot error message from the VeraCrypt loader, or on older loader versions a return to the password prompt): the firmware policy rejects the Windows Boot Manager copy (bootmgfw_ms.vc) that VeraCrypt chainloads.

1. Temporarily disable Secure Boot in the firmware setup and start Windows normally (VeraCrypt pre-boot authentication works with Secure Boot disabled). The VeraCrypt Rescue Disk can restore VeraCrypt loader components when they are missing or damaged, but it cannot manufacture a current Windows Boot Manager or make a PCA 2011-signed bootmgfw_ms.vc acceptable after that CA has been added to dbx; it is not a substitute for completing the Windows migration.
2. In Windows, adjust the firmware/Windows Secure Boot policy as needed (enable the third-party CAs in firmware setup, restore a valid dbx if a custom-key workflow removed it, or apply the Windows Secure Boot certificate updates as described above), then run VeraCrypt Setup in Repair/Reinstall mode. Repair now checks Windows' serviced EFI_EX/EFI copies and can install a compatible current Windows Boot Manager even while the standard ESP path contains VeraCrypt.
3. Review the VeraCrypt diagnostics and embedded signer as described above, then re-enable Secure Boot and perform a controlled reboot. Do not re-enable it while VeraCrypt reports an incomplete policy assessment or incompatible loader files.

Legacy custom-key procedure (deprecated)