The number of connected devices worldwide is expected to exceed 18 billion in 2026. Every sensor, camera, PLC, and smart meter that connects to the internet is a potential entry point for attackers. IoT security has become one of the most pressing challenges in enterprise IT — and one of the most frequently underestimated. According to the IoT Security Foundation, organizations must continuously assess technology risks.
Millions of devices ship with default usernames and passwords (admin/admin, root/1234) that users never change. Botnets like Mirai scan the internet continuously for these devices and recruit them within hours of connection.
A 2024 study by Forescout found that 57% of IoT devices had high or critical unpatched vulnerabilities. Many vendors provide no update mechanism; others provide updates that operators never apply.
Many IoT devices still use unencrypted protocols: Modbus, BACnet, Telnet, and HTTP without TLS. Traffic on these protocols can be intercepted, replayed, or manipulated by any attacker with network access.
Threat actors increasingly target the IoT supply chain — inserting malicious code into firmware during manufacturing or distribution. The EU Cyber Resilience Act (in force from 2027) will require hardware manufacturers to sign firmware and maintain a software bill of materials (SBOM).
Once an attacker controls an IoT device, they use it as a beachhead for lateral movement within the network. A compromised smart HVAC controller on the corporate network can be used to reach file servers or Active Directory.
The single most impactful control: put all IoT devices on a dedicated network segment (VLAN) with strict firewall rules. IoT devices should only communicate with their management platform and necessary cloud endpoints.
You cannot secure what you cannot see. Use passive network discovery tools (Claroty, Nozomi Networks, or open-source Zeek) to maintain a live inventory of every connected device.
Every device should receive a unique, strong password before it is connected to any network. Maintain passwords in a privileged access management (PAM) system.
Treat every IoT device as untrusted by default. Use certificate-based mutual TLS (mTLS) for device authentication rather than IP-based trust.
If you are beginning your IoT security program today, prioritize in this order: discover and inventory every connected device, segment IoT onto its own VLAN, change all default credentials, identify devices with end-of-life firmware, and deploy passive monitoring for anomaly detection. Start with these five steps and you will be ahead of the majority of European organizations.
The European Union Agency for Cybersecurity (ENISA) published specific IoT security guidelines that identify the most critical risks facing connected device deployments. The top five threats in enterprise IoT environments are:
The EU Cyber Resilience Act (CRA), entering application in 2027, places mandatory security requirements on connected product manufacturers selling in the EU. Relevant provisions for businesses include: products must ship with unique credentials (no more shared defaults), security updates must be provided for the product’s expected lifetime, and vulnerability disclosure must be transparent.
For businesses purchasing IoT devices: use CRA compliance as a vendor selection criterion now, before 2027 requirements force the issue.
IoT security overlaps with the broader Zero Trust Security framework — network segmentation and device authentication are core Zero Trust principles. For industrial IoT deployments, see Smart Factory 4.0.
For further context, review our Iot coverage and It Cloud resources.
Yes, if employees connect personal smart home devices to home networks used for remote work, or if consumer-grade IoT is installed in office environments without IT review. Establish a bring-your-own-device (BYOD) and IoT policy that covers home office environments for remote workers.
OT (Operational Technology) security covers industrial control systems (ICS), SCADA systems, and industrial equipment — the IT that controls physical processes. IoT security covers connected consumer and commercial devices. The risks converge in industrial IoT (IIoT) environments where OT systems gain internet connectivity, dramatically increasing their attack surface.
IoT security cannot be managed effectively as an extension of traditional IT security. The device diversity, constrained computing resources, and operational technology (OT) integration that characterise IoT environments require a dedicated security framework. The most widely adopted reference architecture for enterprise IoT security is the NIST Cybersecurity Framework, adapted with IoT-specific controls.
Asset inventory is the non-negotiable starting point. You cannot secure devices you do not know exist. Automated discovery tools that passively identify IoT devices on the network — without disrupting sensitive OT systems — are now available from vendors including Claroty, Armis, and Forescout. Maintaining an up-to-date inventory is also a baseline requirement under NIS2 for organisations operating critical infrastructure.
Network segmentation is the most impactful single control for IoT security. Placing IoT devices on dedicated VLANs with strict firewall policies prevents a compromised device from becoming a key point into enterprise systems. Combined with encrypted communications and certificate-based device authentication, segmentation forms the core of a defensible IoT architecture.
The most exploited IoT vulnerabilities are default credentials that were never changed, unencrypted communications between devices and management platforms, lack of firmware update mechanisms, and excessive data collection that creates unnecessary privacy exposure. Many IoT breaches involve devices that were forgotten about — deployed years earlier and never patched, updated, or properly decommissioned. Lifecycle management is as important as initial deployment security.
For organisations operating critical infrastructure or essential services, NIS2 explicitly requires risk management measures that cover OT and IoT systems. This includes asset management, network monitoring, incident detection, and supply chain security for device vendors.
NIS2-obligated organisations should ensure their IoT security controls are documented and auditable, as national supervisory authorities are expected to include OT/IoT security in their inspectio Traditional incident response playbooks are not adequate for IoT security events. When an IoT device is compromised, the response options are often more limited than in standard IT: devices may lack logging capabilities, remote access for forensics may be unavailable, and taking a device offline may have immediate operational consequences in manufacturing or healthcare environments. consequences in manufacturing or healthcare environments.
IoT incident response plans need to address these constraints explicitly. This means defining in advance which devices are critical enough to require manual isolation rather than remote disconnection, what forensic evidence can realistically be collected from constrained devices, and how operational continuity is maintained when a device must be taken offline during an investigation.
Tabletop exercises that simulate IoT-specific scenarios — a compromised building management system, a ransomware attack spreading through OT networks, or a data-exfiltrating device on a factory floor — are increasingly valuable for stress-testing response plans and building cross-team awareness between IT, OT, and physical security teams.
Yes, and increasingly this is considered best practice. Zero-trust principles — verify every device identity, grant least-privilege access, assume breach — are well-suited to IoT environments where device diversity and the presence of legacy equipment make traditional perimeter-based security insufficient. Practical implementation requires IoT-aware identity systems that can handle certificate-based device authentication at scale, which is now available from enterprise vendors including Cisco, Palo Alto Networks, and Zscaler.
Editorial disclosure: AI tools may have assisted research, drafting or editing. ITnovati remains responsible for the published text. Time-sensitive technical, legal and product claims should be checked against the linked primary sources.
ITnovati