SASE war Schritt eins. Jetzt muss es funktionieren.

Jahrelang erzählte die Branche eine einfache Geschichte: Geht in die Cloud, führt SASE ein, und die Sicherheit kommt von selbst. Das war überzeugend, und es war notwendig. Netzwerk und Security in einem Cloud-Modell zusammenzuführen, war ein großer Schritt nach vorn. Aber er reicht nicht mehr aus.

Denn wer sich anschaut, wie die Dinge in den meisten Organisationen heute tatsächlich laufen, sieht: Dieses Versprechen hat sich nicht vollständig eingelöst. Nicht weil SASE falsch wäre, sondern weil es nie die ganze Antwort war.

Eines ist inzwischen klar: SASE hat die Komplexität nicht beseitigt. Es hat sie verlagert. Weg von der Hardware, hinein in den Betrieb. Und genau an dieser Verschiebung arbeiten sich viele Organisationen jetzt ab.

Auf dem Papier hat sich viel verändert. SASE-Frameworks sind etabliert. Cloud-Security-Services sind ausgerollt. Zero Trust wird eingeführt, zumindest in Teilen.

In der Praxis sieht das Bild jedoch anders aus: Teams kämpfen weiterhin mit fragmentierter Sichtbarkeit, mit Policies, die über Umgebungen hinweg nicht recht zusammenpassen, und mit einer wachsenden operativen Last. Was vereinfachen sollte, hat in vielen Fällen nur eine andere Art von Komplexität geschaffen - eine, die schwerer zu erkennen, aber viel schwerer zu beherrschen ist.

Das ist die Lücke, über die die Branche zu wenig spricht: Security ist zwar ausgerollt, aber sie wird nicht konsequent betrieben.

Ein großer Teil des Problems liegt darin, wie wir über Plattformen denken. Es gibt die stillschweigende Annahme: Wenn man nur genügend Funktionen zusammenbringt, wird sich das System schon irgendwie selbst verwalten. Dass Integration sich in Kontrolle übersetzt.

Aber so funktioniert es nicht: Selbst in einem gut integrierten SASE-Setup muss immer noch jemand Policies definieren und pflegen, Aktivitäten überwachen, auf Incidents reagieren und Konfigurationen laufend an das sich verändernde Geschäft anpassen. Nichts davon verschwindet, nur weil die Architektur aufgeräumter aussieht.

Das ist kein Technologieproblem. Es ist ein operatives.

Eine Zeit lang konnten viele Organisationen diese Komplexität auffangen. Doch das wird zunehmend schwierig. Die Regulierung zieht an - Rahmenwerke wie NIS2 und DORA verlagern die Verantwortung weiter nach oben in die Organisation. Gleichzeitig beschleunigt KI sowohl das Tempo als auch die Raffinesse von Angriffen. Und Fragen der Datensouveränität sind längst nicht mehr theoretisch; sie landen in Vorstandssitzungen und prägen Architekturentscheidungen.

All das legt die Messlatte höher. Bei Security geht es nicht mehr darum, die richtigen Komponenten zusammenzustellen. Es geht darum, sie zu betreiben: konsistent, global und unter Druck. Deshalb muss sich die Diskussion um SASE verschieben.

Die Frage ist nicht mehr, ob die richtigen Tools vorhanden sind. Sondern wer die Security tatsächlich End-to-End im Griff hat. Denn in einer verteilten, always-on Umgebung entsteht Kontrolle nicht durch Architektur allein. Sie entsteht durch Umsetzung, durch Ownership und durch Verantwortung.

SASE hat das Fundament für einen integrierteren Sicherheitsansatz gelegt. Aber ein Fundament ist noch kein Ergebnis. Und Security ist nichts, was man einmal zusammenbaut und dann abhakt. Security ist etwas, das man betreibt.

Die nächste Phase von SASE wird nicht durch neue Features oder zusätzliche Funktionen definiert. Sie wird dadurch definiert, wer es tatsächlich zum Funktionieren bringt - in realen Umgebungen, unter realen Bedingungen.

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