Most security teams focus on software: code review, network pentesting, cloud configuration. That’s necessary but incomplete — especially for embedded systems, IoT devices, and any product with a physical form factor.
If an attacker can touch your device, they can likely extract your firmware, read your encryption keys, and bypass your authentication. Here’s how.
The attacks software teams don’t know about
JTAG/SWD debug access — most microcontrollers ship with debug interfaces that allow full memory read/write, code stepping, and register inspection. If the debug port is active in production, an attacker can extract your firmware, read secrets from memory, and modify execution flow. Cost of attack: $30 for a JTAG adapter.
SPI flash extraction — your firmware is stored on a flash chip. If it’s not encrypted, an attacker can desolder the chip (or probe the bus without desoldering) and read the entire firmware image. They now have your source code, your keys, your algorithms. Cost of attack: $15 for a bus pirate.
Side-channel analysis — your AES implementation might be mathematically correct. But if it runs faster or draws more power for certain key bits, an attacker can measure the power consumption and extract the key. Cost of attack: $500 for a ChipWhisperer.
Voltage glitching — a brief voltage spike at the right moment can cause a processor to skip an instruction. If that instruction is a security check (password verification, signature validation), the device grants access despite the check failing. Cost of attack: $200 for a glitching rig.
Why this matters
If you build IoT devices, automotive ECUs, medical devices, or any product with a physical form factor — these attacks are relevant. They’re not theoretical. They’re documented, reproducible, and used by real attackers.
Software security is necessary. Hardware security is the layer below it. Without both, your product has a false sense of security.
What to do about it
Lock your debug ports — disable JTAG/SWD in production firmware. Better: use a hardware fuse to permanently disable debug access after manufacturing test.
Encrypt firmware at rest — store firmware encrypted on flash. Use secure boot to verify integrity before execution.
Use hardware crypto — software AES on a general-purpose MCU is vulnerable to side-channel attacks. Hardware crypto accelerators with constant-time execution mode are resistant.
Get assessed — the KnytX security-consulting practice runs hardware security assessments that test all of these attack vectors, using professional-grade equipment and hands-on hardware depth rather than software-layer testing alone.
To discuss your device’s security posture, book a scoping call.