The double-edged sword: Remote management tools for MSPs | Todyl
The Hidden Cascade: How MSP Remote Management Tools Amplify Third-Party Cyber Risk
The modern enterprise operates within an intricate web of third-party relationships, each representing both operational efficiency and potential vulnerability. Among these relationships, Managed Service Providers (MSPs) occupy a uniquely precarious position—they hold the keys to the kingdom for hundreds of clients simultaneously. When their remote management tools become compromised, the resulting damage doesn't spread linearly; it cascades exponentially across entire client portfolios, transforming a single security incident into a governance crisis that can impact thousands of organizations within hours.
The 2021 Kaseya VSA attack stands as a watershed moment in understanding this amplification risk. When the REvil ransomware group exploited zero-day vulnerabilities (CVE-2021-30116) in Kaseya's VSA software, they didn't just breach a single vendor—they weaponized the trust architecture that connects MSPs to their clients. The attack propagated through established service relationships, ultimately affecting approximately 1,500 businesses downstream. This incident revealed a fundamental blind spot in how organizations assess and manage third-party risk: most treat MSPs as isolated vendors rather than recognizing them as critical infrastructure nodes capable of multiplying security incidents across their entire service ecosystem.
The Privileged Access Paradox
Remote Monitoring and Management (RMM) tools exist to solve a legitimate business problem: they enable MSPs to efficiently manage IT infrastructure across multiple client environments. These platforms require deep, persistent access to client systems—often at administrative or root level—to perform essential functions like patch management, system monitoring, security updates, and troubleshooting. This privileged access model creates extraordinary operational value while simultaneously establishing the perfect conditions for catastrophic security failure.
The paradox lies in the dual nature of this relationship. Organizations engage MSPs specifically because they lack internal resources or expertise to manage complex IT environments. The MSP becomes a critical dependency for business continuity, often managing core infrastructure including email servers, file storage, authentication systems, and security controls. Yet this same dependency relationship means the MSP represents the highest-impact attack vector in the organization's entire threat landscape.
Traditional vendor risk assessments frequently fail to capture this complexity. Organizations request SOC 2 reports, review security questionnaires, and verify certifications—all valuable activities that nonetheless miss the fundamental question: What happens when the centralized access management system itself becomes the attack vector? The Kaseya incident demonstrated that even MSPs with reasonable security practices can become vehicles for widespread compromise when the tools they rely upon contain exploitable vulnerabilities.
Regulatory Notification Cascades Under NIS2 and DORA
The regulatory landscape surrounding cybersecurity incidents has evolved significantly, with frameworks like the EU's NIS2 Directive and the Digital Operational Resilience Act (DORA) establishing strict notification requirements and explicit expectations for third-party risk management. MSP tool compromises create particularly challenging scenarios within these frameworks, compressing notification timelines and creating coordination complexities that few organizations have adequately prepared for.
Under NIS2, organizations classified as essential or important entities must report significant incidents within 24 hours of becoming aware of them, with detailed reports due within 72 hours. When an MSP's remote management tool is compromised, the "awareness" clock starts ticking simultaneously for potentially hundreds of organizations. Each affected entity faces the same compressed timeline, must conduct its own impact assessment, and must determine whether the incident meets reporting thresholds—often without complete information about the scope or nature of the compromise.
This creates a notification cascade where regulatory authorities may receive hundreds of related incident reports within hours, each requiring review and potentially triggering sector-wide assessments. For organizations in critical sectors like healthcare, finance, or energy, the regulatory scrutiny intensifies further. A hospital using an affected MSP must determine whether patient data was accessed, a bank must assess whether financial systems were compromised, and energy providers must evaluate whether operational technology environments were exposed—all while the MSP itself conducts its own investigation.
DORA compounds these challenges for financial institutions by establishing explicit requirements for ICT third-party risk management. Financial entities must maintain comprehensive registers of ICT third-party service providers, conduct due diligence proportionate to the criticality of services provided, and ensure contractual arrangements include specific security requirements and audit rights. When an MSP tool compromise occurs, financial institutions must not only manage the immediate incident response but also demonstrate to regulators that their third-party risk management framework was adequate—a difficult position when the compromise affects multiple institutions simultaneously through the same vendor relationship.
Contractual Performance and Concentrated Liability
The legal and contractual implications of MSP tool compromises extend far beyond immediate technical remediation. When remote management platforms fail or become compromised, MSPs may simultaneously breach service level agreements (SLAs) with their entire client portfolio. This concentration of contractual liability represents a systemic risk that most MSP engagement models fail to adequately address.
Consider the typical MSP service agreement: it promises specific uptime guarantees, response times for incidents, and often includes security assurances about the protection of client data and systems. When an RMM tool compromise occurs, the MSP may simultaneously fail to meet these obligations for hundreds of clients. The resulting liability exposure can include:
Direct damages from service interruption, including lost revenue, recovery costs, and emergency response expenses. In the Kaseya incident, some affected businesses faced extended downtime during critical business periods, with recovery costs running into hundreds of thousands of dollars per organization.
Regulatory penalties that may be assessed against both the MSP and affected clients, particularly in regulated industries where data protection or operational resilience requirements create strict liability frameworks.
Third-party claims from customers, partners, or other stakeholders affected by the downstream impact of the compromise. A retail business affected by an MSP breach during peak season might face claims from customers unable to complete transactions, while a healthcare provider might face liability for delayed patient care.
Reputational damage that affects both the MSP's ability to retain and acquire clients and the affected organizations' relationships with their own customers and stakeholders.
Most MSP contracts include limitation of liability clauses that cap damages at some multiple of annual service fees—often 12 months or less. When a single incident affects hundreds of clients simultaneously, these limitations become meaningless as aggregate exposure vastly exceeds any reasonable insurance coverage or financial reserves. This creates an existential risk for MSPs while leaving clients with inadequate recourse for significant losses.
Rethinking MSP Risk Assessment Frameworks
Organizations must fundamentally reconsider how they evaluate and manage MSP relationships in light of these concentrated risks. Traditional vendor risk assessment approaches—treating MSPs as isolated third parties evaluated primarily on their own security practices—prove inadequate when the systemic nature of RMM tool vulnerabilities is properly understood.
A more robust framework should incorporate several key elements:
Architectural risk assessment that evaluates not just the MSP's security practices but the inherent risks in the RMM tools themselves. This includes understanding what vulnerabilities have been identified in specific platforms, how vendors respond to vulnerability disclosures, and what compensating controls exist to limit blast radius when compromises occur.
Concentration risk analysis that explicitly models the impact of MSP-wide incidents rather than assuming isolated failures. Organizations should conduct tabletop exercises that simulate scenarios where the MSP and all its clients are simultaneously compromised, testing notification procedures, alternative service arrangements, and recovery capabilities.
Contractual provisions that specifically address portfolio-wide incidents, including requirements for MSPs to maintain adequate cyber insurance, establish segregated access controls that limit lateral movement between client environments, and provide detailed incident response plans that account for mass-compromise scenarios.
Continuous monitoring that goes beyond periodic assessments to include real-time visibility into MSP activities within client environments. This might include requirements for MSPs to provide detailed logging of administrative actions, implement just-in-time access controls that limit standing privileges, and participate in threat intelligence sharing that provides early warning of potential compromises.
Alternative service arrangements that enable rapid transition to different providers or in-house management in the event of MSP compromise. Organizations overly dependent on single MSPs for critical functions face extended recovery periods when those relationships are disrupted by security incidents.
The Path Forward: Shared Responsibility in the MSP Ecosystem
The challenges posed by RMM tool vulnerabilities cannot be solved by any single stakeholder acting alone. MSPs, their clients, RMM tool vendors, and regulators all play essential roles in establishing a more resilient ecosystem.
MSPs must move beyond treating security as a compliance checkbox and recognize that their privileged access to client environments creates extraordinary responsibility. This includes implementing defense-in-depth strategies that assume RMM tools may be compromised, maintaining segregated environments that limit lateral movement between clients, and establishing transparent communication channels that enable rapid notification when incidents occur.
RMM tool vendors must prioritize security in product development, establish robust vulnerability management programs, and design architectures that limit the blast radius of potential compromises. The Kaseya incident revealed that even widely-used enterprise platforms can contain exploitable vulnerabilities; vendors must assume breach scenarios and build containment capabilities accordingly.
Client organizations must evolve beyond passive reliance on MSP security assurances to become active participants in risk management. This includes conducting meaningful due diligence on both MSPs and the tools they use, maintaining incident response capabilities that function even when MSP services are unavailable, and structuring contracts that align incentives toward security rather than simply cost optimization.
Regulators must recognize the systemic nature of MSP risks and develop frameworks that account for the cascading impact of RMM tool compromises. This includes establishing clear expectations for how MSPs should be classified in third-party risk frameworks, creating streamlined notification procedures for mass-impact incidents, and potentially developing specific requirements for RMM tool security that go beyond general cybersecurity frameworks.
Conclusion: Recognizing the True Nature of MSP Risk
The Kaseya VSA attack was not an isolated incident but rather a clarifying moment that revealed the true nature of risk in MSP relationships. These service providers are not simply vendors to be assessed and managed like software suppliers or cloud platforms. They represent critical infrastructure nodes in the modern enterprise ecosystem, with privileged access that creates concentrated risk across entire client portfolios.
Organizations that continue to treat MSPs as conventional third-party vendors—evaluating them primarily through questionnaires and certifications—fundamentally misunderstand the risk landscape. The privileged access inherent in RMM tools creates a unique threat model where a single compromise can trigger simultaneous regulatory notifications, contractual breaches, and operational disruptions across hundreds of organizations.
As regulatory frameworks like NIS2 and DORA establish increasingly stringent requirements for third-party risk management, organizations can no longer afford this blind spot. The path forward requires honest assessment of the systemic risks posed by MSP relationships, meaningful investment in monitoring and control capabilities, and contractual structures that align incentives toward security rather than simply shifting liability.
The double-edged sword of MSP remote management tools will remain sharp on both sides—they provide essential operational capabilities while creating concentrated vulnerability. The question is not whether to use these tools but how to do so with clear-eyed understanding of the risks involved and robust frameworks to manage them effectively.
This analysis draws upon research from Todyl examining MSP remote management tool vulnerabilities and the Kaseya VSA ransomware attack. For detailed technical insights into MSP tool security and specific recommendations, visit: https://www.todyl.com/blog/remote-management-tools-vulnerabilities-msps