ConnectWise ScreenConnect Vulnerabilities: What Your Business Needs to Know If Your MSP Uses It

On March 17, 2026, ConnectWise published a security bulletin for CVE-2026-3564 — a cryptographic signature verification flaw rated CVSS 9.0 that could allow an attacker with access to server-level key material to hijack authenticated sessions and escalate privileges across ScreenConnect deployments. It was the third major vulnerability disclosure for the platform in just over two years, and it arrived while many organizations were still processing the fallout from a confirmed nation-state breach tied to the previous vulnerability. For businesses whose managed IT services provider relies on ConnectWise ScreenConnect as their primary remote access tool, the question is no longer whether the platform carries risk. The question is what to do about it.

ScreenConnect — formerly known as ConnectWise Control — is one of the most widely deployed remote monitoring and management (RMM) tools in the managed services industry. It gives MSPs administrative-level access to every endpoint under their care. That design is what makes it useful. It is also what makes every vulnerability in the platform a potential supply chain catastrophe that cascades from a single compromised server to hundreds of client organizations simultaneously.

This article traces the full timeline of ConnectWise ScreenConnect vulnerabilities, explains why they matter to businesses that rely on MSPs, outlines the specific steps companies should take right now, and clarifies why ITECS clients are not affected by any of these disclosures.

The ConnectWise ScreenConnect Vulnerability Timeline

What makes the ScreenConnect situation particularly concerning is not any single vulnerability in isolation. It is the pattern — a recurring cadence of critical disclosures that has persisted across three consecutive years, each one exploited in the wild before many organizations could respond.

A single compromised remote management server can cascade administrative access to every client environment the MSP manages.

Why ScreenConnect Vulnerabilities Are a Supply Chain Risk

To understand why a vulnerability in a single software product warrants this level of concern, it helps to understand what RMM tools actually do and why they represent an outsized attack surface.

Remote monitoring and management platforms like ScreenConnect are the operational backbone of managed IT services. They provide MSPs with persistent, often administrative-level access to every server, workstation, and endpoint under their management. A technician sitting at their desk can remotely access a client's domain controller, push software updates to hundreds of machines, execute scripts with elevated privileges, and transfer files — all through the RMM platform. This is by design. Without this access, an MSP cannot deliver the service its clients are paying for.

But that same architecture means a compromised RMM server is not just one breached system. It is an authenticated bridge into every client environment the MSP manages. When an attacker gains control of a ScreenConnect server, they inherit the same administrative reach the MSP's own engineers use every day. They can deploy ransomware to every managed endpoint simultaneously. They can exfiltrate data from any connected client. They can establish persistence across dozens or hundreds of organizations from a single point of entry.

This is the definition of a supply chain attack, and it is precisely what security researchers warned about after each ScreenConnect disclosure. As cybersecurity threat analysis shows, the organizations most affected are often not the ones running the vulnerable software directly — they are the downstream clients who trusted their provider to maintain secure infrastructure.

What to Do If Your MSP Uses ConnectWise ScreenConnect

If your organization contracts IT management to an MSP that uses ConnectWise ScreenConnect, the following steps are not optional. They are the minimum due diligence required to understand your actual exposure and protect your business.

Step 1: Confirm Patch Status Immediately

Contact your MSP and ask them to confirm — in writing — that their ScreenConnect deployment is running version 26.1 or later. This is the version that addresses CVE-2026-3564, the most recent cryptographic vulnerability. If they are running on-premises ScreenConnect, they must have upgraded manually. Cloud-hosted instances were patched automatically, but you should still verify. If they cannot confirm the version number, that is a red flag. If they are running a version older than 25.2.4, the system is also still vulnerable to the 2025 nation-state exploit (CVE-2025-3935).

Step 2: Request Incident Response Documentation

Ask your MSP whether they were affected by any of the three vulnerability windows — particularly the May 2025 breach. A reputable provider will be able to share their internal security assessment, the timeline of when they applied patches, and any forensic analysis they conducted. If they dismissed the disclosures or cannot provide documentation, you should seriously question whether their security operations meet the standard your business requires.

Step 3: Review Access Controls and Logging

Ask your MSP to explain how ScreenConnect access to your environment is controlled. Key questions include:

• Is multi-factor authentication enforced for all technician accounts accessing ScreenConnect?
• Is session logging enabled so that every remote access event is recorded with timestamps, user identity, and actions taken?
• Are administrative interfaces IP-restricted, or can anyone on the internet reach the ScreenConnect login page?
• How are machine keys managed? Are they encrypted at rest, and has key material been rotated following the 2025 and 2026 disclosures?
• What is the MSP's patching SLA for critical vulnerabilities in their own infrastructure — not your endpoints, but their management tools?

Step 4: Evaluate Alternative Providers

If your MSP cannot satisfactorily answer these questions, or if the cumulative risk of three major vulnerability disclosures in 25 months exceeds your organization's tolerance, it may be time to evaluate alternative managed IT services providers that use different remote access tooling. Not all MSPs use ScreenConnect. The platform you never heard of until this article is the one with administrative access to every machine in your network. That should matter in your vendor selection.

Evaluating your MSP's security posture requires direct questions about patching timelines, access controls, and incident response documentation.

What Good MSP Security Looks Like vs. Red Flags

Not every MSP handles security tooling the same way. The following comparison highlights the practices that separate mature, security-conscious providers from those that may be exposing their clients to unnecessary risk.

Security-first infrastructure begins with the tools and platforms a provider chooses to deploy — not just the defenses applied to client environments.

ITECS Does Not Use ConnectWise ScreenConnect

If you are an ITECS client reading this article, the straightforward answer is: none of these vulnerabilities affect you.

ITECS does not use ConnectWise ScreenConnect — or any ConnectWise product — in any part of its managed IT service delivery. This is not an accident or a recent decision made in response to these disclosures. It reflects a deliberate toolchain philosophy rooted in security-first vendor selection, where every platform in our operational stack is evaluated not only for its capabilities but for its security track record, architectural transparency, and the vendor's demonstrated commitment to proactive vulnerability management.

The remote access and monitoring tools ITECS deploys are selected based on criteria that include least-privilege access models, end-to-end encryption, mandatory multi-factor authentication for all administrative sessions, comprehensive audit logging, and a vendor security posture that has been validated through independent assessment. We do not accept tools where a single vulnerability disclosure can expose an entire client base to supply chain risk.

For ITECS clients, this means:

• Zero exposure to CVE-2024-1709, CVE-2024-1708, CVE-2025-3935, CVE-2025-14265, or CVE-2026-3564.
• No action required in response to any ConnectWise security bulletin or CISA KEV alert related to ScreenConnect.
• No supply chain risk from the ConnectWise platform — neither the 2024 mass exploitation campaigns nor the 2025 nation-state breach had any pathway into ITECS-managed environments.
• Continuous toolchain evaluation — ITECS regularly reviews the security posture of every vendor in our stack and will proactively communicate with clients if any tool we use is affected by a significant vulnerability disclosure.

This is part of what it means to choose a managed IT provider that treats its own operational security with the same rigor it applies to client environments. If you want to understand more about how ITECS approaches security-first service delivery, our approach to managed IT services details the principles behind these decisions.

Best Practices for Evaluating Your MSP's Security Toolchain

Whether or not the ConnectWise ScreenConnect disclosures directly affect your organization, they highlight a broader truth about managed IT services: the tools your MSP uses to manage your infrastructure are part of your attack surface. Evaluating those tools should be a routine part of vendor governance, not something triggered only by a crisis.

Require Toolchain Transparency

Your MSP should be able to provide a complete list of every software platform that has network access to your environment, administrative privileges on your endpoints, or the ability to execute commands remotely. This is not proprietary information — it is a basic security requirement. If your MSP considers their toolchain a trade secret, that is not a sign of competitive advantage. It is a sign that they do not want you to evaluate the risk.

Audit Patching Practices for MSP-Side Infrastructure

Most SLAs cover patching for client endpoints. Fewer cover the MSP's own management infrastructure. Ask explicitly: what is your patching SLA for critical vulnerabilities in the tools you use to access our systems? The answer should be measured in hours for CVSS 9+ vulnerabilities, not days or weeks. For context, CVE-2024-1709 had working exploit code published within 24 hours of disclosure [Huntress]. Any MSP that took longer than that to patch was operating an actively exploitable bridge into every client network.

Validate Access Controls and Session Governance

Every remote session into your environment should be authenticated with MFA, logged with full attribution (which technician, when, what actions), and governed by least-privilege policies. Ask your MSP whether technicians use shared credentials or individual accounts. Ask whether sessions can be initiated without your knowledge or approval. Ask whether you can receive audit logs of all remote access to your systems. A mature network monitoring and management practice will have clear answers to all of these questions.

Assess Vendor Concentration Risk

If your MSP's entire service delivery depends on a single vendor's ecosystem — remote access, ticketing, monitoring, patching, and backup all from one platform — a vulnerability in that vendor becomes a single point of failure for everything. The ScreenConnect disclosures illustrate this precisely: organizations whose MSPs built their entire practice on the ConnectWise stack faced compounding risk as each new vulnerability emerged. Defense-in-depth applies to your MSP's toolchain, not just your own network. The best providers use a diversified stack with independent layers of endpoint detection and response, managed firewall services, and backup and disaster recovery that do not share a single upstream dependency.

Establish Breach Notification Expectations

Your contract with your MSP should specify how quickly they must notify you if a tool they use to access your environment is compromised. The ConnectWise nation-state breach in May 2025 is instructive: ConnectWise disclosed the incident publicly, but individual MSPs varied wildly in how quickly — or whether — they informed their own clients. Some providers sent detailed notifications within 24 hours. Others said nothing and hoped their clients would not read the news. Your MSP agreement should leave no ambiguity about which category your provider falls into.

The Bigger Picture: RMM Security Is Everyone's Problem

The ConnectWise ScreenConnect vulnerabilities are not an isolated case. They are part of a broader pattern affecting the entire remote monitoring and management category. In recent years, vulnerabilities in Kaseya VSA, SolarWinds Orion, and other widely deployed MSP platforms have demonstrated that the tools designed to protect and manage IT infrastructure can themselves become the most consequential attack vectors.

For business leaders, the takeaway is not that one specific product is unsafe and should be avoided. The takeaway is that the security of your MSP's operational toolchain is inseparable from the security of your own organization. When you grant a managed services provider administrative access to your servers, workstations, and cloud resources, you are extending your trust boundary to include every tool they use, every patch they apply (or defer), and every access control they enforce (or neglect).

That trust must be verified. Not once during vendor selection, but continuously — through contractual obligations, regular audits, transparent communication, and the expectation that your MSP holds itself to the same security standard it applies to your environment. The organizations that treat MSP vendor governance as an afterthought are the same ones that discover their exposure from a CISA advisory instead of from their own provider.

If the ConnectWise disclosures have prompted you to ask harder questions about your current IT management arrangement, that is exactly the right response. The ITECS team is available to discuss how a security-first managed IT approach can address the concerns raised in this article — whether you are evaluating a new provider or looking to strengthen the governance of your existing one.

Sources

• Huntress — Understanding the ConnectWise ScreenConnect CVE-2024-1709 & CVE-2024-1708
• Palo Alto Unit 42 — Threat Brief: ConnectWise ScreenConnect Vulnerabilities
• BleepingComputer — CISA Warns of ConnectWise ScreenConnect Bug Exploited in Attacks
• SOCRadar — ConnectWise ScreenConnect Breach and CVE-2025-3935: What You Need to Know
• ConnectWise — ScreenConnect 26.1 Security Hardening Bulletin (March 2026)
• Censys — ConnectWise ScreenConnect Vulnerability Advisory (CVE-2025-3935)
• Google Cloud (Mandiant) — Remediation and Hardening Guide for ConnectWise ScreenConnect Vulnerabilities