Working with an ODM

Options for Hubble customers working with contract manufacturers to produce Bluetooth beacon devices with a Hubble image to properly handle registered device ownership.

---

ODM Context

When you order Bluetooth® devices from an outsourced design manufacturer (ODM) such as an asset tag manufacturer, the ODM builds a generic beacon device running a Hubble firmware image.

What makes that device yours is the device key — a unique device identifier registered to your Hubble organization. Once registered, all device packet data transmitted on the network is sent to your org.

Why Provision at Factory

Device key provisioning at production time is a well-supported pattern. There are two reasons to handle it this way rather than post-production:

• Not all firmware images support post-production key writes. Many Bluetooth images don't expose a bootloader or data transfer state after manufacturing. If a Hubble device key is not burned in during the factory flash, there may be no path to write it afterward.
• It integrates cleanly with existing factory toolchains. ODMs may already handle certificates or other per-device credentials in the factory flashing toolchain. If a Hubble device key is burned in at manufacturing time, nothing needs to be written to the device post-production.

Handling Device Ownership

The cleanest way to handle device ownership is to register the device directly into your organization at the time of provisioning. When working with an ODM, this means the manufacturer uses a device key generated for your org when building the firmware image. This keeps ownership unambiguous from the start.

There are two primary options for ensuring device ownership is correctly handled:

1. Provide the ODM with a Scoped API Token – recommended for ongoing or just-in-time manufacturing. The customer always remains in control of access to their org.
2. Generate and share Pre-Registered Device Keys with the ODM – for when API access is not appropriate or feasible. This works well for fixed production runs, but requires knowing the volume up front.

Using a Scoped API Token

This is the recommended approach for ongoing or just-in-time manufacturing.

The Hubble customer grants the ODM a narrow-scope API token — enough access to register your devices and optionally confirm beaconing functionality by detecting packets, and nothing else.

Customer Steps

1. In your Hubble account, generate an API token using the "Device Manufacturer" preset. This automatically grants these authorization scopes: read-devices, write-devices, and read-packets (optional).
2. Securely share the API token with the ODM (e.g., via your existing secrets management process or an encrypted file transfer).
3. Communicate any production details for registering the device (e.g. encryption mode, device metadata like name, custom tags, etc.).

Customers remain in control of API access. You can revoke this token at any time from your account settings — immediately ending the ODM's ability to register devices to your organization.

Typically, customers use device.name for custom identifiers (e.g. serial number, customer UUID) and/or custom tags (e.g. for production date, SKU, etc.). These identifiers are returned with device packets data.

ODM Steps

1. Before provisioning a device, use the scoped API token to register a new device belonging to the customer’s Hubble organization. This generates a unique device key that is written into the firmware, and ensures that the device belongs to the customer.
2. Provision the device.
3. (Optional) Confirm beaconing behavior by reading packets for that registered device.

The device ships already registered to the customer's org. No backend handoff required. Customers can view new devices in the Hubble Dashboard or via GET /devices API request. Each device has a Hubble UUID and customer-assigned ID as device.name.

Using Hubble CLI, the ODM can verify beaconing behavior just using the encryption key. They don’t need read-packets access.

Sharing Pre-Registered Device Keys

If API access isn't appropriate (for example, during a trial engagement or evaluation period) or not possible (because the facility lacks an internet connection) Hubble customers can generate a pre-registered device list and securely share the encryption keys with the ODM.

Customer Steps

1. In your Hubble account, pre-register the expected number of devices to generate device keys.
2. Export the keys (e.g., as a CSV) and share them securely with the ODM.

ODM Steps

1. Receives the CSV of device keys from the customer.
2. During provisioning, assigns the next available key from the list to each device and writes it to the firmware.

No live Hubble API access is required. Devices ship with keys already registered to the customer's org. Any unused keys may be deleted, or used in a future production run.

---

FAQs

1. Can the ODM use the same token for multiple customers?

No — each token is scoped to a specific customer's organization. If an ODM works with multiple Hubble customers, each customer provides their own token. This keeps registrations isolated by organization.

2. What if I'm on a trial and not ready to give API access?

Use the pre-registered keys flow. Once you're ready to move to production, switch to the API token approach for greater flexibility.

3. What if the ODM registers a device using the wrong token?

The device will be registered to whichever organization the token belongs to. This is why the API token approach is preferable — ownership is established at registration time, in the correct org, with no ambiguity.

4. Can I revoke access mid-production run?

Yes. Revoking the API token immediately prevents any further registrations. Devices already provisioned are unaffected — they retain their keys and remain registered to your org.

5. Must the ODM provision devices into my production environment?

No. You can register devices to Sandbox using environment tags, then promote devices to production when you’re ready.