AWS IoT Core vs Custom PKI: The Security Decision You Cannot Cheaply Undo

Most teams need this answer: if your devices will run on AWS, ship within the next two quarters, and face no certification regime, use the certificates AWS IoT Core issues for you and put the saved weeks into the product. Own the certificate authority from day one if your hardware will outlive the cloud contract, must authenticate against anything other than AWS, or sits inside a product whose auditors will ask who controls the signing key. What follows is about telling those two situations apart before the first production run.

This decision is sticky in a way most architecture choices are not. You can swap a database after launch. You cannot easily swap the root certificate baked into a device sitting in a basement in Ohio. The trust anchor you pick is the one your fleet keeps until the hardware is retired or physically touched, and touching a fleet in the field is the most expensive thing an IoT company can be forced to do.

The short answer, by fleet shape

Most teams asking this question fall into one of three situations. Each has a clear answer.

• Prototype through roughly 10,000 devices, AWS only, no regulator. Use AWS IoT Core managed certificates with fleet provisioning. You get mutual TLS working in a day, a device registry you can query, and per-device policies attached to each certificate. Revisit when a second cloud or a compliance requirement appears, not before.
• Regulated or long-lived hardware. Medical devices, industrial controllers, utility meters and anything automotive commonly stay in service for ten to fifteen years. Own the CA. The certificate hierarchy must be planned against the hardware's service life, and you cannot hand that planning off to a provider's defaults.
• Multi-cloud, on-premise brokers, or a deliberate hedge. Own the CA. One chain of trust can then authenticate devices against AWS IoT Core, against a self-hosted MQTT broker, and against whatever you move to in 2031, without a field visit in between.

Picking the wrong option is rarely the expensive mistake. The costly one is choosing without knowing which of the three applies to you, and then finding the answer after the first production run.

What you are actually choosing

AWS IoT Core versus custom PKI looks like a single decision. In fact it is three. Conflating them is why these discussions keep going in circles.

1. The trust anchor. Whose root certificate does the device trust, and who holds the private key that signs everything below it? This is the part you cannot change without touching the device.
2. Issuance. How does a device get its first legitimate identity, on a factory floor that may belong to a contract manufacturer you do not control, possibly with no internet at the bench?
3. Revocation and rotation. After a device is stolen, how do you un-trust it, and how do you replace every certificate in the fleet before they expire?

AWS IoT Core answers all three with sensible defaults, while a custom PKI leaves the answers to you. Those defaults are genuinely good. So the real question is whether they are yours to change later, not whether they work.

To make this concrete, count the components your team ends up operating. IoT Core with fleet provisioning leaves you running three: a provisioning template and its claim credential, the policy model deciding what each certificate may publish and subscribe to, and a rotation job. A managed private CA brings that to five, since the CA and its revocation publishing become yours. Build the whole thing yourself and the list grows to eight: root key custody, an issuing CA, an enrollment service, a revocation endpoint, certificate distribution, monitoring, rotation automation, and the audit evidence proving all of it worked. Any serious auditor will expect the root key in a hardware security module; doing that adds the HSM cluster plus the key ceremony that governs it.

When AWS IoT Core is the right call

On three counts that matter more than engineers tend to admit, the managed path wins.

Time to a secure connection. With fleet provisioning templates, a device bootstraps using a shared claim credential, swaps it for a unique certificate on first connect, and never takes a long-lived shared secret into the field. To build the equivalent, you design an enrollment protocol, harden it against a device someone has opened on a workbench, and test it on hardware you do not have yet.

Revocation as a flag, not a publication event. In IoT Core, a certificate is a registry object with a status. Setting it to inactive stops the next connection attempt. There is no list to regenerate, no endpoint for devices to fetch, and no window where some devices have the new revocation list and others do not. For a team without a security engineer on staff, that difference is worth more than any feature comparison.

Inventory you can query. The registry tracks which certificate belongs to which thing, when it expires, and which policy is attached. AWS IoT Device Defender can audit that set for the failure modes teams really run into: certificates close to expiry, for instance, or a single certificate shared across many devices because someone cloned a firmware image. Most self-built PKIs get that visibility a year late, after an incident.

If nobody on the team has run a certificate authority before, that is a legitimate architectural input, not an admission of weakness. Teams that need the skill in-house hire for it, or bring in AWS engineers who have shipped a provisioning flow at scale.

When a custom PKI earns its keep

Four conditions flip the answer. Usually any one of them is enough.

The hardware outlives the plan. Install a meter in 2026, service it until 2041, and it needs a chain of trust valid for fifteen years, plus a documented path for what happens when an intermediate expires in year eight. Only you know the service life, so that calculation is yours.

Someone will audit the key ceremony. Under California's SB-327, connected devices must ship with unique credentials instead of a shared default. The EU Cyber Resilience Act pushes manufacturers toward documented vulnerability handling and secure-by-default identity. For medical devices, premarket cybersecurity expectations go further and ask how identity is issued and withdrawn. A managed CA is not forbidden by any of these. They do ask for evidence of who controls the signing key, though, and that evidence is harder to produce for a key you do not hold.

The factory cannot phone home. Suppose identity must be injected at a contract manufacturer's bench that has no outbound internet, or without giving that manufacturer a credential able to create things in your cloud account. Then offline issuance from your own CA is the clean answer.

You intend to keep your options open. Once your own CA is registered against IoT Core, moving a fleet to another broker is a server-side configuration change. If the provider's CA issued the certificates, that same move requires re-provisioning every device, which usually means a firmware campaign and a tail of units that never update.

Owning the CA does not mean leaving AWS. Registering your own CA with IoT Core, then using just-in-time registration so a device's first connection enrolls it automatically, is the most common serious configuration. You keep the broker, the rules engine and the registry; you keep the root key too. Getting that split right is work for security engineers rather than a weekend spike.

Side by side: the questions that actually differ

Feature tables comparing these two options usually list what both can do. This one lists only the places where the answers diverge.

On cost, do not settle this with a spreadsheet of list prices. Managed private CA services bill a monthly fee per authority plus a per-certificate charge, so the floor dominates at small fleets and the per-certificate line dominates at large ones. Self-hosting converts both into salary, hardware and on-call time, which is cheaper on paper and rarely cheaper in practice. Price the current rate cards when you budget, and estimate the development cost from the work rather than from the tooling.

Rotation load is the number that settles most arguments

Fleet size divided by certificate lifetime in days gives the number of rotations your system has to complete every day, forever. On one-year certificates, 1,000 devices means 3 rotations a day, 10,000 means 28, 50,000 means 137, and 250,000 means 685. Who issues the certificates changes nothing in that arithmetic.

The arithmetic shows where manual operation dies. Suppose one person can babysit five rotations a day next to their real job: the ceiling is then about 1,800 devices on one-year certificates. Beyond that, rotation must be automated, monitored and alerted on, since a failed rotation throws no error you will see. Instead it produces a device that silently stops connecting some months later, somewhere nobody wants to visit.

Shortening certificate lifetimes, which security teams increasingly ask for, multiplies the load directly. Move from one-year to 90-day certificates and a 10,000-device fleet goes from 28 rotations a day to 112. That is fine if rotation runs unattended and pages someone on failure. It is a slow-motion outage if rotation is a runbook. Run the calculation for your three-year fleet target before you choose a CA, not after.

Revocation, and the hour you cannot get back

Every team plans how identity gets issued. Far fewer rehearse taking it back, yet revocation is what you are judged on after an incident. Answer this out loud: how much time passes between the moment you decide a device is compromised and the moment it can no longer connect? An answer not measured in minutes means you have a hope, not a revocation story.

On the managed path, the registry is the answer. Mark a certificate inactive and its next connection fails; there is nothing to distribute and no propagation delay to reason about.

Own the CA and you own the answer. A certificate revocation list is a signed file that grows with each revocation and that devices must fetch on a schedule, which makes your configured refresh interval your worst-case exposure. The Online Certificate Status Protocol swaps that for a per-certificate query answered in real time, with far smaller responses; that is why it scales better across a large PKI. It brings a new dependency, though. When the responder is unreachable, clients have to choose between failing open and failing closed, and neither answer is comfortable. Client-side checks also leak to a third party which certificate is being validated.

Stapling fixes most of that by shifting the query to the server: it fetches the status, caches it, and attaches it to the certificate during the TLS handshake. For server certificates on custom domains, AWS IoT Core supports stapling. It refreshes the response hourly and serves it from cache, so the device can validate the server without a round trip of its own.

Whatever path you take, write down the revocation drill and run it on a real device before launch. Treat it as you would monitoring a production system: alerting nobody has tested is indistinguishable from no alerting.

Decide it in five questions

Answer these questions honestly and in writing, together with the people who will carry the result.

1. For how many years will this hardware stay in service, and will any certificate in the chain expire before that?
2. Will anything other than AWS ever need to authenticate these devices?
3. Is a regulator, enterprise customer or auditor going to ask who controls the signing key?
4. Who issues identity at the factory, and would you be willing to hand them a credential that touches your cloud account?
5. Given your three-year fleet size and target certificate lifetime, how many rotations per day does that mean, and who owns the job performing them?

When one or two answers push toward ownership, start on AWS IoT Core managed certificates and keep the migration path documented. With three or more, register your own CA now, while the fleet is still small enough that a mistake costs a firmware build rather than a truck roll. If none do, the managed path is the correct engineering decision and no compromise.

Whatever you choose, have the decision reviewed by someone who has operated both. The failure modes here are quiet, slow and expensive. If that experience is not on your team, bring in IoT developers who have run a fleet through a certificate rotation and ask them what broke.