A notebook is a comparatively grateful device for modern security teams. It has an operating system, a manageable identity and usually a client that can be used to control access. The situation is different for a charging point, a POS terminal, a vehicle gateway or an industrial tablet. These devices often communicate via mobile communications, run in the field for years and cannot be treated like a workstation computer.
This is where a gap between Zero Trust strategy and operational reality arises. The organization may have already modernized access rules for users and locations. Nevertheless, the mobile network inventory remains distributed in separate APNs, private networks, VPN constructions and carrier portals. Security sees one part of the communication, the network team sees another, and the device operator often only sees whether a SIM is active.
The decisive question is not: "How do we get another agent on the device?" It is: "How do we get identity, policy and observability to a communication channel where an agent is often not possible at all?"
The problem doesn't start with the SIM
At first glance, mobile communications seem like a connectivity issue. In practice, however, four different decisions depend on this:
- Which device is allowed to communicate over which connection?
- What internet or personal destinations are required for this device?
- How is unexpected behavior detected?
- Who can distinguish between device, cellular, target application, and security policy in the event of a disruption?
A classic network model often answers these questions with segments and blanket trust zones. This scales poorly when thousands of devices in different countries, networks and operating models are added. Also, a device doesn't automatically become trusted just because it uses a known SIM or comes from a private APN.
Zero Trust reverses this logic: communication is limited to the necessary purpose. The architecture asks about the specific device, the destination and the permitted relationship – not whether the traffic is "in the internal network".
What Zscaler Cellular promises technically
Zscaler describes Cellular as a solution for secure, scalable cellular connectivity of IoT and mobile devices. The publicly documented architecture consists of Zscaler SIM and Zscaler Cellular Edge. Mobile communications traffic is routed to the Zero Trust Exchange, where it is linked to ZIA or ZPA guidelines.
For agentless devices, one detail is particularly relevant: According to Zscaler, a device connected via a Zscaler SIM does not require an additional software agent. In the documented architecture, policies can refer to IP addresses, IMEI or IMSI, among others. Zscaler cites vending machines, charging infrastructure, machines as well as tablets and kiosks as examples.
This is not an incidental gain in comfort. For durable or specialized devices, the agent question often determines whether a security model is practically rollable. When control shifts to connectivity and policy enforcement, an organization can include devices that are unsuitable for classic endpoint mechanisms.
Nevertheless, "agentless" is not a synonym for "automatically secure". The impact still depends on a clean equipment inventory, clear communication relationships, appropriate guidelines and a resilient operating process.
Three typical betting patterns
1. Charging infrastructure and distributed energy components
A charging point requires connections to the backend, monitoring and, if necessary, maintenance services. However, he does not need arbitrary access to internal networks. A viable pilot therefore first models the actually required goals and protocols. It then examines how outages, roaming, maintenance and switching providers are handled.
2. Kiosk, POS and Field Service
Kiosk and POS devices are located outside controlled office locations. A technician tablet also switches between regions and networks. The combination of limited communication and centrally visible telemetry is interesting here. However, the pilot must map real transactions, updates, support accesses, and offline scenarios – not just a successful demo connection.
3. Industrial and IoT-related devices
Machine gateways, sensors and mobile control units often have long life cycles. Changes to the device are expensive or only possible during maintenance windows. Agentless access can make adoption easier. Before that, however, it must be clear what responsibility Zscaler Cellular assumes and which continues to lie in device hardening, application safety, OT zoning and process safety.
This is what a resilient discovery and pilot process looks like
A sensible start does not start with a SIM order, but with a limited use case.
Step 1: Clarify the status quo and responsibility. What device types, countries, carriers, contracts, APNs, and target applications are affected? Who owns the device, application, mobile contract, security policy and support process?
Step 2: Capture communication relationships. What goals and protocols are technically necessary? Which connections have only grown historically? Which return channels or maintenance accesses need to be considered?
Step 3: Check architecture and availability. Does the documented Zscaler Cellular feature set fit the country, carrier, device type, and existing ZIA/ZPA model? Which SKU, SIM or eSIM variant and which partner service are required?
Step 4: Establish pilot criteria. A pilot needs more than "device is online". At a minimum, successful specialist transactions, policy hits, visibility, fault diagnosis, failover behaviour and operational effort should be measured.
Step 5: Test the handover of operations. Who reacts to an abnormal SIM, an interrupted connection or a blocked target relationship? A RACI for carriers, device operations, applications, networks, security and service providers is part of the result.
Five questions that must be answered before the offer
- Is Zscaler Cellular available for the countries, carriers, and device variants you need?
- What ZIA/ZPA licenses, cellular SKUs, and partner services are actually needed?
- Who provides the SIM or eSIM and is responsible for activation, replacement and decommissioning?
- Which target application is suitable for a limited, measurable pilot?
- How are disruptions, security events and commercial carrier cases separated from each other?
If these questions remain unanswered, an attractive architectural foil without an operable offer is quickly created.
What SourcingBlox can do in this area
SourcingBlox does not position itself as another mobile carrier. The useful contribution lies in the architecture, introduction and operating model: limit the use case, make communication relationships and responsibilities visible, define the pilot measurably and bring together security, network, device and partner teams.
The later offer model can consist of three stages:
- Discovery & Architecture: Inventory, use case, target relationships, partner and RACI clarification.
- Pilot: limited equipment population, defined applications, test and acceptance criteria.
- Managed Cellular Zero Trust: Ongoing policy, visibility and operational support – only with confirmed scope of services and clear differentiation from the carrier.
It is not yet possible to derive a flat-rate bookable product from this. Prior to a public service commitment, Zscaler SKU and partner status, carrier/eSIM model, RACI, and pilot use case must be verified.
Conclusion: First the operating case, then the technology
Zscaler Cellular can close a real gap: Extend Zero Trust principles to mobile devices where a classic client doesn't make sense. However, the value is not created by the SIM alone. It occurs when device identity, necessary communication relationships, policy, telemetry, and support process are planned as one operating model.
The right first step is therefore not a large-scale rollout. It is a clearly defined discovery appointment with a specific device type and application.