How to Build Connected Hardware as One Product System

Why Connected Hardware Is Harder Than Adding an App

Connected hardware is difficult because the product is no longer only a device. It becomes one operating system across mechanics, electronics, firmware, networking, identity, mobile software, cloud services, manufacturing, updates, and support.

Existing components do not remove the integration work. They move the work to interfaces, failure behavior, test coverage, suppliers, and long-term ownership.

The practical rule is simple: every interface and every failure needs a named owner.

A diagram can hide the hard parts

A typical architecture drawing shows a device, cloud, and app connected by arrows. The arrows are where much of the product risk lives.

What happens when the device sends the same event twice? Which clock controls the activity record? What if the app revokes a user while the device is offline? What state wins when the safe reconnects? Can a factory test account survive into a customer's unit? What does the device do when an update changes the data format but the app has not updated yet?

flowchart TD
    A["Mechanical system"] <--> B["Electronics and power"]
    B <--> C["Firmware and device OS"]
    C <--> D["Network and device identity"]
    D <--> E["Cloud and notification services"]
    E <--> F["Mobile app and user account"]
    G["Factory provisioning and tests"] --> B
    G --> C
    G --> D
    H["Updates, support, and end-of-life"] --> C
    H --> E
    H --> F

Each connection needs a protocol, state model, error behavior, test method, security boundary, version policy, and support owner.

Product architecture comes before factory execution

In episode 105, Oscar Hedaya describes approaching safe manufacturers with a product that combined a steel enclosure, lock, screen, cameras, sensors, custom electronics, firmware, and software. The factories were accustomed to clearer, narrower instructions.

That account illustrates a common mistake. A contract manufacturer can be excellent at sourcing, fabrication, assembly, test execution, yield improvement, and production control. It cannot resolve an undefined product architecture on behalf of the founder.

The product company must define what the device does, which subsystem owns each state, how components communicate, how units are provisioned, what passes factory test, and how failures reach engineering.

The manufacturer needs a controlled build package. Engineering needs feedback from the actual process. Neither side can throw the problem over the wall.

Mechanical and electronic design constrain each other

Mechanics determine more than appearance. Material thickness, door travel, hinge geometry, lock placement, cable routing, antenna position, camera view, heat, sealing, service access, and anchoring all affect the connected system.

Electronics add their own constraints. Power draw changes battery and thermal requirements. A touchscreen changes the door and glass. Wireless radios need an antenna environment that steel can disrupt. Cameras need views that survive real placement. Sensors need thresholds that distinguish ordinary use from meaningful events.

A late mechanical change can move a sensor and invalidate detection behavior. A substitute display can require different firmware and tooling. A battery change can affect charging, shipping, enclosure space, and safety testing.

The bill of materials is therefore not a shopping list. It is a network of verified dependencies.

Firmware turns components into behavior

Hedaya describes the printed circuit board assembly as the brain connecting the product's components. Firmware gives that hardware a state model.

The device needs to know whether the door is open, whether the lock reached its position, which credential was presented, whether a camera event should be stored, whether power has failed, and whether an update can begin.

Those states need safe transitions. A motor command should not rely only on elapsed time if position can be confirmed. A low battery should change behavior in a defined way. A failed sensor should be visible instead of silently converted into a normal reading.

The software team also needs versioned interfaces. The mobile app cannot assume every device has the latest firmware. The backend cannot discard an event merely because an older device names it differently.

The product includes the account and cloud

NIST IR 8425 treats a consumer IoT product as the device plus any companion applications and backend services that are needed for its functions.

That whole-product view changes ownership. A safe can have strong local access control and still expose camera data through a weak account-recovery process. A device can encrypt network traffic and still keep a former user's authorization active. A mobile app can look polished while the notification service drops critical events without visible status.

The system needs device identity, user identity, authorization, key management, data protection, logging, recovery, revocation, and a clear source of truth.

Security requirements belong in the product specification, not in a late penetration test.

Prototype success is not production readiness

A prototype proves that a path can work. Production needs the path to work across units, suppliers, environments, user behavior, versions, failures, and time.

Production readiness includes controlled firmware, signed releases, component traceability, calibration, unique device credentials, factory-test limits, serial records, rework control, packaging, installation, support diagnostics, and a path from field failure back to the exact build.

SPACE's March 2025 update describes manufacturing-partner problems, financial losses, and the need for production support after years of development. Its January 2026 update says the company was still testing printed circuit board assemblies while also developing its own OTA system.

Those public notes make a useful point. A working feature and a repeatable product are different milestones.

Build the security program with the product

The April 2026 revision of NIST IR 8259 recommends foundational cybersecurity activities for IoT manufacturers before products are sold. NIST IR 8259A covers technical capabilities such as device identification, configuration, data protection, logical access, software update, and cybersecurity-state awareness.

NIST IR 8259B adds the work around the device: documentation, receiving questions and vulnerability reports, and distributing security and support information.

This combination is important. A secure-update mechanism without a vulnerability-intake process can sit idle while researchers have nowhere to report a flaw. An access-control feature without user documentation can be configured in a dangerous way. A product without an end-of-support notice can look healthy while its software ages.

Design recovery before the failure

Connected hardware will fail in ways that are physical, digital, and organizational.

The device can lose power, connectivity, storage, time, or a sensor. The app can become incompatible. A cloud provider can fail. A certificate can expire. An update can be interrupted. A supplier can disappear. The vendor itself can stop operating the service.

Recovery needs several levels. Local access should be understood. Device state should survive expected interruptions. Failed updates need a safe path. Support needs enough diagnostic data to distinguish user error, component failure, software failure, and service outage. Final end-of-life behavior should preserve the safest useful local operation the architecture allows.

NIST SP 800-193 frames firmware resilience through protection, detection, and recovery. The same mindset is useful across the product.

A practical interface review

Create a table with one row for every subsystem boundary. Record the producer, consumer, data or signal, timing, source of truth, authentication, failure state, retry rule, test, version owner, factory check, support signal, and end-of-life behavior.

Then review every row with the disciplines on both sides. Mechanical engineering and firmware should agree on door state. Firmware and cloud should agree on event identity. Cloud and app should agree on authorization and stale data. Manufacturing and security should agree on device credentials. Product and support should agree on what a customer sees when any part fails.

NIST SP 800-218 provides a common framework for secure software development. It does not replace category-specific safety and physical engineering, but it can keep the software lifecycle from becoming an informal side project.

The test for a connected hardware company is not whether all the parts exist. It is whether the company can explain how the whole system behaves, how each unit was built, how faults are found, how updates are trusted, and what remains when support ends.

AI assisted with research organization and drafting. Dalton Anderson remains responsible for the guide, source boundaries, and publication decision.