Secure Boot has absolutely nothing to do with Windows Update, so that guidance makes no sense. That message about managed settings means some settings are being controlled by Group Policy. That can be coming from a local policy on the system (view it by running GPEdit.msc) and/or from your Active Directory domain if your system is joined to one.
No @remie2 , that is not accurate. Secure Boot doesn't prevent booting whenever the bootloader files have changed. It prevents booting whenever the bootloader files are not properly signed, meaning the bootloader files either have no digital signature at all or have been altered from their state when those specific files were signed by their author, in this case Microsoft. But if you replace existing properly signed bootloader files with other properly signed bootloader files, then Secure Boot won't have a problem at all. If you install a Windows update/upgrade that includes new bootloader files, then the new files would be properly signed by Microsoft. So no, you do not need to disable Secure Boot prior to installing a new Windows 10 feature release. If that were true, then pretty much every home user who bought a Windows PC in the last 7 years would have to go into their BIOS Setup and muck around with Secure Boot every time they installed a new Windows 10 release in order to avoid their system becoming unbootable after that installation, and that's not what actually happens.
You may be confusing the way Secure Boot works with the way BitLocker works. When BitLocker uses a TPM protector, certain hardware or firmware-level changes from the specific "trusted state" will cause the platform integrity check to fail, which will result in a Recovery Key prompt. And then you need to enter the Recovery Key to get the system to "re-seal" to the new state and trust that. The alternative is to suspend BitLocker before making the change in the first place, in which case BitLocker will automatically re-seal to the new state at the next boot. But that's a completely different technology. And Windows updates do not cause this behavior that requires you to either enter the Recovery Key or manually suspend BitLocker beforehand. However, on some systems, performing a BIOS update will trigger this behavior, and certain BIOS configuration changes will too.
@remie2 There's no point posting the same reply in two different threads. But while it may be true that updating Windows requires disabling Secure Boot "in your case" due to something about the way you've got your environment set up, that is not what you originally said. Your original post said, "You have to disable secure boot if you want to upgrade Windows. Because the boot files are changed." Neither of those sentences are universally true. Whatever is forcing YOU to disable Secure Boot "in your case" is something that is specific to your case, not an inherent requirement of Windows or Secure Boot. And again, Secure Boot doesn't prevent boot files from being changed, and it won't block booting just because boot files have changed. It will only block booting after a change if the new files are not properly signed, so even if your environment requires you to disable Secure Boot, it's not "because the boot files are changed". Something else is going on with your setup.
