IoT security maturity in 2026 still depends on identity and trust

At a glance

What this is: GlobalSign argues that IoT security maturity still lags device adoption, and that identity, PKI, and lifecycle governance are now the practical baseline for trustworthy connected systems.

Why it matters: For IAM and security teams, the article underlines that connected devices must be governed as identities with issuance, authentication, rotation, and revocation controls, not left as unmanaged endpoints.

Context

IoT security fails when devices are treated as connectivity assets rather than governed identities. The article frames a familiar but unresolved gap: products ship faster than the controls needed to authenticate them, maintain them, and retire them safely.

That gap matters because IoT now sits inside operational and critical environments, not just consumer spaces. When devices become part of factories, healthcare, energy, and logistics, weak identity assurance and poor lifecycle control become enterprise risk, not product quirks.

Key questions

Q: What breaks when bots and IoT devices are left out of identity governance?

A: When bots and IoT devices are excluded from identity governance, organisations lose visibility into non-human access, approvals, and privilege scope. That creates orphaned accounts, over-permissioned automation, and unmanaged machine-to-machine trust. The result is weaker auditability and a larger attack surface, especially when those identities interact with business-critical systems.

Q: Why does weak IoT device identity create risk in federal and enterprise environments?

A: Weak device identity creates risk because IoT systems are often integrated into larger systems of systems, where trust depends on reliable identification, access control, and data integrity. If devices cannot be uniquely identified or securely authenticated, organisations lose visibility into what is connecting, what it can do, and whether its outputs can be trusted.

Q: What are the signs that xIoT security controls are failing in practice?

A: Common warning signs include widespread password noncompliance, weak device-level hardening, and teams that cannot identify most connected devices. Those symptoms show that discovery and configuration management are incomplete, which leaves the attack surface larger than expected. When visibility is poor, security baselines cannot be enforced consistently and remediation becomes reactive instead of controlled.

Q: How do organisations keep IoT trust visible across large device fleets?

A: Organisations keep IoT trust visible by inventorying all certificate-bearing devices, linking them to owners and systems, and reviewing their lifecycle status regularly. Visibility must include expiry dates, revocation status, and whether the device is still in active service, otherwise the fleet will contain trusted assets nobody can explain.

Technical breakdown

Why device identity is the missing control layer for IoT

IoT security becomes manageable only when each device can prove its identity before it exchanges data or accepts updates. Certificates and PKI give devices cryptographic credentials, while secure hardware such as TPMs or secure elements protect the private keys that make those credentials trustworthy. Without that layer, systems fall back to shared passwords, opaque trust, and manual exceptions that do not scale across large fleets. The real issue is not whether a device can connect, but whether the platform can distinguish a legitimate device from a counterfeit or compromised one.

Practical implication: Treat device identity as a mandatory control plane, not an optional add-on to network onboarding.

How lifecycle governance prevents trust from decaying over time

IoT trust is not static. Devices need secure onboarding, authenticated patch delivery, certificate renewal, and revocation when they are lost, repurposed, or retired. That lifecycle resembles identity governance in enterprise IAM, because trust that cannot be updated or withdrawn eventually becomes stale trust. The article correctly points to the operational weakness: many vendors still ship products without a reliable process for ongoing assurance. If a device cannot be patched or revoked at scale, its identity model is already failing.

Practical implication: Build lifecycle controls for issuance, renewal, and revocation before large-scale deployment.

Why AI can help detect IoT compromise but also expands the attack surface

AI can identify unusual device behaviour faster than human operators, especially in environments with thousands or millions of telemetry signals. But the same article also shows the downside: adversaries can use generative AI to adapt malware, falsify telemetry, or manipulate decision inputs from connected devices. That creates a dual-control problem where detection becomes more dynamic, but trust in the data pipeline becomes harder to validate. For IoT and IIoT environments, AI improves visibility only if the underlying device identity and telemetry integrity are already trustworthy.

Practical implication: Use AI for anomaly detection, but anchor detections to authenticated device identities and trusted telemetry paths.

Threat narrative

Attacker objective: The attacker wants to use compromised IoT devices as scalable infrastructure for disruption, deception, or broader intrusion.

1. Entry occurs through weak passwords, outdated firmware, and hurried manufacturing practices that leave devices exposed at deployment.
2. Credential abuse then lets attackers impersonate legitimate devices or enroll untrusted devices into the environment without reliable cryptographic proof.
3. Escalation happens when compromised devices are used inside botnets or as sources of false telemetry that influence automated systems.
4. Impact appears as DDoS activity, disrupted operations, or corrupted decision-making across connected environments.

NHI Mgmt Group analysis

IoT identity debt is now a governance problem, not a device problem: the industry spent a decade shipping connected products without a durable model for authentication, renewal, and retirement. That leaves organisations with fleets that can communicate but cannot be trusted over time. For identity programmes, the lesson is that device trust must be governed as a lifecycle, not as a one-time onboarding event.

PKI is becoming the practical boundary between connected and trustworthy: the article is right to centre certificates because shared passwords and ad hoc trust do not scale across modern device fleets. Certificates, secure hardware, and revocation processes are the difference between managed identity and permanent exposure. Practitioners should view this as a baseline control set, not an advanced option.

IoT security maturity will be judged by whether organisations can revoke trust at scale: many programmes can enroll devices, but far fewer can remove or replace trust cleanly when firmware ages or a device is compromised. That is the control gap the article exposes. The practitioner priority is to design for issuance, rotation, and revocation before deployment expands.

Identity-bound trust is the new IoT governance concept: the market is moving from connectivity-first design to trust-first design, where the ability to authenticate, update, and retire a device matters more than feature count. This is the same structural shift that made human IAM and NHI governance unavoidable in other domains. Teams that still treat devices as static assets will keep inheriting unmanaged risk.

What this signals

IoT trust controls will be judged by revocation, not just enrollment: many programmes can prove a device identity at onboarding, but far fewer can remove trust cleanly when a device is compromised or retired. That makes lifecycle governance the practical measure of maturity, especially where connected devices sit inside critical operations.

The identity lesson from IoT is now familiar across adjacent domains: if a system can be onboarded but not reliably revoked, it is not truly governed. For security architects, that means trust architecture must be designed for replacement, renewal, and offboarding from the start.

For practitioners

• Define a device identity lifecycle Assign ownership for device issuance, certificate renewal, revocation, and retirement across procurement, security, and operations so trust does not decay after deployment.
• Require cryptographic device authentication Use PKI-backed credentials and secure hardware for onboarding and ongoing verification rather than shared passwords or factory defaults.
• Segment operational IoT from general IT Isolate connected devices by function and risk so a compromised sensor or camera cannot be reused as a foothold into broader systems.
• Instrument telemetry for anomalous device behaviour Baseline normal device communication, update patterns, and command frequency so compromise signals are visible before disruption spreads.

Key takeaways

• IoT security still fails at the same point: devices are connected faster than they are governed, authenticated, and retired.
• The article shows that the real maturity test is whether organisations can manage identity, certificates, and lifecycle controls at fleet scale.
• For practitioners, the priority is to treat connected devices as identities with issuance, renewal, and revocation requirements, not as static hardware.

Key terms

• Device Identity: Device identity is the cryptographic proof that a specific machine is the thing being accessed, independent of its IP address or current network. In fleet governance, it allows policy, audit, and revocation to follow the device across locations and transports.
• pnPKI: The Philippine National Public Key Infrastructure is the government-backed framework for issuing and managing digital certificates used in authentication, encryption, and legally recognised signatures. It relies on asymmetric cryptography, certificate lifecycle controls, and trusted certificate authorities to support high-assurance, non-repudiable transactions in regulated Philippine workflows.
• Certificate Revocation List: A Certificate Revocation List is a signed publication from a certificate authority that lists certificates that are no longer trusted before their natural expiry. It is used by relying systems to confirm current status, and it becomes operationally useful only when the list is reachable, current, and readable by the consuming toolchain.
• IoT Lifecycle Management: IoT lifecycle management is the process of tracking connected devices from acquisition to retirement. It includes onboarding, patching, monitoring, ownership, replacement, and secure decommissioning, all of which determine whether a device remains a controlled asset or becomes a lingering risk.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management in a way that maps directly to device trust and lifecycle control. It helps practitioners connect identity discipline to the broader security programme that connected systems now require.