IoT Development Guide

What is IoT development?

IoT development is the design and engineering of internet-connected devices together with the software that makes them useful: embedded firmware, a connectivity layer, a cloud back end for identity, messaging and data, user apps, and a fleet process for updates and support. It treats the device and its software as one product with a long service life.

The long life is what makes IoT different from app development. A phone app can be replaced in a day. A device on a wall, a vehicle or a factory floor may run the same hardware for many years, so every early decision about identity, updates and data formats lasts as long as the hardware does.

Which layers make up a connected product?

A connected product has five layers, and each needs its own owner and test plan. The list below shows what each one does and the decision that matters most in it.

• Device and firmware: The microcontroller or processor, sensors and the firmware or embedded Linux image. The key decision is how much memory and flash to reserve for future updates and security features.
• Connectivity: The radio and protocol that move data off the device, such as Wi-Fi, Bluetooth Low Energy, cellular or a low-power wide-area network. The key decision is the match between power budget, range and data volume.
• Cloud: Device identity, a message broker, storage and the rules that act on incoming data. The key decision is the topic and data model, because every device and app will depend on it.
• Apps: The mobile or web apps for onboarding, control and reporting. The key decision is how a new device is claimed by the right user or account.
• Fleet operations: The registry, update service, monitoring and support tools. The key decision is how you find and fix one faulty unit among many.

A common gap is staffing the first three layers well and leaving fleet operations until late. Fleet tooling is what support and operations teams use daily after launch, so it deserves design time early.

How do you choose the connectivity?

You choose connectivity by starting from the power source, the distance to the nearest gateway or network, and how much data the device sends. Cost and certification follow from those three.

• Wi-Fi: Suits mains-powered devices in homes and offices that send moderate or large amounts of data. Onboarding to the user's network is the main design task.
• Bluetooth Low Energy: Suits battery devices that sit near a phone or a hub. Data reaches the cloud through that phone or hub, so the app becomes part of the data path.
• Cellular LTE-M or NB-IoT: Suits devices that move or sit far from local networks. It adds a carrier contract, SIM management and carrier certification to the plan.
• LoRaWAN: Suits small, infrequent messages over long range on battery power, through gateways the operator or a network provider runs.
• Thread with Matter: Suits smart home devices that need to work across several ecosystems, with Bluetooth LE used during commissioning.

Some products combine two radios, for example Bluetooth LE for setup and Wi-Fi or cellular for data. Plan the firmware, power and certification work for both from the first prototype.

From prototype to fleet in seven steps

A connected product moves from prototype to fleet through seven steps, and a skipped step can show up as a field problem later. The order below reflects which decisions are hardest to change.

• 1. Requirements: Define what the device measures or controls, its power source, its expected service life and the markets it will be sold in, because those set the security and radio rules.
• 2. Prototype: Build on development boards to prove the sensing and the data path end to end, with a throwaway cloud if needed.
• 3. Identity and provisioning: Decide how each unit gets a unique identity, such as an X.509 certificate created or injected at the factory, and how the cloud registers it.
• 4. Messaging and data model: Choose the protocol, often MQTT, and design topics, payload schemas and versioning so old and new firmware can coexist.
• 5. Update path: Build signed over-the-air updates with rollback before the first field trial, not after it.
• 6. Field pilot: Run a limited batch in real conditions and watch connection drops, battery life, update success and support calls.
• 7. Fleet launch and support: Turn on monitoring, staged rollouts and support tools, and set the period for which the product will receive security updates.

For messaging, the newer MQTT version adds features such as reason codes, message expiry and shared subscriptions that help large fleets. Check that the chosen broker or cloud service supports the version and features you plan to use.

Updates that do not brick devices

Over-the-air updates are safe when each image is signed, the device can fall back to the last good version, and rollouts happen in waves that stop on bad signals. Without all three, one bad release can disable a fleet.

• Signed images: The device verifies the update's signature against a key it trusts before installing anything.
• A and B partitions: The device writes the new image to an inactive slot and switches only after it boots and checks in.
• Automatic rollback: If the new image fails to boot or connect within a set window, the device returns to the previous slot.
• Staged rollout: Release to a small group first, compare boot and connection health with devices on the old version, then widen.
• Version tracking: The cloud records the firmware version each device reports, so support can see who has what.
• Power and network checks: The device delays installing when the battery is low or the connection is unstable.

Which security rules shape an IoT product?

In the US the main guidance is voluntary and comes from NIST and the FCC, while the EU has made product cybersecurity mandatory. These facts set the baseline to plan against.

• NIST IR 8259 Rev. 1: Published in April 2026 as "Foundational Cybersecurity Activities for IoT Product Manufacturers", it describes cybersecurity activities manufacturers should consider before their products are sold, and it supersedes the 2020 version.
• NISTIR 8259A: The core baseline lists six device capabilities: device identification, device configuration, data protection, logical access to interfaces, software update and cybersecurity state awareness.
• EU Cyber Resilience Act: Regulation (EU) 2024/2847 applies to products with digital elements. Manufacturers' reporting duties for actively exploited vulnerabilities and severe incidents apply from 11 September 2026, with an early warning due within 24 hours, and the main obligations apply from 11 December 2027.
• FCC U.S. Cyber Trust Mark: A voluntary labeling program for consumer wireless IoT products under 47 CFR Part 8. Its administrators and standards were still being set during 2026, so check the FCC program page before planning a label.

The six NISTIR 8259A capabilities make a practical design checklist. For each one, name the firmware feature, the cloud feature and the app feature that deliver it, and the test that proves it.

Two habits make the checklist cheaper to keep. Give every unit its own credential from the factory, never a shared default password, and publish a simple way for researchers to report vulnerabilities. Both are expected by consumer IoT baselines in several markets, and both are hard to add after devices ship.

Keep the evidence with the build. Store the software bill of materials, the signing records and the security test results for each firmware release, so a buyer, a test lab or a regulator can see what shipped and when.

Where IoT products fail after launch

After launch, IoT products are most exposed on identity, updates and dependencies rather than on the core feature. This failure-point list covers the issues worth designing out.

• Shared credentials: Every unit ships with the same key or password, so one extracted device exposes the fleet.
• No rollback: An update that fails on one hardware revision leaves those devices unusable until a technician visits.
• Rigid payloads: A new firmware field breaks the cloud parser, so the team cannot change the data format without a fleet-wide update.
• Cloud service retirement: Google retired its Cloud IoT Core service, forcing customers to migrate. Keep device-facing protocols standard so a provider change does not mean new firmware.
• Unknown components: Without a software bill of materials, nobody can tell which devices carry a library with a newly published vulnerability.
• No support period: The product has no stated end date for security updates, which the EU Cyber Resilience Act now expects manufacturers to set.
• Debug ports left open: Production units keep debug interfaces enabled, giving physical attackers an easy path.

How Agnotic can help

Connected products succeed when device identity, the data model and the update path are designed before the first production batch. Agnotic Technologies builds the cloud, app and fleet software for connected products with the client's firmware and hardware team, covering provisioning, MQTT messaging, signed updates, staged rollouts and the fleet console.

Agnotic can also map the product against NISTIR 8259A capabilities and the EU Cyber Resilience Act timelines, so security features and evidence are planned with the build. Circuit design, enclosures and radio certification stay with the client's hardware partners and accredited labs.

Sources

• NIST IR 8259 Rev. 1: Foundational Cybersecurity Activities for IoT Product Manufacturers
• NISTIR 8259A: IoT Device Cybersecurity Capability Core Baseline
• European Commission: Cyber Resilience Act reporting obligations
• FCC: U.S. Cyber Trust Mark program