Security Shouldn’t Depend on the Device: Introducing Soracom Traffic Filtering

TL:DR

• IoT devices can’t run security software – Soracom Traffic Filtering moves egress control to the network itself, enforcing rules at the VPG regardless of device capability.
• Customers now write rules against domain names, not IP addresses – Soracom handles dynamic resolution, so allowlists don’t break when cloud providers rotate endpoints.
• Native to the Soracom platform, no separate appliance required – with specific compliance value for regulated industries like healthcare, energy, and logistics.

---

There’s a quiet paradox at the heart of IoT security. The devices doing the most consequential work (monitoring patients in hospital rooms, managing sensors on power infrastructure, tracking shipments across continents, etc.) are often the least capable of protecting themselves. They can’t run security agents, can’t self-enforce policy, and typically lack the processing headroom or firmware flexibility to support the kind of endpoint controls that secure a laptop or a server.

For years, the industry’s answer to this was essentially: do your best at the edges, and hope the network in between behaves itself. That answer is no longer sufficient.

---

The Problem with Hope as a Security Posture

Traditional egress control for IoT has relied on IP allowlists: a list of approved destination addresses that devices are permitted to reach. It’s a reasonable approach for a more static internet – but the internet that IoT devices connect to today looks very different.

Cloud service endpoints rotate. CDN-routed addresses change without notice. The SaaS platforms and APIs that modern IoT applications depend on don’t live at stable, predictable addresses – and the rise of AI and LLM integrations has added a new category of endpoints that organizations need to govern but often can’t easily enumerate. The result is that a carefully maintained CIDR allowlist quietly goes stale, and the team responsible for it doesn’t always notice until something breaks or an auditor asks a hard-to-answer question.

The alternative – buying a separate firewall appliance and integrating it with existing connectivity infrastructure – solves part of the problem while creating others: another vendor relationship, another integration point, another operational dependency that can fail at inconvenient moments.

---

Enforcement at the Network Layer

Soracom Traffic Filtering moves the control point to where it belongs: the network itself.

Every device connected through Soracom’s platform routes its traffic through a Virtual Private Gateway (VPG). Traffic Filtering evaluates egress rules at the VPG – before packets reach their destination, and before any question of what the device itself is or isn’t capable of. The policy travels with the SIM. A low-cost sensor and a high-end industrial gateway receive the same enforcement, because the enforcement doesn’t live on either of them.

The feature ships with two distinct capabilities. The first is domain-name (FQDN) filtering: instead of maintaining a list of IP addresses, customers write rules against domain names – api.myplatform.com, for example. Soracom resolves those dynamically and keeps the underlying IP mappings current. When a cloud provider rotates its endpoints, the rule doesn’t break. The allowlist stays accurate without manual maintenance.

The second capability adds precision to IP-based rules: customers can now specify not just destination address but protocol and port. An organization that wants to permit only HTTPS traffic to any IP while blocking all other protocols can express that clearly, without ambiguity about which rule applies in which scenario. Traffic Filtering uses most-specific-match logic (the most precise matching rule wins) so broad allow policies with narrow overrides behave predictably.

Rules are defined via the platform, configurable via API or CSV for bulk fleet management, and independently auditable per VPG. Policies are a documented, rule-defined configuration — the current ruleset is inspectable and demonstrable to an auditor at any point.”

---

What This Means for Regulated Industries

For organizations operating in healthcare, energy, or financial services, the compliance implications are direct. Consider connected medical devices: IV pumps, patient monitors, and diagnostic equipment transmitting telemetry over cellular. HIPAA requires demonstrable controls over where patient-adjacent data flows. The devices themselves can’t run endpoint agents. Traffic Filtering closes that gap by restricting each device to reach only approved endpoints, with FQDN rules handling destination resolution regardless of underlying IP changes, and a policy record that satisfies auditors without requiring an engineer to reverse-engineer what was in place six months ago.

The same logic applies to remote grid monitoring in the energy sector, where any unexpected outbound connection is a threat indicator, not a nuisance – and to logistics fleets where operators manage thousands of devices from multiple hardware vendors and cannot guarantee what third-party firmware does on the wire. In each case, the value is the same: enforceable, documented policy that doesn’t depend on trusting the device.

There’s also a containment dimension. A compromised device on a network without egress control can reach anything. Traffic Filtering structurally limits what a compromised device can contact, reducing the blast radius of an incident before it becomes a breach.

---

Built In, Not Bolted On

Most connectivity providers deliver a pipe. Security on top of that pipe means a separate procurement process, a separate integration, and a separate operational burden. Traffic Filtering is native to the Soracom platform, managed in the same console, controlled through the same API, alongside Beam, Funnel, and the existing Outbound Filter that customers already operate. There is no additional appliance. There is no network redesign. Enabling it is a single toggle.

Traffic Filtering is available now for Type-F, Type-G, and Type-F2 VPGs and requires a separate contract. If your organization operates devices in a regulated environment, manages a heterogeneous fleet, or is moving toward zero-trust architecture for OT or IoT assets, we’d welcome the conversation.

---

Interested in mastering your own data traffic? Contact us today to learn more about this new and exciting feature – including how to implement it!