Scanner im Lager, mobile Router im Fahrzeug, Telemetrieeinheiten und Servicegeräte haben eine Gemeinsamkeit: Sie arbeiten dort, wo klassische Standort- und Client-Architekturen an Grenzen stoßen. Viele dieser Systeme besitzen keinen geeigneten Security-Agenten. Gleichzeitig benötigen sie zuverlässige Verbindungen zu Cloud- oder privaten Anwendungen.
Die technische Herausforderung ist damit nicht nur Konnektivität. Unternehmen müssen Geräte identifizieren, Datenwege kontrollieren, Zuständigkeiten klären und den Betrieb über Carrier-, Mobilfunk- und Security-Grenzen hinweg beherrschbar machen.
Warum herkömmliche Muster schwierig werden
Ein verwaltetes Notebook kann Identität, Gerätezustand und Security-Client bereitstellen. Ein Scanner, Router oder Embedded-Gerät kann das häufig nicht. Klassische VPN-Muster lösen dann zwar einen Transportweg, schaffen aber nicht automatisch eine passende Segmentierung oder Transparenz.
In Logistik und Field Service verschärfen wechselnde Orte, Mobilfunkabdeckung, unterschiedliche Hardwaregenerationen und verteilte Verantwortlichkeiten das Problem. Eine Störung kann am Gerät, am Mobilfunkprofil, beim Carrier, im Security-Service, an DNS oder an der Zielanwendung liegen.
Was Zscaler Cellular adressiert
Zscaler beschreibt Cellular als cloudbasierten Zero-Trust-Zugriff für SIM- oder eSIM-verbundene Geräte, auch wenn diese keinen Agenten ausführen können. Der Datenverkehr wird über Mobilfunkintegration in die Zscaler-Plattform geführt. Öffentliche Produktinformationen nennen sichere Internet- und private Anwendungszugriffe sowie zentrale Policy-Kontrolle als Einsatzfelder.
Das ist eine wichtige technische Grundlage. Ob ein konkreter Use Case passt, hängt jedoch von Gerät, Carrier- beziehungsweise eSIM-Modell, Region, Protokollen und Zielanwendungen ab.
Discovery: Nicht mit der SIM-Liste beginnen
Eine belastbare Discovery verbindet technische und betriebliche Fragen:
- Welche Geräteklasse soll angebunden werden?
- Wer besitzt Gerät, Mobilfunkvertrag und Anwendung?
- Welche Ziele und Protokolle werden benötigt?
- Ist der Verkehr nur ausgehend oder gibt es eingehende Anforderungen?
- Welche Geräteidentität steht zur Verfügung?
- Welche Regionen und Roaming-Szenarien sind relevant?
- Wie werden Konfiguration, Austausch und Stilllegung gesteuert?
- Welche Logs benötigt Support oder Security?
Die Antworten bilden einen kontrollierbaren Use Case. Eine bloße Zahl aktiver SIM-Karten reicht nicht.
Pilot: Einen vollständigen Arbeitsweg testen
Der Pilot sollte keinen künstlichen Labordatenstrom prüfen, sondern einen vollständigen Arbeitsweg. Im Field Service könnte das der Zugriff eines Servicegeräts auf eine private Anwendung sein. In der Logistik kann es ein Scanner mit Cloud-Backend und definiertem Ausfallszenario sein.
Zu den Abnahmekriterien gehören:
- erfolgreiche Erstaktivierung,
- korrekter Internet- und Anwendungszugriff,
- Verhalten bei nicht erlaubten Zielen,
- Roaming- oder Netzwechsel, sofern relevant,
- Sichtbarkeit für Betrieb und Support,
- Ablauf bei verlorener oder ausgetauschter Hardware,
- Diagnoseweg bei Störung.
Rollen an den Übergängen klären
Cellular-Projekte berühren oft mehrere Lieferketten: Gerätehersteller, Carrier oder eSIM-Partner, Zscaler, interne Netz- und Security-Teams sowie fachliche Anwendungseigner. Deshalb ist ein RACI keine Projektbürokratie, sondern Teil der technischen Lösung.
Besonders wichtig ist die Abgrenzung:
- Wer aktiviert und deaktiviert Profile?
- Wer sieht Verbindungs- und Security-Ereignisse?
- Wer prüft zuerst bei einer Störung?
- Wer genehmigt neue Ziele?
- Wer dokumentiert Gerätewechsel?
- Wer kontrolliert Kosten und Nutzung?
Ohne diese Antworten kann eine technisch funktionierende Verbindung im Alltag trotzdem scheitern.
Vom Pilot zum Managed Cellular Zero Trust
Nach dem Pilot beginnt die eigentliche Skalierungsarbeit: wiederholbare Geräteklassen, Policy-Templates, Monitoring, Serviceübergabe und Lifecycle-Prozesse. Ein gutes Betriebsmodell zeigt nicht nur, dass ein Gerät online ist. Es macht verständlich, welcher Datenweg erlaubt ist, welche Änderung stattgefunden hat und wer als Nächstes handeln muss.
SourcingBlox strukturiert diesen Weg in Discovery & Architecture, einen begrenzten Pilot und ein optionales Managed-Betriebsmodell. Vor jedem Markt- oder Projektversprechen werden Zscaler-SKU, Carrier- beziehungsweise eSIM-Partner, Region und Pilot-Use-Case bestätigt.
So entsteht aus Mobilfunkkonnektivität ein kontrollierter, betreibbarer Zugriffspfad.
Logistik: Wenn der Scanner funktioniert, aber der Prozess steht
In einem Lager kann ein Scanner im Mobilfunknetz eingebucht sein und trotzdem keine Buchung abschließen. Ein sauberer Diagnoseweg muss unterscheiden, ob das Gerät ein gültiges Profil besitzt, ob der vorgesehene Datenweg erlaubt wird, ob DNS und Backend erreichbar sind und ob die Anwendung selbst antwortet.
Für den Support bedeutet das: Die Geräte-ID muss eindeutig einem Standort, Mobilfunkprofil und fachlichen Prozess zugeordnet sein. Policy-Ereignisse und Verbindungsstatus benötigen eine gemeinsame Zeitbasis. Erst dann kann der First Level eine Störung qualifizieren, statt sie gleichzeitig an Netzwerk, Carrier und Anwendung weiterzugeben.
Bei der Architektur werden deshalb nicht nur erlaubte Ziele dokumentiert. Auch Telemetrie, Namenskonvention, Ersatzgerät und Eskalationsübergabe gehören zum Arbeitsprodukt.
Field Service: Verbindungen wechseln, Verantwortung bleibt
Ein Servicegerät bewegt sich zwischen Regionen und Mobilfunknetzen. Der Mitarbeitende erwartet, dass Auftrag, Dokumentation und private Serviceanwendung verfügbar bleiben. Das Unternehmen muss zugleich verhindern, dass das Gerät einen allgemeinen, unkontrollierten Zugang erhält.
Ein Pilot sollte daher nicht nur am Hauptstandort stattfinden. Er benötigt mindestens eine realistische Außendienststrecke, einen Netzwechsel und eine Situation mit eingeschränkter Abdeckung. Außerdem wird getestet, wie der Prozess weiterläuft, wenn die Verbindung vorübergehend nicht verfügbar ist. Diese Offline- oder Rückfalllogik ist eine Eigenschaft der Anwendung und des Arbeitsprozesses, nicht allein der Security-Plattform.
Lifecycle: Vom ersten Profil bis zur sicheren Stilllegung
Mit wachsender Gerätezahl wird der Lifecycle wichtiger als die einzelne Konfiguration:
- Ein berechtigter Auftrag löst die Bereitstellung aus.
- Gerät, Profil, Owner und Zweck werden verknüpft.
- Die vorgesehene Policy wird automatisiert oder kontrolliert zugewiesen.
- Nutzung und Abweichungen werden beobachtet.
- Austausch und Reparatur folgen einem dokumentierten Verfahren.
- Bei Verlust oder Vertragsende wird der Zugriff zeitnah beendet.
Die Kennzahlen dazu können aktive Profile ohne zugeordnetes Gerät, inaktive Geräte, wiederholte Policy-Verstöße, Diagnosezeit und Alter offener Ausnahmen umfassen.
Wann ein Use Case noch nicht pilotbereit ist
Ein Pilot sollte nicht starten, wenn die Zielanwendung unbekannt ist, niemand das Mobilfunkprofil verantwortet oder unklar bleibt, welcher Partner welche Komponente liefert. „Wir testen erst einmal die Verbindung“ erzeugt sonst nur einen technischen Erfolg ohne belastbaren Betriebsnachweis.
Pilotbereit ist ein Use Case, wenn Gerät, Region, Carrier-/eSIM-Modell, Zielwege, Owner, Testfälle und Abbruchkriterien benannt sind. Genau diese Klarheit ist der erste messbare Wert der Discovery.