Scanners in the warehouse, mobile routers in the vehicle, telemetry units and service devices have one thing in common: they work where classic location and client architectures reach their limits. Many of these systems do not have a suitable security agent. At the same time, they need reliable connections to cloud or private applications.
The technical challenge is therefore not only connectivity. Companies must identify devices, control data paths, clarify responsibilities and make operations manageable across carrier, mobile communications and security boundaries.
Why conventional patterns are becoming difficult
A managed notebook can provide identity, device health, and security client. A scanner, router or embedded device often cannot do this. Classic VPN patterns then solve a transport route, but do not automatically create a suitable segmentation or transparency.
In logistics and field service, changing locations, mobile coverage, different generations of hardware and distributed responsibilities exacerbate the problem. A fault can be caused by the device, the mobile phone profile, the carrier, the security service, DNS or the target application.
What Zscaler Cellular addresses
Zscaler describes Cellular as cloud-based Zero Trust access for SIM or eSIM-connected devices, even if they can't run an agent. Data traffic is routed into the Zscaler platform via cellular integration. Public product information mentions secure Internet and private application access as well as central policy control as areas of application.
This is an important technical basis. However, whether a specific use case fits depends on the device, carrier or eSIM model, region, protocols and target applications.
Discovery: Don't start with the SIM list
A resilient discovery connects technical and operational issues:
- Which device class should be connected?
- Who owns the device, mobile phone contract and application?
- What goals and protocols are needed?
- Is the traffic only outbound or are there incoming requests?
- What device identity is available?
- Which regions and roaming scenarios are relevant?
- How are configuration, replacement, and decommissioning controlled?
- Which logs does support or security need?
The answers form a controllable use case. A mere number of active SIM cards is not enough.
Pilot: Testing a full commute
The pilot was not supposed to test an artificial laboratory data stream, but a complete work path. In field service, this could be the access of a service device to a private application. In logistics, it can be a scanner with a cloud backend and a defined failure scenario.
Acceptance criteria include:
- successful initial activation,
- Correct Internet and application access,
- Behavior in the event of unauthorized targets,
- roaming or network switching, where relevant;
- Visibility for operations and support,
- Procedure in case of lost or replaced hardware,
- Diagnostic route in case of malfunction.
Clarify roles at the transitions
Cellular projects often touch multiple supply chains: device manufacturers, carriers or eSIM partners, Zscaler, internal network and security teams, and business application owners. That's why a RACI is not a project bureaucracy, but part of the technical solution.
The distinction is particularly important:
- Who activates and deactivates profiles?
- Who sees connection and security events?
- Who checks first in the event of a malfunction?
- Who approves new targets?
- Who documents device changes?
- Who controls costs and usage?
Without these answers, a technically functioning connection can still fail in everyday life.
From Pilot to Managed Cellular Zero Trust
After the pilot, the actual scaling work begins: repeatable device classes, policy templates, monitoring, service handover, and lifecycle processes. A good operating model doesn't just show that a device is online. It makes it understandable which data path is allowed, what change has taken place and who needs to act next.
SourcingBlox structures this path into Discovery & Architecture, a limited pilot, and an optional managed operating model. Each market or project promise is preceded by the Zscaler SKU, carrier or eSIM partner, region, and pilot use case.
This creates a controlled, operable access path from mobile connectivity.
Logistics: When the scanner works, but the process stops
In a warehouse, a scanner can be logged into the mobile network and still not complete a booking. A clean diagnostic path must distinguish whether the device has a valid profile, whether the intended data path is allowed, whether DNS and backend are reachable and whether the application itself responds.
For support, this means that the device ID must be uniquely assigned to a location, mobile phone profile and business process. Policy events and connection states need a common time base. Only then can the first level qualify a fault instead of passing it on to the network, carrier and application at the same time.
In architecture, therefore, not only permitted goals are documented. Telemetry, naming convention, replacement device and escalation handover are also part of the work product.
Field Service: Change connections, responsibility remains
A service device moves between regions and mobile networks. The employee expects the order, documentation and private service application to remain available. At the same time, the company must prevent the device from gaining general, uncontrolled access.
A pilot should therefore not only take place at the main location. He needs at least a realistic field service route, a network change and a situation with limited coverage. It also tests how the process continues if the connection is temporarily unavailable. This offline or fallback logic is a property of the application and the work process, not just the security platform.
Lifecycle: From the first profile to safe decommissioning
As the number of devices grows, the lifecycle becomes more important than the individual configuration:
- An eligible order triggers provisioning.
- Device, profile, owner and purpose are linked.
- The intended policy is assigned automatically or in a controlled manner.
- Usage and deviations are observed.
- Replacement and repair follow a documented procedure.
- In the event of loss or termination of the contract, access will be terminated promptly.
Metrics can include active profiles with no associated device, inactive devices, repeated policy violations, diagnosis time, and age of open exceptions.
When a use case is not yet ready for a pilot
A pilot should not start if the target application is unknown, no one is responsible for the mobile phone profile, or it remains unclear which partner supplies which component. "We test the connection first" otherwise only produces a technical success without reliable proof of operation.
A use case is ready for a pilot if the device, region, carrier/eSIM model, destination paths, owner, test cases and termination criteria have been named. It is precisely this clarity that is the first measurable value of discovery.