I'll say having been in a neighboring industry that this sounds quite odd and only really relevant to SoCs, which is good since I don't want any more surface/vu

I'll say having been in a neighboring industry that this sounds quite odd and only really relevant to SoCs, which is good since I don't want any more surface/vulnerabilities in the many HW/FW support components like we've seen with branch-prediction and caching. I suppose SMART for HD is somewhat similar to this, but it's not hidden and is completely customer focused. The only other consumer useful things I can think of here would be over-temp and over-volt memory for failure debugging, and maybe parity or ECC failures. Those should either be available as registers at boot or through some external serial bus. That's what I've seen for high volume testing to improve yields. You don't want to be running an OS with a 7-14 second takt time for component testing. From their description you still have to get the data out somehow. Most of it can't survive a power-cycle or it needs flash to be stored in the "database" they describe, but then it's in memory you can see from the processor and unless it's encrypted could be reverse engineered. I don't see there being backdoors to radios or ethernet (OK I can see router companies doing this). It really doesn't sound like something to run while you're in production rather than test. It adds power, possibly latency, and even designing it in make closure and testing more complex. Kinda crazy not to make that modal.