Sophos Protected Browser: Troubleshooting access and sign-in

This runbook helps isolate access problems with Protected Browser and agentless ZTNA RDP/SSH resources. In Sophos Central, go to Meine Produkte > Protected Browser and start with the visible symptom. Fix only the cause confirmed during the checks. Broad changes to DNS, the user directory or ZTNA make diagnosis more difficult.

Quick path: If adding or editing a resource already fails, check the email addresses of every member of the user group in use. If an existing resource is unreachable without a specific error message, test the ZTNA user portal first, followed by DNS resolution of the ZTNA gateway FQDN. For “Netzwerk nicht erreichbar” or “Verbindung konnte nicht hergestellt werden”, compare the identity provider configured in ZTNA directly with the sign-in method used for the Protected Browser session. If Protected Browser sign-in fails, check access to the Self Service Portal and verify that the email address is unique across tenants. Handle “Hostschlüsselüberprüfung fehlgeschlagen” separately.

Prerequisites and safe working limits

These checks require an existing Protected Browser and ZTNA environment and a clearly identified affected user. Missing menus or permissions do not prove a particular licensing or role issue. In that case, hand the check over to the responsible Sophos Central administrator.

To check the user in Sophos Central, access to Meine Umgebung > Benutzer und Gruppen > Benutzer is required. For the connectivity test, the ZTNA gateway FQDN actually configured and the gateway type must be known: Sophos Cloud Gateway or local gateway. In the command, replace the placeholder with the ZTNA gateway FQDN, not the name of an RDP/SSH target resource.

During diagnosis, change only one value at a time, then retest with the same user and device. If a prerequisite is unclear or user management is inaccessible, stop the diagnosis and hand the case over to the responsible Sophos Central, directory service or ZTNA administrator.

Troubleshooting by symptom

Adding or editing an agentless RDP/SSH resource fails

Likely cause: At least one member of the user group in use does not have a valid email address. This can affect both a ZTNA resource and an RDP/SSH resource in a Protected Browser application group.

Check:

1. Go to Meine Umgebung > Benutzer und Gruppen > Benutzer.
2. In the E-Mail column, check every user in the group that is to be assigned to the resource or application group.

Expected observation: Every user in the affected group has a valid email address. A blank entry confirms the fault condition.

Safe action: Add the missing address in the authoritative directory service. Add it directly in Sophos Central only for users created manually in Sophos Central. Do not change existing addresses speculatively.

Validate again: Repeat the attempt to add or edit the same resource with the group unchanged. If it still fails even though the E-Mail column is complete, this cause is not confirmed. Rather than changing more identity data, record the resource type, group, time and visible message, then escalate the case.

Agentless RDP/SSH resource is not reachable through Protected Browser

Likely cause: The device cannot resolve the ZTNA gateway FQDN correctly. However, the first point of isolation is the ZTNA user portal: if that is already unreachable through Protected Browser, the problem occurs before the individual RDP/SSH resource.

Check:

1. On the same device and as the same user, try to open the ZTNA user portal through Protected Browser.
2. If the portal is unreachable, run a DNS query on the affected device:

nslookup <ZTNA-Gateway-FQDN>

Replace <ZTNA-Gateway-FQDN> with the gateway name actually configured. nslookup is a read-only test and does not change any configuration.

Expected observation: For a Sophos Cloud Gateway, the gateway name resolves to the address of the gateway proxy. For a local gateway, it resolves to the ZTNA gateway address configured on the organisation’s DNS server. Compare the response with the target actually configured for the relevant gateway model. If resolution fails, the DNS configuration needs to be checked. A different response confirms a fault only if it does not match the configured target. If the intended target is unknown, do not change DNS; hand the check over to the DNS/ZTNA owner.

Safe action: Correct the DNS configuration using the designated DNS/ZTNA procedure. The correct zone and target depend on the gateway model, so do not make generic DNS changes here.

Validate again: After the DNS/ZTNA owner confirms that a correction has been made using the designated procedure, run the same nslookup query again. Then open the ZTNA user portal and only then test the original RDP/SSH resource. If the DNS response is as expected and the portal is reachable but the resource remains inaccessible, document these two successful control checks and escalate the resource-specific ZTNA investigation.

“Netzwerk nicht erreichbar” or “Verbindung konnte nicht hergestellt werden”

Likely cause: ZTNA uses an identity provider such as Okta or Entra ID, but the user is signed in to Protected Browser with their Sophos ID or as a local user. When accessing an SSH or RDP application behind the ZTNA gateway, the messages above may then appear.

Check: Identify which identity provider is configured in ZTNA and compare it with the sign-in method of the current Protected Browser session.

Expected observation: The cause is confirmed if ZTNA uses an identity provider but the Protected Browser session was not authenticated through that provider.

Safe action: End the affected session and sign the user in to Protected Browser through the identity provider configured in ZTNA. Do not change the ZTNA identity provider to work around a single sign-in error.

Validate again: In the newly authenticated session, open the same SSH or RDP application. If the message remains despite matching sign-in methods, record the identity provider, user, resource and time, then hand the case over to the ZTNA owner.

User cannot sign in to Protected Browser

Check two independent causes here. Do not fix them at the same time, so it remains clear which one was the actual cause.

No access to the Self Service Portal

Check: Go to Meine Umgebung > Benutzer und Gruppen > Benutzer and check the Rolle column for the affected user. Alternatively, select the username and check the text below the profile photo.

Expected observation: If the user has access to Sophos Central Self Service Portal, SelfService appears in the Rolle column or below the profile photo.

Safe action: If SelfService is missing, hand the assignment of Self Service Portal access over to the responsible Sophos Central administrator.

Validate again: First confirm that SelfService is displayed, then repeat the sign-in attempt with exactly that user.

Email address is linked to multiple Sophos Central accounts

Check: Establish whether the affected user’s email address is assigned to more than one Sophos Central account.

Expected observation: The address must not be linked to multiple Sophos Central accounts.

Safe action: Have the responsible tenant or identity administrator correct the assignment. Do not delete a user or change a production address without a confirmed target tenant.

Validate again: Once the unique assignment has been confirmed, repeat the Protected Browser sign-in. If it still fails, document SelfService, the email assignment, time and visible message for escalation.

SSH reports “Hostschlüsselüberprüfung fehlgeschlagen”

Likely cause: The key stored in the SSH client no longer matches the host’s key. This can happen after a legitimate change such as a reinstallation, but the same message can also indicate an unexpected change.

Check: Obtain the expected host key fingerprint from the system owner through an independent, trusted channel and compare it with the fingerprint of the correct target host. Do not rely on either the failed SSH connection or the new key offered there. If the expected fingerprint has not been independently confirmed, does not match or the change cannot be explained, stop here and escalate the matter as a security incident.

Expected observation: The target host, legitimate key change and expected fingerprint have all been independently and unambiguously confirmed.

Safe action: Before deleting anything, establish which entries the SSH client’s offered function removes. Sophos gives Bekannte Hosts löschen as an example, but does not confirm that this function removes only the affected host. If the deletion scope is unknown or the expected fingerprint cannot be independently confirmed, do not perform a reset; escalate instead. Remove the stored key only when the scope is clear and the fingerprint confirmed. On the next connection, accept only the key whose fingerprint matches the independent confirmation.

Validate again: Re-establish the connection. Host key verification should succeed with the newly accepted key. If the message appears again or the key changes unexpectedly once more, do not repeatedly remove entries; escalate with the hostname, time and SSH client.

Reversal, escalation and operational limits

There is no universal rollback for these issues. The safe way back is to avoid broad changes and record the initial value of any user assignment changed in a targeted way. If the action does not resolve the issue, stop at the relevant escalation point. Deleting known SSH host keys is not a general reset and is acceptable only when the fingerprint has been independently confirmed and the deletion scope is known.

For a support or internal escalation, record at least the symptom, user, device, resource type, gateway model, ZTNA gateway FQDN, time and result of the directly related check. Credentials, private keys and tokens must not be included in the ticket.

Repeat only the check associated with the action actually taken or the confirmed handover: adding or editing the resource again after an email correction; signing in after confirmed Self Service Portal access or unique account assignment; opening the resource after signing in through the configured identity provider; or connecting over SSH after the controlled host key reset. Following a handover to the DNS/ZTNA owner, retest nslookup, the user portal and the original resource only after that owner confirms a correction under their procedure.

Scope in relation to other guides

This runbook covers only the Protected Browser symptoms described here. Setting up Protected Browser or the extension, and general DNS and ZTNA configuration, belong in the relevant setup guides. Where such configuration is required, hand the case over to the responsible administrator.