Enforce Sophos Protected Browser for SaaS applications

Access to critical SaaS applications can be restricted so that it works only through Sophos Protected Browser. Entra ID or Okta authenticates the requests and, for the selected applications, permits only traffic from the ZTNA data plane IP addresses copied from Sophos Central. This blocks access from another browser.

The safe workflow consists of four parts: prepare the identity provider and applications, enable browser enforcement in Sophos Central, register the copied ZTNA IP addresses with the identity provider as a trusted location, and initially enable the access policy within a limited scope. With Entra ID, a small pilot group limits the user population. The documented Okta workflow, however, has no equivalent group selector: use a dedicated pilot application or explicitly check in advance which users are assigned to the selected application. Choose Entra ID or Okta; do not run both workflows in parallel for the same pilot application.

Sophos refers to this task in the navigation as Globale Einstellungen > Protected Browser erzwingen. In the interface described, the exact click path is Globale Einstellungen > Produkte und Services > Protected Browser > Browserdurchsetzung. The official Entra ID instructions also provide a video for this workflow; however, you can complete all the following steps without it.

Requirements, licensing and responsibilities

Before making the change, clarify who administers Sophos Central and who administers the identity provider. The released sources do not mention a separate Sophos license or specific Sophos Central role for this process. Don’t invent permission from this: the responsible account must be able to open the Globale Einstellungen > Produkte und Services > Protected Browser > Browserdurchsetzung area and change the settings. If the menu item or change option is missing, this is a permissions or product access issue that needs to be resolved before rollout.

These documented requirements apply to Entra ID:

Microsoft Entra ID P1 license.
Entra ID is added as a federated identity provider in Sophos Central.
The applications to be protected are added in Entra ID.
SAML is configured for user authentication in Entra ID.
The account that sets up browser enforcement in Entra ID is an administrator.

These requirements apply to Okta:

Okta is added as a federated identity provider in Sophos Central.
The applications to be protected are added in Okta.
SAML is configured for user authentication in Okta.
The account that sets up browser enforcement in Okta is an administrator.

Both variants also require a selectable Bereich der Datenebene. This guide assumes that the ZTNA region already exists; it does not cover its creation or general ZTNA, directory or role management.

Record before starting the pilot: the selected identity provider, ZTNA region, copied IP list and pilot application. For Entra ID, also record the test users or test group. For Okta, document the users assigned to the pilot application instead. Third-party menus can change independently of Sophos. Before enabling the configuration in production, compare the Entra ID or Okta paths in this guide with the provider’s current documentation.

Configure Entra ID for browser enforcement

Entra ID authenticates requests to login.microsoftonline.com and routes permitted traffic through the selected ZTNA range. For the first test, only use a pilot application and a small test group. This means that a faulty condition remains limited.

Activate Entra ID in Protected Browser

Open Globale Einstellungen > Produkte und Services > Protected Browser.
Click on Browserdurchsetzung.
Activate Entra ID.
Under Bereich der Datenebene, select the ZTNA range to use for authentication.
Click on IP-Liste kopieren. These IP addresses will be stored as a named location in the next step.

Important for an extension installed later: If the Protected Browser extension is only installed after browser enforcement with Entra ID, you must deactivate Entra ID in this setting and then reactivate it.

Create a named location in Entra ID

In Entra ID, open Enterprise-Anwendungen > Bedingter Zugriff.
Select Benannte Standorte and click IP-Bereichsstandort.
Give it a unique name, for example Sophos-PB-ZTNA-Pilot. The name can be freely chosen; it should identify the associated ZTNA area and purpose.
Click on the plus symbol and insert the IP addresses previously taken over with IP-Liste kopieren.
Click on Erstellen.

Check the inserted values against the noted IP list. An old or incomplete list would block legitimate Protected Browser traffic or exclude an incorrect location.

Create conditional policy

Stay under Enterprise-Anwendungen > Bedingter Zugriff, select Richtlinien and click Neue Richtlinie.
Give it a name, for example SaaS nur via Protected Browser - Pilot.
Open Benutzer > Einbeziehen > Benutzer und Gruppen auswählen, click on Benutzer und Gruppen and select only the pilot user or pilot group.
Open Zielressourcen > Einbeziehen, click on Ressourcen auswählen and first select only the pilot application.
Open Netzwerk and set Konfigurieren to Ja.
Under Einbeziehen, select Jedes Netzwerk oder jeder Standort.
Under Ausschliessen, select Ausgewählte Netzwerke und Standorte and then select the named location you created previously.
Open Gewähren, select Zugriff blockieren and click Auswählen. This blocks all included access outside the named ZTNA location.
Set Richtlinie aktivieren to Ein and click Erstellen.

Before the final step, double-check the combination of test users, pilot application, and exempt ZTNA location. Too wide a selection can immediately block direct SaaS access for many users.

Configure Okta for browser enforcement

For Okta, in Sophos Central you specify the domain that receives the application access requests. Okta authenticates these requests and passes permitted traffic through the selected ZTNA range. Unlike the described Entra-ID flow, the Okta policy here is not limited to a pilot group. Therefore, prepare a dedicated pilot application. If an application that is already in productive use should be selected instead, explicitly review and document its application assignments before making the change.

Activate Okta in Protected Browser

Open Globale Einstellungen > Produkte und Services > Protected Browser.
Click on Browserdurchsetzung.
Activate Okta and enter the domain that receives application access requests.
Select the designated ZTNA area under Bereich der Datenebene.
Click on IP-Liste kopieren. These addresses are used as the Okta IP zone.

Important for an extension installed later: If the Protected Browser extension is only installed after browser enforcement with Okta, you must deactivate Okta and then activate it again.

Add an IP zone in Okta

Open Okta Sicherheit > Netzwerke.
Click on Zone hinzufügen and select IP-Zone.
Give it a name, for example Sophos-PB-ZTNA-Pilot.
Under Gateway-IPs, paste the IP addresses of the ZTNA range copied from Sophos Central.
Click on Speichern.

Create a Conditional Access policy in Okta

Check impact before editing: The Catch-all rule applies to all users assigned to the selected application. Setting it to Verweigert for a production application can block its access outside the allowed ZTNA IP zone for all assigned users. Proceed only with a dedicated pilot application or with a pre-vetted and documented application assignment.

Open Sicherheit > Authentifizierungsrichtlinien and click App-Anmeldung.
Click on Richtlinie erstellen, give it the name SaaS nur via Protected Browser - Pilot, for example, and click on Richtlinie erstellen again.
Click Bearbeiten under Regeln next to the Catch-all-Regel under Aktionen.
Set Dann ist der Zugriff auf to Verweigert and click Speichern.
Click on Regel hinzufügen and give it a unique name.
Set Die IP des Benutzers ist to In einer der folgenden Zonen and select the IP zone created previously.
Set Dann ist der Zugriff auf to Erlaubt nach erfolgreicher Authentifizierung and click Speichern.
Under Anwendungen, select only the dedicated pilot application or the application with the previously checked assignment and click Speichern.

The order is security-related: The Catch-all rule denies access to the users assigned to the application; the additional rule only allows it from the zone with the copied ZTNA IP addresses and after successful authentication.

Check effect with a limited pilot

The published sources do not identify a report that confirms success. Test the actual access behaviour with the exact user and application included in the pilot:

Sign the test user out of the pilot application completely so that an old session cannot distort the result. For Entra ID, the user must belong to the pilot group; for Okta, the user must be assigned to the dedicated or previously reviewed pilot application.
Open the pilot application in Protected Browser and authenticate the test user. Access must be possible after successful authentication.
Open the same application as the same test user in a different browser. This access must be blocked.
Check the scope in a provider-appropriate way: with Entra ID, the behaviour of a user outside the pilot group must not change unintentionally. With Okta, the behaviour of another application that is not linked to this authentication policy must not change. Also confirm that the documented application assignments still match the intended pilot population.
Document the selected ZTNA range and compare the IP list stored with the identity provider again with IP-Liste kopieren.

The authentication token is managed by the identity provider. Conditional Access session controls configured there take precedence. A sign-in frequency of two days configured there therefore ends the session after two days. According to Sophos, if no session control is configured at the identity provider, Protected Browser uses a default session expiry time of seven days. An existing token can therefore make a test behave differently from a fresh sign-in.

Troubleshoot by symptom

Another browser still gets access

First, check that the tested user and the correct SaaS application are covered by the policy. Then compare the IP zone or named location at the identity provider with the current IP list copied from Sophos Central. Entra ID must include Jedes Netzwerk oder jeder Standort, exclude the named ZTNA location, and select Zugriff blockieren for all other access. For Okta, the Catch-all rule must deny access and the allow rule must be limited to the IP zone you created.

End existing application sessions and test with a fresh sign-in. If access remains possible, stop expanding the pilot and check the current policy evaluation at the identity provider. The sources provide no evidence of an additional Sophos setting that should be used to bypass an incorrect third-party rule.

The Protected Browser is also blocked

Compare the IP addresses from IP-Liste kopieren character by character with the named location or the Gateway-IPs. Also check whether the same Bereich der Datenebene is selected in Sophos Central, whose addresses were stored with the identity provider. Then check SAML, the selected application and the test user based on the requirements.

If the Protected Browser extension was installed later, deactivate the configured provider in Sophos Central and then reactivate it. This is explicitly required for Entra ID and Okta. Do not change the ZTNA region, IP list and access policy at the same time; otherwise, you will not be able to isolate the cause reliably.

Sessions end sooner or later than expected

Check session controls and login frequency in the identity provider. These values take precedence over the session behavior of the Protected Browser. The documented standard expiry time of seven days only applies if no session control is set there.

Third party menus or field names differ

Entra ID and Okta are third-party products. Do not save a similar rule for a menu or control panel that cannot be clearly assigned. Compare the process with the current documentation of the respective provider or escalate to their administration or support. The safest interim measure is not to expand the productive rollout beyond the already successfully tested pilot scope: for Entra ID the pilot group, for Okta the dedicated or pre-tested application assignment.

Safe rollback and offboarding

The published sources do not document a complete deletion, offboarding or rollback procedure. Do not delete the location, IP zone or SAML connection first: doing so could leave the blocking rule active without the required exception.

Use this safety framework for every rollback:

Stop any expansion and record the pilot user, pilot application, identity provider, ZTNA region and IP list. Also record the pilot group for Entra ID and the current application assignments for Okta.
Use the current Entra ID or Okta documentation to identify the supported method for taking the specific access policy out of force in a controlled manner.
Deactivate only the pilot policy, using the confirmed method. Sign the pilot user out of the application completely and authenticate them again. The expected result is that the pilot application is accessible again in both Protected Browser and another browser, unless another access policy prevents it. With Entra ID, access for a user outside the pilot group must remain unchanged; with Okta, an application not linked to the pilot policy must remain unchanged.
Compare the actual result with these expectations. If any result differs, stop the rollback and do not delete any further policies, locations, IP zones or application assignments. Instead, check the current policy evaluation and escalate to the responsible administrator or the provider’s support team.
Remove the named location or IP zone only after the expected result has been achieved and no active policy refers to it.
Disable browser enforcement in Sophos Central or remove Federated Identity, SAML or ZTNA components only within the scope of their own approved operating instructions.

If you cannot clearly confirm the identity provider’s supported deactivation method, stop and escalate. Guessing which setting to use is not a safe rollback method for a policy that blocks SaaS access.

Operations and lifecycle

Treat browser enforcement as a joint change of Sophos Central, ZTNA data plane and identity provider. After changing the ZTNA range or its IP addresses, the list stored with the identity provider must be compared again and tested with a limited user. The same applies after changes to SAML, the protected applications, user or group associations and session controls.

Also include this control in the regular review of the Entra ID or Okta policies. The owner, selected applications, included user population, referenced location and documented IP list should continue to match. When installing the Protected Browser extension, treat the reactivation of the relevant identity provider described above as a separate change step, followed by a positive and a negative test.

The sources do not provide any blanket term, migration date, or end-of-life behavior for this configuration. Such decisions must therefore be made based on current product and manufacturer documentation, not historical assumptions.

Policy objects, general ZTNA setup, role management, directory synchronisation, and installation or removal of the Protected Browser extension are separate operational tasks. This guide deliberately does not duplicate those procedures. Use the relevant canonical article as soon as it is available in the current language version of the knowledge base.