And here is was thinking we had all this solved already, a jumper on the mother board that has to be shorted to update the bios. But I'm too old to understand why that isn't good enough I guess :-)
Essentially your proposition comes down to 'no BIOS updates. And that has it's own problems, from a security pov and from a manufacturing recall pov.
Now that means normal users and IT depts can do all the updates they need, but if you have a need for your own private key you can do that too (after physically touching hardware).
Oh and for bonus points, a motherboard switch can enable the keyboard on a physical designated USB slot to be able to authorize a cert modification. So you get convenience of not having to open the system, or if you want additional security then open the case and remove that jumper.
I happily updated BIOS until I experienced a catastrophic failure that bricked the board, don't know how. Since then I'm terrified of updating BIOS. I've also experienced UEFI conflicts(?) loading linux to new boards that took forever to sort out. It seems BIOS development has not progressed as well or far as one might expect, but that may just be me and my klutzy bad luck.
My experience with BIOS updates has been mixed.
The first time I did a BIOS update, it added an option to tell it that the HDD connection had 80 wires instead of 40 wires, which enabled a faster transfer mode. The second time I did a BIOS update (on that same machine), however, it made the realtime clock lose touch with reality, apparently running twice as fast, so I had to revert this update. That put me off from doing BIOS updates for a while.
My latest laptop can be updated through LVFS (using UEFI capsule updates), and it's new and under warranty, so I decided to risk it. One of the first BIOS updates I did made, according to its release notes, an important-looking change to the battery management. Some time later, the laptop started crashing randomly (the crashes happened when the display turned off, but not every time). After a lot of searching, I found out that a later BIOS update made some unknown change which causes these crashes, unless you add "i915.enable_dc=0" to the kernel command line.
For now, I'll keep risking it (at least while it's still under warranty), and hope no other obscure BIOS-update-caused bugs happen (and I'll probably keep using "i915.enable_dc=0" on this laptop forever, since there's no way to know whether a later BIOS fixed it).
Enabling it in a machine-controlled menu that can't be navigated except by the physical keys might be better