EFI Secure Boot

VeraCrypt system encryption is compatible with EFI Secure Boot: the VeraCrypt EFI bootloaders are signed by Microsoft through the Microsoft third-party UEFI signing program, so they can be verified by the firmware using the standard Microsoft certificates without enrolling any custom key. This page explains how VeraCrypt selects its signed bootloaders, how this interacts with the Microsoft Secure Boot certificate transition from the 2011 certificate authorities (CAs) to the 2023 CAs, and how to diagnose and recover from Secure Boot related boot failures.

Signed bootloader sets

Since version 1.26.29, VeraCrypt ships two complete sets of Microsoft-signed EFI bootloaders:

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).

At installation, upgrade, repair and system encryption time, VeraCrypt reads the firmware db and selects the loader set whose signing CAs are trusted. If the 2023 CA pair is present, the 2023 set is preferred; otherwise the 2011 set is used when Microsoft Corporation UEFI CA 2011 is trusted. If Secure Boot is enabled and neither set is trusted by the firmware, VeraCrypt refuses to install its bootloader and displays an error instead of installing a loader that the firmware would reject at the next reboot.

Changing the firmware Secure Boot configuration (for example enabling additional certificates in the BIOS setup) does not by itself rewrite the files already installed on the EFI System Partition. Run VeraCrypt Setup in Repair/Reinstall mode after changing the firmware Secure Boot database, or let the VeraCrypt System Favorites service refresh the loader automatically (it re-evaluates the selection at Windows startup, session logon/unlock, resume from sleep, and shutdown).

Diagnostics

VeraCrypt records which loader set was installed and why under the following registry key:

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)
    EfiBootLoaderSelectionTimeUtc     REG_SZ     time of the last selection

The following commands, run from an elevated PowerShell prompt, show which Microsoft certificates are present in the firmware db (note that on some firmware the names may not be visible in this simple text search even when the certificates are present):

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($_))" }

In addition, the VeraCrypt System Favorites service writes a warning to the Windows Application event log (source VeraCryptSystemFavorites) when it detects that the active Secure Boot db no longer trusts a component of the installed boot chain.

The Microsoft 2023 certificate transition

The Microsoft Secure Boot certificates from 2011 expire in 2026: Microsoft Corporation KEK CA 2011 and Microsoft Corporation UEFI CA 2011 expired in June 2026, and Microsoft Windows Production PCA 2011 expires in October 2026. Microsoft replaces them with 2023 CAs and distributes the new certificates, as well as a Windows Boot Manager signed by Windows UEFI CA 2023, through Windows Update.

Two important points for VeraCrypt users:

Certificate expiration does not stop already-installed loaders from booting. UEFI firmware does not evaluate certificate validity periods during Secure Boot verification, so bootloaders signed through the 2011 CAs continue to load after the expiration dates on virtually all firmware implementations. The expiration means that new binaries can no longer be signed through the 2011 CAs, and that systems which never receive the 2023 certificates will stop receiving boot-chain security updates.
A future revocation of the 2011 CAs would stop them from booting. Microsoft has announced that, at a later stage of the transition (not yet scheduled), the 2011 CAs may be revoked via the Secure Boot forbidden signature database (dbx) on systems that have completed the transition. Migrating to the 2023 loader set before that stage is therefore recommended.

New computers that trust only the 2023 CAs

Some recent computers ship from the factory with a Secure Boot configuration that contains only Windows UEFI CA 2023 and no Microsoft third-party CAs at all. On such systems, the two third-party CAs required by the VeraCrypt 2023 loader set (Microsoft UEFI CA 2023 and Microsoft Option ROM UEFI CA 2023) must first be enabled in the firmware setup. The option is typically called "Allow Microsoft 3rd Party UEFI CA", "Third-Party CA" or "Third-Party Certificates". After enabling it, run VeraCrypt Setup in Repair/Reinstall mode (or start system encryption) so that VeraCrypt selects the 2023 loader set.

If the firmware provides no way to trust a Microsoft third-party CA, VeraCrypt system encryption cannot be used with Secure Boot enabled on that machine.

Updating an existing system to the 2023 certificates

Windows deploys the 2023 certificates through a staged, telemetry-driven rollout. Devices are updated automatically only once Microsoft has high confidence in their hardware/firmware combination. Because a system-encrypted VeraCrypt machine boots through a non-standard boot chain (the VeraCrypt loader occupies the Windows Boot Manager location), such machines are typically not classified for automatic update and the rollout does not trigger on its own. The Windows Security app may report that there is "not yet enough data to classify your device". For the same reason, opting into the Microsoft-managed rollout (the MicrosoftUpdateManagedOptIn registry value) may not be sufficient on these machines.

Microsoft documents a registry value that triggers the update explicitly (see Microsoft KB5068202, "Registry key updates for Secure Boot"). From an elevated command prompt:

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"

Progress can be monitored under HKLM\SYSTEM\CurrentControlSet\Control\Secureboot\Servicing (values UEFICA2023Status and UEFICA2023Error) and through Secure Boot servicing events in the Windows event log. The db update adds Windows UEFI CA 2023, and, on systems that already trust Microsoft Corporation UEFI CA 2011 (which is the case on every VeraCrypt Secure Boot system), it also adds Microsoft UEFI CA 2023 and Microsoft Option ROM UEFI CA 2023.

Before triggering the update on a VeraCrypt system-encrypted machine, take the following precautions:

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.
Do not disable the VeraCrypt System Favorites service or its bootloader update function. When the Windows servicing task installs the 2023-signed Windows Boot Manager at the standard location, this service is what preserves the VeraCrypt boot chain: it saves the new boot manager as bootmgfw_ms.vc (the copy VeraCrypt chainloads after pre-boot authentication) and restores the VeraCrypt loader.
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).
Expect Windows to keep reporting the Secure Boot certificate servicing as not fully completed even after everything works. Windows checks whether the file at the standard boot manager location is the 2023-signed Microsoft Boot Manager; on a VeraCrypt system that location holds the VeraCrypt loader by design. This status is cosmetic and does not affect the security or operation of the system.

After the db update has been applied, VeraCrypt automatically switches to the 2023 loader set the next time the bootloader is refreshed (Repair/Reinstall, upgrade, or one of the automatic refresh points of the System Favorites service). You can verify the result in the diagnostics registry key described above and recreate the Rescue Disk when prompted.

Recovering from a Secure Boot boot failure

Two distinct failures can occur when the firmware Secure Boot configuration no longer trusts a component of the boot chain:

Before the password prompt (message such as "Secure Boot Violation" or an immediate return to the firmware): the firmware does not trust the CA that signs 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 does not trust the CA that signs the Windows Boot Manager copy (bootmgfw_ms.vc) that VeraCrypt chainloads.

In both cases, the recovery procedure is:

Temporarily disable Secure Boot in the firmware setup and start Windows normally (VeraCrypt pre-boot authentication works with Secure Boot disabled), or boot the VeraCrypt Rescue Disk and use "Restore VeraCrypt loader binaries to system disk".
In Windows, adjust the firmware/Windows Secure Boot certificates as needed (enable the third-party CAs in the firmware setup, or apply the Windows Secure Boot certificate updates as described above), then run VeraCrypt Setup in Repair/Reinstall mode.
Re-enable Secure Boot.

Legacy custom-key procedure (deprecated)

Older VeraCrypt versions documented a custom-key procedure (the VeraCrypt-DCS SecureBoot script, sb_set_siglists.ps1) that replaced the firmware Secure Boot databases with a custom platform key and the 2011-era Microsoft certificates. This procedure is deprecated and must not be used on systems using the 2023 certificate chain: it removes trust for the 2023-signed Windows Boot Manager and breaks the Windows boot process after VeraCrypt pre-boot authentication. Systems where it was applied should restore the manufacturer Secure Boot keys, then follow the normal procedure described on this page.

Next Section >>