Thx for the response, @benjarobin! To clarify, when I followed your full procedure, including the “Rollback..” step, secure boot did work. The first time I tried, however, I did everything except the rollback step, because I never deleted the factory DBX, PKX and KEKX signatures, only the PK, KEK and DB sigs. Perhaps I misinterpreted, but I believed deleting those sigs was the only reason to do a roll back. So that first time, while I still had the full firmware upgrades in place, secure boot did not work after following the all the other steps, including the --microsoft / -m and --firmware-builtin / -f flags.
So now, similar to what @Ken_Chappell was saying above, I believed I could only have secure boot working at the cost of having to rollback firmware updates. … or so I thought?
Actually, looking at it now, I don’t believe it rolled back everything. Before I did the firmware update, I had version 0.0.3.4 (how it came from the factory) and flashed 0.0.3.7 via Framework Laptop 12 Intel® Core™ 13th Gen BIOS 3.07 Release STABLE. Running fwupdmgr get-devices shows me that the System Firmware is still at 0.0.3.7 and Internal SPI Controller (BIOS) is v 3.07.
So I guess enabling “Restore Secure Boot to Factory Settings” only effected the relevant parts of the UEFI settings it needed to and left the rest in place? 