Why VPN Is Not Enough for IoT Security

VPNs were built for laptops, not IoT. Learn why VPN limitations create blind spots in IoT security and what secure remote access looks like for connected device fleets.

TL;DR

VPNs were designed to give laptop users encrypted access to corporate networks. They operate on a trust-once-connected model that grants full network access after authentication. This creates three problems for IoT deployments. First, any connected device or contractor has a lateral movement path across the entire network. Second, most IoT devices are headless and lack the resources to run VPN client software. Third, certificate and configuration management scales linearly with fleet size, creating VPN sprawl. Under NIS2 compliance requirements, VPNs also fall short on network segmentation, device behavior visibility, and audit trail capabilities. Zero Trust Network Access (ZTNA) addresses these gaps by enforcing application-level access instead of network-level access, requiring no client software on devices, exposing no inbound ports, and providing continuous traffic monitoring. For IoT and OT environments in regulated industries, Zero Trust at the connectivity layer replaces VPN dependencies with a security model built for connected device fleets.

 

 

IoT Analytics estimated 14.4 billion active IoT endpoints in 2022, with forecasts reaching 30 billion by 2027. The technology securing most of those connections was designed in the 1990s for employees on laptops.

 

That technology is VPN. And the mismatch matters.

 

When a service technician connects via VPN to troubleshoot a temperature sensor at a remote facility, the tunnel encrypts the traffic and authenticates the session. But it does not give access to one sensor. It opens a path to the entire network. The technician's laptop, which your IT team does not control, is now sitting inside your OT environment. If that laptop carries malware, the attacker does not need to break in. The VPN already let them through.

 

This is how most IoT environments work today. And it is why VPN falls short when applied to connected device fleets.

 

 

VPNs Were Designed for a Different Problem

 

VPN technology was built to solve a specific challenge: give remote employees secure access to a corporate network from their laptops. It creates an encrypted tunnel between a user's device and the company network, protecting data in transit from interception.

The model works on a trust assumption. Once a user authenticates and the tunnel is established, they are treated as a trusted participant on the network. The system grants broad access based on successful login, not based on what the user or device is doing after connection.

For laptop users accessing email and file servers from a hotel room, this was a reasonable tradeoff. The user has a managed device, an IT department pushes updates, and network segmentation limits how far they can move.

IoT changed the equation. Research by Zohaib et al. (2024) in a systematic review of VPN and Zero Trust frameworks highlights that VPNs treat all authenticated users as trusted and give unrestricted network access, a model increasingly misaligned with environments where thousands of devices connect from uncontrolled locations. When your network has 500 sensors, 200 cameras, and a dozen third-party vendors connecting remotely, the trust-once-connected model creates exposure that grows with every device you add.

 

 

Three VPN Limitations That Put IoT Deployments at Risk

 

1. Full network access creates lateral movement paths

This is the core problem. A VPN does not distinguish between "access this one sensor" and "access everything on the network." Once the tunnel is up, the connected device or user has a path to move laterally.

 

Canavese et al. (2024), in a peer-reviewed study on IoT security at the network edge, describe how compromised IoT devices serve as entry points for unauthorized access, leading to data breaches and disruptions to critical infrastructure. The researchers note that even well-intentioned connections can be exploited because the device on the other end of the VPN tunnel is not continuously verified after initial authentication.

 

In practical terms, this means a contractor with a compromised laptop who connects via VPN to service one piece of equipment has a potential path into your entire OT network. The VPN does not limit scope. It does not monitor behavior. It does not ask whether the traffic pattern makes sense.

 

For enterprises running IoT in energy grids, water treatment, manufacturing, or transport infrastructure, this is not an acceptable risk profile. One breached connection should not expose every connected asset.

 

 

 

2. VPN assumes devices run client software

VPN requires software on both ends of the tunnel. On a laptop, installing a VPN client is routine. On a temperature sensor running on a microcontroller with 256KB of memory, it is not possible.

 

Most IoT devices are headless. They have no operating system that supports VPN clients. They run on constrained hardware with limited processing power, limited memory, and often no capability for security updates. Canavese et al. (2024) describe these devices as suffering from intrinsic security vulnerabilities due to limited computing power, low-cost design, and the absence of timely security updates.

 

This creates a fundamental design mismatch. VPN was built for devices with full operating systems, keyboards, and users sitting behind them. IoT devices are autonomous. They send small data packets on schedule. They do not interact with login screens. Forcing VPN architecture onto these devices either fails outright or introduces workarounds that create their own security gaps.

 

 

3. Management overhead scales with your fleet

Every VPN connection needs configuration. Certificates, credentials, tunnel parameters, firewall rules. For 10 devices, this is manageable. For 500 devices spread across three countries, it becomes a full-time job.

 

Zohaib et al. (2024) identify scalability as a critical concern with traditional VPN implementations, noting that VPNs are typically designed to accommodate a fixed number of concurrent connections, creating limitations for organizations with dynamic or growing device fleets.

 

Each device needs its own certificate. Certificates expire and need rotation. VPN concentrators need patching. Firmware updates need coordination. The management burden grows linearly with your fleet, and every unpatched component is a potential vulnerability.

 

At scale, this is what the industry calls VPN sprawl. It is not a single security flaw. It is a systemic increase in attack surface that compounds over time.

 

 

The Compliance Factor: Why VPN Falls Short Under NIS2

 

The EU NIS2 Directive introduces direct obligations for organizations operating critical infrastructure. Among the requirements: network segmentation, incident detection, supply chain risk management, and audit-ready controls.

 

VPN provides encryption in transit. That addresses one piece. But it does not segment traffic between devices. It does not detect anomalous device behavior. It does not log what a device is communicating with after the tunnel is established. If a sensor starts sending data to an unexpected destination, a VPN will not alert you.

 

For organizations in energy, utilities, industrial automation, or transport, these gaps are not theoretical. They are compliance liabilities. Auditors increasingly question whether VPN-based architectures provide sufficient segmentation and visibility for environments with hundreds of connected devices operating across borders.

 

The Sebestyen et al. (2025) literature review on IoT security confirms that regulatory frameworks are driving demand for security models that go beyond perimeter-based encryption, requiring continuous monitoring and granular access control across connected devices.

 

 

What Secure Remote Access Looks Like for IoT

 

If VPN operates on "trust once connected," the alternative operates on the opposite principle: never trust, always verify. This is the Zero Trust model.

 

Zero Trust for IoT means several things in practice:

 

No implicit trust. Every connection is verified before and during the session. A device does not get network access. It gets access to a specific application, for a specific purpose, for a limited time.

 

Device-initiated traffic only. Instead of opening inbound ports for VPN connections, the device initiates outbound connections to a cloud-based security broker. No ports are exposed on your datacenter or cloud infrastructure. There is nothing for an attacker to scan or target.

 

No client software required. Security enforcement happens at the network level, not on the device itself. This is critical for headless IoT devices that have no capacity for agent software. The security wraps around the device through the connectivity layer rather than requiring the device to protect itself.

 

Visibility into device behavior. Instead of seeing only tunnel status, you see what each device communicates with, how often, and whether the pattern matches expected behavior. If a device deviates, the system alerts.

 

Privileged Remote Access for third parties. When a contractor needs to service equipment, they access the specific device through a browser-based session. The session is time-limited, recorded, and restricted to exactly the equipment they are authorized to reach. No VPN client distribution. No broad network access.

 

The Zohaib et al. (2024) framework for integrating Zero Trust with VPN concepts concludes that ZTNA provides granular access control, granting users access only to specific applications and resources based on identity and context, significantly reducing the attack surface compared to traditional VPN.

 

 

IoT Security Comparison

VPN vs. Zero Trust for IoT

Criteria Traditional VPN Zero Trust for IoT
Attack surface
Exposed ports, full network access once connected
One compromised device creates a lateral movement path across the entire network.
Zero exposed ports. Device-initiated traffic only.
No inbound connections accepted. Nothing for an attacker to scan or target.
Visibility
Tunnel status only
No insight into device behavior or traffic destinations after connection.
Visual traffic map with anomaly alerts
See every connection each device makes. Automatic alerts on unexpected behavior.
Third-party access
Full network access via VPN client
Contractors receive broad access. Requires VPN client distribution and credential management.
Browser-based, time-limited, recorded
Contractors access specific equipment through a web portal. Sessions are scoped, timed, and recorded.
Client software
Required on every device
Most IoT devices lack the OS and resources to run VPN clients.
None. Security enforced at the SIM level.
Works with headless, constrained, and legacy devices without software installation.
NIS2 compliance
Encryption in transit only
No network segmentation. Limited audit trail. Auditors question public internet exposure.
Full audit trail, segmentation, access control
Private infrastructure. Maps to NIS2 requirements for segmentation, monitoring, and incident detection.
Built for
Laptops and users
Designed for managed endpoints with full operating systems and human operators.
IoT and OT, including headless devices
Purpose-built for connected device fleets. Works with intelligent and unintelligent endpoints.

 

 

 

A Different Approach to IoT Connectivity Security

 

IXT is a full MVNO that has built Zero Trust security directly into its IoT connectivity platform. Through integration with Zscaler Zero Trust Network Access, IXT routes all device traffic through the Zscaler Zero Trust Exchange, where it is inspected and policy-enforced before reaching its destination.

 

The result: no exposed ports, no VPN tunnels to manage, no client software on devices. Third-party contractors access specific equipment through browser-based, time-limited, recorded sessions. All of this works across 600+ mobile networks in 190+ countries, from a single SIM.

 

For organizations looking to understand how Zero Trust works in practice for IoT and OT environments, IXT has put together a webinar that walks through the architecture, the deployment model, and real scenarios from regulated industries.

 

 

 


 

Frequently Asked Questions

 

 

Is VPN secure enough for IoT?

VPN encrypts data in transit, which provides protection against interception. It does not, by itself, address the broader security requirements of IoT deployments. VPN grants full network access after authentication, does not support headless devices without client software, and offers limited visibility into device behavior. For fleets of connected devices in regulated industries, VPN alone leaves gaps in segmentation, monitoring, and compliance.

 

 

What is Zero Trust for IoT?

Zero Trust for IoT applies the principle of "never trust, always verify" to connected device environments. Instead of granting network-level access through a VPN tunnel, Zero Trust enforces application-level access based on device identity and behavior. No ports are exposed. No inbound connections are accepted. Security policies are enforced at the network edge, without requiring software on the device itself.

 

 

How does Zero Trust replace VPN for connected devices?

 

Zero Trust does not extend the network to remote devices. Instead, it brokers secure, verified connections between specific devices and specific applications. Device traffic is inspected and policy-enforced before it reaches the destination. Third-party access is handled through browser-based sessions, eliminating VPN client distribution. This approach removes the lateral movement risk, scales without per-device configuration, and provides continuous visibility into what devices are doing on the network.

 

Why does VPN management become a problem at scale?

 

Every VPN connection requires certificates, credentials, and configuration. As device fleets grow to hundreds or thousands of units across multiple countries, maintaining these connections creates significant operational overhead. Certificates expire, VPN concentrators need patching, and every unmanaged component represents a potential vulnerability. This scaling problem is often called VPN sprawl.

 


 

External sources

Canavese, D., Mannella, L., Regano, L., and Basile, C. (2024). Security at the edge for resource-limited IoT devices. Sensors, 24(2), 590. https://doi.org/10.3390/s24020590

 

Zohaib, S. M., Sajjad, S. M., Iqbal, Z., Yousaf, M., Haseeb, M., and Muhammad, Z. (2024). Zero Trust VPN (ZT-VPN): A systematic literature review and cybersecurity framework for hybrid and remote work. Information, 15(11), 734. https://doi.org/10.3390/info15110734

 

Sebestyen, H., Popescu, D. E., and Zmaranda, R. D. (2025). A literature review on security in the Internet of Things: Identifying and analysing critical categories. Computers, 14(2), 61. https://doi.org/10.3390/computers14020061

 

Tariq, U., Ahmed, I., Bashir, A. K., and Shaukat, K. (2023). A critical cybersecurity analysis and future research directions for the Internet of Things: A comprehensive review. Sensors, 23(8), 4117. https://doi.org/10.3390/s23084117