Network Zero-Touch Provisioning Security Guide: Trusting Routers and Switches on First Boot

Zero-touch provisioning lets a factory-fresh router or switch configure itself from the network, which means the first thing it trusts is whatever answers its DHCP request. Classic DHCP-driven ZTP hands a device a file server address and a filename, then the device fetches an image, a configuration or a script, often over TFTP or plain HTTP, and runs it. Anyone who can answer on that segment, or who controls the file server, decides what the device becomes. This guide explains the trust problem in first-boot provisioning, compares classic ZTP with Secure Zero Touch Provisioning (SZTP, RFC 8572) and BRSKI (RFC 8995), and sets out how to secure the provisioning network, servers, artefacts and credentials. It is written for network engineers, automation teams and security architects who roll out network devices at scale. Certificate enrolment protocols are covered in the IoT and Device Certificate Provisioning (EST, SCEP) Guide, and server PXE boot in the Bare-Metal Provisioning and PXE Boot Security Guide.

Key takeaways

• Classic ZTP trusts the network by default. A DHCP reply chooses the file server and the file, and transfer can be TFTP, FTP or HTTP, so rogue DHCP (ATT&CK T1557.003) or a compromised file server owns the device from its first boot.
• SZTP moves trust from the network to signatures. Under RFC 8572 a device processes onboarding information from an untrusted source only if it is signed by an owner certificate that chains to a manufacturer-signed ownership voucher.
• BRSKI gives mutual authentication and a local certificate. The device proves itself with its IEEE 802.1AR IDevID, a manufacturer authority vouches for your registrar, and the device then enrols for a locally issued LDevID over EST.
• The provisioning server is tier zero for your network. It holds configurations, images, scripts and often credentials for every new device, so it needs the protection of a privileged system.
• Provisioning ends with hand-off. Disable ZTP or provisioning features after onboarding, rotate any bootstrap secrets, and verify the running configuration and image against the intended state.

How classic ZTP works and where it is exposed

Each vendor implements ZTP differently, but the pattern is consistent. Juniper's documentation, for example, describes a device with a factory-default configuration obtaining an address from DHCP, reading ZTP parameters from the reply, fetching and installing a software image and a configuration or script, and finishing when the configuration commits. Its DHCPv4 parameters use option 43 sub-options for the image filename, the configuration or script filename and the transfer mode (TFTP, FTP, HTTP or HTTPS), and option 150 or 66 for the file server address. A configuration file whose first line names an interpreter is run as a script. Other vendors use similar DHCP options, vendor cloud redirect services or USB.

The last row is not theoretical. The CISA-led joint guidance Enhanced Visibility and Hardening Guidance for Communications Infrastructure (3 December 2024) tells operators to disable unauthenticated management functions such as Cisco Smart Install, a legacy zero-touch feature for switches, with no vstack.

Secure Zero Touch Provisioning (SZTP, RFC 8572)

RFC 8572 (Standards Track, April 2019) defines how a device bootstraps itself using data that can be verified even when it arrives over an untrusted path. The device iterates over sources of bootstrapping data: removable storage, DNS records, DHCP (which can carry only unsigned redirect information) and bootstrap servers reached over RESTCONF. A source returns either redirect information, pointing to another bootstrap server, or onboarding information, which can set a boot image with hash values, a configuration, and pre- and post-configuration scripts.

Three artefacts carry the trust:

• Ownership voucher: signed by the manufacturer in the RFC 8366 format, binding the device serial number to a pinned domain certificate that anchors the owner's certificate.
• Owner certificate: identifies the owner and verifies the signature over the conveyed information.
• Conveyed information: the redirect or onboarding data in a CMS structure, signed by the owner and optionally encrypted to the device's identity certificate so only that device can read it.

The key rule is that unsigned onboarding information is never processed unless it comes from a source the device already trusts. Unsigned redirect information from an untrusted source may be followed provisionally, but the device then demands signed data from the next server. RFC 8572 also lists the residual risks: devices need an accurate clock to check voucher and certificate validity, and NTP is not considered secure for this; the TLS client certificate reveals at least the device serial number to any server it contacts; trust delivered in one redirect cascades to every later step; conveyed information has no built-in validity period and vouchers cannot be revoked, so a unique owner certificate per artefact is recommended; and IDevID private keys should be held in secure storage such as a TPM, with bootstrap server signing keys ideally in an HSM.

BRSKI and voucher-based onboarding (RFC 8995)

BRSKI, Bootstrapping Remote Secure Key Infrastructure (Standards Track, May 2021), solves the same first-contact problem with mutual authentication and ends with the device holding an operator-issued certificate.

1. The new device (the pledge) discovers a join proxy and the domain registrar.
2. It opens TLS to the registrar using its manufacturer-installed IEEE 802.1AR IDevID, accepting the registrar's certificate only provisionally.
3. It sends a voucher request, normally including a nonce, which the registrar checks and forwards to the manufacturer's MASA (Manufacturer Authorized Signing Authority).
4. The MASA returns a signed voucher naming the registrar; the registrar decides whether to accept the device and passes the voucher on.
5. The pledge validates the voucher, completes authentication of the registrar and reports status.
6. Over the now-authenticated connection, it enrols for a locally issued LDevID certificate using EST (RFC 7030).

Nonced vouchers prove freshness; nonceless vouchers can be obtained in advance for sites that cannot reach the MASA, at the cost of depending on clocks or long validity. The MASA keeps an anonymised audit log of the device's previous owners, which the registrar can check before accepting a second-hand or returned device. The trade-offs are dependence on the manufacturer's MASA being available and the manufacturer learning which domain claimed which device.

For IoT fleets, the NCCoE's NIST SP 1800-36 (final, November 2025) describes the same idea as trusted network-layer onboarding: the device and network verify each other's identity and posture before the device receives network credentials. See also the FIDO Device Onboard Guide and the IoT Device Onboarding Guide.

Choosing an approach

Small organisations that receive a handful of devices a year gain little from building SZTP; staging on an isolated bench with verified images and then shipping is simpler and safer. Large and multi-site organisations should require SZTP or an equivalent signed-data mechanism in procurement, because classic ZTP across branch networks they do not fully control cannot be made trustworthy.

Securing the provisioning infrastructure

• Provisioning network: run onboarding in a dedicated VLAN or VRF with DHCP snooping, only your DHCP servers or relays trusted, and no route to production until the device is verified. See the Layer 2 Attacks Guide for DHCP and ARP protections.
• File and bootstrap servers: serve over HTTPS only, disable TFTP and anonymous FTP, restrict write access to the pipeline that generates artefacts, and log every download with the requesting serial number.
• Images: fetch from the vendor, verify hashes against vendor-published values (the CISA joint guidance asks operators to verify image integrity this way), and enforce platform image signing where available. See the Firmware and Boot Security Guide.
• Configurations and scripts: generate from source control through the same review as other infrastructure code; keep scripts minimal, and prefer signed onboarding information where the platform supports SZTP.
• Signing keys: protect owner and bootstrap signing keys in an HSM, as RFC 8572 suggests, and keep a separate owner certificate per artefact or batch so one can be revoked.
• Inventory binding: accept only serial numbers on an expected-device list tied to purchase orders, and alert on requests from unknown serials.

Where identity fits: bootstrap credentials and device certificates

Provisioning is where a network device receives its first credentials, so it is where non-human identity mistakes are made at scale:

• Bootstrap configurations often contain secrets: local admin hashes, TACACS+ or RADIUS keys, SNMPv3 credentials and routing keys. Inject them from a secrets manager at generation time, encrypt onboarding information to the device where supported, and never leave them in world-readable file server directories. See the Secrets Management Guide.
• Replace bootstrap credentials after hand-off: any shared or temporary credential used during onboarding should be rotated once the device is under normal management.
• Use device certificates for ongoing trust: the IDevID proves manufacturer identity; an LDevID issued by your CA proves membership of your network and should be used for management and network access afterwards. See the Enterprise PKI Design and CA Hierarchy Guide.
• Protect automation accounts: the pipeline and service accounts that write to bootstrap servers can reconfigure every new device; treat them as privileged non-human identities. See the Network Device Management Plane Hardening Guide.

Implementation steps

1. Inventory current provisioning: list every method in use (ZTP, vendor cloud, USB, manual), the servers and DHCP scopes involved, and which device models support HTTPS validation, SZTP or BRSKI.
2. Isolate and harden first: move onboarding into a dedicated segment with DHCP snooping, switch file servers to HTTPS, and remove TFTP. This needs no device changes.
3. Remove secrets from static files: generate per-device configurations on request with secrets injected, and rotate any secrets that have been sitting on file servers.
4. Add verification after boot: before routing the device into production, compare its image hash and running configuration with the intended state, and quarantine on mismatch.
5. Pilot SZTP or BRSKI: start with one device family and one site; obtain ownership vouchers from the vendor, stand up owner certificates in your PKI, and test failure modes such as clock errors and unreachable servers.
6. Roll out and set procurement requirements: require signed-data onboarding and IDevID support in new purchases.
7. Rollback path: keep a console-based manual staging procedure, with verified images, for devices that fail secure onboarding; never fall back to an open classic ZTP scope on a production segment.
8. Close the door: disable ZTP clients and legacy provisioning features after onboarding, and check for them in configuration compliance scans.

Detection and measurement

• DHCP: DHCP snooping violations and offers from unexpected servers on provisioning segments.
• Bootstrap and file servers: requests from unknown serial numbers, repeated failures, downloads outside rollout windows, and any change to served artefacts outside the pipeline.
• Devices: provisioning or ZTP processes starting on devices that are already in production, which may indicate a reset or tampering.
• Post-boot verification failures: image hash or configuration mismatches in quarantine.

Common failure patterns

• ZTP on the production access network: any device that boots with a default configuration, including one reset by an intruder, fetches whatever the local DHCP server offers.
• Static configuration files full of secrets: a file server directory holds every site's AAA key and SNMP credentials in plain text, readable by anything on the provisioning network. Harvested network device secrets are what made intrusions like the Salt Typhoon telecom intrusions so persistent.
• Provisioning features never disabled: legacy features such as Smart Install remain reachable long after deployment, which is why the CISA joint guidance calls them out.
• HTTPS without certificate validation: the transport is encrypted but the device accepts any server certificate.
• Clock and voucher surprises: devices without accurate time fail signed onboarding, and teams respond by turning validation off instead of fixing time or voucher validity.
• Second-hand or returned hardware accepted blindly: no check of the device's history or of whether it belongs to the expected purchase order.

Framework mapping

Practitioner checklist

• Inventory every provisioning method, DHCP scope and bootstrap server in use.
• Confine onboarding to an isolated provisioning segment with DHCP snooping and no production reachability.
• Serve images and configurations over validated HTTPS only, and remove TFTP and anonymous FTP.
• Generate per-device configurations with secrets injected from a secrets manager, and rotate bootstrap secrets after hand-off.
• Verify image hashes and running configuration before a device joins production.
• Require SZTP (RFC 8572), BRSKI (RFC 8995) or equivalent signed onboarding and IDevID support in procurement.
• Protect owner and bootstrap signing keys in an HSM and accept only expected serial numbers.
• Disable ZTP clients and legacy provisioning features such as Smart Install on managed devices.

Standards and references

• IETF: RFC 8572 Secure Zero Touch Provisioning (SZTP)
• IETF: RFC 8995 Bootstrapping Remote Secure Key Infrastructure (BRSKI)
• NIST: SP 1800-36 Trusted IoT Device Network-Layer Onboarding and Lifecycle Management
• CISA: Enhanced Visibility and Hardening Guidance for Communications Infrastructure
• Juniper Networks: Zero Touch Provisioning
• MITRE ATT&CK: DHCP Spoofing

Related NHI Mgmt Group resources: IoT and Device Certificate Provisioning (EST, SCEP) Guide · Network Device Management Plane Hardening Guide · FIDO Device Onboard Guide · Interior Routing Protocol Security Guide