IoT security gaps are widening as device populations scale

At a glance

What this is: This is a German-language explainer on IoT growth, use cases, and the need for stronger IoT security controls such as encryption, authentication, and testing.

Why it matters: It matters because IoT fleets behave like distributed identity estates, and IAM, PAM, and certificate governance increasingly determine whether devices can be trusted, rotated, and revoked safely.

By the numbers:

• The number of IoT devices will grow from 9.7 billion in 2020 to more than 29 billion by 2030.
• Only 5.7% of organisations have full visibility into their service accounts.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
• 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation.

👉 Read GlobalSign's guide to IoT security, use cases, and device protection

Context

IoT is the security problem created when physical devices, vehicles, appliances, sensors, and industrial systems become internet-connected and start exchanging data continuously. The article's core point is straightforward: growth is accelerating faster than many organisations' ability to secure device identity, communications, and lifecycle control.

For practitioners, the identity question is not only how to authenticate users to devices, but how to bind each device to a trustworthy certificate, revoke access when hardware changes hands, and prevent unmanaged device credentials from becoming durable attack paths. That is why IoT security belongs in the same governance conversation as non-human identity management, even when the article itself focuses on connected objects rather than classic service accounts.

Key questions

Q: What makes IoT devices difficult to govern like normal endpoints?

A: IoT devices are difficult to govern because they often rely on embedded credentials, fixed certificates, and long-lived trust relationships that are hard to rotate or revoke at scale. They also span operational, physical, and IT environments, so ownership and lifecycle control are often fragmented. The result is a trust estate that behaves more like non-human identity than a standard laptop fleet.

Q: How should organisations secure IoT devices before deploying them at scale?

A: Organisations should treat IoT onboarding like identity onboarding. Assign unique credentials, enforce ownership, require encryption, and block devices that are still on default settings. They should also maintain a live inventory of devices, accounts, and network paths so security teams can track changes across the device lifecycle instead of discovering gaps after deployment.

Q: What do teams get wrong about IoT certificate management?

A: Teams often treat certificates as a deployment step instead of a lifecycle control. That creates durable trust when the real requirement is bounded trust that can be renewed and removed as devices change state. If revocation is slow, unclear, or manual, the certificate becomes an operational liability rather than a security control.

Q: Which controls matter most when IoT devices are retired or replaced?

A: The critical controls are inventory accuracy, certificate revocation, decommissioning validation, and removal of any stored secrets or remote access paths linked to the old device. Retired devices should not retain network trust or authentication authority, because reuse and cloning are common sources of residual access in IoT environments.

Technical breakdown

IoT device identity and certificate trust

IoT security depends on proving that a device is the device it claims to be. In practice, that usually means certificates, keys, and device identities rather than passwords. When fleets scale into the millions, the real control problem becomes provisioning, renewal, and revocation at machine speed. If certificates are static or stored poorly, compromise persists even when the device itself is replaced. The security model is therefore closer to workload identity governance than to traditional endpoint trust.

Practical implication: treat device certificates as lifecycle-bound identities and design for renewal, revocation, and replacement from day one.

Encryption and authentication in connected fleets

Encryption protects telemetry and commands in transit, while authentication limits which systems can send or receive those commands. In IoT environments, these controls are often only as strong as the weakest embedded device or integration point. A fleet can appear secure at the network layer while still allowing spoofed devices, replayed messages, or unauthorised control traffic if authentication is inconsistent across device classes and protocols.

Practical implication: standardise authenticated device onboarding and enforce encrypted communications across every protocol the fleet uses.

Why penetration testing matters for IoT

Penetration testing helps reveal default credentials, exposed management interfaces, weak firmware update paths, and insecure third-party integrations before attackers find them. IoT systems often fail in ways that are invisible from a normal IT control review because devices are distributed, long-lived, and operationally constrained. Testing needs to reflect the whole device lifecycle, not just the network perimeter or a single application.

Practical implication: test device onboarding, remote administration, firmware updates, and decommissioning as separate attack surfaces.

Threat narrative

Attacker objective: The attacker aims to turn trusted connected devices into persistent access points, data sources, or disruption tools inside operational and enterprise environments.

1. Entry occurs when an attacker reaches an exposed IoT management interface, a weak device credential, or an insecure device onboarding path.
2. Escalation follows when the attacker abuses device trust or firmware weaknesses to issue unauthorised commands or move into adjacent systems.
3. Impact is achieved when compromised devices are used for surveillance, service disruption, data theft, or as a foothold into broader operational networks.

NHI Mgmt Group analysis

IoT security is now an identity governance problem, not just a device hardening problem. Connected devices create their own credential estates, and those estates need provisioning, rotation, monitoring, and offboarding discipline. The article correctly points to encryption and authentication, but the deeper issue is whether each device has a bounded trust relationship that can be managed over time. In that sense, IoT governance overlaps directly with non-human identity control, especially where certificates and API-style device access are involved.

Device sprawl creates a trust surface that traditional endpoint thinking misses. An IoT fleet is not a collection of isolated assets. It is a distributed identity fabric with firmware, certificates, telemetry channels, and remote administration paths that all need lifecycle control. That means security teams should not rely on perimeter segmentation alone. They need identity-aware controls for onboarding, renewal, and revocation so the fleet can be reduced quickly when devices are retired, cloned, or compromised.

Certificate-based trust only works when revocation is operationally real. Many IoT programmes treat certificates as a deployment task, not an ongoing governance control. That is where the model fails, because a trusted device identity that cannot be revoked quickly is just a durable compromise waiting to happen. The practitioner lesson is to design certificate lifecycle management as an operational control, not a procurement checkbox.

IoT security programmes should be measured by recoverability, not device count. The article emphasises growth, but scale alone does not define risk. What matters is whether organisations can inventory devices, prove which identities are active, and remove trust when devices fall out of policy. Without that, growth turns into unmanaged access, and unmanaged access is what attackers exploit. The field should start treating IoT identity as a core governance domain rather than a niche embedded-systems issue.

What this signals

Device identity will become a board-level governance issue as IoT deployments keep expanding. The practical challenge is not whether organisations can connect more devices, but whether they can prove which devices are trusted, which are stale, and which have lost policy alignment. That mirrors the broader non-human identity problem, where unmanaged credentials quietly outlive the systems they were meant to protect.

IoT programmes should be measured by revocation speed and trust recovery, not only by asset coverage. If a device identity cannot be withdrawn quickly, the security model is already weak. Practitioners should connect certificate lifecycle controls to their broader identity programme and align device governance with zero trust expectations, including the controls described in NIST SP 800-53 Rev 5 Security and Privacy Controls and the NIST Zero Trust model.

For practitioners

• Build a device identity inventory Create a live inventory of every connected device, certificate, and remote access path so you can see which identities are active, stale, or duplicated. Tie ownership to a business system and include firmware version, onboarding date, and revocation status.
• Enforce certificate lifecycle controls Automate certificate issuance, renewal, and revocation for IoT devices, and require short-lived trust where the platform allows it. If a device cannot be revoked quickly, treat that as a control gap rather than a technical limitation.
• Separate operational and management channels Keep telemetry flows, administrative access, and firmware update paths distinct so compromise of one channel does not expose the others. Apply strong authentication to device management interfaces and restrict them to known administrative sources.
• Test the full device lifecycle Include onboarding, remote administration, update delivery, and decommissioning in penetration tests and red-team exercises. Many IoT failures occur when a device is retired, reset, or reused but its trust state is not fully withdrawn.

Key takeaways

• IoT growth turns device identity into a governance problem, because each connected object carries trust that must be issued, monitored, and withdrawn.
• The article's security advice is directionally correct, but the operational challenge is lifecycle control across certificates, access paths, and device retirement.
• Practitioners should treat IoT fleets as non-human identity estates and measure success by revocation speed, inventory accuracy, and bounded trust.

Key terms

• IoT Device Identity: A device identity is the unique security profile that lets an IoT asset prove what it is before it participates in a service chain. It supports authentication, authorization, and traceability, and it should be governed through lifecycle controls so the identity can be issued, scoped, and revoked when the device changes state.
• Certificate Lifecycle Management: The process of issuing, renewing, rotating, and revoking device certificates in a controlled way. For IoT, this matters because certificates often stand in for the device's identity and access authority, so weak lifecycle handling can leave retired or compromised devices trusted long after they should be removed.
• Device Fleet Trust Surface: The total set of trust relationships created by a population of connected devices, including identities, management channels, update paths, and integrations. It is a useful way to think about IoT risk because the attack surface grows as trust relationships multiply, not just as hardware counts rise.

What's in the full article

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

• The article's full list of IoT application areas across homes, cities, vehicles, healthcare, agriculture, retail, and industrial systems.
• The vendor's explanation of IoT fundamentals and history, including how connected devices collect and exchange data.
• The specific security measures the article recommends for connected devices, including encryption, authentication, and penetration testing.
• The vendor's framing of IoT certificates and related services for protecting connected objects and data.

👉 GlobalSign's full article covers IoT examples, security measures, and device protection context in more detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, secrets management, and identity lifecycle control. It helps practitioners connect device trust, revocation, and access governance to the wider security programme.