Why do IoT devices need certificates instead of shared secrets?

Why This Matters for Security Teams

IoT certificate decisions are really identity decisions: every sensor, gateway, camera, and actuator is a non-human identity that needs to prove who it is before it can be trusted. Shared secrets seem simpler at first, but they scale poorly because the same credential is copied, embedded, reused, and eventually exposed across fleets. That makes clone detection, revocation, and incident containment much harder than most deployment teams expect.

This is the same pattern NHI Management Group documents in the Guide to the Secret Sprawl Challenge, where credential distribution and recovery become the real operational burden. The risk is not abstract: once a shared secret escapes, every device using it inherits the same exposure. By contrast, certificate-based trust gives each device a distinct cryptographic identity and makes compromise easier to isolate. That aligns with the OWASP Non-Human Identity Top 10, which treats identity sprawl and weak credential lifecycle controls as core failure modes.

NHI Management Group’s research also shows how quickly secrets fail in practice: the State of Secrets in AppSec reports that the average time to remediate a leaked secret is 27 days, which is far too slow for devices that may already be deployed globally. In practice, many security teams discover cloneable secrets only after one compromised device has already exposed an entire fleet.

How It Works in Practice

Certificate-based IoT security replaces “everyone knows the same secret” with “each device proves its identity through a unique key pair and certificate chain.” During onboarding, a device generates or receives a private key, and a trusted authority issues a certificate binding that key to the device identity. At connection time, mutual TLS lets both the device and the service verify each other, which reduces impersonation risk and supports stronger device-level accountability.

Operationally, the advantage is not just authentication. Certificates support lifecycle controls that shared secrets struggle to match: per-device revocation, short validity periods, renewal automation, and clearer separation between authentic devices and counterfeit endpoints. For constrained or intermittently connected devices, current guidance suggests balancing certificate complexity against bootstrap reliability, but the security model still benefits from unique identities. Guidance from the Ultimate Guide to NHIs - Static vs Dynamic Secrets reinforces that short-lived credentials are easier to contain than long-lived shared values.

• Use a device-specific key pair rather than a fleet-wide password or API key.
• Issue certificates from a trusted CA and bind them to a device identity, not just a network location.
• Automate renewal so certificates rotate before expiry, rather than extending secret lifetimes to avoid downtime.
• Revoke compromised devices individually instead of forcing a full fleet reset.
• Prefer hardware-backed key storage where possible to reduce extraction risk.

For implementers, the relevant external references are IETF RFC 5280 for certificate profiles and CISA guidance for device trust and operational resilience. These controls tend to break down when devices cannot securely protect private keys or when field updates are so unreliable that certificate renewal cannot be automated.

Common Variations and Edge Cases

Tighter certificate handling often increases onboarding and renewal overhead, so organisations have to balance strong identity assurance against field maintenance costs. That tradeoff is especially visible in low-power devices, offline equipment, and legacy industrial controllers where full PKI workflows can be difficult to deploy. In those environments, best practice is evolving rather than settled, and there is no universal standard for every bootstrap pattern.

Some teams use manufacturer-installed certificates at factory time, while others provision certificates at first boot through a registration service. Both can work, but they create different trust assumptions and recovery paths. The important distinction is that certificate authority control, revocation, and renewal must remain manageable at fleet scale. If those processes are manual, the organisation may end up recreating the same operational fragility that shared secrets already caused.

Emerging IoT architectures also benefit from tying certificates to broader NHI governance, especially when devices call APIs, publish telemetry, or receive commands from cloud services. The Ultimate Guide to NHIs - What are Non-Human Identities is useful here because it frames devices as identities with lifecycles, not just endpoints. In practice, the right choice is not “certificates everywhere” but “unique, revocable, cryptographically verifiable identities wherever device trust matters.”

Related resources from NHI Mgmt Group

• How should security teams reduce credential sharing on shared devices?
• How should healthcare organisations secure shared mobile devices without slowing clinicians down?
• How do certificates improve IoT security and privacy controls?
• Why do expired certificates increase breach risk in enterprise environments?