• Blog

What zero touch provisioning is and how it works

Zero touch provisioning (ZTP) is a self-provisioning method that automatically configures networking devices the moment they join a network.

It is the standard approach for rolling out networking devices such as routers, firewalls, and switches across multiple sites at scale, without the cost and complexity of dispatching engineers to each location.

This guide explains what ZTP is, how it works, and why it matters for scaling multi-site network deployments.

Contents:

• What is zero touch provisioning (ZTP)?
• ZTP as a key component of modern networks
• How does ZTP work?
• What are the security risks of ZTP?

What is zero touch provisioning (ZTP)?

Zero touch provisioning (ZTP) is a method used for deploying networking devices such as routers, firewalls, switches and WiFi access points at scale, without manual intervention beyond physically connecting them to a network.

As soon as new devices gain basic connectivity, they receive an IP address and instructions to locate and reach the provisioning server automatically. Once authenticated as valid devices, they retrieve firmware, configuration settings, and certificates from predefined locations in the vendor cloud or local network, a process that typically completes within minutes.

The result is a large number of fully-provisioned devices brought online with little or no on-site engineering input. While some may start operating immediately, others are ready to receive their final WAN policies from a central controller or dashboard before doing so.

This makes ZTP the standard approach for network deployments at scale, such as:

• Retail chain rollouts: Deploying routers and firewalls across hundreds of stores simultaneously without on-site engineers.
• Bank branch upgrades: Provisioning SD-WAN appliances across dozens of regional branches, each coming online with the correct security policies.
• Hotel group WiFi: Rolling out WLAN access points across tens of properties so guest WiFi and PoS systems are live the moment a device is plugged in.
• Remote worker devices: Shipping pre-enrolled laptops and home-office gateways directly to employees, so devices configure themselves automatically on first connection.

It is worth noting that “zero touch” does not mean zero human involvement. Someone still needs to unbox the device, cable it up, and power it on, but that can be anyone on-site, with no technical expertise required.

ZTP as a key component of modern networks

Modern business networking has shifted decisively toward cloud-managed, software-defined models (SD-WAN, SASE, cloud-managed WAN, WiFi and firewalls) where the control plane lives in a vendor portal, and the hardware on site is effectively just an execution point.

ZTP makes these solutions significantly easier to deploy by:

• Simplifying multi-site rollouts: Devices auto-configure on first boot, so they can ship directly from distributor to site and be brought online by non-technical staff. This removes the cost of dispatching engineers to every branch, and eliminates the need for staging warehouses or pre-configured shipping.
• It enforces consistency at scale. Every device across the WAN pulls from the same pre-tested, hardened template, eliminating the configuration drift risk of manually provisioned networks and making security posture uniform across sites.
• It aligns with how IT teams actually operate. Most in-house teams are small and centralised, and most multi-site rollouts are delivered by third-party service providers. Both models depend on remote, automated provisioning, and neither has engineers to spare for site visits.

How does ZTP work?

When a ZTP-enabled device is powered on for the first time, it follows the same sequence every time to retrieve and apply its configuration automatically.

While deployment details vary depending on the solution being rolled out, the underlying process is consistent across all of them:

1. Device is physically connected to the network and turned on

A member of staff connects the device to the local area network and powers it on. This step is non-technical and may be performed by anybody from a receptionist to an office manager.

On first boot, the device detects that it has no saved configuration and automatically enters ZTP discovery mode, ready to reach out for its configuration.

2. DHCP request and IP address assignment

Without a configuration to work from, the device broadcasts a DHCP (Dynamic Host Configuration Protocol) request across the network. The DHCP server responds with an IP address, giving the device basic network connectivity.

In most modern deployments, this is sufficient. The vendor cloud address is embedded in the device firmware, so it knows how to reach the provisioning server.

In deployments where this is unavailable, the DHCP server can also return additional instruction fields called “Options” that tell the device where to find its provisioning server:

• Option 43: Carries vendor-specific instructions pointing to the provisioning server.
• Option 66: Specifies the hostname or IP address of the provisioning server.
• Option 67: Specifies the filename of the configuration file to retrieve.

3. Device authentication and configuration delivery

Once a device reaches its provisioning server, how it authenticates and receives its configuration depends on where that configuration is stored.

Vendor cloud portal (single-vendor environments)

When devices are delivered as a single-vendor solution, such as Cisco Meraki or Fortinet, they authenticate using a serial number or certificate embedded at manufacture, which the vendor portal cross-references against pre-registered device records.

A bootstrap configuration is delivered first, establishing base settings and a secure tunnel to the controller, which then pushes the full configuration: routing policies, traffic steering rules, and security settings.

This is the most widely adopted model across SD-WAN solutions, SASE, and cloud-managed firewall deployments.

Cloud storage (multi-vendor environments)

In environments spanning multiple vendors, generations, or device types, configuration files are typically created and hosted in independent cloud storage such as AWS or Azure.

The device authenticates via cloud access credentials or a pre-shared token, then pulls a complete static configuration file from the storage bucket on first boot.

Local provisioning server (high security environments)

For devices where configuration must remain within a controlled network perimeter, common in regulated industries or air-gapped environments, configuration is retrieved entirely within the business local or private wide area network.

The server validates the device by serial number or MAC address against a pre-registered list, then delivers the configuration and any required firmware over the local network.

5. Configuration and registration per device type

The device applies its configuration automatically without any manual input. Exactly what gets configured varies by device type. Typical examples include:

• A Dual-WAN router receiving broadband failover and load balancing policies
• A firewall receives traffic rules and VPN settings
• A switch receiving its VLAN assignments
• A WiFi 7 access point receiving its SSID and band configuration

Once applied, the device registers with its central management platform. It appears as fully operational in the IT team’s dashboard, completing its transition from an unrecognised box on the network to a fully managed device.

6. Failure fallback

If any step in the sequence fails, whether the device cannot reach the vendor cloud portal, the provisioning server is unreachable, the serial number is not recognised, or the configuration file is corrupted, the device will fall back to an unconfigured state and retry at intervals.

The central management platform will flag any device that has failed to provision, allowing the IT team to identify and resolve the issue remotely. Monitoring deployment status is an essential part of any ZTP rollout.

What are the security risks of ZTP?

ZTP is typically considered significantly more secure than manual device configuration because it eliminates human error from the provisioning process and makes auditing significantly easier.

Every device receives the same pre-tested, hardened configuration template, removing the risk of mistyped settings, forgotten hardening steps, or inconsistent configurations across sites.

It also leaves a clear audit trail of what configuration was applied, when, and to which device, supporting the documentation requirements of GDPR‘s accountability principle.

However, like any technology, ZTP does introduce new risks. While these are largely mitigated by design, it is still worth understanding them:

DHCP spoofing and man-in-the-middle attacks

Any ZTP device that has just been powered on has no configuration, no security policies, and no authenticated relationships.

It trusts whatever DHCP response it receives, meaning an attacker who can intercept or spoof that response can redirect the device to a rogue provisioning server and deliver a malicious configuration.

This is addressed by Secure ZTP, as defined in IETF RFC 8572, through three built-in mechanisms:

• Mutual TLS authentication: Both the device and server verify each other before any configuration is exchanged.
• Signed configuration artefacts: The configuration file is cryptographically signed so the device can verify it has not been tampered with.
• Manufacturer embedded device identity: Each device carries a unique cryptographic identity embedded during manufacture, eliminating the risk of rogue devices provisioning themselves.

Unauthorised access to provisioning configurations

Unlike manual configuration, ZTP requires devices to access a remote provisioning server or vendor cloud portal, introducing unauthorised access risks.

To mitigate this, organisations or service providers usually need to pre-register device serial numbers in the provisioning server or vendor cloud portal before shipping, ensuring only known devices can retrieve configurations.

Additionally, access to the provisioning server itself should be restricted to HTTPS with valid certificates, with network access limited to expected devices and IP ranges only.

Misconfigured or under-tested configuration templates

Because ZTP automatically configures multiple devices, if their configuration template has not been properly hardened (i.e., tested) before deployment, it may consistently reproduce the same security gaps across every device it touches.

To mitigate this, templates should be hardened and validated in a test environment before production deployment.

At a minimum, the template should meet the Cyber Essentials baseline and NCSC network device security guidance: default passwords changed, unnecessary services disabled, access controls in place, network segmentation applied, and software up to date.

What are the differences between ZTP and manual provisioning?

ZTP automates deployment through upfront preparation, while manual provisioning requires more hands-on effort but is generally simpler to set up for smaller deployments. Neither approach is inherently better; each is better suited to different deployment scenarios.

Here is a summary of the differences between them:

The crossover point where ZTP beats manual provisioning is usually somewhere between five and ten simultaneous deployments.

How does a business plan for ZTP?

ZTP isn’t usually planned as a standalone project. It sits inside a larger deployment, typically an SD-WAN rollout, a firewall refresh, or a multi-site network upgrade, as the mechanism that makes the rollout practical at scale.

Within that parent project, the ZTP-specific decisions a business needs to make are:

• Deployment model: Cloud-managed (simpler, but needs internet at every site) or traditional with a local provisioning server (more complex, but works offline).
• Pre-registration process: Who registers device serial numbers with the vendor cloud, and at what point in the supply chain, usually the supplier or MSP, before shipping.
• Golden template: Who builds, hardens, and owns the configuration template, and how it’s validated against Cyber Essentials and NCSC guidance.
• Site readiness: How circuits, cabling, and on-site staff briefings are coordinated so devices can be plugged in and powered on without issues.
• Monitoring and fallback: Who watches the provisioning dashboard during rollout, and how failures are escalated.

Most UK businesses don’t own this process themselves. Instead, it’s handled by an MSP as part of the wider deployment, or by a dedicated network engineer for the duration of the project.

Zero touch provisioning (ZTP) – FAQs

Our business networking experts answer commonly asked questions regarding zero touch provisioning of networking devices:

Does the broadband circuit at a remote site need to be active before ZTP can work?

In most cases, yes. Except for deployments where the device fetches its configuration locally, devices need to reach the vendor’s cloud portal over the internet to pull their bootstrap configuration.

This means the business broadband connection at the site must be live before the hardware is powered on. For remote sites where fixed-line connectivity is limited or unreliable, a business satellite broadband connection can provide the stable internet access ZTP needs to complete successfully.

If it isn’t, the device will boot and attempt to reach the provisioning server, fail, and enter a retry loop, cycling through the same attempts until connectivity comes up or the process times out entirely. In practice, this is one of the more common causes of ZTP delays at remote sites.

Search the best business broadband providers for your sites today using our trusted business broadband comparison service.

Does ZTP replace the need for a network management platform after deployment?

No. ZTP handles day-zero provisioning only. This is the initial configuration that turns an unboxed device into a working piece of network kit.

Everything after that (network monitoring, configuration changes, firmware updates, policy enforcement, troubleshooting) is handled by a network management platform.

In most modern deployments, the two are the same system: the vendor cloud portal that delivers the ZTP configuration is also the ongoing management platform.

Can ZTP provision both the underlay and overlay configuration for SD-WAN?

Yes, in sequence. ZTP applies the underlay first (WAN interface, IP addressing, routing to reach the controller) so the device can get online, then the SD-WAN controller pushes the overlay (encrypted tunnels, traffic steering, QoS) automatically once the device registers.

Without this two-stage ZTP flow, SD-WAN rollouts would require an engineer on every site to configure both layers manually.

Read our SD-WAN explainer to learn more about this rapidly growing networking technology.

Is ZTP compatible with devices from multiple vendors in the same network?

Yes, but each vendor runs its own ZTP workflow through its own cloud portal. A mixed Cisco, Fortinet, and Juniper estate means pulling configurations from Cisco PnP Connect, FortiCloud, and Juniper Mist, respectively; three parallel pre-registration processes and three template formats.

Secure ZTP (as defined in IETF RFC 8572) offers a standards-based alternative, but vendor adoption is inconsistent. Multi-vendor estates typically consolidate onto a single vendor specifically to simplify ZTP and ongoing management.

How does Cisco Plug and Play differ from standards-based ZTP?

Cisco PnP is Cisco’s proprietary ZTP implementation, built for Cisco IOS-XE devices and tied to Cisco management platforms (Catalyst Center, Meraki Dashboard).

Secure ZTP (as defined in IETF RFC 8572) is a vendor-neutral alternative built by the Internet Engineering Task Force, which any compliant device can use.

There are three practical differences between them.

• Ecosystem: Cisco PnP only works with Cisco kit. RFC 8572 works across vendors.
• Discovery: Cisco PnP uses Cisco’s cloud redirect service. RFC 8572 uses DHCP options or DNS.
• Certificates: Cisco PnP uses Cisco-issued certificates by default. RFC 8572 works with any standards-compliant CA.

For Cisco-only environments, PnP is more mature. For multi-vendor estates, RFC 8572 is the only path to a unified workflow.

What is a golden configuration template and how is it used in ZTP?

A golden configuration template is the standardised, pre-tested, security-hardened configuration that serves as the baseline for every device of a given type and role.

In ZTP, it is what the vendor cloud or provisioning server delivers to each new device. Site-specific variables (site name, dynamic IP addressing, VLANs) are substituted in at provisioning time, but the underlying security policies, routing, and access controls stay consistent across the estate.

When a vulnerability or policy change appears, it’s updated on the template once, tested, and rolled out, not reconfigured device by device.

What are the most common reasons a ZTP deployment fails?

ZTP rarely fails when implemented by reputable service providers. The process itself is deterministic; if the preconditions are met, it works. When things do go wrong, the cause is almost always one of the following:

• Serial numbers not pre-registered: The vendor cloud doesn’t recognise the device and refuses to deliver a configuration. Usually a handover gap between the supplier and the team managing the cloud portal.
• Broadband circuit not active on the day: The device powers on, can’t reach the vendor cloud, and sits in retry loops. A site readiness check the day before usually catches this.
• Firewall blocking vendor cloud domains: Common at sites with existing network infrastructure where outbound traffic to the vendor’s provisioning domain hasn’t been whitelisted.
• Untested template change: A configuration update pushed to the golden template without proper lab validation breaks provisioning across every device that pulls it. This is the one genuinely ZTP-specific failure mode, and the reason lab testing matters.

Can ZTP be used for firmware upgrades as well as initial configuration?

No, ZTP only ensures devices are initially deployed with consistent, tested firmware.

Ongoing firmware upgrades after deployment aren’t technically ZTP anymore; they’re handled by the vendor’s management platform over the same secure channel.

In practice, the distinction rarely matters because ZTP and the management platform are usually the same ecosystem.

Can ZTP work in an environment without internet access at the remote site?

Yes, but only when using a local provisioning server. The device retrieves its configuration over the LAN or private wide area network (if available) from a server within the organisation’s own network, so no internet access is required.

ZTP for cloud-managed WANs (the more common modern approach) does need internet access. For genuinely offline sites, the device needs to be either pre-staged before shipping or use a traditional ZTP workflow.

How do managed service providers (MSPs) in the UK use ZTP for customer deployments?

ZTP is the backbone of MSP branch rollout services. The standard workflow is as follows:

1. MSP pre-registers customer device serial numbers with the vendor cloud before the hardware ships.
2. Devices ship directly from the distributor to the customer site, bypassing the MSP warehouse.
3. Non-technical site staff unbox, cable, and power on the device.
4. The device provisions itself from the MSP-managed cloud portal using the customer-specific template.
5. The MSP monitors provisioning remotely and intervenes only on failure.

For MSPs with hundreds or thousands of customer sites, ZTP is the only commercially viable way to deliver branch services at scale.

Is ZTP worth the setup investment for a business with only five or six branch offices?

It depends. For a static estate in one city, a technician can probably visit each site in a couple of days for less than the cost of building and testing ZTP templates.

For sites spread across the UK, or a business expecting to add sites regularly, ZTP pays back within the first two or three deployments. Avoiding travel and engineering time usually covers the setup cost quickly.

Even small estates benefit from ZTP’s consistency and audit trail if regular template changes or device refreshes are expected.

In the end, most multi-site deployments are done with assistance from third parties, so it’s ultimately up to their expertise.

What should an IT team test in a lab before rolling out ZTP to production sites?

At a minimum, IT teams should test:

• Template application: The configuration applies cleanly to a factory-reset device without errors.
• Template hardening: The configuration meets Cyber Essentials and NCSC baseline requirements.
• Serial registration workflow: The end-to-end process works, from adding a new serial to confirming the device is recognised.
• Failure fallback: The device behaves as expected when something goes wrong, such as the server being unreachable or the serial being unregistered.
• Firmware compatibility: The template works across every firmware version in use, not just the latest.
• Management platform registration: The device appears correctly in the central dashboard after provisioning.
• Time to provision: The full process completes within an acceptable window, typically under 15 minutes.

Skipping lab testing is the most common cause of ZTP rollouts going badly. A template that works on one device can fail silently across fifty.

How does ZTP work in SD-WAN deployments?

SD-WAN is the most common ZTP use case. The typical flow:

1. SD-WAN appliance is pre-registered with the vendor’s orchestrator (Cisco vManage, Fortinet FortiManager, Versa Director) using its serial number.
2. Device ships directly to the branch.
3. Site staff plug it into the WAN circuit and power it on.
4. Device contacts the vendor cloud using embedded firmware, authenticates via certificate, and pulls its underlay configuration.
5. Once online, it registers with the SD-WAN controller and pulls its overlay configuration (tunnels, traffic steering, application-aware routing).
6. The device appears in the SD-WAN dashboard as fully operational, typically within 10-15 minutes.

The commercial case for SD-WAN depends on ZTP working reliably. Without it, branch rollout costs erode most of the savings SD-WAN is meant to deliver.

Back to blog Back to broadband guides

• Share:
• 
• 
• 
•