IoT security maturity still hinges on identity and lifecycle control

At a glance

What this is: This is an analysis of why IoT security has lagged behind adoption, and how regulation, standardisation, PKI, and embedded trust are shaping the next phase of maturity.

Why it matters: It matters because IoT and IIoT devices increasingly sit inside business-critical environments, where weak device identity, poor lifecycle control, and inconsistent offboarding can create enterprise-wide exposure.

By the numbers:

• 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation.
• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.

👉 Read GlobalSign's analysis of IoT security maturity, PKI, and device trust

Context

IoT security fails when device identity, firmware governance, and ownership are treated as separate problems. The article argues that the industry spent years optimising for speed and connectivity while leaving authentication, update discipline, and accountability underdeveloped, which is why insecure devices still become reliable entry points into larger environments.

That pattern has a clear identity dimension. IoT devices, gateways, and sensors behave like non-human identities in operational terms because they need credentials, trust anchors, and lifecycle controls to communicate safely. When those controls are absent, the device layer becomes a governance gap rather than just an endpoint problem, and that is typical of immature IoT programmes.

Key questions

Q: What fails when IoT devices do not have cryptographic identity controls?

A: Without cryptographic identity, devices can be impersonated, cloned, or silently replaced in the network. That breaks trust in onboarding, updates, and remote management because the system cannot distinguish a legitimate device from a counterfeit or compromised one. The result is a scalable access problem, not just a hardware problem.

Q: Why do IoT devices create the same governance problems as non-human identities?

A: IoT devices need credentials, trust anchors, renewal, and revocation just like service accounts or API keys. They also outlive deployment teams and often operate without direct human interaction, which means lifecycle ownership matters more than one-time hardening. When that ownership is missing, stale trust persists.

Q: How should organisations govern IoT devices that are distributed across vendors and resellers?

A: They should assign lifecycle ownership at the operator level, standardise certificate issuance, and require revocation at retirement regardless of who manufactured or resold the device. Shared accountability only works when one party is responsible for the trust relationship end to end.

Q: Who is accountable when an IoT device with stale credentials is used in an attack?

A: The accountable party is the organisation that controls the active trust relationship, not just the hardware supplier. Regulators and auditors will look for ownership of onboarding, update enforcement, and revocation. If those controls are not assigned and documented, the organisation owns the risk.

Technical breakdown

Why device identity is the control plane for IoT security

IoT security depends on proving that a device is genuine before it is allowed to communicate, receive updates, or join a management domain. That requires certificates, PKI, secure elements, or TPM-backed keys, which create a cryptographic trust chain instead of relying on static passwords or permissive network placement. In practice, this turns each device into a managed identity with authenticated relationships to systems, brokers, and update services. Without that layer, counterfeit or compromised devices can impersonate legitimate assets and blend into normal traffic.

Practical implication: treat device identity as a prerequisite for onboarding, update access, and revocation, not as an optional add-on.

How lifecycle governance changes when millions of devices behave like NHIs

Unlike human users, IoT devices often operate for years, communicate automatically, and outlive the teams that deployed them. That creates an identity lifecycle problem: provisioning, renewal, firmware update rights, certificate expiry, decommissioning, and revocation all have to be tracked at machine scale. If ownership is unclear across manufacturers, resellers, and operators, the device may continue to exist after support ends or after its trust anchor should have been withdrawn. This is the same structural issue seen in NHI programmes, where unmanaged credentials persist because no one owns the offboarding step.

Practical implication: define a lifecycle owner for every device class and tie certificate renewal, firmware support, and retirement to that ownership.

Why embedded trust and managed certificates matter for autonomous device behaviour

Embedded trust uses hardware-backed key storage and local attestation to keep device credentials from being copied, extracted, or reused elsewhere. Managed certificate services then allow the trust state to be issued, renewed, and revoked centrally without manual intervention for every device action. This matters because many IoT systems are now too large and too distributed for human approval loops to be viable. The technical shift is away from static trust and toward continuous proof of identity at the edge, which is exactly where many IoT environments still fall short.

Practical implication: prioritise hardware-backed key protection and automated certificate issuance for any device estate that must scale beyond manual administration.

Threat narrative

Attacker objective: The attacker aims to turn insecure IoT devices into scalable infrastructure for disruption, surveillance, or lateral access into higher-value environments.

1. Entry begins with weak default credentials, exposed services, or unmanaged devices that can be discovered and enrolled by attackers.
2. Escalation follows when compromised devices are used as a foothold for botnet activity, traffic manipulation, or access into adjacent enterprise systems.
3. Impact comes through DDoS amplification, operational disruption, false telemetry, or the use of compromised IoT devices as trusted pivot points into critical environments.

NHI Mgmt Group analysis

IoT security maturity is really device identity maturity. The article is strongest when it moves past firmware and instead points to trust anchors, certificates, and revocation as the basis of safe scale. That maps directly to NHI governance because unmanaged devices behave like unmanaged machine identities, and the governance model must follow the trust relationship rather than the hardware category. Practitioners should treat device identity as core security architecture, not infrastructure decoration.

Fragmented accountability is the real control failure in IoT programmes. The article describes a chain in which manufacturers, resellers, and operators each own only part of the problem, which leaves update, offboarding, and recovery responsibilities ambiguous. That is the same failure pattern seen in other NHI environments where no one owns revocation or lifecycle closure. Practitioners should assign explicit lifecycle accountability before scale creates permanent exposure.

PKI and embedded trust are becoming the practical replacement for assumption-based trust. The article’s argument is not that cryptography fixes every IoT risk, but that scalable identity proof is the minimum condition for safe automation. In identity terms, this is a move away from implicit trust and toward continuously verifiable device identity. Practitioners should align IoT onboarding and certificate governance with broader machine identity controls.

AI makes IoT governance more valuable, not less. The article is right to show that anomaly detection can help, but AI also expands the attack surface when telemetry can be manipulated or models can be misled. That means the trustworthiness of data, devices, and decisions must be governed together. Practitioners should treat AI-enabled IoT as a combined identity, data integrity, and monitoring problem.

Smart infrastructure will fail if the industry keeps underestimating lifecycle offboarding. The article focuses on secure build and secure operation, but the harder issue is what happens when devices are abandoned, resold, or left on unsupported firmware. That is a classic machine identity blind spot. Practitioners should make retirement and certificate revocation part of the design baseline, not an afterthought.

What this signals

Device identity governance will matter more as IoT becomes a trust boundary for operational systems. Teams that still treat connected devices as isolated endpoint assets will struggle to prove provenance, revoke trust, or defend against counterfeit enrollment. The practical shift is toward certificate lifecycle management, ownership mapping, and revocation playbooks that can scale across fleets.

Lifecycle closure is the control most IoT programmes underinvest in. The article points toward secure deployment, but the harder operational requirement is retiring devices cleanly when support ends, ownership changes, or firmware becomes untrusted. That is where the organisation’s machine identity model either holds or collapses.

As AI-driven monitoring enters IoT estates, teams will need to validate both the device and the telemetry it produces. That makes identity assurance, data integrity, and detection logic part of the same governance conversation, especially in industrial and healthcare environments.

For practitioners

• Implement device identity as a mandatory onboarding gate Require cryptographic proof of identity, such as certificate-based authentication or hardware-backed keys, before any IoT device joins production networks or management planes.
• Tie certificate renewal to device lifecycle ownership Assign a named owner for every device class and make certificate renewal, firmware update rights, and revocation part of that owner’s control set.
• Automate offboarding and revocation for retired devices Build retirement workflows that revoke credentials, remove trust anchors, and disable update channels as soon as a device is decommissioned or replaced.
• Use hardware-backed trust for high-impact deployments Prioritise TPMs, secure elements, or equivalent hardware-backed key protection for industrial, healthcare, and critical infrastructure devices.
• Map IoT certificate governance to machine identity policy Align device onboarding, renewal, and revocation rules with broader machine identity standards so IoT does not become a separate governance island.

Key takeaways

• IoT insecurity persists because the industry still underestimates device identity, lifecycle ownership, and revocation discipline.
• The scale problem is now operational, because connected devices can affect factories, utilities, healthcare, and enterprise networks at once.
• The control gap that changes the outcome is cryptographic trust tied to automated onboarding, renewal, and offboarding.

Key terms

• Device Identity: Device identity is the cryptographic proof that a connected device is genuine and authorised to communicate. In practice it relies on certificates, keys, or hardware-backed trust so that systems can verify provenance, enforce access, and revoke trust when the device is retired or compromised.
• Machine Identity: Machine identity is the set of credentials and trust relationships used by non-human systems such as devices, services, or workloads. It includes certificates, tokens, keys, and lifecycle controls that allow automated systems to authenticate without human intervention.
• Embedded Trust: Embedded trust is the use of hardware or chip-level protections to store keys and perform local attestation. It reduces the chance that credentials can be extracted, cloned, or reused, which makes large device fleets easier to govern securely.
• Certificate Lifecycle Management: Certificate lifecycle management is the process of issuing, renewing, rotating, and revoking certificates over time. For IoT, it is the mechanism that keeps trust current, prevents stale credentials from persisting, and enables safe device retirement at scale.

What's in the full article

GlobalSign's full blog covers the operational detail this post intentionally leaves for the source:

• How the article frames EU Cyber Resilience Act pressure on device makers and why lifecycle update obligations matter.
• The article's discussion of PKI, certificates, TPMs, and secure elements as the trust foundation for large IoT fleets.
• Its examples of how AI can both improve anomaly detection and expand the attack surface for manipulated telemetry.
• The article's broader argument about standards such as ETSI EN 303 645 and ISO/IEC 27400 in reducing fragmentation.

👉 GlobalSign's full post expands on regulation, embedded trust, and AI's double role in IoT security.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management in a practitioner-focused format. It is designed for security teams that need to govern identities, credentials, and lifecycle controls across modern environments.