There's two ways microcode goes on Intel CPUs. The first is when it gets flashed in at the factory onto an OTP ROM. The second is when it gets uploaded to a block of internal RAM by your computer, every time it boots. That's why packages like this one (https://www.archlinux.org/packages/extra/any/intel-ucode/) exist.
One is set at the factory, one is set by your computer every time, once at boot, before the completion of boot. Also, it's very carefully signed, so even if you managed to put a bootkit before the OS boot, you would need to steal Intel's microcode key.
Microcode is not targetable. Few things at that level are. (A decent example of something that might be more targetable at that level is a hard drive controller. Less difficult but still not easy.) The amount of engineering needed to pull off an exploit that is "99.9% chance" unnoticeable, but still persistent, is much more than that of a "99% chance".
(I know nothing of AMD's CPUs and their microcode, but I'm guessing it's much of the same.)
It was a big deal at the time known as "l'affaire gemplus" and it prompted the french government to set up the "Fonds stratégique d'investissement" or strategic investment fund, sort of a french in-q-tel.
Intel being a US company it is probable the US agencies have their ways with them.
This is why I run libreboot and I neutralized the IME by flashing my BIOS using SOIC-8 chip clips and a Bus Pirate.
I guess I'm paranoid.
I guess you refer to a procedure as described in
https://hardenedlinux.github.io/firmware/2016/11/17/neutrali...
I would say what you did is to "neutralize" the ME firmware part in the flash BIOS. But this is only firmware that the ME loads additionally to load applications like e.g. AMT. The ME has it's own internal ROM containing it's very own firmware which is inaccessible and can not be modified.
So what you have is libreboot running on top of a still functional IME. All you gained is, that you got your BIOS of choice installed, and to remove some ME apps from the flash image. Correct me if I am wrong.
Scenario 1: Supply chain interdiction. You don't need to target the CPU only after it has been manufactured and put into whatever you want to hack, you can start way earlier, including at the factory.
Scenario 2: Getting the signing keys from hardware manufacturers, including Intel, seems quite feasible for state actors. You don't even need hacking (I assume Intel's keys are kept air-gapped) or relying on secret court orders, plain old spycraft would probably do the trick.
That said, my argument can be rephrased to consider the hard-drive controller or other peripheral firmware rootkits instead, if you prefer and care only about scenarios where the rootkit must be delivered over the network to a clean system without attacking the CPU manufacturer.
I'd expect a microcode-level rootkit to run a five-nines success rate evading detection unless used against someone who's paranoid enough to have _something_ in place to detect it, and I'd venture further that the 3LAs of the world are smart enough not to target the infosec-paranoids of the world.
Admittedly, the best rootkits probably target the network equipment as well as the host.
At the host level, most organizations wouldn't be able to detect an unmasked trojan running as its own separate user process unless its signature was already known or its behavior caught by a blacklist-based IDS.
Also rootkits are way overrated. What you do when you compromise an organization is you open a connection to your C&C on a few machines to keep your foothold if any reboot. If you need to get in you just connect to one of those boxes and just continue on. You never have to drop anything on the hard disk which makes it much stealthier.