FIDO Device Onboard Zero-Touch IoT Provisioning: Implementation Guide

FIDO Device Onboard has four components: the Device, the Manufacturer Service, the Rendezvous Server, and the Device Onboard Service (owner's server).

Manufacturing phase:

1. The device manufacturer generates a unique key pair for each device at manufacturing time and stores the private key in a hardware root of trust (TPM, secure element, or trusted execution environment).
2. The manufacturer creates an ownership voucher -- a signed data structure that records the device's identity and initial owner (the manufacturer).
3. The voucher is transferred through the supply chain (manufacturer to distributor to reseller) cryptographically: each transfer extends the voucher with the new owner's public key.
4. The final owner (the organization deploying the device) receives the ownership voucher and registers it with their Device Onboard Service.

First boot phase:

1. The device powers on and contacts the Rendezvous Server at a URL pre-programmed at manufacturing time.
2. The device authenticates to the Rendezvous Server using its device key.
3. The Rendezvous Server looks up the device in its registry and redirects it to the final owner's Device Onboard Service.
4. The device connects to the Device Onboard Service and proves ownership of the device key.
5. The Device Onboard Service validates the ownership voucher chain and delivers the device's final configuration: network credentials, certificates, cloud enrollment tokens, or any other configuration the owner pre-staged.
6. The device is now provisioned and joins the operational fleet.

No human interaction is required after the ownership voucher is registered. No default credentials are transmitted. The device has never known its production credentials before provisioning -- they are only received after cryptographic authentication.

FDO's security guarantees depend on the device key being stored in a hardware root of trust that cannot be extracted. The options, in order of security strength:

TPM 2.0: Provides hardware key storage with key non-exportability guarantees. TPM 2.0 is available in many commercial IoT gateways and industrial controllers. FDO's reference implementation supports TPM 2.0 as the device key store.

Secure element: A dedicated cryptographic processor (for example, an NXP SE050 or Microchip ATECC608) that stores keys and performs cryptographic operations without exposing key material. Common in constrained devices where a full TPM is too large or power-intensive.

Trusted Execution Environment (TEE): Software-based isolation (ARM TrustZone, Intel TDX) that isolates the device key in a protected execution environment. Weaker than dedicated hardware but stronger than general-purpose software key storage.

Software key store (not recommended for production): Keys stored in encrypted files on the device filesystem. The FDO reference implementation supports this for development and testing. Not recommended for production because encrypted keys are still extractable if the device is physically compromised.

Procurement consideration: To use FDO at scale, devices must have hardware root of trust capability built in at manufacturing time. For new device procurement, specify TPM 2.0 or secure element as a requirement. For existing device fleets without hardware root of trust, FDO cannot be applied retroactively.

The Device Onboard Service (DOS) is the owner-operated component that receives devices on first boot and delivers their configuration. Implementation steps:

Step 1 -- Choose a DOS implementation:

• Intel FDO Reference Implementation (open-source): Available on GitHub (secure-device-onboard). Requires Java runtime; supports REST API for voucher management and device service configuration.
• Red Hat FDO: Included in RHEL for Edge; integrates with Ignition for Linux system configuration delivery.
• Commercial implementations: Several IoT platform vendors (Azure IoT Hub, AWS IoT Core) have published FDO integration paths or native FDO support roadmaps.

Step 2 -- Register the Rendezvous Server: The FIDO Alliance operates a public Rendezvous Server for FDO. Organizations can also run a private Rendezvous Server. For air-gapped or high-security environments, a private Rendezvous Server eliminates the dependency on the public FIDO Alliance infrastructure.

Step 3 -- Configure service info modules: FDO's Service Info protocol allows the DOS to deliver configuration to the device as part of onboarding. Standard service info modules include:

• SSH key installation
• TLS certificate installation
• Arbitrary command execution (for running provisioning scripts)
• File transfer (for delivering configuration files)

Step 4 -- Ownership voucher management: Establish a voucher management process: how vouchers are received from the device manufacturer, stored securely, assigned to specific DOS instances, and retired when devices are decommissioned.

Step 5 -- Test the provisioning flow: Before deploying to production, test the full provisioning flow: manufacturing, voucher transfer, device first boot, DOS delivery of configuration, and device operational verification. FDO provides no retry mechanism for failed provisioning -- a device that fails provisioning on first boot may require manual recovery.

FDO's primary operational security improvement is the elimination of default credentials. The security improvement compared to manual provisioning:

Before FDO (manual provisioning):

1. Device ships with a default username and password
2. Technician receives the device, connects to it using default credentials
3. Technician sets a new credential, records it in a credential management system
4. Device is deployed

Problems with manual provisioning at scale:

• Default credential exposure window: the device is reachable via default credentials from manufacturing to provisioning
• Credential management system risk: all device credentials are stored in a central system that becomes a high-value attack target
• Operational error: at scale, some percentage of devices will not have their default credentials changed, creating permanent attack surface

After FDO:

1. Device ships with a device key (no network credentials)
2. Ownership voucher is registered in the DOS
3. Device powers on, authenticates via device key, receives production credentials
4. Production credentials are never stored in a central system -- they are provisioned directly to each device

Security improvement measurement: Measure the reduction in attack surface by tracking:

• Number of devices with default credentials active (should be zero after FDO rollout)
• Mean time from device power-on to production credential delivery (FDO target: under 5 minutes)
• Number of provisioning failures requiring manual intervention (should be under 1%)

FDO integration with cloud IoT platforms allows devices to be automatically enrolled in cloud management after FDO provisioning:

AWS IoT Core: AWS IoT Core supports just-in-time provisioning (JITP) and fleet provisioning that can be triggered by FDO service info module delivery. The FDO DOS can deliver an AWS IoT fleet provisioning claim certificate, which the device uses to authenticate to AWS IoT Core and receive its final X.509 certificate. This eliminates the need to pre-register device certificates in AWS IoT Core.

Azure IoT Hub: Azure Device Provisioning Service (DPS) supports X.509 certificate-based attestation. The FDO DOS can deliver a DPS enrollment certificate to the device during provisioning, allowing it to self-enroll in Azure IoT Hub without pre-registration.

Red Hat Device Edge: Red Hat FDO is natively integrated with RHEL for Edge's provisioning pipeline. FDO triggers an Ignition configuration delivery that enrolls the device in Red Hat Insights and configures the base OS.

Integration pattern: For all cloud IoT platforms, the FDO integration pattern is the same: the DOS delivers a bootstrap credential (a temporary certificate or token) during FDO provisioning, the device uses it to self-enroll in the cloud platform, and the cloud platform issues the production credential. This avoids storing production credentials in the DOS.

FDO provisioning infrastructure requires its own operational security controls:

Rendezvous Server protection: If using a private Rendezvous Server, it must be highly available (devices contact it on first boot and cannot provision without it) and protected against denial-of-service attacks. The public FIDO Alliance Rendezvous Server eliminates operational burden but creates a dependency on external infrastructure.

DOS access control: The Device Onboard Service must be accessible to devices on first boot but should not be accessible to general internet traffic. Use network controls (IP allowlisting, cloud provider security groups) to restrict DOS access to expected device networks.

Ownership voucher security: Ownership vouchers are the cryptographic root of device identity. A stolen voucher allows an adversary to register as the owner of the corresponding device before the legitimate owner does. Store vouchers in a secrets management system (HashiCorp Vault, AWS Secrets Manager) with access logging.

Decommissioning: When a device is decommissioned, retire its ownership voucher and revoke its production credentials through the cloud IoT platform. FDO does not provide a device-side credential revocation mechanism -- revocation must be handled at the cloud platform layer.