Industrial device identity needs lifecycle governance, not point fixes

At a glance

What this is: This is a digital trust analysis arguing that OT and IoT security depends on device lifecycle management, certificate governance, and standards-based interoperability across heterogeneous fleets.

Why it matters: It matters to IAM practitioners because device identities and certificates create the same governance pressure as human and workload identities, with higher operational cost and longer persistence windows.

By the numbers:

• The recurring cost of certificates can protect millions of devices over their estimated service lifetime of five to 30+ years.
• 12 to 18 months
• Device lifetimes can reach 15 to 30 years in OT, compared with three to five years for IT equipment.

👉 Read DigiCert's analysis of device lifecycle management and digital trust in OT

Context

Industrial device identity is the problem of proving what a device is, keeping that identity trustworthy over time, and doing so without breaking operations. In OT and IoT estates, the issue is not only authentication at onboarding but also the lifecycle of keys, certificates, and update trust across equipment that may remain in service for decades.

That is why the article frames device lifecycle management as the centre of gravity. The governance challenge extends beyond security engineering into procurement, operations, and manufacturing, where identification, certificate handling, remote maintenance, and provenance all need to line up across heterogeneous devices and mixed IT/OT environments.

For IAM and NHI teams, this is a lifecycle story rather than a one-time hardening exercise. The same operational logic that applies to service accounts and workload identities applies here: if identity cannot be governed through its full life, trust becomes an ongoing liability.

Key questions

Q: How should security teams govern device identities across long OT lifecycles?

A: Security teams should manage device identities as lifecycle assets, not as one-time onboarding events. That means authoritative identification at manufacture or deployment, controlled certificate issuance, defined renewal and revocation paths, and explicit retirement steps. In OT, the lifecycle has to fit production uptime, vendor diversity, and remote maintenance constraints.

Q: Why do OT devices complicate certificate governance more than standard IT assets?

A: OT devices often remain in service for years longer than IT endpoints, yet they still depend on trustworthy keys and certificates for access, updates, and telemetry. That combination creates operational drag, especially where downtime is expensive and environments are heterogeneous. Teams must plan for long-lived trust, not short-lived desktop patterns.

Q: What breaks when device identity is treated like a deployment-only control?

A: When identity ends at deployment, teams lose visibility into renewal, update trust, and retirement. Certificates age out, maintenance channels drift, and devices keep operating on assumptions that no longer match reality. The result is a silent trust gap that only becomes visible when operations fail or an attacker exploits the stale state.

Q: How do you know if industrial identity controls are actually working?

A: You know controls are working when each device can be traced from authoritative issuance through active use to retirement, and when certificate renewal, revocation, and update validation happen without improvised exceptions. If teams cannot prove that chain for a device class, governance is incomplete even if the devices are still online.

Technical breakdown

Device identity, certificates, and the trust chain

OT devices are often headless, long-lived, and deployed in mixed brownfield and greenfield environments, which makes identity more than a login problem. The article’s core point is that certificates and protected keys form the trust chain for device authentication, signed updates, and encrypted communication. That trust chain has to survive manufacturing, onboarding, remote maintenance, and field updates without relying on human interaction at every step. In practice, device identity must be authoritative before onboarding and durable enough to support later provisioning, monitoring, and revocation.

Practical implication: treat device identity as a lifecycle control, not a deployment artifact.

Why PKI is operationally different in OT

The article distinguishes OT from IT by cost, latency, and availability constraints. PKI in OT is harder because the environment may have resource limits, vendor diversity, and update paths that cannot tolerate disruption. The result is that certificate issuance, storage, rotation, and revocation are not abstract security tasks but production dependencies. If certificates are expensive to manage or difficult to embed into device workflows, teams tend to fall back to weaker patterns such as shared passwords or ad hoc remote access, which undermines the trust model the certificates were meant to create.

Practical implication: design certificate operations around uptime and device constraints, not enterprise IT assumptions.

Secure updates and provenance in heterogeneous fleets

The article ties device intelligence to secure updates and provenance because operational trust depends on knowing where a device came from and whether its software path has been tampered with. In OT, updates may need to be staged, scheduled, and validated differently across device families, and backward compatibility often matters more than speed. Supply chain provenance, tamper resistance, and secure update workflows become part of the identity problem because they determine whether the device still deserves trust after it leaves the factory.

Practical implication: require provenance and update assurance as part of device identity governance.

Threat narrative

Attacker objective: The attacker seeks to undermine device trust so they can manipulate updates, persistence, or remote access across industrial systems.

1. Entry occurs when devices are shipped or deployed without strong authoritative identity, leaving factory defaults, weak remote access patterns, or inconsistent onboarding paths in place.
2. Escalation follows when protected keys, certificates, or update channels are not managed consistently across the fleet, allowing insecure maintenance or compromised trust chains to persist.
3. Impact is operational compromise of device trust, update integrity, or remote maintenance access across heterogeneous OT and IoT environments.

Breaches seen in the wild

• Sisense breach — unauthorized GitLab access led to exfiltration of access tokens, API keys and certificates.
• Schneider Electric credentials breach — exposed credentials gave attackers access to Schneider Electric Jira, exfiltrating 40GB.

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

NHI Mgmt Group analysis

Device identity lifecycle is the control plane for OT trust: In industrial environments, the question is not whether a device can authenticate once, but whether its identity remains authoritative through years of maintenance, updates, and ownership change. That makes lifecycle governance the primary control plane, not a side task attached to PKI. Practitioners should treat onboarding, renewal, update integrity, and retirement as one continuous trust process.

Certificate sprawl becomes operational debt when device lifetimes outlast governance cycles: OT devices can remain in service for 15 to 30 years, while many identity programmes still operate on human-time assumptions. That mismatch creates certificate and key debt that accumulates long before an incident exposes it. The implication is that device trust can no longer be measured by deployment success alone.

Industrial identity exposes the same lifecycle weakness seen in NHI programmes: Device credentials are non-human identities in practice, and they fail in familiar ways when rotation, visibility, and offboarding are not built into the operating model. The difference is that OT failures often remain hidden until the device is needed for production, remote maintenance, or update validation. Practitioners should align device identity governance with the same discipline used for other long-lived NHIs.

Standards-based interoperability is now a governance requirement, not just an engineering preference: The article shows that mixed device estates cannot rely on one-off security retrofits. Interoperability across OEMs, field devices, and update paths is what makes lifecycle governance sustainable at scale. The implication is that teams need a policy model that can survive vendor diversity and long service life.

Protected keys and trusted workflows are the minimum viable trust model for industrial systems: When devices cannot tolerate interactive human controls, the trust boundary shifts to the cryptographic artefacts that represent them. That means the governance question is whether keys, certificates, and device provenance are controlled tightly enough to support secure operations over the full device life. Practitioners should evaluate OT trust as a lifecycle assurance problem, not a point-in-time security check.

From our research:

• The recurring cost of certificates can protect millions of devices over their estimated service lifetime of five to 30+ years, according to The State of Non-Human Identity Security.
• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared with nearly 1 in 4 for securing human identities.
• That confidence gap is a reason to align device lifecycle governance with NHI Lifecycle Management Guide before scale makes exceptions permanent.

What this signals

Device identity governance will increasingly converge with NHI lifecycle management: The operational problems in OT are the same ones that appear in workload and service-account estates, just stretched over longer asset lives and harsher uptime constraints. Teams that already struggle with certificate renewal and offboarding in NHI programmes should expect the same failure modes to reappear in industrial environments unless lifecycle ownership is explicit.

The practical signal is that certificate and key management can no longer be handled as a tooling issue alone. If the estate includes thousands or millions of devices, lifecycle automation, provenance checks, and ownership clarity become board-level resilience issues rather than backend tasks.

Industrial trust models will also need to align more closely with standards such as the NIST Cybersecurity Framework 2.0 as organisations try to connect device assurance, operational continuity, and governance evidence in one programme.

For practitioners

• Map every device identity lifecycle stage Document how devices are identified at manufacture, onboarded, maintained, updated, and retired. Use the map to find where ownership changes, manual workarounds, or shared credentials break trust.
• Standardise certificate handling for long-lived devices Define issuance, renewal, revocation, and storage rules that match OT uptime constraints and device longevity. Align those rules to NIST Cybersecurity Framework 2.0 and the NHI Lifecycle Management Guide.
• Require provenance for update workflows Verify that update paths preserve device provenance, integrity, and compatibility across OEMs and field device classes. Tie update approval to a trusted chain rather than a maintenance schedule alone.
• Remove factory-default and shared access patterns Replace default passwords and ad hoc remote access with device-unique credentials and protected key storage wherever the platform allows. Where it does not, treat the exception as a risk acceptance item, not an implicit control.

Key takeaways

• OT identity governance fails when device trust is treated as a deployment step instead of a full lifecycle.
• Long device lifetimes, expensive certificate operations, and heterogeneous fleets turn weak governance into lasting operational debt.
• Practitioners should manage device identity, provenance, and update trust as one continuous control problem across the device life.

Key terms

• Device Identity Lifecycle: The controlled sequence that begins when a device is issued an identity and ends when that identity is revoked or retired. In OT, the lifecycle must cover onboarding, maintenance, update validation, and decommissioning because devices often remain in service far longer than the systems that manage them.
• Protected Key: A protected key is a cryptographic key stored so it cannot be casually copied or extracted from the device. In industrial environments, protected keys support authentication, signed updates, and trusted communication, making key storage a governance issue as much as a technical one.
• Device Provenance: Device provenance is the evidence chain showing where a device came from, how it was built, and whether its trust state has been altered. For OT and IoT fleets, provenance helps determine whether the device should still be trusted after manufacturing, shipment, field servicing, or software updates.

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 responsible for identity security strategy or operational governance, it is worth exploring.

This post draws on content published by DigiCert: How Technology is Transforming Industries in the Digital Era. Read the original.