Über Jahre hinweg hat die Branche eine einfache Geschichte erzählt: Ab in die Cloud, SASE einführen, und Security wird automatisch folgen. Das war überzeugend, und es war notwendig. Denn die Zusammenführung von Netzwerk und Sicherheit in ein cloudbasiertes Modell war ein wichtiger Schritt nach vorne. Aber das reicht nicht mehr.

Denn schaut man sich an, wie es heute in den meisten Organisationen tatsächlich aussieht, hat sich dieses Versprechen nicht vollständig erfüllt. Nicht, weil SASE falsch ist, sondern weil es nie die ganze Antwort war.

Was heute klar wird: SASE hat die Komplexität nicht eliminiert. Es hat sie verschoben: weg von der Hardware, hin in den Betrieb. Und genau dort geraten heute viele Organisationen ins Straucheln.

Auf dem Papier hat sich viel verändert. SASE-Frameworks sind implementiert. Cloud-basierte Sicherheitsservices sind ausgerollt. Zero Trust wird zumindest teilweise eingeführt. In der Praxis zeigt sich aber ein anderes Bild: Teams kämpfen weiterhin mit fragmentierter Sichtbarkeit, nicht sauber abgestimmten Policies über verschiedene Umgebungen hinweg und einer steigenden operativen Belastung.

Was eigentlich vereinfachen sollte, hat oft nur eine neue Art von Komplexität geschaffen – weniger sichtbar, aber deutlich schwerer zu beherrschen. Und hier liegt die Lücke, über die kaum gesprochen wird: Sicherheit ist implementiert. Aber sie wird nicht konsequent betrieben.

Ein wesentlicher Teil des Problems liegt darin, wie wir über Plattformen denken. Es besteht die Annahme, dass genügend integrierte Funktionen automatisch zu Kontrolle führen. Das tun sie aber nicht. Denn selbst in einer gut integrierten SASE-Umgebung muss jemand Policies definieren und pflegen, Aktivitäten überwachen, auf Vorfälle reagieren und Konfigurationen laufend anpassen, wenn sich das Geschäft verändert. Nichts davon verschwindet, nur weil die Architektur sauberer aussieht.

Somit ist das kein Technologieproblem, sondern ein Betriebsproblem.

Eine Zeit lang konnten viele Organisationen diese Komplexität noch auffangen. Das wird zunehmend schwieriger. Denn regulatorische Anforderungen nehmen zu, etwa durch NIS2 oder DORA, und verlagern Verantwortung bis in die Geschäftsleitung. Gleichzeitig beschleunigt KI die Geschwindigkeit und Komplexität von Angriffen. Und Fragen der Datensouveränität sind längst keine Theorie mehr; sie prägen konkrete Architekturentscheidungen und stehen auf der Agenda der Führungsebene.

Das alles erhöht den Druck. Sicherheit bedeutet heute nicht mehr, die richtigen Komponenten zusammenzustellen, sondern sie zu betreiben – konsistent, global und unter Druck. Und genau deshalb muss sich die Diskussion rund um SASE verändern.

Die entscheidende Frage ist nicht mehr, ob die richtigen Tools vorhanden sind. Sondern: Wer hat die Kontrolle über die Sicherheit, und zwar end-to-end?

Denn in einer verteilten, jederzeit aktiven Umgebung entsteht Kontrolle nicht allein durch Architektur. Sondern durch Umsetzung, Verantwortung und klare Zuständigkeit.

SASE hat die Grundlage für einen integrierteren Sicherheitsansatz geschaffen. Aber eine Grundlage ist kein Ergebnis. Und Sicherheit ist nichts, das man einmal implementiert und dann abhakt. Sicherheit ist etwas, das man betreibt.

Die nächste Phase von SASE wird nicht durch neue Features oder zusätzliche Funktionen definiert. Sondern dadurch, wer es schafft, das Bestehende tatsächlich zum Laufen zu bringen – in realen Umgebungen, unter realen Bedingungen.

Mit anderen Worten: SASE war der erste Schritt. Jetzt muss es funktionieren.