Now, your point about Autoboot and encryption is spot-on. Many embedded devices prioritize convenience and cost over security. Autoboot means the device needs to load the kernel and root filesystem without user interaction—no password prompt, no decryption step. For that to work, the storage typically can’t be fully encrypted, because the bootloader would need a way to access a decryption key automatically. If there’s no secure hardware module (like a TPM or HSM) to store that key—and many cheap embedded systems don’t have one—the key would have to be plaintext somewhere on the device, defeating the purpose. So, yeah, in a lot of cases, the NAND or eMMC is left unencrypted to keep things simple and fast.
That said, some devices could use encryption and still autoboot, but it requires more sophistication. For example, a secure boot chain with a trusted execution environment (TEE) could store keys and decrypt the filesystem transparently. Or the bootloader could pull a key from a fused hardware register (like eFuses or OTP memory) that’s inaccessible after manufacturing. High-end embedded systems—like some automotive ECUs or IoT devices from bigger vendors—might do this. But the average off-the-shelf board or hobbyist-grade hardware? Probably not. It’s too expensive or complex for the use case.
So, what stops an attacker from desoldering and reading the storage? Practically speaking, not much beyond physical effort and know-how. The real barriers are:
If the device isn’t encrypted—and with Autoboot enabled, it probably isn’t—then desoldering gives the attacker everything. The “UART and JTAG disabled = secure” claim is more about reducing low-hanging fruit for casual attackers, not stopping a determined one with physical access. For real security, you’d need encrypted storage, secure boot, and ideally some anti-tamper measures—all of which add cost and complexity most vendors skip unless they’re forced to care.