On the better hardware or open source BIOS you can disable the entire USB interface from being activated by the UEFI. That is a more pressing problem than when the PC is running but locked, because that's where the system would be more vulnerable.
For instance: if you would want to read something from the PC over the USB bus, and a linux system is running even though locked, you would have to know an exploit that would allow you to do that, and the RBAC/MAC would have to be set to permissive at least. In practice, you would have to already have malware on that PC, malware that is exempt from the RBAC of the system, so for instance the proprietary nVidia driver or something along those lines.
But, if you would shut off the system and fire it up again, the UEFI or BIOS would initialize a pretty functional USB interface for you, without asking questions. If it were a system with secure boot, chances are that secure boot is either switched off, which is something a lot of linux users do and all BSD and Mac users do, or it's a system that had windows on it or was prepared to have windows on it by the OEM, so it has the well documented Windows keys marked as trusted in it. So if USB booting is not disabled, the whole PC is pwned at that time, because rootkits can be installed, etc... on systems with a non-discrete TPM, this is even more of a problem.
However, even if USB booting is disabled, and if it's a PC that once had Windows on it or that has an Intel ME supporting chip or that comes from a particular OEM (cough Lenovo cough), merely the initialisation is already enough to probably get to the rootkits that are on the system (e.g. FlexNet for PC's that had Windows on them before or still have it in dual boot, Intel ME, Lenovo Care, ...). The portion of the boot disk that would be read to find the boot manager, something that the UEFI selects, would be read while the system was still not initiated by the operating system, but rather by the UEFI, so there would be no protection by the operating system. On Linux, the first thing to load would be Yama, then Systemd, and that would effectively block further attempt, because the kernel provides functionality to prevent such data access, but in order to read just that tiny single block 32 FlexNet rootkit that Microsoft and Adobe and Autodesk and nVidia and many others use for their DRM marking, it would be enough. It's definitely enough to see the identity of the owner of the PC and to have a basic profile of him/her based upon the DRM registrations.
Edit: and it gets worse sometimes lol. On linux and BSD, the support for OPAL is refused up until now because it would trust the UEFI with the keys to the encryption of the hard drive. On other systems, it could be enabled. So for instance that sexy Samsung SSD (which has had OPAL functionality since forever, because Samsung does primarily mobile, and there it makes sense), unless you're on an open source operating system, the UEFI will actually load the decryption key for your hard drive to get to your operating system, so while on basic full hardware initialisation through the UEFI. That is just about the ultimate backdoor to any full drive encryption. In linux and BSD, you normally make two boot partitions, one is the boot-efi, which loads grub from UEFI, and there GRUB takes over as boot manager from the UEFI. Then GRUB loads the init.rc or initramfs initialising system of linux, which loads the decryption over user input and starts to decrypt the drive to get to the operating system. It's not perfect because those two boot partitions are unencrypted, and again, if there was windows installed before on that PC, or still is in dual boot, the FlexNet rootkit will be in the first boot partition, unencrypted, loadable by the UEFI, but at least it won't load a decryption key. Some users but the actual initramfs boot partition in the /boot directory under root, so that Grub has to load the decryption key (from user input), then initramfs (which has no way of getting it from grub) asks for that key again to decrypt the OS partition. Most users put it in the extra unencrypted /boot partition, so that grub doesn't load any key, but only initramfs does. No solution is perfect, but the second is probably a tiny bit better, because the UEFI basically loads GRUB, but has nothing to do with initramfs, so there is an extra hurdle there for a UEFI functionality based intrusion.
I see the post was marked with solution but I didn't give a solution yet lol. The solution would be to set your UEFI to ask for a password before initialising ("set password at boot"). This prevents the USB ports from initialising on UEFI start, unless a password is given.