What the ConnectWise 2026 MSP Threat Report reveals about trust, execution, and the limits of reactive security.

Modern cyberattacks do not always defeat security controls through technical sophistication. Increasingly, they succeed by persuading systems and people to treat unauthorised activity as legitimate.

That is the central theme of the ConnectWise 2026 MSP Threat Report. Drawing on incidents affecting managed service providers and the small and medium sized businesses they support, the report argues that attackers are exploiting trusted identities, software, updates, system utilities and ordinary user behaviour.

Its most important conclusion is blunt: reactive security models repeatedly failed MSP environments because detection after execution was often too late.

For MSPs and MSSPs, this raises a difficult question.

What happens when the attacker does not appear overtly malicious until after executable code has already been introduced and launched?

Trust has become an attack surface.

Traditional cybersecurity architectures rely on several forms of trust.

A user is trusted because they have authenticated successfully. Software is trusted because it has been signed by a recognised publisher. An update is trusted because it came through an established distribution mechanism. A system utility is trusted because it forms part of Windows. An administrator is trusted because they hold elevated privileges.

None of these assumptions is inherently unreasonable. The problem is that attackers now understand how to exploit them.

The ConnectWise report describes incidents in which adversaries used stolen credentials, compromised software suppliers, legitimate system utilities and user‑initiated execution to bypass controls that treated trusted activity as safe.

This does not mean that identity security, digital signatures or trusted supply chains are unimportant. It means they answer different questions.

Identity security asks whether a person or account is authorised to access a system.

Digital signing asks whether software can be associated with a particular publisher.

Neither necessarily establishes whether a specific piece of executable code should be allowed to enter and run within a particular environment.

That distinction is becoming increasingly important.

ClickFix illustrates the execution problem.

ClickFix is one of the clearest examples in the report.

Rather than delivering malware through a conventional attachment or exploiting a software vulnerability, ClickFix attacks persuade users to copy and paste commands into the Windows Run dialogue or a command shell. The prompt may be presented as a browser verification step, a CAPTCHA, a file repair instruction, or a security warning.

The user believes they are following a legitimate process. The system sees a recognised user launching legitimate Windows tools. The command then retrieves and launches a loader, information stealer or remote access tool.

The initial execution path therefore appears legitimate at several levels.

The user is authorised.

The utility is trusted.

The action may take place within an apparently legitimate browser session.

Yet the resulting code is not authorised.

The report notes that later ClickFix campaigns increasingly used PowerShell, MSHTA, reflective loading and in‑memory delivery techniques. Attackers reduced visible artefacts while continuing to rely on trusted execution paths and user consent.

This is not just another phishing variant. It exposes an execution control problem that security awareness training alone cannot reliably solve.

Training users remains necessary, but no awareness programme eliminates human error. Nor should an organisation’s final defensive boundary depend on every employee correctly identifying every deceptive instruction.

Software supply chains amplify the same weakness.

The same issue appears in software supply chain attacks.

The report describes how attackers compromise package maintainers, developer accounts and build pipelines, allowing malicious code to enter trusted packages and updates. Once distributed through normal channels, those components can spread across large numbers of downstream environments.

The software may arrive from a familiar supplier. It may be digitally signed. It may be installed through an approved management process.

The source appears trusted, but the executable content has changed.

ConnectWise recommends layered safeguards including approved repositories, version locking, software bills of materials, signature checks, application control and staged rollouts. It also acknowledges that these measures do not guarantee safety and are not implemented consistently.

This exposes a weakness in reputation‑based security.

A signature establishes origin and integrity from the point of signing. It does not establish that the signed code is safe, necessary, or authorised for every protected system.

Similarly, a software bill of materials helps organisations understand what components are present. It does not itself prevent a compromised component from executing.

These controls remain valuable, but they do not provide a deterministic answer to the question that matters at the endpoint: Is this executable code authorised to be introduced here?

Ransomware moves faster than the response cycle.

The report’s discussion of Akira ransomware reinforces the problem.

Akira affiliates commonly gained access through stolen VPN credentials and then moved rapidly through scanning, credential theft, exfiltration, and encryption. They also used legitimate but vulnerable drivers to disable endpoint protection before deploying ransomware.

The attack sequence is significant.

By the time an EDR platform detects suspicious behaviour, an MDR analyst investigates it, and containment begins, the attacker may already have disabled security tools, compromised backups or deployed the final payload.

This does not make EDR or MDR ineffective. Both remain essential for visibility, investigation, and response.

It does mean that detection and response operate under time pressure. The attacker only needs one successful execution chain. The defender must identify, interpret, and interrupt it quickly enough to prevent impact.

For MSPs managing thousands of endpoints across multiple customers, that creates both security and operational consequences.

Every successful malicious execution risks becoming an alert.

Every alert requires triage.

Every genuine incident consumes analyst time.

Every delay increases the potential blast radius.

The result is a service model in which revenue may grow through additional customers and endpoints, while delivery costs rise through additional telemetry, investigations, and analyst workload.

Deterministic eXecution Integrity addresses a different layer.

Deterministic eXecution Integrity, or DXI, is intended to operate beneath detection and response.

Rather than attempting to determine whether code is malicious, DXI asks whether executable code is authorised to be introduced onto the protected system.

That is a narrower question, but it can produce a deterministic outcome within the execution paths DXI controls.

Authorised executable code, as defined by DXI policy, is permitted.

Executable code that is not authorised by policy is prevented from being written to or executed from protected storage.

This approach does not depend on recognising a malware family, matching a signature, observing suspicious behaviour, or waiting for threat intelligence to classify a new payload.

It also does not assume that an authenticated user, an administrator, a signed application, or a legitimate Windows utility should be able to introduce arbitrary executable code.

That makes DXI particularly relevant to attacks involving:

• user‑initiated downloads and execution.
• trojanised installers and updates.
• ransomware payloads.
• malicious drivers.
• persistence components.
• loaders and remote access tools.
• and executable code delivered through compromised supply chains.

DXI cannot, by itself, turn a compromised but policy‑approved update into a safe one, but it significantly reduces exposure to unexpected executables and ad‑hoc tooling introduced outside defined update processes.

The objective is not to generate another alert. It is to prevent the unauthorised executable component from becoming an active incident.

DXI is not a replacement for the security stack.

The distinction matters because DXI should not be positioned as a replacement for identity security, EDR, MDR, SIEM, network monitoring or immutable backup.

Stolen credentials must still be detected and controlled.

Malicious access to data must still be monitored.

Authorised tools may still be abused.

Browser‑based identity attacks may not require a new executable payload.

Data exfiltration can occur through software that is already present and authorised.

Backups remain necessary because no single control can address every failure mode.

The case for DXI is therefore not that the rest of the security stack is redundant. It is that the stack is incomplete without an effective execution control layer.

ConnectWise itself concludes that security must move earlier in the attack lifecycle, while maintaining identity protection, monitoring and resilient recovery.

DXI fits within that layered model.

Identity controls who may enter.

Network security controls where they may go.

EDR and MDR identify suspicious activity.

SIEM provides context.

Backup supports recovery.

DXI controls whether unauthorised executable code can be introduced.

A practical opportunity for MSPs

For MSPs and MSSPs, the value is not limited to technical prevention.

A deterministic execution layer can potentially reduce the number of attacks that progress into full security incidents.

That means fewer avoidable alerts, fewer emergency investigations and less pressure on SOC resources.

It may also allow an MSP to offer a differentiated prevention service alongside existing MDR, SIEM and backup products.

The commercial argument should not be that DXI replaces the SOC.

It is that fewer attacks should need to reach the SOC in the first place.

The ConnectWise report describes a threat environment in which trust is routinely abused, execution paths appear legitimate, and attackers move faster than reactive controls can always respond.

That is precisely why execution integrity deserves to be treated as a distinct security layer.

The industry has spent years improving its ability to detect malicious behaviour.

The next question is whether more of that behaviour can be prevented from beginning at all.