TL;DR: IoT device security is strongest when PKI, digital certificates, and device identity are built into design, manufacturing, provisioning, and update workflows, according to DigiCert. The governance gap is not authentication alone but lifecycle trust: devices need integrity, confidentiality, and revocation-aware identity controls from factory to field.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on DigiCert's blog post: IoT device security needs PKI across the full device lifecycle, not just at first authentication.
Why it matters: For IAM and security teams, it shows why device identity, certificate lifecycle management, and update integrity have to be governed as one control plane for connected devices.
Context
IoT device security fails when organisations treat authentication as a point control instead of a lifecycle property. A device that can prove itself once at provisioning but cannot be traced, updated, or revoked safely later still carries identity risk into the field.
In this article, DigiCert links IoT security to PKI, digital certificates, secure boot, encrypted updates, and device identity. That framing matters because connected devices are long-lived assets whose trust must survive manufacturing, deployment, cloud connection, and software maintenance.
The broader governance problem is that many IoT programmes still separate product design from identity assurance. Once devices are deployed at scale, weak certificate handling and poor provenance controls become operational security issues, not just technical implementation details.
Key questions
A: Security teams should treat PKI for IoT as a lifecycle programme, not just a certificate issuance task. Start with device identity at manufacturing or onboarding, use scalable certificate enrollment, monitor certificate inventory continuously, and plan for renewal, revocation, and reporting. The goal is to keep authentication strong while making certificate management efficient enough for large device populations.
Q: Why do IoT devices need more than two-factor authentication?
A: Two-factor authentication helps with access events, but IoT devices need cryptographic identity that survives manufacturing, updates, and cloud connectivity. A device must prove authenticity repeatedly, not just at login, and it must support secure update and revocation workflows. Certificates provide that persistent device trust model.
Q: What breaks when IoT identity is handled only at provisioning?
A: Provisioning-only identity leaves later stages ungoverned, so a device may be genuine at first use but unauthorised, stale, or unverifiable after deployment. That creates gaps in update integrity, revocation, and cloud access control. In practice, the fleet becomes harder to trust the longer it operates.
Q: What is the difference between secure boot and firmware signing in IoT devices?
A: Firmware signing protects the authenticity of the update package before it is installed, while secure boot checks trust at startup so the device only runs approved code. Together they cover two different moments in the lifecycle: delivery and execution. Both are needed because a trusted update is not enough if the device later boots untrusted software.
Technical breakdown
Why PKI becomes the device trust layer for IoT
Public key infrastructure gives an IoT device a verifiable identity and a way to prove that identity to services, update systems, and management platforms. In this model, certificates support mutual authentication, encrypted transport, integrity validation, and device-to-cloud trust. That matters because IoT devices are often unattended, distributed, and difficult to patch in place. PKI does not replace secure engineering, but it provides the cryptographic control plane that lets manufacturers distinguish genuine devices from impostors and validate that messages and updates have not been altered in transit.
Practical implication: Treat PKI as the baseline identity layer for IoT fleets, not as an optional add-on to network security.
How certificate lifecycle management supports manufacturing and field deployment
IoT environments need flexible certificate provisioning because devices may be personalised before manufacturing, during supply-chain assembly, or after deployment in the field. The article points to on-premises, cloud, hybrid, and air-gapped deployment patterns, which reflects a real operational constraint: device identity has to fit manufacturing reality, not the other way around. Certificate profiles, templates, and issuance timing must align to device capability, shelf life, and connection model. Without that lifecycle discipline, the same identity control that secures one device class can break down across another.
Practical implication: Design certificate issuance and provisioning around the device’s actual build and deployment path.
Why secure updates depend on device identity and authenticity
A major IoT weakness is not just insecure transport, but unsigned or unauthenticated software changes reaching devices that cannot tell whether the update is genuine. PKI solves part of that problem by binding update trust to device identity and encryption. Secure boot extends the same logic to startup, ensuring the device verifies code before execution. In practice, firmware integrity, authenticated delivery, and device-specific decryption form one chain of trust. If any link is weak, a malicious update or counterfeit device can slip through a process that otherwise appears controlled.
Practical implication: Use certificate-backed signing and verification for firmware and OTA updates, and make revocation part of the update trust model.
Breaches seen in the wild
- GitHub code signing certificate theft 2022: A machine account's compromised token cloned GitHub's Desktop and Atom repos, exposing encrypted signing certificates later revoked.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
PKI is the only scalable way to make IoT identity durable across the device lifecycle. IoT devices are not authenticated once and then forgotten. They move through design, production, provisioning, field operation, update cycles, and eventual retirement, which means their identity has to survive every phase. The security mistake is treating trust as a setup event rather than a lifecycle state. Practitioners should govern device identity as an ongoing control domain, not a one-time certificate issue.
Device authenticity and software integrity are now inseparable controls. The article correctly ties genuine-device identification to secure update delivery because counterfeit devices and tampered firmware solve the same attacker problem from different angles. If a device cannot prove who it is, and an update cannot prove what it is, the same trust gap remains. That is why IoT governance has to couple provenance, issuance, and update validation instead of managing them as separate programmes.
PKI exposes a governance gap that many IoT programmes still ignore: revocation has to be operationally real. A certificate is only useful if the organisation can rotate it, revoke it, and re-establish trust without breaking the fleet. That requirement is especially important where devices are long-lived or physically hard to touch. The practitioner conclusion is straightforward: revocation-aware device identity must be designed into operations before scale makes exceptions unmanageable.
IoT security depends on crossing the boundary between product engineering and identity governance. The article shows why manufacturers cannot leave security to the final deployment stage. Device identity, certificate lifecycle management, and authenticated updates are governance problems as much as engineering ones. That means security teams, product teams, and operations teams need a shared model for issuing, validating, and retiring device trust.
What this signals
Device trust has to be lifecycle-aware: IoT programmes should stop treating certificates as a provisioning artefact and start managing them as an operational identity control. That changes ownership across engineering, operations, and security, because identity now has to survive update, recovery, and retirement events.
The most useful mental model is to think of the device as a non-human identity with a long service life and a short tolerance for trust drift. Once that is accepted, certificate renewal, update signing, and revocation become core governance work rather than background administration.
For practitioners
- Build certificate-backed device identity into product design Define how each device class will receive a unique identity, how that identity will be validated, and how it will be re-established after replacement or recovery.
- Align provisioning with manufacturing reality Map certificate issuance to the actual production, supply-chain, or field-provisioning stage used for each device family, including offline or air-gapped environments.
- Require signed and encrypted device updates Make firmware and OTA update workflows verify authenticity before installation and bind decryption to the intended device identity.
- Plan for certificate renewal and revocation at fleet scale Document how stale certificates are renewed or revoked without leaving unmanaged devices in the field or breaking critical device operations.
- Separate genuine-device checks from access decisions Use device authentication to prove provenance first, then apply policy for service access, telemetry, and cloud connectivity based on that verified identity.
Key takeaways
- IoT device security weakens when authentication is separated from the rest of the device lifecycle, because trust has to survive manufacturing, deployment, updates, and retirement.
- PKI gives manufacturers a practical way to bind identity, encryption, integrity, and update assurance to a specific device instead of to the network alone.
- For practitioners, the operational question is no longer whether devices can authenticate, but whether their identity can be issued, renewed, and revoked without breaking the fleet.
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 addresses the attack and risk surface, while NIST SP 800-53 Rev 5, CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | IoT devices need revocation and retirement handling across their lifecycle. |
| NHI-04 — Insecure Authentication | The article centres on certificate-backed device authentication and trust. | |
| NHI-07 — Long-Lived Secrets | IoT device certificates can persist too long without lifecycle governance. | |
| Recommendation — Define device retirement and certificate revocation as a mandatory offboarding step for every IoT identity. Use certificate-based authentication to verify device identity before allowing service access. Track certificate age and renewal windows so device credentials do not outlive their intended trust period. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Certificate issuance, renewal, and revocation map directly to authenticator lifecycle. |
| IA-9 — Service Identification and Authentication | IoT devices authenticate to services and cloud endpoints using machine identity. | |
| Recommendation — Apply authenticator management controls to provision, rotate, and revoke device certificates on schedule. Require service-to-device mutual authentication before any telemetry or update exchange. | ||
| CIS Controls v8 | CIS-5 — Account Management | Device identity lifecycle management is an account lifecycle problem at fleet scale. |
| Recommendation — Maintain an inventory of device identities and remove stale credentials when devices are retired. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Device certificates govern who or what can access IoT services and updates. |
| Recommendation — Tie device entitlements to verified identity and remove access when trust can no longer be proven. | ||
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.
- 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.
- Secure Boot: A device startup process that verifies each code stage before execution continues. It ensures the firmware, bootloader, kernel, and operating system have valid signatures, so unauthorised code is blocked before it can control the platform.
- Firmware Signing: The process of applying a cryptographic signature to device software so the device can verify it came from an approved source. It is a governance control as much as a technical control because signer access, key protection, and auditability determine whether the trust chain remains valid.
Deepen your knowledge
NHI governance, identity lifecycle, and workload identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 24, 2026.
Updated on October 8, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org