Edge Computing wird meistens über seine naheliegenden Vorteile erklärt: geringere Latenzen, weniger Bandbreitenbedarf, schnellere Reaktionen vor Ort. Das stimmt natürlich. Doch mit der Rechenleistung wandert auch ein Teil der Verantwortung aus der Zentrale heraus. Daten werden nicht mehr nur im Rechenzentrum oder in der Cloud verarbeitet, sondern ebenso in Filialen, Produktionsumgebungen, Gebäuden oder direkt an IoT-Gateways. Aus Sicht der IT heißt das vor allem: Der Ort, an dem entschieden, gesteuert und überwacht wird, verteilt sich. Und mit ihm verteilt sich zwangsläufig auch die Angriffsfläche.

Ein Beispiel ist der Filialbetrieb im Handel: In einer größeren Niederlassung laufen heute Self-Checkout, Kameras, digitale Preisschilder, Kühlanlagen, Gebäudeautomation, WLAN und externe Wartungszugänge parallel. Vieles davon muss lokal funktionieren, auch wenn die Verbindung zur Zentrale stockt oder kurz ganz weg ist. Die Filiale ist damit schon lange nicht mehr bloß Außenstelle. Sie ist ein digitaler Betriebsraum mit eigener Verfügbarkeitslogik, eigener Kritikalität und oft genug direkten Folgen für den Betrieb vor Ort.

Genau hier liegt der eigentliche Bruch mit der klassischen IT-Sicherheitslogik. Früher standen Rechenzentrum, WAN-Übergang und einige wenige, klar definierte Sicherheitsgrenzen im Mittelpunkt. Edge Computing löst dieses Bild nach und nach auf. Statt einiger großer Kontrollpunkte entstehen viele kleinere, teils sehr unterschiedliche Sicherheitszonen: Filialnetze, lokale Analyseplattformen, Gebäudeautomation, Fertigungszellen, Logistikflächen oder 5G-nahe Infrastrukturen. Das BSI verweist in seiner Empfehlung zur sicheren Nutzung von Edge Computing ausdrücklich auf die große Bandbreite der Anwendungsfälle, auf exponierte Einsatzorte und auf den hohen Vernetzungsgrad solcher Umgebungen [1]. ENISA ordnet Edge- und Fog-Computing im 5G-Kontext ebenfalls als Teil eines verteilten Cloud- und Netzwerkmodells ein.

Das erklärt auch, warum der Edge nicht einfach wie ein "kleines Rechenzentrum draußen" behandelt werden kann. Die Technik sitzt näher am Prozess, näher an Menschen, Maschinen und betriebsrelevanten Abläufen. Damit steigen nicht nur die Anforderungen an Verfügbarkeit und Fernadministration, sondern eben auch an Härtung, Transparenz und Segmentierung. Ein Satz aus der Herstellerperspektive bringt das dennoch ganz gut auf den Punkt: Sicherheit folgt der Rechenleistung. Die Formulierung stammt von Fortinet, beschreibt aber letztlich eine Entwicklung, die sich überall beobachten lässt. Wenn Workloads und Entscheidungen an den Rand des Netzes wandern, dann müssen Schutzmechanismen, Sichtbarkeit und Richtlinien mitwandern [2].

Wenn der Standort im Netz kein verlässliches Vertrauensmerkmal mehr ist, braucht es ein anderes Grundprinzip. Genau deshalb passt Zero Trust so gut zu Edge-Architekturen. Im europäischen Kontext ist das keine einzelne Vorschrift, sondern eher eine klare Richtung, die sich aus NIS2, den ENISA-Leitlinien und dem Gedanken von Security-by-Design ergibt. Die NIS2-Richtlinie verlangt Cybersecurity-Risikomanagement, etwa für Incident Handling, Business Continuity, Lieferkettensicherheit, den sicheren Erwerb und die Wartung von Systemen, Kryptografie und Zugriffskontrollen. ENISA nennt in ihrer technischen Umsetzungsleitlinie ausdrücklich auch Cybersecurity-by-Design und Zero-Trust-Architekturen als relevante Praxis [3].

Im Betrieb heißt das nichts anderes, als dass ein Gerät in der Filiale, im Lager oder an der Maschine nicht automatisch vertrauenswürdig ist, nur weil es "intern" steht. Vertrauen muss sich aus Identität, Kontext, Gerätezustand und zulässiger Kommunikation ableiten. Im Filialalltag klingt das zunächst sperriger, als es eigentlich ist. Kassen, Kameras, Access Points, Kühlsteuerungen, Wartungslaptops und Administrationszugänge sollten nicht über historisch gewachsene Netzfreigaben miteinander kommunizieren, sondern über klar definierte Rollen, Segmente und Richtlinien. Zero Trust ist damit weniger ein Produkt als eine Frage der Betriebsdisziplin.

Daraus ergibt sich fast automatisch ein zweiter Punkt: Netzwerk und Sicherheit lassen sich am Edge immer schlechter getrennt voneinander betreiben. Genau deshalb hat sich der Markt in Richtung integrierter Plattformen entwickelt. Zu den großen Anbietern in diesem Umfeld zählen neben Fortinet auch Cisco, HPE Aruba, Palo Alto Networks sowie VM- ware/Broadcom. Dass Fortinet hier besonders sichtbar ist, liegt an der engen Verbindung von Secure Branch, SD-WAN, Zero Trust und OT-Sicherheit. Gleichzeitig zeigt der Wettbewerb ziemlich deutlich, dass die Konvergenz von Netzwerk und Security heute eher Marktstandard als Sonderweg ist.

Die eigentliche Bewährungsprobe findet selten in der Zentrale statt, sondern draußen in der Fläche. Kleine Filialen, Lager, Werkaußenstellen oder unbemannte Servicepunkte verfügen meist über keine lokale IT, aber über Prozesse, die für Umsatz, Betrieb und Sicherheit kritisch sind. Das BSI empfiehlt deshalb, Sicherheit in Edge- und Fog-Szenarien nicht erst später nachzurüsten, sondern bereits bei Planung und Nutzung systematisch mitzudenken. Im Alltag ist das oft genau der Unterschied zwischen einer beherrschbaren Fläche und einem Sammelsurium aus Sonderkonfigurationen.

Praktisch beginnt das erst einmal mit Transparenz. Unternehmen müssen wissen, welche Systeme an einem Standort überhaupt vorhanden sind, welche davon geschäftskritisch sind, wie lange sie noch unterstützt werden und welche Datenflüsse über sie laufen. NIS2 zieht diese Linie weiter, weil die Richtlinie eben nicht nur Technik, sondern auch Governance, Lieferkettensicherheit und Managementverantwortung einfordert. Hinzu kommt mit dem Cyber Resilience Act eine zweite europäische Leitplanke: Produkte mit digitalen Elementen sollen mit weniger Schwachstellen in Verkehr gebracht werden, und Hersteller sollen Sicherheit über den gesamten Lebenszyklus hinweg ernst nehmen. Für Edge-Umgebungen ist das deshalb relevant, weil dort veraltete Gateways, schlecht gepflegte Appliances oder schwer aktualisierbare Steuerungskomponenten häufig die realistischsten Eintrittspunkte darstellen.

Gerade an dieser Stelle hilft der Blick auf bewährte Strukturmodelle. Im Beitrag zum Purdue-Modell hat der Autor die "klare Struktur und Abgrenzung der Ebenen" als den eigentlichen Sicherheitsgewinn beschrieben [4]. Genau dieser Gedanke passt auch zum Edge. Wer verteilte Standorte schützen will, muss Übergänge, Zuständigkeiten und Kommunikationsbeziehungen sauber definieren. Sonst entsteht schnell eine Infrastruktur, die zwar performant wirkt, im Ernstfall aber nur schwer kontrollierbar bleibt.

Noch anspruchsvoller wird es dort, wo Edge auf OT trifft. In der Praxis verschwimmen diese Welten immer häufiger. Gebäudeautomation, Energieversorgung, Kühltechnik, Fördertechnik oder lokale Produktionssysteme hängen längst an denselben Netzen, Plattformen und Fernwartungsmodellen wie die klassische IT. Genau daraus entstehen neue Angriffsflächen. Das BSI verweist in seinen Grundschutz-Bausteinen zur industriellen IT ausdrücklich auf hohe Verfügbarkeitsanforderungen sowie auf die Bedeutung von Anbindungszonen und DMZ-Strukturen. Für die Fernwartung im industriellen Umfeld empfiehlt das BSI, entkoppelnde Systeme möglichst in einer OT-DMZ zu platzieren.

Im Filialbeispiel betrifft das vor allem Kühlanlagen, Gebäudeleittechnik oder Logistikkomponenten. Solche Systeme werden organisatorisch oft nicht als Teil der klassischen IT wahrgenommen, technisch gehören sie aber längst zur gleichen Angriffsfläche. Eine offen erreichbare Wartungsschnittstelle, ein historisch gewachsener Zugriffspfad oder ein schlecht segmentiertes Managementnetz genügt, um Betriebs- und Sicherheitsrisiken miteinander zu verbinden. Im Purdue-Beitrag war die OT-DMZ auf Ebene 3.5 deshalb nicht bloß ein planerisches Element, sondern der kontrollierte Übergang zwischen Office-IT und Produktion. Diese Logik gilt am Edge unverändert weiter.

Ähnlich wichtig ist die Sichtbarkeit. In meinem EDR-Beitrag zur OT hat der Autor geschrieben, dass zunächst "vollständige Sichtbarkeit über digitale Assets" hergestellt werden muss, bevor Schutzmaßnahmen wirklich greifen [5]. Für Edge-Umgebungen gilt das erst recht. Wer nicht weiß, welche Sensoren, Controller, Kameras, Gateways und Wartungspfade an einem Standort aktiv sind, wird einen Vorfall weder frühzeitig erkennen noch sauber eingrenzen können. Asset-Discovery, Inventarisierung und Segmentierung sind deshalb keine Fleißarbeit, sondern Voraussetzungen für jede belastbare Edge-Sicherheitsstrategie.

Eine tragfähige Edge-Strategie beginnt nicht mit Hardware, sondern mit Klarheit. Unternehmen sollten zuerst definieren, was in ihrer Umgebung überhaupt zum Edge gehört: Filialen, IoT-Gateways, lokale Server, Gebäudeautomation, OT-Komponenten, Servicezugänge oder 5G-nahe Plattformen. Ohne ein vollständiges Bild von Standorten, Geräten, Datenflüssen und Verantwortlichkeiten bleiben Zero Trust, Segmentierung und Incident Response lückenhaft.

Im zweiten Schritt muss Vertrauen konsequent vom Standort getrennt werden. Statt pauschaler Netzfreigaben braucht es identitäts-, zustands- und kontextbasierte Zugriffe. Statt impliziter Vertrauenszonen braucht es klar definierte Kommunikationsbeziehungen. Das klingt ein wenig nach Lehrbuch, ist am Edge aber sehr konkret: weniger VPN-Zugänge, mehr segmentierte und zeitlich kontrollierte Verbindungen, weniger Sonderrechte für Wartungszugänge und mehr standardisierte Freigabeprozesse.

Ebenso wichtig ist die organisatorische Seite. Edge-Sicherheit scheitert in der Praxis selten an fehlender Technologie. Häufig fehlen einheitliche Standards, belastbare Betriebsprozesse und klare Zuständigkeiten zwischen Netzwerk, Security, OT und den Fachbereichen. Wer WAN, LAN, Zugriffskontrolle, Logging, Wartung und Incident Handling in getrennten Silos organisiert, erzeugt am Edge Reibungsverluste und Sicherheitslücken. Deshalb sollte der Edge als gemeinsames Betriebsmodell verstanden werden – mit standardisierten Grundmustern, zentraler Sichtbarkeit und lokaler Resilienz.

Schließlich muss der Edge über seinen gesamten Lebenszyklus hinweg beherrschbar bleiben. Dazu gehören Updatefähigkeit, kontrollierte Fernwartung, der Austausch nicht mehr unterstützter Komponenten, belastbare Logs und geübte Fallback-Prozesse. Im EDR-Beitrag war der entscheidende Punkt, dass OT-Sicherheit nicht mit einem Security-Tool beginnt, sondern mit Sichtbarkeit, Zonierung und verhaltensbasierter Erkennung. Für den Edge gilt dasselbe. Erst wenn Inventarisierung, Segmentierung und Anomalieerkennung zusammenspielen, wird aus verteilter IT eine belastbare Architektur.

Edge Computing ist kein entfernter Ausläufer der zentralen IT mehr, sondern der Ort, an dem Anwendungen, Daten, physische Prozesse und Sicherheitsentscheidungen zusammenlaufen. Damit verliert der klassische Perimeter weiter an Bedeutung. An seine Stelle tritt ein Sicherheitsmodell, das Identitäten, Segmentierung, Produktlebenszyklen, Telemetrie und Betriebsdisziplin in den Mittelpunkt stellt. Der Edge ist deshalb vor allem eine strategische Security-Heraus- forderung – und genau so sollte er auch behandelt werden.

Hinzu kommt der regulatorische Druck, der das Thema aus der IT-Abteilung in die Führungsetage hebt. NIS2 und der Cyber Resilience Act sind keine fernen Complianceübungen, sondern verbindliche Rahmenbedingungen mit konkreten Konsequenzen für Betreiber und Hersteller gleichermaßen. Wer Edge-Infrastrukturen betreibt, trägt künftig Verantwortung für deren Sicherheit über den gesamten Lebenszyklus – von der Inbetriebnahme bis zur Außerbetriebnahme nicht mehr unterstützter Komponenten.