Sophos Managed Risk: Systematically diagnose scans and appliances

If a Sophos Managed Risk scan fails, hangs or returns unexpectedly few results, a symptom-based diagnosis is faster than restarting the appliance or broadly opening the firewall. This runbook walks through four possible areas of failure: external cloud scanning, internal scanning appliance, target reachability, and authenticated access.

Find the right diagnostic branch in five steps

1. Capture affected scan, scanner, time window and exact visible status.
2. Select the appropriate symptom branch in the following table.
3. First check scope, network path and configuration; only make a limited correction at a time.
4. Validate again using the same target and a comparable time frame.
5. If the error persists, create an evidence package with all secrets removed and escalate to the correct recipient.

Record the initial state first

Under My Products > Managed Risk > Scans open the appropriate tab External or Internal. With an internal scanner, also move the mouse over Status and record the detailed status.

Start by recording the information needed to reproduce the issue:

• Tenant or account ID and account region
• Scan name and for internal scans, scanner name
• Scan Type: Discovery, Authenticated or Unauthenticated
• expected and actually captured target
• scheduled start, observed start and end with time zone
• complete status or error text
• latest change to scan, scope, exclusion, credential, firewall, VLAN, hypervisor or IP assignment
• an affected target and, if available, a functioning comparison target

Then only change one variable at a time. This makes it clear which correction actually helped.

External scan does not reach the target

Managed Risk uses regional Tenable Cloud Sensors for external vulnerability scans. The decisive factors are therefore the account region and the currently published sensor networks - not an older IP list from a ticket.

For the complete configuration and scope limits, see Set up external Managed Risk scans. This section only isolates the fault indicated by the symptom.

1. In the email Welcome to Sophos Managed Risk Service, check the region of the Sophos Fusion account.
2. If the email is missing, open the welcome case under Threat Analysis Center > Cases and read the region there.
3. In the current Tenable Cloud Sensors list, determine exactly the IP ranges for this region.
4. Check the firewall to see whether incoming connections from these areas are allowed to the authorised public targets. Limit target address and published services closely.
5. Check the available firewall or load balancer event window to see if a connection was rejected from the expected sensor range. No vendor-specific log path is required.
6. After a correction, wait for the next authorised scan or a test agreed with the Managed Risk Team and check the same target again.

Temporarily unblocking the entire Internet is not a suitable test. Do not add an extra web app scanning address from another Tenable support case to the Managed Risk allowlist.

External does not show scan settings

The external scanning settings become available only after at least one authorised contact has been saved:

1. Open My Products > Managed Risk > Settings > Authorized Contacts.
2. Check that Primary is assigned a Sophos Fusion admin and that contact details are complete.
3. Select Save.
4. Reopen My Products > Managed Risk > Scans > External.

You cannot change external scan settings that have already been saved. For a reset or change under Threat Analysis Center > Cases > Create case, select type Managed Risk service request. Do not try to circumvent the restriction by using a second, different scope.

Scope is rejected or contains unexpected targets

Check external scope against the limits

The following limits apply under My Products > Managed Risk > Scans > External:

• Add Domains: maximum of 25 publicly registered and Internet routable domains
• Add IP addresses: maximum of 100 unique IP addresses or CIDR ranges
• external CIDR ranges: no prefix smaller than /24
• maximum 1,000 external devices
• no private ranges such as 10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16

A name like firma.local or a private IP is not a valid external destination. In the event of an error message, add the entries individually instead of as a large list. This makes it clear which value fails due to the format, public accessibility or a limit. Do not use another public IP as a placeholder.

Compare internal targets and global exclusions

Discovery and vulnerability scans accept IP addresses, CIDR ranges, and hostnames under Add scan targets. A syntactically valid target can still be missing if it has been globally excluded.

Under Managed Risk > Settings > Global Exclusions, check all entries against the affected hostname, IP address and parent CIDR range. A global exclusion affects internal and external scans. Therefore, do not delete or widen an exclusion too quickly. First compare the name, description, Add targets and the approved purpose with the actual scope. If a change is necessary, just correct the incorrect target and then check both scan types for unintentional coverage.

Scanner stops or appears offline

Immediately after it is added, a new scanner shows Waiting for Deployment. After deployment, it moves through the visible states Downloaded, Waiting for appliance, Loading plugins and finally Connected. The status shows where to focus the investigation.

For installation and baseline configuration, see Set up internal scans and the scanning appliance. The checks below assume that setup is complete.

1. Compare the VM with the supported hypervisor versions and the minimum vCPU, RAM and storage sizing in the linked deployment guide.
2. Check the effective CPU generation presented to the VM. On VMware, also verify that EVC meets the documented baseline; on Hyper-V, Processor Compatibility Mode must not be enabled.
3. Confirm that the appliance still has its reserved DHCP address or documented manual address, and that its gateway, DNS and time synchronization are working.
4. In the applicable firewall or proxy events, verify outbound access only to the ports and domains documented in the deployment guide. Do not replace that list with a broad Internet rule.
5. If image generation remains pending for more than a few minutes, refresh the Sophos Fusion page as described in the deployment guide. If a VMware deployment must be started again, use a newly generated single-use OVA rather than the old file.
6. Allow up to 30 minutes for the first start and initial plugin load. Only treat Loading plugins as stuck after that window; then record the hovered status and elapsed time rather than restarting the appliance.

Internal scan runs too long or does not reach targets

A large scope can look like an appliance failure. CIDR ranges with /16 or smaller prefix can cause timeouts because a large number of addresses are being checked. Divide such networks into technically sensible areas and schedule the scans on different days or at different times. No unauthorised networks are allowed to enter the scope.

If only individual targets are missing, this short network-path check is usually faster:

1. Is the target entered in the correct discovery or vulnerability scan?
2. Does a Global Exclusion cover the target directly or through a CIDR range?
3. Does the scanner continue to use the reserved or manually configured IP address?
4. Is the target on a different VLAN? Then the scanning appliance needs full bi-directional access to all ports and protocols required to scan that target.
5. Does a network ACL, host firewall, IPS/IDS rule, or endpoint protection policy block access from the scanning appliance IP address?

Do not allow unrestricted traffic between VLANs. Limit a rule from the fixed scanner IP to the approved targets and validate exactly these targets on the next scan. If even a small, accessible scope remains in Running or if no report appears under Managed Risk > Report History after completion, save the time, scope and status for product support.

Authenticated results missing

An Unauthenticated scan simulates an external attacker and typically detects fewer vulnerabilities. An Authenticated scan gets deeper access and usually finds more. However, this only works if the correct credential is assigned and the target allows the required access.

For credential types, creation and secure assignment, see Configure credentials for authenticated scans. This section only diagnoses why an existing assignment does not return authenticated results.

Open the vulnerability scan under My Products > Managed Risk > Scans > Internal. The configuration is only correct if all of the following points are met:

• Scan type is set to Authenticated.
• The credential intended for the target is selected under Select credentials.
• A scan uses a maximum of ten credentials.
• Optional Targets of an SSH credential contain the affected host or its area.
• Credential type and destination match: Windows, SSH, SNMPv3 or VMware ESX SOAP API.
• The credential was updated after a password, key, domain, KDC, or permission change under Managed Risk > Settings > Credentials.

Do not delete credentials as a test. Deleting removes a credential from all scanning configurations that use it.

For Windows, a dedicated local administrator account should be used for normal systems. Domain administrator credentials only belong in separate, specially protected scans for domain controllers. Host firewall, local or domain policies, endpoint protection, IPS/IDS, WMI, administrative shares and Remote Registry must not block the scan path.

For macOS and Linux, check the SSH access, the selected authentication, permissions and any privilege elevation on the target. With Kerberos, KDC, realm, transport and reverse DNS must fit together. Do not weaken operating system settings globally just for testing purposes.

Test Windows credentials in a controlled manner

The following documented tests apply only to Windows credentials. The starting point is an authorised Windows system on the same subnet as the scanning appliance to ensure network conditions remain comparable. Use an administrative Command Prompt or PowerShell session and the exact same credential as in Sophos Fusion. Make sure beforehand that neither a persistent command history nor a session recording saves the input.

First check IPC$ and the administrative share:

net use \\<Target_IP>\ipc$ /user:<username> *
net use \\<Target_IP>\admin$ /user:<username> *

The command completed successfully is expected in each case. The first success confirms basic network and credential functionality, the second administrator access and share access.

If both connections work, Remote Registry and WMI follow:

reg query \\<Target_IP>\HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion /v ProgramFilesDir
wmic /node:"<Target_IP>" /user:"<username>" /password:* os get name

A returned ProgramFilesDir confirms that Remote Registry is reachable with this credential. An operating system output confirms WMI access. If only one of these steps fails, correct this exact path - share, service reachability, WMI rule or permission - on the target. Do not grant additional permissions until you have identified the specific cause of the rejection.

Always disconnect the two session connections after the checks - even if a partial step fails:

net use \\<Target_IP>\ipc$ /delete
net use \\<Target_IP>\admin$ /delete

Then run net use and confirm that no connection to the test target remains, close the shell, and make sure no password was saved in notes or diagnostic attachments. Run an authorised scan with the same credential and compare the results.

Interpret differing results correctly

Different findings are not automatically an error. Two tools or scan runs may use different rules, plugins and update cycles. In addition, the operating system, open ports and Scan type determine which checks are applicable.

For a reliable comparison, note the following points:

• Product and scan type of both comparisons
• Scan time and target scope
• authenticated or unauthenticated
• Credential used successfully, without secret
• accessible services and changes between runs
• Affected vulnerability or CVE and visible justification text

Managed Risk does not assess web application or API level vulnerabilities. A missing web app or API finding is therefore not evidence of a defective network vulnerability scan. Conversely, an Authenticated scan with more findings does not prove that the earlier Unauthenticated scan was defective.

If a specific finding remains unclear despite comparable conditions, request a technical review by the Managed Risk Team under Threat Analysis Center > Cases > Create case > Managed Risk service request.

Compile an evidence package without secrets

The evidence package should reduce follow-up questions without creating new risks. Include:

• Tenant or account ID and account region
• Scan and scanner name
• visible status and full error text
• Start, end and reproduction time with time zone
• Scan type, targets and relevant exclusions
• for appliance problems: hypervisor and version, VM hardware version, CPU model or EVC mode, vCPU, RAM, storage and IP allocation type
• for network problems: scanner IP, affected target, VLANs and result of the firewall/ACL check
• for credential problems: credential name and type, assignment to the scan and result of IPC$, ADMIN$, Remote Registry and WMI
• latest relevant changes and business impact
• Secure correction that has already been carried out and the result of the repeat test

Do not include: passwords, NTLM hashes, private keys, passphrases, KDC secrets, session data, or complete unnecessary system output. Screenshots and logs may contain internal IP addresses, hostnames and usernames and are only transmitted via the agreed protected support channel.

Choose the right escalation route

For creating, securely sharing and tracking cases, see Create and manage Managed Risk cases.

Managed Risk Team

Questions about service, scan coverage, results or reports, as well as changes to saved external scan settings belong in a Managed Risk case:

Threat Analysis Center > Cases > Create case > Managed Risk service request

Use a meaningful case name and attach the sanitized evidence package. The shared case list includes XDR, MDR, and Managed Risk cases, so check that Case type is Managed Risk. Only Sophos teams handle Managed Risk cases.

Product Support

A reproducible product or appliance fault should be sent to Product Support. These include an appliance that does not become Connected despite meeting the platform and network requirements, a persistent intermediate status or a technical error in the interface. In Sophos Fusion, open the Help icon, select Create support case and send the cleaned evidence package.

MDR Operations

Route only active MDR incidents to MDR Operations. Escalate a failed vulnerability scan, scan setting or faulty scanning appliance through the appropriate Managed Risk or Product Support route above.

Remote assistance only for a specific support case

Only activate Remote Assistance when Product Support requests it for an existing case. The appliance must be online for this.

1. Open My Products > Managed Risk > Scans > Internal.
2. Open the three-dot menu in the row of the correct appliance on the far right.
3. Select Remote Assistance.
4. Activate Enable in the dialog.
5. Confirm the Sophos Group Privacy Notice checkbox and select Save.
6. Wait for Sophos Fusion to display Access ID.
7. Only send the Access ID via the agreed support channel and only for the relevant case.

Remote Assistance ends automatically after seven days. If it is no longer needed, switch off the Enable option in the Remote Assistance dialog. If Access ID cannot be obtained, first confirm that the appliance is online; then add the visible error to the existing product support case. Do not restart or wipe the appliance to force Remote Assistance.