any operational impact if not enabled secure boot and not updated CA/KEY 2023 like applying monthly security patches?

If I ignore this and do nothing, will devices with (or without) secure boot enabled continue to boot?

What is the timeline of assisted Controlled Feature Update? Are you planning to roll out the Secure Boot Cert. Update to 100% of devices before June 2026? Or should we already prepare the alternative ways to update the devices (registry, GPO or Intune policy)?  

Any guidance on older Lenovo ThinkStation devices?  Specifically P330 Tiny and P350 Tiny.  We've updated to the latest BIOS, but they all throw an Access Denied error when attempting to update the KEK.  We've discovered that suspending BitLocker, manually entering BIOS, and loading factory default Secure Boot keys resolves the issue, but we don't have the resources to physically put hands on all these devices.  Are there more updates in the works that will allow these ThinkStations to update the KEK without manual user intervention?

Seeing some devices running on Hyper V with the March 2026 updates applied, some Server 2019 servers show updated, but capable = 0 other server 2019 same build same patch level shows updated and capable = 2. is this expected behavior that this status is different between these two VM's?

What would be the impact of blanketly applying this policy setting?  Enable Secureboot Certificate Updates:

(Enabled) Initiates the deployment of new secure boot certificates and related updates.

We started a while before the playbook came out – using previous instructions on how to update the db and verify the 2023 certificate in the EFI file.

Only recently noticed that this does not update KEK automatically.

Could we in confidence, target out confirmed db\efi file updated devices with the script to update the AvailableUpdates key and the Scheduled Task to complete the update?

On the handful of devices I tried this on, the UEFICA2023Status value changed to Updated after a few moments.

We are not able to enable the share diagnostic data with Microsoft settings to allow MicrosoftUpdateManagedOptin, so we’ll be managing this ourselves.

Are these updates Bitlocker aware? Do we need to suspend bitlocker for 2-3 reboots during this process? 

We've ran into Bitlocker boot loops on a small percentage of Surface Laptop 7 devices. How do we prevent that using registry deployment (AvailableUpdates 0x5944)?

What is the proper to detect if a device's secureboot certs updated correctly?

Some devices show different responses across all 3 detection methods that was recommended:

UEFICA2023Status = Enabled

EventViewer Event 1808 = Updated

Intune SecureBoot Report = Successful

Sometimes the 3 above conflict with each other on some devices. A device may have UEFICA2023Status = Enabled but no 1808 event in EventViewer

Is there a risk we trigger BitLocker recovery for users if we update the secure boot cert? Not seen any cases yet but there does seem to be fear around this aspect. Perhaps we need to be careful in some scenarios only? thanks