Scalable Device Provisioning in AWS IoT Using Fleet Provisioning

HomeTechnology Scalable Device Provisioning in AWS IoT Using Fleet Provisioning
January 30, 2026 by Tuyền Nguyễn Technology
Scalable Device Provisioning in AWS IoT Using Fleet Provisioning
1. Overview of AWS IoT and Device Identity Management
2. Provisioning Mechanisms in AWS IoT
3. AWS IoT Fleet Provisioning Templates Explained
4. Implementation of the Fleet Provisioning Applications
5. Claim Certificate vs CSR: A Comparison in AWS IoT Provisioning
6. Security Considerations for AWS IoT Fleet Provisioning
7. Conclusion – Why Fleet Provisioning is the Best Choice for Scalable IoT 
1. Overview of AWS IoT and Device Identity Management

AWS IoT is Amazon Web Services’ platform that enables the centralized and highly scalable connection, management, and security of millions of IoT devices. Within this ecosystem, Fleet Provisioning plays a crucial role in addressing the challenge of deploying IoT devices on a large scale, especially in mass production scenarios.

What is Fleet Provisioning?

Fleet Provisioning is a mechanism that allows IoT devices to automatically register (onboard) into the AWS IoT Core system upon first power-on, without the need to manually create certificates and configure each device. Instead of creating certificates for each device, hardcoding the certificate and private key into the firmware, and manually assigning policies and Thing Names, AWS IoT Fleet Provisioning allows devices to be configured with minimal initial information (claim certificate or CSR). Upon initial connection, AWS IoT will automatically create a unique certificate, assign policies, create Things, and link related resources. In other words, Fleet Provisioning is a platform for automatically, securely, and scalably onboarding IoT devices.

Note: Avoid hardcoding certificates in firmware: Hardcoding certificates and private keys in firmware is common practice in small Proof-of-Concept (PoC) systems, but it’s unsuitable for real-world IoT systems because:

  • High security risk: If firmware is leaked, reversed, or flashed, the private key is exposed, and all devices sharing the same key can be impersonated.
  • Scalability is impossible: Manually creating and managing thousands/millions of certificates is impractical.
  • Device lifecycle management is lacking: Hardcoded firmware offers virtually no support for revoking, rotating, or re-provisioning devices.

Fleet Provisioning solves these problems by separating the identity provisioning process from the firmware. Large-scale IoT deployments require a well-structured device management strategy. Below are the three most important practical needs that businesses should focus on:

Optimize Mass Production:

  • Firmware Unification: Allows all devices in the same batch to be flashed with a single firmware version.
  • Automated Identification: Solves the problem of not being able to pre-determine the individual serial number, thing name, or certificate for each device during the manufacturing process.
  • Dynamic Registration: Uses Provisioning Templates to automatically generate “things” and grant permissions as soon as the device leaves the factory or is installed in the field, without requiring manual intervention.

Enhance security Private Key:

  • Personalized certificates: Ensure each device possesses a unique certificate and private key pair, eliminating the need for sharing or hardcoding security information.
  • Secure issuance mechanism: CSR-based – Supports direct key pair generation on the device to ensure the private key is never exposed. Claim-based – Uses a temporary certificate (Claim Certificate) for initial connection, then automatically issues a permanent certificate and revokes the temporary certificate’s authority.

Device Lifecycle Management:

  • Re-provisioning: Allows for flexible reconfiguration and reuse of devices for different clients or purposes.
  • Revocation: Timely disconnects and revokes access to devices that are faulty, lost, or show signs of being compromised.
  • Certificate Rotation: Performs periodic key changes to maintain the highest security standards for the system.
  • Systematized Management: Integrates closely with AWS IoT Policies and Thing Management to monitor devices from activation to deactivation.

Fleet Provisioning offers several key benefits to modern AWS IoT systems, most notably the ability to fully automate the onboard device process. Thanks to its template-based provisioning and certificate claim mechanism, devices can register and receive their identity on the first connection without manual configuration. Furthermore, Fleet Provisioning is highly scalable, suitable for systems with thousands to millions of devices operating simultaneously. Each device is assigned a unique PKI-based identity, ensuring high security and preventing certificate sharing. Eliminating manual configuration significantly reduces operational risk and minimizes errors during production and deployment. Additionally, Fleet Provisioning easily integrates into mass production lines and real-world operations, shortening time to market.

2. Provisioning Mechanisms in AWS IoT

Depending on the scale and hardware capabilities, AWS IoT offers three common approaches to device identity provisioning:

  • Manual Provisioning: This is the simplest method, suitable for proof-of-concept (PoC) or demos with a very small number of devices. The process involves creating the Thing and Certificate directly on the console, then manually loading it into the firmware. However, this method is completely unfeasible for mass production due to high operational resource costs and the risk of operational errors.
  • Just-In-Time Registration (JITR): This method allows the device to self-register on the first connection based on a factory-issued Certificate Authority (CA Certificate). This process requires the device to have a sufficiently powerful MCU to generate key pairs and perform complex encryption algorithms (RSA/ECC). While ensuring high security and each device having its own certificate, JITR increases hardware costs and requires a very strict CA management process at the factory.

jitr flow vs jitp flow

  • Fleet Provisioning: Considered the most balanced solution, Fleet Provisioning uses a temporary Claim Certificate for the initial connection of the device. Afterward, the system automatically issues a separate Production Certificate and configures the device using pre-set templates. Its significant advantages include allowing the use of a single firmware version for the entire batch, reducing the computational load on low-cost devices, and supporting systematic device lifecycle management (recall and reissue).

Provisioning Approaches in AWS IoT

Fleet Provisioning is the optimal solution for automating large-scale device provisioning processes, completely eliminating slow and error-prone manual registration operations. This method optimizes factory production by requiring only a single Claim Certificate for the entire batch instead of managing millions of individual certificates. Especially when combined with CSR mechanisms, security is maximized because the private key is generated and remains within the device, never needing to be transmitted over the network. Furthermore, management via Provisioning Templates allows administrators to flexibly configure identifiers, assign security policies, and group devices centrally from the cloud. Thanks to the automatic “registration” process upon initial power-on, devices can automatically switch to their own unique identifiers, ensuring seamless and secure unlimited system scalability.

3. AWS IoT Fleet Provisioning Templates Explained

What is Provisioning Template?

Fleet Provisioning Template is a JSON configuration file in AWS IoT that acts as a blueprint for automating resource provisioning for devices. When a device uses a claim certificate to call a provisioning API over MQTT or HTTPS on its first connection, the system executes this template to automatically identify and configure the device. Specifically, the template details how to create a Thing, issue a new Certificate, assign corresponding security policies, and establish a tight link between those components, making mass deployment secure and consistent without manual intervention.

In Fleet Provisioning, the Provisioning Template allows for:

  • Standardizing how devices are onboarded
  • Completely automating the Thing and certificate creation process
  • Ensuring all devices adhere to the same security policy
  • Reducing operational errors due to manual configuration

A provisioning template typically includes: Parameters (Parameters passed from the device, e.g., serial number, device ID); Resources, the AWS IoT resources created: Thing, Certificate, Policy attachment, Thing–Certificate attachment; Overrides (optional) allow overriding certain attributes when needed. The following is an example image of Provisioning Templates:

example template provisioning

Form Flow:

  1. Device send request provisioning: Call API ReateKeysAndCertificate or RegisterThing, after send parameters SerialNumber
  2. AWS IoT implement templates: Create Thing with the name by SerialNumber, create certificate and private key, assign policy for certificateAttach certificate in Thing.
  3. Device receive results: Receive production certificate, save certificate and private key, finally stop using claim certificate

When designing a Provisioning Template: ThingName should be associated with a serial number or unique ID, the Policy assigned to the device needs to have minimum access restrictions, the Claim certificate should only be used for provisioning, not for operation, and policies should be separated (Claim policy, Production device policy).

4. Implement of the Fleet Provisioning Application

The process flow diagram includes the following steps:

1. Initialization using a Claim Certificate: The device begins connecting to AWS IoT Core via a single Claim Certificate used for the entire production batch. At this step, the device sends a request to create a new identifier ($aws/certificates/create/json) to the system via MQTT/HTTPS, simplifying data loading at the factory.

2. Issuance and Storage of the New Certificate: AWS IoT Core receives the request and automatically generates a unique Certificate and Private Key signed by the AWS CA. After receiving this information, the device writes data to secure storage or via the topic ($aws/certificates/create/json/accepted) for use in subsequent official connections. The device receives the new certificate and writes this Certificate/Private Key pair to its secure storage.

3. Executing the Template and Activating the Identifier: The device sends a configuration activation request along with specific identifiers (such as Serial Number) to the Provisioning Template. Based on this design, AWS automatically creates a Thing, assigns it to the appropriate device group, and assigns corresponding security policies. Next, the device sends a configuration activation request to the topic: $aws/provisioning-templates/{template-name}/provision/json. In this step, it includes the device’s specific identifiers (such as Serial Number).

4. Switching to a Formal Connection: After receiving a successful assignment response, the device disconnects using the old Claim Certificate. Finally, it establishes a new connection using the newly received device certificate, officially joining the system with full privileges and a unique identifier. The successful result is sent back to the device via the topic: $aws/provisioning-templates/{template-name}/provision/json/accepted.

This process saves manufacturers time: instead of loading 10,000 different certificates for 10,000 devices, they only need to load a single identical Claim Certificate. AWS handles the identity separation when the device first goes online.

 

The core difference between Fleet Provisioning by Claim and Fleet Provisioning with CSR lies in where the Private Key is generated and managed.

1. Initial connection using a Claim Certificate: The device makes its first connection to AWS IoT Core using a Claim Certificate. This is a temporary certificate pre-installed for the entire fleet, giving the device basic access to the system topics necessary for registration.

2. Device generates the Key and submits the CSR: Instead of receiving the private key from the cloud, the device generates an internal public/private key pair. It then creates a CSR (Certificate Signing Request) and publishes this request to AWS via the topic `$aws/certificates/create-from-csr/json`. This ensures the private key never leaves the device, providing maximum security.

3. AWS Validation and Certificate Signing: AWS IoT Core receives the request, validates the Claim Certificate, and checks the accompanying policies. If valid, AWS signs the CSR to create a device certificate in .pem format and sends it back to the device via the /accepted topic.

4. Storage and Execution of Provisioning Template: The device receives the signed certificate and, combined with the available private key, writes it to secure storage. Next, it sends its specific identifiers to the Provisioning Template topic. AWS uses this template to automatically allocate resources, such as creating Thing Names, grouping, and assigning official permissions.

5. Completion and Official Connection: After AWS confirms the successful allocation process via the /accepted topic, the device enters its official operational state. From this point on, it temporarily disconnects and uses the unique device certificate it just received to establish a secure and permanent connection to the system.

5. Claim Certificate vs CSR: A Comparison in AWS IoT

compare claim certificate vs csr

Private Key Security

  • In the By Claim method, AWS acts as the creator. While convenient, it means the Private Key exists in transit (as an MQTT payload) before being written to the device’s secure storage.
  • In the With CSR method, the device generates the key. AWS only “stamps” (signs) the device’s public key. This aligns with strict security standards where the Private Key must remain permanently within a secure element or TPM.

Commonalities

  • Both methods begin by using a Claim Certificate to establish the initial “bootstrap” connection with AWS.
  • Both use a Provisioning Template to configure resources such as Thing Name, Policies, and Thing Groups once the unique identity is established.
  • The end result for both processes is that the device obtains a unique Device Certificate for its permanent connection, replacing the initial shared Claim Certificate.

Recommendation: If your hardware (like a Raspberry Pi or an STM32 with cryptographic library support) is capable, you should prioritize the CSR method to ensure the private key is never exposed.

6. Security Consideration for AWS IoT Fleet Provisioning

Security is a core element in Fleet Provisioning, especially when using Claim Certificates as a bootstrap mechanism for a range of devices. Claim certificates are not the device’s permanent operational identity; therefore, the policies associated with them must be kept to a minimum. Specifically, claim certificates should only be allowed to connect to AWS IoT Core and publish/subscribe MQTT topics for provisioning. They should absolutely not be allowed to access operational functions such as publishing telemetry data, manipulating Device Shadows, or performing OTA updates, to avoid the risk of abuse if the claim certificate is compromised.

Furthermore, the device’s private key needs to be strictly protected throughout its lifecycle. The creation and storage of the private key should be done in secure environments such as secure elements, modem key stores, or flash areas protected by TrustZone. The private key should not be printed to logs, transmitted externally in any form, or exposed through debug interfaces or internal APIs. This is a mandatory requirement to ensure the device’s identity cannot be tampered with.

To prevent device cloning, the provisioning process should associate certificate signing requests (CSRs) with unique hardware identifiers such as serial number, IMEI, or hardware ID. The backend can use this information to verify validity and detect unusual registration behavior, thereby preventing a valid certificate from being copied and used on multiple devices.

7. Conclusion – Why Fleet Provisioning is the Best Choice for Scalable IoT

Fleet Provisioning provides a powerful mechanism that simplifies and fully automates the onboarding of devices into AWS IoT. By separating the identity provisioning process from firmware and delegating much of the certificate management responsibility to AWS, Fleet Provisioning allows systems to easily scale up while maintaining high security and efficient device lifecycle management.

Thanks to these features, Fleet Provisioning is particularly well-suited for mass-produced IoT systems, including cellular devices, gateways, and Wi-Fi, where rapid deployment, cost optimization, and long-term operational stability are required. In the context of modern commercial IoT, Fleet Provisioning is not just a technical choice, but a best practice for large-scale AWS IoT systems.

Related Posts

NB-IoT: Principles and Architecture
January 23, 2026 Technology

NB-IoT: Principles and Architecture

CAN Bus Protocol
January 23, 2026 Technology

CAN Bus Protocol

Leave a Reply

Your email address will not be published. Required fields are marked *

+84 90 686 2311

[email protected]

7A Thoai Ngoc Hau
Hoa Thanh Ward, Tan Phu District, Ho Chi Minh City

Our mission

Our mission is to enhance value for businesses, provide effective solutions, and create professional software applications that meet the needs of both Vietnamese and international enterprises.

Menu

Industrial Embedded Solutions Joint Stock Company
Registration code: 0318004045 Phone: +84 90 686 2311 Email: [email protected] Address: 7A Thoai Ngoc Hau, Hoa Thanh Ward, Tan Phu District, Ho Chi Minh City
© 2026 — Industrial Embedded Solutions. All Rights Reserved.