Every Device in Xyte is associated with a Device Model that defines its capabilities, Commands, Configuration, and the Digital Products it supports.
At registration, each Device presents a Hardware Key that the platform uses to match the Device to its Device Model. For better security and tracking, create a separate Hardware Key per production batch (see below).
A Hardware Key is a provisioning credential, not a Device identity. It is sent exactly once — on the Register Device API call to a Provisioning Server — and that call returns the Device's own id and access_key, which authenticate every call afterwards. The Device never needs the Hardware Key again, and Devices that have already registered are unaffected by anything that happens to the key later.
Managing hardware keys
Hardware Keys are managed in the Partner Portal on the Hardware Keys tab of the Device Model details page (Partner Portal → Product → Models → select model → Hardware Keys).
From this tab you can create Hardware Keys and see how many Devices registered with each one. Set Max devices number to the number of Devices you expect a key to serve, then reconcile it against the Registered devices column — a count higher than the number of units you built is the earliest sign that a key is being used somewhere it should not be.
Retiring a keyKeys can be added at any time, but they cannot currently be edited or removed from the Partner Portal. To have a key disabled — because its batch is complete, or because you suspect it leaked — contact [email protected]. Devices that already registered with that key keep working normally.
Key safety
A Hardware Key must be kept secret. A leaked key lets attackers spoof Devices on the manufacturer's account, which corrupts reported state and could be abused for spam or DDoS attacks.
To contain that risk, generate a separate Hardware Key per production batch — or per firmware image, or per rollout wave — and distribute keys only to personnel directly involved in manufacturing. Never use one key across a whole product line, and treat any firmware image that carries a key as public: anyone who can download that image can extract the key.
Getting the key onto a Device
Three patterns, strongest first.
Register at the factory. The provisioning station calls the Register Device API over the factory network and writes only the returned id and access_key to the unit. The Hardware Key never leaves your factory, and units ship already registered.
Register through your own service. The Device authenticates to a service you run, using an identity it already has — a per-unit secret, a client certificate, an activation code — and that service registers the Device with Xyte on its behalf, handing back only the Device's own credentials. The key stays server-side, so extracting a firmware image reveals nothing and you can switch keys without a firmware release. This is usually the practical option for Devices already in the field.
Embed the key in firmware. The simplest option and the most exposed. If you do this, use a dedicated key for that image or rollout wave, and have the Device erase the key from storage immediately after a successful registration.
Storing credentials on a Device
Prefer storing only the id and access_key returned by registration. They are unique per Device, so a compromise affects one unit rather than a batch. If a Hardware Key has to live on the Device, keep it single-use and erase it after registration, and use a secure element or trusted execution environment where the hardware offers one.
Neither the Hardware Key nor the access_key should be readable through any Device surface — no read-back over the control interface, no configuration export, no diagnostic dump, no log line, and no copy inside a configuration backup.
If a key leaks
- Add a new Hardware Key on the Device Model and switch your provisioning to it, so manufacturing is never blocked.
- Contact [email protected] to have the compromised key disabled.
- Deliver the new key only where it is needed. Devices that already registered require no action — do not push a new key to them, as that only exposes it again.
- Reconcile. Compare the compromised key's Registered devices count with the number of units you actually built, and send us anything unexpected so we can review and remove spoofed Devices.