Device connectivity¶
What a device connects to¶
A device uses one origin for both supported transports — the origin of its account’s region:
Endpoint |
Purpose |
Device authentication |
|---|---|---|
|
enrollment, certificate rotation, time fallback, and OTA |
factory attestation before enrollment; device certificate afterward |
|
telemetry, client attributes, commands, and shared configuration |
device certificate (mTLS) |
Allow outbound DNS, TCP 443, and TCP 8883 from the device network. Those two ports on your origin are the entire device contract: a device never connects to any other platform host, and never to the public API edge that serves browser and integrator applications.
Region and provisioning origin¶
Each region has its own origin. Provision a device against the origin of the region its account belongs to.
Region |
Origin |
Short name |
Device transport |
|---|---|---|---|
Japan |
|
|
MQTT over TLS on port 8883 |
Korea |
|
|
MQTT over TLS on port 8883 |
The region belongs to the account, not to the device. It is bound when the account is onboarded, and every device in the account uses that account’s origin. There is nothing to choose per device — not at the factory, not at enrollment, and not at first connection.
Both columns above name the same origin, and either may be written wherever an origin is given: the host, or the short name the platform records for the device. A device recorded with one and configured with the other is on the correct origin, not on the wrong one.
A device that connects to the other region’s origin is refused. The refusal names both origins and leaves the device’s recorded origin untouched: a device stays on the origin it was provisioned against until it is re-provisioned explicitly. A wrong-region connection is never corrected silently, and a device configured for another region’s origin is refused before it connects at all — nothing is dialled, and no credential leaves the device.
Important
A wrong-region refusal is terminal. The broker answers the device’s credentials with a not-authorized response and the SDK stops retrying rather than backing off forever, because the same credentials cannot become acceptable to the other region by repetition. Confirm the account’s region and re-provision the device deliberately. A device pointed at the wrong region’s origin is caught before that: the SDK refuses the connection locally, so nothing is sent to the other region’s broker.
A device first provisioned before the origin was recorded simply records it the first time it is saved. That is not a mismatch and needs no action.
Important
Both ports present a server certificate issued by the device certificate authority — the same chain your device certificate belongs to — not a public web certificate authority. A device must trust that chain explicitly. A generic HTTPS client using only the operating system’s public trust store will fail to verify your origin; that is the design, not a fault.
First connection¶
The device identifies itself over HTTPS with its factory bootstrap credential.
It creates its private key locally and sends a certificate signing request.
DDI returns the device certificate, CA chain, and operational connection settings.
The device stores the key and certificate in protected storage and discards the bootstrap credential.
The device reconnects with its certificate for MQTT and later HTTPS calls.
The private key must not leave the device. If a product cannot generate or protect a key locally, stop the integration and review the hardware security design before production.
OTA updates¶
The device polls https://<your origin>/ddi/v1/ota/ with its device
certificate. DDI identifies the device from that certificate and relays the
request to the platform’s private HawkBit service. Firmware must not configure
a HawkBit hostname, tenant, controller ID, or gateway token.
Bazaar Dev2M is the management side: authorized software publishers define artifacts, rollout triggers, and assignment rules there. OTAForge is the human view of rollout state. Neither browser application is part of the device route.
Certificate lifecycle¶
Rotate a certificate before it expires by using the DDI SDK.
A deactivated or annihilated device is denied at the device edge.
Do not retry a terminal blacklist response. Escalate it to the fleet owner.
Treat a stale or unavailable revocation decision as a connection failure; the platform fails closed.