IoT Security
IoT security is not optional. This guide covers essential practices for enterprise IoT deployments.
Key Metrics
High
Efficiency
99.99%
Reliability
Full
Coverage
3-6 mo
ROI
Why This Matters
Sensors Are the New Attack Surface
An IoT network is the largest expansion of connected devices most organizations will ever make - and most of those devices are tiny computers with limited processing, default credentials, and firmware that may never be updated. A compromised sensor may hold no data of value itself, but it is a foothold: a pivot point into the corporate network, the BAS, or the industrial control system that sits behind it.
The stakes are operational, not just informational. In a smart building, the network carries both sensor telemetry and control commands. An attacker who reaches the control plane can alter setpoints, disable alarms, or mask a safety condition - a fundamentally different risk profile from a laptop breach.
This guide assumes a defense-in-depth posture: no single control is trusted, every device is treated as untrusted until proven otherwise, and the network is designed so that compromise of one segment does not imply compromise of the whole.
Threat Model
How IoT Gets Compromised
Many field devices ship with known factory passwords. Attackers scan the internet for exactly these devices.
Embedded devices run unpatched Linux or RTOS with known CVEs for years because no update process exists.
Sensors, servers, and control systems on one segment let lateral movement reach the crown jewels from any device.
Legacy Modbus, BACnet, and plain MQTT carry credentials and control commands without authentication or encryption.
Teams deploy sensors without IT approval, bypassing segmentation, patching, and monitoring altogether.
Deep Dive
Network Segmentation: The Primary Control
Segmentation is the single most effective measure for IoT because it contains the damage a compromised device can do. The principle is simple: sensors and controllers live on dedicated VLANs, communicate with the rest of the network only through governed gateways, and cannot initiate connections to the corporate LAN at all.
Zone 1
Sensors and field devices - only speak to their own gateway; internet access denied by default
Zone 2
Gateways and edge processors - the only devices that translate between field protocols and the enterprise
Zone 3
Applications and users - access through authenticated APIs, never direct to field devices
Beyond VLANs, segmentation is enforced with firewall rules that are deny-by-default, micro-segmentation between individual gateways, and east-west traffic inspection that detects a sensor beaconing to an unexpected host. Zero-trust extends the same logic to every device-to-device relationship.
Deep Dive
Device Identity and Encryption
Every device needs an identity that cannot be guessed and a credential that cannot be shared. Shared passwords across a sensor fleet mean one stolen credential authenticates every device. The standard answer is certificate-based identity: each device holds a unique certificate from the organization's PKI, provisioned at commissioning and revoked on decommission.
Encryption covers both states of data. In transit, TLS 1.2 or newer for IP-based protocols, and transport-layer encryption or secure tunneling for legacy field protocols. At rest, the platform database encrypts readings and credentials with AES-256. Key rotation - not just issuance - is what keeps long-lived device certificates from becoming liabilities.
Deep Dive
Firmware Lifecycle Management
A device you cannot update is a standing risk you cannot remediate. Over-the-air (OTA) update pipelines should be automated, signed, and rollback-capable: signed so a compromised distribution point cannot push malicious firmware, and rollback-capable so a bad release can be reverted without a site visit.
The practical discipline is an inventory that ties every device to its firmware version, a patch cadence that treats critical CVEs as mandatory, and a decommissioning process that revokes certificates and removes credentials when devices are retired. Firmware entropy is what turns an aging sensor fleet from an operational cost into a security incident.
Compliance
Frameworks That Codify IoT Security
| Framework | Focus | Relevant Requirement |
|---|---|---|
| IEC 62443 | Industrial automation and control systems | Zones and conduits, device hardening, secure lifecycle |
| NIST SP 800-82 | Industrial control system security | Network architecture, identity, access, and monitoring for OT |
| NIST CSF 2.0 | General organizational cybersecurity | Govern, identify, protect, detect, respond, recover |
| ISO/IEC 27001 | Information security management systems | Risk treatment, asset management, supplier security |
| EN 18031 | Radio equipment cybersecurity (EU) | Secure default config, password handling, protection against attacks |
Best Practices
The IoT Security Baseline
Minimum Controls for Every Deployment
- Change every default credential at commissioning; maintain a zero-default-password policy
- Put every sensor on a dedicated segment with deny-by-default firewall rules
- Issue unique device certificates and enforce an automated rotation and revocation process
- Encrypt all traffic in transit (TLS 1.2+) and data at rest (AES-256)
- Maintain an OTA firmware pipeline with signed images and rollback capability
- Monitor east-west traffic and alert on any device communicating outside its expected pattern
- Enforce least-privilege RBAC with MFA for every admin and operator account
- Document a decommissioning process that revokes identity and wipes credentials
Secure Your IoT Deployment
Get our security team to review your architecture against the controls in this checklist.
Get Started