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.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on DigiCert's blog post: Trusted IoT depends on identity, certificates, and chain-of-custody controls, not cryptography alone.
Why it matters: It matters because IAM, NHI, and device-security programmes all need a trust model that spans users, services, and connected devices across OT and cloud environments.
Context
Trusted IoT is a governance problem as much as a technical one: the system only becomes trustworthy when identities, certificates, and provenance are controlled from the device outward. The article frames digital trust as the foundation for connecting users, services, and devices across operational and cloud environments.
That matters because IoT environments often combine IT-operated user devices with OT-operated headless devices, where traditional network-first security does not scale well. In this model, the question is not whether cryptography exists, but whether certificate lifecycle, identity binding, and data custody remain intact from manufacture through runtime.
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. Assign a clear owner for provisioning, separate partner support from customer administration, and require auditable approval for any access that can alter device state or credentials.
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. Trust in IoT depends on the identity, the device context, and the handling of the data together.
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. The result is operational uncertainty, because encrypted transport does not compensate for untrusted origin, tampered telemetry, or weak provenance controls.
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.
Technical breakdown
Why mutual authentication is the trust anchor for connected devices
Mutual authentication means both ends of a connection prove identity before data flows. In IoT, that identity layer has to cover users, services, and devices because a device may be headless, remotely managed, and continuously connected to cloud services. Certificates and keys are the mechanisms, but the real control is whether the identity presented at runtime is the same identity that was onboarded, managed, and authorised for that specific operational role.
Practical implication: Treat device authentication as an identity governance problem, not just a transport-layer control.
How chain of custody affects data-driven decisions
Chain of custody is the trust path that shows where data came from, how it moved, and whether it remained reliable enough to support operational decisions. The article ties this to analytics, predictive maintenance, and condition monitoring, where data quality affects the confidence of downstream automation. If provenance is weak, the system may still function, but its decisions become probabilistic in a way that undermines operational integrity.
Practical implication: Verify data provenance for IoT telemetry before using it in analytics, maintenance, or control workflows.
Why certificate lifecycle is central to IoT trust
Certificate lifecycle management covers issuance, renewal, replacement, and revocation for device and service identities. In distributed IoT and IIoT environments, certificates are not static badges but living credentials that must track manufacturing, onboarding, updates, and field operations. The article’s point is that trust fails when lifecycle control stops at issuance and does not extend through the device’s operational life.
Practical implication: Build lifecycle controls for operational certificates into onboarding, update, and offboarding processes.
Threat narrative
Attacker objective: The objective is to manipulate or exploit the trust chain so that operational systems accept untrusted devices, identities, or data as legitimate.
- Entry occurs when a device, service, or user is connected without strong identity binding or verified provenance. That leaves the runtime path dependent on trust assumptions rather than explicit authentication.
- Credential or certificate abuse follows when long-lived or weakly governed identities are reused across device-to-cloud interactions. The attacker or failure state benefits from credentials that outlive the trust relationship they were meant to represent.
- Impact appears as compromised operational integrity, because analytics, monitoring, or control decisions are made on data that cannot be trusted end to end. In OT and IoT environments, that can affect maintenance, supply chain actions, and remote operations.
Breaches seen in the wild
- GitHub code signing certificate theft 2022: A machine account's compromised token cloned GitHub's Desktop and Atom repos, exposing encrypted signing certificates later revoked.
- Dropbox Sign breach 2024: A compromised back-end service account gave attackers Dropbox Sign customer data, including API keys, OAuth tokens and MFA information.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group 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.
Chain of custody is the missing trust boundary in many IoT programmes: data can be encrypted and still be operationally unreliable if provenance is weak. The article correctly ties analytics and predictive maintenance to source integrity, because decision engines only work when the system can explain where the data came from and how it was handled. That makes provenance a governance control, not a reporting nicety.
Certificate lifecycle is the real control surface, not certificate presence: having certificates in place does not mean trust is governed. The article’s industry examples show that onboarding, updates, field devices, and air-gapped environments all depend on lifecycle discipline, especially where identity is embedded in physical assets. Practitioners should measure whether certificates remain aligned to the device’s actual operational state.
Zero trust in IoT fails if it stops at the network layer: the article makes clear that connected entities must be trusted explicitly across identity, authentication, and data protection. That aligns with a broader industry pattern where OT and cloud convergence breaks old perimeter assumptions. The practical conclusion is that identity governance has to span device operations, service access, and data flow together.
Operational intelligence depends on trusted identities, not just trusted infrastructure: the article links digital trust to real-time monitoring, remote management, and condition-based maintenance. That means the identity problem is upstream of the analytics problem. If the device identity, service identity, or data source identity is weak, the downstream intelligence stack inherits uncertainty by design.
What this signals
Chain-of-custody governance will matter more as IoT expands into analytics: once connected devices feed predictive maintenance and operational intelligence, identity assurance extends beyond authentication to include source integrity and data lineage. Practitioners should expect trust failures to show up first as bad decisions, not obvious access events.
The operational boundary between IT and OT is also an identity boundary. Programmes that assume user-style controls can govern headless devices will miss the lifecycle, ownership, and revocation gaps that define IoT risk in the field.
For practitioners
- 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.
- Separate IT and OT trust requirements Document where enterprise IAM patterns stop working for headless or autonomous field devices and define the controls needed for OT-managed identities.
Key takeaways
- Trusted IoT depends on identity continuity across devices, services, and data sources, not on cryptography by itself.
- The article shows that analytics and operational intelligence are only as reliable as the chain of custody behind the data.
- Identity teams should govern certificates, device ownership, and provenance as one lifecycle rather than separate controls.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5, NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | IoT device trust depends on strong identity proof and mutual authentication. |
| NHI-07 — Long-Lived Secrets | The article stresses lifecycle management for keys and operational certificates. | |
| Recommendation — Apply NHI-04 controls to ensure devices and services authenticate with approved identity proofing methods. Reduce long-lived credential exposure by enforcing rotation and revocation for device certificates. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Certificate lifecycle management is the core identity control discussed in the article. |
| Recommendation — Use IA-5 to govern issuance, renewal, rotation, and revocation of device authenticators. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Explicit trust for connected entities requires controlled authorisation for devices and services. |
| Recommendation — Align device and service authorisations to PR.AA-05 so access stays tied to approved operational scope. | ||
| CIS Controls v8 | CIS-5 — Account Management | The article's identity lifecycle emphasis maps to governed management of machine and service accounts. |
| Recommendation — Apply CIS-5 to inventory, manage, and remove connected-device accounts across their lifecycle. | ||
Key terms
- Digital Trust: Digital trust is the set of cryptographic and identity controls that allow systems, users, and services to verify each other reliably. It includes PKI, federation, certificates, and authentication foundations that must remain adaptable as technologies and threat conditions change.
- Chain of custody: A documented record that preserves the integrity of evidence from the moment an event is detected through investigation and response. In identity and data protection workflows, it helps prove what happened, when it happened, and which actor or session was involved.
- Mutual Authentication: Mutual authentication is a two-way verification process where each party proves its identity before communication proceeds. In connected operational systems, it prevents devices and services from trusting unauthenticated peers and helps enforce identity-first security across distributed environments.
- Certificate Lifecycle Management: The governance of digital certificates from issuance through renewal and revocation, ensuring certificates are valid, monitored, and rotated before expiry. Expired certificates are a leading cause of outages and unplanned security gaps.
Deepen your knowledge
NHI governance, machine identity security, and identity lifecycle management are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 25, 2026.
Updated on October 8, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org