The Conventional Wisdom
Many security leaders treat IoT security like traditional IT security, using patch management, network segmentation, endpoint protection, and access controls. They add "IoT" to their asset inventory and assume it's secure. If it connects to your network, it's just another endpoint, right?
This mindset has dominated since connected devices began proliferating. You've likely seen it: IoT devices are lumped into the same policies and governance structures as laptops and servers. They're treated as IT assets with different form factors.
Why We Disagree
This approach misunderstands what makes IoT unique, leading to challenges that traditional IT security doesn't face.
NIST has highlighted these differences since its Cybersecurity for IoT Program began in 2017. Their work, especially NISTIR 8228, shows IoT products operate under constraints that traditional IT doesn't: limited computational resources, specialized operating systems, long operational lifespans, and direct physical impact when things go wrong.
Treating IoT like IT turns security into a paperwork exercise, not reflecting operational reality. You're retrofitting frameworks meant for enterprise computing onto devices controlling manufacturing lines, building systems, and medical equipment. The result? Security becomes an added burden, with compliance artifacts that don't match how these systems work or fail.
The Evidence
Here's what happens when you apply traditional IT controls to IoT:
Patch management fails. IT patch cycles assume you can reboot systems during maintenance windows and roll back if needed. Industrial IoT controlling a manufacturing line can't go down for patches without affecting production. Medical devices need FDA validation before firmware updates. Building systems often run on proprietary protocols updated on the manufacturer's timeline, not yours.
Network segmentation differs. Traditional IT assumes logical segmentation is possible. IoT devices often need physical access to operational technology networks, direct cloud connections for telemetry, and integration with legacy systems. Your zero-trust model doesn't account for a 15-year-old HVAC controller needing internet access for diagnostics.
Asset inventory becomes fiction. Your CMDB tracks IT assets through procurement. IoT devices appear embedded in equipment bought for other purposes, connect through cellular modems you didn't provision, and operate on networks you don't control. The facilities team deployed 200 smart sensors last quarter without informing IT.
NIST's updates to NISTIR 8259 and SP 800-213 acknowledge this. They're moving toward context-based approaches that secure IoT products based on their actual use case and environment, not IT-centric frameworks.
What to Do Instead
Recognize that IoT security needs different governance structures, not just technical controls.
Build context-specific risk models. Categorize IoT devices by operational context: What happens if this device fails or is compromised? Does it affect physical safety, operational continuity, data confidentiality, or all three? A compromised badge reader has different implications than a compromised industrial robot.
Integrate with operational stakeholders. Your facilities, manufacturing, and clinical engineering teams manage these systems. They understand operational constraints, maintenance windows, and failure modes. Security requirements should fit their reality, not replace it. Establish joint governance structures where security and operations make trade-offs together.
Focus on manufacturer accountability. Unlike IT, where you control the full stack, IoT security relies on manufacturer capabilities. Set procurement requirements addressing secure development practices, vulnerability disclosure processes, and support lifecycles. Reference NIST SP 800-213 when writing RFPs for IoT products.
Accept human-in-the-loop is permanent. IoT systems will always need human decision-making due to their physical context and safety implications. Your security program needs processes for operational decision-making, not just automated controls. Document who decides when a critical vulnerability affects a production system that can't be patched immediately.
Separate compliance from operational security. Stop mapping IoT security to IT frameworks. Create lightweight, context-specific documentation reflecting how these systems work. If implementing NIST CSF for IoT, customize the implementation tiers and profiles for operational technology instead of forcing IT-centric interpretations.
When the Conventional Wisdom Is Right
Traditional IT security approaches apply in specific IoT contexts. Don't overcorrect.
If your IoT deployment is mainly enterprise IT with sensors, standard controls work. Employee wearables, smart conference room systems, and network-connected office equipment can follow existing endpoint management processes.
When you control the full deployment environment and can enforce technical controls, treat it like IT. Cloud-connected IoT applications you develop in-house should follow your secure development lifecycle, use your identity providers, and integrate with your SIEM.
For data-focused IoT deployments where physical impact isn't a concern, IT-centric frameworks make sense. Analytics platforms collecting telemetry from distributed sensors can follow your data governance and privacy controls without operational constraints.
The key is knowing when you're working within IT's model versus securing systems with network connectivity but different constraints. NIST's evolving guidance reflects this nuance, but only if you stop forcing IoT into IT boxes that don't fit.
Your security program needs both approaches. Just know which one you're applying, and why.
