I'm kind of the opposite opinion of Jonathanjo

**If you're concerned about security, always choose a modern, well-established encryption method; the medium doesn't matter, and wired is the easiest to sniff and intercept**. Jonathanjo's statement that ciphers do get easier to crack over time with growing compute power (ASICs, FPGAs, and GPUs: we're not cracking encryption with CPUs anymore, too slow) is right, but irrelevant: for anything made of the semiconductors we know today, we won't be cracking AES-256 to get access to a microcontroller. That's just such a stupid attack scenario: in order to *passively read* a recorded session, you'd spend millions to tens of thousands in electricity, even if we had the machines fast enough to do that (we don't.)? And in the meantime, the key got rotated as mandated by modern WPA, so you can't even send fake data? I doubt that whatever you're building is *that* lucrative.

**If you want operational safety in absence of physical tampering, use wired**. You can jam wireless from the next room. You can *also* jam wired electronics, but it takes orders of more power.

Jonathanjo is *absolute, 100%, on point*:

> When thinking about security, try to avoid ideas like "100% secured", as there is no such thing. 

yep. Think about ancient fortresses / castles: safe against specific attacks, not safe against others, only safe in context with monitoring (say, people with arrows, rams and swords will not throw down a 2m thick stone wall, but enough people with arrows covering other people with ladders is another problem).

> Instead, consider "how much resource would it take to break it to the extent of X", where X is deny service, elevate permission, reprogram, etc, depending on your concerns. If it requires the resources of the CIA and takes a year is very different from requires 1000 CPU-hours and an undergraduate crew.

*Threat modelling* is the engineering discipline of having an idea of 1. what you protect, 2. against which kind of adversary, 3. using which kind of resources, 4. to which end. Start with that! Piece of paper, pencil, write down the answer to these 4 questions first. Research if you can't answer them right away.

I think the main risk here is that re: 1. you're defending a device running someone else's software stack. Microcontroller firmware on average *is not as good as it should be*. ESP's IDF isn't the worst, but you can't look inside the firmware blob actually doing Wifi. I'm sure your MQTT library is written and tested; but you need to make sure it's really not doing things on a microntroller that it wouldn't do in the continuous integration test infrastructure. Do you have a software bill of materials for your network stack? Check for quality in all components. If you remember the *left-pad disaster*, this phenomenon of people importing low-quality code from sources with *no* reliability whatsoever has long reached the microcontroller world; in the shape of Arduino "libraries", mbed repos, and since the dawn of C in the shape of people that really should realize they're developing a software product telling themselves they don't need to understand the code they're just copying.