IoT security maturity in 2026 still depends on identity and trust

At a glance

What this is: This analysis argues that IoT security is still immature because connectivity has outpaced identity, lifecycle, and trust controls, even as regulation and standardisation begin to tighten requirements.

Why it matters: It matters because IoT devices are now part of critical business and operational systems, so IAM, PAM, and NHI teams need to govern device identity, credential trust, and revocation as core security controls.

👉 Read GlobalSign's analysis of why IoT security maturity still depends on identity and trust

Context

IoT security fails when organisations treat connected devices as simple endpoints instead of identities with lifecycles, credentials, and revocation requirements. The article’s core point is that the trust problem is not just technical debt, it is governance debt: devices are deployed faster than they are authenticated, rotated, or retired.

That creates a direct identity security intersection. As IoT expands into factories, healthcare, and infrastructure, certificate-based trust, device authentication, and managed lifecycle controls become part of the same governance conversation that IAM and NHI teams already manage for service accounts, tokens, and workload identities.

Key questions

Q: How should organisations govern IoT device identities at scale?

A: Treat each device as a revocable identity with an owner, lifecycle state, and cryptographic credential. Use certificates or hardware-backed keys, track issuance and rotation, and require offboarding when a device is retired. The goal is to make authentication and revocation routine, not exceptional, so a compromised device can be isolated without reworking the whole environment.

Q: Why do insecure IoT devices create broader enterprise risk?

A: Because once connected devices are inside a trusted environment, they can be used as entry points, persistence platforms, or sources of false data. Weak passwords, poor patching, and unclear ownership turn a single device into a systemic exposure. The risk is amplified when devices support operational systems, where disruption can affect revenue, safety, or service continuity.

Q: What do teams get wrong about IoT security maturity?

A: They often confuse connectivity with control. A device that is online, monitored, or centrally visible is not necessarily governed if its credentials cannot be rotated, its firmware cannot be patched, or its identity cannot be revoked. Mature IoT security is defined by lifecycle enforcement, not by device count or dashboard coverage.

Q: Who is accountable when an insecure IoT device causes an incident?

A: Accountability should be shared across procurement, security, operations, and the vendor, but it must be defined before deployment. If ownership is vague, security gaps persist because no one is responsible for patch support, revocation, or retirement. Governance frameworks should make device identity and lifecycle control explicit procurement requirements.

Technical breakdown

Why IoT device identity is the real trust layer

IoT devices need cryptographic identity before they can be trusted on a network. Certificates, public key infrastructure, and hardware-backed secrets give each device a verifiable identity, which lets systems authenticate the device, encrypt traffic, and revoke access when a device is compromised or retired. Without that identity layer, the environment relies on network position or static secrets, both of which fail at scale when millions of devices are involved. For security teams, the practical issue is not whether the device can connect, but whether it can be authenticated, scoped, and offboarded cleanly.

Practical implication: inventory device identities and ensure every connected asset has a revocable credential and an owner.

Why firmware lifecycle and patching remain the hard control problem

IoT insecurity often persists because firmware update paths are fragmented, slow, or absent. A device may ship with weak defaults, but the bigger risk is that it remains exposed for years because patching depends on vendor support, field access, and operational downtime. Lifecycle governance matters here: provisioning, update approval, maintenance windows, and end-of-life retirement all affect exposure. In practice, IoT risk is a supply-chain and operations problem as much as a vulnerability problem, because the organisation may never get a reliable chance to remediate once the device is deployed.

Practical implication: tie procurement to patch support, signed updates, and enforced end-of-life retirement dates.

How AI changes IoT detection and attack surfaces

AI can help by identifying abnormal device behaviour, but it also creates new attack surfaces when device telemetry, decision logic, or anomaly models are manipulated. In connected environments, attackers may not need to crash a device if they can alter the data it emits or the model that interprets it. That makes integrity of telemetry and trust in analytics part of the security model. For mature programmes, AI should improve detection without becoming a hidden dependency that the organisation cannot explain or validate.

Practical implication: validate telemetry integrity and define who can change device analytics, models, or alert thresholds.

Threat narrative

Attacker objective: The attacker aims to turn unmanaged connected devices into scalable infrastructure for disruption, access, or deception.

1. Entry begins with weak default credentials, exposed management interfaces, or outdated firmware on connected devices.
2. Escalation follows when those devices are grouped into larger networks, allowing attackers to repurpose them for botnets, lateral access, or false telemetry.
3. Impact appears as DDoS activity, operational disruption, or corrupted data that affects industrial and safety-critical systems.

NHI Mgmt Group analysis

Identity is becoming the missing operating layer for IoT trust. The article correctly frames certificates and PKI as the basis for device confidence, but the deeper point is governance: every connected device is an identity that needs issuance, rotation, revocation, and offboarding. That is familiar territory for IAM and NHI teams, even when the device is not a traditional workload. The organisations that treat IoT as an identity problem will be better positioned to control risk at scale.

IoT maturity will be measured by lifecycle control, not by connectivity alone. The article shows that regulation and standardisation are pushing manufacturers toward secure-by-design behaviour, but buyers still inherit the operational consequences. If devices cannot be patched, authenticated, or retired on schedule, the programme remains exposed regardless of how advanced the front-end product claims to be. Practitioners should judge IoT vendors by lifecycle enforceability, not feature lists.

IoT trust gaps mirror familiar NHI failures in a different form. Weak defaults, unmanaged credentials, and unclear ownership are the same failure patterns that appear in service account sprawl and secrets exposure. The named concept here is connected identity sprawl: devices multiply faster than governance can track them, so visibility and revocation lag behind deployment. Security teams should treat that as an identity governance problem, not a niche device issue.

AI will amplify both IoT detection and IoT deception. The article’s warning is directionally right, but the governance challenge is that AI can only help if device telemetry and model inputs are trustworthy. Once attackers can influence data at scale, anomaly detection becomes noisy and decision automation becomes brittle. Teams need accountability for who can alter analytics pipelines, not just who can access the devices.

Regulation is finally forcing accountability into a market that has relied on shared blame for too long. The article’s emphasis on manufacturer responsibility reflects a broader trend: security outcomes are increasingly being pushed back to the point of design and procurement. That matters for practitioners because buying insecure devices now carries governance risk, not just technical risk. Procurement, legal, and security teams need a common control baseline before deployment.

What this signals

IoT programmes are moving from product selection to identity governance. The practical shift is that buyers now need evidence of certificate issuance, patch support, and revocation workflows before devices enter production, because connectivity without lifecycle control simply creates another unmanaged trust domain.

Connected identity sprawl: this is the point at which devices multiply faster than governance can classify them, leaving security teams unable to track ownership, rotation, or retirement. The control answer is to treat device identities as first-class assets and align them to the same governance discipline used for service accounts and workload credentials.

As device fleets converge with automation and AI-driven monitoring, the line between IoT security and identity security will keep narrowing. Teams that already understand the NHI lifecycle problem will be better prepared to govern certificates, keys, and revocation across both operational and digital estates.

For practitioners

• Define device identity ownership Assign a business owner, technical custodian, and revocation path for every connected device class. Include certificates, hardware-backed keys, and replacement planning so device identity does not become orphaned after deployment.
• Tie procurement to lifecycle controls Require signed firmware, patch support commitments, end-of-life dates, and revocation capabilities in procurement language. If a vendor cannot support secure updates and retirement, the device should not enter the estate.
• Build revocation into onboarding Use certificate issuance and device enrolment workflows that allow quarantine, suspension, and revocation without manual field intervention. That is the difference between a managed fleet and an irrecoverable one.
• Treat telemetry integrity as a control Validate the provenance of device data before it feeds alerting, automation, or operational decisions. Protect analytics pipelines from unauthorised changes and review who can modify thresholds or model inputs.
• Make retirement a security event Retire devices on a defined schedule, not only when they fail. Offboarding should include credential destruction, service deregistration, and removal from monitoring and automation paths.

Key takeaways

• IoT insecurity is no longer just a device problem, it is an identity and lifecycle governance problem.
• The biggest operational gap is not connectivity but the inability to rotate, revoke, and retire device trust cleanly.
• Security teams should use procurement, ownership, and revocation requirements to turn IoT scale into governable risk.

Key terms

• Device Identity: Device identity is the cryptographic proof that a connected asset is the specific thing it claims to be. In practice, this is usually established through certificates, keys, or hardware-backed credentials so the device can be authenticated, tracked, and revoked across its lifecycle.
• Connected Identity Sprawl: Connected identity sprawl is the governance problem that appears when large numbers of devices, sensors, and controllers are deployed faster than security teams can classify, own, and control them. It creates blind spots in authentication, revocation, and offboarding.
• Hardware-backed Trust: Hardware-backed trust means storing or using cryptographic material in a chip or module designed to resist extraction, such as a TPM or secure element. It reduces the chance that a stolen file system, image, or configuration export exposes the device's identity credentials.
• Telemetry Integrity: Telemetry integrity is the assurance that data sent by a device has not been altered, spoofed, or routed through an untrusted path before it reaches monitoring or automation systems. It matters because detection, response, and operational decisions depend on the data being reliable.

What's in the full article

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

• How the article frames the shift from device connectivity to lifecycle accountability.
• The regulatory implications of Cyber Resilience Act style requirements for manufacturers and buyers.
• Why certificates, PKI, and hardware-backed trust are presented as the practical foundation for IoT authentication.
• How AI-driven detection may change IoT monitoring while expanding the integrity risks around telemetry and models.

👉 GlobalSign's full article expands on regulation, certificates, AI, and the operational path to trusted IoT.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It is designed for practitioners who need a consistent control model for identities that outlive individual users.