About iotbastion

I'm Vik Thomas. I write firmware for a living — motor control and connected industrial gear, mostly Cortex-M class parts running an RTOS or bare metal. I've been doing it for about ten years, the last four of which have been some flavor of "make the existing product talk to the cloud without burning it down."

iotbastion exists because the writing I needed didn't. Vendor blogs sell SDKs. Academic papers describe attacks on parts I can't buy. The middle ground — what a senior firmware engineer needs to actually ship a connected product that survives a CVE — is mostly missing. So I started writing the posts I wish I'd been able to find.

The other reason this site exists is the EU Cyber Resilience Act. The CRA is the first regulation that makes embedded security a hard delivery requirement rather than a soft commitment to "best practices." A lot of teams I talk to are still treating it like a paperwork problem. It is not. It is a firmware problem with a paperwork wrapper.

I once shipped a product with a secure boot that verified the bootloader but not the application. The bootloader was signed. The flash region the application sat in was writable from JTAG. That was a $2M recall. I am not interested in helping anyone repeat that.

Everything here is bench-verified or it's labeled as not bench-verified. No sponsored content. No affiliate links. No "AI-assisted" SEO grass. If a post is wrong, email me and I'll fix it and credit you.

What you'll find here

• Engineering deep-dives — the long technical pieces. Secure boot, JTAG defense, fuzzing constrained firmware, the things you can do on Monday.
• Teardowns — public vulnerability disclosures, walked through from the embedded engineer's perspective. What went wrong, what would have caught it, what to copy.
• Compliance — CRA, RED, ETSI EN 303 645. Mapped to code, not to lawyer paragraphs.
• Build in Public — what I'm shipping, what's broken, what I'd do differently. Less polish, more honesty.