IoT Device Security: Lessons from the Iranian Camera Hack

In March 2026, Check Point researchers documented something that should make every CISO with IP cameras on their network pause. Iranian state actors exploited five known vulnerabilities in Hikvision and Dahua security cameras across Israel, the UAE, Qatar, Bahrain, Kuwait, Lebanon, and Cyprus. The attacks weren't random. They were timed to coincide with Iranian missile and drone strikes, turning surveillance cameras into real-time reconnaissance tools for kinetic military operations.

The technical details matter: CVE-2021-36260 (command injection in Hikvision web servers), CVE-2021-33044 (authentication bypass in Dahua products), CVE-2017-7921 (improper authentication in Hikvision firmware), CVE-2023-6895 (OS command injection in Hikvision Intercom), and CVE-2025-34067 (unauthenticated RCE in Hikvision's iSecure Center platform via Fastjson deserialization). Five CVEs. Two vendors. Hundreds of compromise attempts. And here's the part that keeps me up at night: every one of these cameras was sitting on a network that someone believed was secured.

I've talked to dozens of CISOs over the past year about IoT device security, and the conversation almost always starts the same way. They know their cameras, badge readers, HVAC controllers, and infusion pumps are a problem. They just don't have a practical way to solve it. This attack is a case study in why that gap is so dangerous, and what the path forward actually looks like.

Why IoT Cameras Are Perfect Pivot Points for Lateral Movement

The Iranian campaign targeted cameras specifically, and that choice wasn't accidental. Security cameras (and IoT devices broadly) share a set of characteristics that make them ideal entry points for lateral movement techniques attackers use to traverse corporate networks.

Hardcoded and default credentials. Despite years of advisories, a staggering number of deployed cameras still run factory credentials. CVE-2017-7921 and CVE-2021-33044 both exploit authentication weaknesses that have persisted across firmware generations. In many organizations, nobody owns the credential lifecycle for these devices. IT assumes facilities handles it. Facilities assumes IT handles it. Nobody handles it.

No endpoint agent capability. These devices run stripped-down embedded Linux or RTOS. There's no mechanism to install an EDR agent, no way to push security updates through standard patch management tools. They're black boxes with IP addresses.

Overpermissive east-west access. This is the big one. Most cameras sit on a "security" or "facilities" VLAN with broad access to other network segments. They need to reach a video management system (VMS), maybe cloud storage, and a handful of management interfaces. Instead, they can often reach everything. Once an attacker gains code execution on a camera (which CVE-2021-36260 and CVE-2025-34067 provide), that overpermissive access becomes a highway into your corporate network.

Long deployment lifecycles. Cameras get installed and forgotten. I've seen Hikvision cameras running firmware from 2018 on networks that otherwise maintain rigorous patching schedules. The device works, the video feeds flow, and nobody touches it until it physically fails. That's seven or eight years of accumulated vulnerabilities sitting at the network edge.

Why Standard Defenses Fail Against IoT Security Threats

Here's the uncomfortable truth about IoT device security. The defenses most organizations rely on today were designed for a world where every device on the network was a managed Windows endpoint. That world hasn't existed for a decade, but the security architecture hasn't caught up. Let me walk through each failure mode specifically.

VLANs: Flat segmentation, static trust

According to Omdia's Enterprise Microsegmentation Adoption Survey (352 enterprise respondents, Q3 2025), commissioned by Elisity, 53% of organizations still rely on VLANs as their primary segmentation approach. VLANs create broad zones, not granular controls. Every device on the "camera VLAN" can talk to every other device on that VLAN. Once an attacker compromises one camera, they can scan and pivot to every other device in that segment. VLANs also require manual maintenance. Every time you add a camera, move a switch port, or reconfigure a building's network, someone has to update VLAN assignments. At scale, this breaks down fast.

ACLs: Complexity that defeats itself

49% of organizations use ACLs for segmentation (Omdia 2025). ACLs can technically achieve granular control, but the operational reality is brutal. A mid-size hospital with 5,000 IoT devices would need tens of thousands of ACL rules, manually written and maintained across dozens of switches. Nobody does this well. The rules accumulate, become contradictory, and eventually someone adds an "any-any" rule to fix a connectivity issue. That rule never gets removed. The segmentation is effectively gone.

NAC: Built for laptops, not cameras

Network Access Control was designed to answer the question: "Is this laptop allowed on the network?" It authenticates users via 802.1X, checks for endpoint compliance (antivirus installed, patches current), and grants or denies access. IoT cameras don't support 802.1X. They can't run compliance agents. Most NAC solutions fall back to MAC-based authentication for IoT devices, which provides almost zero security. MAC addresses are trivially spoofable, and MAC-auth doesn't enforce any ongoing behavioral policy.

Firewalls: The wrong chokepoint

Firewalls enforce policy at network boundaries, north-south traffic between zones. But the Iranian camera attack is an east-west problem. Once the attacker is on the camera (which sits inside your perimeter), the firewall never sees the lateral movement traffic. You'd need to hairpin every device-to-device communication through a firewall, which creates performance bottlenecks, management nightmares, and still doesn't scale to per-device policy.

Only 24% of organizations have adopted microsegmentation, according to Omdia's research. That means three-quarters of enterprises are relying on tools that fundamentally cannot contain an IoT device compromise.

The Lateral Movement Chain: How Camera Compromises Escalate

Effective IoT device security requires understanding how these attacks unfold. Let me map what the Iranian campaign (and campaigns like it) look like through the lens of real-world lateral movement attacks and MITRE ATT&CK techniques. Understanding this chain is critical for knowing where your defenses need to intervene.

Initial Access (T1190: Exploit Public-Facing Application). The attacker scans for internet-exposed cameras and exploits one of the five CVEs identified by Check Point. They now have code execution on an embedded Linux device inside your network.

Discovery (T1046: Network Service Scanning). From the compromised camera, the attacker scans the local subnet and adjacent VLANs. They're mapping your internal network topology using a device you probably forgot was there.

Lateral Movement (T1021: Remote Services). The attacker uses discovered services (SSH, SMB, RDP, web management interfaces) to pivot from the camera to higher-value targets. This is where overpermissive east-west access becomes catastrophic.

Lateral Tool Transfer (T1570). The attacker stages tools on the compromised camera and transfers them to newly compromised hosts. The camera becomes a persistent beachhead, a staging server that no EDR agent is monitoring. This is the core IoT security failure: the device is invisible to your detection stack.

Collection and Exfiltration. From higher-value systems reached via lateral movement, the attacker accesses sensitive data, intellectual property, or (in the Iranian case) real-time video feeds used to support kinetic operations.

The entire chain can execute in minutes. CrowdStrike's 2026 Global Threat Report puts average eCrime breakout time at 29 minutes, with the fastest observed at 27 seconds. Your response window is measured in minutes, not hours.

Why "Just Install an Agent" Is Architecturally Impossible for IoT

I hear this suggestion in almost every security architecture review. "Can't we just put an agent on these devices?" The short answer is no, and it's worth understanding why, because it shapes the entire solution strategy.

IoT devices like cameras run purpose-built firmware on resource-constrained hardware. A Hikvision camera doesn't have spare CPU cycles, memory, or storage for a security agent. The firmware is signed and locked. Even if you could somehow sideload an agent, you'd void the warranty, break the firmware update path, and likely destabilize the device. This isn't a temporary limitation. It's a fundamental architectural constraint of embedded systems, from cameras and badge readers to medical infusion pumps and manufacturing PLCs. Any serious approach to IoT device security must account for this reality.

The numbers bear this out. Based on Elisity's analysis of enterprise network environments, an estimated 50-70% of devices on a typical enterprise network cannot support traditional security agents. Omdia's research found that agent-based segmentation is used by only 12% of organizations, precisely because it doesn't work for the devices that need protection most. You need a security model that works without touching the endpoint.

Identity-Based Microsegmentation: A Practical Framework for IoT Device Security

So if VLANs are too coarse, ACLs don't scale, NAC can't see IoT, firewalls miss east-west traffic, and agents are architecturally impossible, what actually works? The answer that's emerging across the industry is identity-based microsegmentation, and 69% of security leaders in Omdia's survey identified it as the most desirable approach for how network segmentation stops lateral movement.

Here's how the framework operates in practice.

Step 1: Continuous asset discovery and classification

You can't protect what you can't see. The foundation is passively identifying every device on the network: not just the managed endpoints your CMDB knows about, but the cameras, sensors, controllers, and medical devices that were never inventoried. Identity is built from multiple signals (MAC address, DHCP fingerprint, traffic behavior, device type, manufacturer, firmware version) to create a rich identity profile without requiring any agent.

Step 2: Policy based on identity, not network location

Instead of writing rules based on IP addresses and VLAN memberships (which change constantly), you write policy based on what a device is. "Hikvision cameras can communicate with the VMS server on ports 554 and 80, and nothing else." That policy follows the device regardless of which switch port it's on or which building it's in. Write the policy once for a device class, and it applies everywhere.

Step 3: Enforcement at the network edge, not the endpoint

Since you can't put agents on IoT devices, enforcement has to happen in the infrastructure itself, at the switch port or access point where the device connects. Modern approaches use the existing network switches (the ones you already own) to enforce per-device, per-flow policy. No new hardware. No forklift upgrades. No agents. The network becomes the enforcement point.

Step 4: Continuous verification

Identity doesn't stop at initial authentication. The system continuously monitors device behavior and re-evaluates trust. If a camera that normally sends RTSP video streams suddenly starts scanning the network or attempting SSH connections, that behavioral anomaly triggers policy enforcement immediately. This is where you catch the attacker at the discovery phase (T1046), before lateral movement begins.

Elisity's approach to identity-based microsegmentation follows this framework, using the IdentityGraph engine for asset intelligence and Virtual Edge for policy enforcement through existing network infrastructure. But the architectural principles apply regardless of which vendor you choose. The critical shift is moving from network-centric segmentation to identity-centric segmentation.

What Identity-Based Microsegmentation Won't Solve

To be fair, identity-based microsegmentation isn't a magic bullet. Organizations considering this approach should understand several realities.

Policy development takes effort. You need to understand what legitimate communication patterns look like before you can write restrictive policies. This means running in monitoring mode first, observing traffic flows, and building policies incrementally. Rushing to enforcement without understanding baseline behavior will break things.

Legacy network infrastructure matters. Not every switch supports the protocols needed for dynamic policy enforcement. Organizations running very old switching infrastructure may need selective upgrades at critical enforcement points. Most modern enterprise switches (last 5-7 years) support what's needed, but it's worth validating.

It's not a replacement for patching. Microsegmentation contains the blast radius of a compromised device, but it doesn't fix the vulnerability. You still need to patch what you can, replace what you can't, and use segmentation as the containment layer for the inevitable gaps. The Iranian campaign exploited CVEs dating back to 2017. Segmentation limits what an attacker can do after exploitation, but the best outcome is never being exploited in the first place.

Organizational alignment is required. IoT devices span IT, OT, facilities, and biomedical engineering. Effective segmentation requires collaboration across these teams. The technology is the easy part. The organizational coordination is where most programs stall.

Looking Forward: IoT Device Security as a Board-Level Priority

The Iranian camera campaign isn't an outlier. It's a preview. As the Dragos 2026 report documents, threat actors are moving beyond pre-positioning into actively mapping control loops and understanding how to manipulate physical processes. The convergence of cyber and physical operations (cameras guiding missile strikes) is the new reality for industrial network security and critical infrastructure.

The organizations that will weather this shift are the ones treating IoT device security as an architectural challenge, not a patching problem. That means moving past VLANs and ACLs toward identity-based segmentation that can block lateral movement with microsegmentation at the speed attackers actually operate. Twenty-nine minutes is your window. In many cases, it's less.

The good news is that the technology to enforce per-device, per-flow policy at scale already exists. It works with infrastructure you already own, doesn't require agents on endpoints, and avoids the operational drag that killed earlier segmentation efforts. The question isn't whether to adopt this model. It's whether you do it before or after your cameras become someone else's reconnaissance platform.

Frequently asked questions about IoT device security

How can IoT devices be used for lateral movement in a cyberattack?

IoT devices like cameras run embedded operating systems that give attackers code execution once compromised. The Iranian campaign exploited five CVEs in Hikvision and Dahua cameras to gain initial access, then used the devices' network connectivity to scan adjacent systems and pivot to higher-value targets. Because IoT devices typically have overpermissive network access and no endpoint detection, they serve as unmonitored beachheads for discovery (MITRE T1046), remote service exploitation (T1021), and lateral tool transfer (T1570). The growing list of real-world lateral movement attacks increasingly involves IoT devices as initial pivot points.

Why can't you install security agents on IoT devices like cameras?

IoT devices run purpose-built firmware on resource-constrained hardware with limited CPU, memory, and storage. They lack general-purpose operating systems that support third-party software. Firmware is signed and locked by the manufacturer, and sideloading agents voids warranties and destabilizes operation. This applies across cameras, badge readers, medical devices, and industrial controllers. Omdia's 2025 research found that only 12% of organizations use agent-based segmentation, largely because 50-70% of enterprise devices cannot support agents.

What is the best way to secure IoT devices on a corporate network?

The most effective approach combines three elements: comprehensive asset discovery (you can't protect what you can't see), identity-based policy (rules tied to what a device is, not where it sits), and enforcement at the network edge rather than on the endpoint. A camera should only reach its video management server. A badge reader should only reach its access control system. Everything else gets denied by default. This works without agents, scales across thousands of devices, and adapts automatically as devices move or topology changes.

How does microsegmentation prevent IoT device attacks from spreading?

Microsegmentation enforces granular, per-device policies that restrict what each device can talk to. When an attacker compromises a camera, microsegmentation prevents scanning other segments, accessing file servers, or pivoting to domain controllers. The blast radius is contained to the device and its explicitly permitted paths. This breaks the lateral movement chain at the discovery and movement phases (MITRE T1046 and T1021), exactly where the Iranian campaign would have been stopped. Unlike VLANs (which segment broadly) or firewalls (which only see north-south traffic), microsegmentation enforces east-west policy at the individual device level.

Further reading

• Lateral Movement Techniques Attackers Use to Traverse Enterprise Networks
• How Network Segmentation Stops Lateral Movement Attacks
• OT Security Vendor Landscape for 2026
• What Is Microsegmentation?
• Block Lateral Movement with Microsegmentation
• Industrial Network Security Solutions

Charlie Treadwell

CMO, Elisity

Charlie Treadwell is the Chief Marketing Officer at Elisity, where he leads the company's go-to-market strategy and thought leadership in identity-based microsegmentation. With deep expertise in cybersecurity marketing and enterprise network security, Charlie focuses on helping security leaders understand and address the evolving challenges of IoT/OT device protection and Zero Trust architecture.