Secure Sophos Fusion sign-in with MFA and passkeys

Sophos Fusion (formerly Sophos Central) controls policies, exclusions, Live Response and device isolation. A compromised administrator account can therefore cause more damage than a single infected endpoint. MFA is the minimum requirement, but it does not replace appropriate roles or a recovery process.

Distinguish Partner, Customer and Enterprise access

For Sophos Fusion Partner, the requirement is explicit: every Partner administrator must register at least two MFA methods and authenticate with MFA at every sign-in. Passkeys and TOTP authenticator apps are supported; any of the registered methods can be used to sign in. Initial enrollment sets up a password and at least one TOTP app; passkeys can be added afterwards. When Sophos prompts for two methods to be registered, complete that registration. The following sections explain how to set up TOTP and passkeys and choose independent devices.

A Partner account and a managed Customer tenant are not the same administrative scope, however. The Partner requirement does not mean that MFA, SSO or recovery settings are automatically inherited by Customer or Enterprise accounts. Before making a change, check which portal you are signed in to and which account the affected identity belongs to. For an MFA reset, this scope determines the authorized administrator and the correct procedure: the Super Admin of the Customer tenant, or the Partner Super Admin in the Partner portal. The Customer and Partner procedures below do not replace a separately verified Enterprise recovery procedure.

Set up MFA immediately and redundantly

Every administrator must register at least two MFA methods and is prompted for MFA at every sign-in. Sophos supports passkeys and authenticator apps with time-based one-time passwords, or TOTP.

Register two independent methods for privileged accounts, such as a passkey on a hardware security key and an authenticator app on a separate device. Two passkeys on the same laptop do not provide genuine redundancy. Sophos also identifies two passkeys on separate devices or two separate authenticator registrations as possible combinations.

Replacement hardware security keys and documented recovery information belong in a protected corporate vault. They must not be stored in one employee’s personal password manager or in an open ticket.

Each administrator account can register at most ten TOTP authenticator apps. A browser authenticator extension is technically possible, but it is a third-party product not developed or supported by Sophos. Before installation, review the publisher, permissions, update path, and corporate policy. For a privileged account, an extension in the same browser profile as the Sophos Fusion session does not provide good factor separation.

Manage registered methods in the profile under Manage login settings or Manage MFA. Deleting an entry only from the local authenticator app does not remove it from Sophos Fusion. When changing devices, first test a second method, then remove the old Sophos Fusion registration, and reset the old device only afterward.

Configure an authenticator app

After signing in with an existing method, open profile icon > My info > Manage MFA. Alternatively, Sophos ID > My Profile > Manage MFA opens the same management page. Reauthenticate, select the plus icon on Multi-Factor Authentication, choose Authentication App under Set up MFA method, and then select Set up now.

Scan the one-time QR code with the approved authenticator app. Enter its generated security code in Sophos Fusion, optionally assign a unique device name, and choose Continue. Successful enrollment confirms registration; another Continue completes the workflow. At the next test sign-in, enter the app’s current verification code after email address and password.

An account can have no more than ten authenticator apps. Do not store the QR code or underlying TOTP secret as a screenshot. After testing, configure a second independent method before removing an old device or registration.

Configure a browser-based authenticator app

A browser extension can generate TOTP codes, but privileged accounts should use one only after a deliberate risk assessment:

1. In Sophos Fusion, open profile icon > My info > Manage MFA and confirm with an existing method.
2. Under Multi-factor Authentication, select the plus icon, choose Authentication App, and open Set up now.
3. Keep the one-time QR code open. In another tab, install the approved extension from the browser’s official extension store.
4. Return to the QR code page, open the extension beside the address bar, and select Add Account > Scan QR from screen.
5. Enter the generated code under Verify Your Device > Security Code, optionally assign a unique device name, and select Continue.
6. Under profile icon > My info > Manage MFA, verify the method is registered. A test sign-in must work with the username and password and the extension’s code.

The QR code is a one-time registration secret and must not be stored as a screenshot or sent in a ticket. Review the publisher, requested browser permissions, update source, and data synchronization before approval. Because the browser profile, Sophos Fusion session, and TOTP secret would otherwise reside together, retain a separate method on another device or hardware key.

Manage registered MFA methods

Open profile icon > My info > Manage MFA or Sophos ID > My Profile > Manage MFA. After reauthentication, Sophos Fusion shows all registered methods, their default or display name, and last use.

Use the plus icon to add another authenticator app or passkey. At most ten registrations are possible per method type. From a method’s three-dot menu, select Rename, enter a new name, and confirm with the check mark. Delete removes the registration from Sophos Fusion.

At least two MFA methods must remain registered. Once only the required minimum remains, Sophos Fusion does not allow another deletion. Continue closes management and returns to the Sophos Fusion dashboard. Test the new method in a separate sign-in before removing the old one.

Configure a passkey and choose its storage

Add a passkey as another method only after an authenticator app is configured. Under profile icon > My info > Manage MFA, reauthenticate, select the plus icon, and choose Passkey. The operating system or credential manager guides PIN or biometric verification. On Windows, for example, this can be a fingerprint through Windows Hello. After Passkey Saved, confirm with OK, check the new registration in the method list, and finish with Continue.

Storage location is part of the security decision. Options include a credential manager on the local computer, such as a browser, operating system, or enterprise password manager; a device-bound authenticator such as YubiKey; or a mobile device through a QR-code workflow. For resilience, register passkeys on more than one controlled device. Sophos Fusion permits at most ten passkeys.

Sign in with a passkey or authenticator app

For passkey sign-in, open fusion.sophos.com, enter the email address, and select Continue. On the passkey page, Login with passkey starts the registered method, such as fingerprint, device PIN, or hardware key. The Sophos Fusion dashboard opens after successful verification.

When a passkey and authenticator app are registered, Sophos Fusion prefers the passkey. Try another way permits another method after entering the password. For classic authenticator sign-in, enter the email address and select Continue, then enter the password and choose Sign in. On MFA Validation Required, enter the current authenticator code.

Test both workflows after setup, device changes, and browser updates. A stored passkey alone is not sufficient recovery when the credential manager, device access, and Sophos Fusion session are affected by the same failure or account lockout.

My info, role, and local password

Under profile icon > My info, an administrator sees the current role, Sophos Fusion sign-in address, and password and MFA settings. Selecting the role name opens its full permissions. The email address is therefore also an important mapping attribute for sign-in, role review, and support cases.

Change a local Sophos password under My info > Password > Change password. After verification, Sophos Fusion shows the current password prefilled. The new password requires at least eight characters, including a lowercase letter, uppercase letter, and either a number or special character. After Reset Password, Sophos Fusion signs the administrator in automatically with the new password and returns to the portal; the old password becomes invalid immediately. With federated sign-in, change the password at the responsible identity provider instead.

Account Details also contain personal email subscription settings. These subscriptions are not the tenant-wide Alert recipients under Configure Email Alerts. Manage administrators, distribution lists, and ticketing systems that receive security notifications through Configure Sophos Fusion alert emails and notifications.

Secure sensitive actions with transaction MFA

Transaction Authentication using MFA requires additional authentication before selected sensitive actions in the Customer tenant (CDB). It is not a general action protection feature for the Partner or Enterprise dashboard. Confirmation uses the passkey or authenticator app already registered for Sophos MFA. According to the announcement of September 15, 2026, the feature is off by default.

Before activation, verify the correct Customer tenant, a Super Admin authorized to make the change, and a working registered MFA method. The permissions and licenses required for Live Response or the particular Response Action remain separate. If an administrator is allowed only federated sign-in and MFA is provided exclusively by the federated IdP, this setting is unavailable to that administrator. Do not change the IdP configuration solely for this test.

1. As a Super Admin in the Customer tenant, open Global Settings > Access Control > Sign-in and Identity > Multi-factor Authentication and record the existing state. If the option is missing, check the tenant, role, and sign-in method first; the announcement alone does not establish availability in your tenant.
2. Before enabling it, inform the affected administrators and allow pop-ups for Sophos sign-in. If the browser blocks them, consider a targeted exception for sophos.com rather than disabling pop-up protection generally.
3. Under Transaction Authentication using MFA, enable Require re-authentication before executing high risk operations. Do not accidentally enable the separate Expand MFA Coverage option: it extends MFA to additional portal sign-ins and cannot be disabled again once enabled.
4. Reopen the page and verify that the setting is enabled. The affected administrators must then sign out and sign back in for the change to take effect in their new Fusion session. An already open session is not a valid test of its effect.

In the new session, reauthentication is expected every time a Live Response session starts. For a Response Action, it is required if the last reauthentication did not occur within the preceding 15 minutes. This is not a blanket 15-minute window for Live Response or a promise that every possible action type is covered.

Check the MFA prompt during the next explicitly authorized action; do not trigger device isolation, another Response Action, or a production Live Response session solely for testing. If the expected prompt is missing, first check the new sign-in, saved setting, Customer context, IdP exception, and pop-up blocking. If the behavior still differs, do not approve the sensitive action as sufficiently protected; escalate to Sophos Support with the tenant, time, and observations, without credentials. The reviewed help describes enabling the feature but provides no reliable disable or rollback procedure; therefore, do not promise reversal without verification.

Understand device-bound sessions with DBSC

Device Bound Session Credentials (DBSC) bind a session to a cryptographic key on the device. The browser regularly proves possession of this key, making a stolen session cookie less useful on another device. This is an additional layer against session theft, not a replacement for MFA, secure endpoints, or deliberate sign-out.

Sophos announced DBSC for Customer, Enterprise, and Partner dashboards (CDB, EDB and PDB). With a supported browser and platform, it works transparently; no customer switch or custom DBSC implementation is required. The Sophos announcement of September 15, 2026 lists Google Chrome and Microsoft Edge version 146 or later on Windows with TPM and version 147 or later on macOS. Confirm platform support and whether the feature is enabled for the session; the announcement alone does not establish either.

Google describes the underlying DBSC capability already for Chrome 145 on Windows. That is not equivalent to the higher Sophos threshold and does not confirm Edge or macOS support for Sophos Fusion. Without suitable browser/platform support, do not plan on DBSC as an available protection. Inventory the browser and operating system versions actually deployed for rollout; successful sign-in alone does not prove DBSC binding.

Limit idle administrator sessions

MFA protects sign-in, but not an already open session on an unattended computer. Under Connected Sessions, Session Idle Timeout specifies how many hours of inactivity can pass before an administrator must sign in again. Sophos documents this setting separately for the Customer, Enterprise, and Partner portals. Before making a change, verify the portal in use, the associated account or tenant, and the sign-in method. When accessing Customer accounts through a Partner or Enterprise session, that session’s timeout takes precedence according to the session announcement. The Customer value alone therefore does not describe that session. This priority is not an automatic copy of Customer settings or general inheritance of MFA, SSO, or other account requirements.

1. In the relevant portal, open the Global Settings icon and select Access Control > Sign-in and Identity > Connected Sessions.
2. Record the previous Session Idle Timeout value so it can be restored if needed. The permitted range is 1 to 23 hours, and the documented default is 3 hours.
3. Enter the maximum idle duration and select Save. For privileged administrator accounts, 1 hour is a deliberately strict Avanet pilot example, not a Sophos default. A shorter value limits the time during which an unattended idle session can remain usable, but requires more frequent sign-ins during normal operation. Agree on the value with the responsible administrators; the timeout replaces neither screen locking nor deliberate sign-out.

After saving, reopen the page and verify the saved value. To test its effect, have a test administrator sign in to the same portal in a separate browser session. Leave that session open without interaction for longer than the configured duration, then open a protected page. A new sign-in prompt is expected. Then successfully complete the local or federated sign-in flow actually used, including the MFA required by that flow. Perform this test separately for each affected portal.

If the session remains usable after the intended period of inactivity, first check the portal, tenant, saved value, and any possible activity during the test. Then repeat the test with a freshly signed-in session. If the result still differs from the expected behaviour, document the portal, time, and observations for Sophos Support without including credentials. If the change must be rolled back, save the previously recorded value again and repeat the verification.

Session Idle Timeout does not promise immediate revocation of all already open sessions and is not a substitute for measures to address a compromised account. It also does not imply automatic inheritance between the Customer, Enterprise, and Partner portals. During a security incident, also review account access, roles, the IdP, and Audit Logs.

Understand passkeys correctly

Passkeys are phishing-resistant when the key is bound to the genuine Sophos Fusion domain and protected by a device PIN or biometrics. A synchronised passkey is convenient, but inherits the security and recovery characteristics of the Apple, Google or Microsoft account used.

For Super Admins, a managed hardware security key is a particularly robust method. Before making this a tenant-wide requirement, verify that emergency access, replacement keys and offboarding work.

Microsoft Authenticator is not supported for a Sophos passkey outside a federated Entra ID sign-in. The app can still be used as a TOTP authenticator. Depending on the platform, cross-device passkeys require Bluetooth, physical proximity and a QR-code workflow.

An account can register no more than ten passkeys. Replacement of legacy factors and lockout logic are covered separately below because they affect both TOTP and passkey accounts.

Current documented support includes Windows 10 and 11, macOS 10.15.7 or later, Android 9 or later, and iOS and iPadOS 16 or later. Sophos lists minimum browser versions of Chrome 118, Firefox 119, Safari 16 or later, and Edge 119. Common stores include Windows Hello, Google Password Manager, iCloud Keychain, and 1Password; Sophos names YubiKey 5 and YubiKey NFC as device-bound keys. Other combinations can work when browser and operating-system vendors implement the required passkey protocols.

Sophos estimates this support covers about 98 percent of browser and operating-system combinations in use and common credential managers. This is a reach estimate, not a platform guarantee. Test the operating system, browser, credential manager, synchronization policy, and recovery with the versions actually deployed.

Synchronized passkeys work for Sophos sign-in, but synchronization remains a credential-manager function. iCloud Keychain can, for example, make passkeys available across Macs, iPhones, and iPads using the same iCloud identity. The credential-manager vendor is responsible for synchronization failures. Cross-device passkeys require Bluetooth enabled on computer and mobile device, nearby devices, and a QR-code scanner.

Microsoft Authenticator can use a Sophos passkey only in the context of federated Entra ID sign-in. Without that sign-in method, registration typically shows Failed to add passkey or Microsoft Authenticator doesn’t support this passkey. It remains independently usable as a TOTP app.

With 1Password Business, team or Shared Vault policies can block passkey registration. 1Password then appears in the enrollment dialog but is disabled. The responsible 1Password administrator must permit enrollment in Team Policies; repeatedly deleting the Sophos MFA method does not correct that external policy.

Deprecated MFA methods and account lockout

SMS and email plus PIN are deprecated MFA methods. New Sophos Fusion users must use a TOTP authenticator app or passkey. When MFA is reset for an existing user with SMS or email plus PIN, Sophos Fusion treats the user as new during reenrollment and likewise requires TOTP or a passkey.

After five consecutive incorrect sign-in attempts, Sophos Fusion initially locks the account for one minute. Further attempts with the same account gradually extend the lockout to at most five hours. Do not continue automated attempts after a lockout. If no second method or another Super Admin is available, Sophos Support can unlock the account after identity verification.

Federated sign-in through an Identity Provider

With a supported Identity Provider, Sophos Fusion can delegate sign-in to the central corporate identity. This simplifies Conditional Access, lifecycle management and central account suspension. Sophos Fusion uses a service-provider-initiated flow, or SP-initiated SSO: sign-in starts at Sophos Fusion and is redirected from there to the IdP.

The setup follows a fixed sequence. First verify the organisation’s domain using a DNS TXT record. DNS propagation can take up to 24 hours. A successful verification remains valid for one year and must then be renewed. Next associate the Identity Provider with the verified domain, and activate the required sign-in option only at the end. These tasks require Super Admin permissions.

Sophos Fusion can either permit federated credentials only or also allow a Sophos Fusion email address and password. With Microsoft Entra ID, Sophos Fusion continues to display both options even when Federated credentials only is selected. With other identity providers, this setting instead redirects straight to the IdP without a selection step. This difference must be included in the lockout test.

Select the mode under Global Settings > Access Control > Sign-in and Identity > Sophos sign-in. It generally applies to all Sophos Fusion products. Custom Sign-in Rules can be defined for individual administrators, for example to preserve controlled Sophos sign-in as a fallback during the pilot. A user can be assigned to only one verified domain and identity provider.

With Federated credentials only, users cannot reset their Sophos password themselves. If the tenant later returns to Sophos sign-in only, these accounts may not yet have a usable password and must complete Reset Password. Self Service Portal users with federated-only sign-in receive no separate password-creation invitation and sign in directly through the IdP.

Expand MFA Coverage extends MFA to managed users in additional Sophos portals such as Self Service Portal, Partner Portal, and Support Portal. Once enabled, it cannot be disabled again. Save it tenant-wide only after a pilot with the actual portal users affected.

Clarify the following points before activation:

• unambiguous mapping between the email address and Sophos Fusion login,
• MFA and access rules at the IdP,
• behaviour for guest and partner accounts,
• at least one tested emergency access method,
• prevention of lockout caused by an incorrect domain or IdP configuration.

Federated sign-in does not automatically synchronise Endpoint users or device groups. These are separate functions.

When the UPN and email address differ

Sophos Fusion initially identifies the account by its stored email address. If Microsoft Entra ID uses a different User Principal Name internally, the Entra app requires a customised OpenID Connect configuration with the optional email claim and the appropriate Microsoft Graph permissions. The user continues to enter the email address assigned in Sophos Fusion and then authenticates on the Microsoft page with the UPN.

The standard instructions are sufficient when the email address and UPN are identical. Test a differing configuration with a test account first because a missing or incorrect claim prevents the mapping even when authentication in Entra succeeds.

Manage and enable identity providers

Only a Super Admin can manage a federated identity provider. At least one suitable domain must be verified first. Under Global Settings > Access Control > Sign-in and Identity > Federated identity providers, Add identity provider creates Microsoft Entra ID, OpenID Connect, or Microsoft AD FS. Partially completed providers can be saved but enabled only after complete and valid configuration.

Select the finished provider and choose Turn on. It can then be used for federated sign-in. Providers can also be edited or deleted there. Before selecting Federated credentials only, assign every affected administrator and user to a verified domain and enabled provider; otherwise, lockout occurs. First test the provider with individual accounts while preserving fallback access.

Executable provider guides are available for Microsoft Entra ID, OpenID Connect and Okta, and Microsoft AD FS.

Roles remain essential

MFA protects the identity, but does not restrict its permissions. Use Super Admin only for tenant, role, API and other far-reaching changes. Help Desk, Read-only and Custom Roles reduce the potential impact of an error or compromised account.

Plan Sophos Central Endpoint roles and permissions explains product-specific role assignment.

Lost MFA device and lockout

Test the recovery process before it is needed. First use a second registered method. If no method is available, verify the person’s identity through a known, independently confirmed contact channel before resetting MFA; an email requesting a reset is not sufficient on its own. Notify the affected user through the agreed contact channel. Do not request passwords, passkeys, QR codes or security codes from the caller or store them in the ticket.

For a user account in the Customer tenant, the recovery procedure is:

1. Use the second registered method.
2. Ask a Super Admin in the tenant to select Reset MFA on the user object.
3. Enter the security code delivered by Sophos by email at the next sign-in.
4. Register two new MFA methods and test their independent availability.
5. If no other Super Admin is available, contact Sophos Support with verifiable account details.

For a Partner identity, use the Partner Super Admin and the Partner procedure described below instead. The Customer verification email does not establish what the Partner recovery dialog will show. After a Partner reset, the user follows the sign-in and enrollment prompts actually displayed and restores at least two independent methods. If no other Super Admin is available for the Partner account, contact Sophos Support; further failed sign-in attempts are not a substitute for this recovery process.

After recovery, remove old methods, register new ones and inspect Audit Logs for unusual sign-ins or changes.

Deleting the Sophos entry directly in the authenticator app does not remove the method from Sophos Fusion. It remains registered there but no longer supplies valid codes. The method must therefore also be removed in Sophos Fusion or reset by a Super Admin. If all local methods are deleted, only a second registered method, a reset by another Super Admin or the verified Sophos Support process remains.

Reset MFA as a Super Admin

This procedure applies to a user account in the Customer tenant, not to the Partner Administer MFA page.

Only a Super Admin can reset another user’s MFA registrations. Go to My Environment > Users & Groups > Users, open the user name, select Reset MFA, and then select Reset again. A status message at the bottom confirms success.

Sophos Fusion automatically sends the user a verification email containing a security code. At the next sign-in, the user must enter that code and configure MFA again completely. Verify delivery, caller identity, and successful reenrollment; reset alone does not restore secure access. If the current account is locked and no other Super Admin is available, use verified recovery through Sophos Support.

Reset MFA in the Partner account

The Administer MFA page is visible only to a Partner Super Admin. It is the Partner procedure for managed identities; do not use the Customer path My Environment > Users & Groups > Users for this purpose. You can check the Partner account’s administrators under Global Settings > Access Control > Admin & Roles > Admins.

1. In the Partner portal, open the Global Settings icon and, under Access Control, select the Administer MFA page.
2. Enter the affected identity’s full email address. Only email addresses associated with a Partner account can be searched. A partial address is not sufficient. If nothing is found, neither a notice nor an error message appears; this is not confirmation of a reset. In that case, check the spelling and account association rather than resetting another user.
3. For the result that clearly matches the intended identity, go to the Action column and click Reset MFA. An indication at the bottom of the page confirms the successful reset.
4. Have the user configure MFA again. Then verify a successful sign-in and at least two registered methods that are independently available. A successful reset alone does not confirm that secure access has been restored.

Do not reconstruct a lost passkey from a ticket or replace it by sharing someone else’s key. Recovery uses an available method belonging to the user or an authorized reset; review old or lost registrations afterwards. If the Sophos entry was deleted only locally from the authenticator app, its registration remains in the Partner portal even though it no longer provides usable codes. The distinction explained above between local deletion and removal of the portal registration therefore still applies.

Reset a Customer user’s MFA from the Partner portal

For a user in a managed Customer tenant, Sophos documents a separate entry point:

1. Open My Business > My Customers and select Customers.
2. On Sophos Central Customers, select the correct customer and choose Launch customer. The Customer account opens with its dashboard; verify the customer association before resetting MFA.
3. Open My Environment > Users & Groups, select the affected user and choose Reset MFA in their profile.
4. Check the success message in the lower-right corner and complete recovery with the user, including notification and reenrollment.

This Customer entry point is not the email search on Administer MFA. Anyone who moves from the Partner dashboard to a Customer tenant through Partner SSO cannot change the MFA settings of that tenant’s Super Admins. If a Customer Super Admin is affected, involve another authorized Super Admin of that tenant; if no such access is available, contact Sophos Support. Switching to the Customer tenant does not remove this restriction.

Regular review

At least quarterly, review administrators, roles, API credentials, MFA methods and external identities. When a person leaves or changes role, do not merely disable Sophos Fusion access; also remove the account from administrator roles and relevant IdP groups.

Frequently asked questions