The Firmware Is the Cheap Part: What a Connected Product Actually Costs Once You Owe It Five Years of Updates

The Cost Structure That Breaks Connected Products

Hardware businesses and software businesses have opposite cash-flow shapes, and a connected product is both. The hardware sale is a single transaction with a margin that, for most consumer and light industrial products, is consumed within a few months of shipping. The software obligation attached to that device runs for as long as the device is in the field — which for industrial sensors, building systems or medical peripherals is routinely a decade.

For twenty years the industry resolved this asymmetry by ignoring it. Devices shipped, firmware was frozen, vulnerabilities went unpatched, and the commercial answer to a security problem was a successor model. That approach is now explicitly unavailable in the European market. The Cyber Resilience Act requires updates for the full expected lifetime of the product and at least five years, and it applies regardless of whether the product has already been superseded by a newer model — which removes precisely the escape hatch manufacturers have relied on.

The practical implication is that a connected product's cost model has to be written as a lifetime model or it is wrong. Development cost, then a per-year maintenance obligation multiplied by the support term, then a device-fleet operating cost that scales with units shipped. A product with a €400,000 development budget and a €90,000 annual support obligation across a five-year term is an €850,000 commitment, and it will be a nine-year obligation if the device turns out to have a nine-year field life. That is the number to take to a board, not the development figure.

Teams that model it this way make different product decisions — fewer device variants, longer hardware generations, more shared firmware platform, harder scrutiny of whether a feature genuinely needs to live on the device. Those are all correct decisions and they only become visible once the lifetime cost is on the page.

OTA Is Not a Feature, It Is the Product's Life Support

Every 2026 regulatory framework converges on the same requirement. CRA guidance for IoT manufacturers, ETSI EN 303 645, NIST guidance and the US Cyber Trust Mark all require that connected products be maintainable and kept current throughout their supported life. Shipping a device without a secure, reliable update mechanism stopped being a technical debt decision and became a compliance failure.

Building OTA properly is a bigger project than teams expect, and the reason is that the failure modes are catastrophic rather than annoying. A failed web deployment is rolled back in minutes. A failed firmware update on ten thousand devices in customer premises is a truck roll, and for some product categories it is the end of the company. That asymmetry dictates the architecture.

The non-negotiable pieces are well established: A/B partitioning so a device boots the previous image if the new one fails to come up, cryptographic signing with keys held in an HSM and a defined rotation procedure, secure boot enforcing the chain, atomic updates that cannot leave a device in a half-written state, and a rollback path that works when the device is unreachable. Then the operational layer that manufacturers consistently underestimate: staged rollout by cohort with automatic halt on failure-rate thresholds, per-device version and health telemetry, and the ability to answer "which firmware version is running on which devices in which countries right now" — a question you will be asked under time pressure the first time a vulnerability is disclosed.

A reasonable planning figure: OTA infrastructure and device fleet management is comparable in engineering effort to the device's entire application firmware. Teams routinely budget it as a fraction. That single estimation error explains more late connected-product programmes than any other, because it is discovered in integration rather than in planning.

The 24-Hour Clock

From 11 September 2026, actively exploited vulnerabilities must be reported within 24 hours to ENISA and the relevant national CSIRT. That obligation reaches into the engineering organisation in ways a legal summary does not convey.

Twenty-four hours is not a lot of time to determine whether a vulnerability is actively exploited in your fleet. Answering that requires telemetry that most connected products do not emit: device-level security event logging, a way to correlate anomalous behaviour across a fleet, and — critically — a defined path for external researchers and customers to report something to a human who is on call. If your first notification arrives via a support ticket queue with a two-day SLA, the clock has already run.

It also requires that someone can determine exposure quickly. Which firmware versions contain the affected component? Which devices are running them? Which are internet-exposed versus behind a customer gateway? These are software bill of materials questions, and a connected product without an accurate, versioned SBOM per firmware release cannot answer them inside a day. Generating an SBOM at build time is a modest engineering task; reconstructing one retrospectively for eleven shipped firmware versions is not.

The correct response to the 24-hour clock is therefore mostly preparation rather than process. SBOM generation in CI for every firmware artefact. Fleet telemetry that includes version and health. A published vulnerability disclosure contact that reaches an engineer. A rehearsed incident procedure with named roles. Manufacturers who put these in place before a disclosure treat the clock as a reporting exercise. Those who do not spend the first twenty of their twenty-four hours discovering what they shipped.

Where Connected Product Budgets Actually Go

If you are estimating a connected product, these are the line items that reliably land outside the initial figure.

Device fleet management. Provisioning, identity, certificate lifecycle, configuration, monitoring, and the internal tooling that support staff use to diagnose one customer's device. It is a distributed systems product in its own right, and its cost scales with units shipped rather than with features.

Certificate and key lifecycle. Devices with a ten-year field life will outlive their initial certificates. Rotation must be designed into the device, the backend and the operational procedure from the start; retrofitting it into deployed hardware ranges from expensive to impossible, and "impossible" here means bricked devices.

Connectivity failure handling. Real devices lose connectivity constantly. Every behaviour — buffering, retry with backoff, local operation, state reconciliation after a week offline — is engineering work, and it is where field bugs concentrate because it is the hardest thing to reproduce in a lab.

Manufacturing integration. Provisioning keys and identity on the production line, factory test firmware, end-of-line validation. Frequently discovered late because it involves a different organisation, sometimes on another continent, whose schedule you do not control.

Long-tail maintenance. Toolchain and dependency updates over a five-to-ten-year term, on an embedded stack where the vendor SDK may itself be discontinued. This is the line item that decides whether year six is affordable, and it is essentially never in the original estimate.

Certification and testing. Radio, EMC, safety, and now cybersecurity conformity work under the CRA, plus the retesting that a significant firmware change may trigger. Budget the retest cycles, not just the initial certification.

The Architectural Decision That Governs Lifetime Cost

One decision dominates every other in a connected product's economics: how much behaviour lives on the device versus in the backend.

Device-side logic is fast, works offline, and is expensive to change — every modification requires a firmware release, a staged rollout and a support term. Backend logic is instantly updatable, observable, and requires connectivity. The instinct of embedded teams is to put logic on the device because that is where the competence sits and because it feels more robust. Over a ten-year product life that instinct is usually wrong.

The heuristic that holds up: on the device, put only what must be there — real-time control loops, safety behaviour, and whatever must function while disconnected. Everything else — business rules, thresholds, feature configuration, analytics, integrations — belongs in the backend, delivered as configuration the device consumes. The difference this makes to lifetime cost is enormous, because a firmware release with a five-year obligation attached is a fundamentally more expensive object than a backend deployment.

The corollary is that the firmware you do ship should be small, boring and stable. A minimal, well-tested device image that does little and does it reliably needs fewer updates over its life, which reduces exactly the obligation the CRA imposes. The most expensive connected products to own are the ones that put an ambitious feature set on the device and then need to change it — that is where the truck rolls, the failed rollouts and the year-six maintenance crisis all come from.

Staffing: The Profile That Barely Exists

Connected products need a capability combination that is genuinely scarce, and the scarcity explains most schedule overruns in the category.

You need embedded engineers who can work close to hardware — memory constraints, power budgets, real-time behaviour, board bring-up. You need cloud and distributed systems engineers who can build the ingestion, fleet management and update infrastructure at scale. And you need someone who understands both well enough to make the on-device-versus-backend decisions above, because those decisions are made at the boundary and getting them wrong is a lifetime cost, not a sprint cost.

Most organisations have one of the three. Hardware companies have embedded depth and treat the cloud side as an afterthought until it becomes the critical path. Software companies build a good backend and underestimate how different embedded constraints are — that a memory leak which is a restart in a web service is a field failure in a device with no watchdog reset path. The programmes that go well have at least one person who has shipped a connected product end to end and can therefore see the failure coming.

The work also has a distinct shape: an intense eighteen-to-thirty-month build followed by a long, much thinner maintenance obligation. That is a poor match for permanent hiring at peak size and a poor match for a project agency that disappears at launch — because launch is precisely when the five-year obligation begins.

At StepTo we have run senior engineering teams out of Serbia since 2014, and IoT and connected product engagements have shifted markedly toward this middle layer: OTA and fleet infrastructure, SBOM and update pipelines built for CRA evidence, and the backend that makes a modest device useful. Engineers are assigned by name and stay with the product, which matters unusually much here — the person who designed your update mechanism is the person you want on the phone during a staged rollout that started failing at 4% of the cohort. For manufacturers who want the maintenance capability to continue past launch without carrying peak headcount, a dedicated development team that scales down into a steady state is the structure that fits the obligation curve. Teams that already have embedded depth and need the cloud and fleet side generally add embedded and platform engineers to an existing group instead.

How to Estimate One Honestly

A procedure for producing a number you can defend, which will be larger than the one you were hoping for.

Start from the support term, not the feature list. Decide the expected field life of the device — genuinely, based on how customers will use it, not on your product roadmap — and take that as the support obligation, with a five-year floor. Every subsequent estimate is multiplied by this number, so it belongs first.

Estimate four buckets separately and resist the urge to fold them together: device firmware, backend and data platform, OTA and fleet management, and manufacturing and certification. In most connected products the first bucket — the part everyone thinks of as "the product" — is between a quarter and a third of the total. If your estimate has firmware above half, you have not estimated the other three.

Then add the annual obligation: security patching, dependency and toolchain updates, certificate rotation, OS or SDK migrations, plus incident capacity for the 24-hour clock. Something in the range of 15-25% of the development cost per year is a defensible planning figure for a product under active support, and it does not decay to zero because the drivers are external.

Finally, price the exit. What happens when you discontinue the product? The CRA obligation does not end because you stopped selling it, so you need an end-of-support plan, a customer notification path, and a decision about the final firmware state. Deciding that at end of life is how manufacturers end up supporting a product for three years longer than they intended, because they have no mechanism to stop.