The three layers of an IoT product
Most problems in connected products show up at the joins between layers: a device that cannot be updated once it ships, an app that pairs only some of the time, or a cloud that cannot cope when thousands of devices reconnect at once. We treat the product as one system:
- Device: the firmware's connection layer, secure first-time setup (provisioning), local control where it makes sense, and over-the-air (OTA) updates with a safe fallback if an update fails.
- Cloud: device identity and authentication, a message broker (typically MQTT or HTTPS), storage for readings and events, rules and alerts, and an API for the apps and for your other systems.
- Apps: a mobile app for pairing, control, history and notifications, and a web dashboard for your team to manage devices, customers and firmware releases.
If you already have hardware and firmware from a manufacturer, we can start at the cloud and app layers and integrate with what the device already speaks.
Choosing connectivity
The radio decides battery life, range, cost per unit and how the app talks to the device. The common choices:
- Bluetooth Low Energy: low power, phone-to-device, short range. Ideal for wearables and personal devices, and often used only for setup. Needs a native or cross-platform app, since Safari on iPhone has no Web Bluetooth (see our guide Mobile app or web app?).
- Wi-Fi: direct internet access in homes and offices, higher power use. Setup (getting the device onto the customer's network) is the step that most often goes wrong, so it gets the most testing.
- Cellular (LTE-M, NB-IoT): works anywhere with coverage and without the customer's network, at the cost of a data plan per device. Good for trackers and equipment in the field.
- Low-power wide-area (LoRaWAN) and mesh (Thread, Zigbee): long battery life and many devices, usually through a gateway. Matter, the smart-home standard, runs over Thread and Wi-Fi.
Many products combine two: Bluetooth for setup, Wi-Fi or cellular for everyday data.
Security checklist
The OWASP IoT Top 10 lists the weaknesses that cause most real-world IoT compromises. We design against each one:
- Weak, guessable or hardcoded passwords: no default passwords; unique credentials or certificates per device.
- Insecure network services: only the ports and services the product needs, nothing left open from development.
- Insecure ecosystem interfaces: the cloud API, web dashboard and app are authenticated, authorised per user and per device, and tested like any web application.
- Lack of a secure update mechanism: signed OTA updates, verified on the device, with rollback.
- Insecure or outdated components: a list of the libraries and SDKs in the firmware and apps, so known vulnerabilities can be found and patched.
- Insufficient privacy protection: collect only the data the product needs, and let users see and delete it.
- Insecure data transfer and storage: encrypted connections (TLS) end to end and secrets kept out of plain-text storage.
- Lack of device management: the dashboard shows every device, its firmware version and status, and can disable a lost or compromised one.
- Insecure default settings: secure out of the box; users should not have to change settings to be safe.
- Lack of physical hardening: debug ports disabled or locked in production, so a device in an attacker's hands does not give up the keys to the rest.
Rules that now apply to connected products
Security for consumer IoT is no longer only good practice. Depending on where you sell:
- United Kingdom: the product security regime (PSTI) has applied since April 2024. It bans universal default passwords and requires a way to report vulnerabilities and a stated support period for security updates.
- European Union: the Cyber Resilience Act sets security requirements for products with digital elements, with obligations phasing in through 2027.
- United States: the FCC's voluntary U.S. Cyber Trust Mark labelling programme uses criteria based on NIST's baseline for consumer IoT devices.
Designing against the checklist above covers most of what these rules ask for. Formal certification is done by accredited labs; we prepare the product and documentation for it.
How a project runs
- Discovery: what the device does, who uses it, where it lives, and what data matters. We agree the connectivity and the architecture.
- Prototype: a working end-to-end slice on development hardware: device to cloud to app, including setup and one real feature.
- Build: the full apps, dashboard and cloud, firmware integration, OTA updates and security hardening, in short cycles you can test.
- Pilot: a small batch of devices with real users, to find setup and connectivity problems before volume.
- Launch and support: app store releases, monitoring, firmware and app updates for the life of the product.
Frequently asked questions
Do you design hardware?
Our focus is software: firmware connectivity, cloud and apps. For circuit and enclosure design we work alongside your hardware team or manufacturer.
Can you build an app for a device we already make?
Yes. If the device has a documented Bluetooth or network protocol, or the manufacturer provides an SDK, we can build the app and cloud around it.
Which cloud do you use?
It depends on scale and what you already use. Managed IoT services from the large cloud providers suit some products; a lean MQTT broker and API on a standard server suit others. We recommend one in discovery and explain why.
How are devices updated after they ship?
Over the air. Updates are signed, rolled out to a small group first, and the device keeps the previous version to fall back to if the new one fails to start.
What happens if a device is lost or sold?
The owner can remove it from their account in the app, and your team can disable it from the dashboard. A factory reset clears the owner's data and credentials from the device.
See all our web, mobile app and IoT development services or email info@creahive.com to talk about your product.