This is incredibly far-fetched. At best, a rogue actor within a foundry, who happens to be working on the correct process node, who happens to be on the account

This is incredibly far-fetched. At best, a rogue actor within a foundry, who happens to be working on the correct process node, who happens to be on the account of the customer victim, might be able to access the GDS file (the full-chip layout file submitted by the customer) or maybe even the mask files (GDS split into layers and processed by the foundry). Exfiltrating it is an entirely different story. Usually these files only reside in very, very locked-down environments. For this very reason. Supposing they did get the full layout to an external network, they still likely wouldn't be able to do an ECO because most of the major players will be using custom standard cell libraries, and not the foundru-supplied ones. Even if it were using foundry libraries, the same rogue actor who has access to the chip layout probably wouldn't (and definitely shouldn't) even have access to the foundry's standard cell IP. At this point it's already a virtual impossibility, but let's keep going. The next step is to actually perform the ECO, which requires a "net list", or a text equivalent of the schematic. Can you get one from the layout? Absolutely. That's how all Layout-vs-Schematic tools work. And the research paper says it's trivial, which it is. But what's not trivial is turning the transistor-level netlist to a gate-level net list. Again - standard cells aren't actually standard, especially bigger and more complex ones. Even harder still is using a netlist to figure out what those logic gates are doing. Trust me, I've tried. Is it doable? Theoretically. But with millions, or potentially even billions of logic gates, it's going to take a very, very long time. Then you've got static timing analysis and power analysis to worry about. With the layout and a gate level netlist, you have all you need to run the tools. But again, it's going to take an extremely long time. Real designs are built hierarchically, so each team is doing timing/power closure for their own blocks and summarizing those for the parent block. If you have a massively flat structure it will be impossibly slow. The underlying research paper makes some massive assumptions , which don't have me convinced at all. Their "trojan horse" circuit is legitimate - you create a digitally controlled oscillator tied to some critical data bus like in an AES subsytem, and the changing data modulates the current consumption of the oscillator which can be measured externally. This type of side channel attack is well known. To me, the Trojan horse implementation is trivial, though. The much harder part is pulling off the ECO.