Every connected device has to receive its first credentials somehow, and in most fleets that moment is a technician typing a password, a shared factory secret or a QR code that anyone in the supply chain could copy. FIDO Device Onboard (FDO) is the FIDO Alliance's open protocol for zero-touch onboarding: a device built months earlier, with no knowledge of its eventual owner, powers on, finds its owner through a rendezvous service, proves its identity and receives owner-specific credentials and configuration. This guide explains how FDO works (Device Initialize, the Ownership Voucher and the TO0, TO1 and TO2 protocols), what it protects and what it leaves to you, and how to deploy it across a manufacturing and supply chain. It is for IoT platform architects, OEM security teams and operators of edge and server fleets. For the wider picture of fleet identity, see the Identity for IoT Fleets Guide.
Key takeaways
- FDO separates manufacture from ownership: late binding lets one device image ship to any customer, who claims it with an Ownership Voucher rather than a pre-installed secret.
- The Ownership Voucher is the chain of custody: a COSE-signed document, extended with a signed entry at each hand-off, whose last entry names the key of the current owner.
- The device only ever connects outbound: it asks a rendezvous server where its owner is, then runs TO2 with the owner to authenticate both ways and receive new credentials.
- FDO is the bootstrap, not the whole identity: it delivers whatever the owner sends in ServiceInfo, typically certificates or enrolment tokens for the platform the device will live on.
- The weak points are operational: voucher handling across distributors, the factory DI step, rendezvous configuration and the content of ServiceInfo payloads.
What FDO is and where it sits
FDO 1.1 is a FIDO Alliance Proposed Standard dated 19 April 2022, with editors from Intel, Amazon, Google, Microsoft, Qualcomm and Arm. FIDO also lists an FDO 2.0 Review Draft, a Review Draft on securing FDO credentials in a TPM, Path Verification for FDO (PV4FDO) 1.0 as a Proposed Standard, and app notes on topics including ownership voucher double extension, error codes and security considerations, multi-tenancy and KDF strength (status as listed on the FIDO site, checked 27 October 2026; drafts may change). FDO is unrelated to FIDO2 user authentication apart from the name: it authenticates devices and owners, not people.
- Use cases named by FIDO: IoT and edge nodes, data centre servers, bare metal onboarding that installs an operating system without human intervention, UEFI-embedded FDO clients and closed networks using a local rendezvous server.
- Certification: the FDO certification programme tests FDO-enabled devices, onboarding services and rendezvous servers for compliance and interoperability.
- Software: FIDO does not ship an implementation. Open-source implementations exist in Go, Rust and C, many under the LF Edge FDO project.
Roles and objects
| Entity or object | What it is | What it holds or does |
|---|
| Manufacturer | Builds the device and runs Device Initialize (DI) | Installs the device credential and creates the initial Ownership Voucher |
| Device | Restricted Operating Environment running the FDO client, plus a Management Agent | DeviceCredential: HMAC secret, GUID, rendezvous info, hash of the manufacturer public key, active flag; attestation key |
| Ownership Voucher | COSE-signed header plus a chain of entries | Binds the GUID, device info and manufacturer key hash; each entry signs over to the next owner's key |
| Rendezvous Server | Lookup service the device contacts first | Maps a device GUID to the owner's address blob; trusted only for that mapping |
| Owner Onboarding Service | Runs TO0 and TO2 for the owner | Holds the Owner Key matching the last voucher entry |
| Management Service | The platform that manages the device afterwards | Supplies ServiceInfo content and takes over after onboarding |
The protocol step by step
- Device Initialize (DI), in the factory: non-normative and based on trust on first use. The device receives its GUID, rendezvous information and the manufacturer key hash, generates or receives its HMAC secret, and returns an HMAC over the voucher header (messages 10 to 13). The manufacturer creates the Ownership Voucher.
- Supply chain transfer: each party that sells the device on extends the voucher with an entry signed by its own key and naming the next owner's public key. The device is not involved and the voucher is never stored on it.
- TO0, owner registers: the owner presents the voucher to the rendezvous server and registers where the device should find it (messages 20 to 23).
- TO1, device looks up its owner: on first boot the device contacts the rendezvous server, proves it holds the credential for its GUID and receives the owner's address (messages 30 to 33).
- TO2, mutual authentication and transfer: the device connects to the owner, the owner proves the voucher chain and possession of the Owner Key, the device proves its identity with an attestation, they agree a session key and exchange ServiceInfo, and the device replaces its GUID and onboarding credentials (messages 60 to 71).
- Hand-off to management: the Management Agent uses what it received (certificates, enrolment tokens, configuration) to join the owner's platform. The device credential is marked inactive unless ServiceInfo asks to keep it active for later re-onboarding.
Cryptography and encodings
| Area | FDO 1.1 options | Practical note |
|---|
| Device attestation | Entity Attestation Token in COSE_Sign1; ECDSA P-256 or P-384 with X.509 or X5CHAIN; Intel EPID 1.0 and 1.1 | EPID gives group attestation that limits device correlation; ECDSA keys should live in a TPM or secure element |
| Voucher signatures | RSA 2048 and 3072, ECDSA P-256 and P-384 | Match strengths: the weakest parameter sets the overall strength |
| Voucher HMAC | HMAC-SHA256 (256-bit secret) or HMAC-SHA384 (512-bit secret) | Proves the device was not re-initialised since the voucher was made |
| TO2 key exchange | ECDH256, ECDH384, DHKEXid14, DHKEXid15, ASYMKEX2048, ASYMKEX3072 | Prefer ECDH384 where the device supports it |
| Session protection | AES-GCM or AES-CCM, or AES with HMAC-SHA256 or HMAC-SHA384 | ServiceInfo travels inside this channel |
| Encoding | CBOR (RFC 8949) deterministic encoding, COSE, CDDL schemas | Indefinite-length CBOR is prohibited; parsers are a classic bug source |
| Transport | Rendezvous and Owner support HTTP and HTTPS; device supports one; other transports allowed | FDO protects messages itself, but use HTTPS where possible for metadata privacy |
What FDO protects, and what it leaves to you
- Protected: a stolen voucher is useless without the Owner Key; a device will only accept an owner whose voucher chains back to its own manufacturer key hash; a rendezvous server cannot impersonate the owner; ServiceInfo is encrypted and integrity protected in transit.
- Factory trust: DI is trust on first use. If the factory station or the voucher signing key is compromised, the attacker can mint vouchers for real devices. The spec says the HMAC secret should be generated inside the device, and if generated externally all copies must be destroyed.
- Credential storage: only the HMAC secret needs confidentiality, but the whole DeviceCredential must be protected from modification. FIDO's TPM draft addresses storing it in a TPM.
- Voucher custody: the voucher is the legal and technical title. Losing it strands devices; mishandling extensions has its own app note on double extension.
- ServiceInfo content: FDO delivers it faithfully. If the owner service sends a weak shared password or an unsigned script, FDO cannot help. ServiceInfo can carry executables such as installation scripts, so treat the owner service as a high-value code distribution point.
- Privacy: the spec relies on random GUIDs, rendezvous servers that only store GUID mappings and optional group attestation to limit tracking.
Threats and the controls that answer them
| Threat | FDO mechanism | Control you must add |
|---|
| Device diverted to an attacker's platform in transit | Device accepts only an owner proving the voucher chain and Owner Key | Authenticated voucher delivery and chain verification at intake |
| Counterfeit or cloned device joins your fleet | Device attestation in TO2 with ECDSA or EPID | Allowlist expected manufacturer keys and device models; hardware-protected attestation keys |
| Rogue rendezvous server | Rendezvous only maps GUID to address; owner still authenticated in TO2 | Pin rendezvous addresses at DI; use a local rendezvous server on closed networks |
| Interception of configuration | Encrypted, integrity-protected TO2 session | No shared secrets in ServiceInfo; sign scripts and packages |
| Factory insider mints vouchers | None beyond the DI trust assumption | HSM for voucher signing, dual control and DI audit logs |
| Re-onboarding by a later voucher holder | Active flag cleared after TO2 | Verify deactivation; define resale extension process |
Hardening the owner service
- Isolate it: the owner onboarding service holds the Owner Key and decides what code and credentials every new device receives. Run it as a separate, privileged service with its own administrators and change control.
- Limit ServiceInfo authors: only a release pipeline should be able to change ServiceInfo payloads, and payload versions should be logged per device.
- Multi-tenant care: FIDO publishes an app note on multi-tenancy; if one owner service onboards for several customers, keep vouchers, keys and payloads separated per tenant.
How FDO fits with other device identity standards
| Mechanism | What it does | Relationship to FDO |
|---|
| TPM or DICE device identity | Hardware-rooted keys and attestation | Can hold the FDO attestation key and credential; see the IoT Device Identity with TPM and DICE Guide |
| EST or SCEP certificate enrolment | Issue operational certificates from your PKI | Commonly triggered after TO2 using a bootstrap token delivered in ServiceInfo; see the IoT and Device Certificate Provisioning Guide |
| Matter device attestation | Consumer smart home commissioning with a device attestation certificate | Different ecosystem and trust model; see the Matter Device Attestation and Security Guide |
| Cloud provider fleet provisioning | Claim certificates or registration tokens for a single platform | FDO keeps the choice of platform open until the owner claims the device |
Decision guidance
- Choose FDO when: devices ship through distributors to many customers, the owning platform is not known at manufacture, devices are installed by non-specialists, or the same hardware may be resold and re-onboarded.
- A single-cloud claim flow may be enough when: you make and operate the devices yourself and will only ever connect them to one platform.
- Small operators: buy FDO-certified devices and use a hosted or open-source owner service; your main job is voucher intake and ServiceInfo content.
- Large OEMs and operators: run DI with hardware-protected signing keys, integrate voucher extension with order systems, host or contract rendezvous services and certify your onboarding service.
Where identity fits
A device is a non-human identity from the moment DI runs, and FDO is its credential issuance process. Treat the manufacturer voucher signing key, the Owner Key and the owner service credentials as tier-zero secrets: hardware protection, named custodians and rotation plans. Record each device's GUID, voucher chain and post-onboarding credentials in your inventory so lifecycle events (resale, decommission, compromise) can be traced. See the Device and IoT Identity Guide.
How to implement
- Specify FDO in procurement: require FDO 1.1 support, FDO certification where available, hardware-protected attestation keys and voucher delivery with each order.
- Set up voucher intake: receive vouchers through an authenticated channel from the supplier, verify the chain to the manufacturer key you expect, and store them in the owner service with access control and backups.
- Stand up the owner service and rendezvous: protect the Owner Key in an HSM, run TO0 for received vouchers, and choose a public or local rendezvous service.
- Design ServiceInfo: deliver per-device bootstrap material only (a one-time enrolment token or certificate request instruction), signed payloads and no shared secrets.
- Pilot: onboard a small batch on an isolated network with a local rendezvous server, confirm every device lands in the right tenant and that DI credentials are deactivated, then widen.
- Plan reset and resale: decide how devices are re-onboarded after repair or resale and how vouchers are extended to the next owner. Rollback for a failed onboarding is a device reset to the FDO state with the credential still active.
Detection and measurement
- Log: TO0 registrations, TO1 lookups by GUID, TO2 successes and failures with error codes, voucher intake and extension events, ServiceInfo payload versions delivered.
- Alert on: TO2 attempts for GUIDs you do not own, repeated TO2 failures from one device, vouchers whose chain does not match the expected manufacturer, devices that keep an active onboarding credential after TO2.
- Metrics: share of new devices onboarded zero-touch; median time from power-on to managed; share of vouchers verified at intake; devices with operational credentials issued per device rather than shared; onboarding failure rate by supplier.
Framework mapping
| Framework | Reference | FDO relevance |
|---|
| NIST SP 800-53 Rev 5 | IA-3 Device Identification and Authentication | Device attestation in TO1 and TO2 |
| NIST SP 800-53 Rev 5 | SR-4 Provenance, SR-11 Component Authenticity | Ownership Voucher chain of custody |
| NIST SP 800-53 Rev 5 | SC-12, SC-8 | Owner and manufacturer keys; protected ServiceInfo channel |
| NIST SP 800-53 Rev 5 | CM-8 System Component Inventory | GUID and voucher records per device |
| NIST CSF 2.0 | PR.AA-01, PR.AA-03, ID.AM-01, GV.SC-04 | Device credentials, authentication, hardware inventory, supplier criticality |
| MITRE ATT&CK | T1195.003 Compromise Hardware Supply Chain, T1557 Adversary-in-the-Middle | Threats the voucher chain and mutual authentication address |
Common failure patterns
- Voucher signing key on a factory PC: a compromised DI station lets an attacker create valid vouchers and claim devices.
- Vouchers emailed as attachments: no integrity check at intake, so a substituted voucher sends devices to the wrong owner.
- Shared secrets in ServiceInfo: every device receives the same platform password, undoing the per-device identity FDO established.
- Onboarding credential left active: devices can be re-onboarded by whoever obtains a voucher later.
- Unverified CBOR parsers: custom device clients with fragile parsing become a remote attack surface before the device is even managed.
- No plan for resale or RMA: devices returned for repair cannot be re-onboarded, so technicians fall back to manual credentials.
Practitioner checklist
- Require FDO 1.1 support and certification in device procurement.
- Protect manufacturer and Owner Keys in HSMs with named custodians.
- Verify every voucher chain at intake against the expected manufacturer key.
- Use per-device bootstrap material in ServiceInfo, never shared secrets.
- Store FDO credentials in a TPM or secure element where hardware allows.
- Confirm the onboarding credential is deactivated after TO2 unless re-onboarding is planned.
- Log TO0, TO1 and TO2 events and alert on unknown GUIDs and repeated failures.
- Define reset, resale and RMA procedures before the first deployment.
Standards and references
Related NHI Mgmt Group resources: Identity for IoT Fleets Guide · IoT Device Onboarding Guide · IoT Device Identity with TPM and DICE Guide · IoT and Device Certificate Provisioning Guide