IoT Security Reference
The Internet of Things (IoT) encompasses billions of network-connected devices — from industrial sensors and medical equipment to smart building controllers and consumer electronics — that extend attack surfaces far beyond traditional IT perimeters. This reference covers the definition and scope of IoT security, the mechanisms through which IoT devices are protected, the most common vulnerability scenarios, and the decision boundaries practitioners use to classify and address IoT risk. The sector operates under a fragmented but evolving regulatory landscape, with guidance from NIST, CISA, and the FTC shaping baseline expectations for manufacturers and operators.
Definition and scope
IoT security refers to the discipline of protecting network-connected physical devices, their embedded firmware, communication channels, and supporting cloud or on-premises infrastructure from unauthorized access, manipulation, or disruption. The scope extends across the full device lifecycle — from hardware design and firmware development through deployment, operation, and decommissioning.
NIST defines IoT devices as devices that "have at least one transducer (sensor or actuator) for interacting directly with the physical world, have at least one network interface" (NIST SP 800-213). That definition captures an estimated 15 billion connected devices globally as of 2023, a figure cited by industry analyses drawing on GSMA Intelligence reporting.
IoT security is distinct from conventional endpoint security in three structural ways: devices frequently run stripped-down operating systems with no patch management interface, physical access to hardware is often impossible after deployment, and device lifespans commonly exceed the support windows of their embedded software.
The regulatory perimeter includes:
- NIST SP 800-213 — federal IoT cybersecurity guidance for agencies
- FTC Act Section 5 — applied to deceptive or unfair IoT security practices by manufacturers
- CISA's IoT Security Guidance — voluntary baseline recommendations for critical infrastructure operators
- California SB-327 (2018) — the first US state law requiring "reasonable security features" for connected devices sold in California, codified at California Civil Code §1798.91.04
- NISTIR 8259 — foundational activities for IoT device manufacturers (NISTIR 8259A)
IoT security intersects significantly with OT/ICS security in industrial environments, where physical process control systems and sensor networks share network infrastructure.
How it works
IoT security operates across four distinct layers, each requiring separate controls:
-
Device hardware layer — Secure boot, hardware security modules (HSMs), tamper-evident enclosures, and trusted platform modules (TPMs) protect against physical compromise and firmware replacement. NIST SP 800-193 covers platform firmware resiliency.
-
Firmware and software layer — Code signing, vulnerability scanning, and Software Bill of Materials (SBOM) practices ensure firmware integrity. NIST SP 800-213 requires that IoT devices support logical access control, software updates, and cybersecurity event logging as minimum capabilities.
-
Network communication layer — Transport Layer Security (TLS) 1.2 or 1.3 for data in transit, network segmentation (placing IoT devices on isolated VLANs), and protocol-specific hardening for MQTT, CoAP, and Zigbee. Network security concepts applied to IoT frequently include micro-segmentation consistent with zero trust architecture principles.
-
Cloud and back-end layer — API authentication, identity and access management for device-to-cloud communication, and encrypted data storage. Cloud-connected IoT systems fall under cloud security fundamentals requirements, including access logging and anomaly detection.
Vulnerability management for IoT differs from enterprise IT because over-the-air (OTA) update mechanisms are inconsistently implemented, and patching often requires coordinated device recalls or manual firmware flashing.
Common scenarios
IoT security failures follow recognizable patterns documented in public disclosures and CISA advisories:
Default credential exploitation — Devices shipped with factory-default usernames and passwords that operators fail to change remain one of the most consistently exploited conditions. The Mirai botnet, documented in 2016, compromised over 600,000 IoT devices using default credentials to launch distributed denial-of-service attacks.
Unencrypted communications — Devices transmitting sensor data or commands over plaintext protocols (HTTP, Telnet, MQTT without TLS) expose operational data to interception on shared or poorly secured network segments.
Supply chain firmware compromise — Third-party components embedded in IoT firmware introduce vulnerabilities traceable to upstream suppliers. Supply chain security frameworks address this through SBOM requirements and vendor attestation.
Medical IoT (IoMT) risks — Connected medical devices — infusion pumps, imaging equipment, patient monitors — are subject to HIPAA cybersecurity requirements and FDA guidance. The FDA's 2023 cybersecurity guidance for premarket submissions requires manufacturers to document device software architecture and provide a plan for patching.
Industrial sensor manipulation — In operational technology environments, compromised IoT sensors can feed false data to control systems, triggering unsafe physical responses. CISA and ICS-CERT publish advisories covering these scenarios under the ICS-CERT advisory program.
Decision boundaries
Practitioners and procurement officers use structured criteria to classify IoT risk and select appropriate controls:
| Factor | Lower risk profile | Higher risk profile |
|---|---|---|
| Network exposure | Air-gapped or VLAN-isolated | Internet-facing, cloud-managed |
| Physical access | Locked facility, monitored | Public or unmonitored locations |
| Data sensitivity | Non-personal operational data | PHI, PII, or process control signals |
| Regulatory scope | No sector-specific mandate | FDA, NERC CIP, HIPAA, FedRAMP |
| Update capability | OTA updates supported | Manual-only or no update path |
Devices that fall into higher-risk classifications across 3 or more of these factors typically require formal cybersecurity risk management assessments under NIST SP 800-30 or equivalent frameworks.
The distinction between consumer IoT and industrial IoT (IIoT) carries compliance implications: consumer devices sold in California trigger SB-327 requirements; IIoT devices in energy infrastructure fall under NERC CIP standards; federal agency deployments must comply with NIST SP 800-213 and the IoT Cybersecurity Improvement Act of 2020 (Public Law 116-207).
Cybersecurity frameworks and standards — particularly the NIST Cybersecurity Framework and NIST SP 800-82 for industrial systems — provide the governance scaffolding within which IoT-specific controls are typically embedded.
References
- NIST SP 800-213: IoT Cybersecurity Guidance for the Federal Government
- NISTIR 8259A: IoT Device Cybersecurity Capability Core Baseline
- NIST SP 800-193: Platform Firmware Resiliency Guidelines
- CISA IoT Security Resources
- FTC — Internet of Things: Privacy and Security in a Connected World
- California SB-327, California Civil Code §1798.91.04
- IoT Cybersecurity Improvement Act of 2020 — Public Law 116-207
- FDA Cybersecurity in Medical Devices Guidance (2023)
- NERC CIP Standards