IoT Security Guide

Most organisations run more connected devices than they can name, and many of those devices ship with weak credentials, no update path and a direct route to the internet. Cameras, door controllers, printers, building sensors, smart TVs and vending machines sit on corporate networks outside endpoint agents and patch tooling, and they are the raw material for botnets. This guide covers IoT threats and attack surface, wireless and messaging protocols, inventory, segmentation and network access control, device identity, firmware updates and vulnerability disclosure, testing, and the UK, EU and US rules that now apply to manufacturers. It is written for security architects, network and facilities teams, and product security teams buying or building connected devices.

Key takeaways

• You cannot secure what you have not found. Passive discovery and classification of every connected device is the first control, because most IoT cannot run an agent.
• Default and shared credentials are still the main way in. UK law has banned universal default passwords on consumer connectable products since 29 April 2024, but older and enterprise devices still carry them.
• Segmentation does the work devices cannot. Put devices in their own zones, allow only the flows they need and admit them through network access control.
• The support period is a security requirement. Buy devices with signed updates, a published end of support and a vulnerability disclosure route, and retire them when support ends.
• Every device needs its own identity. Unique certificates or credentials per device, not shared secrets or API keys baked into firmware, make revocation and attribution possible.

Consumer IoT, enterprise IoT and IIoT

IIoT shares the device problems below but sits inside control system architecture. See the OT Security Guide for the Purdue model and zones and conduits, and the Medical Device Security Guide and Automotive Cybersecurity Guide for regulated device sectors.

IoT attack surface and threats

An IoT product is a system: the device, its radio links, a gateway or hub, a vendor cloud and a mobile app. The OWASP IoT Top 10 (2018) is still the most widely used checklist of where these systems fail.

Botnets and the Mirai lesson

Mirai, analysed in "Understanding the Mirai Botnet" (USENIX Security 2017), grew to a peak of about 600,000 infections of a botnet "composed primarily of embedded and IoT devices" and launched massive DDoS attacks in late 2016. At a high level it spread by scanning the internet for devices that accepted remote log-in with factory default credentials; its source code was later published and spawned many variants. In ATT&CK terms the entry is T1078.001 Valid Accounts: Default Accounts and the payoff is T1498 Network Denial of Service. The lesson still holds: devices with internet-reachable management services and default credentials are found and enlisted quickly. Compromised devices are also used as residential proxies and as footholds for lateral movement. See the Lateral Movement Guide.

Protocols and their security features

For Wi-Fi devices, use WPA3 or at least WPA2 with a dedicated SSID per device class. See the Wi-Fi Security Guide and the Network Ports and Protocols Security Guide.

Device inventory and classification

• Discover passively first: DHCP fingerprints, switch MAC tables, LLDP and CDP, mDNS and SSDP announcements, and NetFlow reveal devices without touching them. Active scanning of fragile devices should be gentle and scheduled.
• Classify by function and risk: manufacturer, model, firmware version, owner, location, data handled, internet dependence and end-of-support date. A camera in a car park and a badge reader on a data centre door are both "IoT" but carry very different risk.
• Find the owner: facilities and business teams buy most IoT. Every device class needs a named owner who approves updates, access and decommissioning.
• Watch the external view: check internet-facing exposure of device management interfaces from outside. See the Attack Surface Management Guide.
• Track SIMs and cloud tenants: cellular devices and vendor cloud accounts are part of the inventory even when nothing appears on the LAN.

Network segmentation and network access control

• Zone by device class: separate VLANs or VRFs for cameras, building systems, printers, conferencing and guest or consumer devices, with default-deny firewall rules between zones. See the Network Segmentation Guide.
• Allow only required flows: a camera needs its recorder and perhaps its vendor update service, not the internet at large or the user network. Build allowlists from observed traffic, then enforce.
• Admit devices through NAC: use 802.1X with certificates where devices support it; for the many that do not, MAC Authentication Bypass (MAB) combined with profiling, which is weaker because MAC addresses can be spoofed. Place unknown devices in a quarantine VLAN. See the Network Access Control (NAC) Guide.
• Harden gateways and hubs: a Zigbee, LoRaWAN or Thread border gateway bridges radio meshes to IP networks, so treat it as a boundary device: patched, admin access restricted to a management network, and only the uplinks it needs.
• Block legacy management: deny Telnet, unencrypted HTTP management and UPnP at zone boundaries, and never port-forward device management to the internet.
• Broker vendor remote access: route vendor support through a managed remote access gateway with named accounts and session recording, not device-level cloud tunnels nobody monitors.

Where identity fits

A device on the network is a non-human identity. Shared credentials make it impossible to tell one device from another, to revoke one without touching thousands, or to attribute activity.

• Unique credentials per device: the UK PSTI regulations require passwords to be unique per product or defined by the user, and forbid ones based on incremental counters, public information or serial numbers unless protected. Apply the same rule to enterprise kit through procurement.
• Certificates over passwords: factory-installed device identities (IEEE 802.1AR DevID is the common model) let a device prove what it is to NAC and to the vendor cloud. Matter does this for smart home devices: each product carries a Device Attestation Certificate unique to the device, chained to a Product Attestation Authority listed in the Connectivity Standards Alliance's Distributed Compliance Ledger, and commissioners validate the chain including revocation checks. See the Device and IoT Identity Guide.
• Manage certificate lifecycle: enrol operational certificates from your own CA, track expiry and revoke on decommissioning. See the Machine Identity, PKI and Certificate Lifecycle Guide.
• No secrets in firmware: hard-coded API keys and admin passwords are extracted and reused at scale, as the Rabbit R1 hard-coded API keys exposure and the HPE Aruba Instant On hard-coded credentials flaw showed. See the Secrets Management Guide.
• Protect the management plane: vendor cloud consoles and device management platforms control every device at once; give them phishing-resistant MFA, named admins and API keys scoped and rotated like any other privileged credential.

Firmware updates and vulnerability disclosure

• Signed, verified updates: updates should be cryptographically signed, verified by the device before installation and protected against rollback to vulnerable versions, ideally anchored in secure boot. See the Firmware and Boot Security Guide.
• Know the support period: ETSI EN 303 645 provision 5.3-13 and UK PSTI both require manufacturers to publish the defined support period. Record it in the inventory and plan replacement before it ends.
• Patch on a schedule you control: stage updates on a pilot group of each model, confirm function, then roll out by zone. Keep the previous firmware image and configuration backup for rollback where the device allows it. See the Patch Management Guide.
• Ask for an SBOM: component lists let you answer "are we affected?" when a library flaw is announced. See the Vulnerability Management Guide.
• Disclosure route: manufacturers must publish a contact point and timelines for acknowledgement and status updates (ETSI 5.2-1, PSTI Schedule 1 paragraph 2). If you build devices, run a vulnerability disclosure policy aligned to ISO/IEC 29147.
• Compensate when updates are impossible: isolate the device tightly, restrict it to known peers, monitor it and set a retirement date.

Regulation and certification

Under the CRA, manufacturers must also set a support period of at least five years unless the product is expected to be used for less. Products placed on the Northern Ireland market follow the RED delegated act and are excepted from PSTI. See the Global Cybersecurity Regulatory Map.

Buying and testing devices

Procurement decisions

• Small organisations: buy from manufacturers that publish a support period and disclosure policy, put all IoT on a separate SSID or VLAN with internet-only access, and change every credential at install.
• Large organisations: write requirements into contracts: SP 800-213 device capabilities, 802.1X and certificate support, local management without mandatory vendor cloud, SBOM, signed updates and a support period longer than the planned service life.
• Cloud-dependent versus local: choose locally managed devices where data sensitivity or availability matters; choose cloud-managed fleets when you lack staff to patch, then govern the vendor's console as a privileged system.

IoT penetration testing scope

A useful assessment covers every layer: hardware (debug interfaces, storage, tamper resistance), firmware (extracted image analysis for secrets and outdated components), radio (pairing and joining), network services, the cloud API and the mobile app. Test production-equivalent units in a lab, not live devices on a plant or building network, and require findings to be retested after fixes.

Rolling out an IoT security programme

1. Discover: run passive discovery across all sites for four weeks and reconcile against purchase and facilities records.
2. Triage: fix internet-exposed management interfaces and default credentials first; these are what botnets find.
3. Design zones: define device classes, zones and allowed flows; build rules from observed traffic.
4. Enforce in monitor mode: apply NAC profiling and firewall rules in log-only mode for two to four weeks, review would-be blocks with device owners, then enforce one zone and site at a time. Keep the previous policy version ready to restore if a critical device fails.
5. Move to device identity: enrol certificates for devices that support 802.1X; tighten MAB profiles for the rest.
6. Bring updates into process: owners, pilot groups, maintenance windows and end-of-support dates for each model.
7. Govern procurement: no new device class joins the network without a security review against the agreed baseline.

Detection and measurement

What to monitor: new or unprofiled devices; devices talking outside their allowlisted peers; outbound connections to unusual countries or on unusual ports; spikes in outbound traffic volume (a sign of DDoS participation); failed and successful log-ins to device management interfaces; firmware version changes outside maintenance windows; and certificate expiry. Use flow data and NAC logs, since most devices cannot run an agent. See the SIEM Guide.

Common failure patterns

• Treating the vendor cloud as somebody else's problem: in the Verkada camera breach, admin credentials on an exposed support server opened customer cameras. The management plane is part of your attack surface.
• Flat networks: a compromised camera or smart TV can reach servers and user devices because nobody segmented it.
• Hard-coded and shared secrets: one extracted password or key works on every unit of a model, so a single disclosure becomes a fleet compromise.
• Network devices left unmanaged: long-lived credentials and secrets on routers and edge devices kept attackers inside for years in the Salt Typhoon telecom intrusions.
• Ignoring end of support: devices keep working long after the last update, so they stay connected with known, unfixable flaws.

Framework mapping

Practitioner checklist

• Run passive discovery on every site and give each device class a named owner and an end-of-support date.
• Remove internet exposure of device management interfaces and close Telnet and UPnP at zone boundaries.
• Replace every default or shared credential with unique per-device credentials or certificates.
• Place IoT in dedicated zones with default-deny rules and allowlisted flows.
• Admit devices through NAC: 802.1X with certificates where supported, profiled MAB with quarantine otherwise.
• Require signed updates, an SBOM, a published support period and a disclosure policy in every IoT purchase.
• Pilot firmware updates per model, keep rollback images and track time to deploy critical fixes.
• Protect vendor cloud consoles and device management platforms with phishing-resistant MFA and scoped API keys.
• Monitor flows, NAC events and management log-ins for devices acting outside their profile.
• Map products you sell or import against PSTI, the CRA timetable and the RED delegated act.

Standards and references

• legislation.gov.uk: The Product Security and Telecommunications Infrastructure (Security Requirements for Relevant Connectable Products) Regulations 2023
• ETSI: EN 303 645 Cyber Security for Consumer Internet of Things: Baseline Requirements
• European Commission: Cyber Resilience Act
• GOV.UK: Regulation (EU) 2022/30 factsheet
• FCC: Public Notice DA 26-834 on Cybersecurity Label Administrators
• NIST: IR 8259A IoT Device Cybersecurity Capability Core Baseline
• NIST: SP 800-213 IoT Device Cybersecurity Guidance for the Federal Government
• OWASP: Internet of Things Project

Related NHI Mgmt Group resources: Device and IoT Identity Guide · OT Security Guide · Machine Identity, PKI and Certificate Lifecycle Guide · Network Segmentation Guide · Network Access Control (NAC) Guide