Charging points, kiosks and POS systems are often located in places where no classic corporate network is available. Mobile communications create connectivity quickly – but an active SIM card does not answer any security question.
For operators, a complete life cycle counts: a device is installed, receives exactly the necessary communication channels, is monitored, diagnosed in the event of malfunctions and is safely taken out of service at the end. It is precisely at these transitions that blind spots often arise.
The devices are similar – their risks are not
A charging point communicates with a backend and, if necessary, payment or maintenance services. A kiosk needs content, management, and transactions. A POS system processes particularly sensitive business channels. Therefore, shared mobile phone access should not become an undifferentiated network.
The architecture must define the following for each device class:
- permitted goals and protocols,
- private and public application channels,
- required name resolution,
- identification of the device or port,
- Update and maintenance path,
- Monitoring and alerting needs,
- What to do in the event of exchange, loss or suspicion of manipulation.
Why an agent should not be a prerequisite
Many embedded and specialized devices do not allow the installation of an endpoint agent. This does not mean that they have to communicate unfiltered. Zscaler positions Cellular for SIM and eSIM connected devices that use cellular connectivity as a controlled path to the Zscaler platform.
This allows a policy to move closer to the device and application. Which identity features and control options are available in a specific case must be checked in the interaction of hardware, mobile phone profile, carrier integration and Zscaler configuration.
Segmentation starts with a whitelist
For specialized devices, a whitelist is often more understandable than general Internet access. The operator describes the necessary business channels and only allows the necessary destinations.
This sounds simple, but without discovery, it quickly fails due to hidden dependencies: certificate verification, time servers, update services, DNS, content delivery networks or changing cloud endpoints. A pilot must make these dependencies visible and document them instead of circumventing them via broad exceptions.
A meaningful pilot stays small and complete
A suitable pilot includes a few devices, but the entire process:
- Deploy your cellular profile and device.
- Configure allowed goals and policies.
- Test installation at a realistic location.
- Observe normal operation and blocked communication.
- Perform failure, replacement, and deactivation process.
- Reduce support and security visibility.
Charging infrastructure should include at least one real backend and maintenance path. For kiosks and POSs, central business processes as well as updates and remote support must be taken into account.
Operation means: knowing the next person in charge
In the event of a malfunction, the department initially only sees "Device offline" or "Transaction failed". For a quick diagnosis, support needs a clear chain: device, mobile status, policy event, target reachability and application.
The operating model therefore clarifies:
- what telemetry is available,
- who is allowed to view it,
- which initial check is carried out by the Service Desk,
- when carrier, security or application team are involved,
- how changes and exceptions are released,
- when inactive profiles are terminated.
SourcingBlox Combines Architecture and Handover
SourcingBlox starts with device class and business path, not with a blanket product commitment. Discovery & Architecture clarifies feasibility and dependencies. A pilot checks the technology and workflow. Only then will a repeatable rollout and operating model be designed.
Before an offer can be made, the Zscaler SKU, carrier or eSIM partner, country coverage, hardware characteristics and responsibility model must be confirmed. This examination protects both sides from a promise that does not hold up in a concrete operation.
The result is a controlled connection for specialized equipment – with a traceable path from installation to decommissioning.
Charging points: Plan availability and maintenance separately
When it comes to charging infrastructure, operating data, billing, authorization, firmware and remote maintenance are different ways. They can have different owners and protection needs. A single broad clearance may speed up the pilot, but it complicates later diagnosis and governance.
A meaningful data flow matrix describes the source, destination, protocol, technical purpose, expected behavior and responsible persons for each path. Changes to the backend or certificates can thus be tested in a targeted manner. The replacement of a charging controller also becomes a defined lifecycle event instead of a manual exception.
The cellular path can support availability, but it does not replace an end-to-end availability design. Power supply, hardware, wireless coverage, backend, and payment services remain their own dependencies.
Kiosk and POS: Updates belong in the security model
In addition to the actual application, kiosk and POS systems usually require operating system, signature, content or application updates. If these targets are only discovered retrospectively, the positive list grows uncontrollably.
The pilot therefore observes at least one complete update cycle. The following are examined:
- which domains and services are actually targeted,
- whether goals are stable or dynamic,
- how certificate and time verification work,
- whether maintenance windows or bandwidth limits are necessary,
- how to detect failed updates,
- who releases a new dependency.
A separate technical and compliance review remains required for payment systems and regulatory requirements. A secure network connection alone does not prove compliance.
From a hundred individual devices to a few operating profiles
Scaling succeeds when devices are not improvised individually. Operators define a few profiles such as "charging point standard", "kiosk with content" or "POS with maintenance access". Each profile contains data paths, policy, monitoring, owner and lifecycle.
A deviation is documented as a deliberate variant. This allows the team to see if a new requirement really needs its own class or is covered by an existing profile.
Making it measurable whether the operation is working
Suitable measuring points are not only online odds. Time to accountability, profiles with no active device, unscheduled shares, blocked unknown destinations, age of exceptions, and success rate of scheduled updates are also significant.
These metrics link security to operational quality. They show where a policy is too narrow, a discovery is incomplete, or a handover process is not yet mature.