FIDO Device Onboard (FDO): Zero-Touch IoT Device Onboarding, Ownership Vouchers and Rendezvous Servers (2026)

Most IoT fleets are born insecure for a boring reason: the factory does not know who will own the device. A gateway leaves the line before anyone has decided which cloud, which tenant or which customer it will serve, so vendors burn in a shared password, a shared claim certificate or a vendor-controlled cloud endpoint, and hope nobody notices. FIDO Device Onboard (FDO) is the standards-track answer to that problem. It lets a device be built with no knowledge of its eventual owner, ship through any number of distributors, and then bind to the right management platform on first power-up with no technician, no shared secret and no pre-staging.

It matters now because the specification moved. FDO 2.0 was published as a Proposed Standard by the FIDO Alliance on 2 April 2026, adding delegation, capability negotiation and room for post-quantum cryptography, while regulation such as the EU Cyber Resilience Act is pushing vendors away from default credentials. This post gives you the architecture, the voucher cryptography, the TO0/TO1/TO2 protocol walk-through, a comparison with cloud-native provisioning, and the failure modes that the brochures skip.

What this covers: the roles and trust model, how an ownership voucher works, the rendezvous and ownership-transfer protocols, TPM-backed device credentials, a decision matrix against AWS, Azure DPS, EST and BRSKI, and a hardening checklist.

Context and Background

Onboarding is the moment a device first acquires an identity it can use and a place to use it. Everything downstream, from mutual TLS to firmware signing to telemetry authorisation, assumes that moment went well. The industry has tried several ways to get it right, and each embeds a different assumption about who knows what at manufacturing time.

The first family is pre-provisioned identity. The factory injects a unique key pair and X.509 certificate into every unit, often through a hardware secure element. The cloud later recognises that certificate. AWS IoT calls this just-in-time provisioning or registration, where the certificate authority that signed the device certificate is registered with the service and the device is provisioned on first connection (AWS IoT device provisioning). Azure’s Device Provisioning Service accepts X.509, TPM or symmetric-key attestation (Azure DPS concepts). It works well, but the identity is anchored to a trust root the factory chose, and the device usually knows the target service in advance.

The second family is claim-based provisioning. Devices carry a shared, low-privilege claim credential and trade it at first boot for a unique one. AWS fleet provisioning by claim works this way. It is convenient for the manufacturer and weak against extraction: anyone who pulls the claim certificate from one unit can attempt to enrol imposters until the template or the account catches up.

The third family is network-assisted bootstrapping, standardised by the IETF. Enrollment over Secure Transport (EST, RFC 7030) lets a device obtain a certificate from a CA, and BRSKI (RFC 8995) adds a manufacturer-signed voucher so a local network can trust a new device. These work best in managed networks with a reachable manufacturer authorised signing service. We cover adjacent constrained-device mechanisms in CoAP, OSCORE and EDHOC.

FDO sits in a different spot. Its design goal, in the FIDO Alliance’s own words, is late binding: the ability for the owner to choose the IoT platform at a late stage in the device life cycle. The FIDO Alliance describes FDO as an automatic onboarding protocol that securely installs secrets and configuration so devices can connect to cloud and edge management platforms, and runs a certification programme covering devices, onboarding services and rendezvous servers (FIDO Alliance device onboarding overview). The lineage is worth knowing: FDO grew out of Intel’s Secure Device Onboard, which became an LF Edge project and was renamed to FIDO Device Onboard when it moved into the FIDO Alliance.

One caution on scope. FDO is an onboarding protocol. It does not replace your device management protocol, your PKI or your telemetry transport. It delivers a device to your management plane with credentials in hand, then steps out of the way. If you want the surrounding picture of how a platform consumes newly onboarded devices, our ThingsBoard device provisioning tutorial shows the platform side of the handoff.

The FDO Reference Architecture

Direct answer: FDO separates three questions that other schemes bundle together. Who made the device (a manufacturer-signed ownership voucher), who owns it now (the last key in the voucher chain) and where is that owner (a rendezvous server that maps the device GUID to an address). The device proves itself to the owner directly, and the owner then pushes credentials and configuration.

Figure 1: FIDO Device Onboard roles and the flow of the ownership voucher, TO0 registration, TO1 lookup and TO2 transfer.

The figure traces two parallel journeys. The voucher travels along the supply chain, passing from manufacturer to distributor to owner, each hand-off adding a signed entry. The device travels separately and knows only a GUID and the address of a rendezvous server. They meet on the owner’s onboarding service at first boot.

The roles

The specification defines a compact set of roles (FDO 2.0 Proposed Standard).

• Manufacturer. Runs Device Initialize (DI), which generates the device identity, loads credentials and creates the initial ownership voucher.
• Device. Holds the device credential inside a restricted operating environment (ROE). The ROE is the protected piece of the device, ideally backed by a TPM or secure element, that runs the FDO client.
• Owner and Owner Onboarding Service. The party that holds the final key in the voucher and runs the TO2 server. The onboarding service is the machine that executes the protocols on the owner’s behalf.
• Rendezvous (RV) server. A directory that maps device GUIDs to owner addresses. It is trusted to remember a mapping and nothing else.
• Manager and Management Agent. The post-onboarding management service and its device-side counterpart, which talk through the ServiceInfo mechanism.
• Delegate Owner (new in 2.0). A subsidiary owner site authorised by a certificate signed by the Owner, without extending the voucher.

Notice what is absent: there is no central FIDO cloud. The Alliance does not run an FDO service; it publishes specs and certifies products, and the open-source implementations are hosted by the Linux Foundation’s LF Edge in Go, Rust and C. That decentralisation is a deliberate property. It also means you operate the pieces, and operating a rendezvous server badly is a real way to fail.

Why a voucher rather than a certificate

A conventional device certificate says “this unit was made by X”. It carries no notion of change of ownership. An ownership voucher does. It is a chain of signed public keys where each entry authorises the holder of the next key to take ownership or pass it along. The device stores only a hash of the manufacturer’s public key at manufacture time, and everything else is verified against that anchor during onboarding.

This gives FDO a property that certificate-only schemes lack: ownership is transferable and auditable offline. A reseller can extend a voucher to a customer by signing one more entry, with no round trip to the manufacturer and no change to the device. The extension is a pure data operation. We unpack the cryptography in the next section.

Three protocols, three jobs

FDO’s wire protocols are named for their purpose: TO0 (the owner registers with the rendezvous server), TO1 (the device asks the rendezvous server where its owner is) and TO2 (the device and owner transfer ownership and the owner provisions the device). The preceding DI protocol runs once at the factory and is non-normative in the spec, because manufacturing lines vary. Messages are encoded as deterministic CBOR (Concise Binary Object Representation, RFC 8949) and the specification prohibits indefinite-length CBOR, which keeps parsers on constrained devices small. Transport is HTTP or HTTPS, and the 2.0 text requires rendezvous servers and owners to support both while devices need only one.

The split matters operationally. TO0 and TO1 touch the rendezvous server only, which is cheap, stateless-ish and can be scaled or even replaced. TO2 is the expensive, security-critical exchange and it happens only between the device and its owner. A compromised rendezvous server can send a device to the wrong address but cannot make the device accept it, because the device verifies the owner against the voucher in TO2.

Late binding in practice

Consider a gateway vendor selling through three channel partners into twenty customers. In a pre-provisioned model the vendor must either manufacture customer-specific SKUs or ship generic units and accept a manual enrolment step. With FDO the vendor ships identical hardware. When a customer buys, the vendor (or a partner) extends the voucher to that customer’s public key, and the customer imports the voucher into its onboarding service. The device powers up, discovers its owner and receives that customer’s certificates and configuration. Nobody touched the box.

The FIDO Alliance notes that the specification does not define how vouchers move through the supply chain, and that its working group is addressing it. This is the single biggest practical gap, and we return to it in the failure-modes section.

Ownership Vouchers and the TO0/TO1/TO2 Protocols

Anatomy of an ownership voucher

Figure 2: An ownership voucher is a signed chain. The device trusts it because it stores a hash of the manufacturer key.

The voucher has a header and a list of entries. The header names the device GUID, the rendezvous instructions the device was initialised with, a description of the device, the manufacturer’s public key and a hash of the device certificate chain where one is used. An HMAC over the header, computed with a secret that only the device and the manufacturer’s DI process share, binds the voucher to a specific device. Each entry then carries a public key and is signed by the previous key in the chain, with a hash of the preceding material so entries cannot be reordered or spliced.

Read the chain as a series of statements. Entry zero says “the manufacturer authorises key K1 to take ownership.” Entry one, signed by K1, says “K1 authorises K2.” The last entry names the Owner Key, and the current owner proves it holds that key by signing a nonce during TO2. The device stores a hash of the manufacturer’s public key, so it can verify the whole chain from a single trust anchor. Nothing on the device changes when a reseller extends the voucher, which is why vouchers can be handled in a back-office system rather than on the factory floor.

The voucher is not the RFC 8366 voucher used by BRSKI, despite the shared word. Per the 2.0 specification the FDO voucher is its own structure. Supported primitives in the base profile include SHA-256 and SHA-384 hashing, HMAC-SHA256 and HMAC-SHA384, and signatures with ECDSA on P-256 or P-384 or with RSA (PKCS#1 v1.5 and a restricted 2048-bit profile). RSA-PSS is not in the base profile of the 2.0 text, though some implementations accept it. Check your library’s advertised key types against your device’s capability before you commit a hardware root key.

The consequences of the design are subtle. Because the chain is a hash-linked list of signatures, anyone holding a valid voucher can read the device GUID and its rendezvous information. A voucher is therefore sensitive metadata even though it contains no private key. The FIDO Alliance’s ownership-voucher guidance application note concentrates on the sharper risk: a voucher extended to two different parties.

TO0: the owner registers a blob

TO0 is how an owner makes itself findable. The owner onboarding service opens a session with the rendezvous server and sends a signed blob containing its own address (the “to1d” structure, signed with the Owner Key), along with the voucher. The rendezvous server checks the voucher chain, verifies the signature and stores the mapping from GUID to blob for a limited time. The specification does not fix a lifetime. Owners keep the entry alive by re-running TO0. Message types are TO0.Hello (20), TO0.HelloAck (21), TO0.OwnerSign (22) and TO0.AcceptOwner (23).

The rendezvous server verifies the voucher but is trusted only to remember the mapping. It does not authorise the transfer. The device performs the real authorisation later, so a malicious rendezvous server that returns a bad address achieves a denial of service at worst.

TO1: the device asks where its owner is

At first boot the device knows its GUID and the rendezvous instruction baked into its credential, which can be a DNS name, an IP address and port, or a list of them with delays and bypass hints. It sends TO1.HelloRV (30), receives a nonce in TO1.HelloRVAck (31), and answers with TO1.ProveToRV (32), a signed proof using its device attestation key. If a blob exists the server returns TO1.RVRedirect (33) containing the owner’s signed address. If no mapping exists the device retries after a randomised delay, which the spec describes so that a fleet powering on simultaneously does not hammer the server.

Two details deserve emphasis. First, local discovery: the 2.0 specification requires every implementation to support a device initialised with the rendezvous DNS name rvserver.local, which lets an air-gapped site run its own rendezvous server. Second, RVBypass lets a device skip rendezvous and contact a known owner directly, which suits closed deployments but removes the late-binding flexibility.

TO2: the ownership transfer

TO2 is where the work is done, and it is a mutually authenticated exchange between device and owner. In the 1.1 text the message numbers run from TO2.HelloDevice (60) through TO2.Done2 (71). The 2.0 text renumbers and extends the set, starting with a probe, HelloDeviceProbe (80), that supports version negotiation, followed by HelloDeviceAck20 (81), ProveDevice20 (82), ProveOVHdr20 (83) and so on up to DoneAck20 (91). The shape is the same in both versions, summarised below.

Figure 3: The TO0, TO1 and TO2 sequence from owner registration to completed ownership transfer.

1. Hello and key exchange. The device announces its GUID, a nonce, and the key-exchange and cipher suites it supports. Choices include ECDH on P-256 or P-384, finite-field Diffie-Hellman groups, and RSA-based asymmetric key exchange.
2. Owner proves the voucher. The owner replies with the voucher header and entry count, signed with the Owner Key. The device fetches entries one by one (GetOVNextEntry and OVNextEntry) and verifies the chain end to end against its stored manufacturer key hash. The owner is then required to sign device-supplied nonces to prove possession of the final key.
3. Device proves itself. The device returns an Entity Attestation Token (EAT, RFC 9711) signed with its attestation key, ECDSA P-256 or P-384.
4. Encrypted channel. After key exchange, subsequent messages are encrypted and authenticated with AES in GCM or CCM mode, or encrypt-then-MAC with AES-CBC and HMAC.
5. Credential replacement. The owner may supply a replacement GUID and new rendezvous information. Per the specification, after TO2 all FDO keys and identifiers are replaced except the device attestation key, so the device carries no memory of its original GUID. That prevents correlating a device across owners.
6. ServiceInfo. Device and owner exchange key-value pairs through FDO ServiceInfo Modules (FSIMs). A device can send a PKCS#10 certificate signing request and the owner returns a signed certificate; the owner can push a configuration file or a command; the device reports its inventory through the devmod module.
7. Done. The device stops running FDO until ownership is transferred again.

The EAT reference is RFC 9711, which standardises the token format; the FDO specification builds device attestation on top of it. For clarity: the claim that the FDO attestation is “an EAT” comes from the specification text, and the RFC number is our own pointer to the IETF standard rather than something the FDO page states.

Resale and credential reuse

Two further protocols address what happens after the first owner. Resale lets a device, during TO2, allocate a fresh secret and hand the owner an HMAC for a new voucher, so the owner can later sell the device without the manufacturer’s participation. Credential Reuse lets an owner keep the same device credential across re-onboarding instead of rotating it. Both are optional, and an open-source implementation such as go-fdo exposes them as flags. The reuse trade-off is plain: it saves a rotation step at the cost of weakening the unlinkability FDO otherwise gives you between owners.

What changed in FDO 2.0

According to the published 2.0 text (FDO 2.0):

• Delegation. Delegate Owners onboard devices with an X.509 Delegate Certificate signed by the Owner, so a regional integrator can act without being added to the voucher.
• Capability flags and version negotiation. CapabilityFlags and VendorCapFlags let peers discover each other’s features, and the new HelloDeviceProbe message supports negotiation.
• EPID removed. Intel’s Enhanced Privacy ID attestation is supported only up to 1.1, with its definitions kept as legacy.
• Larger messages. The message-length type changed from a 16-bit field to an unbounded unsigned integer, explicitly to allow larger post-quantum-safe objects.
• Post-quantum. The text says post-quantum-safe cryptography is “highly recommended” but not mandated. We could not verify which specific algorithm identifiers are defined, so do not assume ML-DSA support in a given product. For firmware-signing context, see our comparison of SLH-DSA, ML-DSA and FN-DSA for IoT.

Our fetch of the 2.0 text was truncated before its appendix on differences from 1.1, so the list above is what we could confirm, not a complete changelog. Read Appendix F yourself before planning a migration.

Deeper Analysis: Device Credentials, TPM Binding and the Comparison with Cloud Provisioning

What lives on the device

The device credential identifies the manufacturer key used in the voucher and holds the device’s own secrets. In the 1.1 text its fields include an active flag, protocol version, an HMAC secret, device info, the GUID, rendezvous info and a hash of the manufacturer public key. The HMAC secret is what ties a voucher to a physical unit, and the attestation key is what proves the unit is real. If either leaks from a single device, an attacker can impersonate that one device, but not the fleet. That blast-radius property is the opposite of a shared claim certificate.

For high-assurance products the FIDO Alliance publishes an application note on securing FDO credentials in a TPM (Securing FDO credentials in TPM). Its approach is worth understanding because it solves a real problem: how to keep FDO secrets in a TPM and still survive a TPM clear and a resale. The note describes the following.

• The device key (ECC P-256 or P-384) and the HMAC secret are created as primary objects in the Endorsement hierarchy with TPM2_CreatePrimary, using a “Unique String” supplied by the caller. Primary keys derive deterministically, so they can be recreated.
• The Unique Strings are stored in NV indices under the Platform hierarchy, so they survive TPM2_Clear. Changing a Unique String yields a new key, which is how a replacement is issued after TO2.
• Object attributes include fixedTPM, fixedParent and sensitiveDataOrigin, and encryptedDuplication is clear, so keys are generated inside the TPM and cannot be duplicated. Decrypt is clear, so the device key signs external data only.
• Access is gated by an authPolicy that combines PolicyNV and PolicySecret tied to the Unique String index, and only the restricted environment should reach these objects.

The note’s persistent and NV handles are explicitly provisional test values, not yet allocated by the Trusted Computing Group, so treat it as a review draft. For the measurement and attestation side of TPMs, see our guide to TPM 2.0, measured boot and remote attestation for IoT fleets. A practical point: FDO attestation proves a device holds a particular key, whereas TPM remote attestation proves what software booted. They answer different questions and are complementary.

Where the open-source implementations stand

As of this writing the Go implementation, go-fdo, implements FDO 1.1, with roles for the device client (DI, TO1, TO2), the DI server and the owner service (TO2 server and TO0 client). It supports Resale and Credential Reuse, the common key-exchange suites, and storing device secrets in a file or a TPM 2.0, under the Apache-2.0 licence. Its own documentation warns that interoperability testing with the FIDO Alliance is not yet complete and that the module has no stable v1 release (go-fdo package documentation). Red Hat documents FDO for RHEL for Edge, and Microsoft has shown a prototype running the FDO client inside UEFI firmware. We did not verify the current production status of those vendor integrations; check release notes before depending on them.

The implication for your design is that FDO is real and deployable, but you should budget for interop testing between your device client and your chosen owner service, and ideally use the Alliance certification programme as a procurement requirement.

Failure handling during first boot

Think of onboarding as a state machine with three outcomes: stuck, succeeded and compromised. Stuck is the common one. A device that cannot reach its rendezvous server retries after a randomised delay. A device that reaches the server but finds no mapping, because the owner never ran TO0 or the entry expired, simply loops. This is by design, but it surprises operators who expect an error. Instrument your rendezvous server to count TO1 requests per unknown GUID; a rising count is your best signal that vouchers were imported late or TO0 renewals broke.

Figure 4: A decision flow for choosing an onboarding model, and the hardening work that follows from choosing FDO.

FDO versus the alternatives

The table compares onboarding models on the properties that decide real projects. Cloud rows reflect the vendors’ documentation cited above. FDO and BRSKI/EST rows reflect the specifications. Treat “effort” entries as our judgement rather than measured values.

Dimension	FDO	AWS JITP/JITR	AWS claim / trusted user	Azure DPS	EST (RFC 7030)	BRSKI (RFC 8995)
Unique credential at factory	Yes: device key plus voucher	Yes: device certificate	No: shared claim certificate (trusted user: temporary claim valid about 5 minutes)	Yes for X.509 and TPM; symmetric key groups derive per-device keys	Typically a manufacturer certificate	Yes: manufacturer certificate (IDevID)
Owner known at manufacture	No (late binding)	Usually the target account	No	Needs ID scope in firmware	Needs CA address	No: discovered locally
Ownership transfer	Native via voucher extension, resale	Re-register or new account	Re-provision	Reprovisioning or new DPS	Re-enrol	Re-run with new domain
Central dependency	Your RV and owner service; no vendor cloud	AWS IoT	AWS IoT	Azure DPS	Your CA	Manufacturer authorised signing service
Primary target	Edge, IoT, servers, multi-owner	AWS fleets	AWS fleets	Azure fleets	Certificate issuance	Managed networks
Provisions credentials for any platform	Yes, through ServiceInfo	Provisions to AWS only	Provisions to AWS only	Provisions to Azure IoT Hub and apps	Certificates only	Certificates only

Three points hold up the comparison.

FDO is platform-neutral; cloud services are not. DPS has a global endpoint and a per-service ID scope that is immutable, so moving devices between DPS instances may require configuration or firmware updates. FDO’s rendezvous indirection exists specifically to avoid baking a destination into firmware. The cost is that FDO hands you a protocol, not a service. You still need to deliver a platform enrolment, which is what ServiceInfo is for.

FDO and cloud provisioning compose. A common pattern is to use FDO for the first hop and your cloud’s native provisioning for the second. FDO delivers a customer-specific certificate and endpoint to the device, and the device then registers with AWS IoT or Azure DPS using that credential. The device never held a cloud secret at manufacture. For the platform side of this, SPIFFE and SPIRE workload identity is one way to hand identity to software once the device has a root credential.

EST and BRSKI solve certificate issuance, not ownership. EST gets a device a certificate from a CA. BRSKI adds a voucher signed by the manufacturer’s authorised signing service so a domain can trust a new device, but it presumes a reachable manufacturer service and a local network proxy. FDO’s voucher is held by the owner and works offline from the manufacturer once issued, which is why it suits devices that cross organisational boundaries.

Capacity and cost thinking

FDO’s runtime cost is dominated by TO2. Each device does an ECDH key exchange, verifies a voucher chain of N entries (N signature verifications plus hashes), produces one signature, and exchanges a handful of encrypted messages plus whatever ServiceInfo carries. On a modern server that is negligible; on a microcontroller the voucher fetch loop and ECDSA verifications dominate, so keep chains short and prefer P-256 on devices with hardware acceleration. We have not benchmarked this and quote no latency figures.

At fleet scale the interesting load is a thundering herd. Ten thousand devices powering on after a site outage will all send TO1 requests. The randomised retry delay in the spec protects the rendezvous server, but your owner service sees a burst of TO2 sessions once mappings exist. Rate-limit TO2 sessions per owner, size the database that stores voucher and session state for the burst, and keep ServiceInfo payloads small, pushing large artefacts as URLs the device downloads rather than as inline blobs.

Trade-offs, Gotchas, and What Goes Wrong

The double-extended voucher

The most instructive failure is documented by the FIDO Alliance itself. A careless, compromised or malicious party in the supply chain extends the same voucher to two different owners, A and B. Both now hold valid vouchers. Because the rendezvous server indexes entries by GUID, whichever owner registered most recently can steer a device that arrives later to its own address. B can also attack A’s availability to stop A renewing its entry (FDO OV guidance application note).

The note’s countermeasures live in the rendezvous server. It should cache the owner public key from the last voucher entry for each stored entry, reject TO0 requests with a different key, and retain that key for a period after the entry times out (the note proposes one week, extended on each successful TO0). Owners should register their voucher with all candidate rendezvous servers before shipping. It also admits limits: if the owner’s private key is stolen, detection is beyond its scope, and if the owner does not control the delivery premises it cannot tell a failed onboarding from a device still in transit. In plain terms, FDO shifts trust to your voucher custody process, and an insecure process defeats strong cryptography.

Vouchers are sensitive and the supply chain is undefined

The spec does not say how vouchers travel between companies. In practice they are exchanged as files or via APIs, and anyone who receives a voucher learns device GUIDs and rendezvous information. Treat them like licence keys: encrypt in transit, restrict by contract and log every extension. If you operate a distribution channel, expect to build or buy voucher-management tooling, because the standard will not hand you one.

First-boot trust is still trust on first use

DI is non-normative and assumes the manufacturing environment is trustworthy. If an attacker corrupts the factory, they can issue vouchers for devices they control or clone attestation keys. FDO lets the owner verify what the manufacturer signed; it does not prove the factory was honest. Hardware-backed keys, audited lines and, for regulated products, supplier assurance programmes still matter. Our coverage of the EU Cyber Resilience Act and IoT compliance shows why a documented, secure-by-default onboarding story is becoming a compliance matter and not just an engineering preference.

Other gotchas

• Rendezvous expiry. Mappings are held for a limited time with no fixed TTL in the spec. Forgotten TO0 renewals are the most common cause of devices that appear dead.
• Clock and certificate assumptions. Devices without a trustworthy clock cannot validate HTTPS certificates reliably during first boot. FDO’s own authentication does not depend on the clock, but the HTTPS layer might. Many deployments use HTTP at the transport layer because FDO provides its own encryption after key exchange; weigh that choice with your threat model and see our TLS 1.3 handshake guide for constrained IoT.
• Version skew. A 1.1 device meeting a 2.0-only owner needs the version negotiation path. Test the pairing matrix, not just the happy path.
• Credential reuse versus unlinkability. Reuse is convenient, but it keeps identifiers constant across owners.
• Confusing the vouchers. FDO vouchers and RFC 8366 vouchers share a name and nothing else; libraries are not interchangeable.
• Post-quantum is aspirational. The 2.0 text recommends post-quantum cryptography but does not mandate it. A fleet shipping today with ECDSA P-256 roots has a long-lived exposure, so plan algorithm agility into the device credential before you ship.

Practical Recommendations

Choose FDO when the owner is unknown at manufacture, when devices change hands, or when you must serve several platforms from one hardware SKU. Choose native cloud provisioning when you control the whole chain, ship to a single cloud, and can inject unique certificates at the factory. Combine them when you want a platform-neutral first hop and a cloud-native second hop.

Start small. Stand up the open-source reference pieces in a lab, onboard one emulated device, and read the TO2 traces until you can explain every message. Then decide what you will own: a rendezvous server, an owner onboarding service, a voucher store, or only the device client if you are a hardware vendor shipping to customers who run their own services.

Be explicit about custody. Write down who is allowed to extend a voucher, how vouchers are transferred, and how you detect a double extension. Put the countermeasures from the Alliance guidance into your rendezvous configuration where the product allows it. Treat the voucher store like a key-management system.

Finally, make certification and interoperability part of procurement. The Alliance’s programme covers devices, onboarding services and rendezvous servers, so certified components should interoperate with each other.

Checklist before launch:

• [ ] Device attestation key and HMAC secret generated in hardware (TPM or secure element) where available.
• [ ] Voucher custody process written down, with logging of every extension.
• [ ] Rendezvous server rejects TO0 from a different owner key and caches the key after expiry.
• [ ] TO0 renewals monitored; alerts on unknown-GUID TO1 spikes.
• [ ] Owner service rate-limits TO2 and keeps ServiceInfo payloads small.
• [ ] Version-pairing test matrix (1.1 and 2.0) passed.
• [ ] Algorithm agility and a post-quantum plan documented.
• [ ] Local rendezvous (rvserver.local) supported for offline sites.
• [ ] Post-onboarding certificate rotation handled by your PKI, for example via ACME-style short-lived certificates where devices can support them.

Frequently Asked Questions

What is FIDO Device Onboard?

FIDO Device Onboard is a FIDO Alliance protocol that automatically and securely onboards IoT, edge and server devices to a management platform. A manufacturer creates a device identity and an ownership voucher, the owner registers with a rendezvous server, and on first power-up the device finds its owner, proves itself and receives credentials. Version 2.0 was published as a Proposed Standard on 2 April 2026, building on 1.0 and 1.1.

What is an ownership voucher?

An ownership voucher is a chain of signed public keys that records who may own a given device. Each entry authorises the holder of the next key to take ownership or pass it on, and the last entry holds the Owner Key. The device stores only a hash of the manufacturer key and verifies the entire chain against it during onboarding. A reseller extends the voucher by adding a signed entry, so the device itself does not change.

What does an FDO rendezvous server do?

A rendezvous server maps a device GUID to the address of its owner onboarding service. Owners register a signed blob during TO0, and devices query the server during TO1. It is trusted only to remember the mapping, because the device verifies the owner in TO2. Entries expire after a limited time unless renewed, and a local rendezvous server named rvserver.local supports closed networks.

How is FDO different from AWS or Azure provisioning?

AWS IoT and Azure DPS provision devices into their own platforms and typically expect a unique certificate or a claim credential at the factory, plus a destination known to the firmware. FDO is platform-neutral: the device is built without a destination, the owner is bound late through the voucher, and the owner then delivers credentials for any platform via ServiceInfo. The two can be combined, with FDO as the first hop and a cloud service as the second.

Is FDO the same as FIDO2 or passkeys?

No. FIDO2, WebAuthn and passkeys authenticate people to websites. FDO is a separate FIDO Alliance specification for onboarding machines, and it shares only the organisation and a focus on avoiding shared secrets. FDO uses its own voucher, attestation and key-exchange mechanisms rather than WebAuthn credentials, so tooling and libraries for passkeys cannot be reused for device onboarding.

Does FDO support post-quantum cryptography?

The 2.0 specification says post-quantum-safe cryptography is highly recommended but not mandated, and it widened the message length field to accommodate larger post-quantum objects. We could not confirm which post-quantum algorithms are formally defined, so check your vendor’s documentation. Plan for algorithm agility now, especially for long-lived devices whose manufacturer keys are ECDSA.

Further Reading

• ThingsBoard device provisioning tutorial for the platform side of device registration.
• TPM 2.0, secure boot and remote attestation for IoT fleets for hardware-backed keys.
• CoAP, OSCORE and EDHOC constrained-device security for alternatives on very small devices.
• SPIFFE and SPIRE workload identity for identity after onboarding.
• OPC UA security certificates and GDS trust lists for industrial certificate management.
• FIDO Device Onboard 2.0 Proposed Standard, the primary specification.
• RFC 8995: BRSKI, the IETF counterpart for managed networks.

By Riju — about