MSP and RMM Security Testing in 2026: Why Supply Chain VAPT Is Now Non-Negotiable for Indian Businesses

The CVE-2026-18577 exploitation campaign — in which attackers bypassed authentication on N-able N-central servers, gained administrative access to managed service provider infrastructure, and installed persistent Cloudflare tunnels on downstream client endpoints — is not just a patching story. It is a case study in why the traditional definition of "your attack surface" is dangerously incomplete.

Most organisations test the applications and infrastructure they directly control: their web apps, their internal network, their cloud environments. Few test the security of the managed service providers and remote monitoring platforms that have privileged access to those same environments from the outside. That gap is exactly what sophisticated attackers are now exploiting at scale.

In 2026, a robust VAPT programme cannot stop at your perimeter. It has to follow the trust relationships that actually govern access to your systems.

The MSP Trust Problem

When an organisation engages a managed service provider, it typically grants that MSP elevated access across its environment — domain admin credentials for Active Directory, agent software installed on every endpoint, firewall rules that allow the MSP's RMM platform to connect inbound. This access is necessary for the MSP to do its job. It is also a standing invitation for any attacker who can compromise the MSP.

According to data from multiple threat intelligence providers, attacks routed through compromised MSPs and RMM platforms increased over 400% between 2022 and 2025. The economics are straightforward: one compromised RMM server yields access to every downstream client. Ransomware operators, nation-state groups, and financially motivated attackers all share the same rational preference for high-leverage access paths.

The N-able N-central exploit chain followed this exact model. Attackers bypassed authentication on N-central, gained administrative control of the RMM platform, pushed Cloudflare tunnel binaries to managed endpoints, and established persistence that survived the eventual detection and remediation of the initial N-central compromise. The downstream clients — who may have had excellent internal security controls — were compromised because their MSP was compromised.

What MSP and RMM Security Testing Must Cover

Extending VAPT scope to cover supply chain and MSP relationships requires testing in three distinct areas.

MSP Access Review and Privilege Audit: The first step is understanding exactly what access your MSP has to your environment, and whether that access is proportionate to the services being delivered. This is not technical testing — it is a structured access review. What credentials does the MSP hold? Are they rotated on a schedule? Are they scoped to the minimum privilege required? Is the MSP's access logged in your SIEM, or only in the MSP's own tooling (which you do not control)?

Most organisations that go through this review find at least one credential set that is either over-privileged, stale (tied to an employee who left the MSP months ago), or unmonitored. Each of these is a live attack path.

RMM Agent and Management Plane Testing: The RMM agents installed on your endpoints create management channels that, by design, can execute arbitrary commands with administrative privileges. A security tester should validate that those agents are running the latest patched version, that their management console traffic is authenticated and encrypted, that access to the management console is protected by multi-factor authentication, and that there is no path for an unauthenticated actor to issue commands to agents through the management plane.

This testing should also include verification that your endpoints would detect and alert on unexpected command execution originating from the RMM agent — because in a compromise scenario, the attacker's payloads arrive through a trusted channel.

Third-Party Access Segmentation Testing: Penetration testing should verify that your MSP's access cannot be used as a pivot into segments of your network that the MSP has no legitimate reason to reach. If an MSP has RMM agent access to your Windows workstations but not your payment processing servers, a tester should verify that the workstation segment genuinely cannot reach the payment segment. The combination of lateral movement and MSP-originated trust is exactly the technique that the Kaseya VSA and N-able exploits demonstrated could deliver ransomware to air-gapped-looking segments.

DPDPA Implications for Indian Data Fiduciaries

Under India's Digital Personal Data Protection Act, Data Fiduciaries are responsible for how their data processors handle personal data — and the DPDPA's definition of "processor" extends to anyone who processes personal data on the Fiduciary's behalf. MSPs that have access to systems containing personal data — which in practice means most MSPs serving Indian businesses — are data processors under the Act.

This creates a legal obligation that has direct security implications. If your MSP suffers a breach and personal data is compromised as a result, you — the Data Fiduciary — bear the notification obligation to the Data Protection Board of India and to affected data principals. The fine falls on you, not on the MSP, unless your contracts and oversight programme can demonstrate that you fulfilled your due diligence obligations.

The DPDP Rules require that processor agreements contain specific data protection obligations. But a compliant contract is not sufficient on its own: the DPBI is expected to scrutinise whether Data Fiduciaries conducted any actual oversight of their processors' security practices. An annual security questionnaire with no independent verification will not satisfy this standard.

What will satisfy it? Independent security assessment of the MSP's environment — or at minimum, a review of the MSP's own recent penetration testing reports from a CERT-In-empanelled firm, combined with a review of their incident response procedures and breach history.

The PTaaS Model for Continuous Supply Chain Coverage

Point-in-time VAPT has a well-known limitation: it tests a snapshot. The moment a new RMM agent version is deployed, a new MSP employee is granted access, or a firewall rule is changed to accommodate a new management tool, the snapshot is outdated. For the specific risk of MSP and supply chain compromise — where the attack surface changes every time the MSP makes a change on your behalf — continuous testing is the only model that provides real assurance.

Penetration Testing as a Service (PTaaS) platforms address this by running continuous automated scanning against your environment's externally visible attack surface, combined with scheduled human-led assessments of higher-complexity attack paths like MSP trust relationships and RMM agent security. The PTaaS market is growing at 22.6% CAGR and is projected to reach $1.98 billion by 2031, driven precisely by the recognition that annual assessments cannot keep pace with the speed at which environments — and their supply chains — change.

Alastor Pulse delivers first critical findings in under six hours, with continuous attack surface monitoring that covers your entire perimeter including third-party access points. For Indian organisations who need to demonstrate DPDPA-compliant processor oversight alongside technical security assurance, a combined PTaaS and processor security review programme is the most efficient path to both.

Practical Steps to Take This Week

The N-able N-central incident is a concrete, current example of what happens when MSP security is not treated as part of the principal's attack surface. There are four immediate actions every Indian business with an MSP relationship should take:

First, confirm that your MSP has patched to N-central 2026.3.1.7 if they use N-able, or confirmed their RMM platform is on a current, patched version. Do not accept "we handle that" as an answer without documentation. Second, request a copy of your MSP's most recent penetration test report — specifically one that covers their RMM platform and management infrastructure. Third, run an access audit: document every credential, service account, and API key your MSP holds in your environment, verify each is still active and necessary, and rotate any that are older than your standard rotation period. Fourth, verify that your SIEM or endpoint detection tooling is logging commands executed via RMM agents, so you would detect exploitation even if it originates through a trusted channel.

If you need help scoping a supply chain VAPT engagement or reviewing your MSP security programme against DPDPA processor oversight requirements, reach out to the Alastor InfoSec team or visit Alastor Pulse to see how continuous testing covers your full attack surface, including third-party access paths.

The attack surface has expanded beyond your perimeter — in 2026, effective VAPT means testing the trust relationships that govern who can reach your systems, not just the systems themselves.