Terminology and processes for initial security setup of IoT devices

Standards and Protocols

Bluetooth Mesh Provisioning Bluetooth 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. 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 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 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.

Device Provisioning Protocol (DPP) The Wi-Fi Alliance Device Provisioning Protocol (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. 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. 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 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).

Enrollment over Secure Transport (EST) Enrollment over Secure Transport (EST) 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 over Transport Layer Security (TLS) as its primary transport, and a companion specification also defines how EST can be used over secure CoAP . 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 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 or Digest 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 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 .

Open Mobile Alliance (OMA) Lightweight Machine to Machine specification (LwM2M) The Open Mobile Alliance Lightweight Machine to Machine (LwM2M) specification 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 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. 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.

Nimble out-of-band authentication for EAP (EAP-NOOB) Extensible Authentication Protocol (EAP) framework provides support for multiple authentication methods. EAP-NOOB 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 , allowing authentication exchanges to be routed to the appropriate server. 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-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.

Open Connectivity Foundation (OCF) The Open Connectivity Foundation (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 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. 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 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.

Bootstrapping Remote Secure Key Infrastructures (BRSKI) Bootstrapping Remote Secure Key Infrastructures (BRSKI) defines a bootstrapping solution that enables devices to securely join the device owner's network domain using manufacturer-installed IEEE 802.1AR 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. 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. 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 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.

Secure Zero Touch Provisioning (SZTP) Secure Zero Touch Provisioning (SZTP) 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 or RESTCONF 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. 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 . 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. 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 . 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. 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.

FIDO Device Onboard (FDO) The Fast IDentity Online Alliance (FIDO) Device Onboard (FDO) specification 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) and may be transported over application-layer protocols such as CoAP . 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. 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. 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. 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 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.

Thread Thread Mesh Commissioning Protocol (MeshCoP) 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. 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 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 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.

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.

Comparison of terminology The ten protocols covered in 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. 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.

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. 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.

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. 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. 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 . 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 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.

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 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.

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. 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 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.