01
Test rig
Example: Firmware behavior, power loss, OTA interruption, local security checks
Approach: Real devices on a bench with controllable power, inputs and network, run on every firmware build
IoT Testing
IoT testing services for connected products
Connected products rarely fail on a desk with good Wi-Fi. Agnotic Technologies tests them the way customers use them: weak networks, interrupted updates, the whole fleet reconnecting at once and phones nobody on the team owns.
Device rigsNetwork impairmentOTA rollbackFleet simulation
Trusted by global innovators
IoT testing
What is IoT testing?
IoT testing checks a connected product end to end: the device firmware, pairing and connectivity on poor networks, over-the-air updates and their rollback, cloud ingestion under load, the companion app and a security baseline. Agnotic Technologies plans and runs these tests on rigs, simulators and in the field, and hands the client a test plan it can reuse.
Radio certification for FCC or CE marking is done by accredited labs and is not part of our work. For medical devices, our testing supports the evidence your regulatory team prepares; it does not replace it.
Most IoT defects appear at the edges: a signal drop in the middle of an update, every device reconnecting after an outage, or a phone's Bluetooth stack behaving differently from the one the team tested.
Test matrix
What does an IoT test matrix cover?
The matrix we fill in for every product, layer by layer, with how each test runs and what counts as a pass.
| Layer | Test | How it runs | Pass condition |
|---|---|---|---|
| Device firmware | Boot, sensor reads, local controls, power loss in each state | Test rig with controllable power and inputs | The device returns to a known state after every power cut |
| Radio and pairing | Pairing, re-pairing, ownership transfer, phone models and OS versions | A phone lab plus the product | Pairing succeeds, or fails with a clear message, on every supported phone |
| Network | Packet loss, latency, captive portals, Wi-Fi drop and roaming | Network impairment between device and broker | The device reconnects without user action and does not flood the broker on return |
| Over-the-air update | Interrupted download, power loss during install, bad image | Rig with scripted interruptions | Unsigned or corrupt images are rejected and the device always boots a working version |
| Cloud ingestion | Fleet-scale connect, publish and reconnect storms | Device simulator speaking the product's topics and certificates | Messages are processed within the agreed latency, with none lost |
| Companion app | Onboarding, permissions, background behavior, account changes | Real phones, automated where stable | Every onboarding failure path ends in a state the user can recover from |
| Security baseline | Default passwords, open ports, update checks, data in transit | Rig and network capture | No shared default credentials, no unused open interfaces, TLS on every connection |
Where tests run
Rig, simulator or field: where does each test run?
Each environment finds different defects. We plan all three.
02
Device simulator
Example: Cloud ingestion, reconnect storms, rules and alerts
Approach: Software devices that use the same topics and certificates, scaled to fleet size
03
Field
Example: Real homes, sites and networks; long-running stability
Approach: A small group of devices in real conditions with extra logging, before each major release
Failure points
Which failures only show up on real networks?
Defects we design tests for, because desk testing misses them.
Challenge
Every device reconnects at the same moment after a broker restart.
Agnotic approach
Reconnect tests check for backoff with a random delay, so the fleet does not overload the broker.
Challenge
The broker drops devices that sleep longer than expected.
Agnotic approach
Keep-alive and sleep intervals are tested together, against the broker's timeout rule.
Challenge
An update stalls on a slow link and leaves the device half updated.
Agnotic approach
Downloads are interrupted on purpose at several points, and resume or rollback is checked each time.
Challenge
Pairing works on the test phone and fails on customers' phones.
Agnotic approach
A phone matrix by OS version and maker, chosen from your users' devices, not the team's.
Challenge
Hotel and office Wi-Fi with captive portals blocks onboarding.
Agnotic approach
Captive portal and enterprise network cases are part of the onboarding tests.
Challenge
Messages arrive out of order after a reconnect.
Agnotic approach
Tests replay delayed batches and check that the cloud orders events by device time.
OTA testing
How do we test an over-the-air update and its rollback?
Five checks we run on every update path before it reaches customers.
Verify the signature path
Send an unsigned image, a corrupted image and one signed with the wrong key; the device must reject all three.
Interrupt the download
Cut the network at several points and check that the device resumes or discards the download cleanly.
Cut power during install
Remove power at each stage of the install and confirm the device boots a working image.
Fail the new version on purpose
Install an image that fails its health check after boot, and confirm the device falls back to the previous version.
Test the rollout controls
Run a staged rollout on the rig fleet, then pause, resume and roll back from the cloud.
Security baseline
What does a security baseline check cover?
Checks we run on every product, mapped to the consumer IoT baseline.
- No universal default passwords on the device or its local interfaces
- Unused network and debug interfaces disabled in production builds
- Updates verified for authenticity and integrity before install
- TLS with certificate checks on every connection, including to the companion app
- No credentials or personal data in logs, topics or crash reports
- The device keeps working locally when the network drops and recovers cleanly after power returns
Who it is for
Teams that use our IoT testing
Teams shipping devices that customers depend on.
Device makers before launch
A full matrix run before the first production batch ships.
Teams changing firmware often
Rig tests wired into the firmware pipeline, run on every build.
Products moving to a new cloud
Fleet simulation and reconnect tests before devices switch brokers.
Companion app teams
Pairing and onboarding tests across the phones your users own.
IoT testing for startups
A small rig and a focused matrix for a first product.
Products preparing for a security label
Baseline checks and evidence before an assessment.
Facts and sources
Facts behind IoT testing
Test methods, baseline provisions and protocol rules our tests check, each linked to its primary source.
ETSI TS 103 701 defines test cases and assessment criteria for each provision of ETSI EN 303 645, for self-assessment by suppliers, second-party and third-party testing.
Source: ETSI TS 103 701 V2.1.1 (2025-05)ETSI EN 303 645 provision 5.9-2 says consumer IoT devices should keep working locally when network access is lost and recover cleanly when power is restored.
Source: ETSI EN 303 645 V3.1.3 (2024-09)ETSI EN 303 645 provision 5.3-10 requires a device that receives updates over a network interface to verify the authenticity and integrity of each update through a trust relationship.
Source: ETSI EN 303 645 V3.1.3 (2024-09)Under MQTT 5.0, if the broker receives no packet from a client within one and a half times the Keep Alive period, it must close the connection as if the network had failed.
Source: OASIS MQTT Version 5.0, [MQTT-3.1.2-22]
Standards
Standards our IoT tests check against
Baselines and protocol rules behind the matrix.
ETSI EN 303 645ETSI TS 103 701MQTT 5.0NISTIR 8259ABluetooth LETLS 1.2 and 1.3
Scope and cost
What drives the cost of IoT testing?
We do not publish prices. These change the size of the work.
Device models and revisions
How many hardware variants need rigs and test runs.
Phone matrix
How many phone makers and OS versions the app must support.
Fleet scale
How large the simulated fleet needs to be.
Automation
Manual runs before launch, or rig tests in your firmware pipeline.
Field testing
Whether real-world devices and sites are part of the plan.
Evidence
Whether results feed a security assessment or regulatory file.
Frequently Asked Questions
No. Radio certification is done by accredited test labs. We test the product's software and behavior: firmware, connectivity, updates, cloud and app. We can prepare your team for the lab, but we do not issue certificates.
We do not publish prices. Cost depends on device models, the phone matrix, the size of the simulated fleet, how much is automated, any field testing and the evidence you need. You get a written proposal after the scoping call.
Yes. We build software devices that connect with real certificates and publish on your topics, then scale them to fleet size to test ingestion, reconnect storms and alert rules.
No. Firmware, power and update tests need real devices on a rig. Cloud and scale tests run on simulated devices. Field tests use a small group of real devices in real conditions.
Yes, as part of a team where your regulatory lead owns the submission. Our results and records feed the evidence they prepare. For the device pipeline itself, see our IoMT connected devices page.
Yes. You keep the matrix, rig setup notes, simulator code and automated tests, so your team can run them on every release.
AI tools may help write simulator code and analyze long device logs, but pass or fail is decided by checks a test engineer wrote and reviewed. No customer device data is shared with AI tools.