Sophos Fusion Admin: Übergang von Sophos Central

Sophos Fusion ist der aktuelle Name der Plattform, die zuvor Sophos Central hiess. Dabei sind zwei Änderungen auseinanderzuhalten: die Umstellung von Portalnamen und Zugang sowie das schrittweise Upgrade der EDR-, XDR- und MDR-Lösungen. Ein Fusion-Logo allein bestätigt nicht, dass ein bestimmter Tenant bereits das Produktupgrade erhalten hat. Für die reine Zugangsumstellung werden weder Tenants, Geräte, Policies, Rollen noch technische Endpunkte neu angelegt. Nach dem Produktupgrade können dagegen gezielte Integrationsarbeiten nötig sein.

Dieses Runbook führt durch die lokale Zugangsumstellung und die tenantbezogene Betriebsprüfung. Die konkreten Schritte für neue oder erneut autorisierte Verbindungen stehen in MDR- und XDR-Integrationen einrichten.

Produktupgrade: Tenant und Betriebsfolgen prüfen

Prüfstand 11. Oktober 2026: Der September-Stand des Rollouts beschreibt eine bereits laufende, mehrmonatige Umstellung, nicht die abgeschlossene Migration aller Kunden. Sophos steuert das Upgrade; ein frei wählbarer Kundentermin ist nicht vorgesehen. Ungefähr eine Woche vorher erscheint ein Hinweis in der Konsole. Nach Abschluss folgt ein weiterer Hinweis mit einer kurzen Tour. Dokumentiere für den betroffenen Tenant die Ankündigung, den Abschluss und die tatsächlich erreichbaren Funktionen, statt den Zustand aus einem Newsletter oder dem Portalnamen abzuleiten.

Für MSP-verwaltete Tenants nennt Sophos einen späteren Beginn ab dem vierten Kalenderquartal 2026. Die Tenants desselben MSP sollen gemeinsam umgestellt werden, damit der Partner auf einer einheitlichen Betriebsplattform arbeitet. Auch am 11. Oktober bedeutet diese Zeitangabe nicht, dass alle MSP-Tenants bereits migriert sind. Bis zum tatsächlichen Upgrade bleibt der bisherige Lösungsstand massgeblich; den Kundenzustand bei unklarer Ankündigung mit dem Partnerteam klären.

Das Produktupgrade ist automatisch. Dafür sind weder eine erneute Agentenverteilung noch ein Lizenzwechsel erforderlich. Es ersetzt aber nicht die folgenden Betriebsarbeiten:

1. Prüfe nach dem Abschluss bestehende Microsoft 365 Response Actions. Die Verbindung beziehungsweise deren Credentials müssen im neuen Security Operations erneut eingerichtet oder autorisiert werden. Eine weiterhin laufende Datenintegration beweist nicht, dass alle Response-Aktionen funktionieren.
2. Öffne bei Nutzung von Sophos Firewall einen Case und kontrolliere, ob die Firewall-Response-Aktionen angeboten werden. Nur wenn sie fehlen, ist eine Sophos Firewall (Actions)-Verbindung anzulegen. Beide Integrationsaufgaben sind im oben verlinkten Runbook beschrieben.
3. Inventarisiere für XDR-Automationen getrennt lesende Abfragen und schreibende Workflows sowie deren verwendete APIs. Der API-Nachtrag vom 9. Oktober 2026 ist eine spätere Änderung und kein Bestandteil, dessen Verfügbarkeit bereits beim September-Launch vorausgesetzt werden darf. Die Classic-/GraphQL-Grenze erklärt das Integrationsrunbook.
4. Erfasse vorhandene SVA-Syslog-Collector und gegebenenfalls NDR-Arbeitslasten. Ein automatisch vorprovisionierter XDR Data Collector ist noch nicht ausgerollt. Für Adressentscheidung, Deployment, Umschaltung und Rückweg gilt SVA-Log-Collector zu XDR Data Collectors migrieren.

MDR-Namen und Reporting umstellen

Die bisherigen Stufen Sophos MDR Essentials und Sophos MDR Complete heissen Sophos MDR beziehungsweise Sophos MDR Plus. Das Produkt bleibt Sophos XDR; Sophos XDR Powered by Secureworks kennzeichnet die erweiterte Lösung während des Übergangs. Ein neuer Name ist kein Anlass, den Vertrag oder die Service-Stufe eigenmächtig zu ändern.

Beim Upgrade des MDR-Kontos endet die bisherige automatische Zustellung der wöchentlichen und monatlichen MDR-Berichte. Stimme deshalb mit den Berichtsempfängern ab, wer im Übergang das MDR Dashboard nutzt, den benötigten Zeitraum auswählt und einen PDF-Export für die vorhandenen Reportingpflichten erstellt. Das Dashboard bietet flexible Zeiträume und anpassbare Ansichten. Prüfe den Export für einen bekannten Zeitraum und dokumentiere, wo er abgelegt wird; ausgebliebene automatische Berichte nach dem Upgrade sind nicht allein ein Beleg für ausgefallenen Schutz.

Eine neue Self-Service-Berichterstellung war für später im Jahr 2026 geplant. Daraus folgt keine bestätigte heutige Verfügbarkeit oder bereits funktionierende automatische Zustellung. Erst eine im eigenen Tenant verfügbare und geprüfte Reportingfunktion darf den vereinbarten Übergangsprozess ersetzen.

Wer zusätzlich Sophos Managed Risk nutzt, erhält durch dieses Upgrade keinen geänderten Managed-Risk-Service. Geändert werden das Case-Format und der Zugang: Managed-Risk-Cases sind unter Security Operations > Cases erreichbar. Öffne nach dem Upgrade einen erwarteten Managed-Risk-Case und prüfe, dass er im richtigen Tenant erreichbar ist. Dieser Hinweis gilt nur für Kunden mit bestehendem Managed-Risk-Service und begründet keinen neuen Service-Anspruch.

Optionale Erweiterungen nicht mit dem Upgrade gleichsetzen

Sophos AI Defense ist seit 13. Oktober 2026 allgemein verfügbar und ein kostenpflichtiges Add-on für qualifizierende EDR-, XDR- und MDR-Kunden. Sophos nennt zusätzlich Sophos EDR Endpoint Protection als Voraussetzung. Die frühere EAP-Phase und das damalige Q4-Ziel sind damit historischer Kontext, kein aktueller Verfügbarkeitsstatus. Die allgemeine Freigabe beweist aber weder den Vertragsanspruch noch die Freischaltung im eigenen Tenant. Berechtigte Taegis-Kunden können bereits zur GA kaufen, ohne ihre Fusion-Migration abzuwarten; diese Kaufausnahme hebt die dokumentierte technische Setup-Voraussetzung nicht auf. AI Defense ist nicht der AI Assistant oder AI Search für XDR-Untersuchungen. Plane den Basisbetrieb nicht von diesem Add-on abhängig.

Das dokumentierte Setup verlangt weiterhin ein auf die neue Plattform mit Security Operations aktualisiertes Fusion-Konto. Im Assistenten sind Sophos Endpoint, Sophos Firewall und Sophos Linux Server auswählbar. Die breitere Aufzählung von DNS Protection, Protected Browser und Sophos Data Lake in der Produktübersicht ist nicht dieselbe Sensorauswahlliste. Endpoint benötigt Daten-Uploads, TLS-Entschlüsselung, QUIC-Blockierung sowie Web- und Application-Control-Einstellungen. Für Firewall sind Gruppenverwaltung und Web-Policy-Logging erforderlich; Firewalls ausserhalb der Gruppenverwaltung erhalten keine AI-Defense-Durchsetzungsregeln. Linux Server benötigt den Upload von Network Data in den Data Lake. Eine Sensorauswahl allein bestätigt keinen wirksamen Schutz.

AI Defense bietet Sichtbarkeit, App-Zugriffspolicies und Reporting. Die Base Policy gilt für alle in der Organisation; eine vorhandene Base Policy bleibt beim Onboarding unverändert. Bei zusätzlichen Policies speichert Save ohne Aktivierung, während Save & Enable sofort mit höchster Priorität aktiviert. Geltungsbereich, Regeln und Reihenfolge müssen vor der Freigabe geprüft werden. Promptprüfung und -schutz sind trotz weitergehender GA-Presseformulierungen in der späteren Partnerinformation als Roadmap eingeordnet und dürfen nicht als zugesicherter aktueller Schutz eingeplant werden. Den vollständigen Ablauf mit Sensoranforderungen, begrenztem Pilot, Validierung und Rückweg erklärt Sophos AI Defense: KI-Nutzung erkennen und kontrollieren.

Bei ehemaliger Cloud-Optix-Nutzung ist zusätzlich eine getrennte Lücke zu prüfen: Das End of Life am 30. September 2026 liegt bereits in der Vergangenheit. Neue Cloud-Telemetrie-Verbindungen werden nicht automatisch durch das Produktupgrade eingerichtet und ersetzen keine CSPM-Funktionen. Das Integrationsrunbook beschreibt die Abgrenzung und die jetzt nötige Bestandsprüfung.

Sichtbare Namen und Portaltypen unterscheiden

Je nach Rolle und Kontotyp erscheint eine andere Oberfläche:

Die drei Namen bezeichnen unterschiedliche Verwaltungskontexte und sind nicht austauschbar. Welche Kunden, Sub-Estates oder Produkte sichtbar sind, hängt weiterhin von Konto, Rolle und Berechtigung ab. Die detaillierte Orientierung im Kundentenant steht in Sophos Fusion Tenant sicher in Betrieb nehmen; die verschiedenen Portaltypen ordnet Sophos Portale im Überblick ein.

Umstellung vorbereiten

1. Betroffenen Kontotyp, Tenant, Datenregion und verwendete Adminrolle dokumentieren.
2. Eine funktionierende Anmeldung in einem unterstützten, aktuellen Desktop-Browser bestätigen. Nicht gleichzeitig Authentifizierung, Rolle oder Identity Provider ändern.
3. Lokale Verweise auf den bisherigen Portal-Einstieg erfassen: Browser-Lesezeichen, Passwortmanager-Eintrag, interne Dokumentation und Startseiten sowie, sofern eingesetzt, Proxy- oder Web-Filter-Regeln und Conditional-Access-Zieldefinitionen.
4. Verwendete technische Verweise getrennt inventarisieren: API-Hosts, Redirect URIs, OIDC-Callbacks, Webhooks, Self-Service-Links, Skripte und fest konfigurierte Produktendpunkte.
5. Für den Abnahmetest einen Testaccount mit der für den Betrieb vorgesehenen Adminrolle bereithalten. Wird zusätzlich das Enterprise- oder Partnerportal genutzt, ist je verwendetem Portaltyp ein entsprechender Testaccount nötig. Ausserdem einen zweiten berechtigten Admin und ein privates Browserfenster bereithalten.

MFA, Passkeys und Recovery werden nicht in diesem Runbook umgebaut. Dafür gilt Sophos Fusion Anmeldung mit MFA, Passkeys und IdP absichern. Änderungen an Entra ID, Conditional Access oder OIDC folgen den separaten Anleitungen für Microsoft Entra ID beziehungsweise OpenID Connect und Okta.

Login und lokale Verweise umstellen

Der aktuelle, benutzerseitige Einstieg lautet:

➜ Sophos Fusion öffnen

1. https://fusion.sophos.com direkt in einem privaten Browserfenster öffnen.
2. Die normale Anmeldung vollständig durchlaufen und Tenant, Kontotyp sowie Rolle kontrollieren.
3. Erst nach erfolgreichem Test das Browser-Lesezeichen und den Portal-Link in der internen Admin-Dokumentation auf https://fusion.sophos.com ändern.
4. Im Passwortmanager nur den Login-URI beziehungsweise die Zuordnung für diesen Portal-Einstieg ergänzen oder aktualisieren. Zugangsdaten, Passkeys und gespeicherte technische URLs nicht pauschal verschieben.
5. Falls ein eingesetzter Proxy, DNS-Sicherheitsdienst oder Web-Filter den neuen Host blockiert, den tatsächlich protokollierten Zielhost mit dem kleinsten nötigen Umfang freigeben und erneut testen. Keine unbelegten Wildcard-Ausnahmen für *.sophos.com oder ganze Kategorien erstellen und TLS-Inspection nicht pauschal deaktivieren.
6. Falls Conditional Access für den Anmeldeweg konfiguriert ist, die echten Anmeldeereignisse prüfen. Eine neue Hostbezeichnung rechtfertigt weder eine breite Ausnahme noch eine Änderung an Benutzer-, Geräte-, Standort- oder MFA-Bedingungen.

Beim Aufruf von fusion.sophos.com kann der Browser über bestehende, Legacy-kompatible Central-Infrastruktur weitergeleitet werden. Beobachtete Hosts oder Pfade mit central.sophos.com sind dabei kein Hinweis auf ein Rollback und kein Beleg für einen falschen Tenant. Entscheidend sind ein vertrauenswürdiges Sophos-Ziel, die erwartete Anmeldung und der richtige Verwaltungskontext.

Technische Central-Bezeichner unverändert lassen

Die sichtbare Umbenennung ist keine technische Such-und-Ersetz-Aktion. Folgende Werte bleiben exakt erhalten, solange die jeweilige Integration oder Dokumentation keinen ausdrücklich neuen Wert vorgibt:

• Sophos-Dokumentationspfade mit /central/;
• bestehende Sophos-Central-API-Namen, API-Hosts und Basis-URLs;
• konfigurierte Redirect URIs und Callback-Werte, zum Beispiel https://federation.sophos.com/login/callback;
• der technisch erforderliche, Legacy-kompatible Self-Service-Einstieg https://central.sophos.com/manage/self-service;
• Webhooks, Skriptvariablen, Secrets, Zertifikatsbezüge und andere technische Endpunkte mit central im Namen;
• stabile interne Slugs, Suchbegriffe und historische Nachweise.

Solche Werte können Protokollverträge oder exakte Vergleiche sein. Eine redaktionelle Umbenennung kann SSO, API-Clients oder Benutzerzugänge unterbrechen. Lizenzarbeiten gehören stattdessen in Sophos Fusion Lizenzen aktivieren, prüfen und erneuern.

Validierung

Die Umstellung ist abgeschlossen, wenn die folgenden zutreffenden Punkte mit einem Testaccount in der für den Betrieb vorgesehenen Adminrolle geprüft sind. Für jeden zusätzlich verwendeten Portaltyp wird der Test mit dem dafür vorgesehenen Testaccount wiederholt:

• https://fusion.sophos.com öffnet die erwartete Sophos-Anmeldung ohne Zertifikats- oder Filterwarnung.
• Eine konfigurierte MFA und, falls verwendet, der föderierte Anmeldeweg funktionieren unverändert; die erwartete Rolle und der richtige Tenant sind sichtbar.
• Der Kunden-, Enterprise- oder Partnerkontext trägt den passenden sichtbaren Namen.
• My Environment, Global Settings, Profil und Sophos Help sind entsprechend der Rolle erreichbar.
• Ein vorhandener API- oder Automations-Smoketest läuft ohne geänderten Host oder Secret durch.
• Falls konfiguriert beziehungsweise verwendet, funktionieren SSO-Callback, Self-Service-Link und weitere technische Central-Endpunkte unverändert.
• Sofern Proxy, DNS-Sicherheitsdienst, Web-Filter, IdP oder Conditional Access eingesetzt werden, zeigen deren Logs keine neue Blockierung oder unerwartete Ausnahme.
• Alte interne Anleitungen verweisen für den Admin-Einstieg auf die Fusion-URL, bewahren aber exakte technische Central-Werte.

Troubleshooting

Weiterleitung auf einen Central-Host

Nicht auf einen vermeintlichen alten Zustand zurückschalten. Zuerst Zertifikat, vollständige Redirect-Kette, Zielmandant und erfolgreiche Anmeldung prüfen. Legacy-Namen in der Laufzeit-Infrastruktur können weiterhin korrekt sein.

Blockierte oder leere Seite

Browser ohne Erweiterungen beziehungsweise in einem privaten Browserfenster testen und Uhrzeit, Ausgangs-URL, finalen Host sowie Fehlertext erfassen. Danach die Logs der eingesetzten Proxy-, DNS-, Web-Filter- und TLS-Inspection-Systeme auf den konkret blockierten Host prüfen. Nur diesen belegten Bedarf ändern, nicht vorsorglich Wildcards freigeben.

Sind mehrere unabhängige Anmeldungen oder Tenants gleichzeitig betroffen, dient Sophos Status zur Prüfung auf einen möglichen übergreifenden Dienstausfall. Die Statusseite ist ein Diagnosehinweis; lokale Änderungen werden weiterhin nur anhand belegter Ursachen vorgenommen.

Fehler bei Anmeldung oder Conditional Access

Sophos-Anmeldung und, sofern ein IdP verwendet wird, dessen Ereignisse zeitlich vergleichen. Keine IdP-App, Callback-URL oder Conditional-Access-Policy allein wegen des neuen sichtbaren Namens neu erstellen. Für Diagnose und Rückbau gilt ausschliesslich das oben für den betroffenen Anmeldeweg verlinkte SSO-Runbook; der getestete Rückfall-Admin bleibt erhalten.

Fehlender Menüpunkt

Zuerst Kontotyp und Rolle prüfen. Danach unter My Environment, über das Zahnrad für Global Settings, über das Profil und über Sophos Help suchen. Ein fehlender Menüpunkt kann eine Rollen- oder Lizenzgrenze sein; er beweist keine fehlgeschlagene Umbenennung.

Fehlende Tenants, Produkte oder Kunden

Anmeldung beenden, in einem privaten Browserfenster mit der vorgesehenen Identität erneut starten und Kontotyp sowie Tenant prüfen. Keine Ersatz-Tenants, Trials oder neuen Partnerzuordnungen als Reparatur anlegen.

Bleibt der Zugang nach diesen Prüfungen gestört, werden Zeitfenster mit Zeitzone, betroffene Identität, Tenant beziehungsweise Customer ID, Browser, Ausgangs- und Zielhost, Fehlertext sowie bereinigte Screenshots gesammelt. Die Eskalation erfolgt anschliessend über Sophos Supportticket mit Support Assistant eröffnen.

Lokaler Rollback

Die vendorseitige Umbenennung von Sophos Central zu Sophos Fusion kann der Kunde nicht zurückrollen. Rückgängig gemacht werden dürfen nur die in diesem Change vorgenommenen lokalen Anpassungen:

• Lesezeichen und interne Dokumentationslinks,
• Login-URI-Zuordnungen im Passwortmanager,
• konkrete Proxy-, DNS- oder Web-Filter-Regeln.

Vor dem Rückbau wird der vorherige Wert aus der Change-Dokumentation übernommen und danach der Zugang erneut getestet. IdP- oder Conditional-Access-Anpassungen gehören nicht zu diesem lokalen Rollback; sie werden nur nach dem für den betroffenen Anmeldeweg oben verlinkten SSO-Runbook und dessen dokumentiertem Rückbau zurückgenommen. Der alte Central-Hostname ist kein garantierter Rollback-Pfad. API-Hosts, Callbacks, Self-Service-URLs und andere technische Werte, die für diese Umstellung bewusst unverändert blieben, werden nicht angefasst.