How should security teams authenticate IoT devices at scale?

Why This Matters for Security Teams

IoT authentication fails at scale when devices are treated like users instead of constrained, long-lived workloads with distinct identity lifecycles. Shared passwords, factory-default secrets, and manual enrollment create brittle trust paths that break under fleet growth, device replacement, and field operations. NIST guidance on device identity and the NIST Cybersecurity Framework 2.0 both point toward stronger identity assurance, but the practical challenge is operational: every device needs a verifiable, revocable identity from first boot to decommissioning.

This is where non-human identity discipline matters. NHI Management Group has documented how weak lifecycle controls dominate real-world exposure, including the fact that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys. The same pattern shows up in IoT fleets when secrets are embedded in firmware, copied into provisioning scripts, or left unchanged across thousands of devices. In practice, many security teams discover the authentication problem only after a device has already been cloned, resold, or quietly used as a foothold for lateral movement.

How It Works in Practice

The scalable model is PKI-backed device identity with per-device certificates, centralized issuance, and automated renewal. Each device should receive a unique cryptographic identity during manufacturing, staging, or first enrollment, then authenticate with mutual TLS or another certificate-based mechanism. This avoids the operational failure of shared secrets, where one leak compromises the entire fleet.

At a minimum, effective implementation usually includes:

• Unique device key pairs generated in secure hardware where possible, such as TPMs, secure elements, or trusted enclaves.
• Automated certificate issuance and renewal, ideally tied to device posture, serial number, ownership, and policy state.
• Short-lived credentials and rapid revocation so a lost, retired, or tampered device cannot keep authenticating.
• Central inventory and telemetry so identity, firmware, and network status can be correlated during incident response.
• Policy decisions that evaluate device context at connection time, not just at onboarding.

Current guidance suggests pairing PKI with Zero Trust principles rather than assuming the device is safe because it sits on an internal network. That means using explicit authentication for each service interaction, constraining trust by device class, and rotating certificates automatically so renewal is not a manual rescue task. This lines up with the operational reality described in The State of Non-Human Identity Security, which highlights credential rotation and monitoring gaps as recurring causes of compromise. For governance and architecture context, the NIST Cybersecurity Framework 2.0 reinforces identity, monitoring, and recovery as continuous functions, not one-time setup tasks. These controls tend to break down when low-power devices cannot support secure key storage or when the fleet includes legacy hardware that was never designed for per-device cryptographic enrollment.

Common Variations and Edge Cases

Tighter device authentication often increases operational overhead, requiring organisations to balance stronger assurance against manufacturing, logistics, and field-service constraints. That tradeoff is especially visible when fleets include mixed generations of hardware, intermittent connectivity, or third-party-managed devices.

There is no universal standard for every IoT environment yet, but a few patterns are consistent. In highly constrained devices, certificate renewal intervals may need to be longer, with compensating controls such as signed firmware, secure boot, and network segmentation. In offline or intermittently connected environments, best practice is evolving toward delegated issuance windows and grace periods rather than permanent shared credentials. For third-party devices, contract language should require unique identity per unit, revocation support, and evidence of key protection before onboarding.

Security teams should also distinguish between device identity and application identity. A device certificate proves the hardware or embedded runtime, but it does not automatically prove the trustworthiness of the software running on it. That is why many programs combine PKI with attestation, posture checks, and least-privilege network access. The lesson from NHIMG research is consistent: authentication alone is not enough if revocation, monitoring, and offboarding are weak. In practice, teams struggle most when field devices cannot be reached for renewal or revocation, because identity hygiene collapses once the fleet is no longer fully managed.

Related resources from NHI Mgmt Group

• How should security teams authenticate AI agents in enterprise environments?
• How should security teams implement Client ID Metadata Documents?
• What should security teams do when IoT devices reach end of life?
• How should security teams secure Linux IoT devices with limited CPU and memory?