Terminology and processes for initial security setup of IoT devices
draft-irtf-t2trg-security-setup-iot-devices-07
This document is an Internet-Draft (I-D) that has been submitted to the Internet Research Task Force (IRTF) stream.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (t2trg RG) | |
|---|---|---|---|
| Authors | Mohit Sethi , Behcet Sarikaya , Dan Garcia-Carrillo | ||
| Last updated | 2026-09-21 (Latest revision 2026-07-06) | ||
| Replaces | draft-sarikaya-core-sbootstrapping, draft-sarikaya-t2trg-sbootstrapping, draft-irtf-t2trg-secure-bootstrapping | ||
| RFC stream | Internet Research Task Force (IRTF) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Additional resources | Mailing list discussion | ||
| Stream | IRTF state | (None) | |
| Consensus boilerplate | Unknown | ||
| Document shepherd | Carsten Bormann | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | cabo@tzi.org |
draft-irtf-t2trg-security-setup-iot-devices-07
Network Working Group M. Sethi
Internet-Draft Aalto University
Intended status: Informational B. Sarikaya
Expires: 7 January 2027 Unaffiliated
D. Garcia-Carrillo
University of Oviedo
6 July 2026
Terminology and processes for initial security setup of IoT devices
draft-irtf-t2trg-security-setup-iot-devices-07
Abstract
This document provides an overview of terms that are commonly used
when discussing the initial security setup of Internet of Things
(IoT) devices. This document also presents a brief but illustrative
survey of protocols and standards available for initial security
setup of IoT devices. For each protocol, we identify the terminology
used, the entities involved, the initial assumptions, the processes
necessary for completion, and the knowledge imparted to the IoT
devices after the setup is complete.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 7 January 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
Sethi, et al. Expires 7 January 2027 [Page 1]
Internet-Draft IoT initial security setup July 2026
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Standards and Protocols . . . . . . . . . . . . . . . . . . . 4
2.1. Bluetooth Mesh Provisioning . . . . . . . . . . . . . . . 4
2.2. Device Provisioning Protocol (DPP) . . . . . . . . . . . 7
2.3. Enrollment over Secure Transport (EST) . . . . . . . . . 10
2.4. Open Mobile Alliance (OMA) Lightweight Machine to Machine
specification (LwM2M) . . . . . . . . . . . . . . . . . 13
2.5. Nimble out-of-band authentication for EAP (EAP-NOOB) . . 14
2.6. Open Connectivity Foundation (OCF) . . . . . . . . . . . 16
2.7. Bootstrapping Remote Secure Key Infrastructures
(BRSKI) . . . . . . . . . . . . . . . . . . . . . . . . 19
2.8. Secure Zero Touch Provisioning (SZTP) . . . . . . . . . . 22
2.9. FIDO Device Onboard (FDO) . . . . . . . . . . . . . . . . 25
2.10. Thread . . . . . . . . . . . . . . . . . . . . . . . . . 29
3. Comparison . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.1. Comparison of terminology . . . . . . . . . . . . . . . . 33
3.2. Comparison of players . . . . . . . . . . . . . . . . . . 35
3.3. Comparison of initial beliefs . . . . . . . . . . . . . . 36
3.4. Comparison of processes . . . . . . . . . . . . . . . . . 39
3.5. Comparison of knowledge imparted to the device . . . . . 40
4. Security Considerations . . . . . . . . . . . . . . . . . . . 42
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 42
7. Informative References . . . . . . . . . . . . . . . . . . . 43
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45
1. Introduction
Initial security setup for a device refers to any process that takes
place before a device can become fully operational. The phrase
*initial security setup* intentionally includes the term _security_,
as setup of devices without adequate security or with insecure
processes is no longer acceptable. The initial security setup
process can involve, among other things, network discovery and
selection, access authentication, and configuration of necessary
credentials and parameters. Not all mechanisms include every aspect;
for example, some protocols assume that network connectivity and
discovery have been established a priori and focus solely on
authentication and credential provisioning.
Sethi, et al. Expires 7 January 2027 [Page 2]
Internet-Draft IoT initial security setup July 2026
Initial security setup for IoT devices is challenging because the
size of an IoT network varies from a couple of devices to tens of
thousands, depending on the application. Moreover, devices in IoT
networks are produced by a variety of vendors and are typically
heterogeneous in terms of constraints on power supply, communication
capability, computation capacity, and available user interfaces.
This challenge of initial security setup in IoT was identified by
Sethi et al. [Sethi14] while developing a solution for smart
displays.
Initial security setup of devices typically also involves providing
them with some form of network connectivity, as the functionality of
a disconnected device is limited. Many mechanisms assume that some
network or supporting infrastructure has already been established a
priori. Setting up and maintaining such infrastructure can itself be
complex, for example requiring configuration of network identifiers
(such as Service Set Identifiers (SSIDs) in Wi-Fi networks),
credentials, or backend services. This document does not focus on
the procedures for establishing these networks or services. Instead,
it focuses on the terminology and processes associated with the
initial security setup of devices, while explicitly identifying the
roles and assumptions related to any required supporting
infrastructure.
Several terms are used in the context of initial security setup of
devices:
* Bootstrapping
* Provisioning
* Onboarding
* Enrollment
* Commissioning
* Initialization
* Configuration
* Registration
* Discovery
In addition to this variety of terminology, initial security setup
mechanisms can rely on several entities. For example, a companion
smartphone device may be necessary for some initial security setup
Sethi, et al. Expires 7 January 2027 [Page 3]
Internet-Draft IoT initial security setup July 2026
mechanisms. Moreover, security setup procedures have diverse initial
assumptions about the device being set up. For instance, a mechanism
may assume, an initial security setup mechanism may assume that the
device is provisioned with a pre-shared key and a list of trusted
network identifiers. Finally, initial security setup mechanisms
impart different information to the device after completion.
Finally, mechanisms differ in the information imparted to the device
upon completion. Some provide only credentials for use with an
authorization server, while others configure more complex artifacts
such as access control policies.
The next section provides an overview of selected standards and
protocols for initial security setup of IoT devices. For each
mechanism, the following are explicitly identified:
* Terminology used
* Entities or "players" involved
* Initial assumptions about the device
* Processes necessary for completion
* Knowledge imparted to the device after completion
2. Standards and Protocols
2.1. Bluetooth Mesh Provisioning
Bluetooth Mesh [bt-mesh] defines provisioning as the process by which
an unprovisioned device is securely added to an existing Bluetooth
mesh network and becomes a mesh node. The process is coordinated by
a Provisioner, typically a smartphone application or dedicated
management tool, which discovers the unprovisioned device, performs
an Elliptic Curve Diffie-Hellman (ECDH) key exchange with it, and
authenticates that exchange using a selected authentication method
such as Output OOB, Input OOB, Static OOB, or No OOB. In user-
assisted OOB methods, the user helps authenticate the key exchange by
transferring or confirming information through available device
interfaces, such as displays, indicators, buttons, or other input and
output mechanisms. Furthermore, Bluetooth Mesh version 1.1
introduced certificate-based provisioning, where the device can
authenticate itself using a manufacturer-issued certificate. Once
the exchange has been authenticated and protected, the Provisioner
securely transfers the information required for the device to
participate in the mesh.
Sethi, et al. Expires 7 January 2027 [Page 4]
Internet-Draft IoT initial security setup July 2026
To support larger or geographically distributed deployments,
Bluetooth Mesh supports remote provisioning, where already-
provisioned mesh nodes relay messages for devices outside the direct
radio range of the Provisioner. At the end of the process, the
device is assigned a unicast address and receives the network
credentials needed to authenticate and protect mesh communication.
Provisioning is intentionally separated from later configuration; it
establishes the device as a member of the mesh security domain by
distributing the Network Key and creating a device-specific trust
relationship through the Device Key. Configuration can then use this
Device Key to perform further management actions, such as
distributing Application Keys and enabling application-layer
communication.
Bluetooth mesh has the following characteristics:
* *Terms*:
- _Provisioning_: is the central term used to refer to the
complete process of securely adding a new device, called a
provisionee, to an existing mesh network with the help of a
Provisioner. It includes discovery, authentication,
establishment of shared keys, and delivery of network specific
credentials and addressing information.
- _Beaconing and discovery_: describe the mechanism by which
unprovisioned devices announce their presence to Provisioners
so that the provisioning process can be initiated.
- _Configuration_: describes the post provisioning process by
which a node is prepared for participation in the mesh network.
Configuration includes the distribution of Application Keys for
instance. Note, distribution of the Network Key, unicast
address, and Device Key is considered essential and is
therefore part of provisioning rather than the optional
configuration phase.
- _Reprovisioning_: refers to the process of provisioning a
device again, either to add it to a new mesh network or to
restore it after removal from a previous network.
* *Players*: In deployments where the device being provisioned uses
a static asymmetric key pair, the device manufacturer is
responsible for equipping each device with that key pair and
making the corresponding public key and related metadata available
to the user, for example by printing it on the device or its
packaging, often encoded as a QR code or URI. In certificate-
based provisioning deployments, the manufacturer additionally
Sethi, et al. Expires 7 January 2027 [Page 5]
Internet-Draft IoT initial security setup July 2026
provisions the device with a unique X.509v3 device certificate.
The Provisioner plays a central role in the protocol and is
typically implemented as a smartphone application provided by the
device manufacturer or system integrator. The device owner/user
is responsible for initiating the provisioning process and
selecting the correct physical device to add to the mesh network.
Depending on the provisioning method, the user may scan a QR code
or URI containing the device public key, UUID, or related
metadata, or select the device from a list of unprovisioned
devices identified by vendor, model, and UUID. If Output OOB,
Input OOB, or Static OOB authentication is negotiated, the user is
also responsible for transferring the required out-of-band
information, for example by observing a blinking LED or numeric
display on the device and entering the value into the Provisioner,
or vice versa. When certificate-based provisioning is used, the
device authenticates itself using its manufacturer-issued
certificate, eliminating the need for user-assisted transfer of
authentication data. The user may still need to select or confirm
the intended physical device, assisted by visual or audio cues
emitted by the device.
* *Initial beliefs assumed in the device*: Each device must have a
unique Device UUID, which is used during discovery to identify the
device to a Provisioner. The device may also be provisioned with
a device specific static asymmetric key pair that is used in the
ECDH key exchange during provisioning. In this case, the public
key is typically made available to the Provisioner out-of-band via
a QR code or NFC tag printed on the device or its packaging. In
deployments that use certificate based provisioning, the device is
additionally provisioned at manufacturing time with an X.509
Device Certificate that binds the device public key and the UUID.
The corresponding trust anchor CA for validating this certificate
is assumed to be available to the Provisioner.
* *Processes*: Once an unprovisioned device is powered on, it
advertises its presence using unprovisioned beacons. The user or
owner then uses a Provisioner application to discover nearby
unprovisioned devices. The user may select the correct device
based on information such as make, model, and Device UUID
displayed by the Provisioner. In deployments that use static
public keys or certificate based provisioning, the user may also
scan a QR code or URI on the device or its packaging to transfer
the device public key and or UUID to the Provisioner prior to
authentication. Thereafter, the unprovisioned device and the
Provisioner perform a capabilities exchange to determine supported
cryptographic algorithms, authentication methods, and available
input and output interfaces. At this stage, the user or owner may
be assisted by visual or audio cues emitted by the device, as
Sethi, et al. Expires 7 January 2027 [Page 6]
Internet-Draft IoT initial security setup July 2026
permitted by its reported capabilities, to clearly identify the
physical device that is being provisioned. Based on the exchanged
capabilities, the Provisioner selects an authentication method and
initiates an Elliptic Curve Diffie Hellman key exchange. The key
exchange is then authenticated using one of the supported methods,
such as Input OOB, Output OOB, or Static OOB, in which case the
user assists by transferring or confirming authentication data
between the device and the Provisioner. The specification also
allows certificate based authentication, where the device presents
a manufacturer issued certificate that is verified by the
Provisioner, removing the need for user mediated out of band
transfer. Upon successful authentication, the Provisioner derives
session keys and a Device Key and securely delivers the
provisioning data, including the Network Key and unicast address,
to the device. After provisioning is complete, the device becomes
a node in the mesh network and can securely participate in network
communication. Subsequent configuration is performed using the
Device Key to distribute Application Keys.
* *Knowledge imparted to the device after protocol execution*: After
the provisioning process is complete, the device possesses one or
more Network Keys that enable it to encrypt and integrity protect
mesh network messages. The device is also assigned a unique
unicast address that defines its identity and addressing within
the mesh network. In addition, the device holds a Device Key that
is shared only with the Provisioner or Configuration Manager and
is used to authenticate and protect future configuration messages
without requiring reprovisioning. The device may also receive one
or more Application Keys that allow it to participate in specific
application level communication contexts.
2.2. Device Provisioning Protocol (DPP)
The Wi-Fi Alliance Device Provisioning Protocol (DPP) [dpp], also
known as Wi-Fi Easy Connect, defines a mechanism for securely
configuring a device, called an enrollee, for access to a Wi-Fi
network. The process is coordinated by a configurator, which
authorizes the enrollee and provisions it with the information
required to join the network. The configurator may be implemented as
a smartphone application used by the device owner, as functionality
within a Wi-Fi access point that directly configures new devices for
its network, or as part of a cloud-connected management service. In
cloud-managed deployments, the enrollee may exchange DPP messages
through a local relay, such as an access point, which forwards those
messages to a remote configurator.
Sethi, et al. Expires 7 January 2027 [Page 7]
Internet-Draft IoT initial security setup July 2026
DPP separates the initial establishment of trust from the later
delivery of network configuration. It begins with a bootstrapping
phase in which one or both parties obtain authenticated bootstrapping
information for the other party. In common deployments, the user
assists bootstrapping by scanning a QR code or using another out-of-
band mechanism to transfer an authenticated copy of the enrollee's
bootstrapping public key to the configurator. DPP also supports
bidirectional bootstrapping, including mechanisms such as PKEX, where
the user enters a short shared secret code on both sides, or NFC,
when both parties need to authenticate each other's bootstrapping
keys. After bootstrapping, the authentication phase uses a fresh
ephemeral key exchange, bound to the authenticated bootstrapping
keys, to establish shared key material between the configurator and
the enrollee. Once authentication is complete, the configurator
provisions the enrollee with a DPP configuration object containing
the network parameters and a Connector, which the enrollee uses to
authenticate to the Wi-Fi access point and join the network.
DPP has the following characteristics:
* *Terms*:
- _Bootstrapping_: refers to the initial establishment of trust
between the configurator and the enrollee through an out of
band exchange of bootstrapping public keys. Only concerned
with public key authentication rather than network
configuration.
- _Discovery_: refers to the mechanisms by which devices locate
each other and determine how DPP messages should be exchanged.
- _Enrollment_: used informally to refer to the act of
authorizing a device to join a specific network domain
- _Configuration_: refers to the phase in which the configurator
provisions the enrollee with the information required to join a
network domain. This includes delivery of a DPP configuration
object containing network parameters and a Connector.
- _Reconfiguration_: refers to the ability of an already
provisioned device to obtain updated network configuration
information from a configurator without repeating the initial
bootstrapping phase.
Sethi, et al. Expires 7 January 2027 [Page 8]
Internet-Draft IoT initial security setup July 2026
- _Provisioning_: used more broadly in DPP to describe the
overall process of securely configuring a device for network
access. It encompasses bootstrapping, authentication,
configuration, and access, rather than referring to a single
protocol step.
* *Players*: The device manufacturer is responsible for provisioning
each device with a bootstrapping asymmetric key pair during
manufacturing. In many deployments, the manufacturer is also
responsible for encoding the corresponding bootstrapping public
key, together with associated metadata, as a QR code printed on
the device or its packaging. The device owner/user is responsible
for securely transferring this bootstrapping public key
information to the configurator. The configurator required to
perform the DPP protocol and enable new devices to join the Wi Fi
network can be provided through functionality built into mobile
operating systems such as Android or iOS, or through a dedicated
application supplied by the device manufacturer. In enterprise or
cloud managed deployments, the configurator may be part of a
remote IoT platform, in which case the local Wi-Fi access point
acts as a relay and must be configured with the network location
of the remote configurator.
* *Initial beliefs assumed in the device*: DPP requires devices to
have a bootstrapping asymmetric key pair, which is typically
installed in the factory. The corresponding bootstrapping public
key is intended to be conveyed securely to the configurator
through an out of band mechanism. Depending on the selected DPP
variant and the device capabilities, this may require the device
to support specific I/O interfaces. For example, devices may
present the bootstrapping public key and associated metadata
encoded as a QR code or NFC tag, or they may support limited user
input to enable password based bootstrapping using PKEX.
* *Processes*: DPP provisioning process begins with bootstrapping,
during which a user initiates an out-of-band transfer of public
keys between the configurator and the enrollee. In a typical
unidirectional deployment, the user employs a configurator, such
as a smartphone application, to scan a QR code associated with the
enrollee, thereby providing the configurator with an authenticated
copy of the enrollee bootstrapping public key. Bidirectional
variants are also supported, including NFC based exchanges and
PKEX, where both the configurator and the enrollee authenticate
each other using a short-shared secret input by the user. Once
the configurator possesses the enrollee authenticated
bootstrapping key, the devices proceed to the authentication
phase, performing cryptographic exchanges to verify the
bootstrapping keys and establish a secure encrypted channel using
Sethi, et al. Expires 7 January 2027 [Page 9]
Internet-Draft IoT initial security setup July 2026
derived shared key material. During the subsequent configuration
phase, the configurator uses this protected channel to provision
the enrollee with a DPP configuration object containing deployment
specific network parameters and a Connector. The Connector is a
cryptographically protected credential that binds the network
identity to a device specific access key and replaces legacy
network wide passwords. In the access phase, the enrollee
presents the Connector to a Wi-Fi AP to establish secure
association with the network. If network settings change or
credentials expire, the device can also undergo reconfiguration by
using its stored keys to obtain updated configuration information
without repeating the initial physical bootstrapping steps.
* *Knowledge imparted to the device after protocol execution*: After
successful completion of the DPP provisioning process, the
enrollee device and the configurator establish shared key material
that is used to protect the subsequent information provisioned
onto the device. The information includes a Connector, which is a
signed and cryptographically protected structure containing a
group identifier, a network role, and a network access key. The
Connector replaces traditional network wide passwords and allows
the device to prove to other peers that it has been authorized by
the configurator to join the network. The device also receives
and trusts the configurator public signing key, which it uses to
verify Connectors presented by other devices such as APs. In
addition, the device gains knowledge of deployment specific
network parameters, typically including the SSID, supported
operating channels, security policies of the domain, and privacy
protection keys (used to protect identity of the enrollee when
requesting reconfiguration by the configurator).
2.3. Enrollment over Secure Transport (EST)
Enrollment over Secure Transport (EST) [RFC7030] defines a
certificate enrollment protocol that allows client devices to obtain
operational certificates and associated certification authority (CA)
certificates from an EST server. EST uses HTTP [RFC9112] over
Transport Layer Security (TLS) as its primary transport, and a
companion specification also defines how EST can be used over secure
CoAP [RFC9148]. The device acting as an EST client is assumed to
already have IP connectivity to the EST server and sufficient
information to initiate a TLS connection.
The EST server is authenticated by the client using a trust anchor
that is already known to the device, or, in minimally configured
deployments, by allowing a human operator to verify the fingerprint
of the server's CA certificate before establishing trust. The client
authenticates to the server using supported methods such as TLS
Sethi, et al. Expires 7 January 2027 [Page 10]
Internet-Draft IoT initial security setup July 2026
client authentication with a pre-provisioned credential, HTTP-based
authentication with a username and password, or a shared secret
provisioned out of band. In many deployments, the device is
provisioned during manufacturing with a client credential, such as an
IEEE 802.1AR device certificate, which is used for TLS client
authentication. Once the secure connection has been authenticated,
the client submits a certificate signing request and receives an
operational certificate and associated CA certificates, enabling it
to authenticate securely in subsequent communications.
EST has the following characteristics:
* *Terms*:
- _Bootstrapping_: used for the process when the client device
has not been configured with an Implicit Trust Anchor (TA)
database and device owner or administrator manually verifies
the fingerprint of the EST CA certificate. This manual
verification is only needed once, as the device establishes an
explicit TA database for subsequent TLS authentication of the
EST server.
- _Enrollment_: describes the entire process of obtaining a
client certificate from the EST CA. This includes learning the
EST CA certificate, discovering required attributes for the
Certificate Signing Request (CSR), submitting the CSR, and
receiving the final client certificate.
- _Initialization_: term used to refer to the essential
initialization data that the device needs for completing the
enrollment including the trust anchors, the EST server URI, and
credentials for TLS authentication.
* *Players*: The network administrator is responsible for deploying
and maintaining the EST CA and EST server before a device can be
enrolled into the network. The device manufacturer must install a
client identity certificate (such as an IEEE 802.1AR certificate),
a shared secret for TLS authentication without certificates, and/
or a username and password for HTTP Basic [RFC7617] or Digest
[RFC7616] authentication. Additionally, the manufacturer may
configure trust anchors for verifying the EST server and set the
EST server URI. However, the EST specification allows for manual
configuration of all required information, including the manual
verification of the EST CA certificate fingerprint.
* *Initial beliefs assumed in the device*: A device acting as an EST
client is assumed to possess an existing credential for
authenticating itself during the TLS handshake with the EST
Sethi, et al. Expires 7 January 2027 [Page 11]
Internet-Draft IoT initial security setup July 2026
server. This credential may be a previously issued EST client
certificate or a certificate from a distinct PKI, such as an IEEE
802.1AR manufacturer-installed certificate. Alternatively, the
client may authenticate using a shared secret-based credential,
such as a pre-installed symmetric key, or a username and password,
either as a standalone method or in combination with TLS
authentication. To verify the EST server, the client relies on a
trust anchor database, which may be explicit, used to authenticate
certificates issued by the EST CA, including the EST server
certificate, or implicit, allowing authentication of the EST
server when it presents a certificate issued by an external CA.
The implicit trust anchor database may initially contain pre-
installed CA certificates and can be disabled once the EST CA
certificate is obtained. The EST client must also be configured
with a Uniform Resource Identifier (URI) to locate the EST server.
* *Processes*: Before a device can enroll using EST, the necessary
network infrastructure must be in place, including the deployment
of the EST server and CA. The device can discover the EST server
URI through various methods, such as manual configuration or
preconfigured settings from the manufacturer. If the device lacks
an explicit Trust Anchor (TA) database, it may require
bootstrapping, where the owner or administrator manually verifies
the fingerprint of the EST CA certificate. Once the EST server is
authenticated, the device retrieves the EST CA certificate, learns
the required attributes for generating a Certificate Signing
Request (CSR), and submits the CSR to obtain a client certificate.
After enrollment, the device can securely authenticate to the
network using its newly issued certificate and renew it before
expiration.
* *Knowledge imparted to the device after protocol execution*: After
completing the enrollment process, the device obtains a client
certificate issued by the EST CA, which it can use for
authentication in subsequent communications. During enrollment,
the device also learns the EST CA certificate, along with any
intermediate certificates needed to build a complete trust chain
to the EST CA trust anchor. The client also discovers the
attributes it should include in a Certificate Signing Request
(CSR), such as key usage, extended key usage, etc. Depending on
the enrollment method, the device may generate its own key pair
and submit a CSR or receive both a server-generated key pair and
certificate. If the client requested a Full PKI, it may also
receive information such as certificate revocation lists (CRLs),
policy and name constriants etc. as defined in [RFC5272].
Sethi, et al. Expires 7 January 2027 [Page 12]
Internet-Draft IoT initial security setup July 2026
2.4. Open Mobile Alliance (OMA) Lightweight Machine to Machine
specification (LwM2M)
The Open Mobile Alliance Lightweight Machine to Machine (LwM2M)
specification [oma] defines a management framework in which a device,
called an LwM2M client, obtains the information required to
communicate securely with one or more LwM2M servers that perform
device management functions. A key component of this framework is
the LwM2M Bootstrap Server, which is responsible for provisioning the
client with the credentials and configuration needed to establish and
maintain secure communication with operational LwM2M servers. The
specification assumes that the client already has network
connectivity and can reach the Bootstrap Server.
During bootstrapping, the LwM2M client establishes a secure
connection to the Bootstrap Server using supported security
mechanisms such as pre-shared keys, raw public keys, or X.509
certificates. The Bootstrap Server then provisions the client with
the security parameters and server information required to register
with one or more LwM2M servers. Once bootstrapping is complete, the
client registers with these servers and transitions to normal
operation, where the servers perform device management tasks such as
data collection, control of device functions, and configuration of
access control. In deployments that use X.509 certificates, the
Bootstrap Server may rely on protocols such as Enrollment over Secure
Transport (EST) to provision certificates instead of directly
installing keys on the device.
OMA has the following characteristics:
* *Terms*:
- _Bootstrapping_ and _Unbootstrapping_: Bootstrapping is used
for describing the process of providing an IoT device with
credentials and information of one or more LwM2M servers.
Interestingly, the transport bindings specification
[oma-transport] also uses the term unbootstrapping for the
process where objects corresponding to an LwM2M Server are
deleted on the client.
- _Provisioning_ and _configuration_: terms used to refer to the
process of providing some information to a LwM2M client.
- _Discovery_: term for the process by which a LwM2M Bootstrap-
Server or LwM2M Server discovers objects, object instances,
resources, and attributes supported by RESTful interfaces of a
LwM2M Client.
Sethi, et al. Expires 7 January 2027 [Page 13]
Internet-Draft IoT initial security setup July 2026
- _Register_ and _De-register_: Register is the process by which
a client device sets up a secure association with an LwM2M
Server and provides the server with information about objects
and existing object instances of the client. De-register is
the process by which the client deletes information about
itself provided to the LwM2M server during the registration
process.
- _Intialization_: term for the process by which an LwM2M
Bootstrap-Server or LwM2M Server deletes objects on the client
before performing any write operations.
* *Players*: Device manufacturers or Smartcard manufacturers are
responsible for providing client IoT devices with initial
information and credentials of LwM2M Bootstrap-Server and/or LwM2M
server.
* *Initial beliefs assumed in the device*: The client at the very
least has the necessary information to trust the LwM2M bootstrap
server.
* *Processes*: LwM2M does not require any actions from the device
owner/user. Once the device is registered with the LwM2M server,
various actions related to device management can be performed by
device owner/user via the LwM2M server.
* *Knowledge imparted to the device after protocol execution*: After
the bootstrapping is performed, the LwM2M client can register
(Security object and Server object) with the LwM2M servers.
2.5. Nimble out-of-band authentication for EAP (EAP-NOOB)
Extensible Authentication Protocol (EAP) framework provides support
for multiple authentication methods. EAP-NOOB [RFC9140] defines an
EAP method intended as a generic bootstrapping solution for IoT
devices that do not have pre-configured authentication credentials
and are not yet registered with an authentication server. The
protocol relies on a user-assisted out-of-band (OOB) channel between
the device (peer in EAP terminology) and the server to establish
initial trust. The application server may be part of the local
deployment environment or a remote service, and may be operated
either by the device owner or by a third party such as the device
manufacturer. EAP-NOOB operates within the existing Authentication,
Authorization, and Accounting (AAA) infrastructure [RFC2904],
allowing authentication exchanges to be routed to the appropriate
server.
Sethi, et al. Expires 7 January 2027 [Page 14]
Internet-Draft IoT initial security setup July 2026
During bootstrapping, the device and server establish a secure
association by combining an ephemeral key exchange with information
transferred over the OOB channel, which binds the external user-
assisted interaction to the ongoing authentication session. The user
transfers the OOB message between the device and the server, for
example using QR codes, NFC, or other mechanisms, depending on device
capabilities. Once the exchange is complete, the device and server
derive shared keying material that can be used both for network
access (through the EAP authenticator) and for application-layer
security with the server. This approach allows devices without prior
credentials to be securely registered and authenticated.
EAP-NOOB has the following characteristics:
* *Terms*:
- _Bootstrapping_: used to describe the entire process involved
during the initial security setup of an IoT device. The
specification does not use separate terms or distinguish the
process of obtaining identifier and credentials for
communicating with an application server where the user has an
account or for network connectivity.
- _Registration_: describes the process of associating the device
with a user account on an application server.
* *Players*: The device owner/user is responsible for transferring
an OOB message necessary for protocol completion. The application
server where the device is registered may be provided by different
service providers including the device manufacturer or device
owner. The local network needs standard AAA configuration for
routing EAP-NOOB sessions to the application server chosen by the
device owner/user.
* *Initial beliefs assumed in the device*: EAP-NOOB does not require
devices to have any pre-installed credentials but expects all
devices to use a standard identifier (noob@eap-noob.arpa) during
initial network discovery. The devices also populate the PeerInfo
JSON object using during the boostrapping process and may contain
information such as the MAC Address, Manufacturer name, and model
information.
* - *Processes*: The EAP-NOOB setup process begins when the IoT
device (peer) is powered on and performs network discovery,
initiating EAP exchanges with one or more candidate networks
using the well-known identity (noob@eap-noob.arpa). The device
and the server perform an Initial Exchange, during which they
negotiate I/O capabilities and perform an ephemeral Diffie-
Sethi, et al. Expires 7 January 2027 [Page 15]
Internet-Draft IoT initial security setup July 2026
Hellman key exchange. Based on the I/O capabilities, either
the peer or the server generates an out-of-band (OOB) message.
In the OOB Step, the user transfers the OOB message from one
side to the other (e.g., by scanning a QR code or using NFC, as
the specification is agnostic to the transfer method). While
this manual transfer is pending, the peer and server may
execute a Waiting Exchange to proble if the OOB step has
completed. Once the OOB information is delivered, the
Completion Exchange binds the OOB channel to the ongoing EAP
session, confirms the key exchange, and derives shared keying
material. Part of this keying material is delivered to the
authenticator (e.g., in Wi-Fi networks for performing the 4-way
handshake), and part of it is exported as an Application Master
Session Key (AMSK) which can be used for application-layer
security between the device and server. Lastly, an optional
Reconnect Exchange can be used in subsequent sessions to
securely re-authenticate the device and refresh keys without
repeating the user-assisted OOB step.
- *Knowledge imparted to the device after protocol execution*:
After the EAP-NOOB bootstrapping process is complete, the peer
device (and the server) possess shared keying material,
including the EAP Master Session Key (MSK), which can be used
by the network authenticator (for example, a Wi-Fi access
point) to provide network access, and an Application Master
Session Key (AMSK), which can be used for application-layer
security between the device and the server. The device and
server also establish a persistent association that includes a
Peer Identifier (PeerID) assigned to the device for use in
subsequent authentication exchanges, along with an optional
Network Access Identifier (NAI). In addition, the device
stores persistent key material (Kz) and related state, enabling
the device and server to re-establish trust and perform future
authenticated sessions without repeating the full user-assisted
out-of-band procedure.
2.6. Open Connectivity Foundation (OCF)
The Open Connectivity Foundation (OCF) [ocf] defines the set of
procedures required to bring a device from an unowned, factory
default state into an operational and managed state as onboarding. A
central element of OCF onboarding is ownership transfer, which
establishes a legitimate device owner and forms the root of trust for
subsequent security configuration and access control. Ownership
transfer is performed with the assistance of an Onboarding Tool
(OBT), a logical entity under the control of the user or
administrator that interacts with the device to authenticate it,
establish secure communication, and provision initial security
Sethi, et al. Expires 7 January 2027 [Page 16]
Internet-Draft IoT initial security setup July 2026
credentials. The OBT may be implemented, for example, as part of a
home gateway, smartphone application, or device management tool.
OCF specifies several Ownership Transfer Methods (OTMs) that define
how the device and the OBT authenticate each other and establish a
secure channel during onboarding. These include Just Works
(unauthenticated Diffie-Hellman), Random PIN (DTLS-PSK using a
randomly generated PIN entered by the user), and Manufacturer
Certificate-based authentication, alongside support for vendor-
specific methods. Once ownership has been established, the device
can be provisioned with credentials and information about dedicated
Access Management Services (AMS) and Credential Management Services
(CMS) for ongoing lifecycle management.
OCF has the following characteristics:
* *Terms*:
- _Onboarding_: is the umbrella process that transitions a device
from an initial unowned state to a fully operational managed
state and includes discovery, ownership transfer, credential
provisioning, and initialization of access control and
credential management services.
- _Discovery_: process by which an Onboarding Tool (OBT) locates
unowned or owned devices on the network and learns their basic
identifiers, security state, and supported Ownership Transfer
Methods.
- _Enrollment_: used in the context of certificate enrollment to
obtain a certificate from the CMS after onboarding is complete.
- _Configuration_: refers to the act of setting or modifying the
state of device resources through their exposed interfaces.
Configuration applies to both functional resources and security
related resources such as identity and credentials.
- _Provisioning_: refers to security focused configuration
operations performed during and after ownership transfer that
establish or modify the trust relationships of a device.
Provisioning includes the configuration of ownership
information, security credentials, trust anchors, access
control policies, and security service endpoints, and defines
the security domain in which the device operates.
Sethi, et al. Expires 7 January 2027 [Page 17]
Internet-Draft IoT initial security setup July 2026
- _Registration_: act of associating a device with its security
domain and management services after ownership transfer.
Registration typically includes provisioning the locations and
identities of the Access Management Service (AMS) and
Credential Management Service (CMS).
* *Players*: The device manufacturer is responsible for provisioning
the device during manufacturing with a unique device identity
(UUID) and, where certificate based ownership transfer is used, a
manufacturer issued X.509v3 certificate and corresponding trust
anchors. The Onboarding Tool (OBT) may be implemented as a
smartphone application, a home gateway, or a dedicated device
management system, and is often provided by the device
manufacturer or platform vendor. The device owner/user is
responsible for initiating the onboarding process and establishing
ownership of the device using the OBT. During the ownership
transfer process, the user may be required to input a randomly
generated PIN or explicitly approve a Just Works transfer, with
the expectation that this occurs in a physically and logically
secure environment. For certificate based ownership transfer
methods, the user or owner typically selects the correct device
from a list presented by the OBT, identified by its Device UUID or
additional device metadata. After onboarding is complete and
information about the Credential Management Service (CMS) and the
Access Management Service (AMS) has been provisioned into the
device, these services become responsible for ongoing security
provisioning, including credential lifecycle management, access
control configuration, and authorization policy updates.
* *Initial beliefs assumed in the device*: OCF requires devices to
have a unique device identityty (UUID). Depending on the
supported Ownership Transfer Methods, the device may also have a
manufacturer issued X.509 certificate and corresponding private
key. Additionally, the device is initialized with a default,
restrictive Access Control List (ACL) that permits anonymous,
unauthenticated access only to the specific security resources
required for onboarding while blocking access to all other device
resources until ownership is established.
* *Processes*: OCF onboarding process begins when a device that is
in an unowned or reset state is discovered by an Onboarding Tool
(OBT) typically by sending a multicast CoAP request. Once
discovered, the OBT initiates an Ownership Transfer Method (OTM)
to establish a secure relationship between the device and the new
owner. Depending on the selected OTM, the device and OBT perform
an authenticated or unauthenticated key establishment procedure,
such as a Just Works Diffie Hellman exchange, a PIN based
authenticated key exchange, or a certificate based authentication
Sethi, et al. Expires 7 January 2027 [Page 18]
Internet-Draft IoT initial security setup July 2026
using manufacturer installed credentials. During this phase, a
secure communication channel is established and ownership of the
device is transferred by provisioning an Owner Credential and
updating the device ownership state. Upon successful ownership
transfer, the device accepts privileged configuration operations
from the OBT, regardless of existing access control entries. The
OBT then provisions the device with security relevant information
required for operational use, including credentials and trust
anchors for interacting with the Credential Management Service
(CMS) and the Access Management Service (AMS), as well as initial
access control policies. After these provisioning steps are
completed, the device transitions into an owned and operational
state. Subsequent security provisioning and configuration
operations are performed through the CMS and AMS, allowing
credentials, access control entries, and other security parameters
to be updated over the device lifetime without repeating the
ownership transfer process.
* *Knowledge imparted to the device after protocol execution*: Upon
successful completion of the OCF onboarding and Ownership Transfer
process, the device transitions from an unowned state to an owned
and operational state. The device now possesses an Owner
Credential, which cryptographically binds the device to its
legitimate owner and allows it to mutually authenticate the Device
Ownership Transfer Service (DOTS) in the future. This credential
may take the form of a shared secret, a public key certificate, or
another credential type defined by the selected Ownership Transfer
Method. In addition, the device is provisioned with the
identities and network locations of core OCF security services,
including the Credential Management Service (CMS) and the Access
Management Service (AMS). The device trusts these services to
manage security credentials and access control policies on behalf
of the owner.
2.7. Bootstrapping Remote Secure Key Infrastructures (BRSKI)
Bootstrapping Remote Secure Key Infrastructures (BRSKI) [RFC8995]
defines a bootstrapping solution that enables devices to securely
join the device owner's network domain using manufacturer-installed
IEEE 802.1AR [ieee8021ar] certificates, together with a manufacturer-
provided Internet service called the Manufacturer Authorized Signing
Authority (MASA). The solution assumes that an unconfigured device,
called a Pledge, has access to the local network and can establish
provisional connectivity to a domain Registrar, either directly or
via a local proxy (Join Proxy). The goal of the protocol is to
securely provide the Pledge with the trust anchor of the owner's
domain, allowing it to identify and trust future interactions within
that domain.
Sethi, et al. Expires 7 January 2027 [Page 19]
Internet-Draft IoT initial security setup July 2026
During bootstrapping, the Pledge presents its manufacturer-installed
credential to the Registrar, which authenticates the device and,
based on its configured trust in device manufacturers and
identifiers, contacts the MASA to obtain a signed voucher. This
voucher proves that the Pledge is authorized to join the specific
owner's domain. After verifying the voucher, the Pledge accepts the
domain trust anchor and establishes trust in the owner network. If
the owner network provides additional services such as Enrollment
over Secure Transport (EST), the device may subsequently enroll and
obtain a locally issued certificate bound to the owner domain,
enabling secure communication and management within the network.
BRSKI has the following characteristics:
* *Terms*:
- _Bootstrapping_: used to describe the overall process by which
a device transitions from an unaffiliated factory state to
being a trusted member of an owner network. In BRSKI,
bootstrapping encompasses device discovery of the local domain,
interaction with the registrar and manufacturer authorized
signing authority, validation of a voucher, and establishment
of trust in the owner domain. The term broadly covers all
protocol steps required before the device can securely operate
in the network.
- _Provisioning_: used in a general sense to refer to the act of
supplying a device with the information and trust anchors it
needs to operate securely in a specific domain. In BRSKI,
provisioning primarily occurs when the device accepts the
domain trust anchor conveyed in the voucher and optionally
receives a locally issued device certificate. The term is not
used as a formally distinct protocol phase and is largely
interchangeable with bootstrapping in descriptive text.
- _Enrollment_: used to refer specifically to the process of
obtaining a locally issued identity within the owner domain.
This typically occurs after imprinting and is realized through
Enrollment over Secure Transport, where the device enrolls with
a local certification authority to obtain a Locally Issued
Device Identifier certificate.
- _Onboarding_: not used as a primary or formally defined term.
It appears informally to generally refer to the broader act of
bringing a device under the control of an owner network.
Sethi, et al. Expires 7 January 2027 [Page 20]
Internet-Draft IoT initial security setup July 2026
- _Join_: used to describe the act of a device attempting to
attach itself to a specific owner network. It reflects the
device intent to become a member of the domain but does not by
itself imply trust has been established.
- _Imprint_: used to describe the transition where the device
accepts the owner domain trust anchor provided in the voucher.
Imprinting marks the point at which the device irrevocably
binds itself to the owner domain by trusting the pinned domain
certificate.
* *Players*: The device manufacturer is responsible for installing
the IEEE 802.1AR IDevID certificate and private key during
manufacturing, along with the trust anchor required to verify
vouchers signed by the Manufacturer Authorized Signing Authority
(MASA) and the MASA service location itself. The manufacturer
must also operate the MASA service, which authorizes devices to
join specific owner domains by issuing signed vouchers, and
maintain sufficient asset tracking to associate device identities
such as serial numbers with authorized owners.
On the owner side, the network into which the device is deployed
must provide initial connectivity, often via a proxy, to allow the
device to communicate with the registrar and indirectly with the
MASA before it has full network access. The device owner operates
a registrar that authenticates devices using their manufacturer
installed certificates, maintains a list of trusted manufacturers
and corresponding MASA services, and tracks the identities of
devices that are permitted to join the domain. If the owner
intends to issue locally scoped identity credentials, the owner
must additionally deploy and operate an Enrollment over Secure
Transport (EST) server to provision domain specific certificates
to devices after successful bootstrapping.
* *Initial beliefs assumed in the device*: BRSKI requires each
device to possess an IEEE 802.1AR Initial Device Identifier
(IDevID) certificate and associated private key. In addition, the
device must include a built in trust anchor that enables it to
validate vouchers signed by the manufacturer's Manufacturer
Authorized Signing Authority (MASA). The device is also
configured with the MASA service location, typically expressed as
a URI embedded in the IDevID certificate.
* *Processes*: BRSKI assumes that devices are manufactured with an
IEEE 802.1AR Initial Device Identifier certificate and the
information required to contact the manufacturer authorized
signing authority. When a device is powered on in the owner
network, it discovers the owner proxy using link local discovery
Sethi, et al. Expires 7 January 2027 [Page 21]
Internet-Draft IoT initial security setup July 2026
mechanisms and establishes provisional network connectivity.
Through this proxy, the device connects to the domain registrar
using a provisional (unauthenticated) TLS connection and presents
its IDevID for identification. The device then generates a
voucher request and sends it to the registrar, which validates the
request and contacts the appropriate MASA. The manufacturer
verifies the device identity and issues a signed voucher that
authorizes the device to join the owner domain. This voucher is
relayed back to the device via the registrar, where the device
verifies the manufacturer signature and associated freshness
information. Upon successful verification, the device imprints by
accepting the owner domain certificate conveyed in the voucher as
a new trust anchor. If supported by the owner network, the device
then enrolls with a local EST server to obtain a locally issued
device identifier certificate for ongoing authentication and
management. After these steps are completed, the device is able
to securely participate in the owner network. With BRSKI, once
the required infrastructure such as the registrar, proxy, and
manufacturer services is in place, it enables a bootstrapping
experience that requires only physical installation, connectivity,
and powering up of the device.
* *Knowledge imparted to the device after protocol execution*: After
the BRSKI bootstrapping process, the device obtains the CA
fingerprint of the owner's network domain, which establishes the
basis for trusting future interactions with the owner network. If
enrollment is performed, the device additionally obtains a Locally
Issued Device Identifier (LDevID) certificate. With this trust
anchor and optional local identity in place, the device can
securely communicate with domain services, participate in secure
routing, and be managed by the owner using domain specific
management protocols.
2.8. Secure Zero Touch Provisioning (SZTP)
Secure Zero Touch Provisioning (SZTP) [RFC8572] defines a
bootstrapping strategy that enables devices to securely obtain
configuration information with minimal installer input, beyond
physical placement and cable connections. The goal of SZTP is to
allow a device to establish a secure NETCONF [RFC6241] or RESTCONF
[RFC8040] connection to a deployment-specific network management
system (NMS). The device is provisioned during manufacturing with an
initial identity, typically an IEEE 802.1AR certificate, and a set of
trust anchors and bootstrap server information that allow it to
locate and communicate with bootstrap services.
Sethi, et al. Expires 7 January 2027 [Page 22]
Internet-Draft IoT initial security setup July 2026
When the device is powered on, it discovers bootstrap servers using
mechanisms such as DHCP, DNS, or preconfigured information, and
retrieves an owner certificate and an ownership voucher [RFC8366].
The ownership voucher, signed by the manufacturer, binds the device
identity to the intended owner and allows the device to verify that
it is communicating with an authorized domain. After verifying the
owner certificate and voucher, the device establishes trust in the
owner domain and retrieves onboarding information, which may include
boot images, configuration data, and scripts required for operation.
Using this information, the device securely connects to the
designated network management system and transitions into an
operational state.
SZTP has the following characteristics:
* *Terms*:
- _Bootstrapping_: used to describe the entire process involved
during the initial security setup of devices. It involves the
device authenticating itself with manufacturer-issued
certificates, fetching the owner certificate and ownership
voucher, and retrieving the signed or encrypted onboarding
information, such as the boot image, initial configuration, and
scripts.
- _Provisioning_: refers to the process of providing all the
necessary bootstrap information to a device so that it can
become functional. In some sense, the terms bootstrapping and
provisioning are used interchangeably because, for provisioning
the bootstrap information onto the device, it is necessary to
bootstrap the device. In fact, the specification also refers
to Secure Zero Touch Provisioning (SZTP) as a _bootstrapping
strategy_. Interestingly, even though the title of the protocol
specification includes the word provisioning, it is used much
less than bootstrapping in the specification text.
- _Onboarding_: used to refer to the information that the device
needs to join the owner's network. In particular, the
onboarding information includes the boot image the device must
run, an initial configuration the device must use, and scripts
that the device must successfully execute. Note that in SZTP,
onboarding information is not the entire set of information
that the device needs for bootstrapping. Prior to obtaining
the onboarding information, the device also needs the owner
certificate and ownership voucher to verify the onboarding
information received later.
Sethi, et al. Expires 7 January 2027 [Page 23]
Internet-Draft IoT initial security setup July 2026
- _Enrollment_: describes the process by which the device owner
registers with the device manufacturer, ensuring that the
manufacturer recognizes the owner and issues the necessary
ownership vouchers. This crucial association is later used by
the manufacturer to provide the owner with the serial numbers
of the devices based on the order. The owner then uses these
serial numbers during the bootstrapping process to verify the
devices as their own.
- _Discovery_: used for describing the process by which devices
discover sources of information, particularly bootstrap servers
that are not already known to the device. This discovery
typically happens via redirects from trusted bootstrapping
servers.
* *Players*: SZTP requires significant involvement of the device
manufacturer. The manufacturer is responsible for installing the
client identity certificate and trust anchors for verifying
bootstrapping server certificates and ownership vouchers during
the manufacturing process. Additionally, the device manufacturer
must support the enrollment of the owner by verifying the owner
certificate and issuing an ownership voucher. After receiving an
order for devices from an enrolled owner, the manufacturer needs
to inform the owner of the serial numbers corresponding to the
ordered devices. This naturally necessitates robust asset
tracking systems. Lastly, the manufacturer may also need to
operate well-known bootstrapping servers that the device contacts
to retrieve the owner certificate and ownership voucher. At the
same time, the device owner also carries substantial
responsibility, including enrolling in the manufacturer's SZTP
program, managing the keys associated with the owner certificate,
and maintaining the network infrastructure to authenticate the
device's serial number and confirm its association with the order
placed with the manufacturer. Once authenticated, the owner is
responsible for sending signed and/or encrypted onboarding
information to the device.
* *Initial beliefs assumed in the device*: SZTP requires devices to
have a pre-configured state, including a client X.509 certificate
for TLS client authentication to bootstrap servers. While the
specification allows the use of HTTP authentication with
passwords, it typically relies on X.509 certificates in the form
of IDevID certificates, as defined in [ieee8021ar]. Additionally,
devices must have a list of trusted bootstrap servers and trust
anchor certificates for verifying bootstrap server certificates
and ownership vouchers signed by the manufacturer. All this
information, including the client TLS certificate and trust
anchors, must be installed during manufacturing.
Sethi, et al. Expires 7 January 2027 [Page 24]
Internet-Draft IoT initial security setup July 2026
* *Processes*: A precursor for the device to bootstrap and join the
owner's network is the enrollment of the owner with the
manufacturer and the setup of all necessary network infrastructure
to authenticate the device. Thereafter, the device can use
various sources such as Domain Name System (DNS), Dynamic Host
Configuration Protocol (DHCP) options, removable storage (e.g.,
USB drives), or knowledge of well-known bootstrapping servers to
locate the owner certificate and ownership voucher. These methods
can be used in parallel to expedite the process. Once the owner
certificate and ownership voucher are obtained and verified, the
device receives, verifies/decrypts the signed and/or encrypted
onboarding information, including boot images, configuration
details, and scripts. With the image, configuration, and scripts,
the device can securely join the owner's network management system
(NMS). Unlike other protocols, once all the infrastructure has
been set up, no actions are needed on the device itself other than
its physical placement, cabling, and booting up.
* *Knowledge imparted to the device after protocol execution*: After
the SZTP bootstrapping process, the device possesses all necessary
information, called as bootstrapping data, for secure
communication with the deployment-specific NMS. This
bootstrapping data includes the ownership voucher, the owner
certificate, and onboarding information. The owner certificate
and ownership voucher are used to verify the onboarding
information, which encompasses the boot image and its hash or
signature, initial configuration, and pre- and post-configuration
scripts to be executed by the device.
2.9. FIDO Device Onboard (FDO)
The Fast IDentity Online Alliance (FIDO) Device Onboard (FDO)
specification [fidospec] defines an automated onboarding protocol
that allows an IoT device to be securely transferred from its
manufacturer-controlled factory state to an owner-selected management
platform. A central feature of FDO is late binding: the final owner
and target IoT platform do not need to be known when the device is
manufactured. Instead, the device is initialized during
manufacturing with device-specific credentials and rendezvous
information, while the manufacturer creates an ownership voucher that
is transferred separately through the supply chain to the eventual
owner. FDO protocol messages are encoded using Concise Binary Object
Representation (CBOR) [RFC8949] and may be transported over
application-layer protocols such as CoAP [RFC7252]. FDO assumes that
the device has IP connectivity when onboarding begins; how this
connectivity is established is outside the protocol, although the
specification mentions that deployments may use mechanisms such as an
HTTP proxy to provide initial reachability.
Sethi, et al. Expires 7 January 2027 [Page 25]
Internet-Draft IoT initial security setup July 2026
When the device is later powered on, it uses its stored rendezvous
information to locate the onboarding service associated with the
current owner. The device and owner authenticate each other using
the device credentials and the ownership voucher, allowing the owner
to prove legitimate control of the device and the device to attest
its identity. After this mutual authentication, the owner's
onboarding service establishes cryptographic control of the device
and securely provides the operational information needed for use,
such as management service endpoints, network or application
configuration, and credentials for the selected IoT platform. FDO
also supports subsequent ownership transfer by allowing the current
owner to update the device's onboarding state and create a new
voucher for a future owner.
FIDO has the following characteristics:
* *Terms*:
- _Onboarding_: is the central term used in FDO and represents
the complete automated process that transitions a device from
its factory state to operational use under the owner's
management. It covers the discovery of the owner through the
rendezvous server, the execution of TO1 and TO2, and the mutual
authentication and secure exchange of configuration and
credentials between the device and the owner's onboarding
service. The ability to determine the final owner and
configuration long after the device has been manufactured is
referred to as _late binding_.
- _Provisioning_: used interchangeably with the term onboarding
to refer to the entire process of making the device
operational. The introduction section of the specification
even states _FDO is a device onboarding scheme from the FIDO
Alliance, sometimes called "device provisioning"_
- _Initialization_: used to refer to the Device Initialization
(DI) protocol, which occurs during device manufacturing and
installs on the device all initial information, including the
attestation key pair, unique identifier (GUID), rendezvous
server information, manufacturer public key hash, and the
secret used for computing the device HMAC. During the same
phase, the manufacturer's tools generate the ownership voucher
that corresponds to the device's credentials.
Sethi, et al. Expires 7 January 2027 [Page 26]
Internet-Draft IoT initial security setup July 2026
- _Resale_: refers to the protocol actions that the current
device owner can perform to transfer ownership of the device to
a new owner without the involvement of the original
manufacturer. This is made possible by the ability of the
owner to update the device's credentials and generate a new
ownership voucher during the onboarding process.
- _Re-provisioning_: refers to the complete onboarding process
being executed again for a new owner.
* *Players*: The device manufacturer plays a significant role in
FDO. During production, the manufacturer provisions each device
with a unique identifier (GUID), an asymmetric key pair used for
cryptographic attestation (based on Intel EPID or standard ECDSA),
a hash of the manufacturer's public key (used for verifying the
ownership voucher chain), and detailed rendezvous information
describing how the device can later locate its onboarding
infrastructure. These rendezvous instructions may include DNS
names, IP addresses, certificate hashes for TLS pinning, and even
information such as a Wi-Fi SSID and passphrase to enable initial
connectivity to the rendezvous server. The manufacturer also
ensures that the device generates a symmetric secret, which is
then used to compute an HMAC value over elements such as the
device's GUID, rendezvous information, and manufacturer public
key. This HMAC, unique to each unit, is embedded into a signed
ownership voucher created by the manufacturer and transferred
separately through the supply chain, establishing a verifiable
link between the physical device and its digital identity. The
specification does not prescribe who operates the rendezvous
servers and refers to them generically as Internet services; in
practice, they are often maintained by the manufacturer but could
be hosted by other entities.
The final device owner, who seeks long-term management of the
device for tasks such as retrieving data and performing software
updates, either operates a dedicated onboarding service or
delegates this function to another entity. The owner maintains a
key pair whose public key is linked to the last entry in the
ownership voucher and uses it to register device ownership with a
rendezvous server. During the TO2 onboarding protocol, the owner
authenticates to the device using its private key and the voucher,
while the device attests its identity in return. Once mutual
trust is established, the owner's onboarding service securely
provisions operational credentials and configuration data, after
which the device updates its internal FDO credentials to enable
future resale or re-onboarding as needed.
Sethi, et al. Expires 7 January 2027 [Page 27]
Internet-Draft IoT initial security setup July 2026
FDO can be seen as a more elaborate evolution of SZTP. While both
rely on manufacturer-installed credentials and trusted servers for
redirection, FDO introduces a tighter cryptographic binding
between the device and its ownership voucher through the embedded
HMAC mechanism and supports verifiable ownership transfers across
multiple entities. This design adds complexity but provides the
important advantage that devices remain manageable even if the
original manufacturer ceases operation, since ownership and
onboarding continuity can be maintained by the last legitimate
owner, who can update all information except the device's
attestation keys.
* *Initial beliefs assumed in the device*: FDO assumes that each
device is provisioned during manufacturing with a unique device
identifier (GUID), a cryptographic key pair used for device
attestation, a hash of the manufacturer's public key for verifying
the ownership voucher chain, and the rendezvous information needed
to discover onboarding services. The rendezvous information may
include DNS names, IP addresses, supported communication
protocols, certificate hashes for authenticating the rendezvous
server, and even Wi-Fi SSID and passphrase details to enable
initial network connectivity. The device also holds a symmetric
secret used to compute and verify HMAC values that
cryptographically bind the device's internal identity to its
ownership voucher.
* *Processes*: A precursor for an FDO device to onboard is the DI
protocol, which imparts the information stated above. At the same
time, the manufacturer creates an ownership voucher linked to the
device through a device-generated HMAC value. The final owner,
after receiving this voucher, possibly transferred through several
intermediaries in the supply chain, registers the address of its
onboarding service with a rendezvous server using the device GUID
through the TO0 protocol. When the device is powered on, it
follows its stored rendezvous instructions and performs the TO1
protocol to contact a rendezvous server, from which it retrieves
the signed blob of data containing the network location of the
owner's onboarding service. The device may optionally
authenticate the rendezvous server through TLS if the rendezvous
information specifies HTTPS and includes certificate hashes for
pinning. The device then initiates a direct connection to the
onboarding service, where the TO2 protocol is executed to perform
mutual authentication and ownership transfer. During this
process, the owner proves ownership using the ownership voucher,
while the device authenticates itself using its attestation
credentials. The device also verifies the authenticity of the
signed blob received from the rendezvous server using the now-
trusted owner key. After successful verification on both sides, a
Sethi, et al. Expires 7 January 2027 [Page 28]
Internet-Draft IoT initial security setup July 2026
secure communication channel is established through which the
owner's onboarding service transfers operational data such as
network configuration parameters, addresses and endpoints of
management servers or IoT platforms, authentication credentials
such as keys, certificates, tokens, or shared secrets. The device
applies these configurations and updates its internal FDO
credentials with new information provided by the owner, which may
include an updated device identifier, new rendezvous information,
and a new trust anchor derived from the owner's public key.
Similar to SZTP, once the supporting infrastructure such as the
ownership voucher and rendezvous server registration has been set
up, FDO enables an experience where only the physical installation
and powering of the device are required for it to securely join
the owner's management system or IoT platform. The specification
does mention a _Trusted Installer_ mode where the device is
provided with advice and input during the onboarding process from
the installer, however this is currently not defined and is left
for future releases.
* *Knowledge imparted to the device after protocol execution*: After
the FDO onboarding process is complete, the device possesses all
configuration and credential information necessary for secure
operation under the new owner's management domain. This includes
data transferred from the owner's onboarding service, which may
contain network configuration parameters, the address and endpoint
URLs of the final management server or IoT platform, and the
credentials such as keys, certificates, tokens, or shared secrets
required for the device to authenticate securely to these
services. The data may also include instructions for installing
required agents, drivers, or firmware updates. In addition, the
device may receive and update its internal FDO credentials with
new information supplied by the owner, which can include an
updated device identifier (GUID), revised rendezvous server
information, and a new hash of the owner's public key to establish
a renewed trust anchor.
2.10. Thread
Thread Mesh Commissioning Protocol (MeshCoP) [threadcommissioning]
defines commissioning as the process by which a new device, called a
Joiner, is authorized to join an existing Thread mesh network. The
process is coordinated by a Commissioner, which may be implemented as
a smartphone application, a border router service, or another
management tool controlled by the device owner. The Commissioner
first authenticates itself to the existing Thread network using the
network's commissioning credential and obtains authority to act as
the active Commissioner. It can then authorize selected Joiners to
enter the network.
Sethi, et al. Expires 7 January 2027 [Page 29]
Internet-Draft IoT initial security setup July 2026
A Joiner does not initially possess the Thread Network Key and
therefore cannot yet participate as a trusted member of the mesh.
Instead, the Joiner and Commissioner authenticate each other using a
device-specific PSKd, typically printed on the device or its
packaging and transferred to the Commissioner by the user. They then
perform a DTLS J-PAKE handshake, which may be relayed through
existing Thread infrastructure, including a Joiner Router and Border
Agent, so that the Commissioner does not need to communicate directly
over IEEE 802.15.4. Once the Joiner has been authenticated, the
Commissioner securely entrusts it with the Thread Network Key and
other operational parameters. The device can then attach to the mesh
and operate as a Thread node.
Thread has the following characteristics:
* *Terms*:
- _Commissioning_: refers to the entire process by which a new
device is authorized to join an existing Thread network. It
encompasses the discovery of commissioning-capable networks,
authentication of the Commissioner, authentication of the
Joiner using a device-specific PSKd, and the secure delivery of
network credentials to the Joiner.
- _Petitioning_: refers specifically to the process by which a
prospective Commissioner requests authority from the Thread
network to act as the active Commissioner.
- _Discovery_: used for the mechanisms by which Joiner devices
identify Thread networks that are currently accepting new
devices.
- _Provisioning_: refer narrowly to the act of delivering
credentials to a Joiner once it has been authenticated.
- _Entrust_: protocol step in which the Commissioner securely
provides the Joiner with the Thread Network Key and other
essential network parameters. Entrusting marks the transition
point at which the joining device gains the cryptographic
material required to participate as a trusted member of the
mesh.
- _Attach_: refers to the process that follows commissioning, in
which the newly provisioned device uses the Network Key to
perform Mesh Link Establishment (MLE) with a parent router.
- _Join_: act of a device that is not yet a member of the Thread
mesh network joining the mesh network
Sethi, et al. Expires 7 January 2027 [Page 30]
Internet-Draft IoT initial security setup July 2026
* *Players*: The device manufacturer is responsible for provisioning
each device with a unique EUI-64 identifier and a Pre-Shared Key
for the Device (PSKd), making this credential available to the
user via physical labels or packaging. The device owner/user is
responsible for establishing the Thread network infrastructure
prior to commissioning. This includes deploying a functioning
Thread mesh with at least one Border Router and selecting a human-
readable Commissioning Credential (passphrase). This passphrase
is used to derive the PSKc (Pre-Shared Key for the Commissioner),
which allows the Commissioner to authenticate and communicate
securely with the network's Border Agent. Additionally, the user
must ensure an existing Thread device is in the vicinity of the
new Joiner to serve as the Joiner Router relay. The Commissioner
role may be fulfilled by functionality built into mobile operating
systems (Android/iOS) or via a manufacturer-supplied application.
Once the infrastructure is ready, the user is responsible for
inputting the new device's PSKd into the Commissioner to initiate
the mutually authenticated joining process.
* *Initial beliefs assumed in the device*: Thread mesh commissioning
assumes that a device is manufactured with a unique EUI-64 and a
Pre Shared Key for the Device (PSKd), which is a short human-
readable string intended to be conveyed out-of-band to an
authorized commissioner. This PSKd is typically printed on the
device itself, on an attached label, or on the original packaging,
and may also be encoded in a QR code to facilitate user entry.
The commissioning process relies on the assumption that this PSKd
is securely transferred by the user to the commissioner, such as a
smartphone application, and is used to initiate a mutually
authenticated commissioning exchange.
* *Processes*: The Thread mesh commissioning process begins when a
user authorized Commissioner, commonly implemented as an
application or service associated with a border router, discovers
the target Thread network via a Border Agent. In parallel, a
prospective device, known as a Joiner, is powered on and placed
into joining mode, where it actively scans available IEEE 802.15.4
channels and transmits Discovery Request messages. Existing
network nodes that are permitted to assist commissioning, such as
routers or router eligible end devices, respond with Discovery
Responses that advertise network identifiers and Steering Data,
enabling the Joiner to identify a compatible network. Before
authorizing new devices, the Commissioner must authenticate itself
by establishing a mutually authenticated DTLS session with the
Border Agent using the network commissioning credential and by
petitioning the network Leader to become the active Commissioner
for the partition. Once authorized, and after the user supplies
the Joiner specific PSKd to the Commissioner, the Joiner initiates
Sethi, et al. Expires 7 January 2027 [Page 31]
Internet-Draft IoT initial security setup July 2026
a DTLS based authentication exchange that is relayed through a
nearby Joiner Router and the Border Agent. This exchange uses a
password authenticated key exchange to mutually prove possession
of the PSKd. Upon successful authentication, a secure
commissioning session is established and the Commissioner performs
the Joiner Entrust procedure, securely delivering the Thread
Network Key and other operational parameters to the Joiner. With
these credentials installed, the Joiner terminates the
commissioning session and proceeds to attach to the mesh by
executing the Mesh Link Establishment protocol with a parent
router, thereby completing commissioning and becoming a fully
authenticated and operational node in the Thread network.
* *Knowledge imparted to the device after protocol execution*: After
completion of the Thread mesh commissioning process, the device
possesses all the information required to securely participate as
a node in the Thread network. This includes network parameters
such as the network name, channel, PAN identifier, and security
policy. The device is also provided with the Thread Network Key,
which serves as the root of trust for securing link-layer frames
and Mesh Link Establishment (MLE) communications, enabling it to
mutually authenticate neighboring nodes as legitimate members of
the same security domain. In addition, the device acquires
addressing and identity information, including the Mesh-Local
Endpoint Identifier (ML-EID) and Routing Locator (RLOC), which are
used to support efficient IPv6 routing and forwarding within the
mesh network.
3. Comparison
This section presents a comparative analysis of the protocols for
initial security setup of IoT devices. While the protocols originate
from different standards bodies and target diverse deployment
environments, they all address the same fundamental challenge of
transitioning a device from a factory default state to a secure and
operational state within a specific administrative, network, or
ownership domain. The comparison is structured along the terminology
used by each protocol, the players involved, the initial beliefs
assumed on the device, the process steps required to complete
onboarding, and finally, the knowledge imparted to the device after
protocol execution. The section also discusses broader implications
such as privacy considerations, resilience to supply chain attacks,
support for resale and reuse, and the trade offs between user
involvement and automation.
Sethi, et al. Expires 7 January 2027 [Page 32]
Internet-Draft IoT initial security setup July 2026
3.1. Comparison of terminology
The ten protocols covered in Section 2 highlight the lack of a common
lexicon for specifying initial security setup mechanisms for IoT
devices. While these protocols broadly aim to achieve the same
outcome, namely transitioning a device from a factory default state
to an operational and trusted network node, the terminology used to
describe this process is fragmented and often inconsistent. Although
it is difficult to identify strict patterns, several noteworthy
observations emerge from a comparison of the terminology used across
the protocols.
IETF protocols such as BRSKI, EAP NOOB, and SZTP predominantly rely
on _bootstrapping_ as the umbrella term for the entire process of
transitioning a device from a factory default state to an operational
state. Notably, SZTP includes the word provisioning in its title but
explicitly describes itself as a bootstrapping strategy within the
specification. In contrast, Wi-Fi DPP uses _bootstrapping_ more
narrowly as only the initial step of establishing trust through
mechanisms such as QR codes or NFC. This differs from the IETF
usage, where bootstrapping typically encompasses the complete
process.
OCF and FDO use _onboarding_ as the umbrella term for the entire
initial security setup. This terminology reflects a consumer or
enterprise management mindset, where a device is brought on board
into an administrative or ownership domain. In both protocols,
onboarding is closely tied to the concept of ownership transfer,
treating the device as an asset that moves between legal or
administrative entities such as manufacturers and owners. It is also
worth noting a subtle semantic distinction OCF and FDO define
onboarding primarily as a verb describing the process of
transitioning the device, whereas SZTP defines _onboarding
information_ as a noun referring to the payload, such as boot images,
configuration, and scripts, that the device receives.
Bluetooth Mesh and Wi Fi DPP use _provisioning_ as the umbrella term
for the entire process. This choice is potentially confusing, as
provisioning has traditionally referred to a specific sub step
involving the delivery of configuration data or credentials. By
elevating provisioning to describe the full lifecycle of initial
security setup, these protocols blur the conceptual boundary between
establishing trust and configuring operational parameters.
Sethi, et al. Expires 7 January 2027 [Page 33]
Internet-Draft IoT initial security setup July 2026
Thread uses the term _commissioning_ to describe entire initial setup
process. This term has possible roots in building automation and
industrial control systems, where it implies a technician physically
installing, verifying, and activating equipment. The choice of
commissioning reflects Thread's emphasis on local installation and
user assisted setup within a constrained network environment.
The term _provisioning_ exhibits the most severe semantic overloading
across protocols. In Wi Fi DPP and Bluetooth Mesh, provisioning
refers to the entire process of adding a device, including discovery,
authentication, and key distribution. In Thread and OCF,
provisioning is a more narrowly defined step that refers specifically
to the delivery of credentials and security related information after
authentication or ownership transfer. SZTP uses the term more
loosely and often interchangeably with bootstrapping, further
contributing to ambiguity.
The term _enrollment_ is predominantly used in protocols that rely on
X.509 certificates. EST and BRSKI use enrollment in its strict PKI
sense, referring to the process by which a device obtains a
certificate from a Certificate Authority. In contrast, Wi Fi DPP
uses enrollment more informally to mean authorizing a device to join
a network, largely detached from its PKI origins. SZTP uses
enrollment in a completely different manner, referring to the device
owner enrolling with the manufacturer, which reverses the more common
direction of device enrolling into a network or domain.
While strict harmonization of terminology across diverse standards is
impractical, this analysis reveals that much of the ambiguity arises
when terms describing atomic actions, such as transferring
credentials, are conflated with terms describing broader lifecycle
phases, such as transitioning a device from a factory state to an
operational state. To improve clarity, it is beneficial to adopt
clear umbrella terms such as _onboarding_ or _bootstrapping_ to
describe the comprehensive process. _Onboarding_ is preferable when
emphasizing ownership or administrative control transitions, as seen
in OCF and FDO, while _bootstrapping_ is more suitable for network
centric state transitions, as in BRSKI and SZTP. Action oriented
terms such as _provisioning_ and _authentication_ should be reserved
for specific sub phases within the umbrella process. In particular,
provisioning should ideally refer to the secure delivery of
configuration data or credentials, rather than the entire initial
security setup lifecycle.
Sethi, et al. Expires 7 January 2027 [Page 34]
Internet-Draft IoT initial security setup July 2026
3.2. Comparison of players
The burden of initial security setup can never truly be eliminated;
it is instead shifted between the entities involved. In some
protocols, this burden is placed primarily on the user, for example
by requiring QR code scanning or PIN entry, while in others it is
placed on the manufacturer, for example by requiring the operation of
online authorization services. In this section, we compare the
protocols based on the players involved and the expectations placed
upon them.
One important distinction lies in the role of the manufacturer. At
one end of the spectrum are protocols with zero preconfiguration,
such as EAP NOOB or Bluetooth Mesh using Just Works, which require
minimal manufacturer involvement. These protocols do not demand
preinstalled unique credentials or cryptographic secrets. Next are
protocols such as Thread, Bluetooth Mesh, and Wi Fi DPP, where the
manufacturer responsibility is largely limited to the factory. In
these cases, the manufacturer must generate a unique identifier, such
as an EUI 64, and provision a static bootstrapping secret or key,
such as a PSKd or a bootstrapping public key. This information is
typically made available physically on the device or its packaging,
for example as a printed label or QR code. OCF similarly requires
provisioning a unique device UUID and optionally a manufacturer
certificate. Once the device leaves the factory, the manufacturer
security role largely ends. At the other end of the spectrum are
protocols that require sustained manufacturer involvement. BRSKI,
SZTP, and FDO require manufacturers to install specific trust anchors
and IEEE 802.1AR IDevID certificates and to operate high availability
online services. In BRSKI, this role is fulfilled by the
Manufacturer Authorized Signing Authority. In SZTP and FDO,
manufacturers issue ownership vouchers and may also operate redirect
or rendezvous services. These protocols further require
manufacturers to track device serial numbers in order to validate
ownership claims, introducing significant logistical and operational
complexity.
The user or installer occupies very different positions across the
protocols. User centric protocols require active participation, such
as scanning QR codes, entering PINs, confirming device identity, or
approving commissioning actions. This is common in Wi Fi DPP,
Bluetooth Mesh, Thread, and OCF Just Works or Random PIN modes. In
contrast, protocols designed for minimal or no user interaction at
the device level, such BRSKI, SZTP, and FDO largely front load the
user responsibilities to system preparation activities such as
configuring backend services and defining policies, after which
devices can complete the protocol without further user involvement.
Sethi, et al. Expires 7 January 2027 [Page 35]
Internet-Draft IoT initial security setup July 2026
Administrator responsibilities also vary significantly between
protocols. Infrastructure centric protocols require the deployment
and operation of specific components. BRSKI requires a Registrar and
often an EST server. LwM2M requires a Bootstrap Server. FDO
requires a Rendezvous Server and an onboarding service. For EAP
NOOB, the administrator must configure the AAA infrastructure, such
as RADIUS, to route the special NAI noob@eap-noob.arpa to the
appropriate application server. In SZTP, the network must support
specific DHCP options or DNS records to allow devices to discover
bootstrap servers. In BRSKI, a Join Proxy is required to facilitate
communication between an unauthenticated pledge and the registrar.
The relationship between owner, user, and administrator is not always
clearly delineated. In a home network using Bluetooth Mesh or
Thread, the owner, administrator, and user are often the same
individual. In contrast, when BRSKI is used for large scale
deployments such as ISP provided CPE, the administrator and owner may
be the service provider, while the end user has little or no role in
the onboarding process beyond physically connecting the device.
Another important dimension of comparison is whether a protocol
relies primarily on local actors or remote infrastructure. Protocols
such as Thread, Bluetooth Mesh, and Wi Fi DPP are largely local in
nature and can operate without continuous Internet connectivity.
Others, such as BRSKI, SZTP, EST, and FDO, introduce additional
remote players operated by manufacturers or service providers,
including certificate authorities, manufacturer authorization
services, bootstrap servers, and rendezvous services. EAP NOOB also
relies on a remote authentication server, although this server may be
colocated with local infrastructure such as an access point. One
advantage of EAP based approaches is that devices can communicate
securely with remote servers before obtaining full IP connectivity, a
capability that is inherent to EAP. A general trend across protocols
is the gradual introduction of optional remote components even in
traditionally local schemes, such as DPP over TCP or remote
provisioning in Bluetooth Mesh, reflecting the practical benefits of
centralizing logic and state in backend services.
3.3. Comparison of initial beliefs
Protocols can be grouped into four broad categories based on the type
and strength of identity and credentials that are imparted to the
device during manufacturing or prior to deployment. The choice of
category has significant implications for supply chain complexity,
user involvement, scalability, and achievable security properties.
Sethi, et al. Expires 7 January 2027 [Page 36]
Internet-Draft IoT initial security setup July 2026
* *The Blank Slate (No Cryptographic Secrets)*: In this category,
devices are assumed to have no pre-installed cryptographic secrets
or unique credentials. Trust is established entirely through
user-assisted mechanisms. Examples include OCF Just Works, OCF
Random PIN, and EAP-NOOB. Security in this category relies
heavily on the user's ability to correctly associate the physical
device in their possession and complete the procedure securely
(e.g. using Just Works in a physically secure environment).
* *Static Symmetric Secrets*: These protocols assume that a shared
secret or password is installed at manufacturing time. In Thread,
the device holds a unique EUI-64 and a PSKd (Pre-Shared Key for
Device). The trust model assumes that possession of the PSKd,
typically obtained by reading a label or scanning a QR code,
implies authorization to commission the device. In LwM2M Factory
or Smartcard modes, a symmetric key known to both the device and
the Bootstrap Server is used, enabling automated bootstrapping
without direct user interaction.
* *Raw Asymmetric Keys*: Devices in this category possess a unique
asymmetric key pair but no certificate signed by a trusted
authority. In Wi-Fi DPP, the device holds a bootstrapping key
pair and the public key is encoded in a QR code or URI that is
transferred to the configurator. Similar approaches are used in
Bluetooth Mesh with Static OOB authentication and in LwM2M Raw
Public Key (RPK) mode. In these protocols, knowledge of the
device public key is sufficient to provision or onboard the
device.
* *Certificates and Supporting Infrastructure*: The most
infrastructure-intensive category assumes that devices are
provisioned during manufacturing with X.509 certificates and
corresponding trust anchors. BRSKI, SZTP, FDO, EST, OCF in
certificate-based modes, and Bluetooth Mesh v1.1 certificate
provisioning fall into this category. In BRSKI, the device must
possess an IEEE 802.1AR IDevID certificate and a trust anchor to
verify vouchers issued by the Manufacturer Authorized Signing
Authority (MASA). SZTP similarly assumes an IDevID and trust
anchors for verifying manufacturer-signed ownership vouchers and
bootstrap servers. FDO assumes a GUID, an attestation key pair, a
hash of the manufacturer public key, rendezvous information, and a
device-specific HMAC secret used to validate ownership vouchers.
EST assumes an existing credential, commonly an IEEE 802.1AR
certificate, to mutually authenticate the TLS session with the EST
server. OCF certificate-based modes and Bluetooth Mesh v1.1
support optional manufacturer-installed certificates that enable
automated device authentication during ownership transfer or
provisioning.
Sethi, et al. Expires 7 January 2027 [Page 37]
Internet-Draft IoT initial security setup July 2026
The nature of the initial beliefs assumed on the devices by various
protocols have other consequences worth considering:
* *Privacy*: Protocols that expose static identifiers can pose
privacy risks. Bluetooth Mesh and Thread often advertise a Device
UUID or EUI-64 in the clear during discovery, creating a
persistent digital fingerprint that can be passively observed.
EAP-NOOB includes a PeerInfo field, which may contain information
such as MAC address or device make and model. However, this
information is revealed only after the server responds to the
initial generic identity noob@eap-noob.arpa, ensuring that
disclosure occurs only to a server that actively participates in
the EAP exchange rather than continuously via broadcast beacons.
Another privacy consideration is protection from the device
manufacturer. Vendor-mediated protocols such as FDO, SZTP, and
BRSKI achieve convenience and minimal user interaction by
requiring the device to contact a manufacturer-operated service
such as a Rendezvous Server, MASA, or bootstrap server. As a
result, the manufacturer or cloud provider can retain a permanent
record of when and from which network a device is onboarded. The
owner cannot install the device without the manufacturer becoming
aware of its activation. In contrast, local sovereignty protocols
operate entirely within the local deployment context and remain
invisible to the manufacturer. A user can deploy a device in an
isolated environment without the vendor ever learning that it was
activated.
* *Vulnerability to label swapping*: Protocols in the static
symmetric secret and raw asymmetric key categories rely heavily on
the physical integrity of device labels. If an attacker can
photograph or copy a QR code in the supply chain or replace it
with a malicious one, they may be able to claim the device as soon
as it comes online or perform a man-in-the-middle attack. Damage
to or loss of the label can also render a device unusable unless
the manufacturer retains and can recover the associated public
key. If the QR code is not attached to the device itself and the
device is resold on a secondary market, the new owner may be
unable to onboard it. In some ecosystems, devices cannot be
transferred to a new owner without cooperation from the previous
owner, leading to devices being resold but effectively unusable.
* *Raw public keys vs. certificates*: Protocols based on raw public
keys, such as Wi Fi DPP with Static OOB authentication, prevent
passive eavesdropping but can be vulnerable to misbinding attacks
[Sethi19]. An attacker can print a QR code containing their own
public key and attach it to a different device. If the user scans
this code, the protocol may complete successfully with an attacker
controlled device. In contrast, certificate based approaches
Sethi, et al. Expires 7 January 2027 [Page 38]
Internet-Draft IoT initial security setup July 2026
allow a device to cryptographically prove contextual information
such as its manufacturer, model, or serial number, reducing the
risk that initial security setup is completed with the wrong or
malicious device. Both raw public keys and certificates introduce
cost factors, since factory installed credentials require secure
manufacturing processes to ensure that keys and certificates are
generated, stored, and injected without leakage. While the use of
certificates is becoming increasingly common and provides the
additional benefit of signed contextual information, the
complexity and cost of operating a public key infrastructure
cannot always be ignored by manufacturers. Commercial private PKI
services, such as those offered by cloud providers like Amazon Web
Services (AWS), typically charge per issued certificate, which may
be prohibitive for certain types of devices.
3.4. Comparison of processes
All protocols solve the same sequence of problems: discovering a
device or service endpoint, establishing initial trust, authorizing
the device for a specific domain or owner, and delivering the
credentials and configuration required for operational use. The
protocols differ primarily in where these steps occur, who
participates in them, and how much user involvement is required.
A first distinguishing factor is *discovery*. Local and user centric
protocols such as Bluetooth Mesh, Thread, and Wi Fi DPP rely on link
local discovery mechanisms, including beaconing, active scanning, or
out-of-band identifiers such as QR codes or NFC. In these protocols,
discovery is tightly coupled to physical proximity and user intent.
In contrast, infrastructure centric protocols such as SZTP, BRSKI,
FDO, and LwM2M rely on network based discovery mechanisms. Devices
locate bootstrap services using DHCP options, DNS records, well known
URLs, or rendezvous services. EAP NOOB occupies a hybrid position,
where the device uses a well-known identity to trigger bootstrapping
with any network willing to route EAP exchange.
The *establishment of initial trust* is another major point of
divergence. User assisted protocols typically rely on out-of-band
mechanisms such as PINs, QR codes, shared secrets, or visual
confirmation to authenticate the first exchange. Examples include
Thread PSKd entry, Bluetooth Mesh OOB authentication, Wi-Fi DPP QR
code scanning, and OCF Random PIN. These approaches trade automation
for user visibility and local control. Infrastructure centric
protocols instead rely on manufacturer installed credentials and
third-party validation. In BRSKI, the device presents an IDevID
certificate and receives a voucher validated by the manufacturer. In
SZTP and FDO, ownership vouchers and manufacturer signatures play a
similar role. EST assumes the existence of a credential that allows
Sethi, et al. Expires 7 January 2027 [Page 39]
Internet-Draft IoT initial security setup July 2026
immediate mutual authentication with a server. In these protocols,
trust is anchored in a PKI or manufacturer operated service rather
than in user mediated actions.
Protocols also differ in *where authorization decisions are made*. In
network centric schemes such as Thread, Bluetooth Mesh, and DPP,
authorization is implicit in possession of shared credentials or
group membership. Once a device demonstrates knowledge of the
appropriate key material, it is accepted as part of the network. In
contrast, owner centric protocols such as FDO, OCF, and LwM2M
explicitly model ownership and administrative domains. Authorization
involves verifying ownership artifacts, registering devices with
backend services, or associating them with specific management
endpoints. BRSKI similarly requires explicit authorization through
voucher validation, binding the device to a specific domain before it
is allowed to enroll for credentials.
The *delivery of credentials and configuration* also varies in scope
and timing. Some protocols deliver only the minimum information
required for secure communication, such as a network key or access
credential, leaving higher level configuration to later stages.
Thread and Bluetooth Mesh are examples of this approach. Other
protocols deliver a richer set of information during onboarding
itself. SZTP may deliver boot images, configuration files, and
scripts. FDO, OCF, and LwM2M provision management service endpoints,
access control parameters, and long-term credentials as part of the
onboarding flow. In these protocols, initial security setup is
tightly coupled with lifecycle management.
Finally, the protocols differ in their *support for repetition,
reset, and ownership transfer*. Some protocols treat onboarding as a
one time event, with reset and reprovisioning possible but not
explicitly modeled. Thread and Bluetooth Mesh fall largely into this
category. Others explicitly design for reuse and transfer. FDO and
OCF include mechanisms to update internal credentials and ownership
state, enabling resale or reassignment without manufacturer
involvement. These differences have significant implications for
device longevity, secondary markets, and operational flexibility.
3.5. Comparison of knowledge imparted to the device
Although all surveyed protocols aim to securely transition a device
into an operational state, they differ significantly in what beliefs
are imparted to the device once the protocol has completed. These
post execution beliefs define not only how the device authenticates
and communicates afterwards, but also how it interprets authority,
ownership, and its position within a broader administrative or
security domain.
Sethi, et al. Expires 7 January 2027 [Page 40]
Internet-Draft IoT initial security setup July 2026
* *Network centric*: Protocols focused primarily on connectivity
impart, at minimum, the cryptographic material required to
communicate at the data link or network layer. The device learns
how to communicate securely with its neighbors, but not
necessarily who manages it or what its long term application
behavior should be. For example, Thread imparts the Thread
Network Key along with network parameters such as PAN ID and
channel, and provides addressing information including ML EID and
RLOC, enabling the device to participate in IPv6 routing.
Bluetooth Mesh similarly imparts a Network Key and a unicast
address, allowing the device to encrypt and authenticate mesh
traffic. Wi Fi DPP imparts a Connector, a signed credential
containing a group identifier and a network access key, and also
provisions the configurator public signing key, which functions as
a trust anchor for verifying other network participants. In these
protocols, trust is implicitly placed in peers that demonstrate
possession of the same credentials. They generally do not encode
an explicit concept of ownership, and authorization is derived
from membership in a network or group. Bluetooth Mesh partially
blurs this boundary by also provisioning Application Keys and a
Device Key, enabling continued security provisioning and
application level protection beyond basic network access.
* *Infrastructure centric*: Protocols in this category focus on
imparting trust anchors and embedding the device into a public key
infrastructure domain. Examples include BRSKI, EST, and SZTP.
These protocols impart the belief that the device is now a member
of a specific PKI domain and that trust relationships are mediated
through certificates and certificate authorities. After
execution, the device typically holds a locally issued
certificate, trust anchors for the domain, and in some cases
vouchers or ownership related artifacts that bind its identity to
the domain. Authorization decisions are derived from PKI
membership and policy rather than from direct user interaction or
shared secrets. SZTP goes further than most by also imparting
onboarding information that can include boot images, configuration
scripts, and software updates. In this case, the knowledge
imparted to the device is not limited to credentials, but can
extend to defining the complete executable and operational
personality of the device.
* *Service centric*: Protocols such as FDO, OCF, LwM2M, and EAP NOOB
impart the belief that the device belongs to a specific owner or
administrative entity and should report to a specific service
endpoint. Upon completion, the device holds an Owner Credential
or ownership related trust anchor that cryptographically binds it
to an owner or management domain. This belief is stronger and
more persistent than simple network membership and enables fine
Sethi, et al. Expires 7 January 2027 [Page 41]
Internet-Draft IoT initial security setup July 2026
grained authorization, delegation, and lifecycle management.
Rather than binding the device solely to a network, these
protocols bind it to a logical service or platform. Crucially,
they impart service knowledge: the device completes the protocol
knowing exactly which URL or service endpoint to contact for
configuration, credential updates, software updates, and access
control decisions. In protocols such as OCF and FDO, the device
is explicitly provisioned with the identities and endpoints of
management services, including Credential Management Services and
Access Management Services. The device therefore believes not
only who owns it, but also where to obtain policies, credentials,
and updates throughout its operational lifetime.
The extent to which a device is prepared for reuse and ownership
transfer also varies significantly across protocols. Protocols such
as FDO and OCF explicitly update internal state and credentials to
support future resale or re-execution of the protocol for initial
security setup, imparting the belief that ownership and trust
relationships are mutable over time. By contrast, Thread and
Bluetooth Mesh generally treat commissioning as a one time event,
with reset and reprovisioning possible but not explicitly modeled as
ownership transitions. A particularly challenging case arises in
protocols that rely on physical labels. If possession of a label or
QR code is sufficient to claim a device, then an unauthorized
individual with temporary access to the device or its packaging may
be able to take control of it. In other cases, a device reset may
not be sufficient to make the device reusable until the previous
owner explicitly removes it from their management system. These
differences have significant implications for secondary markets,
device longevity, and long term sustainability.
4. Security Considerations
This draft does not take any posture on the security properties of
the different bootstrapping protocols discussed. Specific security
considerations of each protocol is present in the respective
specifications.
5. IANA Considerations
There are no IANA considerations for this document.
6. Acknowledgements
We would like to thank Gabriel Lopez-Millan, Rafa Marin-Lopez, Tuomas
Aura, Hannes Tschofenig, Michael Richardson for providing extensive
feedback and support.
Sethi, et al. Expires 7 January 2027 [Page 42]
Internet-Draft IoT initial security setup July 2026
7. Informative References
[bt-mesh] "Mesh Protocol", v1.1 , 2023, <https://www.bluetooth.com/
wp-
content/uploads/Files/Specification/HTML/MshPRT_v1.1/out/
en/index-en.html>.
[dpp] Wi-Fi Alliance, "Wi-Fi Easy Connect Specification", Wi-Fi
Alliance Version 3.0, 2018,
<https://www.wi-fi.org/wi-fi-download/35330>.
[fidospec] Fast Identity Online Alliance, "FIDO Device Onboard
Specification", Fido Alliance Version: 1.1, April 2022,
<https://fidoalliance.org/specifications/download-iot-
specifications/>.
[ieee8021ar]
IEEE, "IEEE Standard for Local and metropolitan area
networks-Secure Device Identity", 2018,
<https://1.ieee802.org/security/802-1ar/>.
[ocf] Open Connectivity Foundation, "OCF Security
Specification", Version 2.2.6, October 2022,
<https://openconnectivity.org/specs/
OCF_Security_Specification.pdf>.
[oma] Open Mobile Alliance, "Lightweight Machine to Machine
Technical Specification: Core", Approved Version 1.2.1,
December 2022,
<https://openmobilealliance.org/release/LightweightM2M/
V1_2_1-20221209-A/OMA-TS-LightweightM2M_Core-
V1_2_1-20221209-A.pdf>.
[oma-transport]
Open Mobile Alliance, "Lightweight Machine to Machine
Technical Specification: Transport Bindings", Approved
Version 1.2.1, December 2022,
<https://www.openmobilealliance.org/release/
LightweightM2M/V1_2_1-20221209-A/OMA-TS-
LightweightM2M_Transport-V1_2_1-20221209-A.pdf>.
[RFC2904] Vollbrecht, J., Calhoun, P., Farrell, S., Gommans, L.,
Gross, G., de Bruijn, B., de Laat, C., Holdrege, M., and
D. Spence, "AAA Authorization Framework", RFC 2904,
DOI 10.17487/RFC2904, August 2000,
<https://www.rfc-editor.org/rfc/rfc2904>.
Sethi, et al. Expires 7 January 2027 [Page 43]
Internet-Draft IoT initial security setup July 2026
[RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS
(CMC)", RFC 5272, DOI 10.17487/RFC5272, June 2008,
<https://www.rfc-editor.org/rfc/rfc5272>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/rfc/rfc6241>.
[RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed.,
"Enrollment over Secure Transport", RFC 7030,
DOI 10.17487/RFC7030, October 2013,
<https://www.rfc-editor.org/rfc/rfc7030>.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252,
DOI 10.17487/RFC7252, June 2014,
<https://www.rfc-editor.org/rfc/rfc7252>.
[RFC7616] Shekh-Yusef, R., Ed., Ahrens, D., and S. Bremer, "HTTP
Digest Access Authentication", RFC 7616,
DOI 10.17487/RFC7616, September 2015,
<https://www.rfc-editor.org/rfc/rfc7616>.
[RFC7617] Reschke, J., "The 'Basic' HTTP Authentication Scheme",
RFC 7617, DOI 10.17487/RFC7617, September 2015,
<https://www.rfc-editor.org/rfc/rfc7617>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<https://www.rfc-editor.org/rfc/rfc8040>.
[RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert,
"A Voucher Artifact for Bootstrapping Protocols",
RFC 8366, DOI 10.17487/RFC8366, May 2018,
<https://www.rfc-editor.org/rfc/rfc8366>.
[RFC8572] Watsen, K., Farrer, I., and M. Abrahamsson, "Secure Zero
Touch Provisioning (SZTP)", RFC 8572,
DOI 10.17487/RFC8572, April 2019,
<https://www.rfc-editor.org/rfc/rfc8572>.
[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", STD 94, RFC 8949,
DOI 10.17487/RFC8949, December 2020,
<https://www.rfc-editor.org/rfc/rfc8949>.
Sethi, et al. Expires 7 January 2027 [Page 44]
Internet-Draft IoT initial security setup July 2026
[RFC8995] Pritikin, M., Richardson, M., Eckert, T., Behringer, M.,
and K. Watsen, "Bootstrapping Remote Secure Key
Infrastructure (BRSKI)", RFC 8995, DOI 10.17487/RFC8995,
May 2021, <https://www.rfc-editor.org/rfc/rfc8995>.
[RFC9112] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP/1.1", STD 99, RFC 9112, DOI 10.17487/RFC9112,
June 2022, <https://www.rfc-editor.org/rfc/rfc9112>.
[RFC9140] Aura, T., Sethi, M., and A. Peltonen, "Nimble Out-of-Band
Authentication for EAP (EAP-NOOB)", RFC 9140,
DOI 10.17487/RFC9140, December 2021,
<https://www.rfc-editor.org/rfc/rfc9140>.
[RFC9148] van der Stok, P., Kampanakis, P., Richardson, M., and S.
Raza, "EST-coaps: Enrollment over Secure Transport with
the Secure Constrained Application Protocol", RFC 9148,
DOI 10.17487/RFC9148, April 2022,
<https://www.rfc-editor.org/rfc/rfc9148>.
[Sethi14] Sethi, M., Oat, E., Di Francesco, M., and T. Aura, "Secure
Bootstrapping of Cloud-Managed Ubiquitous Displays",
Proceedings of ACM International Joint Conference on
Pervasive and Ubiquitous Computing (UbiComp 2014), pp.
739-750, Seattle, USA, September 2014,
<http://dx.doi.org/10.1145/2632048.2632049>.
[Sethi19] Sethi, M., Peltonen, A., and T. Aura, "Misbinding Attacks
on Secure Device Pairing and Bootstrapping",
Proceedings of the 2019 ACM Asia Conference on Computer
and Communications Security (AsiaCCS '19), pp. 453-464,
Auckland, New Zealand, July 2019,
<https://doi.org/10.1145/3321705.3329813>.
[threadcommissioning]
Thread Group, "Thread Specification", Version: 1.4.0 ,
2024, <https://www.threadgroup.org/ThreadSpec>.
Authors' Addresses
Mohit Sethi
Aalto University
FI-02150 Espoo
Finland
Email: mohit@iki.fi
Sethi, et al. Expires 7 January 2027 [Page 45]
Internet-Draft IoT initial security setup July 2026
Behcet Sarikaya
Unaffiliated
Email: sarikaya@ieee.org
Dan Garcia-Carrillo
University of Oviedo
33207 Oviedo
Spain
Email: garciadan@uniovi.es
Sethi, et al. Expires 7 January 2027 [Page 46]