About files: In C:\Windows\Boot you will find EFI\bootmgfw.efi and EFI_EX\bootmgfw.efi. The first is signed with 2011 and the second with 2023 certificates. This file exists at up to two places in your EFI partition (depending on how exactly the boot variables are set within UEFI). \EFI\boot\bootx64.efi and \EFI\Microsoft\boot\bootmgfw.efi.

Whichever one or two of these files exist, they will be initially the first EFI file, and replaced by the EFI_EX files.

In the firmware, there are named slots, called Variables, which are updated in this process. When secure boot is active, there are restrictions intact that control which variables can be updated from the Operating System. And each of this updates needs to be cryptographically signed by a key that is already mentioned in these variables. In properly implemented Secure Boot UEFI, the PK and KEK variables can only be updated if the update is signed with a key in the PK variable (Platform Key), and the DB and DBX variables can only be updated if the update is signed with a key in the KEK variable.

Also, if TPM is used and sealed against PCR7, the TPM keys will be resealed against the new PCR7 value derived from the new certificates, at the same time when the variables are updated.

Some firmware versions have bugs, like PK or KEK being readonly, or KEK cannot be updated since Microsoft did not receive a signed EFI variable update for that PK (e.g. because the vendor lost it or no longer exists).

In many cases, there are manual workarounds. For example, the firmware setup may provide a menu where you can manually enroll a PK or a KEK. In this case, if enrolling the KEK works there, it is the easiest workaround. (Suspend Bitlocker, if used, before you do anything in firmware setup since it may reset the TPM).

Or it provides a "Setup Mode" where Secure Boot is active but variables are not protected, so you can use third-party tools to enroll the KEK, and afterwards disable Setup Mode again.

Others only provide a single option that will clear all 4 variables, and enroll a new PK only. In that case, you will need third-party tools to sign the KEKs you want to use with the PK, and the DB and DBX content with a KEK (maybe a third KEK you add yourself), and then you can fill the variables again with these updates. After that,, Windows will be happy and work securely again. Just make sure you don't keep your PK secret key on the machine where an attacker could steal it (as in that case you could just turn of Secure Boot and are not off worse). And make sure not to forget any DB or KEK content needed by the firmware or other hardware, or you may have "bricked" your device if you cannot enter UEFI setup any longer.

The last two options are obviously only for people who like to tinker with their hardware and invest some time in them. The same kind of people who brag with using Arch Linux :-P. By the way, the Arch Linux wiki has a good explanation how to set up secure boot completely from scratch, with or without Microsoft keys, so maybe their wiki is for you :)

In any case, for the foreseeable future, having a system that has secure boot enabled but expired KEK only (or even expired KEK and expired DB) is still more secure than secure boot off, as it will properly protect agaisnt a lot of old attacks. It will not protect against new attacks, but disabled Secure Boot will neither.

There may come a point when the old boot manager lacks features you want to use, and only in this case you'd have to bite the bullet and disable Secure Boot.

I know, many technical details in very condensed form. Probably it gives you some basic understanding and you can find the details on the Internet (or in the Secure Boot specification), or just ask again :)