
There have been many certificate changes with ScreenConnect, leaving many MSPs frustrated and scrambling to deploy updates rapidly. Here at Automation Theory, we want to share some bits of backstory (which might be incomplete; please take it with a grain of salt) and advise on code signing for MSPs.
Code signing 101
Lots of MSPs have been diving into cryptographic rabbit holes lately, but a quick review of the big picture is probably in order. In the CIA triad, code signing is used for integrity verification. It demonstrates that a piece of code originated from a specific developer and has not been modified.
This is achieved via a certificate, where a hash of the software is taken, signed with the private key of the certificate, and embedded into the object along with the public key. In Windows, you can open the file properties for a signed file and view the digital signature. Whoever has the file can verify the signature of the hash, and if the hash matches, then the file is unmodified and presumably safe to execute.
The two-fold woes ConnectWise is facing
ConnectWise has two issues that aren’t described in the official channels, but the first one is especially little-known: pirated ScreenConnect instances.
An individual figured out how to circumvent the licensing mechanism of ScreenConnect, and began distributing this software in April of 2018. As we understand it, it modifies a library that handles the license verification, so it never contacts the ConnectWise licensing server. The information for this exists publicly on the Internet in a shady forum, with over 100 pages of conversation over the years. There are a number of servers in Shodan that look like ScreenConnect instances, but are very out of date and have branding removed, which might be using this license bypass.

Why does this impact MSPs, and what does it have to do with code signing? That’s where the second woe comes in.
ScreenConnect allowed for a number of customizations, and these worked by placing the data after the digital signature block. The base installer file was signed at the time of compilation by ConnectWise, and when an installer was generated on an MSP’s server, details like server URLs and config files were embedded into the installer. These additions weren’t part of the digital signature (since the ConnectWise private key isn’t on each on-premise ScreenConnect server), and this practice isn’t always an issue – it depends on what the non-signed embedded data does (and what the application is).
The customization data includes the ability to change images, window titles, and UI messages (like the pop-ups showing a tech is connected to a device). Likewise, as an RMM tool, ScreenConnect supports a number of automation features, including triggers. Essentially, you can configure a command to run when a session connects – and if you’re a bad actor, it’s simple to make that command your malware payload.

In essence, ScreenConnect was the perfect way to create a legitimate-looking Trojan horse (as detailed by GData) – you could create a fake UI launched by trusted code with a valid signature – and it would auto-deploy your malware for you.
This is the problem that ConnectWise is trying to solve, but they don’t want to create any bad PR.
So why does my MSP need to sign ScreenConnect binaries?
Since bad actors are abusing ScreenConnect (which is bad for both ConnectWise and MSPs), something needs to be done about it. The problem? The kill-switch is gone for any bad actors using a pirated instance of ScreenConnect (since the license can’t be pulled to shut down the server). The only way to fix the issue is to revoke the certificate (since that will impact all the old/historical instances that aren’t licensed).
ConnectWise is probably one-bitten-twice-shy about distributing signed executables to on-prem instances, especially since they are probably going to need a fair amount of time to fully rearchitect things. As a result, they are asking MSPs to sign their own ScreenConnect agents. This solves their issue of controlling abuse – if a bad actor with an unlicensed instance starts to abuse the software, it’s a simple matter of revoking an individual organization’s cert with the CA who issued it (instead of the mass chaos of updating every agent on millions of endpoints around the world).
Like it or not, this dynamic is likely to persist, so MSPs should prepare to configure code signing.
Code signing tips for MSPs
Here at Automation Theory, we renewed our code-signing certificate at the end of last year, and things had changed since our previous certificate was issued! Here are our tips for your ScreenConnect code signing journey.
In the past, code signing certificates were like SSL certificates – files with encoded public and private keys. Starting in June of 2023, new requirements put out by the CA/Browser Forum require code signing certificates to be stored on FIPS-compliant hardware security modules (HSMs). As a result, you can’t get plain certificate files anymore – and anywhere that you sign code must understand how to speak to an HSM.
There are three main options for MSPs: use a cloud HSM, provide your own HSM, or have the CA ship you an HSM.
Initially, we had considered providing our own HSM (since Yubikeys will work if you have a FIPS-compliant model). However, we were up against a deadline, and none of the hardware we had on hand was suitable. We ended up having our CA ship us an HSM, but ConnectWise has documentation for configuring an Azure Key Vault option.
Next, you’ll need to decide on the type of certificate: organizational validation (OV) or extended validation (EV). These days, both require an HSM – but the EV certs show the issuer in the UAC prompt, which is a nice touch for an MSP (if branding in the user experience is of interest). However, an OV certificate will get the job done.
Regardless, you’ll need to validate your identity as part of the certificate process. Many CAs pull information from Dun & Bradstreet, so it’s prudent to ensure your MSP’s profile is up-to-date (and have your DUNS number handy). There will be a phone validation, so it’s also advisable to make sure the number doesn’t go to a phone queue.
Any physical HSM will require a PIN for accessing the certificate – and without the PIN (which is different from the FIDO pin you might regularly use on a Yubikey) the token will be useless. Store this PIN in your password/documentation platform of choice – and make sure it’s secure!
Last but not least, make sure to track the certificate expiration just like you would for an SSL certificate—you don’t want to be in a scenario where there’s a critical patch to apply in a few years, but you can’t install it until you renew your signing cert!
