To try and avoid the accidental installation of the offending KBs, checkout this article.

 ZENworks: How to block the automatic install of specific Windows KB updates using PowerShell 

More details will be coming....but I'm trying to get as much info out as quickly as possible.

I have created an additional article for collecting FDE-related information that could be useful for the current issue.

 ZENworks: Collecting Important ZENworks FDE related information 

This solution will let you know which devices do or do not have secure boot enabled as well as which devices are or are not configured with the ZENworks FDE Bootloader.  Any devices with "Secure Boot" enabled and have the "ZENworks FDE Bootloader" will likely have boot issues if the KBs noted above are installed.

Oddly, only Windows 11 devices so far have been impacted in my lab but I certainly would be concerned with Windows 10 as well since lab testing is still early.

--

Steps to protect against possible issues include trying to temporarily block the installation of the noted patches until a patch is available to resolve the conflict. (Most likely from OpenText.)

If the existing FDE Policy does not have "Encyption Lockdown" enabled, then it would be possible to create a Dynamic Group for all devices that have "SecureBoot" disabled and move the FDE Policy Assignment to this group.  This way devices which can safely run ZENworks FDE regardless of the installation status of the MS Patches, will remain encrypted while the others will decrypt and remove the ZENworks FDE Secure Shim that causes the issue.

If "Encryption Lockdown" was enabled, the solution is a little more complex and more details will be forthcoming.  Once the assignment is removed, the devices can be decrypted using a "Quick Task" or manually on the device.

--

The Dynamic Groups by default only update every evening at midnight, though they can be updated manually in the ZCC or scripts can be run on a primary server via a CRON job to update them more often.

If trying to automatically update the assignments as mentioned above, consider disabling "Assignment Optimization" under ZCC->Infrastructure Management->Assignment Optimization Settings and setting the recalculation time to 23hrs and 59 minutes.  When enabled, devices still see old assignments or not see new assignments for up to 4 hours after the changes are made, even after an automatic refresh.  When disabled, they are seen immediately.  When disabled, the calculations will only be used for ZCC reporting so they can occur less often.  Reduce the frequency as noted to avoid excessive assignment calculations.

Expect More Updates to come......

Understanding UEFI SHIM Bootloader Signing Process:

https://techcommunity.microsoft.com/t5/hardware-dev-center/updated-uefi-signing-requirements/ba-p/1062916

To resolve the current issue, the OEM that provides the FDE UEFI Bootloader will need to have the new SHIM signed by Microsoft.

The simple part will be updating the SHIM.  Once that is done, it must be approved by the SHIM Review Board in Step 12.  Once that is done, then Microsoft can sign the SHIM so it will be trusted by the UEFI.

Currently, there is no ETA on when this process may be completed.

Note: There will be a solution forthcoming that will all the automatic removal of FDE encryption and the ZFDE UEFI Boot Shim through the use of Policy System Requirements and scripts, regardless if encryption lockdown is enabled.  All the details have been worked out in the lab.....I just need to do the write-up.  That will come another day....It's now well past the end of my day.....This comment will be updated with details hopefully tomorrow.

Some technical details from an impacted customer : 

The info in ZCC and this community post reached us to little too late. Cumulative MS patches August where released by us to +6200 Windows 10 and Windows 11 devices on Friday 15th. Impact so far : 

The good news: 
- So fare, none of our patched Windows 11 devices are showing the "Verifying shim SBAT boot ..." failure. They have ZCM Agent version 23.4

The bad news :
- Intermittent failures on our Windows 10 devices. Our patch test devices with W10 (sandbox) did not show any errors. So same as the Windows 11 devices. Therefore we decided to release the patches. Some devices do not show the error. Other devices, over 170 devices out of 2200 until now, show the boot failure and have to be corrected by disabling the secure boot option. Which is a very user friendly procedure for the end user ... - (arghs...) and Helpdesk operators.
- We were already confronted with the outdated FDE Boot shim certificate when using the latest HP G10 devices. In the BIOS of those devices we had to change a default BIOS setting (3Rd party boot certificate) so the FDE boot shim gets accepted.

The question :
What now OpenText? How can we fix this and will the fix include an updated boot shim so we can prevent this from hapening again ? 

The offer:
Please contact us for testing any fix testing , as we now have a big lab situation...

For now, Disabling Secure Boot is the only option if the patch has been applied.

Yes, there will be an Updated SHIM.  We do not have an ETA because getting a SHIM signed involves many external entities including the UEFI SHIM Review Board before Microsoft will sign it.  It's not simply a matter of a developer updating the SHIM and it can then be deployed.  Updating the SHIM tends to be the easy part.  Working through the UEFI Consortium tends to be the longer part.  That said, I'm not sure of the current status; we do not have an ETA.

If you want the quickest access to a test patch when one is available, you can open a Service Request so we can try and provide you one, when one becomes available, but the timeline between when we received the signed shim and it's available may be very short.  

Note: "HP G10 devices. In the BIOS of those devices we had to change a default BIOS setting (3Rd party boot certificate) so the FDE boot shim gets accepted.".  This is expected and will always be the case.

Please Review the Official MS Documentation here posted previously -> https://techcommunity.microsoft.com/t5/hardware-dev-center/updated-uefi-signing-requirements/ba-p/1062916

"UEFI signing is a service provided by the Windows Hardware Dev Center dashboard by which developers submit UEFI firmware binaries targeted to x86, x86-64, or ARM computers. After these binaries are approved through manual review, the owners can install them on PCs that have secure boot enabled with the Microsoft 3^rd Party UEFI CA permitted."

Every UEFI Bootloader is Signed by MIcrosoft, including those for REDHAT, SUSE, etc.. etc..

Microsoft sign's it's OWN UEFI Bootloaders with one CA.  Every other UEFI Bootloader with another.  By default, the UEFI on most PCs will accept both.  Some PCs ship with a UEFI that has a setting if they will permit a Non-Microsoft UEFI bootloader signed by Microsoft to load.  Your HP devices have a setting that can prohibit the loading of UEFI Bootloaders signed by Microsoft but not written by Microsoft.

HP has PowerShell addons that allow you to enable/disable this feature as well as to Enable "Secure Boot".  Disabling SecureBoot, however, cannot be done using these tools because automatically turning off SecureBoot is prohibited by the UEFI standards.

Ah. Ok.I made the wrong assumption than. 
Meanwhile, we already instructed HP and the distributor of the devices to deliver the devices with the BIOS setting correct for accepting non-Microsoft bootloaders.
The problem was that we did not know about this issue until the first large shipment arrived. In our build deployment FDE kicks in when te the end user logs on to his brand new shiny device. And next boot the boot device was no longer accepted. With the downside we couldn't even reach the devices with Powershell scripting...

A service request was opened already yesterday morning 9:20 CET. FYI 02943310

Thank you for this reply and extra information via this channel. 

Problem here is that we now have released patches to 6200 devices, which may or may not work after reboot...So as you can imagine, management is on it.

Which brings me to my last question : why is this happening intermittent ? The Windows 11 devices updated to the last Microsoft August patch level with FDE active do not show the issue. And, also, not all Windows 10 devices with FDE active show the error. So the boot error showing is an intermittent event. Why ?

You may want to verify if those PCs have Secure Boot Enabled.  If not, they will not be impacted.  It's possible some devices do not have ZCM FDE Fully enabled.  For Example - If the device is Bitlocker encrypted, which can happen automatically on some PCs out of the box, then the ZCM FDE Bootloaders will not install and it will not be FDE encrypted while it is Bitlocker Encrypted.

Now is it possible that some devices can STILL boot once the Patch is installed AND the ZENworks FDE UEFI Bootloader is installed?  Perhaps, but that is not a question we would ever be able to answer.  Clearly, the FDE Bootloaders do not have the SBAT data that the Windows Update adds as a requirement.  Perhaps there is some BIOS Security on some PCs that prohibited Microsoft from adding that requirement when the patch was applied.  Maybe for some reason, the patch detected an incompatible boot loader and did not enforce the policy.  The Microsoft KB does say if the system is "Dual Boot" with LInux, it would not apply the restriction but web searches have shown that to be far from the case..at least universally.

In my own lab, I was not able to replicate the issue initially except for when the PBA was installed on my Windows 11 devices.  Now I can always.  Exactly why, I cannot say but it may have been a matter of something not kicking in until another reboot.  Since the issue was reported on Friday, I know I have spent every waking moment including the weekend working on this.

Some of the bundles in the article above can help you determine if "Secure Boot" is enabled and the FDE Status of devices.  You may find a pattern