Device provisioning that still works at the ten-thousandth unit.
We build IoT platforms on AWS IoT Core and Azure IoT Hub, starting with how a device gets its first credential, because that choice is the hardest to change once units ship.
An IoT platform is the cloud layer that registers devices, authenticates them, carries their messages and routes their data.
Cohash designs and builds these platforms on AWS IoT Core and Azure IoT Hub with Device Provisioning Service. We pick the provisioning model, set up the certificate authority chain, write device policies and routing, and plan migrations off services like Azure IoT Central before their retirement dates.
you probably need this if
Devices ship next quarter and nobody has decided how each unit gets its first certificate.
Every device in the fleet authenticates with the same key or certificate.
A single IoT policy lets any device publish to any topic.
From the first call to a setup your own team can run.
Here's what usually prompts a call about your IoT Platforms, what we do about it and in which order, and where you end up.
01 · where it hurts02 · what we change03 · how it runs04 · where you end up
incident board · iot platforms3 open
openDevices ship next quarter and nobody has decided how each unit gets its first certificate.
recurringEvery device in the fleet authenticates with the same key or certificate.
blockedA single IoT policy lets any device publish to any topic.
exposure
Provisioning model selectionCertificate authority designDevice policies and least…Azure IoT Central migrationMessage routing and data landingFleet operations
startrehearsehandover
Device and credential…
Platform design
Pilot on real hardware
Scale and hand over
we are here
ready to hand over
A leaked claim can't register unknown devices anymore.
No more group keys.
Device and credential inventory with key-storage findings
Platform design covering provisioning, CA chain and policies
chapter 01 · where it hurts
Why teams reach out
Devices ship next quarter and nobody has decided how each unit gets its first certificate.
Every device in the fleet authenticates with the same key or certificate.
A single IoT policy lets any device publish to any topic.
chapter 02 · what we change
How we solve it
Provisioning model selection
Certificate authority design
Device policies and least privilege
Azure IoT Central migration
Message routing and data landing
Fleet operations
chapter 03 · how it runs
Our approach
Device and credential inventory
Platform design
Pilot on real hardware
Scale and hand over
chapter 04 · where you end up
What changes
A leaked claim can't register unknown devices anymore.
No more group keys.
Device and credential inventory with key-storage findings
Platform design covering provisioning, CA chain and policies
what we do
Where we spend the hours
6 areas of work, each one done by an engineer who has run it in production.
On AWS, just-in-time provisioning when devices leave the factory with unique certificates from your registered CA, and fleet provisioning when they can't. On Azure, DPS enrollment groups backed by X.509, TPM or symmetric-key attestation.
Root and intermediate CAs for device certificates, whether that's AWS Private CA, your enterprise PKI, or Azure Device Registry certificate management (in preview at last check). We decide which credential is the durable onboarding identity and which is the short-lived operational one.
A device should only be able to publish to its own topics. Scope the AWS IoT policies and Azure IoT Hub permissions that way and a stolen certificate costs you one device instead of the fleet.
Microsoft has announced Azure IoT Central retires on 20 September 2029 and points customers to IoT Hub, DPS and Azure Device Registry. We inventory your IoT Central apps, device templates and rules, then rebuild them on the recommended services.
Rules and routes that send telemetry to storage, streaming and your data platform, with schemas agreed before the first device ships so downstream tables stay stable.
We set up device shadows or twins and jobs for remote commands, plus over-the-air update pipelines with staged rollout and rollback.
capability 01 / 06in production
Provisioning model selection
On AWS, just-in-time provisioning when devices leave the factory with unique certificates from your registered CA, and fleet provisioning when they can't. On Azure, DPS enrollment groups backed by X.509, TPM or symmetric-key attestation.
Root and intermediate CAs for device certificates, whether that's AWS Private CA, your enterprise PKI, or Azure Device Registry certificate management (in preview at last check). We decide which credential is the durable onboarding identity and which is the short-lived operational one.
A device should only be able to publish to its own topics. Scope the AWS IoT policies and Azure IoT Hub permissions that way and a stolen certificate costs you one device instead of the fleet.
Microsoft has announced Azure IoT Central retires on 20 September 2029 and points customers to IoT Hub, DPS and Azure Device Registry. We inventory your IoT Central apps, device templates and rules, then rebuild them on the recommended services.
Rules and routes that send telemetry to storage, streaming and your data platform, with schemas agreed before the first device ships so downstream tables stay stable.
We pieced these together from IoT Platforms situations that come up a lot. They're patterns. You won't find a specific client in them.
case file 01
One claim certificate baked into every firmware image
composite · not a client story
Beforethe situation
Devices ship with the same AWS IoT fleet provisioning claim certificate in firmware. A researcher pulled it from a unit bought online, and the team learns that deactivating the claim stops new registrations but not devices already provisioned.
What we dothe work
We deactivate the leaked claim, ship a new one by firmware update and add a pre-provisioning hook that checks serial numbers against the manufacturing list. Device policies are narrowed so each thing can use only its own topics. For the next hardware run, unique certificates go on at the factory and register through JITP.
Afterwhere you end up
A leaked claim can't register unknown devices anymore. Each device publishes only to its own topics. The next production run ships without a shared secret.
case file 02
An IoT Central app with tens of thousands of devices on group SAS keys
composite · not a client story
Beforethe situation
A product line runs on Azure IoT Central with device templates, rules and dashboards built by an earlier team. Microsoft's notice gives 20 September 2029 for retirement, and devices connect with group SAS keys through IoT Central's built-in provisioning.
What we dothe work
We map device templates to IoT Hub device twins and Azure Device Registry. A new Device Provisioning Service instance gets X.509 enrollment groups, and a firmware update points devices at it. IoT Central rules become message routes and Fabric pipelines, and devices move in batches while both apps run.
Afterwhere you end up
No more group keys. Devices use certificates to reach IoT Hub, and IoT Central goes dark well before Microsoft's date.
How a device gets its identity and starts sending data
A device presents a manufacturing or claim certificate to AWS IoT fleet provisioning or Azure DPS, which registers it and issues or links its operational identity. After that it talks MQTT to the IoT service, and rules or routes deliver its messages to storage and your data platform.
AWS IoT Core or IoT Hub → Rules and routes: topic messages
Rules and routes → Streaming and storage: telemetry
Streaming and storage → Data platform: ingest
how it runs
A typical engagement
We don't start a step until the last one has produced something you can check.
step 01
Device and credential inventory
List the device models you have and how each one gets its credentials today. Find out where the private keys actually live.
step 02
Platform design
The provisioning model, CA chain, topic and policy structure, routing and monitoring all go on paper. Your device and security teams sign it before we build.
step 03
Pilot on real hardware
A small batch of production-representative devices provisioned, rotated and revoked end of line to cloud before anything scales.
step 04
Scale and hand over
Infrastructure as code for the platform, runbooks for certificate events, and training for the team that will run it.
you keep
What you're left with
We write these for your IoT Platforms setup, and they're working documents. Your team should be able to keep things running from them long after we've gone.
inventory01
Device and credential inventory with key-storage findings
yours to keep
design02
Platform design covering provisioning, CA chain and policies
Some clients want a project team, some want a couple of engineers on theirs. Either works. Onsite, nearshore or offshore, with handovers across time zones that keep things moving.
Put these to anyone bidding on your IoT Platforms work. The ones who've done it answer differently from the ones who've read about it.
Q1
If one device's credential is stolen, what could an attacker do with it?
Policies with wildcard topics let one device read or spoof the whole fleet. Each device should be limited to its own topics and shadow.
Q2
How will you revoke a certificate, and how fast does the platform enforce it?
Revocation on IoT platforms is often manual and per device. Ask for the procedure and test it before you need it.
Q3
Who owns the CA chain, and what happens when the intermediate CA expires?
CA expiry is a fleet-wide outage with a date on it. The renewal plan should exist before the first device ships.
Q4
How will a migration handle devices that can't take a firmware update?
Some units in every fleet are offline, end-of-life or simply out of reach. Ask how the plan covers them instead of assuming everything updates.
Q5
Can you show the provisioning flow working on our actual hardware?
Simulators lie about secure elements, clocks and network stacks. Run the pilot on real devices and you find the problems before the factory does.
01When does Azure IoT Central retire, and what replaces it?
Microsoft's retirement notice, published 29 September 2026, gives 20 September 2029. It recommends Azure IoT Hub, Device Provisioning Service and Azure Device Registry, with Microsoft Fabric for analytics. That's a long runway, but device-side changes take the longest, so we suggest planning now.
02Should devices use certificates or symmetric keys?
Certificates, in nearly every case we see. Symmetric keys are easier to start with but harder to scope and rotate. Where hardware can't handle certificates, we use per-device keys derived from a group key and keep them in a secure element if one exists.
03Can we use our own certificate authority?
Yes. AWS IoT Core fleet provisioning accepts certificates from your own CA, including AWS Private CA or an external PKI. Azure Device Registry can chain an intermediate CA to your external root. We help you pick based on who should own revocation.
04We moved off Google Cloud IoT Core in a hurry. Can you review what we built?
We do. Cloud IoT Core shut down on 16 August 2023, and many replacements were built against that deadline. Tell us which broker or cloud you landed on, and we'll check whether its identity, policy and update model hold up at your fleet size.
05What if our fleet provisioning claim certificate leaks?
Deactivate it in AWS IoT Core. That stops new registrations with it, but devices already provisioned keep their own certificates, so review recent registrations and revoke any you can't match to real units. A pre-provisioning hook that checks serial numbers limits the damage next time.
related
Often paired with
Projects on IoT Platforms usually end up touching one of these, so they're worth a look.
