TL;DR:

  • Manual certificate issuance doesn’t scale past a few hundred devices — fleet provisioning patterns automate device identity from factory to field
  • AWS IoT Core fleet provisioning uses claim certificates to bootstrap devices; Just-in-Time Registration (JITR) triggers Lambda functions to issue production certificates on first connection
  • Certificate rotation is the hardest operational challenge: devices that miss a rotation cycle can be permanently locked out without a recovery path built in from the start

Provisioning ten IoT devices manually is tedious. Provisioning ten thousand is impossible without a systematic approach to device identity, certificate management, and the workflows that govern how a device goes from factory to field to production-ready state. Most teams discover this the hard way when they start scaling.

This guide covers the main fleet provisioning patterns, the AWS IoT Core implementation in depth, and the operational requirements that teams commonly underestimate.

The Device Identity Problem

Every IoT device needs a unique identity that:

  • Proves the device is legitimate (not a counterfeit or rogue device)
  • Authorises the device to connect to your specific IoT platform
  • Can be revoked if the device is compromised or decommissioned
  • Supports rotation without requiring physical access to the device

X.509 certificates are the standard mechanism. Each device gets a unique certificate signed by a Certificate Authority (CA) you control. The certificate proves identity; the CA’s trust relationship with your IoT platform authorises the connection.

The challenge is issuing unique certificates to potentially millions of devices without creating a manual bottleneck at the factory or field deployment stage.

Pattern 1: Fleet Provisioning with Claim Certificates

AWS IoT Core fleet provisioning is the cleanest solution for new device programs. The flow:

  1. At manufacture: devices are loaded with a shared “claim” certificate and private key. This is not the device’s final identity — it’s a temporary pass that authorises the device to request its permanent certificate.

  2. On first boot/connection: the device connects to AWS IoT Core using the claim certificate and calls the provisioning API with device-specific information (serial number, hardware version, etc.).

  3. Provisioning template: a template in AWS IoT Core defines what happens during provisioning — what certificate to issue, what policies to attach, what Thing to create in the IoT registry, and optionally what pre-provisioning hooks to call.

  4. Device receives its certificate: AWS IoT Core returns a unique certificate and private key. The device stores these and uses them for all subsequent connections. The claim certificate is invalidated.

The critical implementation detail: the claim certificate must be stored in secure hardware (TPM, Secure Element, or at minimum secure flash) on the device. A claim certificate that leaks allows anyone to provision rogue devices into your fleet.

// Example fleet provisioning template
{
  "Parameters": {
    "SerialNumber": {"Type": "String"},
    "HardwareVersion": {"Type": "String"}
  },
  "Resources": {
    "thing": {
      "Type": "AWS::IoT::Thing",
      "Properties": {
        "ThingName": {"Fn::Join": ["", ["device-", {"Ref": "SerialNumber"}]]},
        "AttributePayload": {
          "hw_version": {"Ref": "HardwareVersion"}
        }
      }
    },
    "certificate": {
      "Type": "AWS::IoT::Certificate",
      "Properties": {
        "CertificateId": {"Ref": "AWS::IoT::Certificate::Id"},
        "Status": "Active"
      }
    },
    "policy": {
      "Type": "AWS::IoT::Policy",
      "Properties": {
        "PolicyName": "standard-device-policy"
      }
    }
  }
}

Pattern 2: Just-in-Time Registration (JITR)

JITR is the better pattern when you can’t change the device firmware to support the fleet provisioning API — for example, when provisioning existing devices in the field, or when integrating with third-party hardware that already has manufacturer certificates.

JITR uses your own CA registered with AWS IoT Core. When a device with a certificate signed by your CA connects for the first time:

  1. AWS IoT Core detects an unknown certificate (not yet registered).
  2. It publishes an event to $aws/events/certificates/registered/{certificateId}.
  3. A Lambda function subscribed to this topic receives the event.
  4. The Lambda validates the device (check against your device database, verify the serial number, check it hasn’t been provisioned before), activates the certificate in AWS IoT Core, and attaches the appropriate policy.
  5. The device reconnects — now its certificate is active and it proceeds normally.

JITR gives you full control over provisioning logic in the Lambda, including rejecting devices that don’t pass validation, applying device-specific policies, and logging all provisioning events to your audit trail.

The main operational consideration: JITR requires your Lambda to be available at the moment a device first connects. Failures in the Lambda mean the device can’t provision. Build retry logic into devices — they should reconnect and retry provisioning rather than permanently failing.

Certificate Rotation

Certificates expire. Devices that miss a rotation end up locked out of your IoT platform — unreachable, potentially in the field, requiring physical intervention or a factory reset. This is one of the most expensive operational failures in IoT at scale.

Design for rotation from day one:

  • Issue certificates with defined lifetimes. 1–3 years is common for device certificates; shorter for systems with higher security requirements.
  • Track certificate expiry dates in your device management system, not just in AWS IoT Core.
  • Implement rotation at least 90 days before expiry. Don’t cut it close.

The rotation flow:

  1. Device connects with its current certificate.
  2. You detect the certificate is approaching expiry.
  3. You issue a new certificate via the AWS IoT Core API and push it to the device through your IoT application layer (MQTT message, device shadow update, etc.).
  4. Device stores the new certificate and reconnects with it.
  5. You revoke the old certificate once you’ve confirmed the device is using the new one.

The step most teams skip: confirming the device successfully adopted the new certificate before revoking the old one. Revoke too early and you lock out devices that are still transitioning. Build a confirmation handshake into your rotation flow.

Handling devices that miss rotation:

Some devices will be offline during rotation — seasonal equipment, assets in transit, devices in areas with intermittent connectivity. Your CA and IoT platform need a recovery path for devices that reconnect with expired certificates. Options:

  • Maintain a short-lived “recovery” policy that allows expired certificates to connect to a limited provisioning-only topic, triggering re-provisioning.
  • Factory reset and re-provision from scratch (acceptable for some device types, not for others).

Certificate Revocation at Scale

When a device is compromised, decommissioned, or reported stolen, you need to revoke its certificate quickly. AWS IoT Core supports certificate revocation through:

  • Status update: Set the certificate status to INACTIVE in AWS IoT Core. Active connections are terminated; new connections with that certificate are rejected. This is immediate.
  • Certificate Revocation List (CRL): If devices connect to your own broker (not directly to AWS IoT Core), publish a CRL that brokers check on connection.

For large fleets, build certificate revocation into your incident response runbooks. Automated revocation triggered by anomaly detection (unusual message rates, unexpected message topics, connections from unexpected geographic regions) is the end state; manual revocation with a defined process is the minimum.

Operational Tooling

AWS IoT Device Defender: Continuous audit of your IoT configuration against security best practices, including certificate validity, policy permissions, and device behaviour anomalies. Essential for production fleets.

AWS IoT Fleet Hub: Dashboard for fleet-wide certificate status, provisioning events, and device health. Useful for operations teams who don’t live in the AWS console.

Custom device registry: AWS IoT Core’s Thing registry is useful but limited. Most teams build a supplemental device database (DynamoDB or RDS) that stores manufacturing data, firmware versions, customer assignment, deployment location, and certificate history. This database drives provisioning logic and rotation scheduling.

The provisioning and certificate management architecture you design before you ship the first device determines how much operational pain you absorb at scale. It’s worth the investment to design it correctly upfront — retrofitting a provisioning system onto a deployed fleet is significantly harder than building it right the first time.