Cybersecurity for MSPs and MSSPs Guide: Threats, Regulation and Priority Controls

A managed service provider holds standing administrative access to dozens or hundreds of customer environments, so one compromised technician account, RMM server or delegated admin relationship can become a breach of every customer at once. Attackers know this: state actors and ransomware crews have both targeted MSPs as a route to their customers, and regulators in the EU and UK now treat managed service and managed security service providers as regulated entities in their own right. This guide covers the MSP and MSSP threat picture, the regulation that now applies, the controls that differ from a normal enterprise programme, and how to measure them. It is written for MSP and MSSP security, operations and service leads, and for the customer security teams who assess them.

Key takeaways

• Your blast radius is your customer list. Treat the provider estate (RMM, PSA, documentation platform, delegated admin, technician identities) as tier zero for every customer, not as internal IT.
• Remote access tooling is the main target. Kaseya VSA in 2021 and ScreenConnect in 2024 show that an internet-facing management server with a known exploited flaw becomes a mass deployment channel within hours.
• Identity is the control plane. Phishing-resistant MFA for technicians, per-customer least-privilege roles (GDAP in Microsoft 365), just-in-time elevation and no shared credentials matter more than any perimeter control.
• Regulation has arrived. NIS2 names MSPs and MSSPs explicitly, and the UK Cyber Security and Resilience Bill would bring "relevant managed service providers" under the Information Commission with 24 hour incident notices and customer notification duties.
• Customers must be able to switch you off. Design every access path so a customer, or your own incident team, can disable it quickly without losing the ability to run the estate.

Why MSPs and MSSPs are a distinct risk

An MSP runs IT on behalf of customers under contract: device management, patching, Microsoft 365 and cloud administration, backup and the service desk. An MSSP runs security services such as a SOC, managed detection and response, vulnerability scanning and incident response. The two models often overlap in one company. What makes both distinct is aggregation: a small number of technician identities and automation accounts hold privileged access to many independent organisations, through tools designed to run code everywhere at once.

• One-to-many access: Microsoft described NOBELIUM's 2021 campaign against cloud and managed service providers as a "compromise-one-to-compromise-many" approach. The attackers abused delegated administrative privileges that had often never been audited or removed, and in one case chained access across four providers before reaching the target.
• Tools built for mass execution: RMM platforms push scripts and software to every enrolled endpoint by design. ATT&CK tracks this as T1072 Software Deployment Tools, and abuse of legitimate remote access software as T1219 Remote Access Tools.
• Trusted by default: Provider activity in a customer tenant looks like routine support, so it rarely triggers alerts. ATT&CK T1199 Trusted Relationship describes exactly this initial access path.
• Thin margins, small teams: Many MSPs have a handful of engineers who also run their own internal IT, which makes separation of duties and 24x7 monitoring of the provider estate hard.
• MSSPs hold the keys to the alarm: An MSSP with EDR consoles, SIEM admin rights and incident response access can, if compromised, blind the customer as well as attack it. NIS2 recital 86 notes the particular role MSSPs play in incident response and penetration testing, and asks regulated entities to choose them with care.

Threat picture: how providers are attacked

The table maps the recurring attack paths against providers to ATT&CK v20 techniques and the first control to check. Each has real precedent.

Regulation that now reaches providers

Until recently most MSP obligations were contractual. That has changed. The rules below apply to the provider directly, or reach it through regulated customers. Confirm the current national position before relying on any date: NIS2 transposition varies by Member State and the UK Bill was still before Parliament at the time of writing.

The practical consequence: an MSP serving EU or UK customers needs an incident classification and notification process of its own, not only a process for helping customers notify. Map each regime's clock into one severity model so a single significant incident triggers every relevant notice, including the customer notifications the UK Bill would require.

Priority controls for the provider estate

These controls differ from a general enterprise baseline because they protect the shared tooling and identities that touch every customer. Implement them in the order shown.

Technician identity and privilege

• Phishing-resistant MFA everywhere: FIDO2 security keys or platform passkeys for every technician on RMM, PSA, documentation platform, partner portals and customer tenants. No SMS or voice, no exclusions. See the Phishing-Resistant MFA Guide.
• Per-customer least privilege: In Microsoft 365, Granular Delegated Admin Privileges (GDAP) replace blanket Global Administrator with time-bound, role-scoped access that the customer explicitly grants, assigned through security groups (Microsoft documents a limit of 100 security groups per customer). Remove legacy DAP and unused relationships. See the GDAP and MSP Delegated Admin Access Guide.
• Just-in-time elevation: Standing rights only for read and ticket work; elevate to admin roles per ticket with approval and expiry. See the JIT Access Guide.
• Separate admin identities: Technicians use a dedicated admin account from a hardened admin workstation, never their email identity, and never shared "msp-admin" accounts in customer tenants.
• Help desk verification: Password and MFA resets for technicians and for customer users require out-of-band confirmation through a known contact. See the Account Recovery and Help Desk Security Guide.

RMM, remote support and automation

• Prefer vendor-hosted or proxied consoles: Kaseya stated that only on-premises VSA servers were vulnerable in 2021 and its SaaS platform was not. If you self-host, put the console behind a VPN or identity-aware proxy and restrict source IPs.
• One sanctioned remote tool per purpose: Every extra remote support product is another internet-facing attack surface and another channel attackers can install. Block unsanctioned remote access tools at customer endpoints. See the RMM Tool Security Guide.
• Script governance: Require peer review and signing for scripts in the RMM library; restrict who can run scripts across all customers versus one customer; alert on any "run on all sites" job.
• Emergency patch drill: When a KEV-listed flaw lands in your tooling, the ScreenConnect bulletin's sequence is a good template: upgrade, check for compromise before bringing servers back online, review and remove unrecognised users, rotate passwords, enable MFA, validate extensions.

Machine identities and secrets

• Automation accounts: PSA to RMM integrations, backup service principals, Partner Center API apps and SIEM collectors are non-human identities with cross-customer reach. Give each its own credential per customer where the platform allows, store secrets in a vault, rotate on staff exit and after any incident. Microsoft's Secure Application Model is the documented pattern for partner API integrations.
• Customer credentials you hold: Segment the documentation or password vault per customer, log every reveal, and alert on bulk export. See the Secrets Management Guide.

Backups and recovery

• Isolate backup administration: Backup consoles must not share identities with the RMM or the customer domain, so a ransomware actor holding RMM cannot also delete restore points. See the Backup Identity Isolation Guide.
• Immutable copies: Keep at least one immutable or offline copy per customer and test restores quarterly.

Additional controls for MSSPs

An MSSP inherits every MSP risk and adds the risk of blinding its customers. Its tooling sits inside the detection chain.

• Protect the SOC platform as tier zero: SIEM, SOAR and EDR management consoles need the same phishing-resistant MFA, admin workstation and JIT controls as domain administration. A SOAR playbook that can isolate hosts or disable users is a powerful attack tool.
• Tenant isolation in multi-tenant SIEM and EDR: Verify that analysts can only see and act on the customers they are assigned to, and that customer data cannot leak across tenants in searches, dashboards or exports.
• Change control on detections and exclusions: An attacker who can add an EDR exclusion or disable a detection rule can operate unseen. Log and review every exclusion. See the EDR Tuning and Exclusions Management Guide.
• Response authority agreed in advance: Document which containment actions the MSSP may take without asking, which need customer approval, and who the customer's decision maker is out of hours. See the Co-Managed SOC and SOC-as-a-Service Guide and the MDR Guide.
• Testing staff: Penetration testers hold customer credentials, findings and sometimes implants. Destroy test credentials and artefacts at engagement close and record it.

Phased implementation for a provider

1. Inventory (weeks 1 to 4): List every access path into every customer: RMM agents, remote support tools, GDAP and DAP relationships, Azure Lighthouse delegations, VPN accounts, local admin accounts, API apps and stored credentials. Record owner, customer, privilege and last use.
2. Remove the obvious (weeks 2 to 6): Delete unused delegated admin relationships and dormant technician accounts, remove legacy remote tools, take self-hosted consoles off the open internet.
3. Harden identity (weeks 4 to 12): Enforce phishing-resistant MFA for all technicians, starting with the RMM and partner portals. Pilot with one team, then switch off weaker methods. Keep two break-glass accounts per platform, stored offline, so a misconfigured policy can be rolled back. See the Break-Glass Account Guide.
4. Least privilege and JIT (months 3 to 6): Move customers onto role templates by service tier, migrate standing admin to approval-based elevation, and test with a pilot group of customers before rolling out.
5. Monitoring (months 3 to 6): Ship RMM, PSA, vault, partner portal and identity logs to a SIEM that the technicians cannot administer. Agree with customers which of their logs you can see.
6. Exercise (every year): Run a scenario where your RMM is compromised. Prove you can disable mass script execution, revoke all technician sessions and notify customers inside your contractual and regulatory clocks. Customers can use the Compromised MSP Playbook for their side.

Decision guidance

Small providers (under about 20 staff) should concentrate on phishing-resistant MFA, vendor-hosted tooling, removing unused access, immutable backups and a contracted MDR service. Large providers should add per-tier role templates automated through APIs, a separate security team for the provider estate, independent assurance such as SOC 2 Type II or ISO/IEC 27001 certification covering the managed service, and segmented infrastructure for regulated customers.

Detection and measurement

Monitor the provider estate itself, not only customer environments.

• Partner sign-ins: In Microsoft Entra, customers can filter non-interactive sign-ins by cross-tenant access type "Service provider" to see partner activity; providers should review the Partner Center activity log for new high-privilege users and role assignments.
• RMM events: new technician accounts, MFA changes, scripts run against all sites, new or modified scripts, agent deployment to unexpected sites, logins from new countries or hosting providers.
• Vault events: bulk reveals or exports, access to customers outside the technician's assignment.
• Remote tool sprawl: remote access software appearing on customer endpoints that is not the sanctioned tool.

Framework mapping

For the customer's assessment of providers, CIS Safeguard 15.1 (inventory of service providers) is IG1, and 15.4 (security requirements in contracts) and 15.7 (secure decommissioning, including deactivating user and service accounts) follow in IG2 and IG3. See the CIS Control 15 Service Provider Management Guide.

Common failure patterns

• Technicians exempted from Conditional Access: "We need to log in from anywhere" leads to provider accounts being the weakest identities in every customer tenant, which is exactly what NOBELIUM exploited.
• Access that outlives the contract: delegated admin relationships, local admin accounts and RMM agents left in place after a customer leaves. Microsoft found many delegated privileges were never audited or removed.
• Help desk as the bypass: strong MFA undone by a reset over the phone. The Marks and Spencer cyberattack started with impersonation through a third-party path.
• Self-hosted consoles left exposed: on-premises VSA, ScreenConnect and SimpleHelp servers were exploited because they were reachable and unpatched, and each flaw is now in the KEV catalogue with known ransomware use.
• Backups administered from the same identities as production: the attacker who owns the RMM deletes the restore points before encrypting.
• Notification plans that only cover the customer's duty: providers in NIS2 scope, and RMSPs under the UK Bill if enacted, have their own reporting and customer notification clocks.

Practitioner checklist

• Maintain a live inventory of every access path into every customer, with owner, privilege and last use.
• Enforce phishing-resistant MFA for all technicians on RMM, PSA, vault, partner portals and customer tenants, with no exclusions.
• Replace Global Administrator and legacy DAP with GDAP role templates and JIT elevation.
• Take self-hosted management consoles off the internet and patch KEV-listed flaws in provider tooling within 72 hours.
• Restrict "run on all customers" automation to a small approved group and alert on every use.
• Segment stored customer credentials per customer and alert on bulk export.
• Isolate backup administration from RMM and customer domain identities, and keep immutable copies.
• Map NIS2, the UK Bill and DORA customer clauses into one incident severity and notification process, including customer notification.
• Exercise an RMM compromise scenario every year with at least one customer.
• Remove all access, agents and accounts at contract end, and confirm it to the customer in writing.

Standards and references

• EUR-Lex: Directive (EU) 2022/2555 (NIS2)
• UK Parliament: Cyber Security and Resilience (Network and Information Systems) Bill
• GOV.UK: Cyber Security and Resilience Bill factsheets
• CIS: Control 15 Service Provider Management
• Microsoft Learn: Introduction to granular delegated admin privileges (GDAP)
• Microsoft Security: NOBELIUM targeting delegated administrative privileges to facilitate broader attacks
• ConnectWise: ScreenConnect 23.9.8 security bulletin
• CISA: Known Exploited Vulnerabilities Catalog

Related NHI Mgmt Group resources: Compromised MSP Playbook · GDAP and MSP Delegated Admin Access Guide · RMM Tool Security Guide · Third-Party Access Guide · Third-Party Risk Management Guide. This guide summarises NIS2, the UK Cyber Security and Resilience Bill and DORA as they affect managed service providers and is not legal advice.