2 min read
Securing connected devices: a practical checklist
Ten security foundations every connected device needs, from the hardware root of trust to OTA updates and privacy.
Security problems in connected devices are rarely caused by exotic attacks. Far more often, a foundation was skipped early in the project and became expensive to add later. Here is the checklist we walk through with every device team.
1. Start with a threat model
Before choosing algorithms or chips, write down what you are protecting (user data, device identity, firmware IP, the safety of the system), who you are protecting it from, and how they could reach it: physical access, the network, the supply chain or the factory. Every later decision should trace back to this list.
2. Anchor trust in hardware
Use a secure boot chain rooted in immutable code or a hardware root of trust. Each stage verifies the signature of the next, all the way to the application, and anti-rollback counters stop attackers from reinstalling old, vulnerable firmware.
3. Give every device a unique identity
Never ship a fleet that shares one secret. Generate or inject per-device keys and certificates during factory provisioning, and keep private keys inside a secure element, TEE or secure coprocessor so they can’t be read out, even by your own firmware.
4. Manage keys for their whole lifecycle
Keys need more than a birthday. Plan how they are rotated, revoked and retired, how operators and technicians authenticate in the field, and what happens when a device is decommissioned or resold.
5. Encrypt and authenticate every link
Use TLS 1.3 or DTLS 1.3 with mutual authentication for device-to-cloud traffic. On constrained or lossy links (RF mesh, cellular IoT), session resumption avoids repeating full handshakes, saving both latency and battery. Don’t forget internal links: data moving between chips inside the device deserves protection too.
6. Make OTA updates signed, atomic and recoverable
Every update must be signed and verified before it is applied. Use A/B partitions or another atomic scheme so a power loss mid-update never bricks a device, and roll out in stages so a bad release can be stopped early.
7. Lock down debug and manufacturing interfaces
JTAG/SWD ports, UART consoles and factory test commands are the easiest way into a device. Disable them or require authenticated debug in production, and make sure manufacturing-only features cannot be re-enabled in the field.
8. Isolate and minimize
Keep security-critical code small and separate: a secure coprocessor, TrustZone, or at least MPU-enforced task isolation in your RTOS. Give each component only the privileges it needs, so one bug does not compromise everything.
9. Design for privacy
Collect only the data you need, process it on-device when possible, and make sensitive sensors visible to users. A hardware-enforced indicator when a camera or microphone is active builds trust in a way no privacy policy can.
10. Plan to respond
No device ships perfect. Have a vulnerability disclosure channel, security logging you can actually use, and a patch process with clear timelines. Regulations such as the EU Cyber Resilience Act are turning these practices from good ideas into requirements.
The cheapest security fix is the one designed in before the first board spin.
Want a second pair of eyes on your device’s security architecture? Talk to us.