IoT Fleet Provisioning at Scale: Zero-Touch Onboarding, Device Certificates, Claim Flows and Device Provisioning Services (2026)

Most fleets that fail at onboarding do not fail in the cloud. They fail on the factory floor, months earlier, when someone decided that every unit would ship with the same claim certificate and “we will sort out identity at first boot.” IoT device provisioning looks like a single API call in vendor tutorials. In production it is a relay of three different identities, owned by three different parties, handed over under time pressure.

This matters now because the tooling has finally diverged enough to force a design choice. AWS IoT Core lets you plug your own CA into fleet provisioning, Azure has put a Microsoft-managed PKI for devices into public preview behind its Device Provisioning Service, FIDO Device Onboard reached a 2.0 Proposed Standard in April 2026, and Matter has normalised factory-injected attestation certificates in consumer hardware.

You will leave with a reference architecture, a PKI hierarchy you can defend in an audit, worked capacity math, and a decision tree for picking a claim flow.

What this covers: the three-identity model, zero touch provisioning patterns, AWS fleet provisioning by claim and trusted user, JITP and JITR, Azure DPS enrollment groups and attestation, FDO, BRSKI and EST, Matter DAC chains, factory key injection, X.509 device certificates, rotation, revocation, multi-tenant claims and failure modes.

Context and Background

Provisioning answers three questions for every device: who made you, who owns you, and what are you allowed to talk to. Early IoT platforms collapsed all three into one step. An engineer generated a key and certificate in the cloud console, copied the files onto a development board and moved on. That works for ten devices. It breaks at ten thousand, because it needs a human per device and leaks private keys through laptops and build servers.

The industry’s answer has been “zero touch provisioning”: a device leaves the factory with a credential it can use to prove its origin, and on first power-up it finds the right backend, proves itself and receives the configuration and operational credentials it needs. No technician types anything. The hard part is not the protocol. It is deciding where trust is anchored and who is allowed to bind a specific serial number to a specific customer.

The incumbents fall into three camps. Cloud provisioning services, chiefly AWS IoT Core fleet provisioning and the Azure IoT Hub Device Provisioning Service (DPS), assume the device already knows which cloud it belongs to. Vendor-neutral onboarding standards, chiefly FIDO Device Onboard (FDO) and the IETF’s Bootstrapping Remote Secure Key Infrastructure (BRSKI), assume the owner is not known when the device is built. Ecosystem protocols such as Matter define their own commissioning ceremony with a phone or hub acting as the commissioner.

Platform-level onboarding inside a single product is a narrower problem. Our ThingsBoard device provisioning tutorial walks through provision keys and secrets on one platform end to end. This article sits one level higher: the architecture that feeds any such platform, from the key-injection station to certificate revocation, at fleet scale and across vendors.

Two forces changed the economics. Secure elements and discrete TPMs became cheap enough to put in mid-range devices, so a private key that never leaves silicon is now the default rather than a premium option. And PKI lifetimes are shrinking everywhere. The web PKI is moving to much shorter certificate lifetimes, and that mindset is reaching device fleets. The AWS IoT Core fleet provisioning documentation and Microsoft’s preview certificate management both now describe operational certificates as renewable artefacts rather than install-once files.

The Three-Identity Reference Architecture for IoT Device Provisioning

The core claim of this article is simple. A scalable IoT device provisioning design separates a birth identity, an ownership binding and an operational identity. Each has its own CA or registry, its own lifetime and its own failure mode. Cloud provisioning services are the place where these three meet, not the place where any of them should be created.

Figure 1: Reference architecture for IoT device provisioning, separating birth identity, ownership binding and operational identity.

The diagram reads left to right. A factory hardware security module (HSM) holds the manufacturing issuing CA. A line station generates or reads a key pair inside the device’s secure element or TPM, gets a birth certificate signed and writes it back. The same station emits a signed manifest of serial numbers and public keys. That manifest flows to a claim service, which records which customer or tenant owns which units. On first boot the device contacts an onboarding endpoint, which might be Azure DPS, AWS fleet provisioning, an FDO owner service or a BRSKI registrar. A policy engine combines the device’s proven birth identity with the claim record, picks a tenant, region and hub, and asks an operational CA to sign a certificate for a key the device generates. The registry and device twin are created, the device reconnects to the hub with its operational credential, and the operational CA publishes revocation data.

Birth identity: anchored in silicon and the factory, never in the cloud

The birth identity is what the IEEE 802.1AR standard calls an Initial Device Identifier (IDevID): a certificate bound to a key generated in, or injected into, protected hardware at manufacture. It should live as long as the device and never change. Its only job is to prove “this unit came off our line” during onboarding and, later, during repair or resale.

Keeping birth identity out of the cloud account is the point. If the cloud generated it, the manufacturer would depend on one tenant’s account to prove device origin. A device sold to a customer on another cloud, or moved between AWS accounts, could no longer prove where it came from. Matter makes the same separation explicit. Its Device Attestation Certificate (DAC) is unique per device and chains through a Product Attestation Intermediate (PAI) to a Product Attestation Authority (PAA) root that commissioners trust via the Connectivity Standards Alliance’s Distributed Compliance Ledger, according to Google’s Matter attestation primer.

Ownership binding: a database problem disguised as a crypto problem

The ownership binding maps serial numbers or public keys to an owner. In a vertically integrated product, this is a row written when an order ships. In a distributor model, ownership is unknown at build time and must be bound later. FDO models this as an Ownership Voucher, a signed structure created during manufacture and extended as the device changes hands. BRSKI models it as a voucher signed on demand by the Manufacturer Authorized Signing Authority (MASA).

The binding is where most multi-tenant bugs live. A shared claim certificate proves only that a device possesses a secret that every device possesses. Without an independent ownership record, a cloned unit can claim itself into any tenant. Treat the claim service as a first-class system with its own audit log, not a spreadsheet uploaded to a Lambda environment variable.

Operational identity: short-lived, renewable and per tenant

The operational identity is the certificate the device presents to the MQTT broker or IoT hub every day. It should be issued by a CA dedicated to that tenant or region, carry a validity measured in months rather than decades, and be renewable without repeating the onboarding ceremony. Microsoft’s preview documentation is unusually direct on this. Certificates issued by Azure Device Registry are “operational only”, used after a device is onboarded with a different credential, and IoT Hub supports renewing them without reprovisioning the device.

Separating operational from birth identity also makes revocation tractable. Revoking a compromised operational certificate is routine: issue a new one after re-attestation. Revoking a birth certificate retires the unit. If the two are the same certificate, every incident becomes a hardware recall.

Where the cloud provisioning services sit

Every major service maps cleanly onto this architecture. AWS IoT Core fleet provisioning, DPS, an FDO owner onboarding service and a BRSKI registrar all play the “onboarding endpoint plus policy engine” role. Where they differ is in what they accept as proof of birth identity and how much of the ownership and operational layers they implement for you. The next section walks through each.

Walk-Through: Claim Flows, Provisioning Services and the PKI Behind Them

This section walks through IoT device provisioning service by service, then turns to the factory, the PKI hierarchy and the capacity math. The goal is to know exactly what each flow proves, and what it leaves for you to prove.

AWS IoT Core: fleet provisioning by claim, by trusted user, JITP and JITR

AWS offers several distinct paths, and conflating them is a common design error.

Fleet provisioning by claim. Devices ship with a provisioning claim certificate and private key. The claim certificate’s IoT policy should permit only the provisioning topics: $aws/certificates/create/* (or the CSR variant) and $aws/provisioning-templates/<templateName>/provision/*. The device connects, calls CreateKeysAndCertificate or CreateCertificateFromCsr, then calls RegisterThing with the returned certificateOwnershipToken and template parameters such as a serial number. It then disconnects and reconnects with the new certificate. AWS documents that the ownership token expires after one hour. If the certificate has not been activated and attached by then, it is deleted and the device can retry.

Prefer CreateCertificateFromCsr. With CreateKeysAndCertificate, AWS generates the private key and sends it to the device over the TLS session. With a certificate signing request (CSR), the key is generated on the device, ideally inside a secure element, and never leaves it.

Pre-provisioning hooks. A provisioning template can call a Lambda function before anything is created. The function returns allowProvisioning and optional parameterOverrides. This is where the ownership binding is enforced: the hook looks up the serial number and public-key fingerprint in the claim service and refuses anything that does not match. Without a hook, anyone who extracts the shared claim key from one device can register unlimited things.

Certificate provider. Since AWS added the certificate provider feature, CreateCertificateFromCsr can be routed to your own Lambda, which signs with AWS Private CA or any other CA. The documentation is specific about its limits. There is one certificate provider per account, it applies to the whole fleet calling that API, the Lambda must return within five seconds, and the returned certificate must keep the CSR’s subject and public key. This feature lets the operational CA in Figure 1 be yours rather than AWS’s, with your chosen validity and extensions. Certificates generated by AWS IoT itself expire at 2049-12-31T23:59:59Z, which is effectively “never” and a poor default for operational identity.

Provisioning by trusted user. A technician or end user signs in to a mobile app. The app’s backend calls CreateProvisioningClaim, receives a temporary claim certificate and passes it to the device with Wi-Fi credentials. AWS states that this temporary certificate expires after five minutes and the device must obtain its permanent certificate within that window. The ownership binding is the authenticated user session, which makes this flow a good fit for consumer and installer-led commercial products.

JITP and JITR. Just-in-time registration (JITR) and just-in-time provisioning (JITP) apply when every device already carries a unique certificate signed by a CA you registered with AWS IoT. With JITR, the first TLS connection auto-registers the certificate in PENDING_ACTIVATION status and publishes an event to $aws/events/certificates/registered/<caCertificateId>. A rule then invokes your Lambda to check revocation, activate the certificate and attach a policy. JITP attaches a provisioning template to the CA so AWS creates the thing, policy and activation itself. In both cases, design firmware to expect the first connection attempt not to succeed and to retry with backoff. AWS’s guidance requires the certificate to be active before it can connect, and registration runs asynchronously.

Figure 2: AWS IoT fleet provisioning by claim with CSR signing delegated to your own CA and ownership enforced in a pre-provisioning hook.

Figure 2 shows the full happy path. The device connects with the claim certificate and submits a CSR. AWS IoT Core forwards the CSR to the certificate provider Lambda, which signs it with your issuing CA, and returns the certificate plus an ownership token. The device calls RegisterThing, which triggers the pre-provisioning hook. Only when the hook confirms that this serial and key belong to an expected tenant does AWS create the thing and attach policy. The device then reconnects with the operational certificate and discards its claim credential from active use.

A minimal pre-provisioning hook that enforces a claim record looks like this. The table name and fields are illustrative.

import os, boto3

ddb = boto3.resource("dynamodb").Table(os.environ["CLAIM_TABLE"])

def handler(event, context):
    params = event.get("parameters", {})
    serial = params.get("SerialNumber", "")
    fp = params.get("KeyFingerprint", "")
    item = ddb.get_item(Key={"serial": serial}).get("Item")
    ok = bool(item) and item.get("pubkey_sha256") == fp and item.get("state") == "SHIPPED"
    if not ok:
        return {"allowProvisioning": False}
    # Mark consumed so a cloned unit cannot reuse the same serial
    ddb.update_item(
        Key={"serial": serial},
        UpdateExpression="SET #s = :c",
        ConditionExpression="#s = :shipped",
        ExpressionAttributeNames={"#s": "state"},
        ExpressionAttributeValues={":c": "CLAIMED", ":shipped": "SHIPPED"},
    )
    return {
        "allowProvisioning": True,
        "parameterOverrides": {"TenantId": item["tenant"], "Region": item["region"]},
    }

Two details matter. The conditional update makes claiming idempotent and single-use, so a second device presenting the same serial is refused. And the fingerprint parameter should be derived server-side from the CSR wherever possible. A value the device self-reports is only a hint.

Azure IoT Hub Device Provisioning Service: enrollments, attestation and allocation

Azure DPS takes a registry-first approach. Devices contact the shared global endpoint global.azure-devices-provisioning.net with their instance’s ID scope and a registration ID. DPS authenticates them against an enrollment, chooses an IoT hub and registers the device there.

Microsoft’s DPS concepts documentation lists three attestation mechanisms: X.509 certificates, TPM (a nonce challenge answered with a signed SAS token, using the TPM’s endorsement key) and symmetric keys. Enrollment groups support only X.509 and symmetric keys. TPM attestation is available only through individual enrollments. That single fact shapes fleet design. If you want TPM-rooted identity on a million devices with Azure DPS, you either create a million individual enrollments, typically by uploading endorsement keys from the factory manifest, or you use X.509 certificates whose keys are held in the TPM and enroll them through a group keyed on your intermediate CA.

Symmetric key enrollment groups derive each device key as an HMAC-SHA256 of the registration ID under the group key, so the factory never has to store per-device keys. The weakness follows directly: anyone holding the group key can mint a valid key for any registration ID. Never put the group key on a device. Compute derived keys in the factory HSM or a signing service.

import hmac, hashlib, base64

def derive_device_key(group_key_b64: str, registration_id: str) -> str:
    key = base64.b64decode(group_key_b64)
    sig = hmac.new(key, registration_id.encode("utf-8"), hashlib.sha256).digest()
    return base64.b64encode(sig).decode()

DPS then allocates the device using one of four policies: evenly weighted distribution (the default), lowest latency, static configuration in the enrollment, or a custom allocation implemented as an Azure Function that returns the target hub. The custom function plays the same role as the AWS pre-provisioning hook. It is where the ownership lookup and tenant routing belong. Registration IDs are case-insensitive, up to 128 characters, and for X.509 they come from the certificate’s subject common name, which limits them to 64 characters. Plan serial number formats with that limit in mind.

Azure certificate management: an operational CA as a service, in preview

In November 2025 Microsoft introduced two IoT Hub preview features: Azure Device Registry (ADR) integration and Microsoft-backed X.509 certificate management. As of the IoT Hub “what’s new” page, last updated 6 October 2026, both remain in public preview, not recommended for production, free during preview, and limited to Australia East, Japan East, Central US and UK South. Existing hubs cannot be upgraded; you create a new hub linked to an ADR namespace and a DPS instance.

The design is a clean implementation of the operational layer in Figure 1. Each ADR namespace gets a dedicated cloud PKI with one root CA and up to three intermediate CAs. Each intermediate carries a single certificate policy that sets issued-certificate lifetime. CAs use ECDSA on NIST P-384 with SHA-384, keys are held in Azure Managed HSM, and you can bring your own root by chaining an ADR intermediate to it. The device submits a CSR inside the DPS registration transaction, DPS validates its onboarding credential, and ADR issues the operational certificate. Revocation is CRL-based, with a seven-day CRL validity, publication every 3.5 days and an update on every revocation.

The onboarding credential is still yours. ADR does not issue or manage the X.509, TPM or symmetric-key credential used to authenticate to DPS. That is exactly the birth-versus-operational split this architecture argues for. Treat the preview as a design reference and a pilot target, and re-verify status, regions and limits before committing a production programme to it.

FIDO Device Onboard: late binding across clouds

FDO solves the case cloud services do not: the manufacturer does not know who will own the device or which platform it will join. FIDO’s device onboarding overview describes the model. During Device Initialize (DI) in the factory, credentials go into the device’s restricted operating environment, the device receives a GUID and the manufacturer creates an Ownership Voucher. Each reseller extends the voucher by signing it over to the next party. The final owner registers the voucher with a rendezvous server (protocol TO0). The device, on first boot, asks the rendezvous server where its owner is (TO1), then connects directly to the owner, mutually authenticates and receives new credentials and service information (TO2).

Version 1.1 is the version most deployed implementations and certification programmes have targeted. The FIDO Alliance published FDO 2.0 as a Proposed Standard dated 2 April 2026. According to that document, 2.0 drops Intel EPID attestation (supported up to 1.1), adds delegation so a delegate owner can onboard devices with a delegate certificate without extending the voucher, adds capability flags for version negotiation, renames TO2 messages with a “20” suffix and highly recommends, without mandating, post-quantum-safe cryptography. If you are buying FDO-capable hardware in 2026, ask which version and which crypto suites the device firmware and your owner service both implement.

FDO’s ServiceInfo stage is where it hands off to a cloud provisioning service. The owner can deliver a DPS ID scope and X.509 enrollment, or an AWS claim credential, so FDO and cloud provisioning compose rather than compete.

BRSKI and EST: zero-touch for networked infrastructure

RFC 8995, published in May 2021 on the IETF Standards Track, defines BRSKI. A new device, called a pledge, holds an IEEE 802.1AR IDevID. It discovers a join proxy, connects through it to the domain’s registrar, and sends a voucher request. The registrar forwards it to the manufacturer’s MASA, which returns a signed voucher in the RFC 8366 format. The pledge verifies the voucher, imprints on the domain’s trust anchor, then enrolls for a domain certificate over Enrollment over Secure Transport (EST).

EST, defined in RFC 7030 (2013), is a simple HTTPS-based enrollment protocol with well-known operations: /cacerts to fetch trust anchors, /simpleenroll for a first certificate, /simplereenroll to renew, /csrattrs to learn what the CA wants in a CSR and optional /serverkeygen. Even if you never deploy BRSKI, EST is a pragmatic choice for the “renew operational certificate” path on Linux-class gateways. It is standard, works through HTTP proxies and has mature open-source clients and servers. BRSKI is most at home in industrial and enterprise networking, where switches, gateways and controllers join a plant network that has its own registrar and no cloud dependency.

Matter commissioning: a consumer-grade version of the same pattern

Matter applies the three-identity model to the smart home. The DAC is the birth identity, and its subject carries the vendor ID and product ID. The Certification Declaration, signed by the Connectivity Standards Alliance after certification, proves the product passed testing. During commissioning the commissioner establishes a PASE session using the setup passcode, sends a random 32-byte attestation nonce, and verifies the DAC chain, the attestation signature, the Certification Declaration and the vendor and product IDs against the Distributed Compliance Ledger. It then issues a Node Operational Certificate (NOC) under the fabric’s own root. The NOC is the operational identity, scoped to one fabric, and a device can hold several. Our Matter 1.6.1 developer guide covers the newer NFC commissioning and joint fabric features in detail.

Manufacturing-line key injection: where provisioning really starts

Every IoT device provisioning flow above assumes the device holds a private key nobody else has seen. That assumption is created at a line station, and it is where many programmes cut corners.

There are two patterns. In on-device key generation, the station commands the secure element or TPM to generate a key pair internally, reads the public key or a CSR, has the factory issuing CA sign a birth certificate and writes the certificate back. The private key never exists outside the chip. In key injection, an HSM generates the key and writes it into the device. That is faster on some lines and necessary for parts without on-chip generation, but the key transits the station and must be protected by a wrapped-key transport.

On-device generation is the better default. It makes “the factory leaked our keys” structurally impossible rather than procedurally unlikely. Several secure-element vendors also sell pre-provisioned parts. For example, Microchip’s pre-provisioned ATECC608 variants and NXP’s EdgeLock SE050 family ship with keys and certificates generated at the silicon vendor’s facility, plus a signed manifest of public keys. That moves the key ceremony upstream to a supplier with its own audited facility, at the cost of trusting that supplier’s CA. If you use pre-provisioned parts, your birth identity chain is the silicon vendor’s, and your manifest import becomes the binding step.

The station also writes the manifest that feeds the claim service: serial number, public-key hash, birth-certificate serial, firmware version, line and timestamp. Sign the manifest with a key distinct from the issuing CA, and ship it over a channel independent of the device itself. The claim service should refuse any device that is not in a signed manifest. That single rule defeats most cloning attacks against shared-claim flows.

Cycle time is the constraint the security team forgets. A line producing one unit every few seconds cannot afford an onboarding round trip to a remote cloud CA. Put the issuing CA in an HSM on site, or use a local signing appliance with a pre-authorised issuing quota. Keep the station offline from the internet, and batch-upload manifests. As an illustrative example, a line at one unit every six seconds produces 600 units per hour. If on-chip ECDSA P-256 key generation plus signing takes a few hundred milliseconds, it fits inside the cycle. A cloud round trip with retries on a congested factory network often will not.

PKI hierarchy design for X.509 device certificates

Figure 3: Separate manufacturing and operational hierarchies, with per-factory and per-tenant issuing CAs. Matter’s PAA, PAI and DAC chain is the same pattern in a regulated ecosystem.

Figure 3 shows the hierarchy this architecture recommends for X.509 device certificates. Two offline roots exist. The manufacturing root signs one issuing CA per factory or contract manufacturer, which signs birth certificates valid for the device’s life. The operational root signs one issuing CA per tenant, region or product line, which signs short-lived operational certificates. The dotted edge is a relationship, not a signature: the birth certificate is presented during onboarding to justify issuing the operational one. Matter’s three-tier chain on the right is the same idea with the Alliance-governed DCL as the trust distribution mechanism.

Four rules make this hierarchy survive real incidents.

One issuing CA per blast radius. If a contract manufacturer is compromised, you want to revoke one intermediate and the units it signed, not every device you ever built. The same logic applies to tenants on the operational side. Revoking one customer’s issuing CA must not disconnect another customer.

Path length and name constraints. Set pathLenConstraint so issuing CAs cannot create further subordinates, and use name constraints or certificate policies where your validators support them. Many embedded TLS stacks ignore name constraints, so the broker’s authorisation policy, not the certificate, must enforce what a device can access.

Algorithm choice with constrained devices in mind. ECDSA P-256 is the pragmatic baseline for microcontroller-class devices with secure elements. Azure’s preview CA uses P-384 for its CAs. Check that your device’s TLS stack and secure element can verify the chain you choose, since signature verification for larger curves costs more on small MCUs. Track post-quantum migration, which FDO 2.0 now recommends, but do not deploy hybrid certificates to constrained fleets until your broker and device stacks support them end to end.

Validity that matches the renewal mechanism. Birth certificates often use a very long validity or the special notAfter value of 99991231235959Z defined in RFC 5280 for “no well-defined expiration”, because a device on a shelf for years must still onboard. Operational certificates should be short enough that revocation is a backstop rather than the primary control. Months is a reasonable starting point for devices with reliable connectivity. Weeks are achievable for gateways. The ACME short-lived certificate playbook explains why the web PKI is moving to 47-day lifetimes. The same automation logic applies, with different numbers.

Certificate rotation and revocation in practice

Rotation must be an ordinary operation the device performs on a schedule, not an incident procedure. The pattern is identical across platforms. Generate a new key in the secure element (or reuse the key, if the hardware has only one slot and your threat model accepts it). Submit a CSR authenticated by the current operational certificate. Receive the new certificate, test a connection with it, then commit and discard the old one. AWS fleet provisioning and Azure DPS can both be re-run with an operational credential for this purpose. EST’s /simplereenroll is purpose-built for it.

Keep two certificate slots on the device so a failed renewal never bricks it. Start renewal at roughly two-thirds of validity and add random jitter. Without jitter, every device provisioned during one production week renews in the same hour. Treat clock trust carefully. A device with no real-time clock that boots in 1970 will reject every certificate. Either rely on the broker for time, or skip notBefore checks only during the first-boot window, with a documented rationale.

Revocation is weaker in IoT than people assume. Most MQTT brokers and cloud IoT hubs check revocation against their own registry, not against CRLs or OCSP at connect time. In AWS IoT Core you revoke by setting a certificate’s status to REVOKED or INACTIVE in the registry. In Azure the preview CA publishes CRLs and IoT Hub blocks revoked certificates. Your own broker may or may not check anything. Design revocation as a registry state change plus a policy detach, and use CRLs to inform relying parties outside the hub. Short operational lifetimes are the real revocation mechanism for devices that are offline when you revoke them.

Multi-tenant claims: one product, many customers

Software-as-a-service (SaaS) IoT platforms ship identical hardware to many customers. The design question is where tenant identity enters. There are three workable answers.

The first is binding at order time. The claim service maps serial ranges to tenants as orders ship, and the pre-provisioning hook or DPS custom allocation function routes the device. This is simple and works when you control distribution.

The second is binding at installation. A trusted user signs in to the tenant’s app and claims the device by scanning a QR code containing the serial and a short claim secret. AWS’s trusted-user flow and Matter commissioning are both variants. The device’s birth identity proves it is genuine, while the user session proves which tenant it belongs to.

The third is voucher transfer. Ownership travels with an FDO voucher or BRSKI MASA record, and the tenant’s own owner service onboards the device. This suits channel sales and customers who insist on running their own platform.

All three need the same safeguards. A device can be claimed once, transfers require the current owner’s approval, and an unclaim operation rotates the operational identity so the previous tenant’s credential is useless. Model the device lifecycle explicitly as states such as manufactured, shipped, claimed, active, suspended, transferred and retired. Make every transition an audited API call.

Scale math: provisioning rate, quotas and CA throughput

IoT device provisioning traffic is bursty in ways that telemetry is not. The useful question is not average rate but worst-case burst.

AWS publishes default throttles in its IoT Core quota table. CreateCertificateFromCsr defaults to 15 transactions per second (TPS), while CreateKeysAndCertificate, RegisterThing and CreateProvisioningClaim default to 10 TPS. All of these are adjustable. A claim flow that calls CreateCertificateFromCsr then RegisterThing is therefore bounded by RegisterThing at 10 TPS by default, which is 36,000 devices per hour or 864,000 per day if perfectly smooth.

Now an illustrative scenario. A utility installs 2 million meters over 18 months. The average is under 4,000 per day, far inside the quota. But a firmware bug forces every meter to re-provision after an over-the-air update. At 10 TPS, 2,000,000 devices take 200,000 seconds, about 55.6 hours, even with perfect backoff. Meanwhile devices that retry aggressively waste quota on throttled calls. The lessons are to request quota increases before large rollouts, to make re-provisioning a deliberate operation rather than a boot-time default, and to use exponential backoff with full jitter.

CA throughput rarely limits a single fleet. As an illustrative figure, HSM-backed ECDSA signing typically runs at hundreds to thousands of operations per second depending on the HSM model, so check your vendor’s datasheet. Your bottleneck is more likely the certificate provider Lambda’s five-second budget or registry write rates. On AWS, the sample certificate-provider code calls AWS Private CA’s IssueCertificate and then polls GetCertificate, which adds latency. Measure that path under load before relying on it. On Azure, DPS bills per operation. Each registration, re-registration or enrollment change counts, so a renewal design that re-registers every device monthly multiplies the bill twelvefold compared with yearly.

Item	Value	Source or status
AWS RegisterThing default TPS	10, adjustable	AWS IoT Core quotas
AWS CreateCertificateFromCsr default TPS	15, adjustable	AWS IoT Core quotas
AWS ownership token lifetime	1 hour	AWS fleet provisioning docs
AWS trusted-user claim cert lifetime	5 minutes	AWS fleet provisioning docs
AWS certificate provider Lambda budget	5 seconds	AWS certificate provider docs
Azure ADR CRL validity	7 days, refreshed every 3.5 days	Microsoft preview docs
2M re-provisioning at 10 TPS	about 55.6 hours	Illustrative calculation
Line output at 6 s per unit	600 units per hour	Illustrative

Trade-offs, Gotchas, and What Goes Wrong

Shared claim certificates are a cloning invitation. This is the most common IoT device provisioning flaw we see in reviews. A single claim key in every unit’s flash is a single secret with millions of copies. Someone will extract it. Mitigations, in order of strength, are a unique birth identity per device, a signed-manifest allowlist enforced in the hook, single-use claiming, and monitoring for claim-certificate use from unexpected networks. AWS’s own guidance says to watch CloudWatch for misuse and deactivate the claim certificate if needed. Plan for that: deactivating it stops every not-yet-provisioned unit still in the channel, so keep claim certificates per batch or per production month.

Provisioning at every boot. Firmware that re-runs the full flow on each power cycle turns a regional power cut into a provisioning storm, and every retry burns quota. Provision once, persist the result, and fall back to re-provisioning only on explicit authentication failure.

Lost state between steps. A device that obtains a certificate but loses power before RegisterThing holds a credential with no thing attached. AWS deletes it after the one-hour token window, so the device must be able to start again cleanly. Write each step’s result to non-volatile storage before taking the next step.

Clock and chain mismatches. Devices fail TLS because they lack the right root, because they cannot parse a P-384 chain, or because their clock is wrong. Test the exact chain and an unset clock on real hardware before mass production. Rolling a new root later requires firmware updates in the field.

Preview dependencies. Azure’s certificate management is free and promising but in preview, limited to four regions and unavailable on existing hubs. Building a product launch on it without a fallback CA plan is a schedule risk.

TPM assumptions on Azure. Teams often design around TPM enrollment groups that DPS does not offer. Either budget for individual enrollments fed from the factory manifest, or use X.509 with TPM-held keys.

Revocation that does not reach offline devices. A revoked device that never reconnects keeps a valid-looking certificate. That is harmless only if the broker checks the registry. Do not let a secondary service, such as a firmware download endpoint, accept device certificates without the same check.

Vendor lock-in through birth identity. If the only identity a device has was minted by one cloud provider, migrating means touching every unit. Birth identity under your own root, or FDO, keeps the exit door open.

Figure 4: Choosing a zero touch provisioning flow. Every branch converges on the same operational certificate lifecycle.

Figure 4 condenses the choice. If the owner is known at manufacture and each unit has a unique key, pre-register X.509 certificates through JITP or a DPS enrollment group. If units share a claim credential, the hook allowlist is non-negotiable. If ownership is unknown and devices are IP-connected across clouds, FDO’s voucher model fits. Installer-led products use trusted-user claims or Matter commissioning. Infrastructure on an owned network fits BRSKI with EST. All branches end in the same operational lifecycle of rotation and revocation.

Practical Recommendations

Start IoT device provisioning design with the factory, not the cloud console. Decide whether keys are generated on-chip or bought pre-provisioned, who runs the issuing CA and how manifests reach your claim service. Those choices constrain every later option, and they are the hardest to change after the first production run.

Then pick one primary onboarding flow per product line using Figure 4, and implement the ownership binding as its own service with an audit trail. The cloud provisioning service should call it, through a pre-provisioning hook or DPS custom allocation, rather than embed it. Keep operational certificates short-lived and under a CA you control, whether that is AWS Private CA behind a certificate provider, your own CA, or Azure’s managed CA once it is production-ready for your regions.

Finally, rehearse the bad days. Load-test a full-fleet re-provisioning against your real quotas. Revoke an issuing CA in staging and measure what breaks. Power-cycle a device between every provisioning step and confirm it recovers.

Checklist:

• [ ] Unique key per device, generated in a secure element or TPM where possible.
• [ ] Separate manufacturing and operational roots, both offline, with per-factory and per-tenant issuing CAs.
• [ ] Signed factory manifest feeding a claim service; unknown devices refused.
• [ ] CSR-based issuance; no cloud-generated private keys in production.
• [ ] Single-use, idempotent claims with an explicit device lifecycle state machine.
• [ ] Operational certificate renewal at about two-thirds of validity, with jitter and dual slots.
• [ ] Quota increases requested and retry backoff tested before each large rollout.
• [ ] Revocation implemented as registry state plus policy detach, verified on every service that accepts device certificates.

Frequently Asked Questions

What is IoT device provisioning?

IoT device provisioning is the process of giving a device a trusted identity, registering it with a backend and delivering the credentials and configuration it needs to operate. At scale it has three parts. A birth identity is created at manufacture, ownership is bound to a customer or tenant, and an operational identity is used for day-to-day connections. Cloud services such as AWS IoT Core fleet provisioning and Azure DPS automate the onboarding step. They depend on a factory process and a PKI that you design separately.

What is zero touch provisioning for IoT?

Zero touch provisioning means a device can be unboxed, powered on and connected to the right backend without anyone entering credentials or configuration by hand. The device uses a credential installed at manufacture to authenticate to a provisioning service, which recognises it, chooses its tenant and hub and issues operational credentials. Standards such as FIDO Device Onboard and BRSKI (RFC 8995) extend this to cases where the owner is unknown at build time. Cloud services cover cases where the target cloud is known in advance.

What is the difference between Azure DPS enrollment groups and individual enrollments?

An enrollment group covers many devices that share an attestation mechanism. In practice that is X.509 certificates chaining to a common CA, or symmetric keys derived from a group key. An individual enrollment covers exactly one device and is the only option for TPM attestation. Microsoft recommends groups for large fleets with the same initial configuration and individual enrollments for devices needing unique settings or TPM-based SAS authentication. Many large fleets use X.509 groups, with private keys stored in a TPM or secure element.

Is fleet provisioning by claim secure?

It is secure enough only when the claim credential is treated as weak and ownership is checked separately. Because the claim certificate is shared, anyone who extracts it can request certificates. Restrict its IoT policy to provisioning topics. Use a pre-provisioning hook that checks the serial number and key against a signed factory manifest and makes each claim single-use. Prefer CreateCertificateFromCsr so private keys are generated on the device. Rotate claim certificates per batch so you can deactivate one without stranding your entire channel inventory.

How often should X.509 device certificates be rotated?

Separate the two certificate types. Birth certificates are generally not rotated. They identify the hardware for its lifetime. Operational certificates should be renewed on a schedule your connectivity can support reliably, commonly months for battery or intermittently connected devices and weeks for always-on gateways. Start renewal at about two-thirds of validity, add random jitter to avoid synchronised renewal storms, and keep the old certificate until the new one connects successfully. Short lifetimes limit the damage from compromised keys that revocation cannot reach.

Does FIDO Device Onboard replace AWS or Azure provisioning?

No, it complements them. FDO handles late binding: it proves to a device who its owner is, even when that owner was unknown at manufacture, using an Ownership Voucher and a rendezvous server. Once the device trusts its owner, the owner’s onboarding service delivers configuration. That can include an Azure DPS ID scope and enrollment credential or an AWS claim certificate. The cloud service then performs registration and operational certificate issuance. FDO 2.0 reached Proposed Standard status in April 2026, but check which version your devices and owner service support.

Further Reading

• Device shadow vs device twin compared across AWS, Azure and Eclipse Ditto covers the state model a device inherits once provisioning creates it.
• ThingsBoard IoT platform device provisioning tutorial is a hands-on, single-platform walk-through of provision keys and claiming.
• ACME protocol and short-lived certificates with 47-day TLS lifetimes explains the automation mindset behind short operational certificates.
• TPM 2.0 secure boot, measured boot and remote attestation for IoT fleets goes deeper on the hardware root of trust behind birth identity.
• AWS IoT Core: provisioning devices without device certificates is the primary reference for claim and trusted-user flows.
• RFC 8995, Bootstrapping Remote Secure Key Infrastructure is the IETF specification for voucher-based zero-touch enrollment.

By Riju — about