Sophos Connect: Why admins should not have to chase blog posts

Sophos Connect 2.5 MR1 for Windows is available. At first glance it looks like a small maintenance release: a few client fixes, an updated third-party component, and downloads through the firewall or directly from Sophos.

But that is exactly where my problem starts.

Sophos Connect is not a nice little helper for occasional test VPNs. The client runs on Windows endpoints, establishes remote-access VPNs, and for many organizations is a direct path into the internal network. When a security tool like that updates an important cryptographic library, the information should not feel hidden in a community blog post.

What bothers me even more: OpenSSL 3.3.7 was released on April 7, 2026. Sophos Connect 2.5 MR1 arrived on June 18, 2026. That is roughly ten weeks. For a normal desktop app, that might simply be a late maintenance update. For a VPN client with a cryptographic library, that delay feels much less comfortable.

Should individual users really read Sophos blogs to notice that their VPN client should be updated? Should every small IT admin subscribe to the community feed and hope they catch releases like this in time? For a tool that deals directly with remote access, certificates, authentication, and encryption, that is not enough.

What Sophos Connect 2.5 MR1 changes

Sophos announced Sophos Connect Client 2.5 MR1 for Windows on June 18, 2026. According to Sophos, it is a maintenance release that fixes several community-reported issues.

The most important technical change is clearly stated:

• OpenSSL was updated to version 3.3.7.

That sounds small. Operationally, it is not. More than two months passed between the OpenSSL release on April 7 and the Sophos Connect version on June 18. One can fairly argue that Sophos has to review, integrate, test, and package the library. But that is exactly why a security client needs better transparency: admins should not have to infer from a blog post that a client component has been waiting for a security patch release for weeks.

Sophos also lists several fixed Sophos Connect issues:

• The client did not auto-start for additional Windows users when installed by another user.
• SSO users could see an incorrect VPN status after an internet interruption.
• Credential users with OTP were prompted differently during reconnect depending on whether IPsec or SSL VPN was used.
• SSO users could not establish an SSL VPN connection from a provisioning file when certificates contained special characters.

These are not cosmetic details. They are typical remote-access problems: startup behavior, status display, SSO, OTP, provisioning, and certificates. Exactly the areas where help desks, admins, and users quickly lose visibility when something is not clean.

Still, OpenSSL 3.3.7 is the part that makes this release especially important to me.

Why OpenSSL 3.3.7 matters

OpenSSL 3.3.7 was published on April 7, 2026 as a security patch release. OpenSSL itself rates the most severe fixed issue as Moderate. That does not sound dramatic, but it is not a normal bugfix update either.

OpenSSL 3.3.7 fixes, among other things:

• CVE-2026-31790: incorrect error handling in RSA KEM RSASVE Encapsulation, which could under certain conditions send uninitialized memory contents to a malicious peer.
• CVE-2026-28387: a potential use-after-free issue in DANE client code.
• CVE-2026-28388: a possible NULL pointer dereference while processing a delta CRL.
• CVE-2026-28389 and CVE-2026-28390: possible NULL dereferences while processing certain CMS EnvelopedData structures.
• CVE-2026-31789: a heap buffer overflow during hexadecimal conversion on 32-bit platforms.

Not every one of these vulnerabilities is automatically exploitable in Sophos Connect. That matters. One should not blindly infer from an OpenSSL CVE list that every client in every scenario is acutely compromisable.

But the opposite would be just as wrong: “Moderate” or “Low” does not mean “irrelevant.”

OpenSSL is a base component. It is involved in TLS, certificate validation, cryptographic operations, and many programs that establish secure connections. If a VPN client ships that library, maintaining it is part of the client’s security model. That is especially true for notebooks that travel, operate on foreign networks, and connect back into internal environments.

Why SSL VPN still matters here

Another thing has bothered me about Sophos Connect for a while: the client ships OpenSSL for SSL VPN whether a customer actually uses SSL VPN or not.

Many environments now rely more heavily on IPsec. There are good reasons for that: often better performance, clearer integration into existing VPN designs, and above all easier distribution through software deployment, RMM, Intune, or other endpoint-management tools. In companies, you do not want users manually pulling VPN installers from a portal. You want a package, a version, a rollout window, and clean inventory.

If a customer uses Sophos Connect only for IPsec, OpenSSL for SSL VPN is still part of the installed client. That does not automatically mean every OpenSSL vulnerability is practically exploitable in that environment. But it does mean the library is present, must be maintained, appears in inventory and vulnerability scans, and creates patch work.

That is why update logic matters so much. If a product installs components that not every customer actively uses, the vendor has a special responsibility to maintain those components quickly and visibly. Otherwise you get the classic enterprise problem: a feature is technically present, not used operationally, but still needs to be patched and explained.

Why a dedicated release makes sense

I think it is right that Sophos ships a maintenance release for this.

A VPN client is not just another desktop app. It is part of access control. If that client uses outdated crypto libraries, there is operational risk, even when practical exploitability needs to be assessed case by case.

For security components, three things matter:

• Component maintenance: third-party libraries must be updated promptly.
• Traceability: admins must be able to see which version is deployed.
• Distribution: the patch must reliably reach endpoints.

The first point is fulfilled here: Sophos updates OpenSSL. The second is at least partly fulfilled: the release notes and blog post name the version. The third point is where it gets interesting.

Sophos says the current client installer is distributed to SFOS firewalls via an Up2Date package and can then be downloaded from WebAdmin or the VPN portal. That is useful because the firewall becomes a local source for the installer.

But that is not the same as a clean, visible auto-update process on every Windows endpoint.

If a user installed the client at some point and never actively updates it again, firewall-side installer availability is only half the journey. Someone still has to trigger, monitor, and finish the rollout.

The real criticism: visibility

My criticism is not primarily aimed at the release itself. The release is sensible.

My criticism is about visibility and expectations.

A modern security tool should, in my view, offer at least one of these options:

• a clear update notification in the client,
• a central view in Sophos Central or on the firewall showing outdated client versions,
• an official and well-documented auto-update mechanism,
• or at least an admin warning when a security-relevant client build is outdated.

What I would like most for Sophos Connect is an optional, controllable auto-update mechanism. Not silently, not uncontrolled, and not against company policy. But in a way that lets an admin decide that security-relevant client updates may be rolled out automatically or semi-automatically to defined groups. Small teams would have fewer blind spots, and larger teams could integrate it into their change process.

Of course some environments already solve this through GPO, RMM, Intune, or software deployment. Good admins can handle it. But that does not change the product point: for remote-access clients, update communication should not be left to chance.

Sophos knows how important update automation is. Firewalls have pattern updates, hotfixes, firmware notices, and Central visibility. Endpoint products are expected to update automatically anyway. Why does the VPN client still feel so manual in places?

That is not a luxury problem. It is exactly the kind of place where small gaps remain for a long time.

What admins should do now

For admins, the practical consequence is fairly clear.

First: check whether your Sophos Firewall has already received the new Sophos Connect installer. Sophos says the installer is delivered to SFOS firewalls via Up2Date packages and then made available in WebAdmin or the VPN portal.

Second: check the installed Sophos Connect versions on Windows clients. If you do not have a central inventory, that is the real pain point. You need at least an overview through RMM, Intune, GPO, endpoint management, or a script.

Third: do not test the new client only with a standard user. Test real scenarios:

• SSL VPN with username, password, and MFA
• IPsec with OTP, if used
• Microsoft Entra ID SSO
• provisioning files
• certificates with special characters in names or relevant fields
• reconnect after internet interruption
• multiple Windows users on the same device, if that occurs in your environment

If you use only IPsec, I would still not ignore the update. Check especially whether the client starts cleanly in daily use, whether profiles are distributed as expected, and whether your inventory detects the new version correctly. OpenSSL may not be the actively used VPN path in that case, but the library is still part of the installed client.

Fourth: roll out the update in a planned way. Not as panic, but not someday either. OpenSSL 3.3.7 is a security patch release. A VPN client with OpenSSL is not a candidate for “we will handle it when the next notebook is replaced.”

Fifth: communicate clearly. Users do not need to know what RSASVE, DANE, or CMS KeyAgreeRecipientInfo means. They need to know that the VPN client is being updated, that connections should be tested afterward, and where to report problems with SSO, OTP, or provisioning.

What Sophos should improve

I would like three things from Sophos Connect.

First: clear update information inside the client. If a security-relevant client version is available, the user or at least the local admin should see it. Even better would be a controllable auto-update path for environments that deliberately allow it.

Second: a central admin view. Sophos Central or the firewall should show which Sophos Connect versions are known in an environment and which are outdated. If the client is not centrally managed, Sophos should at least provide clear inventory and rollout recommendations.

Third: better release communication. A community blog post is fine as an announcement. But for security-relevant client components, “read the blog and download the installer” is not an operating model, especially when the underlying OpenSSL version has been available since April.

I do not want to talk Sophos down here. On the contrary: updating OpenSSL is positive. Naming the version in the release notes is positive. Distributing the installer through the firewall is practical.

But in 2026, a security vendor should do more for remote-access clients.

My conclusion

Sophos Connect 2.5 MR1 is not a glamorous release. That is exactly why it is interesting.

It shows what security operations really look like: not only major new features, but component maintenance, small client fixes, certificate details, SSO behavior, OTP reconnects, and the question of whether an update actually lands on every endpoint.

OpenSSL 3.3.7 is a security patch release. Sophos is right to integrate it into Sophos Connect. Admins are right not to ignore the update. But the time from April to June is long enough to ask about update speed and visibility.

The architecture point remains as well: Sophos Connect installs SSL VPN components with OpenSSL even when an environment mainly or exclusively uses IPsec. That may make technical sense because Sophos provides a combined client. Operationally, it creates extra responsibility. What is installed must also be updated reliably.

Sophos should therefore accept the uncomfortable question: Why does an admin need to actively follow a blog post to notice this kind of VPN client update?

For a security tool that protects access to the internal network, that is not enough.

Until next time,
Joe

FAQ