IoT security is now a system problem because connected devices directly touch physical processes, operate outside traditional perimeters, and are exposed for years in hostile environments. Securing them demands architectural changes—zero trust, strong device identity, and secure over-the-air (OTA) updates—rather than a late-stage “network filter” feature. Honeywell reported last year that 50% of the attacked vectors were IoT devices with the OT’s network.
From Edge Checkbox to System Risk
In classic IT, you could often add security at the network edge with firewalls and VPNs because most assets sat in a data center. IoT flips this model: devices are dispersed, often physically accessible, and frequently built with minimal protection by default. In manufacturing, healthcare, and smart buildings, compromised IoT devices can now halt production lines, affect patient care, or disrupt building operations, so failures propagate into the real world, not just into log files.
IoT environments also mix legacy OT, modern cloud services, and consumer-grade devices, creating sprawling attack surfaces that no single perimeter control can reliably protect. Unmanaged or unpatched devices become persistent footholds for attackers, making one weak link enough to compromise an entire deployment.
Why Bolted-On Edge Security Fails
Relying on edge security alone assumes that “inside the network” is trustworthy, which breaks down when many IoT devices are reachable over the internet or can be physically tampered with. Cameras, routers, and gateways often sit in public or semi-public spaces, where an attacker can plug in, open a case, or intercept local traffic.
Traditional perimeter models also struggle with the sheer scale and heterogeneity of IoT fleets. Thousands of device types, multiple connectivity stacks (cellular, Wi-Fi, LPWAN, hybrid networks), and different vendors make it difficult to maintain consistent rules at a single choke point. As a result, regulators now push for device-level controls (security-by-design, updateability, secure defaults) rather than accepting perimeter-only mitigations.
Zero Trust as the New Baseline
Zero trust architectures assume no implicit trust based on network location; every device, user, and action must be authenticated, authorized, and continuously evaluated. This model fits IoT because devices are highly distributed, often mobile, and frequently connected over untrusted networks such as public 5G or the open internet.
In practice, zero trust for IoT means:
- Every device must prove its identity using cryptographic credentials, not shared passwords.
- Access is granted per request with least privilege, not broad “inside network” access.
- Device health (firmware version, behavior, location) influences whether access is allowed.
These principles push security into the architecture: into enrollment workflows, policy engines, and runtime telemetry pipelines across IT, OT, and cloud, rather than a single firewall rule set.
Unique Device Identity as the Root of Trust
At the heart of modern IoT security is unique device identity—each device gets its own cryptographic identity (certificate or key pair) that can be verified, managed, and revoked over time. This identity is ideally bound to hardware (secure elements, TPMs, or similar) so it cannot be cloned or easily extracted if someone opens the device.
A strong identity foundation enables:
- Mutual authentication between device and cloud or edge platforms.
- Fine-grained authorization: policies targeted to a single device or group.
- Continuous compliance and automated deprovisioning when devices are retired or compromised.
Vendors and platforms now treat machine identities as first-class citizens, integrating certificate issuance, lifecycle management, and policy enforcement into IoT management stacks.
Secure OTA: Security as an Ongoing Process
Even well-designed devices ship with bugs and will encounter new threats during their lifetime. Secure over-the-air updates are, therefore, a core architectural requirement, not a nice-to-have maintenance feature. Manufacturers and operators need to deliver authenticated, integrity-protected firmware and software updates at scale, often to devices deployed in remote or hard-to-reach locations.
Effective OTA infrastructure must:
- Verify update authenticity (signed firmware, validated by device).
- Protect update channels end-to-end (TLS, mutual authentication).
- Integrate with asset inventory and monitoring so you can see which devices are out of date and remediate them quickly.
Without robust OTA, organizations accumulate technical debt in the form of unpatched devices, which regulators increasingly view as unacceptable given their role in critical services and industrial operations.
Designing Security into the IoT Stack
Treating IoT security as a system property means baking controls into each layer: device hardware, firmware, connectivity, edge platforms, cloud backends, and operational processes. Architectural patterns now emphasize secure boot, hardware-rooted identities, segmented networks, encrypted communications, and continuous monitoring as standard baseline requirements.
This shift is reinforced by evolving standards and regulations, which expect organizations to maintain visibility over all devices, enforce least-privilege access, separate OT from IT, and implement lifecycle management from onboarding through decommissioning. For architects and product leaders, the implication is clear: if you wait to add security at the end, you will fail compliance tests, increase operational risk, and undermine the long-term viability of your IoT strategy.
Conclusion: The Good News Bad News
A distributed security methodology was inevitable. The fact that Zero Trust has emerged as the baseline to success has been a long time coming from an IoT perspective and an imperative once digital wins were adopted on the factory floor.
Based on conversations I have had with friends in the industry, I estimate that zero trust has been adopted by about a third of the industry. I would also say that, from an implementation perspective, we have two problems in deploying zero trust. The first is that the adoption of the security methodology is happening haphazardly. Companies are treating implementations like pilots and having experienced success go to “full implementation” for anything new. This, of course, leaves the legacy systems as a back door to the network. The second problem is the corollary, where IT and OT are still separate systems and security breaches are internally reported but not addressed on an enterprise-wide scale.
While I would advocate for a best practice that looks to retrofit all elements of the network, I am also a realist on the cost implications of such a physical audit. So, I offer this compromise: treat every new system as a chance to audit traffic. Look for leaks and isolate them.
Edited by
Erik Linask
