A production-ready connected product is not simply a prototype placed in an enclosure. It is a device that can be uniquely identified, recovered after a failed update, understood when it is remote, and retired without leaving valid credentials behind. Use this checklist as a shipment gate. A failed item should produce an owner and a decision: fix it, reduce the first deployment scope, or explicitly accept the consequence.
How to use this checklist
Review one representative unit from the intended production process, not the most carefully prepared engineering sample. Record evidence for every pass criterion: a test log, factory record, recovery exercise or support procedure. The companion article on what makes an IoT device production ready explains the broader reasoning; this list turns that reasoning into release gates.
Pass criterion: every item below has current evidence, a named owner and no unresolved failure that can strand a device, expose the fleet or make support depend on a lab connection. An exception is not a pass. It is a documented release decision.
Identity and provisioning
Each device needs a stable unique identity that the service can map to its hardware record and customer assignment. Provision credentials per device rather than copying one shared secret across the run. A shared credential converts one extraction or manufacturing leak into a fleet-wide event and makes selective revocation difficult.
The factory flow should create or inject identity material, associate it with the unit record, verify that the device can authenticate, and prevent the same identity from being issued twice. Decide how failed provisioning is quarantined and retried. Logs should identify the station and result without exposing secret material.
Pass criterion: two sampled production units present different credentials, both map to the correct unit records, duplicate provisioning is rejected, and a failed unit can be quarantined without revealing or reusing a secret.
Updates and recovery
The field-update path must verify signed artifacts before installation. A version should be rejected if its signature, target hardware or required configuration does not match. The update mechanism also needs a known response to loss of power or connectivity at every stage.
Test rollback with a deliberately bad application that fails its health check. Confirm that the device returns to a previously accepted image without physical access. Also test the recovery path for a unit that cannot complete the normal update flow. The practical details in ESP32 OTA updates in production and marking an application valid or cancelling rollback illustrate why an update is incomplete until the new image proves it can run.
Pass criterion: unsigned or mismatched artifacts are rejected, interruption does not leave an unbootable unit, and a tested failed-health scenario rolls back to a working image through the documented field path.
Connectivity and offline behaviour
A connected product must define what happens when the network is slow, intermittent or absent for longer than expected. Reconnection needs backoff so a fleet outage does not create a synchronized retry storm. The device should distinguish temporary transport failure from invalid credentials or rejected data rather than retrying all errors forever.
Buffering must be bounded. Set limits in bytes, records or elapsed time according to available storage and the value of the data. Define what happens at the boundary: drop oldest records, aggregate, stop accepting a class of events, or enter a safe degraded mode. Recovery should drain data at a controlled rate and preserve ordering only where the application truly requires it.
Pass criterion: an outage test reaches the configured buffer limit without storage exhaustion or reboot loops; the documented overflow policy occurs; and reconnection drains or discards queued data predictably without overwhelming the service.
Observability
Remote support needs more than a heartbeat. Collect firmware version, configuration revision, reset reason, update status, connectivity failures and a small set of health measurements tied to known failure modes. Logs need stable event names and enough context to distinguish a device fault from a network or service fault, but they should not contain credentials or unnecessary personal data.
Provide remote diagnostics that work without shell access or a technician at the enclosure. A support operator should be able to request a bounded diagnostic snapshot, see when it was collected, and tell if it is incomplete. Diagnostic collection itself must not exhaust bandwidth, storage or power.
Pass criterion: from the normal support interface, an authorized operator can identify the unit, firmware and configuration, see its latest reset and update state, and obtain a bounded diagnostic snapshot without physical access or secret leakage.
Power, hardware and environment
Exercise brown-outs, abrupt removal of power and repeated restarts around storage writes and updates. Confirm that persistent state remains valid or can be rebuilt. Test the assembled enclosure across the temperature and power conditions claimed for deployment, because a board that is stable on a bench may behave differently with restricted airflow, a different supply or radio activity inside a case.
Review connectors, strain relief, ingress exposure and any field-replaceable part. Replacement should not create an ambiguous identity or bypass provisioning. Moving from a development board to a product means treating the enclosure, supply and service procedure as part of the system.
Pass criterion: representative enclosed units complete power-interruption and environmental tests within the product's declared operating limits, retain recoverable state, and have a documented replacement procedure for every part expected to be serviced.
Operations and end of life
Name who owns fleet health, update approval, incident response, customer support escalation and vulnerability handling. Support needs a way to link field symptoms to a unit record and preserve returned hardware for analysis. Define which service remains available when a product leaves normal support and how customers are notified of material changes.
Decommissioning is an operation, not a database cleanup. Revoke the device credential, remove or archive its authorization, stop scheduled work, and define what local data must be erased. A returned or resold device should not authenticate as its former owner. Keep the minimum audit record needed to explain when and why access ended.
Pass criterion: a test unit can be decommissioned through the normal operational procedure; its credential is rejected afterward, it no longer receives fleet actions, ownership data is handled according to policy, and the event is visible in the audit record.
Repeat the review whenever the production process changes. A new factory station, a substituted component, a different firmware branch or a new hosting region can invalidate evidence collected earlier, even if the checklist items themselves stay the same. Store the completed checklist with the release record so the next shipment starts from documented evidence rather than from memory.
A first field deployment should proceed only when each pass is supported by evidence. The point is not administrative completeness. It is to make failures observable, bounded and recoverable before physical distance turns them into expensive surprises.