Your RMM Tool Is NIS2’s Highest-Risk Supply Chain Vendor — and Article 21(2)(d) Requires a Written Assessment

On 2 July 2021, REvil ransomware propagated through 60 managed service providers to encrypt systems across 800–1,500 businesses worldwide [3]. The entry point was not a phishing email or a misconfigured firewall — it was CVE-2021-30116, an authentication bypass vulnerability in Kaseya VSA, the remote monitoring and management (RMM) tool those MSPs used to administer client endpoints [4]. Sweden’s Coop supermarket chain closed around 800 stores for nearly a week. The ransom demand reached $70 million [3].

Under NIS2, Article 21(2)(d) makes supply chain security a mandatory measure for every essential and important entity. What most compliance guides omit: the RMM agent your managed service provider runs on your network is formally a “direct supplier or service provider” relationship under that article — and so are the PSA platform your MSP uses to manage tickets and billing, and the NOC monitoring software that watches your infrastructure around the clock.

This article maps the three principal components of the MSP toolchain to their specific Article 21(2)(d) risk level, explains what the Kaseya VSA attack reveals about each one, and sets out what Art.21(3) and CIR 2024/2690 require you to document before a supervisory authority asks.

What Article 21(2)(d) Actually Requires for Managed-Service Relationships

Start with the statutory text. Article 21(2)(d) of Directive (EU) 2022/2555 mandates measures addressing [1]:

“supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers”

Three words carry the compliance weight: direct, suppliers, and service providers. When your organisation uses a managed service provider for network monitoring, endpoint management, or NOC services, that MSP is a direct service provider. Their toolchain vendors — the companies behind the RMM, PSA, and NOC software the MSP operates on your behalf — qualify as the MSP’s direct suppliers. Article 21(3) pushes the assessment one level deeper: you must also consider “vulnerabilities specific to each direct supplier and service provider” and “the overall quality of products and cybersecurity practices of their suppliers, including their secure development procedures” [1].

In practice, this creates a chain of due diligence. Your Art.21(2)(d) obligation covers the MSP directly; Art.21(3) requires you to look through the MSP to the toolchain behind them.

Commission Implementing Regulation (EU) 2024/2690 (CIR 2024/2690) translates these obligations into executable requirements for entities in scope — including MSPs themselves, classified under Annex I as ICT service management (business-to-business) providers [5]. CIR Section 5 mandates a documented supply chain security policy, individual supplier assessments covering the security quality of ICT products and services, contractual security clauses, and ongoing monitoring of supplier posture throughout the contract lifecycle [5].

Plain-language summary: Before a supervisory visit, three documents must exist — a supplier inventory naming every direct supplier and service provider; a documented assessment of each supplier’s cybersecurity practices; and contracts containing enforceable security requirements. Without all three, Art.21(2)(d) is not met regardless of how strong your internal controls are.

The Three-Tier MSP Toolchain Risk Hierarchy

Not all vendor relationships carry equal Art.21(2)(d) weight. Ranking MSP toolchain components by actual attack-path risk gives compliance teams a proportionate response baseline — and determines how much assessment depth each tool category requires.

Tier 1 — RMM Tools: Highest Risk

Remote monitoring and management software — Kaseya VSA, ConnectWise Automate, NinjaOne, Datto RMM — sits on every managed endpoint with local administrative privileges. The RMM agent can push software, execute scripts, restart services, and modify configuration without additional authentication at the endpoint level. That architecture is what allows an MSP engineer to patch 500 client machines in 20 minutes.

It is also what allowed REvil to reach those same machines simultaneously.

The Kaseya VSA attack exploited CVE-2021-30116, an authentication bypass in the VSA on-premises server, then used pre-configured antivirus exclusions — which MSPs routinely set so the RMM agent itself is not blocked — to deliver the payload invisibly [4]. PowerShell commands disabled Microsoft Defender in real time; a legitimate but vulnerable Microsoft executable sideloaded the ransomware into memory [4]. No custom exploit was needed at the endpoint level. The MSP toolchain performed the attacker’s delivery function.

Under Art.21(2)(d), any NIS2-regulated entity whose MSP runs an RMM platform has a direct supplier relationship with that MSP — and through Art.21(3), a duty to understand that platform’s vulnerability disclosure posture, patch SLA, and multi-tenancy architecture.

Tier 2 — PSA Tools: Business Process Risk

Professional Services Automation platforms — ConnectWise Manage, Autotask, Halo PSA — do not touch client endpoints directly. They manage tickets, SOW documents, billing, SLA configurations, contact records, and escalation workflows. A compromised PSA does not propagate malware to endpoints. It exposes the data architecture of every client relationship and, in many implementations, stores API credentials or access tokens used to integrate with the RMM system [8].

For a NIS2-regulated entity, a PSA compromise at the MSP level means exposure of your asset inventory as reported through service tickets, your contract terms, and potentially the identity of individuals with administrative access to your environment. Under Art.21(2)(i), asset management is a required security measure [1]. PSA data is a de facto asset registry — its compromise is a control failure even if no endpoint is touched.

Tier 3 — NOC Monitoring Platforms: Silent Dependency Risk

Network Operations Centre software — Auvik, LogicMonitor, PRTG — aggregates real-time health telemetry from every device in every client environment the MSP monitors. From an attacker’s perspective, a compromised NOC platform is more valuable for intelligence than for immediate damage: it provides complete network topology, alert thresholds, configuration baselines, and — critically — the ability to suppress alerts while moving laterally inside a client network.

An attacker who controls the NOC tool can move undetected inside a client environment while every dashboard shows green. Under Art.21(2)(b), incident handling requires the ability to detect and respond to incidents [1]. If the NOC platform is compromised before an attack begins, the detection layer is blinded at the source — a control failure that maps directly to the incident handling requirement.

Despite this, NOC software is routinely omitted from vendor risk assessments — classified as monitoring infrastructure rather than a security control. That classification error is itself an Art.21(2)(d) finding.

ENISA’s Threat Landscape for Supply Chain Attacks documented a fourfold increase in supply chain attacks between 2020 and 2021, with approximately half attributed to advanced persistent threat actors [6]. The MSP toolchain represents exactly the high-leverage, multi-target supply chain attack surface that report identified.

Mapping the Kaseya VSA Attack to Article 21(2)(d) Control Gaps

The Kaseya VSA attack is not just a useful case study. It is a pre-NIS2 illustration of precisely the failure Art.21(2)(d) and Art.21(3) were designed to prevent. Six specific control gaps are identifiable — each maps to a current NIS2 requirement:

Gap identified in Kaseya VSA attack	Art.21 provision	CIR 2024/2690 section
Zero-day in VSA server not remediated before attack (known to vendor weeks prior via Dutch DIVD report)	Art.21(3): assess supplier vulnerability disclosure and patch SLA	Section 6: security in system acquisition and maintenance
Antivirus exclusions pre-configured for VSA agent enabled payload delivery without detection	Art.21(2)(d): assess security practices of direct service provider	Section 5: supplier security practices assessment
No multi-tenancy isolation — one MSP compromise reached all customers simultaneously	Art.21(2)(j): access control and authentication	Section 5: supplier architecture review requirement
VSA agent operated with local admin rights; least privilege not enforced	Art.21(2)(i): access control and asset management	Section 5: contractual security requirements
Attack launched Friday before a US public holiday — incident response delayed by over 72 hours	Art.21(2)(b): incident handling capacity	Section 5: supplier incident notification SLA
No contractual requirement for Kaseya to notify MSPs of known vulnerability before exploitation	Art.21(2)(d) + Art.21(3)	Section 5: contractual security clauses

Each gap translates to a specific question your Art.21(2)(d) assessment must answer for every Tier 1 vendor in your MSP toolchain:

• Does the vendor have a published responsible disclosure policy with documented patch SLAs for critical CVEs?
• What is the vendor’s multi-tenancy isolation architecture, and has it been validated by a third-party penetration test?
• What privileges does the RMM agent require on managed endpoints, and can those be scoped to least privilege?
• What is the vendor’s contractual commitment to notify clients of security incidents before the Art.23 24-hour CSIRT reporting window expires?

The Bidirectional Obligation: MSP Toolchain Assessment in Both Directions

Article 21(2)(d) operates simultaneously in two directions for any entity involved in managed services — and understanding which direction applies to your organisation determines your compliance obligations.

Direction 1 — The MSP as a regulated entity

MSPs and MSSPs are listed in NIS2 Annex I under “ICT service management (business-to-business)” and face the Directive’s full Article 21 obligations once they meet the size thresholds. Essential entity status applies to MSPs with 250 or more employees, or with annual turnover above €50 million combined with a balance sheet total above €43 million; important entity status applies to those with 50–249 employees or €10–€50 million turnover [7]. As a regulated entity, the MSP must perform its own Art.21(2)(d) assessment of its RMM, PSA, and NOC vendors.

NIS2 Article 6(39) defines an MSP as “an entity that provides services related to the installation, management, operation or maintenance of ICT products, networks, infrastructure, applications or any other network and information systems, via assistance or active administration carried out either on customers’ premises or remotely” [2]. MSSPs under Art.6(40) are a subset providing cybersecurity risk management [2].

Direction 2 — The MSP as a vendor subject to client assessment

For any NIS2-regulated entity that uses managed services, the MSP is a direct service provider under Art.21(2)(d). The regulated entity must assess the MSP’s security posture — which, under Art.21(3), extends to their toolchain. An MSP that cannot provide documentation of its RMM vendor’s security practices is itself failing the client’s Art.21(2)(d) supplier assessment.

Small MSPs with fewer than 50 employees are generally outside NIS2’s direct scope. However, any NIS2-regulated entity engaging a small MSP must include that provider in its Art.21(2)(d) assessment and impose contractual security requirements accordingly. Direct regulatory scope and contractual supply chain obligations are not the same thing.

Third-Party Sub-Processors Behind the Core Toolchain

Article 21(3) requires considering “the overall quality of products and cybersecurity practices of their suppliers, including their secure development procedures.” CIR 2024/2690 extends this explicitly to “supply chain-specific risks including those arising from the supplier’s own supply chain” [5].

In practice: the RMM platform your MSP operates is likely a SaaS product hosted on AWS, Azure, or Google Cloud. That cloud infrastructure provider is a sub-processor behind the tool. A compromise at the cloud hosting layer — comparable in mechanism to the 2020 SolarWinds supply chain attack, where the build pipeline itself was infiltrated before distribution — can propagate through the SaaS platform simultaneously to every MSP customer.

Three integration layers compound this risk:

• RMM-to-PSA integrations: Automated ticket creation passes asset data and alert context between systems. The API credentials used for this integration represent a lateral movement path if either system is compromised.
• PSA-to-billing connections: Financial integrations link PSA data to accounting platforms. A compromised integration can silently modify billing records, SOW terms, or contact information used for security communications.
• NOC-to-SIEM connections: Alert forwarding from NOC platforms to SIEM systems creates an inbound path from the NOC vendor’s infrastructure into the client’s security monitoring stack. A maliciously injected NOC event could trigger false incident workflows and delay response.

Art.21(2)(d) compliance requires documenting these integration points and requesting sub-processor lists from each tool vendor. For the cloud hosting layer specifically, confirming the provider’s security certification (ISO 27001, SOC 2 Type II) and the data residency region is a minimum Art.21(3) assessment step.

Building Your Art.21(2)(d) Supplier Assessment for MSP Tools

The following framework satisfies Art.21(2)(d) and Art.21(3) requirements for an MSP toolchain assessment and addresses CIR 2024/2690 Section 5 supplier assessment requirements for entities in scope.

Step 1 — Build the supplier inventory

Name every MSP tool vendor as a direct supplier in a formal supplier inventory. Record vendor name, product name, version tier, access scope (which systems and data the tool touches), and data classification (personal data, health data, financial data, network topology data).

Step 2 — Classify by risk tier

Apply the three-tier hierarchy: Tier 1 (RMM) — critical, full endpoint access and code execution capability; Tier 2 (PSA) — important, data exposure and credential risk; Tier 3 (NOC) — important, visibility risk and alert suppression capability. Risk tier determines assessment depth and contractual requirements.

Step 3 — Assessment questionnaire for Tier 1 vendors

Obtain documented answers to the following for every RMM vendor:

• Published CVE/vulnerability disclosure policy with timeline commitments for critical severities?
• Third-party penetration test results available — scope, date, and findings summary?
• Multi-tenancy architecture: is client data logically and technically isolated across tenants?
• Agent privilege model: what local rights does the agent require, and is least-privilege configuration supported?
• Patch deployment SLA: how quickly are critical CVEs patched in production and pushed to customers?
• Sub-processor list: which cloud providers host the platform, in which regions, and under what data processing agreements?

Step 4 — Contractual security clauses

CIR 2024/2690 Section 5 requires contractual security obligations for suppliers of ICT products and services [5]. For every RMM, PSA, and NOC vendor, your contract — or the MSP’s contract on your behalf — must include:

• Incident notification timeline aligned to your Article 23 incident reporting obligations — the vendor must notify you before the 24-hour CSIRT early warning window expires
• Audit rights or equivalent third-party assurance (SOC 2 Type II, ISO 27001 certificate with current scope)
• Sub-processor change notification — 30-day minimum advance notice of material infrastructure changes
• Security standards commitment — a named framework: ISO 27001, SOC 2, or equivalent, with annual renewal obligation

Step 5 — Ongoing monitoring cadence

CIR 2024/2690 requires assessment of supplier security posture throughout the contract lifecycle [5]. Schedule quarterly reviews. Trigger an out-of-cycle reassessment whenever a material CVE is published affecting the vendor’s product, or when the vendor announces a security incident impacting its infrastructure. The Kaseya timeline — vulnerability known weeks before exploitation, attack launched over a holiday weekend — illustrates why a reactive annual review cycle fails this requirement.

Frequently Asked Questions

Does Art.21(2)(d) require assessing RMM vendors if my organisation is not itself a NIS2-regulated entity?

If your organisation falls below the medium-enterprise threshold — fewer than 50 employees and less than €10 million annual turnover — NIS2 does not apply directly. However, if your regulated clients include supply chain assessment requirements in their vendor contracts, your MSP faces equivalent obligations contractually. For MSPs serving sectors such as energy, healthcare, finance, or digital infrastructure, de facto compliance is already required by client contracts regardless of direct regulatory scope.

How long do we have to complete supplier assessments?

NIS2 contains no explicit deadline for completing individual vendor assessments — the obligation is ongoing from the transposition date in each member state. In enforcement practice, competent authorities treat the absence of any supplier assessment as a systemic control failure under Art.21(2)(d). A phased approach — Tier 1 vendors assessed within 90 days, Tier 2 and Tier 3 within 180 days — is defensible if documented in your supply chain security policy.

If our RMM vendor is ISO 27001 certified, does that satisfy Art.21(3)?

ISO 27001 certification supports Art.21(3) compliance but does not automatically satisfy it. The standard’s Annex A.5.19 addresses supplier relationship security — but the certificate does not confirm whether critical CVEs are disclosed promptly, whether multi-tenancy isolation meets your specific risk threshold, or whether the agent privilege model follows least privilege. Art.21(3) is explicit: assess “vulnerabilities specific to each direct supplier.” Use the certificate as evidence of a security baseline, then layer the specific technical questions from Step 3 above.

Key Takeaways

• RMM tools are Art.21(2)(d)’s highest-risk supply chain vector for managed-service environments — they combine full endpoint access with a multi-client blast radius proven by the Kaseya VSA attack.
• PSA and NOC tools pose distinct but lower-tier risks: business process exposure for PSA, detection blind-spot risk for NOC platforms.
• Art.21(3) extends your assessment obligation beyond the direct vendor to their sub-processors and cloud hosting layer.
• A defensible Art.21(2)(d) posture requires a named supplier inventory, a documented risk-tier assessment for each tool vendor, contractual security clauses aligned to Art.23 notification timelines, and a quarterly review cadence.

This article provides general information only and does not constitute legal or regulatory advice. Requirements may vary by jurisdiction and organisation type. Consult a qualified legal professional or compliance specialist for advice specific to your situation.

Sources

1. Article 21, NIS2 Directive (EU) 2022/2555 — nis-2-directive.com
2. Article 6, NIS2 Directive (EU) 2022/2555 — nis-2-directive.com
3. Kaseya VSA ransomware attack — Wikipedia
4. The Kaseya VSA REvil Ransomware Supply Chain Attack — AttackIQ
5. CIR 2024/2690 — NIS2 Technical Measures — nisd2.eu
6. Threat Landscape for Supply Chain Attacks — ENISA
7. NIS2 Compliance for MSPs: Build a Service Line Around the EU Directive — GetCybr
8. Cybersecurity for MSP Internal Tools in 2025 — AI Cyber Experts