Trusted IoT depends on identity, certificates, and chain of custody

At a glance

What this is: This is a digital trust analysis arguing that trusted IoT requires identity, mutual authentication, and certificate-based chain-of-custody controls across devices, services, and data flows.

Why it matters: It matters because IoT, OT, and multi-cloud environments fail when identity and trust are treated separately, leaving IAM, NHI, and device governance teams to close the same gap from different angles.

By the numbers:

• In OT environments, 74% of security leaders estimate that a prevent-first strategy will fail.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes, and as quickly as 9 minutes in some cases.

👉 Read DigiCert’s analysis of trusted IoT, identity, and digital trust

Context

Trusted IoT is the discipline of proving that devices, services, and data are authentic before they are allowed to influence operations. The article’s central point is that identity and trust must be embedded across the device-to-cloud path, because security controls that focus only on data at rest, in process, or in transit miss the operational reality of connected systems.

That matters for identity programmes because IoT and OT environments extend non-human identity beyond accounts and secrets into certificates, device onboarding, mutual authentication, and lifecycle management. When the trust boundary spans factory, field, edge, and multi-cloud, IAM, NHI governance, and PKI planning become one continuous control problem rather than separate teams with separate assumptions.

Key questions

Q: How should security teams govern trust for IoT devices across edge and cloud environments?

A: Treat every device as a governed identity with an owner, a certificate lifecycle, and a revocation path. Mutual authentication should be required before any device can influence operations, and trust must extend from onboarding through retirement. In mixed OT and cloud environments, identity assurance is the control that keeps device data and commands reliable.

Q: Why do traditional network controls often fail in OT and IoT environments?

A: They assume frequent patching, stable connectivity, and fast containment, which do not match operational systems. OT devices are often long-lived, distributed, and tied to availability requirements, so perimeter controls alone cannot keep pace. Identity-based verification and managed updates are more effective because they protect the asset itself, not just the network path.

Q: What breaks when certificates are treated as static artefacts instead of managed identities?

A: Rotation, renewal, revocation, and ownership all become unclear, which lets trust outlive the system or person responsible for it. In practice, that creates stale credentials, broken chain-of-custody, and blind spots during incident response. Certificates only work as trust anchors when their lifecycle is governed with the same rigor as the devices they protect.

Q: How do IAM and NHI programmes support trusted IoT operations?

A: They provide the governance model for who or what can authenticate, how identities are issued, and when access must be removed. IoT expands NHI from service accounts into devices and operational systems, so lifecycle discipline, owner assignment, and trust validation have to span the entire connected estate.

Technical breakdown

Digital trust in IoT and OT identity

Digital trust in connected environments means each entity can prove who or what it is before systems rely on its data or commands. In the article’s framing, that includes users, services, and devices, with immutable identities and mutual authentication used to establish operational integrity. For OT, the challenge is harder because many devices are headless, distributed, and expected to operate outside standard enterprise control points. That makes identity assurance a prerequisite for every downstream control, from telemetry to maintenance. Practical implication: treat device identity as an operational dependency, not a certificate exercise.

Practical implication: build device identity requirements into architecture reviews before deployment, not after integration.

Certificate lifecycle management across device, edge, and cloud

Certificates and cryptographic keys are presented as building blocks, not the whole trust model. Their value comes from lifecycle management, meaning issuance, rotation, renewal, revocation, and attestation all have to work across greenfield devices, legacy fleets, and cloud-connected services. The article also highlights that security must be designed from the physical layer to the application layer, which is where many IoT programmes fail: trust is introduced late, after the device is already operational. Practical implication: map certificate ownership and revocation paths before scaling a fleet.

Practical implication: define certificate ownership, renewal, and revocation paths before fleet expansion.

Why prevent-first security fails in OT

The article argues that traditional network-based prevention and detection does not scale in OT systems and cannot keep pace with malware sophistication. That reflects a structural mismatch: operational systems are built for availability, long-lived assets, and mixed IT/OT workflows, while classic controls assume rapid containment and frequent patch cycles. Zero trust in this context is not a slogan. It depends on device-level trust, continuous monitoring, and managed updates that can survive constrained environments. Practical implication: adjust control design to operational resilience, not endpoint-style enforcement.

Practical implication: shift OT security design toward continuous verification and managed update discipline.

Threat narrative

Attacker objective: The attacker seeks to insert false trust into operational systems so that downstream analytics, control actions, or maintenance decisions are made on compromised inputs.

1. Entry occurs when a connected device, service, or supporting supply-chain component is onboarded without a trustworthy identity or validated chain-of-custody.
2. Escalation follows when an untrusted or weakly authenticated entity can communicate with services, telemetry platforms, or management workflows as if it were legitimate.
3. Impact emerges when compromised device trust undermines operational integrity, leading to faulty analytics, maintenance errors, disrupted services, or tampered supply-chain decisions.

Breaches seen in the wild

• Sisense breach — unauthorized GitLab access led to exfiltration of access tokens, API keys and certificates.
• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Trusted IoT is really a chain-of-custody problem, not a device problem. The article’s strongest insight is that identity and trust must survive movement from silicon to transport protocol to application stack. That means the question is not whether a device has a secure element, but whether the trust anchor remains valid when the device starts exchanging data with services, analytics engines, and remote operators. The implication is that device governance cannot be separated from platform governance.

Certificate lifecycle is the control plane for IoT trust. In connected environments, certificates and keys are the operational expression of identity, but only when they are issued, renewed, revoked, and bound to the right entity across the fleet. This is where many programmes weaken: they treat certificates as static artefacts rather than governed identities. The practitioner conclusion is that lifecycle ownership matters as much as initial provisioning.

Zero trust for OT fails when teams assume network controls can compensate for weak identity. The article explicitly says preventive network tooling cannot keep pace with OT reality, which is a governance statement as much as a technical one. That means identity, authenticated communications, and managed updates have to carry more of the burden than perimeter-based assumptions ever did. The implication is that security architecture must move from boundary defence to identity-first operational assurance.

Cross-domain identity governance is now unavoidable across users, services, and devices. IoT programmes expose the same governance blind spot seen in broader NHI work: once systems depend on machine identities, the organisation needs one model for ownership, lifecycle, and trust enforcement. The article points toward converged thinking across IAM, NHI, and OT operations rather than siloed controls. Practitioners should expect those domains to be reviewed together, not sequentially.

Operational intelligence depends on trusted inputs, and that changes the security mandate. If analytics, maintenance, and decision engines are built on untrusted or poorly governed data sources, the organisation automates uncertainty instead of reducing it. That is why the trust model has to extend beyond transport encryption into source authenticity and provenance. The practical conclusion is that analytics teams and identity teams have to share accountability for input trust.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to The State of Secrets in AppSec.
• For a broader lens on machine identity governance, see Ultimate Guide to NHIs , The NHI Market for how tooling and lifecycle thinking intersect across non-human estates.

What this signals

Trusted IoT is converging with broader NHI governance. As connected devices, services, and analytics pipelines multiply, the control problem becomes ownership, lifecycle, and revocation rather than just encryption. Teams that already manage secrets and workload identities will recognise the pattern: trust fails when governance stops at issuance. That is why the Ultimate Guide to NHIs , The NHI Market is increasingly relevant to operational environments, not just cloud application teams.

With 27 days as the average estimated time to remediate a leaked secret, the gap is no longer theoretical. In IoT and OT settings, delayed remediation means trust can persist long after a credential or certificate should have been replaced, which is why lifecycle control has to be built into operations rather than handled as a periodic clean-up activity.

Chain-of-custody trust debt: once analytics, maintenance, and remote management depend on connected identities, every missed revocation becomes operational debt. Security leaders should expect identity reviews to expand beyond human accounts into devices, certificates, and service identities that support physical systems.

For practitioners

• Inventory all device and service identities Map users, services, devices, certificates, and keys to a single ownership register so every connected entity has an accountable controller, renewal path, and revocation path.
• Bind trust to the full device lifecycle Require onboarding, update, renewal, and decommission steps for every connected asset, including field devices and brownfield deployments that may operate in constrained or air-gapped conditions.
• Move OT security toward identity-first verification Use mutual authentication, managed certificate lifecycles, and continuous trust checks so OT systems do not depend on perimeter controls that cannot scale with operational complexity.
• Separate analytics confidence from data trust Validate data provenance and chain-of-custody before feeding operational intelligence, because predictive maintenance and condition monitoring fail when inputs are only assumed to be authentic.

Key takeaways

• Trusted IoT depends on identity proof, mutual authentication, and governed chain-of-custody across devices, services, and data flows.
• Traditional prevent-first security is a poor fit for OT because operational systems need identity-first assurance and lifecycle control.
• Practitioners should manage device certificates, ownership, and revocation as core security operations, not as plumbing.

Key terms

• Digital Trust: Digital trust is the assurance that a device, service, or data source is authentic enough to be relied on in operations. In connected environments it depends on identity, mutual authentication, and lifecycle control, not on encryption alone or a secure component inside the device.
• Chain of Custody: Chain of custody is the evidence trail showing where identity, data, or trust material came from and how it changed over time. For IoT and OT, it includes onboarding, certificate handling, updates, and revocation so organisations can prove that operational inputs remained trustworthy.
• Machine Identity: Machine identity is the set of credentials, certificates, and trust bindings that lets a non-human entity prove who or what it is. In IoT and OT, it must be governed across device, edge, and cloud layers so identity remains valid throughout the asset lifecycle.
• 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.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by DigiCert: The Road Ahead for a Trusted IoT. Read the original.