Device Provisioning in IoT: Secure Onboarding

astructure now behave like a distributed IT system. Each device has an identity, connectivity, access rules, and a lifecycle. The first connection to networks and services sets the security baseline for years.

Scale is growing faster than manual setup can handle. Market estimates point to about 21.1 billion IoT devices by the end of 2025. Cellular IoT connections could reach about 4.5 billion in early 2026, then move toward 8 billion by 2031. Urbanization is rising too, from 55% of the population living in cities in 2018 to a projected 68% by 2050. That makes cities more dependent on reliable IoT across transport, utilities, public safety, and healthcare.

In this context, device provisioning and secure onboarding are core operations, not a one-time technical step. When you manage hundreds of thousands or millions of devices, manual processes become expensive and risky because mistakes are inevitable. Modern approaches rely on automated initial setup tied to manufacturing identity and cryptographic trust checks.

Why onboarding and provisioning become a risk point

The first time a device connects is when it is most exposed. Security policies may not be fully in place yet, firmware may be outdated, monitoring is not running, and the device often starts in an unknown environment. A mistake at this stage can turn into a systemic vulnerability that scales across the whole fleet. Practices that used to be tolerated are now covered by standards and government cyber rules for connected products.

The same risk patterns show up across industries.

• Weak authentication at startup. Default passwords and shared credentials are still common. Consumer IoT baselines now call for unique passwords per device or a user-set password during setup.

• Unreliable update practices and no vulnerability reporting path. Regulators increasingly expect more than removing default passwords. They expect a clear way to report security issues, plus a defined minimum support period for updates.

• Device takeover and botnets. IoT devices are often used for DDoS. A large share of past infections started with weak first-run access and exposed management interfaces.

• Supply chain risk. Secure onboarding usually relies on a cryptographic identity created during manufacturing, then transferred into the owner’s operational domain. If keys leak at the factory stage or components are swapped, that risk follows devices into the field.

• Complex onboarding and human error. In smart home setups, users often face a tiring flow with accounts, model selection, and Wi-Fi entry. Even modern ecosystems do not always remove dependencies on vendor apps. In business deployments, the same issue shows up as installer mistakes and inconsistent integrator practices.

Operationally, this quickly becomes downtime, extra cost, and reputation damage. In IoT, one weakly onboarded device can become a foothold into the network, the impact can be far wider than a local fault.

Principles of secure provisioning and onboarding

Aligned terms for an international team

In international projects, confusion often comes from the same words meaning different steps. In practice, it helps to split the process like this. Bootstrapping covers the full secure first start of a device. Provisioning supplies parameters and data that make the device operational. Onboarding connects it to the owner’s network and services. Enrollment describes the interaction with the manufacturer to obtain the required artifacts at startup.

It helps to treat secure onboarding as a chain, not a single action. It includes manufacturing identity, first connection, owner confirmation, issuing credentials and policies, bringing the device under management, and controlling changes over time.

Core goals of secure onboarding

Reliable provisioning comes down to a few testable goals.

• Unique identity and inventory. Each device must be uniquely identified so it can be managed, incidents can be handled fast, certificates can be rotated, and decommissioning can be done correctly.

• Configuration and access control. Only authorized parties should reach local and network interfaces. The exposed surface at first start should be as small as possible.

• Protect data in transit and at rest. Data should be protected while it is sent and stored. When ownership changes or a device is retired, there should be a way to make prior parties unable to access that data through proper key management.

• Secure updates. The device should accept updates only from authorized sources. It should verify authenticity and apply updates in a controlled way. The first update after activation often closes known risks in early device batches.

• Visibility into security state. The system should distinguish a verified device from a suspicious or degraded one. Those signals should only be visible to authorized parties.

Manufacturing identity as a scaling foundation

Modern approaches increasingly build trust from manufacturer to owner through bootstrap keys or certificates injected during production. A common model separates a supplier-provided initial identity from an operational identity issued by the owner’s domain.

A hardware root of trust adds practical value. Secrets stay inside a protected module, proof of key possession becomes simpler and more reliable, this reduces compromise risk as fleets scale.

Standards and protocols shaping secure onboarding

BRSKI as an onboarding model for network and industrial environments

BRSKI describes an automated start that relies on manufacturer certificates and a manufacturer service to authorize joining an owner domain. A typical flow looks like this. The device on the owner’s network discovers a registrar, gets a voucher, verifies it, accepts the owner domain trust anchor, then operates using locally issued certificates.

The practical value of BRSKI is that it separates manufacturing identity from operational identity. With the right infrastructure in place, setup becomes close to plug in and power on. The permission step is explicit through a signed voucher.

BRSKI AE for different certificate enrollment models

The BRSKI AE extension allows alternative enrollment mechanisms instead of binding everything to one protocol. This is useful in industrial networks that already run their own PKI. Onboarding fits existing processes while keeping BRSKI’s core guarantees.

FIDO Device Onboard as an ownership transfer protocol

FDO treats onboarding as an ownership transfer. Manufacturing creates artifacts such as an ownership voucher. Control can pass between parties in the supply chain until the device is commissioned. A key idea is late binding of the management platform. This helps when the final destination is not known at manufacturing time.

Matter and attestation during commissioning

In the consumer space, Matter focuses on cryptographic device verification during commissioning. The system checks the device certificate chain and confirms the vendor. In practice, this does not always mean one smooth user experience. Some features can still require separate vendor apps and accounts. It helps to separate device authenticity from vendor service logic.

Wi-Fi Easy Connect for headless devices

Wi-Fi Easy Connect, also known as DPP, standardizes secure transfer of Wi-Fi credentials for devices without a screen. Setup often comes down to scanning a QR code or another out-of-band confirmation. The benefit is that provisioning does not depend on open pairing modes or default passwords.

eSIM and remote profile management for cellular IoT

In cellular IoT, provisioning includes both cryptographic identity and connectivity to the operator network. eSIM adds remote profile management. For global rollouts, telecom provisioning and hardware provisioning should be planned as two linked processes inside one lifecycle.

Cases and real-world practices

Scaling cloud provisioning using AWS as an example

Large cloud platforms are useful as field-tested models, even if your team is building its own platform. In AWS, devices typically authenticate with X.509 certificates. Automated provisioning is done through templates that define resources and access rights for a device.

Just-in-time provisioning registers a device at its first connection. You enable auto registration and bind a provisioning template to the CA that signs device certificates. The key detail is that the certificate and private key must already be on the device before onboarding. The customer CA must be registered in the cloud.

The takeaway is straightforward and has two parts. You need a controlled process to issue and deliver keys or certificates to devices during manufacturing or before deployment. You also need templating so one mechanism can cover the whole fleet, not each device as a one-off.

Microsoft Azure DPS as a dedicated onboarding service

Azure DPS treats provisioning as a separate service and supports three authentication options. X.509, TPM, and symmetric keys. For secret storage, the recommendation is hardware-backed protection such as HSM or TPM. Symmetric keys fit simpler scenarios. X.509 is a stronger model. It supports group enrollment for fleets and validates certificate chains from root or intermediate CAs.

A typical practice for medium and large deployments looks like this. A dedicated provisioning service assigns a device to the right hub, applies initial access policies, creates registry entries, then control moves to the main IoT platform.

Reference architecture

Source: Image generated via ChatGPT 5.2 by Volodymyr Kazakov

To make secure onboarding repeatable and scalable, the architecture should separate roles and the artifacts passed between them.

Key roles in industrial or enterprise IoT:

• The manufacturer creates the device’s initial identity. It injects a certificate or key and keeps records of serial numbers and unique IDs.

• The owner or domain operator defines access policies. It issues operational credentials or binds the device to an environment, it manages the lifecycle.

• The provisioning infrastructure moves the device from its initial state into an operational one through a set of services. In BRSKI, this is reflected by the pledge and registrar roles plus a manufacturer service that signs vouchers.

Artifacts that should be explicit in the design:

• A manufacturing credential such as an IDevID.

• Proof of ownership such as a BRSKI voucher or an FDO ownership voucher.

• An operational credential for runtime use such as an LDevID or a certificate issued during enrollment.

• Access policies and configuration that define data paths, command sources, and rules for ongoing management.

Consequences of implementation

Secure onboarding only matters when you can see the impact in numbers and in day-to-day operations.

• Faster rollout and fewer mistakes. A zero-touch approach reduces on-site work to install and power on, assuming the infrastructure is ready. This shortens installation time, lowers the load on field teams, and reduces setup errors.

• Smaller attack surface at first start. Unique credentials, locked-down management interfaces, and configuration control reduce the risk of fleet-wide compromise through default passwords or open ports. This directly lowers the chance devices end up in botnets or become a DDoS source.

• Faster incident response. Managed keys and certificates let teams revoke access quickly, reissue credentials, and move devices into a safe mode without large-scale site visits.

Fordewind: IoT expertise that starts with trust

In large IoT projects, problems often show up at the start. A device’s first contact with the network sets the security model, mistakes scale fast as fleets grow. That is why secure provisioning should be part of the product and operations, not a one-off task.

Fordewind builds IoT as one system where trust and control matter as much as data and interfaces. The team works across the full device lifecycle. Security becomes a practical workflow through automated onboarding, template-based policies, certificate management, rotation and revocation, secure updates, and clear fleet security visibility. This means fewer installation mistakes, faster rollout, a smaller attack surface at first start, and quicker response without mass site visits.

If your goal is an IoT product or platform that will scale to hundreds of thousands or millions of devices, Fordewind can help you build the trust and controllability foundation from day one.

Conclusion

Secure onboarding in device provisioning determines whether an IoT system stays controllable and resilient for years. Device fleets are growing, security requirements are tightening, so onboarding needs to be standardized and automated.

A minimal action plan looks like this:

• Align process terms and split responsibilities between the manufacturer, integrator, and operator.

• Choose an identity model. Use certificates for critical systems. Use TPM or an equivalent for protected devices.

• Build a lifecycle for keys and updates. Plan rotation, revocation, and recovery after incidents.

• Validate baseline security requirements and pick the right protocol for the environment.

• Lock regulatory requirements into the product spec. Unique credentials, a vulnerability reporting channel, a defined support period for updates.

This makes secure onboarding repeatable, scalable, and straightforward to operate.