Device certificates without a PKI team
Why device identity is where fleets cut corners, what doing it properly looks like, and how our certificate authority will make it the easy option.
Ask how a fleet's devices prove who they are, and the honest answers are often uncomfortable: the same password in every unit, one certificate copied into thousands of devices, or a root key on someone's laptop. Nobody chooses these on purpose. Doing it properly takes a public key infrastructure, and running one is a specialist job most equipment makers don't have anyone for.
What goes wrong
- Shared secrets. One leaked device leaks the whole fleet, and you can't revoke one device without revoking all.
- Copied certificates. Every device looks the same to the cloud, so a cloned device is indistinguishable from a real one.
- Certificates that expire. A ten-year certificate is a ten-year risk; a one-year certificate nobody renews takes a fleet offline on the same day.
- A root key that isn't protected. Whoever holds it can make devices you'll trust.
What doing it properly looks like
- Every device has its own key, generated inside the device, in its secure element or TPM where it has one, and never copied anywhere.
- Two certificates. A birth certificate from the factory proves where the device came from. A short-lived operational certificate, renewed every few weeks, is what it connects with.
- Renewal is automatic, over the device's own connection, long before expiry.
- The root is offline, in hardware, and day-to-day signing happens under intermediate certificates that can be replaced.
- You can see everything: every certificate, where it's used, when it expires, and when one certificate shows up in two places at once.
What the clouds give you today
AWS IoT Core expects you to register your own certificate authority, or to use AWS Private CA, a separate paid service; it then recognizes devices signed by that CA on first connection (AWS IoT provisioning, using your own CA). Renewing certificates on devices is up to you. Azure has Microsoft-managed device certificates in public preview: not recommended for production yet, and only together with IoT Hub, Azure Device Registry and the Device Provisioning Service (overview, status).
How Polythings will do it
A certificate authority as a building block of its own, planned for the platform's first release:
- Three ways to own it: we run it; we run issuing CAs under your own root, so your devices stay chained to you even if you leave; or you keep your existing CA and we track and renew through it.
- At the factory: a small station on the production line signs each device as it's tested, with a quota per batch, and keeps working when the factory's internet drops. Secure elements that arrive pre-provisioned from Microchip, NXP or Infineon are imported from the vendor's manifest.
- In the field: our open-source device SDK and agent renew certificates automatically. Decommissioning a device revokes its certificate.
- Alarms for what goes wrong: certificates about to expire, weak keys, and a cloned device seen from two places.
- Beyond devices: gateways, OPC UA application certificates (a familiar pain in plants), and update signing keys under separate roles.
- With other clouds: register a Polythings issuing CA in AWS IoT Core or Azure's provisioning service, and the same certificates work there. You can use the certificate authority without the rest of Polythings.
Because certificates are short-lived and renewed automatically, changing algorithms later, for example to post-quantum signatures, becomes a renewal rather than a recall.
This is planned, not shipped. The roadmap shows when; the platform page has the details.