The drivers for any hardware used in the UEFI environment (so graphics, input, storage, potentially network) have the ability to compromise your system, so they

The drivers for any hardware used in the UEFI environment (so graphics, input, storage, potentially network) have the ability to compromise your system, so they have to be trusted as well. For hardware that's built into your machine, that's fine - the drivers will just live in the firmware volume in flash and can't be replaced, so they're trusted. If they're on a plugin card then it's a different story. There's a few obvious options here. The first is for Microsoft to sign the drivers. That would work but would slow down driver deployment. The other is for the vendor to have a key. That means that systems would have to carry the appropriate public key. If you buy a system with the AMD key then you'd be able to run a Radeon, but unless it also carries the Nvidia key then you won't be able to swap it out for a Geforce. It's also possible that Microsoft will issue vendors keys that have chained trust back up to Microsoft's key. That would avoid the requirement to distribute individual vendor keys, but it means that any vendor key is now trusted by all systems with the Microsoft key (ie, all of them). At that point it's no longer about compromising Microsoft's key, it's about compromising any hardware vendor's key. Succeed in that and you're able to produce malware that'll run on any system. Stuxnet demonstrates that this is a real risk. And once the malware is out there and signed by this leaked key, the only way to fix it is to revoke that key. Which then instantly stops all of that vendor's hardware from working. It's still unclear which of these deployment scenarios will be followed. All of them have downsides, and one of them may well be to restrict your ability to choose which hardware you want to use in your (otherwise compatible) system.