Zero touch provisioning (ZTP) lets a new network device find a server on first boot and download its configuration without anyone typing commands. It saves staff time at scale. Plain ZTP can be hijacked unless the device verifies what it receives, which is what the Secure ZTP standard in RFC 8572 adds.
How does ZTP work in the basic form?
A new switch, router or other device boots with no configuration. It requests an address by DHCP, and the reply includes an option telling it where to fetch a bootstrap file or script. The device downloads it and applies the settings, then may fetch a software image and the full configuration.
For an operator shipping 200 devices to branch offices, this means unboxing, plugging in power and a network cable, and walking away. No engineer needs to travel.
Where is the security risk?
The early steps happen before the device has any trust relationship. If the device believes the first server that answers, an attacker on the same network can respond to the DHCP request with their own server address, and serve their own configuration. The device would then be under the attacker's control, with a path into the network it joins.
A constructed example. A retailer ships a router to a new store. Before the store's own network is ready, the router boots on a temporary guest network in the mall's shared back office. Someone on that network runs a rogue DHCP service and answers first. The router fetches a malicious bootstrap file over an unauthenticated transfer and applies it. If the store's installer never notices, the router now forwards traffic as the attacker designed.
Unauthenticated file transfer protocols and unsigned scripts make the problem worse, since nothing proves the content came from the owner.
What does Secure ZTP change?
RFC 8572 defines Secure Zero Touch Provisioning. Its main ideas are that the device checks signed data and that it need not trust the bootstrap server. The bootstrap information is signed, and the device verifies the signature using trust anchors it already holds, such as a vendor or owner certificate. Ownership vouchers, issued by the manufacturer or its representative, tell the device which owner's signatures it should accept.
The RFC notes that bootstrap servers are untrusted: they can be reached over any network path, and a compromised one cannot give the device bad configuration, since the signature would fail. It can only cause the device to fail to bootstrap.
A related standard, RFC 8995, describes Bootstrapping Remote Secure Key Infrastructures (BRSKI), where a new device is introduced to a network with the help of a manufacturer-run service and vouchers. It is aimed at establishing a trusted identity for the device.
What else should you do?
Secure the supply chain around the device. Order from trusted sources, check serial numbers against your order, and record them. Use a staging network for first boot when possible, with DHCP controls such as DHCP snooping on switches that limit which ports may serve addresses. Remove ZTP settings after provisioning where the platform allows, so a device that is wiped and reconnected later does not repeat the process with an untrusted server.
After provisioning, rotate any initial credentials, check that the configuration matches your template, and put the device under normal monitoring.
How to check or apply this
- List which devices in your environment use ZTP and which protocols they use for the first fetch.
- Check whether your devices support signed bootstrap data and ownership vouchers.
- Enable the secure option wherever it is available, and avoid unauthenticated transfer for configuration.
- Provision on a controlled network, with DHCP snooping enabled.
- Compare the final configuration to your template and alert on drift.
- Record each device's serial number at order and at install.
- Reset default credentials during the first configuration, not later.
Quick check
Is ZTP the same as a vendor's cloud management?
Not exactly. ZTP is the first boot process. Many vendors pair it with a cloud management service, and those services may use their own methods for trust.
Can ZTP be used for servers?
The pattern exists for servers through network boot and automated installation, but RFC 8572 is aimed at network devices.
Sources
- RFC 8572, Secure Zero Touch Provisioning (SZTP)
- RFC 8995, Bootstrapping Remote Secure Key Infrastructure (BRSKI)
Last reviewed: 18 October 2026.
