35 Device Lifecycle Management: Review Stages
35.1 Start With the Decision
A connected product needs evidence from setup through retirement. Record who can deploy, update, repair, and erase it.
35.2 Route Overview
This is part 2 of 2. Review Device Lifecycle Management: LwM2M Workbench for the preceding evidence.
35.3 Learning Objectives
- Trace lifecycle review path across its components and failure boundaries.
- Validate worked review: shared building device with a concrete scenario and pass criteria.
35.4 Chapter Roadmap
- Lifecycle Review Path
- Lifecycle Stages
- Environmental And Durability Evidence
- Provisioning Review
- OTA Update Review
- Lifecycle Readiness Record
- Worked Review: Outdoor Battery Sensor
- Worked Review: Shared Building Device
- Common Findings
- Review Checklist
- Knowledge Check
- Matching Quiz
- Ordering Quiz
- Summary
- Key Takeaway
- Concept Relationships
- What’s Next
35.5 Lifecycle Review Path
Before deciding how Deploy shapes lifecycle review path, inspect Figure 35.1 beside Update. Together, Deploy and Update frame the lifecycle review path claim: connected device lifecycle review path.
Trace Figure 35.1 from Deploy toward Update; that hand-off expresses connected device lifecycle review path. For lifecycle review path, Deploy supplies visible evidence; Update constrains the decision. In Figure 35.1, retain Deploy beside Update so lifecycle review path remains explicit.
Plan: define role, boundary, deployment assumptions, owners, support period, and replacement model. Provision: create device identity, firmware baseline, certificates or keys, configuration limits, and traceability. Deploy: install the device in the intended context, confirm connectivity, verify physical fit, and record site assumptions. Operate: monitor health, freshness, battery or power state, local logs, failure modes, and user-visible status. Update: deliver firmware or configuration changes through signed packages, staged rollout, compatibility checks, and rollback. Maintain: inspect, clean, calibrate, reset, repair, replace parts, recover credentials, and handle field support. Transfer: support ownership changes, account unlinking, reset, re-provisioning, and data-boundary review. Retire: revoke credentials, wipe local data, remove cloud records, recycle or dispose, and close the asset record.
The review is incomplete if any stage depends on informal knowledge that is not recorded.
35.6 Lifecycle Stages
Before deciding how wake shapes lifecycle stages, inspect Figure 35.2 beside update. Together, wake and update frame the lifecycle stages claim: iot device lifecycle state model.
Trace Figure 35.2 from wake toward update; that hand-off expresses iot device lifecycle state model. For lifecycle stages, wake supplies visible evidence; update constrains the decision. In Figure 35.2, retain wake beside update so lifecycle stages remains explicit.
35.6.1 Planning And Readiness
Planning creates the lifecycle contract for the device.
Review:
device role, boundary, users, maintainers, and affected systems. expected support period and minimum update path. deployment assumptions such as weather, mounting, access, signal path, and power source. installation and recovery responsibilities. required logs, health signals, and fault indicators. replacement, transfer, and retirement expectations. acceptance gate before pilot, limited release, or production release.
The strongest planning output is not a long document. It is a record that lets another reviewer understand what the device is expected to survive and who owns each lifecycle decision.
35.6.2 Manufacturing And Provisioning
Provisioning prepares a physical unit to become a trusted system participant.
Review:
unique device identity and asset identifier. firmware baseline, hardware revision, and configuration version. credentials, certificates, keys, or enrollment tokens. secure storage and reset behavior for secrets. factory test result or intake test result. claim that the device can be traced after shipment or installation. recovery path when provisioning fails.
Avoid treating provisioning as only “connect to Wi-Fi.” Network setup is one part of provisioning. Identity, ownership, firmware baseline, cloud or gateway enrollment, and reset behavior are also part of the lifecycle record.
Before deciding how Phase 2 shapes manufacturing and provisioning, inspect Figure 35.3 beside Activate. Together, Phase 2 and Activate frame the manufacturing and provisioning claim: device provisioning flow from manufacturing through user setup to cloud registration and activation.
Trace Figure 35.3 from Phase 2 toward Activate; that hand-off expresses device provisioning flow from manufacturing through user setup to cloud registration and activation. For manufacturing and provisioning, Phase 2 supplies visible evidence; Activate constrains the decision. In Figure 35.3, retain Phase 2 beside Activate so manufacturing and provisioning remains explicit.
35.6.3 Deployment And Commissioning
Commissioning checks whether the device works in its real context.
Review:
installed location, orientation, enclosure condition, and mounting method. radio or wired path after installation, not only on the bench. sensor or actuator behavior in the installed position. power source, charging, battery, or service access. local indicators, setup feedback, and installer instructions. first health report and first successful data path. record of deviations from the planned deployment assumptions.
A device that passes bench testing can still fail after it is placed near metal, water, concrete, heat sources, moving machinery, human bodies, or sealed cabinets. Commissioning evidence belongs in the installed context.
35.6.4 Operation And Monitoring
Operation evidence shows whether the device can be trusted after deployment.
Review:
heartbeat, last-seen time, clock source, and stale-data rule. battery, power, thermal, enclosure, or sensor health signals. local buffering and retry behavior during network loss. visible status for users, installers, or operators. recoverable error states and safe states. log retention, privacy boundary, and diagnostic access. support escalation path when the device is silent or inconsistent.
Monitoring should distinguish healthy silence from a failure. A low-rate sensor may report rarely by design, but the system still needs a way to tell whether the device is asleep, offline, misconfigured, blocked, or retired.
35.6.5 Updates And Change Control
OTA and configuration updates change a deployed device. They need their own lifecycle gate.
Review:
- signed update package or authenticated configuration change
- compatibility check for hardware revision, bootloader, memory, and dependencies
- available power, storage, network, and maintenance window
- staged rollout plan with stop conditions
- rollback path and boot-success confirmation
- user or operator notice for disruptive changes
- post-update health check and record of changed behavior
Safe update design separates “can download a file” from “can survive a failed change.” A robust lifecycle record explains how the device avoids becoming unrecoverable when power fails, the network drops, a package is corrupt, or the new firmware cannot boot successfully.
35.6.6 Maintenance And Service
Maintenance covers the recurring work needed to keep the device useful.
Review:
inspection, cleaning, calibration, consumable replacement, and battery or power checks. tool, access, permission, and training requirements. spare unit or replacement part availability. service interval and service-start conditions. reset and recovery behavior. impact of service on data continuity and user trust. evidence that maintenance is practical in the deployment context.
Do not accept “maintenance-free” as a design claim unless the record shows what changes would prove otherwise. A sealed device can still need cleaning, reset, update, replacement, or retirement.
35.6.7 Transfer And Reuse
Connected devices often change owners, accounts, sites, gateways, or tenants.
Review:
unlinking from the previous account or tenant. local data wipe and credential rotation. reset mode that does not expose previous user data. re-provisioning workflow for the new owner or site. transfer history for replacement, returned units, and owner or tenant changes. data-retention boundary between device, gateway, app, and cloud service.
Ownership transfer is a lifecycle stage, not an edge case. Devices that cannot be safely transferred can create privacy, support, and security risks.
35.6.8 Decommissioning
Decommissioning removes a device from service without leaving active trust relationships behind.
Review:
credential revocation and certificate or key retirement. local data wipe or documented data destruction. cloud, gateway, dashboard, and inventory removal. disposal, recycling, return, or refurbishment path. final status recorded in the asset system. support behavior if the retired device tries to reconnect.
The decommissioning record should make it clear that the device no longer has authority in the system.
Before deciding how replace shapes decommissioning, inspect Figure 35.4 beside Authenticate. Together, replace and Authenticate frame the decommissioning claim: device identity lifecycle from definition and enrollment through credential issue, authentication, renewal, suspension, recovery, and retirement.
Trace Figure 35.4 from replace toward Authenticate; that hand-off expresses device identity lifecycle from definition and enrollment through credential issue, authentication, renewal, suspension, recovery, and retirement. For decommissioning, replace supplies visible evidence; Authenticate constrains the decision. In Figure 35.4, retain replace beside Authenticate so decommissioning remains explicit.
35.7 Environmental And Durability Evidence
Environmental testing should match the intended deployment. The review should not list every possible standard or test. It should explain which conditions matter for this device and what evidence supports the claim.
Common evidence areas:
Temperature: expected operating range, storage range, self-heating, thermal cycling, and battery effect. Moisture and dust: ingress path, seal, venting, condensation, cleaning, and enclosure rating evidence. Mechanical stress: vibration, shock, mounting load, connector strain, wear, and service handling. Chemical and UV exposure: cleaning agents, sunlight, oils, corrosion, and material compatibility. Electromagnetic environment: radio coexistence, emissions, susceptibility, grounding, shielding, and cable routing. Human contact: skin contact, heat, edges, fasteners, cleaning, comfort, and accessibility for users or technicians.
The lifecycle question is simple: will the evidence still be credible after the device has been installed, updated, cleaned, serviced, and exposed to its expected environment?
35.8 Provisioning Review
Provisioning should create a device that is unique, traceable, recoverable, and associated with the correct system owner.
Strong provisioning records usually include:
- unit identifier and hardware or assembly revision
- firmware, bootloader, and configuration baseline
- credential source and storage boundary
- network or gateway enrollment method
- owner, tenant, site, or account association
- reset and re-provisioning behavior
- failure path when setup cannot finish
Provisioning methods such as QR code association, cable-based setup, SoftAP, BLE-assisted setup, gateway-assisted join, or factory enrollment can all be valid. The review should focus on fit: what the method assumes, what can fail, how the user or installer recovers, and how credentials remain protected.
35.9 OTA Update Review
OTA update readiness is an evidence gate, not just a feature.
Review before accepting OTA readiness:
update package integrity and authenticity checks. hardware, firmware, bootloader, and configuration compatibility checks. enough storage for the package, metadata, and rollback state. enough energy or external power for download, write, verification, and reboot. staged rollout plan with health gates and halt conditions. automatic rollback or recovery path. post-update confirmation and monitoring. explicit rule for devices that are offline, low power, or in critical operation.
The update record should answer: what happens if the update is interrupted, rejected, delayed, partially applied, or causes repeated boot failure?
Before deciding how Passed? shapes ota update review, inspect Figure 35.5 beside Update. Together, Passed? and Update frame the ota update review claim: firmware update flow with availability check, battery gate, download, integrity validation, installation, boot verification, rollback, and deferral outcomes.
Trace Figure 35.5 from Passed? toward Update; that hand-off expresses firmware update flow with availability check, battery gate, download, integrity validation, installation, boot verification, rollback, and deferral outcomes. For ota update review, Passed? supplies visible evidence; Update constrains the decision. In Figure 35.5, retain Passed? beside Update so ota update review remains explicit.
35.10 Lifecycle Readiness Record
Before deciding how what remains shapes lifecycle readiness record, inspect Figure 35.6 beside who signs. Together, what remains and who signs frame the lifecycle readiness record claim: connected device lifecycle readiness record.
Trace Figure 35.6 from what remains toward who signs; that hand-off expresses connected device lifecycle readiness record. For lifecycle readiness record, what remains supplies visible evidence; who signs constrains the decision. In Figure 35.6, retain what remains beside who signs so lifecycle readiness record remains explicit.
Identity and baseline: device ID, hardware revision, firmware baseline, configuration version, and credential boundary. Deployment context: intended environment, mounting, network path, power source, users, and maintainers. Health signals: heartbeat, last-seen rule, battery or power state, local logs, error states, and safe-state behavior. Update gate: package verification, compatibility, energy, storage, staged rollout, rollback, and post-update checks. Maintenance path: inspection, cleaning, calibration, reset, repair, replacement, and service access. Transfer path: unlink, wipe, re-provision, owner change, returned unit, and data boundary. Decommissioning path: revoke, wipe, remove from inventory, recycle, refurbish, or dispose. Decision and change condition: accepted tradeoff, owner, known limit, open issue, and condition requiring another review.
The record should be short enough to maintain and specific enough to audit.
35.11 Worked Review: Outdoor Battery Sensor
A battery-powered outdoor sensor reports site conditions through a local gateway.
Lifecycle evidence to request
Unit identity and firmware baseline are recorded before installation. The installation record includes mounting, enclosure orientation, signal path, and service access. Commissioning confirms sensor behavior and gateway connectivity after installation. Heartbeat and stale-data rules distinguish sleep from failure. Battery level is checked before any update attempt. OTA update path includes compatibility, staged rollout, verification, and rollback. Maintenance includes cleaning, battery replacement, seal inspection, and reset. Decommissioning revokes credentials and removes the unit from gateway and cloud inventory.
Likely review action
Hold the lifecycle decision if the record proves only first-day connectivity. A field sensor also needs evidence for update, maintenance, failure recovery, transfer, and retirement.
Change condition
Rerun the review when the enclosure, mounting, antenna path, battery, gateway, firmware, update policy, reporting interval, maintenance access, or deployment environment changes.
35.13 Common Findings
The lifecycle record stops at installation and ignores operation, update, transfer, or retirement. Provisioning is treated as Wi-Fi setup only, with no identity or ownership evidence. The device has no clear way to distinguish sleeping, offline, failed, reset, and retired states. OTA readiness is claimed without power, storage, compatibility, staging, rollback, or post-update evidence. Maintenance depends on physical access, tools, accounts, or permissions that are not recorded. Ownership transfer does not wipe local data or rotate credentials. Decommissioned devices can still reconnect or appear active in dashboards. Environmental evidence was collected on the bench instead of in representative deployment conditions. The record lacks an owner, known limit, open issue, or change condition.
35.14 Review Checklist
Before accepting a connected-device lifecycle decision, confirm that the record includes:
device identity, hardware revision, firmware baseline, and configuration version. deployment assumptions, commissioning checks, and installed-context evidence. provisioning, ownership, credential, reset, and recovery paths. health signals, stale-data rules, local logs, and safe-state behavior. update verification, compatibility, power, storage, rollout, rollback, and post-update checks. maintenance tasks, service access, replacement path, and support escalation. transfer, returned-unit, re-provisioning, and data-boundary handling. decommissioning steps for revocation, wiping, inventory removal, and disposal or reuse. accepted tradeoff, owner, known limit, open issue, and change condition.
35.15 Knowledge Check
35.16 Matching Quiz
35.17 Ordering Quiz
35.18 Summary
Device lifecycle management is the practice of keeping connected devices trustworthy after they leave the bench. The review follows the device through planning, provisioning, deployment, operation, update, maintenance, transfer, and retirement.
The strongest lifecycle records are bounded, testable, and revisable. They show identity, deployment assumptions, health signals, update gates, maintenance paths, ownership-transfer behavior, decommissioning steps, decision owners, known limits, and change conditions.
35.19 Key Takeaway
Device lifecycle design must plan onboarding, operation, maintenance, updates, retirement, ownership transfer, and support evidence before deployment.
35.20 Concept Relationships
Connected Device Fundamentals defines the device role and boundary that lifecycle records preserve over time. Device Form Factors supplies the physical evidence for deployment, service, durability, and environmental exposure. Power Management expands the power-state evidence needed for operation, update deferral, and maintenance. Security and Privacy Overview connects provisioning, credentials, reset, and decommissioning to trust boundaries.
35.21 What’s Next
Continue to Power Management to review battery, power-state, and update-energy evidence in more detail.
35.22 Continue Your Route
This final part closes the route from Lifecycle Review Path through What’s Next. Return to Device Lifecycle Management: LwM2M Workbench or continue from the ux-design module index.