Ein Notebook ist für moderne Security-Teams ein vergleichsweise dankbares Endgerät. Es besitzt ein Betriebssystem, eine verwaltbare Identität und meist einen Client, über den Zugriffe kontrolliert werden können. Bei einem Ladepunkt, einem Kassenterminal, einem Fahrzeug-Gateway oder einem Industrie-Tablet sieht die Lage anders aus. Diese Geräte kommunizieren oft über Mobilfunk, laufen jahrelang im Feld und lassen sich nicht wie ein Arbeitsplatzrechner behandeln.
Genau dort entsteht eine Lücke zwischen Zero-Trust-Strategie und Betriebsrealität. Die Organisation hat vielleicht bereits Zugriffsregeln für Benutzer und Standorte modernisiert. Der Mobilfunkbestand bleibt trotzdem in separaten APNs, privaten Netzen, VPN-Konstruktionen und Carrier-Portalen verteilt. Security sieht einen Teil der Kommunikation, das Netzwerkteam einen anderen und der Gerätebetreiber oft nur, ob eine SIM aktiv ist.
Die entscheidende Frage lautet deshalb nicht: „Wie bringen wir noch einen Agenten auf das Gerät?“ Sie lautet: „Wie bekommen wir Identität, Richtlinie und Beobachtbarkeit an einen Kommunikationsweg, auf dem ein Agent häufig gar nicht möglich ist?“
Das Problem beginnt nicht bei der SIM
Mobilfunk wirkt auf den ersten Blick wie ein Konnektivitätsthema. In der Praxis hängen daran jedoch vier verschiedene Entscheidungen:
- Welches Gerät darf über welche Verbindung kommunizieren?
- Welche Internet- oder privaten Ziele sind für dieses Gerät erforderlich?
- Wie wird unerwartetes Verhalten erkannt?
- Wer kann bei einer Störung zwischen Gerät, Mobilfunk, Zielanwendung und Sicherheitsrichtlinie unterscheiden?
Ein klassisches Netzmodell beantwortet diese Fragen häufig mit Segmenten und pauschalen Vertrauenszonen. Das skaliert schlecht, wenn Tausende Geräte in unterschiedlichen Ländern, Netzen und Betriebsmodellen hinzukommen. Außerdem wird ein Gerät nicht automatisch vertrauenswürdig, nur weil es eine bekannte SIM verwendet oder aus einem privaten APN kommt.
Zero Trust dreht diese Logik um: Kommunikation wird auf den notwendigen Zweck begrenzt. Die Architektur fragt nach dem konkreten Gerät, dem Ziel und der erlaubten Beziehung – nicht danach, ob sich der Verkehr „im internen Netz“ befindet.
Was Zscaler Cellular technisch verspricht
Zscaler beschreibt Cellular als Lösung für sichere, skalierbare Mobilfunkkonnektivität von IoT- und mobilen Geräten. Die öffentlich dokumentierte Architektur besteht aus Zscaler SIM und Zscaler Cellular Edge. Der Mobilfunkverkehr wird zur Zero Trust Exchange geführt und dort mit ZIA- beziehungsweise ZPA-Richtlinien verbunden.
Für agentenlose Geräte ist ein Detail besonders relevant: Laut Zscaler benötigt ein über eine Zscaler SIM angebundenes Gerät keinen zusätzlichen Software-Agenten. Richtlinien können in der dokumentierten Architektur unter anderem auf IP-Adresse, IMEI oder IMSI Bezug nehmen. Zscaler nennt als Beispiele Verkaufsautomaten, Ladeinfrastruktur, Maschinen sowie Tablets und Kiosks.
Das ist kein nebensächlicher Komfortgewinn. Bei langlebigen oder spezialisierten Geräten entscheidet die Agentenfrage oft darüber, ob ein Sicherheitsmodell praktisch ausrollbar ist. Wenn die Kontrolle in Konnektivität und Policy Enforcement verlagert wird, kann ein Unternehmen Geräte einbeziehen, die für klassische Endpoint-Mechanismen ungeeignet sind.
Trotzdem ist „agentenlos“ kein Synonym für „automatisch sicher“. Die Wirkung hängt weiterhin von einem sauberen Gerätebestand, klaren Kommunikationsbeziehungen, passenden Richtlinien und einem belastbaren Betriebsprozess ab.
Drei typische Einsatzmuster
1. Ladeinfrastruktur und verteilte Energiekomponenten
Ein Ladepunkt benötigt Verbindungen zu Backend, Monitoring und gegebenenfalls Wartungsdiensten. Er braucht aber keinen beliebigen Zugriff auf interne Netze. Ein tragfähiger Pilot modelliert deshalb zuerst die tatsächlich erforderlichen Ziele und Protokolle. Anschließend wird geprüft, wie Ausfälle, Roaming, Wartung und Anbieterwechsel behandelt werden.
2. Kiosk, POS und Field Service
Kiosk- und POS-Geräte stehen außerhalb kontrollierter Bürostandorte. Ein Techniker-Tablet wechselt zusätzlich zwischen Regionen und Netzen. Hier ist die Kombination aus begrenzter Kommunikation und zentral sichtbarer Telemetrie interessant. Der Pilot muss jedoch reale Transaktionen, Updates, Supportzugriffe und Offline-Szenarien abbilden – nicht nur eine erfolgreiche Demo-Verbindung.
3. Industrie- und IoT-nahe Geräte
Maschinen-Gateways, Sensorik und mobile Steuergeräte besitzen oft lange Lebenszyklen. Änderungen am Gerät sind teuer oder nur in Wartungsfenstern möglich. Ein agentenloser Zugang kann die Einführung erleichtern. Vorher muss aber klar sein, welche Verantwortung Zscaler Cellular übernimmt und welche weiterhin bei Gerätehärtung, Applikationssicherheit, OT-Zonierung und Prozesssicherheit liegt.
So sieht ein belastbarer Discovery- und Pilotprozess aus
Ein sinnvoller Einstieg beginnt nicht mit einer SIM-Bestellung, sondern mit einem begrenzten Use Case.
Schritt 1: Bestand und Verantwortung klären. Welche Gerätetypen, Länder, Carrier, Verträge, APNs und Zielanwendungen sind betroffen? Wem gehören Gerät, Anwendung, Mobilfunkvertrag, Security Policy und Supportprozess?
Schritt 2: Kommunikationsbeziehungen erfassen. Welche Ziele und Protokolle sind fachlich notwendig? Welche Verbindungen sind nur historisch gewachsen? Welche Rückkanäle oder Wartungszugriffe müssen berücksichtigt werden?
Schritt 3: Architektur und Verfügbarkeit prüfen. Passt der dokumentierte Zscaler-Cellular-Funktionsumfang zum Land, Carrier, Gerätetyp und bestehenden ZIA-/ZPA-Modell? Welche SKU, SIM- beziehungsweise eSIM-Variante und welche Partnerleistung sind erforderlich?
Schritt 4: Pilotkriterien festlegen. Ein Pilot braucht mehr als „Gerät ist online“. Gemessen werden sollten mindestens erfolgreiche Fachtransaktionen, Richtlinientreffer, Sichtbarkeit, Störungsdiagnose, Failover-Verhalten und operativer Aufwand.
Schritt 5: Betriebsübergabe testen. Wer reagiert auf eine auffällige SIM, eine unterbrochene Verbindung oder eine blockierte Zielbeziehung? Ein RACI für Carrier, Gerätebetrieb, Anwendung, Netzwerk, Security und Dienstleister gehört zum Ergebnis.
Fünf Fragen, die vor dem Angebot beantwortet sein müssen
- Ist Zscaler Cellular für die benötigten Länder, Carrier und Gerätevarianten verfügbar?
- Welche ZIA-/ZPA-Lizenzen, Cellular-SKUs und Partnerleistungen werden tatsächlich benötigt?
- Wer stellt SIM oder eSIM bereit und verantwortet Aktivierung, Austausch und Stilllegung?
- Welche Zielanwendung eignet sich für einen begrenzten, messbaren Pilot?
- Wie werden Störung, Security-Ereignis und kommerzieller Carrier-Fall voneinander getrennt?
Wenn diese Fragen offenbleiben, entsteht schnell eine attraktive Architekturfolie ohne betreibbares Angebot.
Was SourcingBlox in diesem Thema leisten kann
SourcingBlox positioniert sich nicht als weiterer Mobilfunkanbieter. Der sinnvolle Beitrag liegt in Architektur, Einführung und Betriebsmodell: den Use Case begrenzen, Kommunikationsbeziehungen und Verantwortlichkeiten sichtbar machen, den Pilot messbar definieren und Security-, Netzwerk-, Geräte- und Partnerteams zusammenführen.
Das spätere Angebotsmodell kann aus drei Stufen bestehen:
- Discovery & Architecture: Bestand, Use Case, Zielbeziehungen, Partner- und RACI-Klärung.
- Pilot: begrenzte Gerätepopulation, definierte Anwendungen, Test- und Abnahmekriterien.
- Managed Cellular Zero Trust: laufende Richtlinien-, Sichtbarkeits- und Betriebsunterstützung – nur mit bestätigtem Leistungsumfang und klarer Abgrenzung zum Carrier.
Noch ist daraus kein pauschal buchbares Produkt abzuleiten. Vor einer öffentlichen Leistungszusage müssen Zscaler-SKU und Partnerstatus, Carrier-/eSIM-Modell, RACI und Pilot-Use-Case bestätigt sein.
Fazit: Erst der Betriebsfall, dann die Technologie
Zscaler Cellular kann eine reale Lücke schließen: Zero-Trust-Prinzipien auf Mobilfunkgeräte ausdehnen, auf denen ein klassischer Client nicht sinnvoll ist. Der Wert entsteht aber nicht durch die SIM allein. Er entsteht, wenn Geräteidentität, notwendige Kommunikationsbeziehungen, Richtlinie, Telemetrie und Supportprozess als ein Betriebsmodell geplant werden.
Der richtige erste Schritt ist deshalb kein Großrollout. Es ist ein klar abgegrenzter Discovery-Termin mit einem konkreten Gerätetyp und einer konkreten Anwendung.