BEKOM OPEN PROSophos-UTM-ExitOPNsense, pfSense, XG evaluieren
Sophos UTM 9 ablösen: OPNsense, pfSense, Sophos Firewall XG und FortiGate im Vergleich, Regelwerk-Konvertierung und Entscheidungsmatrix für eine strukturierte Migration.
Warum Sophos-UTM-Exit aktuell ist
Die Sophos UTM 9 (ehemals Astaro Security Gateway) steht am Ende ihres Lebenszyklus – Sophos hat den End-of-Life-Termin mehrfach verschoben, das finale Support-Ende für Sophos UTM 9.7 ist für den Zeitraum 2026/2027 angesetzt. Firewalls sind in mittelständischen Netzwerken keine austauschbare Einzelkomponente: An ihnen hängen Internet-Anbindung, VPN-Tunnel zu Außenstellen und Home-Office, Web- und E-Mail-Filterung sowie segmentierte Zonen für ERP-, Produktions- und Office-Netze. Fällt die Firewall-Plattform in eine EOL-Situation, betrifft das unmittelbar die Erreichbarkeit zentraler Anwendungen, die Standortvernetzung und die Einhaltung der Informationssicherheitsvorgaben. Sophos drängt Bestandskunden auf die Sophos Firewall XG – eine eigenständige Plattform mit anderem Betriebsmodell, anderer Konsole und Pflicht-Anbindung an Sophos Central. Eine In-Place-Migration gibt es nicht, jeder Kunde steht vor einer Neuinstallation. Damit wird der EOL-Zeitpunkt zur natürlichen Entscheidungsgelegenheit: Sophos Firewall XG, ein anderes proprietäres Produkt oder der Schritt zu einer Open-Source-Plattform wie OPNsense.
Der Sophos-UTM-Exit betrifft geschäftskritische Netzwerkkomponenten, die als Betriebsvoraussetzung für standortübergreifende Auftragsverarbeitung und operative Geschäftsprozesse fungieren. Firewall-Ausfälle unterbrechen unmittelbar ERP-Zugriffe, VPN-Verbindungen zu Außenstellen und compliance-relevante Netzwerksegmentierung. → BEKOM OPEN PRO Security
Was aus dem Astaro-Erbe wird
Sophos UTM stammt aus der 1998 gegründeten Astaro AG und wurde 2011 von Sophos übernommen. Das Produkt hat sich als All-in-One-Gateway mit Paketfilter, VPN, Web-Proxy, Reverse-Proxy, Mailfilter und WAF über Jahrzehnte im deutschen Mittelstand etabliert. Sophos setzt strategisch nicht mehr auf diese Architektur – die Nachfolge liegt ausschließlich auf der Sophos-Firewall-(XG-)Linie.
Die Sophos-Vorgaben für Bestandskunden:
Letzte UTM-9-Support-Phase ohne In-Place-Upgrade – UTM 9.x läuft in die letzte Support-Phase; es gibt keinen direkten In-Place-Upgrade-Pfad auf die XG-Plattform, jeder Wechsel ist eine Neuinstallation
Eigenständige XG-Architektur mit SF-OS – Sophos Firewall (XG) basiert auf SF-OS statt Astaro Linux; Bedienkonzept, Konsole und Lizenzlogik sind grundlegend anders aufgebaut
Pflicht-Anbindung an Sophos Central – zentrale Verwaltung, Policies und Reporting laufen über Sophos Central als Cloud-Plattform; lokale Konsole verliert ihren primären Charakter
Manueller Regelwerk-Aufbau und neue Lizenzstruktur – Regelwerke, Web-Filter-Profile, Reverse-Proxy-Konfigurationen werden manuell neu aufgebaut; Lizenzstruktur wechselt von UTM-Paketlogik zu modularen XStream-Subscriptions
Damit entsteht für Bestandskunden faktisch eine Neu-Entscheidung: Gleiches Produktlogo bei anderer Architektur, oder alternative Plattform mit dokumentierbarem Migrationspfad.
Wann sich ein Sophos-UTM-Exit-Assessment bei BEKOM rechnet
Wenn EOL-Termin, Subscription-Verlängerung oder die Architektur-Lücke zwischen UTM und XG den nächsten Beschaffungsschritt erschweren, ist eine strukturierte Bewertung der Optionen die nächste sinnvolle Stufe. BEKOM begleitet das UTM-Exit-Assessment herstellerneutral und ohne vorgegebenes Zielprodukt.
Typische Anlässe für ein Assessment:
EOL-Druck und letzte Subscription-Verlängerung – Sophos UTM 9 läuft in die letzte Support-Phase; die nächste Verlängerung erzwingt eine Architektur-Entscheidung mit Vorlaufzeit
XG-Migration faktisch eine Neukonfiguration – Wechsel auf Sophos Firewall XG bedeutet Regelwerk-Neuaufbau, Sophos-Central-Anbindung und VPN-Re-Konfiguration; zur freiwilligen Neuinstallation wird die Plattform-Frage neu gestellt
Hardware-Refresh am Standort – Garantieende, Hardware-Generationswechsel oder Konsolidierung mehrerer Standorte werfen Plattform-Frage und Lizenzfrage gleichzeitig auf
Compliance- oder Audit-Druck – TISAX-, ISO-27001- oder KRITIS-Pflichten verlangen dokumentierte Regelwerke, Rule-Hit-Analysen und Sub-Auftragsverarbeiter-Listen, die beim Plattformwechsel ohnehin neu erstellt werden
Im Strategiegespräch werden Regelwerks-Komplexität, VPN-Topologie und Migrationsfenster geklärt – das Ergebnis ist ein schriftliches Angebot mit dokumentiertem Bewertungsrahmen.
Risikolage beim verspäteten UTM-Exit
Wer den UTM-Exit aufschiebt, akzeptiert nicht nur kommerzielle Konsequenzen, sondern auch Sicherheits- und Compliance-Risiken. Mehrere Risikodimensionen wirken parallel und summieren sich über die Zeit.
Risiken mit zunehmender EOL-Nähe:
Patches und Signatur-Feeds laufen aus – nach EOL erhalten UTM-Appliances keine Sicherheits-Updates mehr; Bedrohungslage steigt mit jedem Patch-Tuesday-Release ohne Schutz
Versicherungs- und Audit-Risiken – Cyber-Versicherer und ISO-27001-Auditoren werten EOL-Plattformen als Schwachstelle; Versicherungsbedingungen können bei nicht aktualisierter Schutzsoftware angepasst werden
Regelwerk-Wissensverlust mit Personalwechsel – über Jahre gewachsene Regelwerke ohne aktive Pflege verlieren Dokumentations-Tiefe; spätere Migration wird mit jedem Personalwechsel aufwendiger
Lieferengpässe bei Ersatz-Hardware – mit EOL reduziert Sophos die Reparatur- und Ersatzteil-Kette; bei Hardware-Ausfällen entstehen ungeplante Migrations-Zwänge ohne Vorlauf
Diese Risiken summieren sich zu einem dokumentierbaren Anlass, das Migrationsfenster bewusst vor dem EOL-Termin zu legen.
Alternativen im Vergleich
Die Zielplattformen unterscheiden sich stark in Lizenzmodell, Bedienkonzept und Betriebslogik. Die folgende Einordnung betrachtet vier Optionen, die für mittelständische UTM-Bestandskunden realistisch in Frage kommen. Weiterführend: Intrusion Detection & Prevention.
OPNsense – europäischer Open-Source-Nachfolger
OPNsense ist ein Community-getriebener Fork aus dem m0n0wall/pfSense-Umfeld, seit 2015 von der niederländischen Deciso B.V. gepflegt. Die Plattform hat im deutschsprachigen Raum besondere Relevanz, da Hersteller und Kernentwicklung im europäischen Rechtsraum angesiedelt sind.
Charakteristika:
Lizenzmodell: Open Source (BSD 2-Clause), kommerzielle Business-Edition über Deciso
Funktionsumfang: Paketfilter (pf), IPsec- und WireGuard-VPN, OpenVPN, Web-Proxy, IDS/IPS (Suricata), Reverse-Proxy (HAProxy), DNS/DHCP, HA-Cluster (CARP)
Bedienung: umfangreiche Web-Oberfläche, REST-API, Konfiguration als XML (versionierbar), Updates aus stabilen Release-Kanälen
Support-Optionen: Community, Business-Edition bei Deciso, Partner-Ökosystem in DACH
Für Sophos-UTM-Bestandskunden ist OPNsense in vielen Fällen der funktional nächste Nachfolger: Paketfilter, Web-Proxy, Reverse-Proxy und VPN-Features sind in äquivalenter Tiefe vorhanden, die Oberfläche ist für UTM-Admins zügig zugänglich.
pfSense – etablierter Open-Source-Klassiker
pfSense CE (Community Edition) und pfSense Plus werden von Netgate gepflegt. Das Produkt ist seit 2004 am Markt und hat weltweit die größte installierte Basis der pf-basierten Firewalls.
Charakteristika:
Lizenzmodell: pfSense CE Open Source (Apache 2.0), pfSense Plus proprietär auf Netgate-Hardware
Funktionsumfang: vergleichbar mit OPNsense (gleiche pf-Grundlage), unterschiedliche Paketauswahl und UI-Philosophie
Support-Optionen: TAC-Support über Netgate, globales Partner-Netzwerk
pfSense kommt in Betracht, wenn eine weltweite Hersteller-Basis, Netgate-Hardware-Support oder eine bestehende pfSense-Standortpräsenz gegeben ist. In DACH ist OPNsense organisatorisch und sprachlich häufig die naheliegendere Option.
Sophos Firewall XG – auf Sophos bleiben
Sophos Firewall (ehemals XG) ist die von Sophos selbst positionierte Nachfolgelinie. Wer die Migration auf Astaro-Art vermeiden möchte, wechselt auf die XG-Architektur.
Charakteristika:
Lizenzmodell: proprietäre Subscription mit XStream-Protection-Paketen (Standard, Essentials, Advanced)
Funktionsumfang: Deep Packet Inspection, Xstream Flow Processor, Synchronized Security mit Sophos Endpoint, ZTNA-Modul
Zentrale Verwaltung: verpflichtend über Sophos Central (Cloud), lokale Konsole nicht mehr primäres Bedienwerkzeug
Sophos Firewall XG passt, wenn die Sophos-Endpoint-Landschaft bereits tief integriert ist, Synchronized Security bewusst genutzt wird und die Cloud-gebundene Verwaltung organisatorisch akzeptiert ist. Der strategische Lock-in auf Sophos bleibt bestehen.
FortiGate – proprietäre Konsolidierungs-Plattform
Fortinet positioniert FortiGate als Enterprise-Konsolidierungsplattform mit eigener ASIC-Hardware und tief integriertem Security-Stack.
Charakteristika:
Lizenzmodell: proprietär, FortiCare-Support plus FortiGuard-Subscription-Bundles (UTP, Enterprise)
Funktionsumfang: Paketfilter, SD-WAN, SSL-Inspection, IPS, Sandbox-Anbindung an FortiAnalyzer und FortiManager
Zentrale Verwaltung: FortiManager für Policy-Templates, FortiAnalyzer für Reporting
FortiGate ist relevant, wenn neben der Firewall auch SD-WAN und ein integrierter Security-Fabric-Ansatz gesucht werden. Die Herstellerbindung bleibt – vergleichbar zu Sophos XG, mit anderer Tiefe des Produktstacks.
Migrationspfad und Phasen
Der Umzug einer Sophos-UTM-Installation ist anwendungsgetrieben: Regelwerk, VPN-Topologie, Zertifikate und Proxy-Strukturen werden nacheinander auf das Zielsystem übertragen. Der Prozess läuft in vier abgestimmten Schritten mit Freigabepunkten.
Phase 1: Regelwerk- und Policy-Inventar
Die bestehende UTM-Konfiguration wird vollständig erfasst, gruppiert und bewertet – deutlich strukturierter als ein reines Config-Backup.
Inhalt der Phase:
Export der Netzwerk-, Host- und Service-Definitionen aus UTM inklusive Benennungskonvention
Klassifikation der Firewall-Regeln (aktiv, ungenutzt, historisch gewachsen) anhand Trefferstatistik und Rule-Hit-Analyse
Erfassung der VPN-Endpunkte (Site-to-Site IPsec, SSL-VPN, Road-Warrior), eingesetzte Zertifikate und Authentifizierungsquellen (Active Directory, RADIUS, LDAP)
Dokumentation der Web-Proxy-Profile, Reverse-Proxy-Veröffentlichungen, Email-Relay-Regeln und WAF-Patterns
Ergebnis: eine geordnete Policy-Karte pro Standort mit priorisierter Migrationssequenz. Die Freigabe zur Pilotphase erfolgt nach gemeinsamem Review mit IT-Leitung und Informationssicherheit.
Phase 2: Pilot-Appliance und Regelwerk-Konvertierung
Eine Pilot-Installation der Zielplattform wird mit einem repräsentativen Teil-Regelwerk aufgebaut, um Konvertierungsmuster und Betriebsprozesse zu verifizieren.
Inhalt der Phase:
Aufbau der Zielappliance (OPNsense, pfSense, XG oder FortiGate) in einer abgetrennten Testumgebung mit realitätsnaher Netzwerktopologie
Regelwerk-Konvertierung für einen Standort oder eine Fachabteilung, inklusive Alias-/Objekt-Mapping zwischen UTM-Grammatik und Ziel-Grammatik
Aufbau von VPN-Test-Tunneln (IPsec, WireGuard oder OpenVPN), Zertifikats-Roll-out und Authentifizierungs-Test
Validierung der Web-Proxy- und Reverse-Proxy-Migration mit definierten Testfällen (Kategorien-Filter, TLS-Inspection, Veröffentlichungen)
Typische Befunde in dieser Phase: UTM-spezifische Objektgruppen lassen sich nicht 1:1 übertragen, TLS-Inspection-Zertifikate müssen neu verteilt werden, bestimmte UTM-Regelsemantiken (impliziter Regel-Schluss) weichen ab und benötigen explizite Regeln im Ziel.
Phase 3: Standort-Rollout mit Parallelbetrieb
Der produktive Umzug erfolgt standortweise. Sophos UTM und Zielplattform laufen in definierten Übergangsfenstern parallel, bis die Abnahme je Standort erfolgt ist.
Inhalt der Phase:
Standort-Reihenfolge nach Kritikalität, Komplexität der VPN-Topologie und Wartungsfenster
Cutover-Prozedur pro Standort: IP-Umstellung, Default-Gateway-Wechsel, DNS-Anpassung, VPN-Reauthentifizierung, dokumentierter Rollback
Ausführung mit Abnahmekriterien: Ping-/Pfad-Tests, Applikations-Erreichbarkeit, VPN-Tunnel-Metriken, Proxy-Zugriffstests
Übergangsbetrieb: UTM und neue Appliance koexistieren, bis die Standort-Abnahme vorliegt
Kritische Standorte (Hauptsitz, Rechenzentrum) folgen erst, nachdem kleinere Niederlassungen die Migration bestätigt haben.
Phase 4: UTM-Stilllegung und Dokumentation
Mit Abnahme des letzten Standorts wird die UTM-Landschaft kontrolliert abgebaut und die neue Plattform zur Betriebs-Basis.
Inhalt der Phase:
Abschluss-Review: Regelwerk-Vollständigkeit, VPN-Abdeckung, Reporting-Konsistenz, Alarm-Ketten
Rückbau der UTM-Appliances, Kündigung oder Nichtverlängerung der Subscription-Pakete zum Vertragsende
Aktualisierung von Betriebshandbüchern, Incident-Response-Runbooks und Netzwerkdokumentation
Übergabe an das interne Team oder strukturierter Übergang in den Managed Service
Mit dieser Phase endet das Projekt; der Regelbetrieb übernimmt mit dokumentierter Policy-Baseline.
Betriebsmodelle nach der Migration
Die Firewall-Plattform benötigt nach dem Umzug eine klar definierte Betriebsverantwortung. Drei Modelle sind üblich und lassen sich kombinieren.
Internes Security-Team
Das eigene Security- oder Netzwerkteam führt die neue Plattform weiter: Regelwerk-Pflege, Patch-Management, Incident-Reaktion, Reporting.
Stärken:
Policy-Änderungen ohne Wartezeit oder Change-Ticket an Dritte
Hausinterne Kenntnis der Netzwerkpfade und Anwendungslandschaft
Direkte Rückkopplung mit Fachbereichen bei neuen Veröffentlichungen
Vollständige Kontrolle über Reaktionsentscheidungen bei Security-Events
Geeignet, wenn:
- Firewall-/Security-Kompetenz im Team belastbar abgedeckt ist (mit Vertretung)
- Rufbereitschaft für Sicherheitsvorfälle organisatorisch tragbar ist
- Policies eng mit schneller Entwicklungs- oder Betriebsdynamik abgestimmt werden müssen
Managed Service durch BEKOM
BEKOM übernimmt die Firewall-Plattform mit vertraglich geregelten Leistungen: Regelwerk-Pflege nach dokumentiertem Change-Prozess, Patch-Zyklen, Incident-Response, SIEM-/SOC-Anbindung, Reporting an Informationssicherheit und Geschäftsführung.
Stärken:
Zentrale Policy-Verwaltung mit Change-Historie und Vier-Augen-Prinzip
24/7-Incident-Reaktion auf Security-Events ohne interne Rufbereitschaft
Abgestimmte Reportings gegenüber Revision, Datenschutz und Informationssicherheits-Beauftragten
Klare Trennung zwischen Betrieb (BEKOM) und Steuerung (Kunde)
Geeignet, wenn:
- Das interne Team Security nicht als Hauptfokus hat oder Kapazitäten priorisieren muss
- Sicherheits-SLAs gegenüber Kunden oder Versicherung belegt werden müssen
- Compliance-Anforderungen (TISAX, ISO 27001, KRITIS) eine dokumentierte Service-Struktur verlangen
Geteiltes Betriebsmodell
Change-Hoheit, Architektur-Entscheidungen und Policy-Richtlinien bleiben beim internen Team, während BEKOM operative Routine oder 24/7-Reaktion übernimmt.
Stärken:
Policy-Ownership bleibt im Haus, operative Last reduziert
Rufbereitschaft, Threat-Intelligence-Feeds und Deep-Dives extern abgefedert
Verlagerung der Aufgabenanteile im Zeitverlauf möglich
Wissen bleibt auch bei personellen Wechseln dokumentiert
Geeignet, wenn:
- Ein Security-Team vorhanden, aber nicht 24/7 tragfähig ist
- Kritische Change-Entscheidungen bewusst im Haus bleiben sollen
- Spezialthemen (TLS-Inspection-Design, Multi-Site-SD-WAN) punktuell extern laufen
BEKOM ist Partner für den UTM-Exit
Ein Sophos-UTM-Exit berührt Sicherheitsarchitektur, Regelwerksqualität und Betriebsverantwortung gleichermaßen. Drei Merkmale prägen die Zusammenarbeit mit BEKOM: eine Bewertung ohne Firewall-Vertriebsinteresse, eine geschlossene Verantwortung vom Regelwerk-Inventar bis zur Plattformübergabe und ein mittelständisch ausgerichteter Kommunikations- und Rechtsraum.
Bewertung ohne Firewall-Vertriebsinteresse
BEKOM ist weder OPNsense-, pfSense-, Sophos- noch Fortinet-Reseller und hat keine Margen aus der Plattformwahl. Die Empfehlung orientiert sich an Regelwerk-Komplexität, VPN-Topologie, Integrationsanforderungen und Betriebsstruktur.
Was das konkret bedeutet:
Entscheidungskriterien (Funktionsabdeckung, Administrierbarkeit, SOC-Integration, Lizenzprofil, Supportkette) werden vor Projektstart schriftlich vereinbart
Jede Empfehlung wird gegen mindestens eine plausible Alternative argumentiert
OPNsense, pfSense, Sophos Firewall XG und FortiGate laufen durch dasselbe Bewertungsraster
Ein begründeter Wechsel auf Sophos Firewall XG ist ein zulässiges Ergebnis, wenn die Analyse das stützt
Keine Subscription-Provisionen oder Vertriebsziele fließen in die Entscheidung ein
Methodik, Rule-Hit-Analysen und Objekt-Mappings werden offen dokumentiert
Daraus entsteht eine Grundlage, die gegenüber Geschäftsführung, Informationssicherheit, Audits (ISO 27001, TISAX) oder dem KRITIS-Prüfer belastbar dokumentierbar ist.
Geschlossene Verantwortung über den gesamten Umzug
Regelwerk-Inventar, Pilot-Konvertierung, Standort-Rollout und anschließender Betrieb werden von denselben technischen Rollen begleitet. Übergaben zwischen den Phasen laufen ohne Re-Briefing.
Das heißt konkret:
Die Rule-Hit- und VPN-Analyse aus Phase 1 wird direkt als Arbeitsgrundlage in die Pilot-Konvertierung weitergereicht
Konvertierungsmuster aus Phase 2 (Alias-Mapping, VPN-Templates, TLS-Inspection-Profile) gehen als Baustein in den Rollout
Das Rollout-Team übergibt an den Betrieb mit einem gemeinsam erstellten Runbook inklusive Policy-Change-Prozess
Eine benannte technische Leitung begleitet das Projekt vom Inventar bis zur produktiven Übergabe
Beratungs-, Migrations- und Betriebsrollen laufen unter einheitlicher Vertragsstruktur
Eskalations- und Abnahmewege bleiben über alle Phasen identisch
Das senkt die Schnittstellenverluste, die bei Ketten aus wechselnden Dienstleistern typisch sind – besonders relevant bei Firewall-Migrationen, wo Regelwerke über Jahre gewachsen und nur in Teilen dokumentiert sind.
Mittelstands-orientierter Vertragsrahmen
Vertragsgestaltung, Ansprechpartner und Betriebssprache sind ausschließlich auf deutschsprachige Organisationen ausgerichtet. Keine Eskalation an internationale Security-Operations-Tiers, keine Übersetzungsbeilagen.
Im Alltag bedeutet das:
Vertrag, Leistungsbeschreibung, Policy-Change-Prozesse und SLAs auf Deutsch
Rechtsraum Deutschland, keine außereuropäischen Vertragsklauseln bei Streitfragen
Ansprechpartner mit Erfahrung in mittelständischen Sicherheits- und Change-Prozessen
Security-Eskalationen erreichen verantwortliche Rollen ohne Zeitzonenverzug
Abstimmungen mit Geschäftsführung, Informationssicherheits-Beauftragtem und Betriebsrat in gemeinsamer Sprache
Datenverarbeitung, Log-Speicherung und Support laufen in Deutschland, ohne Weitergabe an Offshore-Teams
Gegenüber globalen Security-Service-Modellen und internationalen Systemhaus-Ketten ist dieser Rahmen ein belegbares Abgrenzungsmerkmal – besonders für Organisationen mit DSGVO-, KRITIS- oder Revisionsanforderungen.
Kostenstruktur eines Sophos-UTM-Exits
Ein UTM-Umzug wirkt auf drei Kostenebenen über den Lebenszyklus. Pauschale Einsparungen verspricht BEKOM nicht — ein strukturiertes Assessment ordnet die Ebenen gegen die heutige Ausgangslage und liefert eine belastbare Vergleichsgrundlage. Die tatsächliche Kostenwirkung hängt von Standortzahl, Regelwerks-Komplexität, VPN-Topologie und Renewal-Terminen ab und wird pro Organisation ermittelt.
Bestandsseite – Sophos UTM heute
Auf der Bestandsseite wirken nicht nur die Subscription-Listenpreise, sondern auch Hardware-Garantie, Protection-Module und gebundenes Personal. Ein vollständiger Vergleich erfasst alle vier Treiber statt nur den sichtbaren Lizenz-Anteil.
Kostentreiber im laufenden UTM-Betrieb:
Subscription-Verlängerungen pro Schutzmodul – Network, Web, Mail, WebServer und Endpoint-Module mit eigener Renewal-Logik und steigenden Listenpreisen
Hardware-Refresh-Zyklen der UTM-/XG-Appliances – Garantieverlängerungen, Hardware-Tausch nach Lifecycle und Lager-Reservehardware bei Multi-Site-Topologie
Sophos-Central-Lizenzen für zentrale Verwaltung – bei Wechsel auf XG verpflichtend; bei UTM 9 anteilige Lizenzlogik je nach Funktionsumfang
Personalkapazität für Regelwerk-Pflege und Audits – gebundene Stunden für Change-Verwaltung, VPN-Onboarding, Reporting an IS-Beauftragte und Audit-Vorbereitung
Im Assessment werden diese Treiber gegen den heutigen Bestand gerechnet und ergeben die Bestandsseite des Vergleichs.
Migrationsphase – einmalige Aufwände
Während der Migration entstehen einmalige Aufwände, die als abgegrenzte Pakete vereinbart werden. Der Vorteil: jede Phase hat eigenen Umfang und eigene Abnahme — die Investitions-Entscheidung bleibt zwischen den Phasen reversibel.
Einmalige Migrations-Aufwände:
Regelwerk-Inventur mit Rule-Hit-Analyse – Klassifikation der UTM-Regeln nach aktiv, ungenutzt, historisch gewachsen; Grundlage für Konvertierungsaufwand und Konsolidierung
Pilot-Konvertierung an einem Standort – Aufbau der Zielappliance, Konvertierungsmuster für Objekt-Mapping, VPN-Templates und TLS-Inspection-Profile
Standort-Rollout mit Parallelbetrieb – pro Standort Cutover, Zertifikatstausch, VPN-Reauthentifizierung, Hypercare und Anwender-Begleitung
Parallel-Subscription während der Übergangsphase – UTM-Subscription läuft bis zum letzten Standort weiter; Doppel-Kosten werden im Stufen-Plan berücksichtigt
Die Anteile werden im Angebot getrennt ausgewiesen, sodass interne Budgetbegründungen und spätere Vergleiche sauber möglich bleiben.
Zielseite – laufender Open-Source-Betrieb
Auf der Zielseite verschieben sich die Treiber von Subscription-Lizenzen zu Plattform-Betrieb. Bei OPNsense oder pfSense entfällt der Lizenz-Anteil weitgehend; dafür entstehen Kosten für Plattform-Betrieb, optional kommerzieller Support und Threat-Intelligence-Feeds.
Kostenebenen im laufenden Betrieb:
Monatliche Plattform-Service-Pauschale – abhängig von Anzahl Standorten, HA-Topologie (CARP-Cluster, Multi-Site), SLA-Stufe und Service-Modell (Fully Managed oder Co-Managed)
Hardware aus Hersteller-Bezug oder Standard-x86 – Deciso-Appliances bei OPNsense, Netgate-Hardware bei pfSense oder Standard-x86; ohne Subscription-Reset bei Hardware-Tausch
Optional Business-Edition oder TAC-Support – Deciso Business Edition bei OPNsense, Netgate TAC bei pfSense; mit klarer Abgrenzung zur Community-Edition
Modular ergänzende Beratungs-Pakete – Threat-Intelligence-Feeds, SOC-Anbindung, Major-Upgrades und Compliance-Begleitung sind als getrennte Pakete buchbar, ohne in der monatlichen Pauschale zu wachsen
Pauschale Einsparungs-Versprechen vermeidet BEKOM bewusst — die belastbare Aussage entsteht erst aus dem Bestands-Vergleich des konkreten Falls.
BEKOM OPEN PRO statt Systemhaus-Migrationsprojekt
Der Sophos-UTM-Exit unterscheidet sich fundamental von klassischen Systemhaus-Ansätzen: BEKOM arbeitet herstellerunabhängig mit Standard-Technologien wie OPNsense und pfSense – ohne Vendor-Lock-in in proprietäre Plattformen.
Während Systemhäuser oft nur die Hardware austauschen und auf Sophos XG mit Zwangs-Cloud-Anbindung drängen, evaluiert BEKOM transparent alle Alternativen einschließlich Open-Source-Firewalls. Der feste Ansprechpartner begleitet den gesamten Exit-Prozess von der UTM-Analyse über die Plattform-Evaluation bis zur produktiven Migration. Deutsche Rechenzentren gewährleisten dabei, dass auch zentrale Firewall-Services und VPN-Gateways im DACH-Raum verbleiben, während das dokumentierte Service-Design-Dokument alle Konfigurationen und Abhängigkeiten für den Nachfolgebetrieb transparent macht.
Häufige Fragen zum Sophos-UTM-Exit
Bis wann muss der Sophos-UTM-Exit umgesetzt sein?
Sophos hat den End-of-Life-Termin für UTM 9 mehrfach verschoben; der aktuell kommunizierte Support-Horizont liegt im Zeitraum 2026/2027. Relevanter als der reine EOL-Stichtag ist der Subscription-Verlängerungszyklus der Schutzmodule und die Hardware-Garantiesituation. Die meisten Bestandskunden planen den Umstieg so, dass er vor der nächsten großen Subscription-Verlängerung abgeschlossen ist – das Assessment ordnet den individuellen Zeitraum ein.
Ist OPNsense ein gleichwertiger Nachfolger für Sophos UTM, oder gibt es funktionale Lücken?
In den meisten Funktionsbereichen ja, in einigen nicht automatisch. OPNsense deckt Paketfilter, VPN, Web-Proxy, Reverse-Proxy, IDS/IPS und HA-Cluster in vergleichbarer Tiefe ab. Unterschiede gibt es bei Sandbox-Anbindung, integriertem Mail-Schutz und Sophos-spezifischen Synchronized-Security-Features mit Endpoint-Stack. Wo diese Bausteine geschäftskritisch sind, werden entweder externe Ergänzungen (Mailgateway, Sandbox-Service) oder bewusst die Sophos-XG-Alternative im Assessment geprüft.
Wie werden bestehende Firewall-Regeln konvertiert?
Die Konvertierung läuft nicht über einen automatischen Import. Aus dem UTM-Konfigurationsexport werden Objekte (Netze, Hosts, Services), Regeln, VPN-Endpunkte und Profile extrahiert, gruppiert und in die Zielgrammatik übertragen. Parallel wird das Regelwerk auf ungenutzte oder obsolete Einträge überprüft (Rule-Hit-Analyse), sodass der Umzug zugleich eine Regelwerk-Konsolidierung ist. Für häufige Muster liegen Konvertierungs-Templates vor, der Kern bleibt handarbeit.
Können bestehende Zertifikate und VPN-Konfigurationen übernommen werden, oder muss alles neu aufgesetzt werden?
Teilweise. IPsec-Phase-1/-2-Parameter und Preshared-Keys lassen sich in der Regel übertragen; X.509-Zertifikate werden neu ausgestellt oder — wenn die interne CA das zulässt — mit neuen Schlüsseln re-signiert. SSL-VPN-Road-Warrior benötigen neue Client-Konfigurationen mit Begleitkommunikation an die Nutzer. WireGuard-Peering wird, falls gewünscht, neu aufgesetzt. Der Zertifikats- und VPN-Umzug ist im Cutover-Plan je Standort detailliert dokumentiert.
Kann parallel zur UTM bereits eine neue Firewall laufen?
Ja, der Parallelbetrieb ist Standardbestandteil des Rollouts. Während des Standort-Umzugs läuft die UTM-Firewall weiter, die neue Appliance steht bereits aktiv in definierter Rolle (zweite DMZ, Standort-spezifische Zone, Test-Standort). Erst mit der Cutover-Entscheidung pro Standort übernimmt die neue Plattform, und die UTM wird nach dokumentierter Nachbeobachtung außer Betrieb genommen. So bleibt bis zum Abschluss jedes Standorts ein definierter Rollback möglich.
Was geschieht mit Web-Proxy, Reverse-Proxy und Mailgateway aus der UTM?
Der UTM-Web-Proxy wird auf den jeweiligen Ziel-Proxy übertragen (OPNsense Web-Proxy mit Squid/ICAP, pfSense Squid, native Proxy-Services auf XG oder FortiGate). Der Reverse-Proxy wandert meist zu HAProxy auf OPNsense/pfSense, auf XG in die Web-Server-Protection oder auf einen dedizierten Reverse-Proxy. Das Mailgateway wird gesondert betrachtet – häufig ausgelagert auf eine dedizierte Mailsecurity-Lösung oder auf einen Managed Mail Service.
Welche Risiken bestehen beim Wechsel von Sophos UTM auf eine neue Plattform?
Typische Befunde: implizit geltende UTM-Regeln müssen explizit übersetzt werden, TLS-Inspection-Zertifikate brauchen erneute Verteilung auf alle betroffenen Clients, VPN-Client-Rollouts erzeugen Unterstützungsbedarf im internen Support, Reporting-Kennzahlen sind zunächst nicht direkt vergleichbar zwischen alter und neuer Plattform. Diese Risiken werden in der Pilotphase identifiziert, in Runbooks dokumentiert und im Standort-Rollout mit Rollback-Fenstern adressiert.
Wird das interne Team aktiv eingebunden?
Ja, durchgehend. In Phase 1 liefert das interne Team Kenntnisse zu gewachsenen Sonderregeln und Historienwissen zu einzelnen Ausnahmen. In Phase 2 erfolgt die Hands-on-Erprobung der Zielplattform gemeinsam. In Phase 3 wird die Aufgabenverteilung pro Standort schriftlich fixiert. Das Betriebsmodell nach der Migration wird mit dem internen Kompetenzprofil abgestimmt, sodass keine Lücken bei Urlaub, Krankheit oder Fachwechsel entstehen.
Was kostet das Sophos-UTM-Exit-Assessment bei BEKOM, und wie wird kalkuliert?
Das Assessment ist ein eigenständiges Beratungsprojekt mit klar abgegrenztem Umfang. Der Aufwand richtet sich nach Standortanzahl, Regelwerk-Umfang, VPN-Topologie-Komplexität und gewünschtem Tiefgrad (Rule-Hit-Analyse, Proxy-Mapping, Reporting-Konzept). Dem Auftrag geht ein unverbindliches Strategiegespräch voraus, in dem Umfang und Abgrenzung definiert werden. Daraus entsteht ein schriftliches Angebot mit Phasenlogik, Abnahmekriterien und pro Phase ausgewiesenen Leistungen.
Kann BEKOM die bestehende UTM-Umgebung übernehmen, solange wir noch nicht zu einer neuen Plattform migrieren?
Ja. Die UTM kann im Rahmen des Managed-Service-Portfolios bis zum Migrationsabschluss weiterbetrieben werden — mit dokumentiertem Change-Prozess, SLA-Rahmen und Incident-Reaktion mit definierten Reaktionszeiten. Das ermöglicht einen kontrollierten Übergang, ohne dass der Regelbetrieb unter Migrationsdruck gerät. Der Migrationsfahrplan wird aus diesem laufenden Managed-Service-Verhältnis heraus strukturiert vorbereitet, ohne dass parallel laufende Operationen unter Druck geraten.
Nächster Schritt: UTM-Exit-Evaluierung
Den Einstieg bildet ein Strategiegespräch zur aktuellen UTM-Landschaft, zu realistischen Zielplattformen und zur passenden Umsetzungsform. Das Gespräch ist unverbindlich und löst keine Folgeverpflichtung aus; ein schriftliches Angebot für das Assessment entsteht erst nach gemeinsamer Abgrenzung von Umfang und Zielbild.
Das Assessment liefert eine vollständige Bestandsaufnahme der bestehenden Sophos-UTM-Konfiguration mit allen VPN-Tunneln, Firewall-Regeln und Proxy-Einstellungen. BEKOM erstellt darauf basierend konkrete Architektur-Empfehlungen für OPNsense, pfSense oder Sophos XG einschließlich Migrations-Roadmap und Service-Design für den Parallelbetrieb. Der Überblick zeigt dabei nicht nur technische Machbarkeit, sondern auch Betriebsumfang und Klarheit über notwendige Anpassungen in abhängigen Systemen und Standortvernetzung.
Strategiegespräch vereinbaren
Im Strategiegespräch klären BEKOM-Spezialisten mit dem internen Security-Team die Ausgangslage: Standort-Topologie, Regelwerk-Größenordnung, VPN-Profile und Integrationsanforderungen. Das Ergebnis ist eine erste fachliche Einordnung – ergebnisoffen und ohne festgelegte Zielplattform.
Strukturiertes Assessment durchführen
Im Assessment entstehen Regelwerk-Inventar mit Rule-Hit-Analyse, VPN-Topologiebeschreibung, Proxy-Mapping, Alternativen-Bewertung und dokumentiertes Zielbild. Die Entscheidungsvorlage enthält begründete Empfehlung, Risikoliste und einen Phasenplan für den Standort-Rollout.
Pilot und Standort-Rollout begleiten
Nach Freigabe begleitet BEKOM die Umsetzung: Pilot-Appliance mit konvertiertem Teil-Regelwerk, VPN-Testverbindungen, Cutover-Prozeduren und Stufen-Rollout bis zur dokumentierten Übergabe. Die Beteiligungsform reicht von Beratung über Projektpartnerschaft bis zur vollständig übernommenen Migrationsdurchführung.