ConnectWise ScreenConnect Hardening Guide

A ConnectWise ScreenConnect server is a control plane for every machine that runs its access agent, so a single authentication flaw or stolen technician login turns it into a ransomware distribution system. ScreenConnect has four entries in the CISA Known Exploited Vulnerabilities catalogue, including CVE-2024-1709, an authentication bypass rated CVSS 10.0 that Mandiant saw mass exploited by multiple threat actors. This guide covers how identity and roles work in ScreenConnect, how to lock down administrators and technicians, how to treat the server's machine credentials and integrations, what to log, and a hardening baseline for on-premises servers, with notes on what changes for ScreenConnect Cloud. It is for MSP engineers, IT operations teams and security teams who run or oversee ScreenConnect. Broader governance of remote monitoring and management tools, including blocking unapproved ones, is covered in the RMM Tool Security Guide.

Key takeaways

Patch as an emergency change. ConnectWise rates its recent ScreenConnect bulletins Priority 1 (High), meaning install as an emergency change or within days; CVE-2024-1709 let an unauthenticated attacker create administrator accounts.
Do not expose the web interface to the whole internet if you can avoid it. The on-premises Web Server (default port 8040) and Relay (default port 8041) need different exposure, and egress can be limited to a few ConnectWise hosts.
Roles decide blast radius. Session group scoping, consent prompts and permissions such as TransferFiles limit what a stolen technician account can do; CVE-2026-84869's interim mitigation was clearing exactly that permission.
Audit events are your detection source. Alert on RanCommand, QueuedTool, SentFiles, RanFiles and new users, and on any request to SetupWizard.aspx once the server is configured.
A compromised server must be rebuilt, not just patched. Mandiant observed new privileged users, web shells and staged tools after CVE-2024-1709; rotate every credential the server held.

How identity and access work in ScreenConnect

ScreenConnect has two populations of identity. Hosts are technicians and administrators who sign in to the web portal and connect to machines. Guests are the endpoints: either a support client that runs for one session, or an access agent installed as a Windows service (ScreenConnect.ClientService.exe) that keeps a standing connection to the server. Every access agent trusts the server it was built for, so whoever controls the server, or holds a host account with access to an agent's session group, can run commands on that endpoint.

Host accounts come from one or more user sources, configured under Administration > Security > User Sources:

User source	Where credentials live	Strengths	Watch for
Internal (forms authentication)	ScreenConnect database (`Security.db` in App_Data on-premises)	Works with no directory; supports two-factor authentication	Separate password lifecycle; leavers not removed automatically
Windows authentication	Local or domain accounts on the server	Uses existing Windows credentials	A domain-joined server ties ScreenConnect risk to Active Directory
LDAP / Active Directory	Directory (Active Directory, OpenLDAP, OpenDJ)	Central joiner, mover, leaver control through groups	Bind account credential; group nesting grants access unexpectedly
External identity provider	Your IdP	Conditional access and phishing-resistant MFA at the IdP	Keep at least one break-glass internal administrator

Two-factor authentication: enable it for every internal account. ConnectWise advises an authenticator app or hardware key rather than email codes, because a compromised mailbox then yields both factors.
Brute force protection and timeouts: ScreenConnect locks accounts after repeated failed sign-ins (on Cloud the administrator account locks after eight failures in ten minutes) and supports a page idle timeout so idle technician sessions end.
IP login restrictions: sign-in can be limited to named IP addresses or ranges per user or organisation. Use it for administrators at minimum.
Revoke user access: the Security page can force all signed-in users to disconnect from endpoints and log out. This is your first containment step when a host account is suspected.

Background on identity for remote access paths is in the Remote Access Identity Guide.

Admin roles and privileged access

ScreenConnect uses role-based security: a role is a set of permissions, applied either globally or to specific session groups (saved filters of machines, typically by customer, site or device type). A host's effective access is the union of the roles assigned to them through their user source. Two design rules matter most: very few people should hold global administration, and technicians should only see the session groups for the customers or estates they support.

Permission area	Why it is sensitive	Recommended scope
Administration (server settings, security, extensions)	Can add users, change user sources, install extensions and disable auditing	Two or three named administrators, IP restricted, phishing-resistant MFA
Running commands and tools in sessions	Equivalent to SYSTEM-level remote code execution on the endpoint	Technicians only, on their own session groups
File transfer (TransferFiles, formerly TransferFilesInSession)	Moves payloads onto endpoints; cleared as interim mitigation for CVE-2026-84869	Only roles that need it, never global
Joining without consent	Removes the end user's chance to refuse a connection	Unattended servers only; require consent on user devices
Building and installing access agents	Creates new persistent footholds	Deployment staff or automation only
Editing sessions, session groups or making sessions public	Can widen who sees a machine (audit event ModifiedIsPublic, ModifiedHost)	Administrators only

Separate administrative and daily accounts: technicians should not use their administrator role for routine sessions. The ConnectWise best practice guide also says not to use administrative Windows accounts on the server for browsing or email.
Consent and locking: enable the consent-to-connect prompt for attended devices, and lock on connect or disconnect so the guest machine is locked when a technician leaves.
Tier the server: Mandiant recommends that AD-integrated accounts which interact with ScreenConnect servers do not administer Tier 0 systems and that the same network and local logon denials applied to other remote access paths cover ScreenConnect too. Treat the ScreenConnect server itself as a Tier 0 adjacent asset because it can reach so many endpoints.
Review users regularly: every ConnectWise bulletin asks partners to remove unrecognised users, change passwords and enable MFA after patching. Make that a monthly review, not only a post-incident task.

For privileged session controls generally, see the Privileged Access Management Guide.

Integrations, API tokens and service accounts

A ScreenConnect server holds more machine credentials than most teams list in their inventory:

Server service identities: on-premises ScreenConnect runs four Windows services (Session Manager, Security Manager, Web Server and Relay). Run them with the least privilege the installer supports, and treat the server's local administrator accounts as privileged credentials that must be unique and vaulted. Mandiant's remediation guidance includes resetting local administrator passwords, especially where they are shared with other systems.
ASP.NET machine keys: the web application is ASP.NET. CVE-2025-3935 showed that an attacker with privileged system-level access could obtain the machine keys and forge ViewState for remote code execution; version 25.2.4 disabled ViewState. Machine keys are secrets: never copy them between servers or from documentation. The ASP.NET Machine Key Attacks 2025 show what happens when they are public.
Directory bind account: an LDAP user source uses a service account to look up users and groups. It should be read-only, excluded from privileged groups and rotated.
PSA and RMM integrations: extensions that connect ScreenConnect to ConnectWise Automate, PSA or ticketing tools hold API keys or integration credentials. Inventory each one, record its owner, and remove extensions you do not use. The ConnectWise Cloud Backup Breach 2026, a different ConnectWise product, shows how a single stolen vendor application credential can reach hundreds of customer tenants at once.
External database credentials: if sessions or audit data are stored in an external database, its account is in scope for rotation after any compromise.
Licence file: License.xml lives in App_Data. Protect the whole App_Data folder: it holds the security database, licence and configuration that incident responders must preserve.

An MSP's ScreenConnect instance is also a trust relationship for every customer it serves (ATT&CK T1199 Trusted Relationship). Customers should ask how the MSP scopes technicians to their session group, how quickly it patches, and whether it shares audit logs. See the Cybersecurity for MSPs and MSSPs Guide and the Secrets Management Guide.

Logging and detection

ScreenConnect records session activity (hosts, guests, timestamps, commands, tools and file transfers) in its server-level audit log, viewable under Administration > Audit, and can record video of sessions. On-premises, the audit data sits in the server's database. Forward it, the Windows event logs and web or firewall request logs to a SIEM so that a server compromise cannot also erase the evidence.

Signal	Source	What it can indicate	ATT&CK
Any request to `SetupWizard.aspx` after initial setup	Firewall, load balancer or reverse proxy logs	CVE-2024-1709 exploitation attempt	T1190 Exploit Public-Facing Application
New host user, especially an administrator, outside change control	ScreenConnect audit log, `Security.db` user table	Persistence through a new account	T1136 Create Account, T1098 Account Manipulation
RanCommand, QueuedCommand, ProcessedCommand, QueuedTool, QueuedElevatedTool	Audit log session events	Commands pushed to endpoints, possibly at scale	T1219.002 Remote Desktop Software, T1059
SentFiles, CopiedFiles, RanFiles, QueuedInstallAccess	Audit log session events	Payload delivery or new agents being installed	T1105 Ingress Tool Transfer
New `.aspx` or `.ashx` files in `App_Extensions`	Windows Event ID 4663 (file system auditing), file integrity monitoring	CVE-2024-1708 path traversal or a web shell	T1505.003 Web Shell
PowerShell or cmd running scripts from `C:\Windows\Temp\ScreenConnect\<version>\`, BITSADMIN use, unusual children of `ScreenConnect.ClientService.exe`	EDR on endpoints	Malicious use of a legitimate agent	T1059 Command and Scripting Interpreter
Host sign-ins from new countries or hosting providers, many endpoints accessed in a short time	Audit log, IdP logs	Stolen technician credentials	T1078 Valid Accounts

Mandiant recommends enabling Windows advanced audit policy (Object Access > Audit File System, Success) on the ScreenConnect temp and App_Extensions folders, limited to those folders because file auditing is expensive on busy servers. If a reverse proxy sits in front of the server, pass X-Forwarded-For so logs keep the real client address.

Measure that the controls work:

Patch latency: hours from a ConnectWise Priority 1 bulletin to every on-premises server patched, plus days to reinstall host clients and update access agents where the bulletin requires it (as CVE-2026-84869 did).
MFA coverage: percentage of host accounts with two-factor authentication or IdP MFA (target 100 per cent).
Privilege spread: number of accounts with administration or global (all session groups) roles, tracked monthly.
Audit forwarding health: hours since the last ScreenConnect audit event reached the SIEM, alerting on gaps.
Agent hygiene: count of access agents not seen for 90 days, and of agents on endpoints that are no longer in the asset inventory.

Hardening baseline

Server and network

Stay on a supported build: CVE-2025-3935 required 25.2.4 or a patched build back to 23.9; CVE-2026-84869 required 26.6.5, reachable directly only from 25.4 or later. Keep maintenance current so you are eligible for fixes, and check the Version Check section on the Administration page.
Use a Windows server: ConnectWise states that Linux and Mac servers no longer receive updates, so migrate them to Windows or to ScreenConnect Cloud.
Harden the operating system: the ConnectWise best practice guide recommends applying the Windows Server STIG, disabling TLS 1.0 and 1.1 in the SCHANNEL registry keys, and blocking TCP 135, 139 and 445 when the server is not domain joined.
TLS on the web interface: the Web Server on port 8040 is plain HTTP unless you bind a certificate; configure TLS before any external use. The Relay on port 8041 encrypts session data.
Limit inbound exposure: guests need the Relay and the web address; technicians need the web interface. Put the web interface behind a VPN, zero trust access proxy or IP restriction where your support model allows it.
Restrict egress: Mandiant suggests allowing outbound traffic only to license.screenconnect.com, check.screenconnect.com, extension.screenconnect.com and, if Automate is used, api.labtechsoftware.com.
Back up App_Data and the installation directory to an isolated location so a rebuild does not lose configuration.

Application settings

Two-factor authentication or IdP MFA for every host; IP login restrictions for administrators.
Roles scoped to session groups; TransferFiles, command and tool permissions only where needed.
Consent-to-connect for attended devices; lock on disconnect; page idle timeout.
Extensions reviewed and unused ones removed; install the Security toolkit extension if you need its controls such as clearing queued commands.
Audit triggers or reports for the session event types listed above, and video auditing where policy requires it.

Rolling it out

Inventory: list every ScreenConnect server and Cloud instance you or your MSPs operate, with version, maintenance status and exposure.
Patch and check for compromise first: ConnectWise asks partners to check for signs of compromise before returning a patched server to service.
Apply identity controls in a pilot group of technicians: MFA, IP restriction, new role scoping. Confirm support workflows still function.
Extend to all hosts, keeping a documented rollback (previous role export and a break-glass administrator) in case scoping blocks urgent work.
Enable forwarding and alerting, then test detections with a benign command on a lab endpoint.

Decision guidance: on-premises or Cloud

ScreenConnect Cloud: ConnectWise patches the server, which removed partner action for CVE-2024-1709 and CVE-2025-3935. You still own users, roles, MFA, agent and host client updates, and audit review.
On-premises: suits regulatory or hosting requirements but makes you responsible for emergency patching, OS hardening, exposure and backups. Small teams without 24-hour patch capacity usually carry less risk on Cloud.
Migrating: assess the on-premises server for compromise before migrating, then decommission it fully, including DNS records and firewall rules, as the ConnectWise bulletin advises.

Common misconfigurations

Unpatched internet-facing servers: CVE-2024-1709 is marked in the KEV catalogue as known to be used in ransomware campaigns, and Mandiant observed mass exploitation by multiple actors. Servers out of maintenance missed fixes until ConnectWise released free interim builds.
Patching without investigating: patching a server that already has a rogue administrator, a web shell in App_Extensions or a staged tool leaves the attacker in place. Rebuild from a trusted image and rotate credentials.
Every technician has every machine: a single global technician role means one phished account reaches every customer. Scope by session group.
Email-based second factor: codes sent to a mailbox that shares the same password give little protection; ConnectWise itself recommends app or hardware based factors.
Forgotten agents and servers: agents left on decommissioned customer devices, and test servers never shut down, extend the attack surface without monitoring.
Unauthorised ScreenConnect instances: attackers also bring their own ScreenConnect. CISA's RMM advisory recommends application control that blocks unapproved RMM tools, including portable versions, which only works if your approved instance is clearly identified.

Framework mapping

Control	NIST SP 800-53 Rev. 5	NIST CSF 2.0	CIS Controls v8.1	ISO/IEC 27001:2022 Annex A
Emergency patching from ConnectWise bulletins and KEV	SI-2, RA-5	ID.RA-01, PR.PS-02	7.4 Automated application patch management	A.8.8 Management of technical vulnerabilities
Host MFA, user sources, user review	IA-2, AC-2	PR.AA-01, PR.AA-03	6.4 MFA for remote network access; 5.3 Disable dormant accounts	A.5.18 Access rights; A.8.5 Secure authentication
Roles scoped to session groups, consent	AC-6, AC-17	PR.AA-05	6.8 Role-based access control	A.8.2 Privileged access rights
Exposure and egress limits	SC-7	PR.IR-01	12.2 Secure network architecture	A.8.20 Network security
Audit forwarding and alerting	AU-2, AU-6, SI-4	PR.PS-04, DE.CM-09, DE.AE-02	8.2 Collect audit logs; 8.11 Conduct audit log reviews	A.8.15 Logging; A.8.16 Monitoring activities
Rebuild and rotate after compromise	IR-4	RS.MI-01	17.4 Incident response process	A.5.26 Response to information security incidents

Practitioner checklist

Record every ScreenConnect server and Cloud instance, its version, maintenance status and who operates it.
Subscribe to ConnectWise security bulletins and patch Priority 1 issues as emergency changes; reinstall host clients and update agents when a bulletin says so.
Enforce two-factor authentication or IdP MFA for every host; restrict administrator sign-in by IP.
Scope technician roles to session groups; limit TransferFiles, command and tool permissions; require consent on attended devices.
Alert on SetupWizard.aspx requests, new users, extension changes and bulk command or file events.
Forward the audit log, Windows events and proxy logs to a SIEM and alert on forwarding gaps.
Restrict inbound access to the web interface and outbound traffic to the ConnectWise hosts the server needs.
Inventory and rotate the server's local administrator, directory bind, integration and database credentials; keep machine keys unique.
Prepare a playbook: revoke user access, isolate, preserve App_Data, rebuild, rotate.
Block unapproved remote access tools on endpoints so attacker-owned ScreenConnect instances stand out.

ConnectWise ScreenConnect Hardening Guide: Patching, Roles, Auditing and Exposure