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

Why This Matters for Security Teams

Pre-shared keys create a trust model that scales poorly in IoT because every device inherits the same secret handling problem: provisioning, storage, rotation, and revocation all become fleet-wide concerns. Once that key leaks, there is no clean way to prove which device used it, which is why incident response becomes broad and expensive. NIST’s Cybersecurity Framework 2.0 emphasises asset visibility and risk management, but shared secrets weaken both in connected device fleets.

NHIMG research shows how quickly secret sprawl turns into operational exposure. The Ultimate Guide to NHIs notes that 71% of NHIs are not rotated within recommended time frames, and 96% of organisations store secrets outside secrets managers in vulnerable locations. In IoT, the same pattern appears when device keys are embedded in firmware, copied into staging systems, or shared across hardware generations. In practice, many security teams encounter the breach only after a single key has already been reused across devices and the revocation window has closed.

How It Works in Practice

The safer model is unique identity per device, not one shared credential for the entire fleet. Each IoT endpoint should have a distinct workload identity, ideally anchored in hardware-backed trust such as a secure element or TPM, then authenticated with short-lived credentials rather than a long-lived pre-shared key. That approach supports selective revocation, cleaner device attribution, and stronger blast-radius control.

In mature deployments, device identity is bound to provisioning and lifecycle controls. A device is enrolled, its identity is attested, and it receives time-bound credentials for a narrow set of services. Access is then evaluated at runtime based on the device, the requested service, and policy context. That is consistent with zero trust principles and with the NHIMG guidance on reducing secret exposure in the Top 10 NHI Issues.

• Use per-device credentials instead of fleet-wide keys.
• Prefer short TTLs and automated renewal over static secrets.
• Store secrets in a dedicated manager, not in firmware, code, or config files.
• Track device identity, certificate lifecycle, and revocation status continuously.
• Use policy-based access decisions rather than assuming any device with the key is trusted forever.

For implementation detail, security teams often align device identity with standards-based models such as mTLS and certificate-based authentication, then map those controls into operational governance using the NIST Cybersecurity Framework 2.0. This is where IoT programs move from shared-secret convenience to accountable identity management. These controls tend to break down in brownfield fleets where devices cannot support certificate updates, because legacy hardware often lacks secure storage, reliable rotation, or remote revocation.

Common Variations and Edge Cases

Tighter credential control often increases provisioning overhead, so organisations must balance security against deployment speed and device constraints. That tradeoff is most visible in low-cost, battery-powered, or intermittently connected IoT devices, where full certificate workflows may be impractical. Current guidance suggests avoiding permanent shared keys where possible, but there is no universal standard for every constrained environment.

Some teams use pre-shared keys during bootstrap only, then replace them with device-specific credentials after first contact. That is a reasonable transition pattern when factory enrolment or secure attestation is available. Others rely on segmented network controls to reduce exposure, but segmentation is not a substitute for identity because a stolen key still authenticates as valid. NHIMG’s 2024 ESG Report: Managing Non-Human Identities found that 72% of organisations have experienced or suspect a breach of non-human identities, which underscores how quickly shared credentials become systemic risk.

Shared keys may still appear in legacy protocols, vendor-managed devices, or offline manufacturing workflows, but the long-term pattern should be removal, not expansion. Where replacement is not yet possible, treat every shared key as high risk, tightly segmented, and time-limited, because one compromise can still expose the entire device class.

Related resources from NHI Mgmt Group

• Why do over-the-air updates create identity risk for IoT fleets?
• Why do non-human identities create more risk than many human accounts?
• Why do non-human identities create more remediation risk than many human accounts?
• Why do static SSH keys and shared admin accounts create compliance risk?