Fleet provisioning with CSR swaps a per-unit private key for one shared claim key in the image

What crosses the network in this flow is a CSR, published over MQTT to the CreateCertificateFromCsr API ^[3]. AWS IoT Core signs it with an AWS-managed CA, or with a self-managed certificate provider tied to an external PKI or AWS Private CA, and returns the certificate ^[4]. A provisioning template then registers the Thing, attaches security policies and activates the certificate ^[5].

To make that first call the device needs a credential before it has one of its own. The guide uses a claim certificate, which it describes as a shared bootstrap X.509 certificate and private key pre-installed on devices during manufacturing ^[6]. So a secret still crosses the factory floor, one secret per image instead of one per unit ^[21].

In the walkthrough that secret is a file. You download the pair from the AWS IoT console and copy it into claim_private.key and claim_cert.crt under fleet_provisioning_with_csr/spiffs_image/certs ^[11], and the directory name says where it ends up. It will also sit in whatever your CI treats as a build input.

iot:Publish and iot:Receive are scoped to two topic ARNs, the create-from-csr topics and the named template's provision topics ^[13]. iot:Subscribe is scoped to the matching topicfilters ^[14]. iot:Connect has Resource set to "*" ^[12]. Three of the four actions are pinned to provisioning topics and the connect permission is not ^[20]. Read literally, a holder of that claim key can connect to the account's endpoint under any client ID and drive the create-from-csr exchange for that template ^[22].

The guide notes that fleet provisioning suits hardware using a secure element where private keys cannot be imported ^[8]. If the part will not accept an imported key, generating the key on the device is the only way to get a unique identity ^[2], and a CSR is the only way to get that identity signed. Signing policy is the other decision: self-managed signing lets you use your own PKI, validity periods and algorithms instead of relying solely on AWS-managed certificates ^[9].

The sequencing in the guide is sensible. It pins esp-idf v5.5.5 and the ESP32-S3-WROOM-1-N16R8 module, and clones esp-aws-iot at branch 202406.05-LTS-release with --recursive ^{[15] [16]}. It sets the target with idf.py set-target esp32s3 and builds ^[17] at step 2.2, before the provisioning policy is created at 2.3, so toolchain and submodule failures surface before any credential exists.

One more account-side dependency: the flow needs an IAM role, because AWS IoT itself needs permission to create, configure and register Things, certificates and policies on your behalf ^[19].