Designing Device Onboarding with AWS IoT JITP
A practical look at provisioning fleets at scale with Just-in-Time Provisioning — when it fits, where it breaks, and how to keep certificate lifecycles sane.
Device onboarding is the first thing every IoT platform gets wrong and the last thing it gets right. The decisions you make here — identity, trust, and the moment a device first speaks to the cloud — quietly constrain everything that follows: security posture, operational cost, and how painful the next hundred thousand devices will be to ship.
This is a placeholder article. The structure below sketches how the finished piece is organized.
Why onboarding is an architecture decision, not a feature
Onboarding determines how identity is established, how trust is rooted, and how a device transitions from “manufactured” to “managed.” Treating it as a checkbox tends to produce one of two failure modes: manual provisioning that doesn’t scale, or shared credentials that can’t be revoked.
Just-in-Time Provisioning, briefly
With JITP, devices ship with a certificate signed by a CA you’ve registered with AWS IoT Core. On first connection, IoT Core provisions the device against a template — creating the thing, policy, and certificate state automatically. No device-by-device pre-registration.
Where JITP fits
- High-volume fleets where pre-registration is impractical.
- Manufacturing flows that can inject a per-device key and certificate.
- Cases where the CA hierarchy is genuinely under your control.
Where it breaks
- When key material is generated off-device and shipped alongside it.
- When the provisioning template hides policy decisions that should be explicit.
- When certificate rotation isn’t designed up front — JITP gets you the first certificate, not the next one.
Keeping certificate lifecycles sane
The interesting work isn’t day-one provisioning; it’s day-800 rotation, revocation, and audit. Design for the full lifecycle before you celebrate the first device connecting.