"Connect it to the cloud" sounds like one task. On the firmware side it is closer to eight, and the ones that get skipped are always the same: what happens when the network is gone, how the device knows what time it is, and how you push a fix to a thousand units already in the field.
The demo is easy — a development board publishing a temperature reading over Wi-Fi takes an afternoon. The gap between that afternoon and a product that stays connected for five years in someone else's building is where connected-hardware projects spend their money.
Identity and credentials come first
Before a device can talk to your backend, the backend has to know it is your device — the hardest decision to change later, because it touches the factory, the cloud, and the firmware at once. The firmware-side requirements:
- A unique identity per unit, not a shared credential in the image. One key across the fleet means a single extracted device compromises everything, with no revocation path.
- Secure storage. Private keys belong where an attacker holding the board cannot trivially read them — a secure element, or a locked flash region with readout protection verified in production test.
- A provisioning routine that runs once, on the line or at first boot, taking the device from blank to registered without a human typing anything.
- A rotation path. Firmware must renew certificates before expiry, or you get a fleet-wide outage on a date you could have predicted.
The manufacturing side — injecting keys and registering identities at line speed without leaking anything — is a project on its own, described in secure device provisioning on the production line. Decide the model before the PCB is finalized, because a secure element is a part you have to place.
TLS on a constrained microcontroller
Mutual TLS is the expected baseline and it is not free on a small part. Budget three things.
Flash and RAM. A TLS stack plus crypto library typically costs 40–120 KB of flash, and a handshake needs roughly 16–40 KB of RAM for buffers and session state. On a part with 64 KB of RAM that is a large fraction — one of the most common reasons a product outgrows its MCU mid-project. See how much flash and RAM your microcontroller really needs.
Time and energy. A full handshake with ECC key exchange can take several seconds on a Cortex-M without hardware acceleration, and it is the most power-hungry thing the device does. Use session resumption so reconnects skip it, and prefer ECC over RSA.
Certificate validation, properly. Ship the root CA in the image, verify the chain, verify the hostname. The temptation to disable validation during bring-up is universal and the flag often survives into production — add a compile-time guard that fails the release build if verification is off.
Buffering and store-and-forward
Assume the network will be unavailable, because it will be. Construction cuts the fiber; the customer's IT department changes the Wi-Fi password. A device that discards data when it cannot connect is a device whose data your customer cannot trust. Design the buffer deliberately:
- Where. RAM buffers vanish on reset. For anything you promised the customer, use flash with wear-leveling.
- How much. Pick an outage you will survive — 24 hours as a default, a week for remote sites — and size from your record rate. A good reason to keep records small.
- What to drop. When the buffer fills, something must go. Keep alarms forever and let routine telemetry decimate. Decide this in the requirements, not in an exception handler.
- Timestamps. Buffered records carry their own, and the backend must accept out-of-order arrivals without treating them as current values. This is where dashboards get embarrassing.
- Drain rate. Do not dump 40,000 records the moment connectivity returns, or your reconnecting fleet looks like a denial-of-service attack on your own backend.
Backoff, reconnection, and jitter
Reconnection logic is short code that decides whether your product is reliable. The pattern that works:
- Exponential backoff from a short first retry to a hard ceiling — 1 s, 2 s, 4 s, 8 s, up to 15 minutes.
- Random jitter on every interval, or a fleet that lost the same backend reconnects in lockstep and hammers it the moment it recovers.
- A layered reset ladder: retry the connection, re-resolve DNS, reset the radio module, reset the MCU — each step only after the one below fails repeatedly.
- Application-level keepalives, not just TCP. A NAT device or carrier gateway silently drops idle connections and the socket looks fine until a write fails minutes later.
- A local indication of connection state, so a technician can tell device from network without a laptop.
Your transport shapes how much of this you write yourself; MQTT brokers give you keepalives and last-will messages for free, part of the argument in MQTT versus HTTP for a connected product.
Knowing what time it is
An embedded device wakes with no idea what year it is, and almost everything depends on getting that right: certificate validity, timestamps on buffered data, scheduled behavior, log correlation across a fleet.
Keep an RTC running from the backup domain with a coin cell or supercapacitor so time survives a power cycle, sync on connect (SNTP is usually enough), and track drift — a cheap crystal can wander several seconds a day, which over a month ruins any analysis correlating events between devices. Store timestamps in UTC. One circular dependency is worth calling out: TLS wants a valid clock to check certificate expiry, and you get the clock from the network you need TLS to reach. Handle it explicitly, with a bounded grace window on first boot or an initial time provisioned at manufacture.
Payload format and size
Every byte costs energy on battery devices and money on cellular ones. A device on a metered plan sending verbose JSON every minute can spend more per year on data than the radio module cost.
| Choice | Typical size | Good for |
|---|---|---|
| Verbose JSON | Baseline | Prototypes, low-rate Wi-Fi devices |
| Short-key JSON | 50–70% | Readability while trimming |
| CBOR or MessagePack | 30–50% | Same structure, binary encoding |
| Protobuf with a schema | 20–40% | Fleets where schema discipline pays |
| Packed binary struct | 10–20% | Constrained links; strict versioning |
Whatever you pick, put a schema version field in every message from day one. You will change the payload, and a backend that cannot tell an old device's format from a new one breaks during a staged rollout. Compression pays above roughly 200 bytes per message; below that, header overhead eats the gain.
OTA hooks, designed in from the start
The most valuable thing in the first firmware release is the ability to replace it. Products ship with bugs, protocols change, certificates expire. A fleet you cannot update is one you will eventually recall or abandon. The minimum set:
- A bootloader that validates and installs an image, with a known-good fallback if the new one fails to run.
- Enough flash for two images. Budget this at PCB design time — retrofitting a second slot into a full part is not possible.
- Signature verification on every image, checked by the bootloader, with the public key where the application cannot rewrite it.
- Resumable download, since a large image over a marginal link will not arrive in one attempt.
- A version report on every connection, and staged rollout support: the backend picks who updates, not the device.
The full mechanics, including rollback strategy, are covered in OTA firmware updates, and the bootloader side in bootloaders in embedded products.
What to give the support team
Report connection state, signal strength, reconnect counts, buffer depth, reset reason, and firmware version as routine telemetry. Each is cheap to send and turns a support call from guesswork into a diagnosis — the pattern in remote diagnostics and logging in deployed devices.
None of this appears in a demo, which is why it gets underestimated. The plumbing described here — provisioning, TLS, buffering, reconnection, time, OTA — commonly runs 30–50% of total firmware effort on a connected product. A managed platform absorbs some but not all of it; the tradeoffs are in choosing between AWS IoT and Azure IoT, and the running costs in what connected-product cloud infrastructure runs per month.
Projects House builds firmware and cloud backends together, so the device side and the server side are designed against the same assumptions. To get the unglamorous parts scoped honestly, use the contact form.