IoT Security: How to Protect a Connected Product

IoT security for a connected product comes down to five things you have to design in before the first unit ships: no shared default password, encrypted transport everywhere, a unique cryptographic identity per device, a signed and verified update path, and development interfaces closed in production. Everything else — cloud hardening, privacy policy, incident response — is important, but it sits on top of those five. Get them wrong and no amount of later patching fully repairs the product, because the weakness is baked into hardware that is already in customers' homes.

Why This Matters Even for a Small Product

Founders of first products often assume attackers only care about big fleets. In practice the opposite is true: automated scanners sweep the entire public internet continuously, and they do not know or care how many units you sold. A camera, a thermostat, or a pet feeder with an exposed telnet port and a factory password gets found within hours of connecting.

The commercial consequences arrive through channels that have nothing to do with hacking. Retailers and enterprise buyers increasingly send security questionnaires as part of onboarding. Consumer-product labeling programs in the US reference baseline expectations like unique passwords and a documented update mechanism. And a single publicized incident on a small brand is disproportionately damaging, because the brand has no reputational reserve to absorb it.

The Five Things to Design In

1. No Shared Default Credentials

The single most exploited weakness in connected products is a password that is identical across every unit. If your product needs a factory credential, it must be unique per device — derived at production from a serial number and a secret, printed on a label, or replaced by a first-boot pairing flow that forces the user to set their own. Whatever you choose has to survive a factory reset without reverting to something guessable.

2. Encrypted Transport, Verified Both Ways

All traffic between the device, the cloud, and the app runs over TLS, with the device validating the server certificate rather than accepting whatever answers. Skipping validation is the classic shortcut that makes debugging easier and man-in-the-middle attacks trivial. Certificate roots need to be updatable, since roots do expire and a device that cannot learn new ones eventually cannot connect at all. Your choice of protocol affects how this is implemented — see our comparison of MQTT vs HTTP for IoT for how each handles sessions and credentials.

3. A Unique Identity Per Device

Each unit should hold its own key pair or certificate, provisioned during manufacturing and stored where it cannot be trivially read off the board — a secure element, or at minimum the protected storage features of the microcontroller you selected. Per-device identity is what lets you revoke one compromised unit instead of rotating a secret shared by the whole fleet. It also gives your backend a trustworthy answer to "which device is this?", which matters for both billing and support.

4. Signed Firmware Updates

A product you cannot securely update is a product you cannot fix. The device must verify a cryptographic signature before it will run new firmware, and it needs a rollback path so a bad image does not brick the unit. This is a design decision about memory layout and bootloader architecture, not a feature you bolt on later; our guide to OTA firmware updates covers the mechanics and the failure modes.

5. Development Interfaces Closed in Production

Debug UARTs, JTAG and SWD ports, shell access, and diagnostic web pages are all useful during bring-up and dangerous in the field. Production firmware should disable or lock them, and the production test procedure should verify that the lock actually took effect on real units — not just in the build configuration.

Personal Data Is a Separate Layer

Device security and data privacy overlap but are not the same problem. If your product collects video, audio, location, or health-adjacent measurements, you also need to decide what you store, for how long, who inside your company can query it, and what happens to it when the user deletes their account. State privacy laws in the US now give consumers deletion and access rights that your architecture has to be able to honor, which is a database design question as much as a legal one. Products aimed at children carry their own regime — see COPPA compliance for kids' apps and connected toys. This article is educational only and is not legal advice; a privacy attorney should review what actually applies to your product.

Mapping the Attack Surface Quickly

You do not need a formal threat model to make real progress. List every way data or commands enter the product and ask what an attacker gains by controlling that path:

• The radio link. Can traffic be sniffed, replayed, or spoofed? Is pairing authenticated?
• The physical board. If someone opens the case, can they read firmware or keys off flash?
• The cloud API. Can device A read device B's data by changing an ID in a request? This is the most common real-world breach in connected products and the cheapest to prevent.
• The mobile app. Are secrets embedded in the binary? Anything shipped in an app is public.
• The factory. Who can produce units with valid credentials, and can that be audited?

Practical Priorities and What It Costs

On a constrained budget, the order that buys the most safety per dollar is: unique credentials, then TLS with real certificate validation, then a working signed update path, then closing debug interfaces, then per-device keys in hardware, then a third-party penetration test before launch. Security work of this kind is a modest fraction of total firmware and cloud effort when planned from the start — usually low tens of thousands of dollars of engineering on a typical connected consumer product — and a much larger figure when retrofitted after a field incident. Our breakdowns of IoT product development cost and IoT cloud infrastructure cost put those numbers in context.

Platform choice helps. Managed IoT services handle per-device certificates, revocation, and policy enforcement so you are not building an authentication system from scratch; compare what each provides in AWS IoT vs Azure IoT. Compute choice matters too, since secure boot and key storage look very different on a small microcontroller than on embedded Linux — see microcontroller vs embedded Linux.

The Organizational Side

Security is not finished at launch. Someone has to own vulnerability reports, watch for advisories in the libraries and radio stacks you depend on, and be able to build, sign, and ship a fix within days rather than months. A published contact route for researchers and a documented support window are cheap to set up and are increasingly what buyers ask about.

Projects House is an engineering firm that develops connected products end to end — firmware, cloud, and app — with device identity, secure update, and hardened interfaces designed in from the architecture stage rather than patched afterward. If you are building a connected product and want the security layer done properly the first time, send us the details through our contact form and we will tell you what your product needs.