When your MSP's tools are the risk: managed service provider and RMM trust

Why this needs its own page. An MSP delivers or manages IT services for customers under a contract, and that work usually needs trusted network connections and privileged access into customer systems. The 2022 joint advisory from the cyber agencies of the UK, Australia (ACSC), Canada, New Zealand and the United States warns that a vulnerable MSP can be used as an initial access route into many customer networks at once, and that compromising one MSP can lead to ransomware or espionage across its whole customer base. RMM platforms concentrate that access: one console, one set of agents, many customers.

What the agencies ask for (AA22-131A)

The advisory frames each control as something the MSP should do and something the customer should require in the contract. In summary:

Prevent initial compromise. Attackers go after vulnerable devices and internet-facing services, brute-force logins and phish staff, so both sides should harden internet-facing systems, including the management platform itself.

Logging. The agencies recommend keeping the most important logs for at least six months, because intrusions can take months to detect. Customers who outsource monitoring should require visibility of the MSP's own presence, activity and connections in their network, and notification of confirmed or suspected incidents on the MSP's infrastructure.

MFA. MSPs should enforce MFA on every account that can reach customer environments and treat those accounts as privileged; customers should make that a contract term.

Segregation. MSPs should keep customer data and services separate from each other and from the MSP's own network, and must not reuse admin credentials across customers. Customers should route MSP traffic through one dedicated secure connection and keep the networks used for that trust relationship segregated from the rest.

Least privilege and account hygiene. Use tiered admin accounts, avoid standing full privileges, and give MSP accounts access only to what the MSP manages. Disable MSP accounts that no longer manage anything; the advisory notes this is easy to miss when a contract ends.

Updates, backups and plans. Prioritise known exploited vulnerabilities over high CVSS scores alone; keep tested, isolated (offline or separately keyed) backups; and keep incident response and recovery plans, with hard copies, that name roles for executives, technical leads and procurement.

When the RMM platform itself is the problem

A flaw or breach in the RMM product turns the trusted channel into the attack path. A recent case on this desk: on 9 November 2026 N-able took its hosted N-central environments offline and told on-premises customers to take their servers offline after a researcher published working exploits for more than 30 unpatched N-central flaws (see the N-able card for the current status). Desk checklist for that day, as practitioner steps rather than agency text:

1. Ask your MSP, in writing, which RMM and remote-access tools touch your environment and whether any are affected. Keep the answer with the incident record.

2. Follow the vendor's instruction (for example taking servers offline) even if it costs service, and agree with the MSP how urgent work will be done without the platform.

3. On your side, look for what an attacker with RMM admin would do: new local or domain admin accounts, new scheduled tasks or services, scripts pushed by the agent, remote sessions outside change windows, and changes to security tools. Check the RMM's own audit trail too, remembering a platform flaw may let an attacker alter it.

4. Before the platform comes back, require the patched version, rotated credentials held in the platform (including any customer passwords or API keys it stores), and confirmation that admin accounts were reviewed.

5. If personal information may have been reached through the MSP, start your own data breach assessment; the provider's statement does not answer your obligations for you.

Practitioner checklist

Can you list today every MSP account and agent in your network, what each can reach, and who at the MSP can use it? Does your contract require MFA, no shared admin credentials, log visibility, incident notification and offboarding of MSP access? If not, fix those before the next RMM advisory, not during it.