IoT device security depends on stronger authentication and trust

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Keyfactor's blog post: IoT device security depends on hardware-backed trust, device certificates, mutual authentication, and disciplined key management rather than assumptions about device legitimacy.

Why it matters: It matters because IoT programmes fail when device identity, certificate lifecycle, and authentication controls do not scale with fleet growth, leaving connected systems open to impersonation and tampering.

Context

IoT device security depends on proving that a device is genuine before it is allowed to connect, load code, or exchange data. The governance gap is that many deployments still treat device identity as a one-time setup task instead of a lifecycle control that has to hold across registration, authentication, and key management.

That gap becomes more dangerous as fleets scale across consumer devices, medical devices, vehicles, and other connected systems. Weak encryption, unclear standards, and inconsistent certificate handling create a trust problem that is as much about identity assurance as it is about firmware integrity.

Key questions

Q: How should security teams authenticate IoT devices at scale?

A: Use PKI with per-device certificates, centralized issuance, and automated renewal so authentication does not rely on shared secrets or manual provisioning. The control objective is to make device identity verifiable across cloud, edge, and embedded environments while preserving revocation and monitoring as normal operational functions.

Q: Why do pre-shared keys create risk in IoT environments?

A: Pre-shared keys become risky because they are hard to rotate, easy to reuse, and difficult to revoke selectively when a single device is compromised. At scale, they turn one trust decision into a fleet-wide exposure problem. Unique device credentials reduce the blast radius and make accountability clearer.

Q: What breaks when IoT device trust is not continuously verified?

A: Devices can be accepted as legitimate after first contact even when their software, keys, or network path have changed. That opens the door to impersonation, man-in-the-middle abuse, and lateral movement from a trusted device into adjacent systems.

Q: Should IoT programmes prioritise device certificates or encryption first?

A: Device certificates should come first when the problem is proving device identity, because encryption without identity assurance still allows imposters to establish protected sessions. Strong transport security matters, but it does not solve trust if the device itself is not reliably authenticated.

Technical breakdown

Root of trust and secure boot in IoT identity

A root of trust is the anchor that lets a device prove it is running authorised code on legitimate hardware. Secure boot extends that trust by verifying boot images and firmware signatures before execution, so tampered code never becomes active. In practice, this chain of trust turns device startup into a verification event rather than a blind execution step. Hardware security modules can hold keys that support this model, which matters because the trust decision only works if the stored material is protected from extraction and reuse. In IoT environments, the device is the identity, so the boot path becomes part of identity assurance.

Practical implication: require hardware-backed boot trust for connected devices that can affect sensitive systems or data.

Device certificates and mutual authentication at fleet scale

X.509 device certificates give each IoT device a unique digital identity that can be validated by a certificate authority. Mutual authentication then checks both sides of the connection, so the device does not trust the server automatically and the server does not accept the device without proof. This matters because man-in-the-middle attacks exploit one-sided trust and weak validation. The operational challenge is not the certificate concept itself but the lifecycle overhead at fleet scale: issuance, renewal, revocation, and replacement have to work across large populations of devices without manual effort.

Practical implication: automate certificate lifecycle management so device identity remains verifiable across the full fleet.

Key management, PSKs, and the limits of static trust

Key management becomes the deciding control when IoT devices rely on symmetric secrets or pre-shared keys. A single compromised key can expose both endpoints, and static secrets are hard to rotate at scale. Zero-trust network access changes the trust model by requiring verification on every request instead of treating the device as trusted after first use. That is why the article’s strongest technical point is not just that IoT needs encryption, but that IoT needs continuous, identity-based verification to resist impersonation and lateral movement. Static trust assumptions break down quickly once devices are always on and always reachable.

Practical implication: treat static keys and one-time trust decisions as temporary measures, not a durable operating model.

Threat narrative

Attacker objective: The attacker aims to impersonate trusted IoT devices or intercept their traffic so they can tamper with data, undermine privacy, or extend access into connected systems.

1. Entry begins when an IoT device connects with weak encryption, a shared secret, or a certificate that is not strongly validated.
2. Credential abuse follows when the attacker reuses a pre-shared key, impersonates the device, or inserts themself into a weakly authenticated session.
3. Escalation occurs when the attacker intercepts or alters device traffic, or uses the trusted connection to move into adjacent systems.
4. Impact is tampering, privacy loss, or wider compromise of connected environments that depend on the device's identity being trusted.

Breaches seen in the wild

• Verkada camera breach 2021: Admin credentials on Verkada's exposed Jenkins support server let hackers into a support interface and customer cameras at 97 customers.
• SonicWall SSL VPN account compromises 2025: Attackers used valid credentials to log in to more than 100 SonicWall SSL VPN accounts across 16 environments in October 2025.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

IoT authentication fails when device identity is treated as a setup problem rather than a lifecycle control: A device certificate only creates value if issuance, renewal, revocation, and replacement remain governed over time. That is the real operating gap in connected-device programmes. Practitioners should treat identity assurance as a fleet process, not a provisioning event.

Static trust assumptions break first in IoT because device populations are too large for manual verification: Pre-shared keys and one-time authentication can work in narrow deployments, but they become brittle once devices multiply across products, regions, and vendors. The resulting operational debt is not just administrative overhead. It is a standing opportunity for impersonation and session abuse.

Zero-trust logic is more appropriate for IoT than perimeter logic because device legitimacy cannot be assumed after first contact: Every request must be revalidated when devices are always on, always connected, and frequently unmanaged by end users. That shifts the control point from network placement to ongoing proof of identity.

Identity blast radius is the right concept for IoT governance: Once a certificate, shared key, or trust anchor is reused across too many devices, a single failure can affect an entire product line. That is why the issue is not only authentication strength, but how much damage one compromised identity can create.

Security standards for IoT still lag deployment reality: Weakly defined requirements leave manufacturers and operators to improvise controls for hardware trust, mutual authentication, and key lifecycle management. Practitioners should treat this as a governance maturity problem, not a feature checklist.

What this signals

Identity assurance is the missing control plane in IoT: fleets fail when teams focus on device hardening but leave authentication, revocation, and key ownership ambiguous. The practical shift is to govern IoT devices as identities that must be issued, validated, and retired with the same discipline used for other non-human identities.

Zero-trust assumptions fit IoT because device legitimacy is not stable over time: a device that was trusted at onboarding can later be cloned, misconfigured, or abused. Continuous verification matters more than perimeter placement when the asset itself is always connected.

Certificate and key sprawl is the real scaling problem: once devices multiply across product lines and regions, the challenge is no longer whether trust is technically possible, but whether the organisation can prove who owns each identity and who can revoke it when needed.

For practitioners

• Establish hardware-backed root of trust Require tamper-resistant trust anchors for devices that authenticate into sensitive networks, and prohibit designs that rely only on software-held secrets for identity proof.
• Automate device certificate lifecycle Use certificate issuance, renewal, and revocation workflows that can scale across large IoT fleets without manual intervention, especially where devices cannot be directly touched by administrators.
• Enforce mutual authentication on device connections Reject one-sided trust for device-to-service traffic and verify both endpoints before accepting telemetry, commands, or configuration updates.
• Reduce reliance on pre-shared keys Limit static shared secrets to narrow exceptions and track where a compromise would expose multiple devices or services at once.
• Define revocation paths before rollout Make certificate and key revocation part of the deployment design so compromised or retired devices can be removed from trust quickly.

Key takeaways

• IoT security fails when trust is inferred from connectivity instead of proved through device identity and authentication.
• The article's core warning is that weak encryption, unclear standards, and static secrets create impersonation risk at fleet scale.
• Practitioners need lifecycle governance for certificates, keys, and revocation, not just stronger device hardening.

Key terms

• Root Of Trust: A root of trust is the authoritative starting point that other identities and certificates rely on for validation. In distributed ecosystems, it determines which parties can establish trust, which can be revoked, and how consistent authentication remains across vendors and environments.
• 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.
• Mutual Authentication: Mutual authentication is a two-way verification process where each party proves its identity before communication proceeds. In connected operational systems, it prevents devices and services from trusting unauthenticated peers and helps enforce identity-first security across distributed environments.
• Digital Certificate Lifecycle: The digital certificate lifecycle covers issuance, deployment, monitoring, renewal, revocation, and replacement. Each stage carries operational and security risk, so mature management requires visibility into where certificates are used and the ability to act quickly when trust conditions change.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle 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.