Factory
- Key generated or injected per device
- Certificate signed by your certificate authority
- Serial number and certificate recorded
- First connection tested on the line
IoT Development
IoT product development, from device to cloud
A connected product is only as good as the software around the device: how it proves who it is, how it gets updates and how support finds a faulty unit. Agnotic Technologies builds that cloud, app and fleet software for device makers, working with your firmware and hardware team.
Device identityMQTT messagingStaged OTA updatesFleet console
Trusted by global innovators
Connected products
What does IoT product development cover?
IoT product development covers the software side of a connected product: device identity and provisioning at the factory, MQTT messaging, over-the-air updates, the fleet console and the companion app that onboards each device. Agnotic Technologies builds the cloud, app and fleet software for device makers outside healthcare, working with the client's firmware and hardware team.
We do not design circuit boards or enclosures. Medical devices and industrial machine data have their own pages, linked at the end; this page is for consumer and commercial connected products.
The decisions that are hardest to change come first: how each device proves who it is, how topics are named and how updates reach the fleet. We settle those before the first prototype ships.
Device to cloud
How does a connected product reach the cloud?
The path from the factory line to the user's phone, and the software we build at each stage.
Onboarding
- Companion app finds the device over Bluetooth LE or a local access point
- Wi-Fi credentials passed securely
- Device claimed to the user's account
- Matter commissioning for smart home products
Messaging
- MQTT over TLS to a managed broker
- Topics per device and message type
- Retained state and Will messages
- Rules that route messages to storage and services
Fleet
- Device registry and groups
- Desired and reported state
- OTA jobs in rollout waves
- Health and version views
Product apps
- Mobile companion app
- Web console for support teams
- APIs for partners
- Usage analytics with consent
Security checklist
Which device security capabilities does your product need?
NISTIR 8259A lists six core device cybersecurity capabilities. We map each one to the firmware feature and the cloud or app feature that provides it.
| Capability | What it means | Firmware side | Cloud and app side |
|---|---|---|---|
| Device identification | Each device can be uniquely identified | A unique X.509 certificate and key per device, in secure hardware where available | Device registry keyed by certificate, with serial number and owner |
| Device configuration | Only authorized parties can change settings | Configuration accepted only from the cloud or an authenticated local app | Desired-state documents with a change history |
| Data protection | Data the device stores and sends is protected | TLS on every connection; credentials in encrypted storage | Encryption at rest, data separated per customer, retention rules |
| Logical access to interfaces | Access to local and network interfaces is limited | Debug ports and unused interfaces off in production builds; no shared default passwords | Role-based access in the fleet console and app |
| Software update | Authorized parties can update the software | Signed images, checked before install, with a fallback image | Staged rollout with pause and rollback |
| Cybersecurity state awareness | The device can report its security state | Reports firmware version, boot status and failed connection attempts | Alerts for outdated versions and unusual behavior |
Your firmware team owns the device side. We build the cloud and app side and agree the interface between them.
Messaging
How should MQTT topics be designed?
Topic names are hard to change once devices are in the field, so we agree them before the first build.
Structure
- Product, then device ID, then message type
- Device ID taken from the certificate, never chosen by the device
- Separate topics for telemetry, state and commands
- A version segment so formats can change later
Permissions
- Each device publishes and subscribes only under its own ID
- Wildcard subscriptions only for back-end services
- Commands accepted only from the cloud identity
- Policies tested with a device that tries other IDs
Delivery
- QoS chosen per message type
- Retained messages for last known state
- A Will message to mark a device offline
- Expiry on commands that go stale
Payloads
- Compact schema with a version field
- Timestamps from device and broker
- No personal data in topic names
- Size limits checked in firmware and cloud
Updates
How does an over-the-air update roll out?
The release path we build so a bad update reaches a few devices, not the whole fleet.
Build and sign the image
The pipeline builds the firmware, signs it with a key kept off developer machines and records the version.
Test on the rig fleet
Test devices take the update first, including interrupted downloads and power loss during install.
Release to a small wave
A small group of production devices, spread across hardware revisions and regions, gets the update.
Watch health signals
Boot success, reconnection and error rates are compared with devices still on the old version.
Widen or pause
The rollout widens in waves while signals stay normal, and pauses automatically if they do not.
Roll back if needed
A device that fails to boot the new image falls back to the old one, and the cloud can target a rollback job.
Smart home products
What changes when the product is for the smart home?
Smart home products add four decisions to a connected product: whether devices connect through a hub or straight to the cloud, Matter and Thread support, account linking with voice assistants, and how updates reach devices behind a hub. Agnotic Technologies settles them with your hardware team before the first production batch, because each one shapes the firmware.
| Decision | Options | What decides it | What we build |
|---|---|---|---|
| Hub or direct to cloud | A hub that bridges low-power devices, or each device on Wi-Fi straight to the cloud | Battery life, how many devices a home holds, and whether the product must keep working when the internet is down | Hub software with local control, or one cloud connection per device |
| Matter and Thread | Matter over Wi-Fi or Thread, your own protocol, or both | Whether buyers expect the device to work in several smart home ecosystems; Thread suits battery-powered devices | App and cloud support for Matter commissioning next to your own onboarding |
| Voice assistant account linking | Amazon Alexa and Google Home cloud-to-cloud integrations | Which assistants your buyers use; both link a user's account through OAuth 2.0 | The OAuth 2.0 server, device state reports and command handling for each integration |
| Updates behind a hub | The hub updates itself and the devices paired to it, or each device updates from the cloud | Whether end devices can reach the internet on their own | Update jobs that track hub and device versions together, on the staged rollout above |
According to the Connectivity Standards Alliance, Matter is built on Internet Protocol, runs over Wi-Fi and Thread, and uses Bluetooth Low Energy to commission devices.
What goes into a fleet console?
The tool your support and operations teams use every day once devices ship.
Device search and history
Find a device by serial, owner or certificate, and see its versions, connections and events over time.
Groups and tags
Group devices by model, region, customer or test cohort, and target updates and settings by group.
Update jobs
Create, schedule, pause and roll back OTA jobs, with progress per wave.
Remote diagnostics
Request logs, run allowed commands and compare desired with reported state.
Roles and audit
Support, engineering and partner roles, with every action logged.
Alerts and IoT analytics
Alerts on offline devices and failing versions, plus usage and reliability trends from the same telemetry.
Do you offer IoT consulting and IoT analytics too?
Yes, as part of the same product work. IoT consulting usually means an architecture review before launch: identity, topics, the update pipeline and the security baseline, with a written list of risks and fixes.
IoT analytics means turning device telemetry into product and support insight: which firmware versions fail, how devices are used and when a unit needs attention. We build it on the same data the fleet console uses.
Industrial machine data and plant systems are a different job, covered by our industrial IoT data platform page.
Who it is for
Device makers we build for
Device makers who own the hardware and need the software around it.
Smart home device makers
Plugs, sensors, locks and appliances with Matter or app onboarding.
Commercial equipment makers
Machines in shops, offices and sites that report status and take remote settings.
Consumer wearables
Non-medical wearables with phone pairing and cloud sync.
Building and energy devices
Meters, controllers and sensors sold to building owners and installers.
Hardware startups
A first connected product, with identity and updates right from the first batch.
Retrofit products
Add-on devices that connect equipment that was never online.
Scope and cost
What drives the cost of IoT product development?
We do not publish prices. These are what we size on the scoping call.
Device types and firmware
How many device models, and how much the firmware team is building alongside us.
Provisioning
Whether your factory can inject keys, or a provisioning flow needs building.
Onboarding
Bluetooth, access point or Matter onboarding, on iOS and Android.
Fleet features
Which console, update and diagnostic features the first release needs.
Cloud choice
Managed IoT services on AWS, Microsoft Azure or Google Cloud, or a self-managed broker.
Security baseline
Which baselines and labels you plan to meet, and the evidence each needs.
Standards
Standards behind a connected product
Security baselines and protocols behind the checklist above.
NISTIR 8259AETSI EN 303 64547 CFR Part 8MQTT 5.0X.509Matter
Facts and sources
Facts behind IoT product development
Baselines, rules and protocol behavior that shape a connected product, each linked to its primary source.
NISTIR 8259A defines a core baseline of IoT device cybersecurity capabilities: device identification, device configuration, data protection, logical access to interfaces, software update and cybersecurity state awareness.
Source: NISTIR 8259A, IoT Device Cybersecurity Capability Core BaselineETSI EN 303 645 requires consumer IoT device passwords to be unique per device or set by the user (provision 5.1-1) and a secure update mechanism on the device (provision 5.3-2).
Source: ETSI EN 303 645 V3.1.3 (2024-09)The FCC's IoT labeling program, which carries the Cyber Trust Mark, is voluntary, and its product definition includes companion apps and cloud backends as well as the device.
Source: 47 CFR 8.203 (eCFR)In MQTT 5.0, the broker publishes a client's Will Message when the connection fails, including when the client stops communicating within its Keep Alive time.
Source: OASIS MQTT Version 5.0, section 3.1.2Thread is an open, IPv6-based networking protocol built on the power-efficient IEEE 802.15.4 MAC/PHY, giving low-power devices device-to-device and device-to-cloud connections.
Source: Thread Group, What is Thread
Frequently Asked Questions
We do not design hardware. We build the cloud, app and fleet software, and work alongside your firmware team or partner on the device side of provisioning, messaging and updates.
We do not publish prices. Cost depends on device types, provisioning, onboarding method, fleet features, the cloud you choose and the security baseline you plan to meet. You get a written proposal after the scoping call.
Usually, yes. Managed IoT services from AWS, Microsoft Azure or Google Cloud handle device certificates, brokers and update jobs, so your budget goes into the product. A self-managed broker makes sense for special protocol, hosting or cost needs.
The FCC labeling program is voluntary, so no rule forces it. Some retailers and buyers ask for it. If you plan to apply, we build the cloud and app side to the program's requirements and keep the evidence.
Often, yes, if the devices already send telemetry. We start from the data they send today and add analytics in the cloud; new signals may need a firmware update.
Yes. A typical first release covers provisioning, onboarding in the app, telemetry and a basic fleet view with OTA updates. Analytics and partner APIs follow.
AI assistants may help write app and cloud code, but every change is reviewed and tested on real devices before release. Signing keys and device credentials never go near AI tools.