Four Ways to Register a Device with AWS IoT Core
The four AWS IoT provisioning paths — manual, trusted user, by claim, and JITP — how each works, how to choose, and the tradeoffs between them.
Series: digital-operations (1 article)
- 1Four Ways to Register a Device with AWS IoT Core This article
Four Ways to Register a Device with AWS IoT Core
The most interesting moment in a device's life is the first time it connects to the cloud. Before that connection it's an anonymous box on a shelf; after it, it's a trusted identity that can publish telemetry, receive jobs, and act on your behalf. How you cross that line — how a device goes from "manufactured" to "registered and trusted" — is one of the more consequential design decisions in any IoT system, and one that's surprisingly easy to get wrong.
AWS IoT Core gives you four ways to register a device . They aren't ranked from worst to best. They're different answers to a different question each time: who is trusted, and when does the device get its permanent identity? This post walks through all four, the flow that most automated fleets actually use, and one distinction that's easy to misread the first time.
The four approaches at a glance
| Approach | Who owns the CA | When the device gets its permanent cert | Best for |
|---|---|---|---|
| Single-thing / manual | AWS IoT CA | Before it ships | Lab devices, one-offs, prototypes |
| Provisioning by trusted user | AWS IoT CA | At commissioning — an authenticated actor calls the API on demand | Any scale, when a commissioning workflow already exists |
| Fleet provisioning by claim | AWS IoT CA | On first connection — device swaps a shared claim cert for a permanent one | Fully automated deployments with no human in the loop |
| JITP / JITR | You own the CA | Before it ships — identity burned in at the factory | Hardware with factory-provisioned identity (HSM, secure element) |
Single-thing provisioning is the one you meet first: you create a Thing, generate a certificate, attach a policy, and flash all of it onto the device by hand. It's perfect for learning and lab work and completely impractical at fleet scale — nobody wants to hand-mint ten thousand certificates.
The other three are how you scale, and the rest of this post is about telling them apart.
Fleet provisioning by claim: the workhorse flow
Fleet provisioning by claim is the path most fully-automated deployments land on, because it needs no human at install time. The idea: every device ships with the same shared claim certificate — a bootstrap credential that can do almost nothing except ask for a real identity. On first connection, the device trades that claim cert for a unique, permanent certificate that IoT Core mints just for it.
Here's the flow, concretely, the way it plays out with the AWS IoT Device Client as the on-device agent:
- A provisioning template defines what to create when a device presents a valid claim: the Thing name, the policy to attach, the group to join, and which permanent certificate to activate. See the provisioning template reference .
- The claim certificate is issued with a deliberately tiny IoT policy — it can connect and call the
$aws/certificates/create/*and$aws/provisioning-templates/{template}/provision/*reserved topics, and nothing else. It cannot publish telemetry or subscribe to anything operational. - On first boot, the device loads the claim cert and calls
CreateKeysAndCertificatefollowed byRegisterThing. IoT Core evaluates the request, creates the Thing, and issues a permanent per-device certificate. - The claim cert is deleted from disk the moment
RegisterThingsucceeds. From then on the device authenticates only with its own unique identity.
Two properties make this clean. The device never holds AWS credentials — the claim cert is scoped so narrowly that leaking it costs you far less than leaking an IAM key. And the permanent certificate's private key can be generated on the device (or on IoT Core) so that each unit ends up cryptographically distinct even though they all shipped identical.
The one thing to respect: the claim certificate is a shared static secret. Anyone holding it can attempt to provision. That's exactly why the next piece matters.
The pre-provisioning hook is your control point
Because the claim cert is a wide key, "any holder can try to register" is the default posture. The pre-provisioning hook is where you narrow it. It's a Lambda that IoT Core calls before it acts on a provisioning request — and its return value decides whether provisioning proceeds.
This is the natural home for whatever "is this a device I actually expect?" logic your system needs:
- Check the incoming serial number against an authoritative source — a device registry, a manufacturing database, an ERP record of what you actually shipped.
- Reject unknown serials, duplicates, or devices that have already provisioned.
- Enrich the registration with attributes (site, model, firmware baseline) that later drive fleet indexing queries and targeted IoT Jobs .
A hook that always returns "allow" turns the shared claim cert into the only gate — fine for a workshop or a closed lab, risky for production. A hook that validates against an authoritative source turns a wide key into a narrow one. The mechanism is the same either way; what you enforce in the hook is a policy choice, and it's the choice that decides how much a leaked claim cert can actually hurt you.
Provisioning by trusted user: when there's a human at install
Provisioning by trusted user fits the case where a person — a field engineer, an installer, a technician — is present at commissioning. Instead of every device carrying a shared secret, the authenticated human requests a one-time-use claim on demand:
- The operator authenticates to your management app (an Amazon Cognito user pool, say).
- The app calls
CreateProvisioningClaim, which returns a short-lived, single-use claim certificate. - That claim is handed to the specific device in front of the operator.
- The device runs the same
RegisterThingflow as before.
The trade-off against by-claim is clean:
| By claim | By trusted user | |
|---|---|---|
| Human required at install | No | Yes — authenticated |
| Per-device audit trail | No (shared cert) | Yes — operator identity + CloudTrail per device |
| Risk surface | Shared static cert must stay secret | No shared secret; short-lived, single-use claims |
| Works with no cloud at the factory | Yes | No — needs a live API call |
By-claim wins when there's genuinely no human in the loop. Trusted user wins almost everywhere a commissioning step already exists, because you get a per-device audit trail and there's no long-lived shared secret to protect.
What JITP actually changes
Just-in-Time Provisioning (JITP) and Just-in-Time Registration (JITR) look, from a distance, like by-claim: the device "self-registers" on first connection. But they're fundamentally different, and it's worth being precise about how.
- With by-claim, the device arrives as a blank slate and AWS mints its identity on first boot.
- With JITP/JITR, the device already holds its permanent identity, signed by a CA you own, burned in at the factory. AWS just learns about it when it first connects and registers it automatically.
It's easy to assume JITP is the only way to get a permanent, factory-provisioned identity — but it isn't. You can burn a per-unit identity in at the factory using the AWS IoT CA too: mint a per-device cert (using
CreateCertificateFromCsr so the private key never leaves the secure element) and flash it in. Both approaches produce the same kind of thing — a unique, permanent certificate per device. What differs is everything around the cert.So what actually separates them? The factory's trust boundary — who holds credentials, and whether the production line depends on your cloud.
- AWS IoT CA at the factory — the flashing station must hold live credentials to your AWS account and call AWS IoT per unit. That extends your account's trust boundary onto the factory floor (often a third-party contract manufacturer) and couples your production line's throughput to your cloud being reachable.
- JITP with a CA you own (for example, AWS Private CA ) — the factory signs certs locally, never touching your AWS account. The manufacturer can even run their own Private CA in their own AWS account; you just register that CA's certificate in your IoT account. No cross-account credentials, no per-unit call to your cloud.
Read that as a decision rule:
- If the factory is trusted with your AWS credentials and has reliable connectivity — say, it's your own facility — minting via the AWS IoT CA is the simpler design, with less machinery to run.
- JITP earns its keep when you can't or won't put AWS credentials in the factory, need the production line to run independently of your cloud, or must be your own root of trust for compliance or portability reasons.
Both give each device a unique, permanent certificate. What changes across these options is where the trust boundary sits and who has to hold credentials — a process and operations property, not a property of the cert itself.
How to choose
Strip away the mechanics and the decision comes down to three questions:
- Is there a human at commissioning? If yes, trusted user gives you a per-device audit trail and no shared secret — reach for it first.
- Fully automated, no human, no factory-side identity? By claim, with a pre-provisioning hook that validates against an authoritative device list. Don't ship the log-only hook to production.
- Do you need the factory to be independent of your AWS account, or to be your own root of trust? JITP with a CA you own. Otherwise, factory-minting with the AWS IoT CA is the simpler path.
And for the first device you ever register — the one you're learning on — single-thing manual provisioning is completely fine. Just don't build a fleet on it.
Try it hands-on
If you want to watch the by-claim flow actually run — claim cert in Secrets Manager, the Device Client calling
RegisterThing, the permanent cert showing up in the registry, and a real Raspberry Pi joining a fleet over SSH — the open-source Edge to Cloud Digital Ops Workshop walks through it end to end, alongside IoT Jobs, Device Shadows, and fleet indexing. It's a good way to make all of this concrete instead of conceptual.The takeaway I'd leave you with: there's no default "best" among these four. Each is the right answer to a specific question about who you trust and when. Get that framing right and the mechanics fall out of it — and you'll stop reaching for JITP by reflex when a simpler path would fit just as well.
Series: digital-operations (1 article)
- 1Four Ways to Register a Device with AWS IoT Core This article
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article