If you run a large fleet of edge devices, provisioning IoT devices at scale is not just an imaging problem. It is an operational one.
Raspberry Pis, industrial edge boxes, cellular routers, and similar field devices are often shipped to provide remote access to equipment at sites. Getting the device online is rarely the hard part. The hard part is provisioning the tunnelling software, identity, naming, and remote-access configuration on each unit without turning every deployment into a custom setup exercise.
This is where many provisioning systems begin to break down. They rely on device-specific configuration files, certificates, or secrets being copied onto each device individually. You can script that process, but you are still carrying a per-device manufacturing workflow that becomes slower, more brittle, and harder to reason about as the fleet grows.
For fleet provisioning, the golden image matters more than going through a checklist.
The image should include the base OS, the site connector, and only the minimum local config needed to complete first boot. It should be consistent enough to flash onto many devices without per-unit changes.
If every device needs its own image, the provisioning problem has simply been moved upstream into manufacturing. That slows release work, increases the number of artifacts you need to track, and makes it harder to understand what actually shipped.
The goal is not to deliver a fully customised device. The goal is to deliver a device that can customize itself safely and predictably once it comes online.
Most teams overcomplicate the factory stage. They generate a new secret package for every device, copy device-specific certificates into the image, or build custom configuration bundles for each site. That can work, but it creates a brittle manufacturing workflow.
Large fleets usually need something lighter. The image should contain only the bootstrap material needed for the device to connect back and enrol. In many cases, that means using the same provisioning key, or a batch-level bootstrap credential, across a manufacturing run instead of creating a unique setup package for every unit.
The point of bootstrap material is not to define the device's final state. Its purpose is only to get the device online and into the provisioning system.
Once the device comes online, it should complete the rest of provisioning itself. That means identifying itself, receiving the correct name or assignment, and pulling the configuration it actually needs for that site. The device leaves the bench generic. First boot is what moves it into its operational role.
That is what zero-touch provisioning should mean at scale. A technician should not need to log in manually and finish the setup just because the device has reached the field. For remote-access devices, first boot should handle registration, configuration retrieval, and local role assignment automatically.
Provisioning is not finished once the device is deployed.
If flashing the original image is the only clean part of the process, the fleet is still hard to manage. You also need a reliable way to deliver software updates and configuration changes to devices that are already in the field.
That does not mean re-imaging hardware for every change. It means building a scriptable, repeatable rollout path for updates after the first deployment.
A fleet that is easy to install but difficult to update still carries operational debt.
Pangolin is a useful example of how to make remote-access fleet provisioning operationally manageable.
The same problems show up again and again in these deployments: too much device-specific material in the image, too much manual setup after first boot, and no clean path from flashed hardware to a usable remote-access node. That is where Pangolin helps.
You can keep the golden image generic. Instead of generating a unique connector identity for every device during manufacturing, you can ship the image with a shared provisioning key and let the connector exchange it for real site credentials on first boot. That removes a large amount of per-device secret handling from the factory workflow.
As shown above, the provisioning key can also carry usage policies, including maximum batch size, validity period, and whether new sites are approved automatically.
You can also keep the first boot responsible for the real assignment. Once the device comes online, it can register itself, create or join the correct site, and pull the configuration it actually needs. With Blueprints, that setup can be applied automatically instead of being rebuilt by hand for every deployment.
private-resources:
ssh-resource:
name: SSH Server
mode: host
destination: localhost
site: {{env.SERIAL_NUMBER}}-site
tcp-ports: "22,3389"
udp-ports: "*"
disable-icmp: false
roles:
- Customer1
- DevOps
users:
- user@example.com
public-resources:
secure-resource:
name: Web Resource
protocol: http
full-domain: {{env.SERIAL_NUMBER}}.example.com
targets:
- site: {{env.SERIAL_NUMBER}}-site
hostname: localhost
method: http
port: 8080
auth:
sso-enabled: true
sso-roles:
- Member
- Admin
sso-users:
- user@example.comIn the Blueprint example above, the device is configured to grant access to Private Resources listening on the localhost interface. More specifically, the rules allow TCP ports 22 and 3389, and all UDP ports, as indicated by the * character.
In the second half of the Blueprint, a Public Resource is defined. It is configured to register as a subdomain of example.com, using the device serial number as the subdomain value.
That gives you a cleaner end-to-end path: flash one image, ship the device, let it connect back, let Pangolin assign its identity and site configuration, and bring it online without per-device image edits or manual dashboard setup.
That is the real benefit. The image stays simple, first boot handles the site-specific state, and the rollout becomes repeatable across large numbers of devices.
It also produces a better operating model once the box is in the field. Rather than acting as a basic VPN endpoint on an off-the-shelf router, the device becomes part of a platform with centralized users, sites, policy, and audit visibility. It can connect outbound from behind NAT or firewalls, support both browser-based and private access, and fit into a multi-site deployment model without turning every user into a broad network user.
For large edge fleets, provisioning should start with a golden image, not a pile of per-device exceptions.
Keep the bootstrap small. Let the first boot handle the real setup. Use the same repeatable path for updates after deployment.
For remote-access devices, Pangolin provides a concrete approach: ship one repeatable image with provisioning keys, let Newt bring the site online on first boot, and use Blueprints to apply resource state without recreating the same deployment by hand each time.
We also can supply our own Pangolin edge-devices that follow this principle.
What is IoT device provisioning at scale?
It is the process of turning many shipped devices into working fleet members without hand-configuring each one. That usually means a repeatable image, a small bootstrap step, first-boot enrollment, and a controlled update path afterward.
What is a golden image for edge devices?
A golden image is the repeatable base image you flash onto a class of devices before they leave the bench. It should contain the OS, the required software, and the minimum bootstrap material needed for first boot.
What is zero-touch provisioning in IoT?
Zero-touch provisioning means the device can come online and complete its setup path without a technician finishing the install by hand. In practice, that usually means bootstrap material in the image, first-boot enrollment, and config pulled after the device connects.
Why is per-device secret generation a problem?
It creates a slower and more fragile factory workflow. You can automate it, but you are still carrying device-by-device state through manufacturing instead of letting the device enroll and pull its real state later.
What should happen when the device first comes online?
It should connect back, identify itself, register or name itself correctly, and pull the config it needs for that site or role.
How does Pangolin fit into this workflow?
Pangolin can be part of the bootstrap path for remote-access devices. A provisioning key lets Newt come online and establish the site, and blueprints let the device apply repeatable resource configuration on first boot.
