TL;DR: IoT security remains fragmented because weak passwords, outdated firmware, inconsistent standards, and unclear lifecycle accountability still leave devices exposed, while PKI, certificates, and hardware trust are becoming the foundation for scalable device authentication, secure updates, and revocation, according to GlobalSign. The critical shift is that IoT maturity is now an identity and governance problem, not just a device hardening problem.
At a glance
What this is: GlobalSign says IoT maturity still depends on identity, certificates, and lifecycle governance because fragmented device security leaves authentication and revocation inconsistent.
Why it matters: For IAM and security teams, the issue is that IoT control now looks like identity governance at device scale, with onboarding, trust, patching, and offboarding all tied together.
Context
IoT security is still constrained by a governance gap, not just a technical gap. Devices can be deployed quickly, but identity, update, and decommissioning controls often remain inconsistent across manufacturers, resellers, and operators, which leaves trust fragmented across the lifecycle.
In practical terms, the article treats IoT as a lifecycle-control problem: who issues trust, who can revoke it, and who remains accountable after devices are in the field. That is directly relevant to IAM and NHI governance because devices, certificates, and embedded keys behave like machine identities that must be provisioned, monitored, and retired.
The article's core claim is that IoT maturity is now measured by whether organisations can govern device identity continuously, not by how quickly they connect hardware. That is a typical failure pattern in large deployments, where operational speed outruns control ownership.
Key questions
Q: What breaks when IoT certificates are not lifecycle-managed?
A: When IoT certificates are not lifecycle-managed, devices can keep trusted access long after business ownership, vendor relationships, or security intent has changed. That creates hidden trust debt, weak revocation posture, and a gap between technical validity and governance validity, which is where many device identity failures start.
Q: Why does lifecycle accountability matter so much for IoT security?
A: IoT risk persists because devices remain in the field for years, while ownership is often split across manufacturers, resellers, and operators. If no one owns updates, revocation, and retirement end to end, security becomes inconsistent and incidents are harder to contain. Accountability is the control that turns policy into action.
Q: How do security teams know IoT traffic controls are working?
A: They should be able to show that devices only contact approved destinations, that unexpected DNS behaviour is investigated, and that inter-device communication is limited to explicit operational needs. If routine device chatter hides unreviewed outbound paths, the control is not working.
Q: When should organisations prioritise PKI over blockchain for IoT and industrial systems?
A: Organisations should prioritise PKI when the main requirement is proving device identity, encrypting communications, and enforcing access control across large fleets of connected assets. That matters in IoT and industrial environments where operators need unique identities, certificate lifecycle management, and policy-based trust. Blockchain is not a substitute for authentication, encryption, or identity binding in those scenarios.
Technical breakdown
Why device identity is the control plane for IoT trust
IoT devices cannot be trusted solely because they are present on a network. They need cryptographic identity so that systems can distinguish legitimate devices from cloned, rogue, or tampered ones. PKI gives each device a verifiable identity, while certificates create a trust chain that supports authentication, encrypted communication, and policy enforcement. Without that layer, device trust depends on weak shared secrets or default credentials, which do not scale across fleets. This is why lifecycle governance matters as much as network security: if identity issuance, validation, and revocation are weak, the rest of the security model becomes brittle.
Practical implication: Treat device identity as the primary control surface and require certificate-based authentication for every IoT device class.
How lifecycle control changes IoT security operations
Lifecycle control means security does not stop at provisioning. A device must be enrolled, maintained, updated, and eventually retired in a way that preserves trust at every stage. That requires processes for certificate issuance, key protection, firmware update validation, and revocation when a device is compromised or decommissioned. In IoT environments, lifecycle failures are especially dangerous because devices often stay deployed for years and operate with limited user visibility. If operators cannot prove who owns the device trust relationship at each stage, then security incidents become hard to contain and even harder to clean up.
Practical implication: Map onboarding, patching, certificate renewal, and decommissioning into one governed device lifecycle process.
Why embedded trust hardware matters in large fleets
TPMs and secure elements move key storage and local authentication into hardware, which reduces the chance that secrets are copied, reused, or extracted at scale. This does not eliminate risk, but it changes the attack economics by making credential theft and device impersonation harder. In large fleets, that matters because manual trust checks do not scale and human intervention for each access decision becomes unrealistic. Managed certificate services then provide the orchestration layer that lets organisations update trust consistently across many devices without relying on ad hoc administration.
Practical implication: Use hardware-backed trust for devices that must authenticate autonomously and align it with managed certificate issuance and revocation.
Threat narrative
Attacker objective: The attacker wants to turn poorly governed IoT devices into scalable footholds for disruption, surveillance, or botnet-driven attacks.
- Entry begins with weak passwords, outdated firmware, or unprotected default access on IoT devices that are brought online without strong identity controls.
- Credential abuse follows when attackers use those weaknesses to impersonate legitimate devices, enroll them into botnets, or pivot through them as trusted endpoints.
- Impact appears as DDoS activity, unsafe telemetry, disrupted operations, or compromised industrial and medical systems that depend on the device feed.
NHI Mgmt Group analysis
IoT security maturity is really machine identity maturity. The article is right to move the discussion away from isolated device hardening and toward authenticated trust across the lifecycle. In identity terms, IoT devices behave like non-human identities that must be issued, validated, rotated, and revoked, or they become unmanaged trust objects. The practitioner conclusion is straightforward: if the device cannot be reliably identified, the fleet cannot be reliably governed.
Lifecycle accountability is the control gap that keeps IoT risk sticky. The article shows that manufacturers, resellers, and operators often split responsibility in ways that leave no single owner for updates, revocation, or retirement. That governance gap is more important than any single technical flaw because it makes remediation inconsistent after deployment. The practitioner conclusion is to assign lifecycle ownership explicitly, not assume the supply chain will self-govern.
PKI is becoming the minimum viable trust model for scaled IoT. Shared passwords and ad hoc onboarding do not provide durable assurance when fleets grow into the millions and devices must communicate autonomously. Certificate-backed identity, supported by secure elements or TPMs, gives operators a way to authenticate devices without manual approval loops. The practitioner conclusion is to treat certificate management as operational infrastructure, not as a niche crypto exercise.
Fragmented standards are now an identity governance risk, not just an interoperability problem. The article's point about uneven standards matters because inconsistent controls create inconsistent trust boundaries, which in turn complicates offboarding, attestation, and revocation. That is why universal device security baselines matter to identity governance as much as they do to compliance. The practitioner conclusion is to normalise device trust requirements across procurement, onboarding, and retirement.
AI will amplify IoT governance unless identity controls keep pace. The article correctly notes that AI can improve anomaly detection while also widening the attack surface through data manipulation and model abuse. That means the security posture of IoT is no longer just about the device, but about the integrity of the telemetry and decision chain behind it. The practitioner conclusion is to validate both device identity and data integrity before automating responses.
What this signals
IoT fleets need machine identity governance, not just perimeter security. As deployments scale, the practical challenge shifts from securing individual devices to governing how every device is issued trust, refreshed, and retired. That is why certificate lifecycle management becomes part of security operations rather than an optional crypto layer.
Lifecycle fragmentation is the underlying reason IoT risk stays stubborn. When manufacturers, distributors, and operators each own only part of the trust chain, no single control closes the gap. The result is familiar to identity teams: accountability is diffuse, and diffuse accountability produces durable exposure.
Hardware-backed trust is the most realistic path to scalable device authentication. TPMs and secure elements make stolen credentials harder to reuse, which matters when millions of devices must authenticate without human approval. For practitioners, the signal is clear: trust has to move into the device and be managed like an identity program.
For practitioners
- Standardise certificate-based device onboarding Require every IoT device class to authenticate with a cryptographic identity before joining production networks, and reject deployments that rely on shared passwords or defaults.
- Build a single device lifecycle owner model Assign one accountable owner for provisioning, certificate renewal, firmware validation, revocation, and retirement so no stage of the device lifecycle is left ambiguous.
- Use hardware-backed trust for high-risk fleets Deploy TPMs or secure elements where devices must authenticate autonomously, then pair them with managed certificate services for key protection and scale.
- Tie IoT procurement to lifecycle security evidence Make update support, revocation capability, and vulnerability reporting part of procurement decisions so lifecycle controls are present before devices are deployed.
Key takeaways
- IoT security maturity is now a governance question because devices need reliable identity, lifecycle ownership, and revocation, not just harder defaults.
- The article links weak passwords, old firmware, fragmented standards, and unclear responsibility to the same root problem: unmanaged trust at scale.
- Practitioners should treat PKI, hardware-backed trust, and lifecycle accountability as the controls that make IoT governance enforceable.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | The article centres on device authentication that fails without certificates or strong identity. |
| NHI-07 — Long-Lived Secrets | IoT devices often persist for years, making stale credentials and unmanaged keys a core risk. | |
| NHI-01 — Improper Offboarding | The article stresses revocation and decommissioning as part of IoT maturity. | |
| Recommendation — Replace shared credentials with certificate-based authentication for every IoT device class. Track and rotate device credentials on a lifecycle schedule that matches fleet exposure. Make offboarding and certificate revocation mandatory parts of device retirement. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Credential issuance, rotation, and revocation are central to the article's lifecycle argument. |
| Recommendation — Apply IA-5 to govern issuance, rotation, and revocation of device authenticators. | ||
| CIS Controls v8 | CIS-5 — Account Management | Device identity lifecycle maps closely to account and credential governance at fleet scale. |
| Recommendation — Extend account management discipline to device identities and machine credentials. | ||
| MITRE ATT&CK | TA0006;TA0040 — Credential Access; Impact | The article's threat path runs from weak device trust to botnet abuse and disruptive impact. |
| Recommendation — Map IoT weak-credential exposure to credential access and impact stages in threat hunting. | ||
Key terms
- Machine Identity: The digital identity of a machine, device, or workload, such as a server, container, or VM, used to authenticate it within a network. Sometimes used interchangeably with NHI, though NHI is the broader category.
- Certificate Lifecycle Management: The governance of digital certificates from issuance through renewal and revocation, ensuring certificates are valid, monitored, and rotated before expiry. Expired certificates are a leading cause of outages and unplanned security gaps.
- 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.
- Vendor offboarding: Vendor offboarding is the controlled removal of a third party's access, data paths, and operational dependencies when the relationship ends or changes. It is a lifecycle control, not an administrative closeout, because any surviving credentials or integrations remain active security exposure.
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 to govern non-human access and lifecycle control across modern environments.
Published by the NHIMG editorial team on July 11, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org