Connected devices with real identities, and data you can actually use.
A fleet that can't prove which device is which ends up as a security finding. We build IoT platforms where every device, gateway and edge node has an identity you issue, rotate and revoke, and where the data lands somewhere your analysts can use.
iot / device identity, edge to cloudcerts rotating
IEC 62443zones & conduitsmTLS
in short·20-second read
IoT work is about connecting physical devices to cloud platforms in a way you can trust, so they can be provisioned, watched and updated.
Cohash designs these platforms on AWS IoT Core and Azure IoT Hub, including device certificates and provisioning. We secure industrial OT networks against IEC 62443 and build edge deployments too. The thread through it is identity. A device gets the same discipline our identity practice gives a person or a workload.
From the first call to a setup your own team can run.
Here's what usually prompts a call about your Internet of Things, what we do about it and in which order, and where you end up.
01 · where it hurts02 · what we change03 · where you end up
incident board · internet of things3 open
openAsk which field devices share a credential, or who would revoke one, and nobody knows.
recurringDevice certificates were issued years ago and nobody owns their renewal.
blockedTelemetry reaches the cloud but sits in raw storage that analysts don't touch.
exposure
IoT platform design and migrationDevice identity and certificate…Smart device security and…Industrial IoT and OT securityEdge computingDevice data engineering
ready to hand over
Leadership chooses from a costed plan per device line that includes the firmware work.
Analysts get plant data in Databricks.
chapter 01 · where it hurts
Why teams reach out
Ask which field devices share a credential, or who would revoke one, and nobody knows.
Device certificates were issued years ago and nobody owns their renewal.
Telemetry reaches the cloud but sits in raw storage that analysts don't touch.
chapter 02 · what we change
How we solve it
IoT platform design and migration
Device identity and certificate lifecycle
Smart device security and compliance
Industrial IoT and OT security
Edge computing
Device data engineering
chapter 03 · where you end up
What changes
Leadership chooses from a costed plan per device line that includes the firmware work.
Analysts get plant data in Databricks.
what we do
Where we spend the hours
6 areas of work, each one done by an engineer who has run it in production.
Device registry, messaging, provisioning and data routing on AWS IoT Core or Azure IoT Hub. We also plan moves off retiring services like Azure IoT Central.
Each device gets an X.509 certificate at manufacture or first connection. It renews on a schedule and gets revoked if the device is lost or resold. We hook the device PKI into the secrets and certificate tooling you already run.
Firmware update paths, vulnerability handling and default-credential removal, mapped to ETSI EN 303 645, the UK PSTI regime and the EU Cyber Resilience Act timelines.
Zones and conduits, target security levels and remote access for plant networks, designed against the ISA/IEC 62443 series and NIST SP 800-82 Rev. 3.
Workloads that run near the equipment on AWS IoT Greengrass, Azure IoT Edge or Arc-enabled Kubernetes, with deployments, updates and identities managed centrally.
Telemetry goes into Databricks, Snowflake or Microsoft Fabric through pipelines we build. We model it so maintenance and operations teams can query it without a data engineer in the room.
capability 01 / 06in production
IoT platform design and migration
Device registry, messaging, provisioning and data routing on AWS IoT Core or Azure IoT Hub. We also plan moves off retiring services like Azure IoT Central.
Each device gets an X.509 certificate at manufacture or first connection. It renews on a schedule and gets revoked if the device is lost or resold. We hook the device PKI into the secrets and certificate tooling you already run.
Firmware update paths, vulnerability handling and default-credential removal, mapped to ETSI EN 303 645, the UK PSTI regime and the EU Cyber Resilience Act timelines.
Workloads that run near the equipment on AWS IoT Greengrass, Azure IoT Edge or Arc-enabled Kubernetes, with deployments, updates and identities managed centrally.
Telemetry goes into Databricks, Snowflake or Microsoft Fabric through pipelines we build. We model it so maintenance and operations teams can query it without a data engineer in the room.
We pieced these together from Internet of Things situations that come up a lot. They're patterns. You won't find a specific client in them.
case file 01
Two connected-product lines after an acquisition, on AWS and IoT Central
composite · not a client story
Beforethe situation
An acquisition left two connected-product lines, one on AWS IoT Core and the other on Azure IoT Central. Microsoft's notice retires IoT Central on 20 September 2029, and the two teams use different certificate authorities and data pipelines.
What we dothe work
We inventory both fleets by device model, firmware version and credential type. Then we compare consolidating on AWS IoT Core with moving the second line to Azure IoT Hub and Device Provisioning Service, including how each device would receive a new credential. Data paths are mapped to one warehouse either way.
Afterwhere you end up
Leadership chooses from a costed plan per device line that includes the firmware work. Device data lands in one place, whichever cloud carries the messages.
case file 02
Plant data that IT wants in the cloud and OT won't connect
composite · not a client story
Beforethe situation
The analytics team wants historian data from several plants landing in Databricks. Those plants run older PLCs on flat networks, and since an earlier incident the plant teams have said no to any direct cloud connection.
What we dothe work
We map each plant into zones and conduits and put a read-only gateway in the DMZ in front of the historian. Data goes out through one conduit. The gateway's certificates come from central issuance and rotate on schedule. Nothing inbound is opened to the control network.
Afterwhere you end up
Analysts get plant data in Databricks. Each plant keeps one documented outbound path that it can watch and shut off.
How devices, cloud and data connect in an IoT estate
Devices, gateways and plant systems connect to an IoT platform using certificates issued from your PKI. The platform routes telemetry to your data platform, and vendor access to plant equipment goes through a PAM broker.
01 · Field
Devices and productssensors · cameras · appliances → IoT platform · MQTT over TLS
Put these to anyone bidding on your Internet of Things work. The ones who've done it answer differently from the ones who've read about it.
Q1
How does each device get its first credential, and who is able to issue one?
Provisioning is the hardest decision to change after devices ship. Shared claim certificates and keys baked into firmware need a compromise plan from day one.
Q2
How would you revoke one device without disturbing the rest of the fleet?
Ask what revoking one device involves. If the answer is rotating a shared key or a CA, then one stolen unit is a fleet-wide incident.
Q3
What happens to field devices when a cloud service or edge runtime reaches end of support?
Greengrass V1, IoT Edge 1.5 and IoT Central all have published end dates. Changes on the device side take longest, so a good plan starts from firmware and how many field updates you can actually push.
Q4
How will your OT work avoid touching controllers while production runs?
Active scanning and untested changes can stop a line. Ask for passive discovery, change windows the plant picks and a rollback for every step.
Q5
Where will device data land, and who owns it once it gets there?
Telemetry dumped in a storage bucket without a model or owner goes unused. The data path should end in a governed table someone is accountable for.
01Do you build hardware or write firmware?
We don't design hardware. We work with your device makers and firmware teams on the parts that touch the platform: the provisioning flow, certificate storage, the update agent and the cloud connection.
02AWS IoT or Azure IoT, which should we pick?
Usually the cloud you already run on, because identity, networking and data tooling carry over. We look harder when you have a large Microsoft OT estate, a heavy edge Kubernetes plan, or devices already shipping with credentials tied to one provider's CA.
03How does IoT connect to your identity practice?
Treat a device certificate the way you'd treat a service account or an API key. Somebody owns it, there's a policy for issuing it, it rotates, and it can be revoked. We govern devices and workloads the same way, often with the same tools.
04What drives the cost of an IoT engagement?
Mostly the number of device types, how they get credentials today, and how many systems the data has to reach. A fleet of one device model on one cloud is a very different job from a mixed estate of plant controllers, gateways and consumer products.
05Can you work with devices that are already in the field?
Yes. Fleets already deployed are a common starting point. We work out what can be changed over the air, what needs a site visit or a truck roll, and plan any credential or platform migration around both.
related
Often paired with
Projects on Internet of Things usually end up touching one of these, so they're worth a look.
