AMD processors have much the same backdoor-"management" coprocessors. Just about the only processors without this stuff is your own softcore design running on an FPGA.
https://github.com/riscv-admin/riscv-uefi-edk2-docs
So if it isn't from door A, door B will do.
And no production OS kernel really uses any of the code that UEFI maps, or keeps any of said code mapped. It may keep the data-table pages (e.g. ACPI sections) mapped, for a while; but usually only long enough to copy said data into its own internal data structures.
(Which is a shame, actually, as an OS kernel that did take advantage of UEFI services like UEFI applications do, would be able to do things that modern kernels currently mostly can't — like storing startup logs and crash dumps in motherboard NAND space reserved for that function, to provide on-device debugging through a separate UEFI crash-log-viewer app in case of startup disk failure, rather than needing to attach a separate serial debugger.)
[1] https://en.wikipedia.org/wiki/System_Management_Mode
[2] https://en.wikipedia.org/wiki/Advanced_Configuration_and_Pow...
Mostly for dynamic powermanagement and voltage regulation, monitoring temperatures, hotplugging, etc. That's just the way it is (now).
I remember when this first made the rounds over a decade ago with some mainboards from CENSORED Apple supplier which were pretty usable, except when running under something else than Microsoft Windows. IIRC it wasn't malice, only implemented in a way which made this hard to interface with from Linux, or the likes. Of course undocumented. Later, but about the same timeframe the first so called open source/security 'zealots' damning ACPI in general for those reasons.
It may be called differently on other platforms, but similar/equivalent mechanisms exist on almost everthing which is not in a museeum or landfill.
Before giving control to the operating system for the first time, the UEFI firmware can configure various peripherals to generate SMI (System Management Interrupts) on various types of events and it can ensure that the SMI requests will be handled in the future by itself and not by the operating system. The UEFI firmware can lock this configuration, so that the operating system will not be able to change it.
When a SMI request happens, the UEFI firmware handles the event with the CPU in SMM (System Management Mode), which is a mode with more privileges than any operating system or hypervisor and which has access to everything, including to things that are protected from accesses by the operating system, e.g. a memory area reserved for SMM use.
The ARM CPUs may also have a mode equivalent with the Intel SMM, named EL3 (Exception Level 3), so, on ARM CPUs that implement EL3, the UEFI firmware can also run concurrently with the operating system or hypervisor, overriding them whenever it wants.
In theory, the UEFI firmware should use SMM only to handle benign events, for which Microsoft was too lazy to write handlers and Intel obliged by creating the ugly SMM, passing this event handling task to the motherboard manufacturers (forcing thus also the other operating systems to use the BIOS/UEFI handlers, even if they could have handled those events better themselves), such as powering up and down peripherals or changing the clock frequency of the CPU.
Nevertheless, the writer of the UEFI firmware could easily do much more than that, e.g. inspecting the content of the memory, the data written or read on storage devices or sent and received through the network. (Full memory, storage and network traffic encryption could prevent this.)
The SMM could also be used to implement a remote control of the computer that cannot be detected or prevented by the operating system, but for this an even more powerful facility has been introduced by Intel and AMD, many years later after SMM, in the form of the auxiliary CPU from ME/PSP.
It's like saying I haven't been robbed until I discover that my stuff is missing.
Well, robbery is theft under threat of force, so it would be very hard to be robbed and remain unaware of it.
To make the analogy work for you, you have to add something about doors being unlocked, or somebody else having the key to your home.
Something like: The locksmith has made a copy of your keys without notifying you. They could hypothetically use those keys to enable a robbery, but you won't know definitively either way until you find something stolen. But it is a pretty weird thing for them to do, right?
There's no Schrodinger's Burglar. You've been robbed once I take your wallet, whether you've discovered it or not.