Internet of Things (IoT) security — SY0-701

WHAT IT IS

The Internet of Things (IoT) is "the network of devices that contain the hardware, software, firmware, and actuators which allow the devices to connect, interact, and freely exchange data and information." (NIST SP 800-172r3.) An IoT device specifically is a device with "at least one transducer (sensor or actuator) for interacting directly with the physical world and at least one network interface (e.g., Ethernet, Wi-Fi, Bluetooth) for interfacing with the digital world." (NISTIR 8425.)

IoT security is the practice of applying controls appropriate to these device characteristics within a larger security architecture.

Mental model

Think of an IoT device as a small, purpose-built computer that cannot easily be patched, cannot authenticate itself the way a workstation can, and sits on the same network as high-value systems unless the architecture explicitly separates it. Every security decision for IoT flows from that constraint: the device itself may be hard or impossible to harden, so the architecture has to compensate.

The core architectural tension:

• The device boundary — what the device can enforce on its own (limited by hardware, firmware, and lifecycle)
• The network boundary — what the surrounding architecture must enforce on the device's behalf

When to use it

Use IoT-specific controls whenever a networked device has a transducer (sensor or actuator) touching the physical world and limited ability to run conventional endpoint security software. The following table shows how IoT differs from conventional endpoints across the properties that matter most for architecture decisions:

Property	Conventional endpoint	IoT device
Patch lifecycle	OS vendor provides regular updates; administrator deploys them	Vendor update cadence is often slow, irregular, or ends at end-of-sale; device may lack an update mechanism
Authentication capability	Supports strong, multi-factor authentication natively	Often ships with default credentials; hardware may not support complex authentication schemes
Attack surface	Large but well-understood; antivirus and EDR tools apply	Attack surface includes physical interfaces and firmware in addition to network interfaces (NIST SP 800-53 Rev. 5 definition: "the set of points on the boundary of a system … where an attacker can try to enter, cause an effect on, or extract data from")
Firmware	Software stored in read-only or programmable memory, not dynamically writable during execution (NIST SP 800-53 Rev. 5)	Firmware is often the primary attack target; updates require physical or privileged network access
Isolation capability	Can run host-based firewall, EDR, VPN agent	Generally cannot; isolation must come from network architecture

Network isolation is the primary compensating control. Because IoT devices often cannot enforce least privilege themselves — "the principle that a security architecture is designed so that each entity is granted the minimum system resources and authorizations that the entity needs to perform its function" (NIST SP 800-53 Rev. 5) — the architecture places them in a dedicated network segment where access to and from other segments is tightly controlled.

COMMON MISCONCEPTION

The exam exploits the assumption that changing default credentials is sufficient to secure an IoT device.

Default credentials are one problem, but the deeper architectural issue is that even a device with a strong password still:

• May carry vulnerabilities — "weakness[es] in an information system, system security procedures, internal controls, or implementation that could be exploited or triggered by a threat source" (NIST SP 800-30 Rev. 1) — in firmware that cannot be patched
• Expands the attack surface across every network interface and physical port, not just the management credential
• Cannot benefit from patch management — "the systematic notification, identification, deployment, installation, and verification of operating system and application software code revisions" (CNSSI 4009-2015) — if the vendor does not provide updates

Changing default credentials is necessary but does not address the firmware vulnerability lifecycle, the lack of isolation, or the absence of a patch process. The architectural response — placing IoT devices in an isolated network segment and controlling what traffic crosses that boundary — addresses all three.

How it shows up on the exam

Questions in this area target analysis and application: given a scenario involving networked devices with physical-world interaction (building controls, medical sensors, industrial controllers, consumer appliances), candidates are asked to identify the most appropriate architectural control.

Candidates often confuse a credential-focused control (changing a password) with an architectural control (network isolation), or confuse a device-level control with a compensating control that the architecture must provide when the device cannot enforce it directly. Watch for scenarios where a device "cannot be patched" or "uses default firmware" — these are signals that the answer involves the surrounding architecture, not the device itself.

Grounding note: The authentication definition from FIPS 200 — "verifying the identity of a user, process, or device, often as a prerequisite to allowing access to resources in an information system" — makes clear that authentication is a prerequisite to access, not a substitute for isolation or vulnerability management. A device that is authenticated but unpatched and fully reachable from other network segments is still architecturally exposed.

Related concepts

• Cloud Architecture Models
• Shared Responsibility Model
• Infrastructure as Code