Zero-touch provisioning
Zero-touch provisioning is for the case where the person installing the hardware is not the person who administers it — and may know nothing about SPEKTRA Edge at all. A box arrives at a shop, a warehouse, or a customer site. Someone plugs it in. It joins your fleet, correctly configured, and appears in your dashboard.
The point is not to save the few minutes of configuring a device. It is that configuring devices at all does not scale to hundreds of sites, and every manual step at the far end of a supply chain is a step that will sometimes be done wrong.
Zero-touch provisioning and the hardware-rooted identity behind it are
capabilities of SPEKTRA Edge OS. A device running the droplet agent installed
from a .deb package onboards with a service account key instead. See
Install the droplet agent.
How it works
Three things have to line up: the device must know where to connect, it must prove it is entitled to join, and the platform must know what to turn it into.
flowchart TB
POLICY["<b>Provisioning policy</b><br/>what the device becomes"]
HW["<b>Hardware record</b><br/>which devices are expected"]
IMAGE["<b>Install image</b><br/>where to connect, and credentials"]
DEVICE["Device powered on at site"]
JOIN["Device joins the fleet<br/><i>named, configured, labelled</i>"]
POLICY --> JOIN
HW --> JOIN
IMAGE --> DEVICE
DEVICE --> JOIN
The provisioning policy does the configuring. What zero-touch adds is the other two pieces: getting credentials onto hardware without an administrator present, and telling the platform in advance which hardware to expect.
Choosing an approach
| Approach | Who touches the device | Suits |
|---|---|---|
| Pre-registered hardware | Nobody — you register serial numbers in advance | You know the serial numbers before the hardware ships |
| Registration session | A non-technical person scans a QR code | Hardware arriving at a site where you do not know the serials |
| Self-registration | Nobody | Devices imaged by you, trusted to join on first boot |
These are not exclusive. A common shape is to pre-register the hardware you know about and run a registration session for the rest.
Pre-registering hardware
If you know what is coming — because you ordered it, or your supplier sent a manifest — create the hardware records before the devices arrive. Each records the identifying details of one physical machine: serial number, manufacturer, product, and where relevant the SIM identifiers for a cellular device.
Two things then become true. The device attaches to the record you already created, arriving with the configuration and labels you set in advance instead of as an anonymous new arrival. And hardware that is not on your list is visible as such, which is the difference between a fleet and a collection of things that connected.
For this to work the policy must specify which hardware fields to match on — see matching known hardware.
Running a registration session
When you do not know the serial numbers in advance, someone at the receiving end has to tell you — and a registration session is how they do it without needing an account, training, or access to your project.
You create a session; the platform emails a link; the recipient opens it on a phone, scans the QR code on each device, and submits. The scanned hardware appears in your project, matched to the policy you chose.
Creating a session
A session specifies:
| Field | Purpose |
|---|---|
| Provisioning policy | What the registered devices will become. |
| Recipient email | Where the link is sent. |
| Start and expiry time | The window in which scanning is allowed. Defaults to one week if you do not set an expiry. |
| Language | The language of the email and the scanning interface. |
| Single use | Whether the link stops working after one submission. |
What the recipient does
The recipient needs a phone with a camera and no knowledge of SPEKTRA Edge. They open the link, see the name of the policy and the time window, scan each device’s QR code, review the list, and submit. They can return to the link to see the status of what they registered.
Devices move through states as they come up — scanned, registered, then provisioning, connecting, and provisioned — so the person on site can see whether the thing they installed actually worked, which is the difference between a clean handover and a phone call.
The recipient’s email address controls where the invitation is delivered. It is not an identity check: the link itself carries the authority to register hardware against the policy, so anyone who obtains it can use it within the session window.
Treat a session link as a secret. Keep the window as short as the job realistically needs, use single-use sessions where one batch is expected, and prefer a narrow role in the policy so that what a registered device can do is limited.
Practical advice
- Keep the window tight. A session open for a week because that is the default is a credential valid for a week. Set it to the day the installation is scheduled.
- One session per site or batch, not one standing session reused all year. It bounds the damage from a leaked link and it tells you which batch a device came from.
- Send it close to the time. A link sitting in an inbox for a fortnight is a link that may be forwarded.
- Check the results yourself. The session records what was registered; compare it against what you expected to receive; do not assume the count matches.
Verifying hardware identity
For higher assurance than a serial number, devices with a TPM can prove their identity cryptographically at provisioning time, so that a device claiming to be a particular machine can be checked rather than believed. See TPM attestation.
This is worth the additional setup where devices are installed by third parties, or where the consequence of an impostor joining the fleet is serious.
Replacing hardware
When a device fails, the replacement should inherit the original’s identity — its name, configuration, labels, and the applications targeted at it — rather than arriving as a new device you have to configure to match.
Hardware replacement does this: the new machine takes over the existing device record, and the deployments and alerting policies that referenced it continue to apply. Because the record persists, its history persists too, which is what lets you notice that one site has replaced three units this year.
The replacement can be registered either by scanning it on site through a session, in the same way as an initial installation, or directly if you have its details.
When devices do not appear
A device that never registers is nearly always one of a small number of causes. In roughly the order worth checking:
- The policy mode. A policy in the unspecified mode accepts nobody and reports nothing. This looks exactly like a network problem.
- The approval queue. If the policy requires manual approval, the devices may be waiting, not failing.
- Connectivity. The device needs outbound access to the platform, possibly through a proxy. See connectivity and ports.
- Session expiry. A registration link outside its window will not work, and the person on site may not be able to tell you why.
- Hardware matching. If the device was expected but arrived as a new record, the policy’s identity fields may not cover the field your supplier populated.
See the troubleshooting playbooks for working through a device that is provisioned but not connecting.
Related
- Provisioning policies — what devices become once admitted.
- Device setup & provisioning — creating the install media itself.
- TPM attestation — cryptographic hardware identity.