Sophos SG UTM End-of-Life: 30. Juni 2026

Sophos SG Hardware mit UTM OS erreicht End-of-Life am 30. Juni 2026. Danach: keine Updates, keine Sicherheitspatches, kein Support. Wenn Sie noch Sophos UTM betreiben, haben Sie etwa 7 Monate für die Migration.

Timeline

Ihre Optionen

EOL-Ankündigungen sind ein guter Zeitpunkt zum Reevaluieren. Bietet die jetzige Lösung noch alles, was Sie heute an Anforderungen haben? Vielleicht wurde die UTM vor 8 Jahren aus Gründen gewählt, die nicht mehr gelten. Vielleicht haben sich Ihre Anforderungen geändert. Vielleicht sind Sie rausgewachsen.

Bei Sophos bleiben: XGS

Sophos empfiehlt die Migration zur XGS Firewall mit dem neuesten Firewall OS. Neue Plattform, neues Interface, neue Features. Wenn Sie mit Sophos zufrieden sind und sie zu Ihren Anforderungen passen, ist das der einfachste Weg.

Anderer Hersteller

Palo Alto, Fortinet, Check Point—jeder hat Stärken je nach Ihren Anforderungen. Besseres Logging und Analytics gebraucht? Engere Integration mit Ihrem SIEM gewünscht? Bestimmte Compliance-Zertifizierungen gesucht? Verschiedene Hersteller, verschiedene Stärken.

Managed Firewall von uns

Wir bieten Managed Firewalls basierend auf Cisco ASAv. Eine echte Firewall—Stateful Packet Inspection, ACLs, NAT. Kein "Next-Gen"-Bloat. IDS/IPS, Application Control, Content Filtering gehören auf andere Systeme. Nicht auf die Firewall. Wir kümmern uns um Hardware, Updates, Monitoring und Regeländerungen. Sie konzentrieren sich auf Ihr Business.

Wir helfen bei der Auswahl

Wir sind herstellerunabhängig bei Empfehlungen. Wir verstehen Ihre Architektur, Ihre Anforderungen, Ihr Budget—und empfehlen was wirklich passt. Manchmal ist das bei Sophos bleiben. Manchmal ein anderer Hersteller. Manchmal unser Managed ASAv Service wo Sie die Firewall gar nicht anfassen.

Das Migrations-Problem

Die technische Migration ist nicht das Schwere. Config exportieren, auf neue Plattform importieren, fertig. Schwierig ist, was passiert, wenn Sie sich die Config anschauen.

• Regeln vor Jahren erstellt von Leuten die nicht mehr im Unternehmen sind
• Keine Dokumentation die erklärt warum bestimmte Regeln existieren
• Objekte benannt "temp-fix" oder "test-rule" die offensichtlich Production sind
• Zu offene Regeln die keiner zu verschärfen wagt
• Regeln für Systeme die stillgelegt aber nie aufgeräumt wurden

Sie könnten alles so migrieren wie es ist und die technischen Schulden auf die neue Plattform mitnehmen. Oder Sie nutzen die Migration als Gelegenheit aufzuräumen und zu verstehen was jede Regel macht.

Traditioneller Ansatz: Application Owner befragen, alte Tickets durchgehen, fundiert raten. Dauert Monate. Übersieht trotzdem Sachen.

Wie wir helfen

Traffic-basierte Regel-Generierung

Wir haben ein Toolkit gebaut um Firewall-Regeln aus Packet Captures zu generieren. Firewall-Interfaces spiegeln, eine Woche Traffic mitschneiden, und wir generieren Access-Lists basierend auf dem was tatsächlich durchs Netzwerk fließt. Die ersten 90% gehen schnell. Braucht trotzdem manuelles Audit, aber Sie prüfen echte Traffic-Muster statt zu raten.

Mehr über pcap_or_it_didnt_happen.sh

Migrations-Services

Wir übernehmen die komplette Migration: Capture, Analyse, Regel-Generierung, Audit mit Ihren Application Teams, Implementierung auf der neuen Plattform. Typisches Engagement: 2–4 Wochen von Kickoff bis fertiges Ruleset.

Hosting und Plattform-Services

Wenn Sie auch Infrastruktur-Änderungen planen—neues Datacenter, Cloud-Migration, Managed Services—wir betreiben eigene europäische Rechenzentren mit eigenem Backbone. Managed Kubernetes, GPU Compute, Storage Server. Keine Drittanbieter-Bottlenecks, direktes Peering mit DE-CIX Frankfurt und AMS-IX.

Mehr über Zero Services