Was bedeutet Zscaler Cellular?
Zscaler Cellular ist ein Ansatz, Mobilfunkverkehr von Geräten über einen kontrollierten, policybasierten Security-Pfad zu führen. Entscheidend ist nicht nur die SIM, sondern die Ende-zu-Ende-Architektur aus Carrier, Identität, Zielressourcen, Policy, Telemetrie und Verantwortung.
Das Problem: Agentenlose Geräte bleiben zwischen Mobilfunk und Unternehmensnetz hängen
Viele IoT- und OT-Geräte erlauben keinen klassischen Security-Agenten. Gleichzeitig benötigen sie Zugriff auf wenige APIs, Steuerungsdienste oder Cloud-Endpunkte. Private APNs, VPNs und lokale Firewalls können das lösen, erzeugen aber häufig zusätzliche Infrastruktur und schwer skalierbare Ausnahmen.
Ein Zero-Trust-Modell muss deshalb pro Gerätetyp klären, welche Ziele erreichbar sein dürfen, wie Geräte identifiziert werden, was bei Verlust oder Missbrauch geschieht und wer Carrier-, Plattform- und Betriebsfehler bearbeitet.
Ein Betreiber verwaltet tausende Ladepunkte mit Mobilfunkanbindung. Jeder Ladepunkt benötigt definierte Backend-Ziele, darf aber nicht als allgemeiner Netzwerkteil behandelt werden. Ein Pilot muss deshalb SIM/eSIM, Carrier-Routing, erlaubte Ziele, Ausfallszenarien und Betriebsübergaben gemeinsam testen.
Die fünf technischen Ebenen
Eine belastbare Cellular-Architektur trennt Verbindung, Identität, Zugriff und Betrieb.
Gerät & SIM
Gerätetyp, Modem, SIM/eSIM-Lifecycle, Besitz und Sperrprozess.
Carrier & Datenpfad
Roaming, APN, Breakout, Region, Latenz und Ausfallverhalten.
Policy & Ziele
Erlaubte FQDNs, IPs, Protokolle, APIs und Richtung des Datenverkehrs.
Telemetrie
Verbindungsstatus, Policy-Ereignisse, Gerätezuordnung und Incident-Daten.
Betrieb
RACI für Carrier, Zscaler, Gerätehersteller, Kunde und Managed Service.
Pilot
Repräsentativer Use Case mit Messpunkten, Ausnahmefällen und Rückfallpfad.
Was muss vor einer Entscheidung geprüft werden?
- Welche Gerätetypen und Firmwarestände existieren?
- Welche Ziele und Protokolle werden wirklich benötigt?
- Welcher Carrier- und eSIM-Partner ist bestätigt?
- Wie werden Geräte eindeutig zugeordnet und gesperrt?
- Welche Region-, Datenschutz- und Verfügbarkeitsanforderungen gelten?
- Wer übernimmt Support und Eskalation je Fehlerdomäne?
Architekturhinweis: Zscaler Cellular ergänzt OT-Segmentierung und Gerätesicherheit. Ein geeigneter Pilot berücksichtigt Gerätetyp, unterstützten Produktumfang, Carrier-/eSIM-Modell und den vollständigen Betriebsweg.
Wie SourcingBlox den Use Case belastbar macht
Wir beginnen mit einem Gerätetyp und einem klaren Betriebsziel.
Discovery & Architecture
Gerät, Datenweg, Ziele, Carrier, Policy und RACI als prüfbares Zielbild erfassen.
Pilot
Einen repräsentativen Use Case mit Messpunkten, Störungen und Rückfalloption testen.
Managed Cellular Zero Trust
Nach Abnahme Monitoring, Changes, Eskalationen und regelmäßige Policy-Reviews strukturieren.
Typische Fehler
- Nur über die SIM sprechen und Backend-Ziele nicht modellieren.
- Roaming, Ausfall und Carrier-Verantwortung nicht testen.
- IoT-, OT- und Nutzergeräte in dieselbe Policy-Schablone pressen.
- Ohne bestätigte SKU und Partnerrollen öffentlich Leistungen versprechen.
Häufige Fragen
Braucht jedes Gerät einen Agenten?
Der konkrete Cellular-Ansatz zielt gerade auf Geräte, bei denen ein klassischer Agent nicht sinnvoll ist. Die Eignung hängt dennoch von Gerät, Mobilfunkprofil und unterstütztem Datenpfad ab.
Ersetzt Cellular eine OT-Firewall?
Nicht automatisch. Zonen, lokale Kommunikation und Safety-Anforderungen können zusätzliche Kontrollen erfordern.
Womit beginnt ein Pilot?
Mit einem Gerätetyp, wenigen erlaubten Zielen und klaren Kriterien für Verbindung, Policy, Latenz, Telemetrie und Support.
Einen IoT-/OT-Use-Case technisch einordnen.
Wir prüfen Gerät, Carrier, Datenweg, Policy und Betriebsgrenzen, bevor ein Pilot geplant wird.
Verwandte Inhalte
Quellen und weiterführende Informationen
Produktumfang, Verfügbarkeit und Partnerrollen sind vor Veröffentlichung aktuell zu verifizieren.