TL;DR: Trusted IoT depends on explicitly trusted identities, mutual authentication, and data protection across users, services, and devices, according to DigiCert. The core issue is not cryptography alone but whether identity, certificate lifecycle, and chain-of-custody controls hold across the device-to-cloud path.
Editorial analysis by NHI Mgmt Group, based on content published by DigiCert: “The Road Ahead for a Trusted IoT”.
Key questions
Q: How should teams govern IoT device identities across distributors and integrators?
A: Treat each distribution handoff as a lifecycle event that changes who can provision, support, or revoke the device identity.
Q: Why do certificates alone not make IoT trustworthy?
A: Certificates prove possession of a credential, but they do not prove that the data source is reliable, the device state is current, or the chain of custody is intact.
Q: What breaks when chain-of-custody controls are missing in IoT?
A: Analytics and automated maintenance decisions start to rely on data that cannot be verified back to a trusted source.
Practitioner guidance
- Define device trust as a lifecycle control Map onboarding, renewal, replacement, and retirement for devices and services so identity remains valid across the full operational life of the asset.
- Bind certificates to operational identity Require every connected device and service to present an immutable identity that is tied to its approved role, environment, and communication path.
- Validate data provenance before analytics use Check whether telemetry, sensor data, or event streams can be traced back to a trusted source before they feed predictive maintenance or automated decisions.
Bottom line: Trusted IoT depends on identity continuity across devices, services, and data sources, not on cryptography by itself.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
Trusted IoT is really a governance model for identity continuity: the article is not arguing for more cryptography in isolation, but for trust continuity across users, services, devices, and data. That is the important shift for identity teams: the control plane has to follow the asset from manufacture to runtime, not stop at enrolment. Practitioners should treat device trust as a lifecycle issue, not a point-in-time authentication event.
A question worth separating out:
Q: How do OT device controls differ from enterprise IAM controls?
A: OT devices often operate as headless or autonomous assets with long service lives, limited patch windows, and field-based ownership. That means the identity model has to account for manufacturing, deployment, remote management, and decommissioning, not just user-centric authentication flows.
👉 Read our full editorial: Trusted IoT depends on identity, certificates, and chain of custody