When Carriers Let Others Offload Your Traffic: The Growing MITM Risk Behind Passpoint and Offload Programs

When Carriers Let Others Offload Your Traffic: The Growing MITM Risk Behind Passpoint and Offload Programs

Introduction

Passpoint technology was meant to make public Wi-Fi safer and more convenient by letting your phone automatically connect to trusted networks. In theory, that should reduce insecure logins and spoofed hotspots. In practice, however, the way major carriers are deploying it through open offload programs like Google Orion and decentralized crypto networks has created new, poorly controlled attack surfaces.

With the right setup, nearly anyone can now deploy an access point that AT&T, T-Mobile, or Google Fi phones automatically connect to. That convenience means your mobile traffic may be locally egressed through a network you do not control, effectively allowing man-in-the-middle (MITM) visibility of your data.

The concerning part is that you cannot opt out except by disabling Wi-Fi or forcing all traffic through an always-on VPN.

How Passpoint Works

Passpoint, also known as Hotspot 2.0, allows devices to automatically authenticate and connect to approved Wi-Fi networks using a secure handshake. While it encrypts the radio link and verifies the network identity, it does not add extra end-to-end encryption for your actual internet traffic. Once connected, your normal data is routed locally, not through your carrier’s encrypted cellular core.

That means your carrier is trusting the Wi-Fi operator. If that operator is careless or malicious, your traffic can be inspected, logged, or manipulated before it ever leaves the access point.

The Growing Offload Problem

AT&T and Google Orion

AT&T is partnering with Google Orion to expand offload coverage using third-party Wi-Fi networks. Orion makes it remarkably easy to sign up. Anyone with basic technical skill can be online in under half an hour. There is no rigorous verification or background check process, meaning even anonymous entities could deploy networks that AT&T and Google Fi devices connect to automatically.

If an unethical operator wanted to, they could perform SSL downgrade attacks, packet inspection, or surveillance under the guise of legitimate offload.

Helium and Crypto-Driven Offload

Helium’s decentralized “DeWi” (Decentralized Wireless) model adds another layer of concern. Both AT&T and T-Mobile allow some Helium devices to provide offload connectivity for rewards. That means people plug hotspots into random connections such as residential broadband or Starlink to earn crypto.

Security on these nodes varies widely. Some owners know what they are doing while others simply chase rewards. Since there is no Know Your Customer (KYC) or strong auditing, anyone can deploy a node, attract carrier traffic, and potentially intercept data before being banned later (if at all).

Verizon’s Cautious Approach

To their credit, Verizon appears to be taking a slower and more controlled path. Their current offload and OpenRoaming pilots are limited to already trusted partners and small test environments.

However, as OpenRoaming and offload adoption accelerate across the industry, even Verizon will face pressure to scale. When that happens, the same risks could emerge if onboarding becomes automated or outsourced to third-party aggregators.

Technical Risks and Security Implications

Even when Passpoint and OpenRoaming connections appear encrypted, they introduce several subtle but serious risks. These are not theoretical problems; they are practical issues that arise when unverified networks are allowed to handle carrier-level traffic. Below are the primary categories of vulnerabilities and what they mean in plain terms.

1. Man-in-the-Middle (MITM) Attacks

When a device connects through a third-party access point, all data traffic is routed through that local network before leaving to the wider internet.

This creates the opportunity for man-in-the-middle interception, where an attacker can observe, modify, or inject packets.

  • Packet inspection: A malicious or compromised access point can monitor DNS requests, HTTP traffic, and metadata even without breaking encryption.

  • Traffic redirection: Attackers can route requests through proxies or fake DNS resolvers to inject advertisements or malware.

  • Credential harvesting: Any unencrypted service or outdated app could reveal login information during an MITM event.

  • Trust exploitation: Because Passpoint networks use legitimate carrier identifiers, users rarely suspect an attack.

2. SSL and TLS Downgrade Attacks

Modern HTTPS encryption usually protects against interception, but misconfigured systems or weak applications can still be forced into insecure states.

Offload networks that terminate or proxy connections can exploit downgrade paths.

  • Legacy handshake manipulation: Attackers can trigger fallback to older SSL or early TLS versions that are easier to decrypt.

  • Certificate injection: Fake or self-signed certificates may be presented if a user taps through browser warnings or if an app ignores validation errors.

  • Proxy-based attacks: In some corporate or malicious networks, transparent proxies attempt to intercept TLS connections using forged certificates.

The risk grows because mobile devices automatically trust the Passpoint offload connection as “carrier Wi-Fi,” making users less cautious about security warnings.

3. Traffic De-anonymization and Metadata Leakage

Even if payload data is encrypted, metadata often is not. Every connection reveals clues about user behavior, identity, and movement patterns.

  • Device fingerprinting: MAC addresses, DHCP requests, and timing information can uniquely identify devices even across sessions.

  • Location inference: By monitoring which hotspot a user connects to, operators can track movement with high precision.

  • Network correlation: Combining Wi-Fi session logs with cellular authentication data allows cross-linking of identities.

  • User profiling: Offload providers could build behavioral models of when and where users connect, and what services they access.

When offload partners are unverified or incentivized only by payment systems like Helium, these datasets could be sold, leaked, or misused for marketing or surveillance.

4. Data Tampering and Injection

Because offload networks handle packets before they leave for the internet, an attacker or poorly configured gateway could alter data in transit.

  • Ad or tracker injection: Adding tracking pixels or scripts to unencrypted web pages.

  • DNS poisoning: Redirecting legitimate domain lookups to malicious or phishing servers.

  • Software update interception: Redirecting device or app update requests to distribute tampered firmware or APKs.

  • Payload alteration: Changing HTTP responses to deliver different content than expected.

These issues may go undetected, especially if users assume the traffic is secured by their carrier.

5. Weak Authentication and Access Point Spoofing

The biggest weakness in large offload ecosystems is that devices often rely on the SSID and advertised credentials to determine whether a network is legitimate.

  • Clone networks: Attackers can create hotspots broadcasting the same Passpoint identifiers as trusted carriers.

  • Misconfigured equipment: Even legitimate offload devices can have default credentials or poor security hardening.

  • Lack of physical or logical verification: Because users do not manually connect, they cannot visually confirm they are on a trusted access point.

This trust model depends entirely on the carrier and aggregator to prevent unauthorized AP registration, yet that control is often delegated or automated.

6. Privacy Erosion and Data Brokerage

Offload networks that collect connection logs may share them with third parties or store them insecurely.

  • Data resale: Some operators could sell anonymized but re-identifiable data such as device IDs, timestamps, and location information.

  • Breach exposure: Weakly secured data stores can leak connection logs, exposing movement patterns of carrier customers.

  • Regulatory gaps: In many jurisdictions, offload partners are not classified as telecom providers and may not be bound by privacy laws.

This turns a technology that was supposed to protect user privacy into another potential vector for surveillance.

Why This Matters

The root issue is that carriers are outsourcing trust. They rely on RADIUS authentication and accounting to confirm a user is legitimate, but those protocols do not give them real-time visibility or control over what is happening inside the local Wi-Fi network.

A rogue or misconfigured access point can still capture unencrypted data, modify packets, or log metadata. Yet the backend systems will report a perfectly valid session. There is no built-in security incident detection or forensic control for what happens between the device and the egress point.

In theory, carriers could fix this by tunneling traffic from every Passpoint connection back through a carrier-managed VPN. But in practice, that defeats the business case. The entire goal of Wi-Fi offload is to reduce mobile core data costs and ease network congestion. Running a full-time VPN for millions of users is expensive in both bandwidth and infrastructure. Even if the VPN were limited only to Passpoint sessions, the operational cost and added latency would undermine the savings the carriers are counting on.

As a result, the carriers have chosen to shift the risk to users and rely on trust in third-party offload partners instead of ensuring end-to-end encryption themselves.

What Should Change

  • Carriers should individually approve offload providers rather than outsourcing trust to aggregators like Orion

  • KYC and periodic audits must be mandatory for all offload operators

  • Encrypted backhaul tunnels should be required between access points and carrier gateways where practical

  • Carriers should be transparent about the cost trade-offs that led them to skip VPN backhauling, and explore lower-cost alternatives such as lightweight traffic encapsulation or selective encryption

  • Security incident reporting should extend beyond RADIUS logs to include anomaly detection, encryption status, and egress path verification

  • Regulators and standards bodies should require clearer disclosure to users when their traffic is locally egressed rather than protected by the carrier network

Industry Silence

Most of the telecom and Wi-Fi industry is staying quiet on this issue. The marketing focus remains on seamless connectivity and unified roaming experiences, not the trade-off in control and visibility.

That silence is troubling. If OpenRoaming and offload programs continue expanding without tighter controls, we will end up with a global mesh of semi-trusted hotspots where your device connects automatically, your carrier sees it as safe, but the real operator could be anyone.

Mitigation for Users

Until carriers enforce stricter validation and logging for offload partners, you can protect yourself by:

  • Disabling Wi-Fi auto-connect when you are not on trusted networks

  • Using an always-on VPN to encrypt all traffic leaving your device

  • Enabling “Disable 2G” and using modern TLS wherever possible

  • Avoiding Passpoint profiles you did not personally install

  • Monitoring your device connections. Some Android builds show “Passpoint” or “carrier Wi-Fi” next to the network name

What Should Change

  • Carriers should individually approve offload providers rather than outsourcing trust to aggregators like Orion

  • KYC and periodic audits must be mandatory for all offload operators

  • Encrypted backhaul tunnels should be required between access points and carrier gateways

  • Security incident reporting should extend beyond RADIUS logs to include anomaly detection, encryption status, and egress path verification

Conclusion

Passpoint and OpenRoaming were supposed to make wireless connections safer and more seamless. Instead, a lack of accountability and oversight in offload ecosystems risks turning them into a shadow network of semi-trusted MITM nodes.

Carriers must treat Wi-Fi offload not as a convenience feature but as a security boundary. Until they do, the only safe path for privacy-minded users is vigilance: disable auto-connect and keep a trusted VPN always on.

 

Sources and Further Reading

Carrier and Platform Documentation

Technical Standards and Background

Security and Privacy Analysis

Community and Industry Discussion

Regulatory and Policy References

 

0 comments

Leave a comment

Please note, comments need to be approved before they are published.