Zephyr LwM2M Fleet Onboarding: Separate Bootstrap, Registration and Product Acceptance

A device appearing on a bootstrap server is an intermediate commissioning event. A deployable Zephyr product must also reach the intended management server, present the right identity, expose its required resources and recover after a reset. Make those milestones observable before treating the first connection as a completed installation.

This design targets Zephyr 3.7.0 and its LwM2M client. It proposes an application commissioning contract, not a replacement for the protocol state machine or a tested fleet implementation.

Keep bootstrap authority separate from operational identity

Inventory the bootstrap service and the operational LwM2M service separately, even when one organization runs both. For each, record its URI, permitted security mode, credential owner and replacement procedure. A credential accepted by the bootstrap service does not establish that the operational service has a matching device record.

The versioned security documentation describes DTLS with PSK or X.509 credentials. It also requires an endpoint name unique within the LwM2M server. Treat the endpoint name, credential identity and asset inventory key as related but distinct fields. Define the mapping explicitly rather than assuming a printed serial number automatically configures all three.

For a hypothetical environmental sensor fleet, manufacturing should reject duplicate endpoint assignments before shipment. Its report can retain credential identifiers and provisioning status without retaining raw keys. Never bake a shared demonstration secret into every production image.

Translate client events into commissioning milestones

In the 3.7.0 RD client implementation, bootstrap registration, completion of the bootstrap transfer and operational registration generate different events. Preserve that distinction in the application and support interface.

• BOOTSTRAP_REG_COMPLETE: the bootstrap registration stage completed. Do not label the device operational.
• BOOTSTRAP_TRANSFER_COMPLETE: the bootstrap exchange reached its completion transition. The product still needs its persistence and operational-connectivity evidence.
• REGISTRATION_COMPLETE: the operational registration stage completed. The application can now evaluate the remaining commissioning requirements.

Use these events as observations, not as interchangeable “online” flags. A dashboard should retain the latest milestone and the reason progress stopped. Include a non-secret commissioning-attempt identifier so a delayed event from an earlier attempt cannot make a later attempt appear complete.

Define one useful operational acceptance check

Choose a small check that proves the intended server can use the intended device. For the fictional sensor, have the authorized service read the expected device identity and a fresh sample with its validity status. Compare the device identity with the work order and verify that the resource model matches the selected firmware.

This is a proposed product check, not an LwM2M guarantee. Registration alone cannot establish sensor validity, correct customer assignment or successful downstream ingestion. Conversely, an unrelated analytics outage should not erase a valid device enrollment. Keep management connectivity and business-service acceptance as separately reported outcomes.

Specify which conditions permit normal measurement before full commissioning and which require a restricted state. Do not let a generic connection callback silently decide that policy.

Make a reboot test part of credential acceptance

Inspect the actual Security and Server object storage path, including any application persistence callbacks. A protocol completion event does not prove that all required object values reached durable storage together. Do not infer transactional storage from the order of callbacks.

Define how startup selects a complete usable configuration and recognizes an interrupted attempt. If the design uses staged generations, document validation, activation and recovery of that generation. If the selected stack writes active objects directly, qualify that behavior rather than describing an imaginary staging layer.

After a successful onboarding trial, reboot the isolated test unit and establish the operational connection again. Confirm the same intended endpoint and server association without silently reprovisioning missing values from the developer’s workstation. Preserve the distinction between a deliberately repeated bootstrap and recovery using already accepted state.

Classify failures before choosing a retry

The pinned RD client contains retry and fallback behavior, including paths back toward bootstrap. Review that behavior with the product’s server policy before adding an application restart loop. Two independent retry owners can create excessive traffic and confusing state transitions.

Fault injected in the lab	Required observation
Bootstrap service unavailable	Bounded retry behavior; device retains its assigned identity.
Bootstrap succeeds, operational credentials rejected	Distinct operational-authentication failure; no downgrade to NoSec.
Reset during configuration transfer	Defined usable state or explicit recovery state after startup.
Duplicate endpoint assignment	Commissioning held for identity correction, not masked by repeated retries.
Operational service temporarily unavailable	Existing ownership retained; authorized recovery remains available.

Set retry limits and any scheduling jitter from the deployed network and server capacity. Do not claim universal values from an unmeasured example. Loss of connectivity alone should not authorize a factory reset or replacement of trust material.

Deliver the commissioning contract with the firmware

Archive the firmware identity, server versions, endpoint mapping, selected security mode, required resource inventory, event trace and reset-test results. Provide a service procedure for devices that cannot recover remotely, with explicit ownership checks and credential-retirement responsibilities.

The official client sample demonstrates bootstrap configuration and combining it with DTLS. Its unsecured and shared-key examples are laboratory material, not production defaults. Pin the complete sample configuration and server implementation used for any experiment.

Version and testing boundary: Zephyr 3.7.0 defaults to LwM2M 1.0.2 and offers an explicit 1.1.1 selection. Match the server and object versions to that choice. Documentation and tagged source were reviewed; no firmware was built, no credentials were provisioned, and no registration, reboot or fleet test was executed. Every acceptance outcome above is a proposed qualification requirement.