SD-WAN automation simplifies operations by moving configuration from individual devices to central, repeatable policy. A new branch device boots, authenticates, fetches its configuration and joins the network without an engineer on site. Changes roll out from one place and can be rolled back. The gain is consistency, and the risk is a bigger blast radius.
What does the automation actually do?
Three jobs account for most of the benefit. Provisioning gets a device from the box to a working configuration. Policy distribution pushes the same routing, segmentation and security intent to many sites. Change control applies updates in a controlled way and recovers if they fail.
None of this is unique to one vendor. The building blocks are open standards, which is useful because you can ask any supplier which of them they implement.
What is zero touch provisioning?
The IETF's RFC 8572 describes Secure Zero Touch Provisioning (SZTP). Its abstract says it presents a technique to securely provision a networking device when it boots in a factory-default state, with variations for both public and private networks. The provisioning steps can update the boot image, commit an initial configuration and execute scripts for auxiliary needs. The updated device can then establish secure connections, for instance NETCONF or RESTCONF, with the network management system.
The word that matters is secure. A device that auto-configures from whatever server answers is an attack path. SZTP is built so the device can verify what it is being told to run.
How do configuration changes reach devices safely?
NETCONF, defined in RFC 6241, provides mechanisms to install, manipulate and delete the configuration of network devices, using XML and remote procedure calls. Several of its optional capabilities are about safety rather than speed: a candidate configuration datastore, a confirmed commit, and rollback on error. A confirmed commit means a change reverts on its own unless you confirm it, which protects you when a change cuts off your own access.
RFC 7426 gives the wider frame: software defined networking is the capacity to initialize, control, change and manage network behavior dynamically through open interfaces, separating the control plane from the data forwarding plane.
What goes wrong when you automate a network?
Automation multiplies mistakes as faithfully as it multiplies good changes. Constructed example: an engineer edits a shared template that sets the guest network's firewall rule. A typo widens the rule, and 200 branches pick it up in the next sync. A manual process would have hit one site at a time and someone would have noticed at site three.
The second risk is the controller itself. If one console can change every site, its access control, logging and recovery plan become the most sensitive part of the network.
What should you ask a supplier or your own team?
- Does zero touch onboarding authenticate the device and the server, and how are ownership and trust anchors set up?
- Can changes be staged to a canary group of sites before everything?
- Is there an automatic rollback if a site loses contact with the controller after a change?
- Who can change global templates, and is every change logged with the name of the person?
- Can you export configuration and logs to systems you control?
How to check or apply this
- Write down your site types and the intended configuration of each, in plain language, before automating anything.
- Keep templates and variables in version control, with review before merge.
- Roll changes out in rings: a lab, a pilot site, one region, then everyone.
- Require confirmed commits or equivalent automatic rollback for any change that could cut off management access.
- Lock down the controller with strong authentication, role separation and an alert on bulk changes.
- Test the recovery of a site with no connectivity to the controller, since that is the case you will meet in an outage.
- Compare running configuration against the intended state on a schedule and alert on drift.
Quick check
Is zero touch provisioning secure by default?
Not automatically. RFC 8572 defines a secure method, but you should confirm how a product authenticates the device and the provisioning server.
Does automation remove the need for network engineers?
No. It shifts their work to design, templates, review and recovery, and mistakes in a template reach every site that uses it.
Sources
- RFC 8572, Secure Zero Touch Provisioning (SZTP)
- RFC 6241, Network Configuration Protocol (NETCONF)
- RFC 7426, Software-Defined Networking: Layers and Architecture Terminology
Last reviewed: 18 October 2026.
