The promise, and the pressure
IoT is a deployed reality operating at a scale that even industry analysts underestimated a decade ago. IoT Analytics counts 21.1 billion active connected IoT devices in 2025, projected to reach 39 billion by 2030 — a 13.2% CAGR driven largely by AI-hungry data pipelines and industrial digitalization.
For engineering leaders, that growth cuts both ways. Every connected node is a new revenue vector — and a new liability. A smart water meter, a connected insulin pump, a factory-floor vibration sensor: each must survive harsh conditions, stay secure for a decade or more, and interoperate with infrastructure that didn’t exist when the device was specced.
This post distills hard-won lessons from the Orthogone engineering floor — the same lessons Olivier Allaire shared at a recent trade show keynote — paired with fresh 2026 data so you can benchmark your own program.
The IoT checklist: more dimensions than most roadmaps admit
When teams scope an IoT product, they typically anchor on features, hardware, and connectivity. But a production-grade IoT program has to answer for at least nine concerns before the first board spin:
- Features — what the device actually does for the user
- Hardware — BoM, power envelope, mechanical constraints
- Backend — cloud services, APIs, data pipelines
- Connectivity — protocols, bearers, geographic coverage
- Security — from silicon root-of-trust to cloud IAM
- Provisioning — how a device moves from factory to customer network
- Updates — OTA strategy, rollback, signing
- Maintenance — field support, telemetry, RMA logistics
- Remote payments / monetization — if applicable, another attack surface entirely
Miss any one of these and you don’t have an IoT product. You have a prototype with a latent cost curve.
The three pressures that shape every IoT program
Three forces consistently determine whether an IoT product lives a long, profitable life or becomes a drag on the balance sheet.
1. The relationship with the end user
An IoT device creates an ongoing obligation. Users don’t just buy a thing — they buy a service, an uptime promise, and an implicit data contract. That relationship can generate recurring revenue for years. It can also become a multi-year support liability if your firmware, backend, or security posture slips.
2. Demanding operational conditions
IoT devices live where engineers don’t: in attics, on tractors, inside walls, underwater, at altitude. Temperature swings, dust, vibration, intermittent connectivity, and power instability are the default. Designs that pass bench testing can still fail at 3 a.m. on a cold day in a customer’s warehouse.
3. Maintenance costs that compound
A bug that costs $0.10 to fix in design can cost $10 in manufacturing and $1,000+ in the field — before you count brand damage. With IoT fleets averaging 10–25 year lifecycles on industrial gear, small early-stage shortcuts compound relentlessly.
Five engineering disciplines worth getting right
Discipline 1: Validate assumptions early
The single most expensive mistake in IoT is confusing a working demo for a working product. Before committing to tooling or volume:
- Test as soon as possible on representative hardware, in representative environments.
- Engage stakeholders continuously — sales, operations, regulatory, customer support — not just at gate reviews.
- Participate in plugfests and interoperability events for your chosen standards. A standards-compliant device that fails against a major ecosystem partner’s stack is still a failed device.
- Bake certification into the schedule from the start. Certification rework is one of the top three causes of IoT launch delays.
- Don’t accept inactive hardware. If a board has been sitting unpowered for six months, it’s an unknown. Treat it like one.
Discipline 2: Do not underestimate small problems
Most catastrophic IoT field failures start as small, “known” quirks that someone decided could wait. The classic bathtub curve — high early-life return rates, a stable middle period, then rising end-of-life failures — is real. The shape of your curve is largely determined in the first six months of engineering.
Three practices move it in your favor:
- Empower teams to catch and fix problems in design. Keep technical project managers in the loop at every stage. Tap your network — suppliers, reference-design engineers, standards body contacts. And don’t compress the testing phase. Sending engineers out to debug a deployed device is expensive and disruptive.
- Design defensively. For consumer electronics, “good enough” works. For IoT, it doesn’t. Choose more robust components, more conservative timing margins, and more rigorous EMC designs, even if BoM cost rises a few percent.
- Patch to the root cause. When something breaks in the field, go after the actual problem — not the symptom. A short-term fix that masks the defect will cost you later. Debugging remotely, over a constrained link, with incomplete telemetry, is genuinely hard. Teams that invest in observability up front debug in hours what others debug in weeks.
Discipline 3: Treat connectivity as a contract, not a checkbox
A device that is “online” but returning stale or malformed data is effectively offline — worse, actually, because it creates false confidence.
When designing the connectivity layer, explicitly account for:
- Service — what SLAs can the bearer realistically meet in deployment geographies?
- Data — payload design, compression, delivery guarantees, and replay handling
- Metadata — timestamps, firmware version, signal quality, battery state
- Updates — OTA payload size vs. data plan cost, rollback strategy, staged rollouts
LPWAN and 5G RedCap are reshaping this layer. Operators now price annual IoT data plans below $2 per device in many markets, which changes the economics of always-on designs. LoRaWAN and NB-IoT shipments crossed 180 million units in 2025, led by utility meter rollouts. Choose your bearer strategy with a five-year horizon, not a one-year one.
Discipline 4: Design for an evolving IoT ecosystem
- Plan for the infrastructure you actually want. Costs related to traffic load are almost never linear with device count. Make sure you have all the requirements — including the ones no one wrote down because “everyone knows.”
- Scale selectively. Choose the right moment to move to the next tier. When something breaks at scale, dig into the problem rather than throwing instances at it. Cloud bills have buried more IoT businesses than any technical issue.
- Plan for the passage of time. Evaluate interdependencies between your device, your cloud, and your ecosystem partners. Data lifetime and archive policies belong on the checklist — especially with the EU Cyber Resilience Act phasing in, with reporting obligations starting September 2026 and main obligations from December 2027.
Discipline 5: Functionality is still the core of the product
It’s easy, surrounded by cloud dashboards and security protocols, to lose sight of why the device exists. Every architectural choice, every security mitigation, every scaling decision should be reviewable against one question: does this make the product better for the person using it?
The 2026 reality check
36%
Of organizations reported compromised IoT or OT devices linked to wireless security incidents in the past 12 months (Cisco 2026 State of Wireless Report). IoT is no longer an edge-case threat surface. It is the threat surface.
60%
Of IoT breaches trace back to unpatched firmware (industry research, 2025). If your OTA pipeline is fragile, your security posture is fragile — regardless of how good your crypto is.
$4.82M
Average breach cost in critical infrastructure — up 107% year over year (IBM Cost of a Data Breach 2025). For industrial IoT deployments in energy, water, and transport, one incident now eclipses the entire lifetime development budget of most products.
Where Orthogone fits
Orthogone is a multidisciplinary engineering partner with 110+ engineers in R&D, electronic product design, embedded and edge software, and digital transformation consulting, from initial concept through commercialization. We do software, hardware, and FPGA development for OEMs, startups, and enterprises navigating the exact trade-offs described in this post. If any of this sounds familiar, reach out
Big things have small beginnings. — The IoT engineer’s unofficial motto.
