Sophos Fusion Admin: Transition from Sophos Central

Sophos Fusion is the current name of the platform formerly called Sophos Central. For administrators, the transition primarily affects visible names, portal access, and navigation. It is not an instruction to recreate tenants, devices, policies, roles, licenses, or integrations. This runbook covers only the controlled transition of administrative access; product configurations remain unchanged.

Distinguish visible names and portal types

A different interface appears depending on the role and account type:

The three names refer to different management contexts and are not interchangeable. Which customers, sub-estates, or products are visible still depends on the account, role, and permissions. For detailed guidance on navigating a customer tenant, see Commission a Sophos Fusion tenant securely; Sophos portals at a glance explains the different portal types.

Prepare for the transition

1. Document the affected account type, tenant, data region, and admin role in use.
2. Confirm that login works in a supported, up-to-date desktop browser. Do not change authentication, the role, or the identity provider at the same time.
3. Record local references to the previous portal entry point: browser bookmarks, the password manager entry, internal documentation and start pages, and, if applicable, proxy or web filter rules and Conditional Access target definitions.
4. Inventory technical references separately: API hosts, redirect URIs, OIDC callbacks, webhooks, self-service links, scripts, and hard-coded product endpoints.
5. Have a test account with the admin role intended for operations ready for the acceptance test. If the Enterprise or Partner portal is also used, a corresponding test account is required for each portal type in use. Also have a second authorized admin and a private browser window ready.

MFA, passkeys, and recovery are not reconfigured in this runbook. For those topics, see Secure Sophos Fusion login with MFA, passkeys, and an IdP. Changes to Entra ID, Conditional Access, or OIDC follow the separate instructions for Microsoft Entra ID or OpenID Connect and Okta, respectively.

Update the login entry point and local references

The current user-facing entry point is:

➜ Open Sophos Fusion

1. Open https://fusion.sophos.com directly in a private browser window.
2. Complete the normal login process and verify the tenant, account type, and role.
3. Update the browser bookmark and the portal link in the internal admin documentation to https://fusion.sophos.com only after a successful test.
4. In the password manager, only add or update the login URI or its association for this portal entry point. Do not move credentials, passkeys, or stored technical URLs indiscriminately.
5. If a proxy, DNS security service, or web filter in use blocks the new host, allow the destination host actually recorded in the logs with the narrowest scope required, then test again. Do not create unsubstantiated wildcard exceptions for *.sophos.com or entire categories, and do not disable TLS inspection indiscriminately.
6. If Conditional Access is configured for the login flow, review the actual sign-in events. A new hostname does not justify either a broad exception or a change to user, device, location, or MFA conditions.

When fusion.sophos.com is opened, the browser may be redirected through legacy-compatible Central infrastructure. Observed hosts or paths containing central.sophos.com do not indicate a rollback or prove that the tenant is incorrect. What matters is a trusted Sophos destination, the expected login, and the correct management context.

Leave technical Central identifiers unchanged

The visible renaming is not a technical search-and-replace operation. The following values remain exactly unchanged unless the relevant integration or documentation explicitly specifies a new value:

• Sophos documentation paths containing /central/;
• existing Sophos Central API names, API hosts, and base URLs;
• configured redirect URIs and callback values, for example https://federation.sophos.com/login/callback;
• the technically required, legacy-compatible self-service entry point https://central.sophos.com/manage/self-service;
• webhooks, script variables, secrets, certificate references, and other technical endpoints with central in their names;
• stable internal slugs, search terms, and historical records.

Such values may be protocol contracts or subject to exact matching. Editorial renaming can disrupt SSO, API clients, or user access. Handle license tasks instead in Activate, verify, and renew Sophos Fusion licenses.

Validation

The transition is complete when the following applicable items have been checked with a test account assigned the admin role intended for operations. Repeat the test for each additional portal type in use with the test account intended for that portal type:

• https://fusion.sophos.com opens the expected Sophos login without a certificate or filtering warning.
• Configured MFA and, if used, the federated login flow continue to work unchanged; the expected role and correct tenant are visible.
• The customer, Enterprise, or Partner context displays the appropriate visible name.
• My Environment, Global Settings, the profile, and Sophos Help are accessible as permitted by the role.
• An existing API or automation smoke test completes without changing the host or secret.
• If configured or used, the SSO callback, self-service link, and other technical Central endpoints continue to work unchanged.
• If a proxy, DNS security service, web filter, IdP, or Conditional Access is used, its logs show no newly blocked requests or unexpected exceptions.
• Old internal instructions point to the Fusion URL for admin access but retain exact technical Central values.

Troubleshooting

Redirect to a Central host

Do not switch back to what appears to be an old state. First verify the certificate, complete redirect chain, destination tenant, and successful login. Legacy names in the runtime infrastructure may still be correct.

Blocked or blank page

Test in a browser without extensions or in a private browser window, and record the time, source URL, final host, and error message. Then check the logs of the proxy, DNS, web filtering, and TLS inspection systems in use for the specific host being blocked. Make only the change supported by this evidence; do not allow wildcards as a precaution.

If multiple independent logins or tenants are affected at the same time, use Sophos Status to check for a possible wider service outage. The status page is a diagnostic indicator; continue to make local changes only on the basis of verified causes.

Login or Conditional Access errors

Compare the Sophos login events chronologically with those from the IdP, if one is used. Do not recreate an IdP app, callback URL, or Conditional Access policy solely because of the new visible name. For diagnosis and rollback, follow only the SSO runbook linked above for the affected login flow; retain the tested fallback admin.

Missing menu item

First check the account type and role. Then look under My Environment, use the gear icon for Global Settings, and check the profile and Sophos Help. A missing menu item may reflect a role or license limitation; it does not prove that the renaming failed.

Missing tenants, products, or customers

Log out, start again in a private browser window with the intended identity, and verify the account type and tenant. Do not create replacement tenants, trials, or new partner assignments as a fix.

If access remains disrupted after these checks, collect the affected time window with time zone, affected identity, tenant or Customer ID, browser, source and destination hosts, error message, and sanitized screenshots. Then escalate by following Open a Sophos support ticket with Support Assistant.

Local rollback

The vendor-side renaming from Sophos Central to Sophos Fusion cannot be rolled back by the customer. Only the local adjustments made as part of this change may be reverted:

• bookmarks and internal documentation links,
• login URI associations in the password manager,
• specific proxy, DNS, or web filter rules.

Before reverting, retrieve the previous value from the change documentation and then test access again. IdP or Conditional Access adjustments are not part of this local rollback; revert them only according to the SSO runbook linked above for the affected login flow and its documented rollback procedure. The old Central hostname is not a guaranteed rollback path. Do not modify API hosts, callbacks, self-service URLs, or other technical values that were intentionally left unchanged for this transition.