Error 1801 Attempted Remediation Causes Windows Hang

Desire:
- Resolve Windows System Event ID 1801 'errors', message: "Updated Secure Boot certificates are available on this device but have not yet been applied to the firmware." on unsupported Win11 PCs.

PC(s) Configuration:
- 'End of Life' Dell PCs with old CPUs (5th-7th gen Intel)
- No Dell firmware updates available for TPM 2023 certificates
- 3 different TPM V1.2 (PPI V1.2) vendor chipsets with same Dell PN TR2C9
- Win11 Pro V10.0.26200.7840 installed

Attempted remediation of 1801 'errors':
- Enabled local group policy to allow Secure Boot updates
- Forced TPM Secure Boot updates via Secure Boot Scheduled Task '\Microsoft\Windows\PI\Secure-Boot-Update'

Result:
- Dell PCs with TPM V1.2 at BIOS V1.24 hangs when the Secure Boot Scheduled Task is launched.
- Dell PCs with TPM V1.2 at BIOS A18 and A22 do not hang when the Secure Boot Scheduled Task is launched, but continue to show Windows 1801 System Events.
- The hang is no mouse or keyboard response, no network connection, and the display is frozen.
- Restoration is to hard power off the PC and launch Windows System Restore to a prior date or disable the Secure Boot update Started Task immediately after reboot if possible.

Remediation for 1801 errors:
- Manually update, via BIOS setup, TPM certificates from another PC, since new OEM firmware is not planned.
- Disable automatic Secure Boot TPM certificate updates via the registry or via local group policy with accepted risk to future TPM updates.
- Disable Secure Boot (not recommended).

Observations:
- 'End of Life' Dell PCs with Dell PN TR2C9 TPM V1.2 (PPI V1.2), with multiple TPM vendor chipsets and with 'disabled' TPM updates, can still be booted with old TPM 2011 certificates with and no adverse affects to Windows other than Windows will no longer indicates System Event ID '1801' errors, but will continue to show TPM System 'information' events where TPM cannot be updated. This as verified by setting the BIOS date to 2 years after certificate expiration and with no network connection.
- For 'End of Life' Dell PCs with Dell PN TR2C9 TPM V2.0 (PPI V1.3), with multiple TPM vendor chipsets and with 'enabled' TPM updates, Windows updated the TPM Secure Boot 2023 certificates successfully after reboots, which eliminated the System Event ID 1801 'errors'.

Risk to manual certificate remediation:
- Valid certificates would need to be obtained and added via a manual BIOS change.
- The updated TPM certificates are kept in volatile CMOS storage and should the CMOS battery be replaced, the updated certificates would need to be manually restored. The only permanent solution is an OEM firmware update, but that is not planned by the OEM.

Risk to disabling TPM updates:
- Future Secure Boot malware protection would not be available.

Going Forward:
- Only Dell TPM V1.2 PCs at BIOS V1.24 were observed to hang when attempting to update TPM certificates via Windows update and Secure Boot update group policy enabled.
- For the 5 Dell PCs tested, TPM V1.2 had no ability to automatically update TPM Secure Boot certificates via Windows Update. This was tested on 5 Dell PCs with different BIOS versions and 3 different TPM OEM vendors.
- For unsupported Windows PCs at TPM V1.2 (PPI V1.2) and with no OEM plans to update the firmware, it may be best to disable Secure Boot updates via local group policy or via the registry, to eliminate spurious Windows TPM System Event 'error' messages that will occur multiple times a day and to potentially avoid hangs due to incompatible hardware/BIOS versions should the Secure Boot scheduled task be fired off.

Command to verify TPM status:
powershell -ExecutionPolicy ByPass Get-Tpm
Note: Disabling or enabling 'AutoProvisioning' did not appear to have an effect on TPM updating during testing.

Potential methods to disable Secure Boot auto updates for 'unsupported' Windows PCs:
- Run 'powershell -ExecutionPolicy ByPass Disable-TpmAutoProvisioning' (not observed to be effective)
or
- Run 'gpedit' and disable the following settings (tested and would recommend):
- 'Computer Configuration>Administrative Templates>Windows Components'
- Enable Secure Boot Certificate Deployment
- Automatic Certificate Deployment via Update
- Certificate Deployment via Controlled Feature Rollout
- Run 'gpupdate /force' to implement the policy changes.
Note: Secure Boot auto updates will then be disabled, but may not be effective until a reboot.
- Once the group policy updates are in effect, the following registry settings will be in place:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot]
"AvailableUpdates"=dword:00000000
"AvailableUpdatesPolicy"=dword:00000000
"HighConfidenceOptOut"=dword:00000000
"MicrosoftUpdateManagedOptIn"=dword:00000000

As mentioned above, this was tested on Win11 Pro and gpedit is not avaiable on 'Home'. Of course, YMMV. Enjoy

Quick answers:

1. The TPM version has no bearing on Secure Boot. Secure Boot signing certs are a function of the UEFI spec, which doesn't cover TPM. SB certs are written to your BIOS's NVRAM variables, and are not stored by the TPM (which is reserved for HW encryption keys).

2. You may be able to manually enroll the KEK CA 2023 cert, from your Secure Boot setup menu, if individual key management exists. It may not, depending on your BIOS's version and mostly age.

3. You may be able to install a replacement Platform Key from MS to replace the Dell Platform Key (PK) native to the BIOS. With a MS-provided PK, it may be possible to write the complete set of CA 2023 certs.

4. Or you may have the generation of Dells that have a tricky and problematic BIOS because it was first supported in the early years, and not well standardized. If the scheduled task is hanging the entire PC, that's not a good sign as the task is only trying to append the certs to your BIOS.

5. If you do have the problem BIOS, there might not be a good solution other than disabling Secure Boot. In the future, Windows will more aggressively attempt to detect non-compliant BIOS'es and apply the certs to them. If the update process hangs now, it will probably always hang in the future. One possibility to try is to perform a factory reset of Secure Boot, and see if the task continues to hang.

6. The update "error" message is logged under the TPM-WMI channel, probably because there isn't a standalone channel dedicated to Secure Boot messages.

7. If you perform a factory reset of an older BIOS, which doesn't have the CA 2023 certs built-in, then the reset will clear the CA 2023 certs. You will have to temporarily disable Secure Boot, boot into Windows, and re-apply the missing certs. Afterwards, you can re-enable Secure Boot.

This can't be fixed because it requires a newer firmware image. But you always have the option to disable Secure Boot, in order to get to a working Windows system for repair.

1. My perspective was tied to TPM, since it was the source of the 'TPM' 1801 system logs. Later I followed the Secure Boot Playbook at 'https://techcommunity.microsoft.com...ook-for-certificates-expiring-in-2026/4469235'
enabling the local group policy to update the Secure Boot certificates, resulting in a hang on 2 out of 5 PCs, all 5 with the same Dell BIOS version. These PCs do not meet the Win11 requirements and Dell has no plans to upgrade the firmware on these PCs.

2. Updating the certs/keys via the BIOS menus for 'Expert Key Management' is plausible, but these PCs are not monitored or occupied and manually entering the key changes requires 'Key Management' to be left in 'Custom' mode where a BIOS reset to default settings or loss of CMOS battery could lose them and potentially not boot if MS gets more stringent later about what keys are recognized for Secure Boot.

3. I have never pursued a Platform Key replacement and suspect there would be the same issue with setting custom keys via BIOS, since the Dell literature indicates the 'default' keys are only changed via a firmware change. I do not know if keys are easily imported from another PC. Not too interested, since some of these PCs are many miles away and logistics would be a challenge. If MS changes the rules or other 'stipulations for use', these PCs are SOL anyway. So avoidance is my mantra.

4. No question these are earlier PCs (8 yrs old). Just wanted make a notice that specific existing situations can cause a hang if someone uses the Secure Boot Playbook for an old Dell PC and they enable the Secure Boot update local group policy to fix 'TPM 1801 errors'.

My issue is specifically that for come Dell motherboards at TPM V1.2 and a specific BIOS level (V1.24) that are receiving 1801 errors, may hang when the local group policy is enabled to force(?) Secure Boot certificate updates. The hang has no visual indication, no console message, no logs, and no dumps to follow a trail for resolution.

I did not have the hang or 1801 issue for Dell PCs at TPM V1.3 or TPM 2.0, so those motherboards/firmware were apparently able to update the Secure Boot hardware certs/keys from Windows Updates successfully. I assume those PCs had other chipsets that were more amendable to Windows Secure Boot certificate updates and not necessarily due to TPM chipset changes. TPM version was my only clue for correlation.

5. These PCs are in place until they are replaced in the future. I have little desire to disable Secure Boot on them, but I do desire to minimize any potential boot malware risk while keeping them from failing in the interim. A hanging PC with no visual indication, logs, or dumps indicating a potential cause or source is unacceptable for PCs currently in use, so avoidance is the better option.

6. Correlating TPM 1801 'error' to TPM was due to other current TPM 'events' which indicate Secure Boot update status changes as a result of the Secure Boot update scheduled task and their use of TPM events for Secure Boot status indications.

7. I have not had a happy time in the past resetting or changing keys/certs via BIOS even when on site for older BIOS version. Since the PCs are in place, I'm not keen on a manual BIOS key change procedure with the 'un-initiated'.

My intent was to keep the PCs in place with old Secure Boot certs and with minimal user interaction. If that does not work in the future, disabling Secure Boot is on the table. Disabling Secure Boot has been tested successfully for these PCs, but who knows how intrusive the future will be with 'compliance' to Win11 'requirements' and Secure Boot on them becomes moot. Win11 25H2 works and these PCs have been in place since 21H2 and thru to 25H2.

Appreciate the insight.

When in doubt, test. Test again for good measure and if you suspect again, test again.

wwhenderson said:

1. My perspective was tied to TPM, since it was the source of the 'TPM' 1801 system logs. Later I followed the Secure Boot Playbook at 'https://techcommunity.microsoft.com...ook-for-certificates-expiring-in-2026/4469235'
enabling the local group policy to update the Secure Boot certificates, resulting in a hang on 2 out of 5 PCs, all 5 with the same Dell BIOS version. These PCs do not meet the Win11 requirements and Dell has no plans to upgrade the firmware on these PCs.

Click to expand...

Enabling the Secure Boot GPO only does one thing, it sets the AvailableUpdates reg key to 0x5944. When the Secure Boot update task (which is always running in the background) sees that bitmask, it tries to apply all the CA 2023 certs in turn until it succeeds or fails.

wwhenderson said:

5. These PCs are in place until they are replaced in the future. I have little desire to disable Secure Boot on them, but I do desire to minimize any potential boot malware risk while keeping them from failing in the interim. A hanging PC with no visual indication, logs, or dumps indicating a potential cause or source is unacceptable for PCs currently in use, so avoidance is the better option.

Click to expand...

You need to enable the GPO for Automatic Certificate Deployment via Updates, so Secure Boot updates are not automatically applied.

https://support.microsoft.com/en-us...8dd5ce7#bkmk_available_configuration_settings

5. Actually enabling the Automatic Certificate Deployment via updates is what causes the hang on older PCs that cannot update the motherboard certificates. That was the reason for my post as it applies to older 'unsupported' Windows 11 PCs with specific BIOS/firmware versions. Enabling the GPO settings causes the hang with no indication for tracing a resolution.

My final notes:

If you either set the Secure Boot update local group policies to 'Enabled' or set the Secure Boot 'AvailableUpdatesPolicy' registry setting to '5944' for some older PCs to force a motherboard Secure Boot certificates update, the PC may hang when the Secure Boot update scheduled task launches (at reboot or every 12 hours). This seems to be more prevalent with older PCs that are prior to TPM V2.0. To avoid the hang on older PCs, it may be recommended to leave the Secure Boot update local group policies as 'Not defined' (or 'Disabled') and the Secure Boot 'AvailableUpdatesPolicy' registry setting to its default of '0000'. In other words, do not force Secure Boot motherboard certificates updates on older PCs to resolve a TPM 1801 'error'. This was validated on older Dell desktop PCs with Windows version: 25H2 (Build 26200.7840).

For older PCs that cannot update the Secure Boot motherboard certificates via Windows update, the TPM System Event 1801 'error' appears to be normal. The remediation to avoid Windows posting the error is by either disabling the Secure Boot update scheduled task or disabling the Secure Boot update local group policies or disabling Secure Boot. None of which may be desired. Otherwise, the 1801 'error' appears to be of little consequence. Of coure this may change as Win11 becomes more stringent about complying with 'requirements' and may even deny booting with expired Secure Boot certificates in the future. At this time, the PCs were tested with BIO dates set to 2028 and they booted successfully, but the certificates were not 'expired'. We'll have to see after June 2026.

The Secure Boot updates local group policies are at gpedit:
'Computer Configuration>Administrative Templates>Windows Components'
- Secure Boot Certificate Deployment
- Automatic Certificate Deployment via Update
- Certificate Deployment via Controlled Feature Rollout

The Secure Boot registry settings are at regedit:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot]
"AvailableUpdatesPolicy"=dword:00000000

The Secure Boot update Scheduled Task is at:
"\Microsoft\Windows\PI\Secure-Boot-Update"

The command to display the Secure Boot system events follows:
powershell -ExecutionPolicy ByPass -Command "Get-WinEvent -FilterHashtable @{ProviderName='microsoft-windows-tpm-wmi'; Id=1032,1033,1034,1035,1036,1037,1043,1044,1045,1795,1796,1797,1798,1799,1801,1808}"

Secure Boot verification commands are on GitHub at:
https://github.com/cjee21/Check-UEFISecureBootVariables/archive/refs/heads/main.zip

The Secure Boot Playbook is at:
https://techcommunity.microsoft.com...ook-for-certificates-expiring-in-2026/4469235

Again this post applies to older PCs that may not be able to update motherboard Secure Boot certificates via Windows Updates due to BIOS/firmware limitations and as a result of a Windows System Event TPM 1801 'errors' posted. This started with trying to comply with the Secure Boot Playbook for older Dell desktop PCs to avoid issues once the certificates 'expire', but some PCs hung with no other indication Forewarned is forearmed.

In the immortal words of Emily Litella 'Never mind'.

You're making this harder than it needs to be. Just disable the Secure Boot scheduled task, so it can't run.

You are correct. My intent was to let others know that if the 'Playbook' was followed for older PCs, it could lead to a hang that would be difficult to troubleshoot. This is especially difficult for me, since I have multiple of these older PCs at remote unattended locations, which make hangs very troublesome. My solution is to leave the scheduled task disabled. The group policy change could be extra insurance, depending how MS turns the screws going forward, once the certs expire.