TL;DR
Most IT leaders point to their firewall, SASE deployment, or next-gen VPN and consider mobile devices “covered” because they eventually touch the corporate network. But a field technician’s phone spends most of its working day on carrier cellular or a customer’s guest Wi-Fi — completely outside that perimeter. Verizon’s 2025 Mobile Security Index found 85% of organizations reporting a rise in mobile-specific attacks, and the reason is structural: network-layer tools were built to inspect traffic crossing a boundary, not to see what happens on a device that’s rarely inside that boundary at all. The real fix isn’t buying a bigger firewall — it’s scoring your fleet against the specific threat vectors that live on the endpoint itself, not the network.
The Status Quo Trap: “We deployed SASE, so the fleet is protected”
Ask most IT directors how their mobile fleet is secured and the answer usually references network infrastructure: a next-gen firewall, a SASE platform, a zero-trust network access gateway. That’s the trap. Those tools do real work — but they were architected to protect what crosses a network boundary, and a mobile device on cellular data, a customer’s guest network, or a public hotspot may cross that boundary for only a fraction of its operating day.
Security vendors themselves describe the split plainly: network security is the walls of the building, while endpoint security is the locks, cameras, and alarms on the doors inside it — network security is like the walls of a building, and endpoint security is like the locks, cameras, and alarms on its doors, with one protecting what’s inside and the other protecting access to it. And critically, even the most effective network monitoring can’t prevent malware from spreading if an endpoint is already compromised. A field fleet of phones and tablets is almost entirely endpoint — the network layer only ever sees a slice of its actual exposure.
This is why the zero-trust market itself has a documented gap. As one analysis of the space puts it, the Zero Trust market is currently dominated by network-centric vendors who focus on securing access at the network edge, and this approach alone leaves a critical blind spot: the endpoint itself. If your entire mobile security posture lives in your network stack, you haven’t closed the gap — you’ve just described where it is.
The status quo isn’t a competing vendor’s product. It’s the assumption that “connected to a secure network sometimes” equals “secure all the time.” For a distributed mobile fleet, that assumption is the actual liability.
The Tele Data Guru Framework: The Mobile Attack Surface Coverage Matrix
Before assuming your existing stack covers the fleet, map each control layer against the threat vectors that actually target mobile devices in the field — not the ones your network diagram was drawn to stop.
| Threat Vector | Network Firewall / SASE | Laptop-Focused EDR | MDM / UEM Policy | Mobile Threat Defense (MTD) |
|---|---|---|---|---|
| Lost or stolen device | No visibility — device is off-network | Rarely deployed on mobile OS | Remote wipe/lock if enrolled and online | Detects tamper and triggers containment |
| SMS phishing (smishing) | Not inspected — SMS bypasses web/DNS filtering | No SMS-layer detection | No content inspection, policy only | Flags malicious links and sender spoofing on-device |
| Malicious or sideloaded apps | Only visible if app traffic transits the tunnel | Not built for mobile app behavior | Can restrict app sources, can’t detect malicious behavior | Behavioral scanning of installed apps |
| Unmanaged BYOD on corporate Wi-Fi | Sees network traffic, not device posture | No agent on personal device | Enrollment-dependent — unmanaged devices are invisible | Can assess risk even on unenrolled devices via app-based agent |
| Public Wi-Fi / cellular exposure off-VPN | Zero coverage once VPN/tunnel is off | Not applicable to mobile | Policy enforcement only if device checks in | Continuous on-device monitoring regardless of network path |
Most fleets score strong on the leftmost columns and nearly empty on the right — which is exactly backwards, since the rightmost threats are the ones a mobile workforce actually encounters most often. Run this matrix against your current stack before your next security budget cycle, not after an incident forces the conversation.
The Blind Spot Exposure Formula
Blind Spot Exposure = (Unmanaged/Off-Network Endpoints × Estimated Incident Rate × Average Cost per Incident) − Current MTD/UEM Spend
SMS phishing is the sharpest illustration of why this matters: click-through rates for SMS-based phishing run 19% to 36%, compared to just 2% to 4% for email — meaning a mobile-targeted lure is roughly nine times more likely to succeed than the same lure sent to an inbox your email security stack is already filtering. Illustrative example: a 300-device field fleet with no on-device threat detection, hit by even one targeted smishing campaign at a 25% click rate, puts 75 devices at risk of credential theft in a single incident — before accounting for downtime. Verizon’s own data shows the downside isn’t hypothetical: the percentage of organizations that had to deal with significant repercussions due to downtime has increased to 63%, up from 47% in 2024, following a mobile-related compromise. Run your own fleet size and downtime cost per hour through the formula — the gap between “we have a firewall” and “we have mobile threat coverage” is usually the number that gets budget approved.
Commercial Realities & Vendor Pitfalls
- Your SASE agent’s mobile coverage may only apply when the tunnel is active. If a technician’s device drops the VPN client to save battery, or an app communicates outside the tunnel entirely (native SMS, many third-party apps), your SASE platform has no visibility into that session — it isn’t a gap in the product, it’s a gap in what the category was built to do.
- MDM and MTD are not the same purchase. Mobile device management enforces configuration policy and can remote-wipe an enrolled device — it does not detect a malicious app’s behavior, a spoofed cell tower, or a phishing link rendering in real time. Confirm which one you actually bought before reporting it as “mobile security” to leadership.
- Budgets are moving, but controls often aren’t keeping pace. 89% of organizations now have a specific mobile security budget, and 75% increased mobile security spending in the past year — yet only 17% of organizations have implemented specific security controls against AI-assisted attacks like AI-generated smishing. Spend and coverage are two different line items.
- Unenrolled BYOD devices are invisible to policy-based tools by design. If a device was never enrolled in MDM, it doesn’t exist in that dashboard — which means “we require MDM” is a policy statement, not a verified control, unless enrollment is enforced at the network or app-access layer.
Implementation Checklist
- Inventory the fleet by ownership and management status: corporate-owned/enrolled, corporate-owned/unenrolled, and BYOD.
- Score current tooling against each row of the Mobile Attack Surface Coverage Matrix — don’t assume network tools cover rows they were never built for.
- Confirm whether your MDM/UEM platform includes an on-device threat detection layer, or whether it’s policy-and-wipe only.
- Run a controlled smishing simulation against the fleet to get an actual click-rate baseline instead of an assumed one.
- Require phishing-resistant authentication for any account with elevated access, since SMS-based one-time codes are themselves a smishing target.
- Calculate your own Blind Spot Exposure figure using real fleet size and your organization’s downtime cost per hour.
- Present the coverage gap — not a generic “we need more security budget” ask — to leadership using the matrix and the formula together.