Notifications
Clear all
Topic starter
25/06/2026 12:15 am
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.
NHIMG editorial — based on content published by DigiCert: This IoT Day, don’t forget to discuss device security
Questions worth separating out
Q: How should security teams govern device identity in IoT fleets?
A: Security teams should govern IoT device identity with the same discipline they use for other machine identities: unique credentials, controlled issuance, monitored renewal, and explicit retirement.
Q: Why do IoT devices need certificates instead of shared secrets?
A: Certificates give each device a verifiable identity and support mutual authentication, while shared secrets are easier to copy, reuse, and expose at scale.
Q: When does secure boot matter most for connected devices?
A: Secure boot matters whenever a device could be physically accessed, remotely updated, or deployed in an environment where attackers can tamper with firmware or configuration.
Practitioner guidance
- Bind device identity to cryptographic trust at provisioning Issue unique certificates or equivalent device identities during manufacturing or secure onboarding, and avoid shared credentials across fleets.
- Require signed firmware and verified update channels Make code signing mandatory for every software and configuration update path, and reject any update that cannot be verified against an authorised signer.
- Track certificate lifecycle from creation to retirement Monitor issuance, renewal, revocation, and decommissioning as a single lifecycle process so identity does not linger after a device is retired or reassigned.
What's in the full article
DigiCert's full blog covers the operational detail this post intentionally leaves for the source:
- Deployment flexibility for on-premises, cloud, hybrid, and air-gapped manufacturing environments
- How DigiCert IoT Trust Manager and Software Trust Manager map to certificate provisioning and software integrity workflows
- Examples of certificate profile design for different device types and shelf-life requirements
- Platform deployment details for teams evaluating whether PKI can fit their manufacturing and field-update processes
👉 Read DigiCert's blog on IoT device security and PKI lifecycle controls →
PKI for IoT devices: what device security teams need to know?
Explore further
25/06/2026 9:08 am
PKI is the identity layer IoT security cannot outsource. The article’s core point is that device security depends on proving device identity, not just protecting the network around the device. That aligns with OWASP-NHI thinking: a device that cannot authenticate itself and its updates is operating outside durable governance. Practitioners should treat cryptographic identity as foundational, not supplemental.
A few things that frame the scale:
- 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, 38% have no or low visibility, and a further 47% have only partial visibility, according to The State of Non-Human Identity Security.
- 45% of organisations cite lack of credential rotation as the top cause of NHI-related attacks, followed by inadequate monitoring and logging at 37% and over-privileged accounts at 37%, according to The State of Non-Human Identity Security.
A question worth separating out:
Q: What should organisations review before rolling IoT devices into production?
A: They should review how identity is issued, where certificates are stored, how updates are signed, and how revoked or retired devices are removed from trust relationships. If those answers are unclear, production deployment will expand the attack surface instead of controlling it.
👉 Read our full editorial: IoT device security depends on PKI across the device lifecycle
