Deploying 50, 200, or 500 industrial IoT gateways shouldn’t require repeated manual configuration at each site. With Zero-Touch Provisioning (ZTP), a pre-enrolled gateway can be taken out of the box, connect to the network, authenticate with the Eziwan cloud, automatically retrieve its configuration, apply its certificates, join its secure tunnel, and report its deployment status. The field technician simply plugs in the equipment; configuration, security, and traceability are managed from a centralized platform.
The Problem with Large-Scale Manual Deployment
In a multi-site industrial IoT project, manual configuration quickly becomes the main bottleneck. As long as only a few gateways are involved, an experienced technician can configure network settings, VPN rules, local IP addresses, and data flows manually. But as soon as the project expands to include dozens or hundreds of sites, this method leads to costs, errors, and variability that is difficult to control.
The challenges are very real.
-
Each gateway often requires the configuration of numerous settings: SIM APN, local IP address, VLAN, DNS, VPN, firewall, NAT rules, certificates, Modbus polling, MQTT endpoint, or business API.
-
Field operations are costly, especially when sites are remote, spread across multiple regions, or accessible only under certain operational constraints.
-
Data entry errors are common: incorrect APN, incorrect network mask, key copied to the wrong location, duplicate subnet, profile applied to the wrong site.
-
Remote diagnostics become difficult when a misconfigured gateway has not yet established its monitoring tunnel.
-
Bulk firmware updates are rarely performed if they require manual action on a site-by-site basis.
-
Configurations vary over time because each technician makes slight adjustments to the settings during installation.
-
Replacing faulty equipment requires a new on-site configuration if the configuration is not centralized.
-
Technical secrets, such as VPN certificates, API tokens, or passwords, can be managed manually using a variety of methods.
-
It is difficult to track the actual progress of the deployment without a centralized dashboard: pending sites, active sites, errors, installed versions, and applied profiles.
ZTP solves this problem by shifting the complexity off-site. The site is no longer where configuration takes place; it becomes the location where equipment is installed that has already been anticipated, identified, and controlled from the cloud.
What Is Industrial Zero-Touch Provisioning?
Zero-Touch Provisioning is an automation mechanism that allows a device to configure itself when it connects for the first time. In an industrial context, it must go beyond simply downloading a file: it must manage hardware identity, security, site-specific profiles, certificates, network rules, updates, and lifecycle management.
A typical industrial ZTP process involves several steps.
The key point is initial trust. The gateway must prove its identity to the provisioning server, and the configuration it receives must be protected against interception, tampering, or spoofing.
Why ZTP Is Critical for Industrial IoT
Industrial IoT deployments rarely involve homogeneous, easily accessible sites. A single fleet may include a combination of pumping stations, electrical cabinets, delivery stations, meters, PLCs, environmental sensors, mobile equipment, specialized machinery, and customer sites.
The ZTP addresses three major challenges.
| Issue | Without ZTP | With ZTP |
|---|---|---|
| Deployment Speed | Site-by-site configuration | Centralized preparation and automatic activation |
| Quality | Varies by technician | Standardized and versioned profiles |
| Security | Secrets handled manually | Controlled distribution of certificates |
| Support | Difficult to diagnose issues before connection | Status updates upon enrollment |
| Maintenance | Individual updates | OTA deployment by groups |
| Replacement | On-site reconfiguration | Reassigning hardware to the site |
The ZTP transforms a field project into a fleet management project. It is this change that enables the transition from a small-scale deployment to a large-scale deployment.
Our Approach
Eziwan’s Zero-Touch Provisioning is based on a simple principle: each gateway has a unique identity and can be pre-enrolled before shipment. When powered on for the first time, it contacts the Eziwan platform, identifies itself, retrieves the configuration associated with its serial number, applies the settings, establishes its secure tunnels, and reports its status.
The configuration may include:
-
WAN, LAN, VLAN, and routing settings.
-
SIM-based camera and carrier profiles.
-
Firewall rules, NAT, and segmentation.
-
OpenVPN or IPSec VPN configuration, depending on the architecture.
-
Certificates, keys, and secrets distributed in a controlled manner.
-
Data collection parameters: Modbus, MQTT, API, monitoring, or telemetry.
-
Alert thresholds, watchdogs, and availability probes.
-
OTA Firmware Update Policy.
-
Tags, groups, customer, region, site, and criticality.
The field technician does not need to open the local administration interface. They plug in the power supply, connect the necessary cables, and check the indicator lights or the status displayed on the dashboard.
Architecture of a ZTP Deployment
An effective ZTP architecture clearly separates preparation, deployment, installation, and operation. The Eziwan cloud serves as a configuration repository, provisioning server, and monitoring dashboard.
This architecture makes it possible to prepare several hundred gateways even before they arrive on site. Each device is tracked, identified, and assigned a profile.
Configuration Profiles for Multiple Site Types
The configuration profile is at the heart of ZTP. It describes what a gateway should become once it is installed. Rather than configuring each device individually, templates are defined by site family.
Examples of profiles:
-
Electrical substation.
-
Pumping station.
-
Remote meter reading cabinet.
-
Industrial controller.
-
Client site with remote maintenance access.
-
Isolated environmental sensor.
-
LTE backup router for the OT network.
-
Modbus-to-MQTT data collection gateway.
A profile can contain common settings and site-specific variables. This avoids having to duplicate 200 nearly identical configurations.
profil:
nom: station_pompage_standard
version: 12
reseau:
lan_ip: "{{site.lan_ip}}"
masque: "255.255.255.0"
dns:
- "1.1.1.1"
- "8.8.8.8"
mobile:
apn: "{{operateur.apn}}"
dual_sim: true
vpn:
mode: openvpn
certificat: automatique
collecte:
modbus:
actif: true
equipements:
- nom: automate_principal
ip: "{{site.plc_ip}}"
port: 502
supervision:
heartbeat: 60s
alertes: active
Variables are resolved at the time of provisioning based on the site, the customer, the carrier, or the type of equipment. This approach keeps the profiles easy to read while allowing for fine-grained customization.
Pre-enrollment via CSV Import
A CSV import is often the easiest way to start a large-scale deployment. It allows you to associate serial numbers with sites, profiles, customers, regions, and variable settings in advance.
An import file can contain:
| Field | Example | Purpose |
|---|---|---|
| serial_number | EZGW-2026-000184 | Identify the gateway |
| site_id | PUMP-NORD-042 | Associate with the site |
| profile | station_pompage_standard | Apply the correct template |
| client | collectivite_nord | Organize the fleet |
| region | hauts_de_france | Filter deployments |
| lan_ip | 192.168.10.1 | Customize the local network |
| plc_ip | 192.168.10.20 | Configure data collection |
| sim_profile | multi_operateur_fr | Choose connectivity |
This pre-registration can be completed before shipment. The installer then receives a gateway that is already associated with the target site.
Real-Time Deployment Dashboard
A multi-site deployment project must be managed like an industrial operation. The ZTP dashboard should provide a quick overview of the status of each gateway.
Useful statutes include, among others:
-
Pre-enrolled.
-
Shipped.
-
Power on.
-
Provisioning in progress.
-
Configuration applied.
-
Tunnel established.
-
Operational.
-
Incorrect.
-
Pending approval.
-
Firmware update in progress.
-
Rollback completed.
A centralized dashboard eliminates the need for manual tracking via spreadsheets, scattered messages, or field calls. It also helps identify the causes of service interruptions: no network connection, inactive SIM card, profile error, expired certificate, incompatible firmware version, or power supply issue.
Handling Provisioning Errors
A good ZTP system shouldn’t just work when everything is going well. It must clearly explain why a device failed to provision.
| Error | Possible Cause | Corrective Action |
|---|---|---|
| Unknown serial number | Gateway not pre-enrolled | Add or correct the association |
| Profile not found | Incorrect profile name | Select a valid profile |
| Missing variables | Incomplete site data | Complete the site record |
| Network unavailable | SIM inactive or WAN missing | Check field connectivity |
| Certificate rejected | Invalid or expired identity | Revoke or regenerate according to procedure |
| Incompatible firmware | Version too old | Apply an update step |
| Tunnel not established | Incorrect firewall or APN | Diagnose the outbound link |
This visibility significantly reduces the back-and-forth communication between project teams, support staff, installers, and operators.
Targeted OTA Firmware Update
OTA (over-the-air) firmware is essential for managing an industrial fleet. It allows you to fix vulnerabilities, add features, improve stability, or adapt equipment to a new network architecture.
The rollout should be gradual.
This strategy prevents an unvalidated version from being deployed across the entire fleet. A rollback must be planned from the outset, ensuring that the configuration is preserved and the system is restored to a known firmware version.
Configuration Versioning
Every configuration change must create a new version. This versioning allows you to know exactly which state is deployed on each gateway, to compare two versions, and to roll back if a change causes a problem.
Versioning serves several purposes.
-
Change tracking.
-
Configuration audit.
-
Quick rollback.
-
Phased rollout.
-
Comparison before validation.
-
Consistency across similar sites.
-
Post-incident analysis.
Here’s a simple example: if a firewall rule added for a new traffic flow blocks an existing monitoring rule, you need to be able to revert to the previous version without having to manually rebuild the entire configuration.
Automatic Hardware Replacement
Hardware replacement is one of the best use cases for ZTP. Without automatic provisioning, replacing a gateway often requires sending a qualified technician to reconfigure the equipment on-site. With ZTP, the process can be much simpler.
Typical steps:
-
Report the faulty gateway to the cloud.
-
Assign the new serial number to the same site.
-
Ship the new gateway.
-
Connect the equipment on site.
-
Let the provisioning process retrieve the configuration from the predecessor.
-
Check the feedback online from the dashboard.
This approach reduces reliance on on-site network expertise. It also speeds up the restoration of service at isolated sites.
Provisioning Security
The ZTP handles sensitive information: network configurations, certificates, VPN tunnels, application secrets, and firewall rules. It should therefore be viewed as a security mechanism, not merely as a convenience tool.
Best practices are essential.
-
Authenticate each gateway using a unique identifier.
-
Sign the configurations that were sent.
-
Encrypt communications with the provisioning server.
-
Never send secrets in plain text.
-
Revoke a lost, stolen, or replaced gateway.
-
Log each provisioning request.
-
Limit administrative privileges by role.
-
Validate sensitive changes before mass deployment.
-
Keep a version history.
-
Separate the test, pilot, and production environments.
Provisioning must avoid a common risk: turning an automation tool into a central point of compromise. The security of the platform is therefore just as important as the security of the gateway.
Automatically Distributed Certificates and Secrets
Secrets should not be copied manually by installers. The ZTP allows them to be generated, distributed, and renewed in a controlled manner.
Examples of such secrets include:
-
OpenVPN certificates.
-
TLS certificates.
-
API keys.
-
Collection tokens.
-
MQTT broker identifiers.
-
Secrets of Supervision.
-
SIEM integration keys or webhooks.
Automated distribution reduces copying errors, inconsistent practices, and the risks associated with uncontrolled local storage.
ZTP API for ERP and CMMS Integration
In a structured industrial deployment, sites already exist in other systems: ERP, CMMS, fleet management tools, project management software, customer databases, or OT asset databases. The ZTP API enables these systems to be connected to Eziwan.
Typical use cases:
-
Automatic creation of an Eziwan site when a piece of equipment is created in the ERP.
-
Pre-enrollment of a gateway based on a deployment order.
-
Linking a serial number to a customer or contract.
-
Update a deployment status in the CMMS.
-
Retrieving firmware versions and configuration data for inventory purposes.
-
Launching an OTA campaign from an internal tool.
This integration eliminates the need for duplicate data entry and improves consistency across databases.
Groups, Tags, and Fleet Management
Groups and tags become essential once the fleet exceeds a few dozen devices. They allow you to target actions without having to manage a list of gateways one by one.
Examples of useful tags:
-
Region.
-
Client.
-
Site type.
-
Criticality.
-
Mobile carrier.
-
Firmware version.
-
Configuration profile.
-
Team in charge.
-
Maintenance contract.
-
Test or production environment.
Using this metadata, it becomes possible to push a configuration exclusively to the pumping stations in a region, test firmware on a pilot group, or delegate visibility of a sub-fleet to a client in MSP mode.
Phased Deployment and Rollback
Mass deployment does not mean deploying everywhere at the same time. A good ZTP strategy involves rolling out in waves.
| Wave | Objective | Approximate size |
|---|---|---|
| Laboratory | Validate firmware, profile, and security | A few gateways |
| Field pilot | Test under real-world conditions | 3 to 10 sites |
| First Wave | Confirm repeatability | 5 to 10% of the fleet |
| Rollout | Extend to the rest of the fleet | By region or customer |
| Stabilization | Correct deviations and document | Entire fleet |
Rollback is essential at every stage. It must be possible to apply it to a gateway, a group, or an entire campaign.
Industrial Use Cases
Multi-site Remote Meter Reading
Remote meter reading projects often involve hundreds of meters, stations, or cabinets. The ZTP allows you to pre-enroll gateways, apply a standard collection profile, and track the gradual activation of sites.
Remote Access to PLCs
A machine manufacturer can ship gateways that are already paired with its customers. Once connected, they automatically retrieve the VPN rules, certificates, and access rights needed for maintenance.
Pumping Stations and Water Systems
Drinking water and wastewater treatment facilities are often scattered across a wide area. The ZTP reduces the need for specialized technicians to travel and allows local teams to install the equipment without complex configuration.
Energy and Substations
In the energy sector, configurations must be consistent and auditable. Versioning, groups, and OTA campaigns make it easier to maintain a fleet of gateways spread across multiple critical sites.
OEM Deployment
A machine manufacturer can integrate a gateway into each piece of equipment it delivers. The end customer receives a connected machine, while the OEM retains centralized management of access, firmware, and profiles in accordance with service contracts.
Checklist Before a Large-Scale ZTP Deployment
Before launching a deployment of 50 to 500 gateways, there are several key points to address.
| Check | Question | Priority |
|---|---|---|
| Inventory | Are the serial numbers known? | High |
| Sites | Is each gateway associated with a site? | High |
| Profiles | Have the profiles been tested in the lab? | High |
| Variables | Are site-specific settings complete? | High |
| Connectivity | Are the WAN, SIM, or backup link ready? | High |
| Security | Are certificates and secrets distributed automatically? | High |
| OTA | Is there a phased update strategy in place? | Medium |
| Rollback | Has rollback been tested? | High |
| Dashboard | Are teams monitoring statuses in real time? | High |
| Support | Is there a procedure for provisioning errors? | High |
This checklist helps prevent preparation issues from coming to light once the installers are already on site.
Common Mistakes to Avoid
Confusing ZTP with a single image
Simply installing the same image on all devices is not enough. ZTP must manage differences in sites, variables, profiles, secrets, versions, and security rules.
Clear Site Data
A serial number without a site, profile, or network variable cannot be provisioned correctly. The quality of the input data determines the success of the deployment.
Deploying Firmware Everywhere Without Drivers
Even an update that has been validated in the lab must be tested on a pilot group. Real-world environments sometimes reveal unexpected constraints, such as mobile operators, NAT, unstable power supplies, local protocols, or outdated equipment.
Working with Secrets Manually
Manually copying certificates or tokens negates some of the benefits of ZTP. Secrets must be generated, transmitted, renewed, and revoked through a controlled process.
Do not plan for hardware replacement
An industrial fleet will be in service for several years. It is necessary to plan from the outset for breakdowns, standard replacements, the decommissioning of old equipment, and the assignment of new serial numbers.
Metrics to Track During the Rollout
A ZTP project must be guided by simple, actionable indicators.
| Metric | Why track it |
|---|---|
| Pre-enrolled gateways | Verify fleet readiness |
| Gateways powered on | Track field progress |
| Successful provisioning | Measure actual success rate |
| Provisioning error | Identify bottlenecks |
| Average activation time | Detect delays |
| Deployed firmware version | Ensure fleet consistency |
| Configuration version | Track discrepancies between sites |
| Rollback rate | Evaluate campaign quality |
| Sites without a heartbeat | Identify silent installations |
| Support tickets per wave | Improve future waves |
These metrics make it possible to manage a week of deployment with precision, rather than discovering delays at the end of the project.
How Eziwan Accelerates Industrial Deployments
Eziwan provides the building blocks needed to transition from a manual setup to automated fleet management.
| Need | Eziwan’s Response | Benefit |
|---|---|---|
| Prepare the fleet | Pre-enrollment by serial number | Simplified field installation |
| Standardize | Configuration profiles | Fewer discrepancies between sites |
| Secure | Signed configurations and distributed secrets | Less manual intervention |
| Update | Targeted OTA firmware | Large-scale maintenance |
| Fix | Versioning and rollback | Rapid rollback |
| Replace | Hardware reassignment | Accelerated return to service |
| Monitor | Real-time dashboard | Rollout management |
| Integrate | ZTP API | Integration with ERP, CMMS, and project tools |
This approach is particularly relevant for the Eziwan gateway, monitoring via the Eziwan cloud, and industrial connectivity projects.
Sample Deployment Plan for 200 Sites
An ambitious deployment should be broken down into clear phases. The example below illustrates a realistic approach, which should be adapted based on installer availability, site readiness, and operational constraints.
| Day | Objective | Expected Result |
|---|---|---|
| 10–5 days before | CSV import, profiles, lab tests | Pre-enrolled devices and validated profiles |
| D-4 to D-2 | Shipping and field coordination | Gateways delivered to teams |
| D-1 | Pilot test at a few sites | Final adjustments |
| D1 to D2 | First regional wave | Detection of recurring errors |
| Day 3 to Day 4 | Expansion to standard sites | Acceleration of the pace |
| Day 5 | Complex or isolated sites | Targeted processing |
| Day 6 to Day 7 | Stabilization and reporting | Documented and operational fleet |
ZTP does not eliminate project planning. It makes it more reliable, more traceable, and much less dependent on repetitive manual tasks.
Conclusion
Zero-Touch Provisioning is an essential component for deploying industrial IoT gateways at scale. Without ZTP, each site requires manual configuration, with the associated risks of errors, delays, costs, and inconsistencies. With ZTP, deployment is prepared in the cloud, executes automatically upon power-up, and is managed from a centralized dashboard.
Eziwan allows you to pre-enroll gateways, apply versioned profiles, distribute certificates and secrets, update firmware over the air (OTA), track progress in real time, and replace hardware without on-site reconfiguration. Whether for a project involving 50, 200, or 500 sites, this approach transforms industrial IoT deployment into a controlled, repeatable, and auditable process.
Further Reading
- OTA provisioning — remotely update the firmware and configuration of your devices
- Fleet management — centralize the monitoring and management of your industrial equipment
- Industrial Routers — compare industrial router lines suitable for large-scale deployment
- Industrial IoT Gateway — the Eziwan gateway designed for large-scale ZTP deployment
- Router Fleet Management Guide — manage hundreds of routers without a dedicated network team