A new branch router should phone home, learn who its controllers are, and join the overlay without anyone logging in. That is what Plug and Play and Zero-Touch Provisioning are for. This lab never used them. We typed the organization name, the Validator address, and the serial list ourselves.
This post explains what Cisco's cloud Plug and Play path does, what Zero-Touch Provisioning means next to it, and which of those steps the earlier posts replaced by hand. It is theory plus a comparison to a Cisco Catalyst SD-WAN 20.18.2.1 fabric with C8000v routers on IOS XE 17.18.02, built in my home lab. I did not register a Smart Account or talk to Cisco's PnP portal.
This is part of the Cisco SD-WAN series. Previous: vEdge in 2026: Onboarding and Why It's End-of-Life. The manual work this path would have skipped starts at Uploading the WAN edge serial list manually and Onboard a Catalyst 8000v 17.18 in controller mode.
For SD-WAN Manager (formerly vManage) and the other old names, see the name map.
The problem: the box does not know your Validator
An edge straight from the factory has no organization name and no Validator address. It does not know whether it should run ordinary IOS XE or join an SD-WAN overlay. Someone has to tell it.
You can type those facts on the console. That is what we did. In a production rollout of dozens of branches, you want the router to discover them by itself the first time it sees the Internet.
Plug and Play (PnP) is Cisco's name for that discovery on IOS XE devices. Zero-Touch Provisioning (ZTP) is the older name for the same idea on vEdge devices. People say "ZTP" for both. The cloud service that holds the mapping is PnP Connect.
Think of PnP Connect as a phone book that Cisco hosts. The factory router looks up its serial number and reads back your Validator and organization name.
The parts
Two sides have to be ready. The network side is a WAN port that can reach the Internet. The admin side is a record in PnP Connect that ties this serial number to your overlay.
According to Cisco's onboarding guide, the admin side looks like this:
- The device is ordered in Cisco Commerce against a Smart Account and Virtual Account, so the serial number lands in the PnP portal.
- You add a Cisco Catalyst SD-WAN Validator controller profile in that same account. The profile holds the Validator address and the organization name.
- You associate the new device with that profile.
- PnP sends the Validator details, serial numbers, organization name, and network ID toward ZTP.
- You download the device serial-number file from PnP and upload it to SD-WAN Manager, or you use Manager's Sync Smart Account option to pull the same list.
I did not perform those portal steps. There is no Smart Account attached to this lab, and this post is not a signup guide.
On the router side, Cisco describes this sequence for an IOS XE WAN edge:
- The supported PnP WAN interface takes an address, default gateway, and Domain Name System (DNS) servers from the Dynamic Host Configuration Protocol (DHCP).
- The router resolves
devicehelper.cisco.comand opens an HTTPS session to PnP Connect. - PnP Connect returns the Validator address and the organization name. For an enterprise-root deployment, Cisco's 2020 onboarding guide also says the router can receive the root certificate here.
- The edge authenticates to the Validator with its chassis or serial and the shared root.
- The Validator hands over the Manager and Controller addresses. The edge builds those control connections and downloads its configuration.
From step 4 onward the overlay looks like the manual path. Discovery is the only piece PnP adds.
What our lab typed instead
The running edges already have the values PnP would have delivered:
edge1#show sdwan running-config system
system
system-ip 10.0.0.1
site-id 100
organization-name pinglabz-lab
vbond 172.16.30.30 port 12346
!show version reports Router operating mode: Controller-Managed. Transports, the enterprise root, the pay-as-you-go chassis identity, and the authorized serial list were all configured by hand. The enterprise root, serial list, and C8000v onboarding posts are that procedure.
Here is the same story as a comparison:
| Fact the edge needs | PnP / ZTP (Cisco docs) | This lab |
|---|---|---|
| First IPv4 address | DHCP on the PnP or ZTP WAN port | Static addresses we configured |
| Who the Validator is | Controller profile in PnP Connect | vbond 172.16.30.30 port 12346 typed on the device |
| Organization name | Same controller profile | organization-name pinglabz-lab typed on the device |
| Authorized serial list | Serial file from PnP, or Sync Smart Account | PAYG identities generated on Manager and pushed by hand |
| Shared root certificate | Cisco well-known roots, or a root sent by PnP for an enterprise CA | A local enterprise root we installed ourselves |
| Controller vs Autonomous mode | PnP can change the mode and reload the box | The C8000v was already Controller-Managed |
A virtual C8000v that you create yourself also does not arrive in PnP Connect the way a purchased ISR does. There is no factory order to drop a serial into your Virtual Account. That is why a PAYG lab tends to use the manual serial-list path even when the operator does have a Smart Account.
PnP can change the mode
Cisco documents a mode-discovery step that we never triggered. If an IOS XE router boots in Autonomous mode and PnP Connect points it at an SD-WAN Validator, the device changes to Controller mode and reloads, then continues discovery. If it boots in Controller mode and PnP points it at an ordinary IOS (non-SD-WAN) deployment, it can change the other way.
The Autonomous vs Controller Mode post covers the CLI form of that switch (controller-mode enable and disable) and the config wipe that comes with enable. PnP is doing the same kind of change without you typing the command.
Cisco also documents bootstrap files as a cousin of PnP. A ciscosdwan.cfg or ciscosdwan_cloud_init.cfg file in the bootstrap location boots the router in Controller mode and applies the file. That is useful in an air-gapped network where devicehelper.cisco.com is unreachable. I did not use a bootstrap file in this lab.
ZTP on vEdge used a different hostname
On Viptela OS vEdges, Cisco's 2020 guide has the router resolve ztp.viptela.com instead of devicehelper.cisco.com. Later onboarding documents also mention ztp.cisco.com. The idea is the same: DHCP, then a well-known name, then the Validator and organization name.
That path belongs to the vEdge family, which is end-of-life. New work should assume the IOS XE PnP hostname.
Cisco's 20.18.1 Manager notes also say unsupported device families were removed from the Zero Touch Provisioning settings page. Check the list in your own Manager before you plan a ZTP profile for an old platform.
I did not open devicehelper.cisco.com, create a PnP controller profile, sync a Smart Account, or trigger a mode change. If you run a production overlay with a Smart Account, use Cisco's current onboarding guide for those portal clicks. This series stays on the manual path because that is what the fabric used.
Once discovery succeeds, the checks are the same ones as a manual onboard: control connections to the Validator, Manager, and Controller, then Overlay Management Protocol (OMP) peers, then Bidirectional Forwarding Detection (BFD) sessions. A factory box that never reaches devicehelper.cisco.com never gets that far. A box that reaches PnP but is missing from the authorized list fails later, at the Validator, for the same reason a manual serial-list mistake does.
Verify you are not accidentally depending on PnP
| Check | What you should see in this style of lab |
|---|---|
| System identity | show sdwan running-config system already has organization-name and vbond |
| Operating mode | show version shows Controller-Managed |
| Control connections | show sdwan control connections to Validator, Controller, and Manager |
| How the serial list arrived | Manager inventory you uploaded or generated, not a Sync Smart Account job |
If vbond is empty and the WAN interface is a DHCP client pointing at the Internet, the router may still be trying PnP. That is expected on a factory box. It is a surprise on a lab edge you thought you configured by hand.
What breaks
- No DHCP, no DNS, or no path to `devicehelper.cisco.com`. The factory IOS XE edge never learns the Validator. The console will sit in discovery. Give it reachability, or abandon PnP and type the system block yourself.
- Device missing from the controller profile. PnP cannot return an organization it has not been told about. The serial also has to exist in Manager before the Validator will accept the edge.
- Wrong mode after discovery. A successful PnP lookup can reload the router into Controller mode and erase Autonomous startup configuration. Back up first if the box already has a working IOS XE config.
- Interrupted ZTP. Cisco warns that if ZTP is interrupted by a reload, it may not restart, and you then finish the upgrade or config by hand.
- Following the vEdge hostname on an IOS XE router. Use
devicehelper.cisco.comfor IOS XE. The vEdge ZTP names belong to a platform this series is not building.
Key takeaways
- PnP Connect is the cloud phone book. It maps a factory serial number to your Validator and organization name. ZTP is the older vEdge name for the same idea.
- After the edge learns those two facts, onboarding continues the usual way: authenticate to the Validator, learn the Manager and Controller, then build OMP and BFD.
- This lab replaced the phone book with typed configuration, a local enterprise root, and a manual PAYG serial list. I did not use a Smart Account.
- PnP can also switch Autonomous mode to Controller mode and reload the router. That is documented by Cisco, not something I triggered here.
- Working control connections from the manual posts mean this fabric does not need PnP. Production IOS XE branches usually do, which is why the discovery steps are worth knowing.