Deploy Sophos Connect with an Entra ID provisioning file

What you are actually deploying#

People ask for "the Sophos Connect config" as if it were one file. It is two steps, and mixing them up is how you end up emailing a user certificate around the company.

The provisioning file is a small JSON document with a .pro extension. It does not contain the tunnel, the split routes, or anyone's certificate. It tells Sophos Connect which firewall to talk to. The client signs in to the VPN portal, with a username or with Microsoft Entra ID, and the portal returns the real configuration: a .scx for IPsec remote access, and a .ovpn for SSL VPN if that user is on an SSL VPN policy. Later changes to those policies come back down the same path, as long as the gateway and the portal port in the .pro have not changed.

The installer is separate. On Windows it is an MSI, named in the admin console along the lines of SophosConnect_x.x_(IPsec_and_SSLVPN).msi. On Mac it is a pkg. Both come from the firewall: Remote access VPN, then IPsec or SSL VPN, then Download client. You can also take them from the VPN portal. Use the copy your own firewall is serving once it has the client you mean to deploy. An old pkg from a laptop in a drawer is how you ship a build that cannot read a .pro.

Sophos documents the templates and what the client does with them in Provisioning file templates (updated 14 October 2026) and Automatic provisioning, configuration files, and clients (updated 2 October 2026). The GPO import article is the Windows automatic import. Copy the .pro into the folder it names and the client takes it. That article does not give you a Mac folder.

The Entra ID profile#

Entra ID SSO does not need a special secret inside the .pro. The app registration, the client secret, and the redirect URIs live on the firewall, under Authentication > Servers, and you assign that server under Authentication > Services. The file only has to point at the right portal.

Two rules, both from Sophos, and both easy to miss:

• With a provisioning file, the VPN portal, IPsec VPN, and SSL VPN authentication methods must use the same Microsoft Entra ID server. Without a provisioning file, IPsec is allowed to differ. With one, it is not. See Requirements and restrictions.
• gateway must be the host in that server's Redirect URI. The host. Not https://, not the port, not the path. If the firewall shows vpn.example.com in the redirect URI, that string is the gateway. Add the VPN portal and remote access URL to the Entra app registration as a web redirect, or the browser comes back from Microsoft and the firewall never hears it.

On Windows, Entra ID SSO in Sophos Connect needs client 2.4, released 2 June 2025, talking to SFOS 21.5 or later. The Mac client that can do the same job is 2.1, released 6 October 2026. Those numbers belong to different release trains. A Windows 2.1 installer will not do what the Mac 2.1 release notes describe.

There is a third rule that the template page does not shout about. display_name is capped at 60 characters. If you leave it out, the client uses the gateway as the name. A long FQDN then fails the import. Sophos staff called this out on the community thread about Entra SSO provisioning files. Put a short name in. Always.

For a pure Entra sign-in, leave otp false. The second factor happens in Entra, in the browser. Sophos' own two-factor templates are a different file: otp true, and 2fa set to 1 for a one-time password from the firewall or 2 for something external such as Duo. can_save_credentials does not apply to SSO. I still set it false, so the client is not offering a password box this design does not use.

Replace every angle-bracket value. Do not put a tenant ID, a client secret, or a user's password in this file. There is nowhere for them, and they do not belong in a file you are about to copy onto every laptop.

[
    {
        "display_name": "<Short name, 60 characters or fewer>",
        "gateway": "<Host from the firewall Redirect URI>",
        "vpn_portal_port": 443,
        "otp": false,
        "can_save_credentials": false,
        "check_remote_availability": false,
        "run_logon_script": false
    }
]

vpn_portal_port is the VPN portal port. 443 is the default. If you moved the portal, change this number. Sophos' pasted template shows the port as a placeholder string. Replace it with a number, the same way their own multi-gateway example uses 9443. The older key user_portal_port still works, and it now means the VPN portal port. Write vpn_portal_port in a new file. On the Windows client that key arrived in 2.3, on 15 May 2024. The Mac client that reads a .pro is the separate 2.1 release from 6 October 2026.

Save it as CompanyVPN.pro, or whatever name you like. The extension is the part that matters. A file called CompanyVPN.pro.txt is still a text file, and the client will ignore it.

Before this file is worth deploying, the portal has to be reachable from the networks your users actually sit on. For home workers that means WAN, under Administration > Device access, local service ACL, for the VPN portal. Sophos is blunt about what that does: a WAN-facing portal can be brute-forced. Turn on the failed-login controls, use a certificate the laptops trust, and do not treat "the portal is open" as a finished design.

On a shared PC, sign the previous person out of Entra before the next person connects. The last browser session is not a handover.

Intune: the client, then the file#

Do this as two Win32 apps. One is the MSI. One is the .pro. If you glue them into a single package, every profile change reinstalls the client, and the other way round is worse: the profile app runs before scvpn exists and the file sits there until someone notices.

Package each with the Win32 Content Prep Tool, the same way as any other Win32 app. I have written up the packaging mechanics in Package an EXE as an .intunewin and deploy it silently with Intune. The Sophos-specific parts are below.

The MSI#

Source folder: the MSI on its own.

Install command, system context, no user interaction:

msiexec /i "SophosConnect.msi" /qn /norestart

Rename the file to match whatever you downloaded, or rename the download to that. Uninstall is msiexec /x "{PRODUCT-CODE}" /qn. Take the product code from the MSI properties on a machine where you have installed it once. I am not going to invent one.

Detection should prove the product is there, not that a script exited 0. After a pilot install, point the rule at the file that actually appeared under C:\Program Files (x86)\Sophos\Connect\, or at the MSI product code. The service you care about later is named scvpn. Sophos' own startup script waits for that service. Do not disable Sophos Connect in the startup apps, or the wait never ends.

Assign it to a pilot group. Confirm the install is silent. Then do the profile.

The provisioning file#

The client watches one folder, and Sophos documents it:

C:\Program Files (x86)\Sophos\Connect\import\

A .pro copied there is imported, then deleted. Deletion means the client took the file. It does not mean the user is signed in, and it does not mean the tunnel works. Intune detection that looks for the .pro still being in that folder will report failure on a good install. Detection that looks for it and treats "missing" as success will also go green if you never copied it. The script below waits until the file disappears, and only then returns success. Use that as the install command of a second Win32 app, with the MSI app as a dependency, installed in system context.

Put CompanyVPN.pro and this script in the same source folder. Wrap the script as the setup file, or call it from a one-line cmd.

# Import-SophosConnectProvisioning.ps1
# System context, after the Sophos Connect MSI.
# Edit $SourcePro if the .pro is not beside this script.

$ErrorActionPreference = 'Stop'

$SourcePro  = Join-Path $PSScriptRoot 'CompanyVPN.pro'
$ImportDir  = 'C:\Program Files (x86)\Sophos\Connect\import'
$Destination = Join-Path $ImportDir 'CompanyVPN.pro'
$ServiceName = 'scvpn'

if (-not (Test-Path -LiteralPath $SourcePro)) {
    throw "Provisioning file not found: $SourcePro"
}

$deadline = (Get-Date).AddMinutes(10)
do {
    $svc = Get-Service -Name $ServiceName -ErrorAction SilentlyContinue
    if ($svc -and $svc.Status -eq 'Running') { break }
    if ((Get-Date) -gt $deadline) {
        throw "Service '$ServiceName' did not start. Is the Sophos Connect MSI installed?"
    }
    Start-Sleep -Seconds 5
} while ($true)

New-Item -ItemType Directory -Path $ImportDir -Force | Out-Null
Copy-Item -LiteralPath $SourcePro -Destination $Destination -Force

# Consumed and deleted by the client. Still present means it was not imported.
$deadline = (Get-Date).AddMinutes(5)
do {
    if (-not (Test-Path -LiteralPath $Destination)) { exit 0 }
    if ((Get-Date) -gt $deadline) {
        throw "File is still in the import folder. Sophos Connect did not take it."
    }
    Start-Sleep -Seconds 5
} while ($true)

When you change the profile later, you need the client to import again. Bumping a version file, or shipping a new Win32 app version of this package, is enough, as long as the script copies the new .pro in. The old connection in the client is replaced by the import. If gateway or the portal port changed, users who already imported an older file do not magically follow. They need this copy.

What the user should see, once they open Sophos Connect, is a connection with your display_name. Connecting starts Entra in the browser. The .scx and .ovpn arrive after that sign-in, not before. If the connection is missing, the file never reached the import folder or the client was not running. If the connection is there and sign-in fails, stop looking at Intune. Check the redirect URI, the portal certificate, and that all three services use the same Entra server.

A file disappearing from import during imaging, before any user has logged on, is fine. The import is done by the service, not by the user clicking around.

Mac, Jamf, and the version you are actually allowed to use#

Sophos Connect 2.1 for macOS was announced on 6 October 2026. That is the build that understands a .pro, speaks Entra ID SSO for IPsec, SSL VPN, and provisioning, and runs natively on Apple Silicon. The release notes put it on macOS 14 Sonoma and newer, Intel and Apple Silicon. Ventura stays on 2.0 MR1, and 2.0 cannot import a provisioning file.

Read the support table before you celebrate a "universal" pkg. Provisioning is supported on Intel, and on Apple Silicon when the client is the native 2.1 build. The Rosetta row is a no. An Apple Silicon Mac running an older client under Rosetta will take a .scx and will not take a .pro.

The release notes allow the system browser for SSO when the firewall is on SFOS 22.0 MR3 or later. The template page names the three choices. The Mac client that can use them shipped on 6 October 2026. The firewall release this provisioning story is lined up with is SFOS 23. That is in an external early access programme, with general availability expected in November 2026. The 2.1 announcement is the public write-up of the client. The release notes are the support matrix. I would not point a production Mac fleet at an EAP firewall. If the EAP notes for your build disagree with the public 21.5 page, follow the EAP notes for that build.

The public help documents one watched folder, and it is the Windows path above. The Mac method in the same article is to share the .pro and open it. Sophos Connect 2.1 registers .pro, .scx, .tgb, and .ovpn, so a double-click imports the file. /Library/Application Support/Sophos/Connect/import is a guess, and a guess is a bad thing to push to a fleet. If an SFOS 23 EAP guide later names a Mac watch folder, use that and drop the open step. Until it does, Jamf installs the client and then opens the file.

The pkg#

Scope a Jamf policy, or a Mac App, to Macs on macOS 14 or newer. Upload the pkg the firewall is actually offering once pattern updates have delivered 2.1. The older admin-console label still talks about a macOS pkg that is IPsec-only. That description is stale for 2.1, which the release notes list for SSL VPN as well. Check About on a pilot Mac and look for 2.1 or newer before you trust the filename.

The pkg will want a network extension for the tunnel. Jamf can pre-approve a system extension, but the team ID and the bundle ID come from the pkg you downloaded, not from a blog post. On the pilot Mac:

codesign -dv --verbose=4 "/Applications/Sophos Connect.app" 2>&1 | grep -E 'Authority|TeamIdentifier'
systemextensionsctl list

Put that team ID into a Jamf configuration profile that allows the extension. Do not copy an identifier from somewhere else and hope.

The .pro, on a Mac#

Ship the same JSON as Windows, plus the one key the template page says applies only to macOS on Sophos Connect 2.1 and later. sso_auth_browser_type is auto, embedded, or system. auto is the default, and it is also what the client uses if the key is missing or nonsense. embedded is the in-app browser. system is the Mac's default browser, and it needs SFOS 22.0 MR3 or later. On the SFOS 23 EAP, confirm that key against the build you are actually on before you depend on anything other than auto.

[
    {
        "display_name": "<Short name, 60 characters or fewer>",
        "gateway": "<Host from the firewall Redirect URI>",
        "vpn_portal_port": 443,
        "otp": false,
        "can_save_credentials": false,
        "check_remote_availability": false,
        "run_logon_script": false,
        "sso_auth_browser_type": "auto"
    }
]

run_logon_script is a Windows behaviour. Leaving it false on a Mac file is harmless.

Jamf cannot drop that file in a Sophos folder that the docs do not define and expect the menu bar icon to grow a connection. Put the file somewhere you own, readable by users, and open it as the person sitting at the Mac so the file association runs in their session:

/Library/Application Support/YOURORG/Sophos Connect/ShortName.pro

That path is yours. Replace YOURORG and ShortName. A signed pkg, or a Jamf policy script, can lay the file down. A second script, after the Sophos pkg, opens it. Run that second script only when someone is logged in. open as root does not import the connection into the user's client.

#!/bin/bash
# Jamf: run after Sophos Connect 2.1 is installed.
# Replace YOURORG and ShortName. This folder is one you create.
# It is not a Sophos watch folder.

PRO="/Library/Application Support/YOURORG/Sophos Connect/ShortName.pro"
USER_NAME="$(stat -f %Su /dev/console)"

if [[ ! -f "$PRO" ]]; then
  echo "Provisioning file missing: $PRO"
  exit 1
fi

if [[ -z "$USER_NAME" || "$USER_NAME" == "root" || "$USER_NAME" == "loginwindow" ]]; then
  echo "No console user. File is in place. Open it at the next graphical login."
  exit 0
fi

sudo -u "$USER_NAME" open "$PRO"

If the policy often runs at check-in with nobody logged in, the script above leaves the file in place and exits 0. Pair it with a LaunchAgent so the open happens in the graphical session. This is the layout I would use. The Sophos app is the vendor's. The YOURORG folder and the LaunchAgent are yours.

/Applications/Sophos Connect.app
/Library/Application Support/YOURORG/Sophos Connect/ShortName.pro
/Library/Application Support/YOURORG/Sophos Connect/open-provisioning.sh
/Library/LaunchAgents/com.YOURORG.sophosconnect.provision.plist

The agent has to run as the user, in the Aqua session, or you are back to open as root. Put a small script next to the .pro. A stamp in the user's home stops it importing on every login. When you ship a changed .pro, change the stamp name, or delete the old stamp, or the agent will decide it has already done the job. Replace YOURORG and ShortName. I have left them as plain tokens so the plist stays valid XML. Angle brackets in a plist string are how you corrupt a configuration profile.

#!/bin/bash
# /Library/Application Support/YOURORG/Sophos Connect/open-provisioning.sh
# LaunchAgent, user context. Not root.

PRO="/Library/Application Support/YOURORG/Sophos Connect/ShortName.pro"
STAMP="$HOME/Library/Application Support/YOURORG/Sophos Connect/imported"

if [[ ! -f "$PRO" ]]; then
  echo "Provisioning file missing: $PRO"
  exit 1
fi

mkdir -p "$(dirname "$STAMP")"
if [[ -f "$STAMP" ]]; then
  exit 0
fi

open "$PRO" && touch "$STAMP"

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
  <key>Label</key>
  <string>com.YOURORG.sophosconnect.provision</string>
  <key>ProgramArguments</key>
  <array>
    <string>/bin/bash</string>
    <string>/Library/Application Support/YOURORG/Sophos Connect/open-provisioning.sh</string>
  </array>
  <key>RunAtLoad</key>
  <true/>
  <key>LimitLoadToSessionType</key>
  <string>Aqua</string>
</dict>
</plist>

Save the plist as /Library/LaunchAgents/com.YOURORG.sophosconnect.provision.plist. Jamf can deploy the script and the plist in a package, or as a policy that writes both files. chmod 755 the script. launchctl bootstrap gui/$(id -u) on that plist is the manual check on a pilot, run as the logged-in user. You want the connection name in the Sophos Connect window, then an Entra prompt, then the tunnel. A script that exits 0 and a window that is still empty is not a successful deploy.

Apple Silicon Macs on the native 2.1 client, Intel Macs on 2.1, and nothing older if the thing you are handing out is a .pro.

What I would check on one machine before the pilot group#

1. The firewall services for the VPN portal, IPsec, and SSL VPN all point at the same Entra ID server.
2. The Entra app has the VPN portal and remote access URL as a web redirect.
3. gateway in the file is that host, and display_name is short.
4. The portal certificate is trusted from a network that is not the office.
5. Windows: the MSI is in, scvpn is running, the .pro lands in import and then vanishes, and the connection name is there before anyone types a password.
6. Mac: About says 2.1 or newer, the pkg's extension is allowed, open was done as the console user, and the same connection name appears.
7. Sign-in. Entra completes. The .scx shows up. The .ovpn shows up only for a user who is actually on an SSL VPN policy. An IPsec profile appearing for everyone is normal. An SSL profile appearing for everyone is not.
8. A user who should not have VPN can see a connection and still cannot pass authentication. Import and permission are different tests.

A .ovpn that someone downloaded by hand contains that user's certificate and key. Do not wrap that in Intune or Jamf and send it to a department. The .pro is the file that is safe to share. The certificate comes down after the person signs in.

References#

• Sophos, Provisioning file templates
• Sophos, Automatic provisioning, configuration files, and clients
• Sophos, Import VPN provisioning file through GPO, including the scvpn service and the Windows import folder
• Sophos, Microsoft Entra ID requirements and restrictions
• Sophos, Add redirect URIs to Microsoft Entra ID
• Sophos Connect release notes, including macOS 2.1 on 6 October 2026
• Sophos community, Sophos Connect 2.1 (macOS) now available
• Sophos community, Entra ID SSO and the provisioning file, including the display name limit
• Microsoft Learn, Win32 app management in Intune