The Anatomy of a Secure Connection: Why VPNs Are So 2015, and How Private Networking Protocols Are Taking Over

TL;DR

• Client VPNs encrypt the connection and authenticate the device, a model built for laptops with a person around to maintain them, not fleets of unattended IoT devices.
• Soracom splits that job in two: the cellular network keeps the device-to-network segment private, and a VPG paired with Canal, Door, or Direct secures the rest, all without a VPN client on the device.
• The SIM handles identity as a secure element that can’t be cloned, with IMEI Lock stopping reuse elsewhere. Hands, Lamplight Logistics, and SmartKitchen already run fleets this way.

---

Every technology has a decade it belongs to. Much like flip phones belong to the 2000s, installing VPN client software on every device you manage belongs to 2015.

That’s not a knock on VPN technology broadly. It’s a critique of one specific pattern, and it raises an obvious question: if you take the VPN client off the device, what keeps the connection secure?

That question deserves a real answer. Here’s what a client VPN actually does, why doing that job per device breaks down at IoT scale, and what replaces it.

---

What a Client VPN Actually Buys You

Strip away the marketing, and a client VPN arguably does two jobs bundled into one piece of software.

First, it encrypts the path. Traffic travels through a tunnel so anyone watching the network in between sees nothing usable. Second, it authenticates the device, using a certificate to prove to the server which device is on the other end.

On a laptop, a person installs the client, loads the credential once, and both jobs run together for as long as that person keeps things updated.

Worth being precise on terminology too. What we just described, a device running its own client software, is Client VPN, sometimes called Point to Site VPN. Site to Site VPN is different: it connects two entire networks, say a data center to a cloud environment, through one tunnel between two gateways, with no client software on any machine behind either side.

Site to Site VPN remains standard, widely used enterprise architecture. Everything below critiques the client side pattern specifically, not VPN technology as a category.

---

The Human Factor: Why This Breaks Down at IoT Scale

Here’s the part that’s easy to miss: a client VPN assumes a person periodically installs software, enters credentials, and keeps both current. That holds for a workforce of laptops. It does not hold for a fleet of tens of thousands, sometimes millions, of headless sensors and machines that connect around the clock with no one behind them.

Try it anyway, and the cracks show up fast. Every device needs its own credential, and those expire without a person on hand to renew them. Most IoT hardware is also resource constrained, so a VPN client’s processing overhead drains battery on devices meant to run for years on one charge.

Client side encryption adds size to every packet too, eating into throughput on the low bandwidth, sometimes unreliable cellular links many of these devices rely on. And because a client VPN typically authenticates once and then grants broad access to whatever sits behind the gateway, one stolen credential can expose far more than intended.

That last point shows up in the breach data. Zscaler’s ThreatLabz 2025 VPN Risk Report, as summarized across security outlets, describes a sharp year over year rise in zero day exploitation of edge and remote access VPN devices, with some coverage citing a jump from the low single digits to over 20 percent of exploitation incidents. Other 2025 surveys cited alongside it put the share of organizations reporting a VPN related breach at roughly half over two years, with stolen credentials a leading cause of ransomware. These are rough estimates from secondary coverage, and figures vary by source, so confirm the original research before citing a hard number externally.

CVE-2025-0282, in Ivanti Connect Secure VPN software, was reported exploited as a zero day and linked to a breach at Nominet, the .UK domain registry. CVE-2025-20333 and CVE-2025-20362, in Cisco ASA and FTD software, were reportedly exploited in a state linked campaign against VPN and firewall edge devices. Treat these as illustrations of a trend, since attribution can shift as investigations continue.

---

Splitting the Job in Two: How Soracom Customers Do It Instead

If a client VPN’s job is really two jobs, encrypting the path and authenticating the device, the fix isn’t one clever replacement that does both on the device. It’s to stop doing either job on the device, and handle each at the network level instead.

The first half, keeping the path private, is already true of cellular connectivity before Soracom gets involved. The air interface between a device and a cell tower is encrypted under 3GPP standards, and a protocol called AKA mutually authenticates the SIM and the network before any data moves. The link from tower to core network sits on carrier infrastructure that isn’t reachable from the public internet, and GSMA guidance increasingly recommends explicit encryption there too.

In practical terms, that’s the same category of protection an encrypted tunnel provides, just implemented at the network level instead of inside a device’s client software. Backhaul implementation varies by carrier and network generation, so treat this as a general industry direction rather than a guarantee everywhere. But the core point holds: this segment doesn’t need a device side VPN client to be private, because it already isn’t public.

That leaves the second half: getting traffic from Soracom’s core network to a customer’s servers privately. This is where the Soracom Virtual Private Gateway, or VPG, comes in, establishing a dedicated network environment for a device fleet at the edge of Soracom’s core.

From there, a customer has real choices. If there’s a genuine requirement for a VPN connection, Soracom Door delivers an industry standard IPsec Site to Site VPN between the VPG and the customer’s environment, on AWS, Azure, Google Cloud, or an on premises firewall. If there’s no specific VPN requirement and the goal is simply private connectivity to a customer’s AWS network, Soracom Canal peers the VPG directly with a customer’s AWS VPC, so traffic never touches the public internet. For the strictest latency or throughput needs, Soracom Direct offers a dedicated physical connection instead.

Either way, no individual device runs VPN client software, negotiates a tunnel, or holds a certificate to protect. That’s a real trade off worth naming: instead of one continuous tunnel, there are now two purpose built segments, cellular privacy on one side and a VPG paired with Canal, Door, or Direct on the other. That’s more architecture to reason about than a single VPN tunnel. The payoff is that the device side becomes essentially zero touch, which matters more at scale than the elegance of one unbroken tunnel.

---

The Other Half of the Puzzle: A Credential You Never Have to Protect

Encrypting the path only solves half the problem. The other half, proving a device is who it claims to be, is where the SIM does more work than it usually gets credit for.

A SIM functions as a hardware secure element. It holds a secret authentication key that, under normal operation, never leaves the chip. Proving identity happens through a cryptographic challenge and response, not by transmitting the key itself, so there’s nothing in transit to intercept.

For SIMs made in roughly the last decade, extracting that key or cloning the SIM isn’t practically feasible. Attempts tend to trip a carrier’s fraud detection rather than succeed. Setup is inserting the SIM and configuring the APN. The credential is already provisioned and already protected.

Compare that to a client VPN, where someone has to generate a certificate, load it onto the device, and keep it safe for the life of the deployment. That’s a meaningful part of why stolen VPN credentials show up so often as a root cause in the breach data above.

One more layer is worth naming: Soracom’s IMEI Lock binds a SIM to the IMEI of the device it ships in. If that SIM is removed and placed into a different device, the network refuses the new session. That closes off a stolen or swapped SIM turning up elsewhere, again with nothing to configure on the device.

---

Proof in the Field

This isn’t theoretical. A few Soracom customers already run fleets this way.

Hands (formerly Tokyu Hands), the Japanese department store chain with more than 80 locations, replaced backup VPN lines at its stores with Soracom Air SIMs and Soracom Canal. Instead of provisioning and recertifying a VPN connection at each site, it now runs a closed network into its central servers with no VPN tunnel to manage anywhere, and deploys new terminals in days instead of months.

Lamplight Logistics, a real time location tracking provider, ships Bluetooth and RFID gateways worldwide using Soracom Air, Virtual Private Gateway, Napter, and Peek to skip what CEO Kurt Nehrenz calls the “IT negotiation” phase. In his words: “I feel comfortable having a giant box of gateways shipped to God knows where, knowing that as soon as they get plugged in, they’re going to work.” There’s no VPN client to install and no certificate to load before a device goes live. The company’s next step is adding IMEI Lock on top of its VPGs for tamper resistance.

SmartKitchen builds IoT monitoring systems for commercial kitchens across Europe. It uses Soracom Air and VPG to isolate devices from the public internet while expanding into new countries. CEO Matti Verkasalo said VPG implementation “was quick and has resulted in significant business benefits,” with no communication interruptions since, and no kitchen operator ever managing a VPN connection.

---

The Same Realization, Elsewhere in IT

If the human factor argument sounds familiar, it should. Enterprise remote access has gone through a related shift, with Zero Trust Network Access, or ZTNA, increasingly replacing remote access VPN for employees.

Worth being precise here too: ZTNA displaces Client VPN, the model where a user authenticates once and gets broad access from there. It isn’t generally a replacement for Site to Site VPN tunnels connecting data centers or clouds, which remain common and aren’t part of this conversation.

Industry commentary frames 2026 as an inflection point for ZTNA adoption, often citing compliance pressure from frameworks like NIST SP 800-207 and the EU’s NIS2 directive. Market size figures vary by source, so treat any specific number as a rough estimate and check it against a named analyst before repeating it. The direction is consistent, though: for individual, client side access, the industry is moving from broad, tunnel based trust toward narrow, continuously verified access, the same direction the cellular network plus VPG architecture takes for machines instead of people.

---

Why This Belongs in the Boardroom

Framed this way, the choice between architectures is a business decision, not just a network engineering one.

There’s an operational cost angle. Splitting the job between the cellular network and a VPG paired with Canal, Door, or Direct removes per device certificate generation and renewal, work that otherwise scales linearly with fleet size. There’s a risk angle too: a hardware backed credential that can’t be extracted, combined with a gateway level connection instead of thousands of individual tunnels, meaningfully shrinks the attack surface described above.

There’s a speed to market angle as well, worth flagging as customer experience rather than an independently benchmarked figure. Hands deployed new terminals in days instead of months, and Lamplight ships gateways globally with no IT approval cycle at the destination.

And there’s a compliance angle that deserves a careful hand. None of these architectures, including Site to Site VPN through Door, guarantee compliance with any specific regulatory requirement on their own. They align directionally with frameworks like NIST SP 800-207 and NIS2, but any specific compliance claim belongs in front of legal and compliance counsel, not settled here.

---

The Verdict

So, what secures the connection if not a VPN client on the device? The job splits in two. The cellular network keeps the device to core network segment private. A Virtual Private Gateway, paired with Canal, Door, or Direct, keeps the core network to server segment private. The SIM, as a secure element with IMEI Lock on top, handles identity without anyone generating or protecting a credential by hand.

None of that makes VPN technology obsolete. Site to Site VPN, through Door, is part of the answer when a real requirement calls for it. What’s retired is treating an IoT device like a laptop and handing it a VPN client. Hands, Lamplight Logistics, and SmartKitchen are already running their fleets the other way.

---

Got a question about Soracom? Whether you’re an existing customer, interested in learning more about our products and services, or want to learn about our Partner program — we’d love to hear from you!