Network boot hands a machine its first code before any operating system, endpoint agent or firewall exists on it, so whoever answers the DHCP request or serves the boot file decides what the machine becomes. Classic PXE relies on DHCP and TFTP, neither of which authenticates anything, and the deployment servers behind it often hold domain join credentials, image secrets and BMC passwords for the whole fleet. This guide covers the provisioning path from firmware network stack to first login: PXE, iPXE and UEFI HTTP(S) Boot, provisioning network design, image signing and Secure Boot, the credentials provisioning systems hold, and how to detect abuse. It is written for infrastructure, data centre and endpoint engineering teams running bare-metal fleets, OpenStack Ironic or similar platforms, MAAS, or Configuration Manager PXE. Sources were checked on 11 November 2026.
Key takeaways
- Classic PXE trusts the network. DHCP offers and TFTP downloads are unauthenticated, so a rogue DHCP or boot server on the same segment can serve any image (MITRE ATT&CK T1557.003 DHCP Spoofing, T1542.005 TFTP Boot).
- The firmware network stack is attack surface. The PixieFail flaws (CERT/CC VU#132380, nine CVEs in the EDK II NetworkPkg) were reachable only when PXE boot was enabled; CERT/CC advises disabling PXE where unused.
- Verify what boots, not just where it came from. Combine UEFI Secure Boot with signed boot loaders and kernels, and use HTTPS boot or iPXE
imgverifyso the image is authenticated as well as the transport. - Isolate the provisioning network. Keep PXE, TFTP, HTTP boot and ramdisk APIs on dedicated VLANs with DHCP snooping, and never enable PXE responders on untrusted or perimeter segments.
- Provisioning systems are credential vaults. Network access accounts, domain join accounts, BMC passwords and agent tokens give fleet-wide control; scope, rotate and monitor them like any privileged NHI.
How network boot works, and where trust is assumed
A bare-metal or freshly reimaged machine boots in a fixed sequence. Each step trusts the one before it unless you add verification.
| Step | Classic PXE | UEFI HTTP(S) Boot | Trust assumption |
|---|---|---|---|
| 1. Firmware network stack starts | UNDI and PXE base code in firmware; DHCP vendor class PXEClient | UEFI HTTP Boot driver; DHCP vendor class HTTPClient | Firmware is current and its network code is safe to run |
| 2. Address and boot server | DHCP offer with next-server and boot file name (options 66 and 67 or BOOTP fields) | DHCP offer with a boot URI; DNS lookup when the URI uses a name | The first DHCP responder is legitimate |
| 3. Network boot program download | TFTP (no authentication, no encryption) | HTTP, or HTTPS when TLS is available in firmware with a configured CA | The server and the path are authentic |
| 4. Boot loader and kernel | Chain to iPXE, shim and GRUB, or a vendor loader | NBP or RAM disk image | Secure Boot checks signatures if enabled |
| 5. Deployment ramdisk or installer | Fetches image, configuration and secrets from the provisioning service | Same | Ramdisk APIs accept only legitimate nodes |
| 6. First boot and enrolment | Domain join, configuration management, monitoring agents | Same | Credentials handed to the node are scoped and short lived |
The UEFI specification (section 24.7) defines HTTP Boot with option 60 set to HTTPClient, says TLS is used "if HTTPS functionality is needed", and allows the boot image to be a UEFI executable or a RAM disk. HTTPS boot authenticates the server through a CA certificate configured in firmware; iPXE documents that UEFI TlsCaCertificate entries are trusted by default. For the rest of the boot chain, see the Firmware and Boot Security Guide.
Threats to the provisioning path
| Threat | Example | Primary controls | ATT&CK |
|---|---|---|---|
| Rogue DHCP or boot server | A device on the build VLAN answers first and serves its own boot program | DHCP snooping, Dynamic ARP Inspection, isolated provisioning VLAN, Secure Boot | T1557.003 DHCP Spoofing |
| Tampered boot image | An attacker with write access to the TFTP or HTTP root replaces a kernel or initrd | Signed images with iPXE imgverify or Secure Boot, file integrity monitoring on the boot server | T1542.005 TFTP Boot, T1542 Pre-OS Boot |
| Firmware network stack exploit | PixieFail class bugs during PXE: remote code execution, denial of service, DNS cache poisoning, information leakage, session hijacking per CERT/CC | Firmware updates, disable PXE where unused, isolate preboot networks | T1542 Pre-OS Boot |
| Rogue client enrolment | An unknown machine PXE boots and becomes a trusted managed client | PXE password, unknown computer controls, NAC | T1200 Hardware Additions |
| Credential theft from deployment | Network access account or domain join password recovered from boot media, task sequences or ramdisk configuration | Remove shared accounts, password-protect media, short-lived tokens | T1078 Valid Accounts |
| Accidental wipe | A production server PXE boots into a deployment that reformats it | Respond only on provisioning interfaces, require approval for deployments | Availability risk |
CERT/CC's PixieFail note (first published 16 January 2024) lists CVE-2023-45229 to CVE-2023-45237 in the TianoCore EDK II network stack, with AMI, Insyde, Intel, Phoenix Technologies and Microsoft among vendors marked affected. Its mitigations are to update UEFI firmware, disable PXE boot if it is not used, isolate the preboot environment, use DHCP snooping and Dynamic ARP Inspection, and consider UEFI HTTPS Boot as a more secure alternative to legacy PXE.
Choosing a boot method
| Method | Transport security | Image authenticity | When to choose |
|---|---|---|---|
| Legacy BIOS PXE with TFTP | None | None unless the next stage verifies | Only for hardware that cannot do anything else, on an isolated VLAN |
| UEFI PXE with Secure Boot (shim and GRUB) | None (TFTP) | Signature checks by firmware and shim | General Linux fleets where HTTPS boot is not supported |
iPXE with HTTPS and imgverify | TLS with a trusted root you choose, optional client certificate | CMS signatures checked by iPXE when built with image trust | Large fleets, flexible scripting, where you can sign and build iPXE yourself |
| UEFI HTTPS Boot | TLS from firmware with a configured CA | Secure Boot checks the downloaded image | Modern hardware; removes TFTP entirely |
| Virtual media through the BMC | Depends on BMC protocol (Redfish over HTTPS) | Secure Boot | Small numbers of servers, remote sites without a build VLAN |
- iPXE and Secure Boot trade-off: OpenStack Ironic notes that network booting with Secure Boot is hard because iPXE is not signed by default; the options are signing your own iPXE (with your own key management) or using shim and GRUB, which has far fewer capabilities.
- iPXE trust settings: iPXE trusts only its own root, which cross-signs the Mozilla CA list, unless you build with
TRUST=your internal CA. Pin it to your internal CA for provisioning. If you embed a client certificate, iPXE stores the private key unencrypted in the binary, so treat the binary as confidential. - Small organisations: with a handful of servers, BMC virtual media and a signed installer ISO avoid running a PXE service at all. See the Server BMC Security guide.
- Large fleets: HTTPS boot or signed iPXE with Secure Boot on every node, with a provisioning service that issues per-node short-lived credentials.
Provisioning network design
- Dedicated VLANs: run DHCP for PXE only on provisioning and cleaning VLANs. Ironic advises blocking outside access to its BMC, provisioning, cleaning and rescue networks, and serving TFTP or HTTP boot files only to those internal networks because "TFTP has no per-user access control".
- Interface binding: Microsoft advises configuring PXE-enabled distribution points to respond only on specified interfaces, and never enabling PXE on a distribution point in an untrusted network such as a perimeter network.
- Layer 2 protection: enable DHCP snooping with trusted ports only toward the real DHCP and relay, plus Dynamic ARP Inspection, as CERT/CC recommends. See the DHCP Security Guide.
- Separate the BMC network: BMCs belong on the out-of-band network, not the build VLAN. Ironic recommends disabling in-band access from the host OS to the BMC. See the Out-of-Band Management Network Design Guide.
- Split API exposure: ramdisk callback APIs need to be reachable from nodes being provisioned but never from users. Ironic's three unauthenticated ramdisk endpoints (
GET /v1/lookup,POST /v1/heartbeat/{node_ident},POST /v1/continue_inspection) should be blocked from external networks, with[api] enable_ramdisk_endpoints = Falseon public API instances. - Disable PXE in firmware where unused: production servers that never reimage over the network should have network boot removed from the boot order, with boot order changes from the host OS blocked.
Image integrity and Secure Boot
- Build images in a controlled pipeline: produce kernels, initrds and installer images from a hardened build with recorded provenance. See the Server Build and Golden Image Hardening Guide.
- Sign every stage: boot loaders and kernels signed for Secure Boot (shim with your enrolled key or the distribution's chain), or CMS signatures checked by iPXE using
imgtrust --permanentandimgverify, so iPXE refuses to boot a file that fails verification. - Protect signing keys: keep them in an HSM or managed key service, separate from the boot servers. See the Linux Secure Boot and Shim Guide.
- Make the boot server read-only to most: only the pipeline writes to the TFTP or HTTP root; monitor file changes.
- Enforce Secure Boot per node: Ironic sets it through the
secure_bootcapability in UEFI mode and can enable it dynamically through Redfish; IPMI has no standard support, so behaviour may be unpredictable. - Track certificate changes: Secure Boot certificate rotations affect PXE and recovery media. See the Secure Boot Certificate Expiry 2026 guide.
Where identity fits
Provisioning systems hold some of the most powerful machine credentials in the estate, and they hand secrets to machines that cannot yet prove who they are.
| Credential | Risk | Control |
|---|---|---|
| Configuration Manager network access account | Shared identity: Microsoft notes clients using it effectively share the same identity | Enable Enhanced HTTP, which removes the need for it in several deployment scenarios; remove the account |
| Domain join and task sequence accounts | Recoverable from media or variables | Least privilege on target OUs only, password-protected boot media, rotation after each use window |
| BMC credentials held by the provisioning platform | Fleet-wide power and console control | Unique password per node (Ironic's advice), rotation with maintenance mode, vault storage |
| Ramdisk agent tokens | Node impersonation during deployment | Per-node tokens (Ironic issues agent_secret_token at lookup), network restriction of callback APIs |
| iPXE client certificates | Private key stored unencrypted in the binary | Treat binaries as secrets, short certificate lifetimes, revoke on leak |
Microsoft's OS deployment guidance also says to require a password for PXE boot, to "always assign a password" to bootable media, and, for unknown computer support, to restrict physical network access and monitor for unauthorised computers. See the Configuration Manager to Intune guide if you are moving away from PXE-based imaging.
Decommissioning and reprovisioning
Reprovisioning is when one tenant's data meets the next. Ironic can erase local disks when an instance is deleted ([conductor] automated_clean with a non-zero [deploy] erase_devices_priority), but its documentation is explicit that cleaning does not reset BIOS or reflash firmware, and that Ironic does not validate firmware integrity. Add custom clean steps for firmware checks, reset BIOS settings to a baseline, and follow sanitisation levels from the Media Sanitisation Guide when hardware leaves your control.
Implementation steps
- Inventory: list every DHCP scope with boot options, every PXE responder, TFTP and HTTP boot root, and every machine with network boot enabled in firmware.
- Patch firmware: apply vendor fixes for PixieFail and other network stack advisories; record firmware versions.
- Reduce: remove network boot from the boot order on servers that do not need it and delete stale boot options from DHCP scopes.
- Isolate: move remaining responders to provisioning VLANs, bind them to those interfaces, and turn on DHCP snooping and Dynamic ARP Inspection.
- Add verification in a pilot: enable Secure Boot and signed boot stages, or HTTPS boot, on one hardware model in a test rack; confirm deployment still succeeds and that an unsigned image is refused.
- Fix credentials: replace shared network access accounts, scope domain join rights, vault BMC passwords, set PXE and media passwords.
- Roll out by hardware generation: expand model by model; keep the previous signed boot chain available so a failed rollout can revert boot files without disabling Secure Boot.
- Rollback: if a firmware or Secure Boot change blocks provisioning, revert the boot file set and DHCP options to the last known good version, not to unauthenticated TFTP.
Detection and measurement
- Rogue DHCP: alert on DHCP snooping violations and on any DHCP offer containing boot options from an unauthorised server.
- Boot server integrity: monitor file changes in TFTP and HTTP boot roots and compare hashes with the pipeline's signed manifest.
- Deployments: log every PXE request, MAC address, image served and deployment approval; alert on unknown MACs on provisioning VLANs.
- Credentials: alert on use of domain join, network access and BMC accounts outside provisioning windows or from hosts other than the provisioning servers.
- Ramdisk APIs: alert on calls to lookup or heartbeat endpoints from outside provisioning networks.
Metrics:
- Percentage of servers with network boot disabled where not required.
- Percentage of network-booted nodes with Secure Boot enforced and signed boot stages.
- Number of PXE responders on non-provisioning segments (target zero).
- Percentage of firmware at versions fixed for known network stack advisories.
- Number of shared provisioning accounts remaining (target zero).
Common failure patterns
- PXE left on everywhere: network boot first in the boot order on production servers, so a reboot plus a rogue DHCP offer reimages them.
- Writable boot roots: TFTP directories writable by operations staff or other services, with no integrity monitoring.
- Secure Boot disabled to make iPXE work: teams turn off Secure Boot instead of signing their boot chain.
- Shared deployment accounts: one network access or domain join account in every task sequence and boot image, rarely rotated.
- Cleaning that is not cleaning: disks wiped between tenants but BIOS settings and firmware never checked.
- Perimeter PXE: a distribution point or PXE responder reachable from a lab or perimeter network.
Framework mapping
| Control area | NIST SP 800-53 Rev 5 | NIST CSF 2.0 | ISO/IEC 27001:2022 Annex A | CIS Controls v8.1 |
|---|---|---|---|---|
| Boot integrity and signed components | SI-7, SI-7(9), SI-7(15), CM-14 | PR.PS-02 | A.8.19 Installation of software on operational systems | Control 2 Inventory and Control of Software Assets |
| Provisioning network isolation | SC-7, AC-4 | PR.IR-01 | A.8.22 Segregation of networks | Control 12 Network Infrastructure Management |
| Baseline configuration and least functionality | CM-2, CM-7 | PR.PS-01 | A.8.9 Configuration management | Control 4 Secure Configuration |
| Device authentication | IA-3 | PR.AA-05 | A.8.20 Networks security | Control 1 Inventory and Control of Enterprise Assets |
| Firmware vulnerabilities | SI-7 | PR.PS-02 | A.8.8 Management of technical vulnerabilities | Control 7 Continuous Vulnerability Management |
| Monitoring | AU-2 | DE.CM-01 | A.8.16 Monitoring activities | Control 13 Network Monitoring and Defense |
Practitioner checklist
- Network boot is disabled in firmware on every server that does not need it.
- UEFI firmware is patched for PixieFail and later network stack advisories.
- PXE and HTTP boot responders run only on provisioning VLANs with DHCP snooping and Dynamic ARP Inspection.
- Every boot stage is signed and verified by Secure Boot or iPXE
imgverify; HTTPS boot is used where hardware supports it. - Boot roots are writable only by the build pipeline and monitored for changes.
- Shared network access accounts are removed; domain join, BMC and agent credentials are scoped, vaulted and rotated.
- PXE boot and boot media require passwords where the platform supports it.
- Ramdisk and callback APIs are unreachable from user and external networks.
- Reprovisioning includes disk sanitisation, BIOS baseline and firmware checks.
Standards and references
- UEFI Forum: UEFI Specification 2.10, Network Protocols (PXE and HTTP Boot)
- CERT/CC: VU#132380 PixieFail vulnerabilities in EDK II NetworkPkg
- OpenStack Ironic: Security overview
- Microsoft Learn: Security and privacy for OS deployment in Configuration Manager
- iPXE: Cryptography (HTTPS, trusted roots, code signing)
- MITRE ATT&CK: T1542.005 TFTP Boot
- MITRE ATT&CK: T1557.003 DHCP Spoofing
- NIST: SP 800-53 Rev 5 Security and Privacy Controls
Related NHI Mgmt Group resources: Firmware and Boot Security Guide · DHCP Security Guide · Server BMC Security · KVM-over-IP Security Guide · Firmware and Bootkit Compromise Playbook