Compromised MSP Playbook: Responding When Your Managed Service Provider Is Breached

When a managed service provider is breached, the attacker inherits the provider's access to [Organisation]: its remote management agents, its delegated admin roles, its VPN accounts and every password it stored on your behalf. MSP access is trusted by design, so attacker activity through it looks like routine support and rarely raises an alert. This playbook template covers the customer side of an MSP compromise: deciding whether [Organisation] is affected, cutting or restricting each provider access path without losing the ability to run the estate, hunting for misuse, rotating the credentials the provider held, and meeting contract and notification duties. It is written for security operations, IT operations, third-party risk and legal teams, with decision points for the executive who owns the provider relationship. Replace every [Organisation] and [MSP] placeholder before adoption.

How to use this template

• Adopt it as a sub-playbook of [Organisation]'s incident response plan. See the Incident Response Plan Template.
• Build the access register now, not during the incident. Section 2.2 lists every path [MSP] has into [Organisation]. Without it, containment becomes guesswork.
• Decision points are marked D1 to D5. Record each decision, who made it, when and on what evidence.
• Use the companion playbooks: the Vendor SaaS Breach Response Playbook for SaaS integrations, the Ransomware Playbook Template if encryption starts, and the Supply Chain Compromise Response Playbook if [MSP] pushed malicious software.
• Test it yearly with [MSP] in the room, including a drill that actually disables one access path.

1. Scope and triggers

1.1 This playbook applies when [Organisation] has reason to believe that a managed service provider, managed security service provider, cloud solution provider or outsourced service desk with administrative access to [Organisation] systems has been compromised, or that its access is being misused.

1.2 Triggers:

• Provider notice: [MSP] reports an incident, or stops responding during a known incident.
• Advisory: a government advisory, the RMM vendor or threat intelligence names [MSP], its RMM platform or a vulnerability in it.
• Internal detection: RMM scripts run outside change windows, partner sign-ins at odd hours or from new locations, new admin accounts created by provider identities, or an unknown remote access tool on hosts.
• Peer report: another customer of [MSP] reports an attack.

1.3 ATT&CK models the path as T1199 Trusted Relationship, often followed by T1219 Remote Access Tools, T1072 Software Deployment Tools, T1133 External Remote Services and T1078.004 Cloud Accounts.

2. Roles and contacts

2.1 If [MSP] runs [Organisation]'s service desk, SOC or email, assume those channels are untrusted. Use the out-of-band contact sheet: insurer [number], IR retainer [number], RMM vendor support [number], Microsoft or cloud support [plan and number].

2.2 MSP access register (maintain quarterly):

See the GDAP and MSP Delegated Admin Access Guide and the RMM Tool Security Guide.

3. Detection and triage

1. Get facts from [MSP] (Supplier relationship owner, within [1] hour). Ask: what was compromised (RMM, PSA, password vault, technician accounts, partner tenant), when, which customers, what the provider has already disabled, and whether its logs are preserved. Record answers and who gave them.
2. Pull [Organisation]'s own logs (Security analyst). In Microsoft Entra sign-in logs, filter on cross-tenant access type "Service provider" to see partner sign-ins. Review audit logs for role assignments, new privileged users, Conditional Access and authentication method changes made by partner identities.
3. Check the RMM side: script and job history, new endpoints enrolled, technician logins to the console, and agents bound to an unexpected console tenant.
4. Check network paths: VPN logins by provider accounts, firewall sessions from provider IP ranges, new port forwards.
5. D1: Severity (Incident lead). Critical: confirmed attacker activity in [Organisation] through [MSP] access, or RMM scripts executed by the attacker. High: [MSP] confirmed compromise of systems holding [Organisation] access, no activity seen yet. Medium: [MSP] incident with no link to customer access paths.

4. Containment

4.1 D2: Cut or restrict? (Executive sponsor on advice from Incident lead).

1. RMM first: block the RMM console and relay domains at the firewall and proxy, then disable the agent service through EDR or group policy. Do not uninstall agents until evidence is collected.
2. Delegated admin: remove GDAP roles or terminate the relationship, remove Azure Lighthouse delegations, disable guest and named provider accounts, revoke their sessions. Confirm [Organisation] still holds working break-glass accounts first. See the Break-Glass Account Guide.
3. Network: disable provider VPN profiles and certificates and deny provider IP ranges.
4. Cloud: deactivate access keys and remove role trust relationships used by the provider.
5. Protect backups: remove provider admins from backup consoles and confirm immutability and retention settings have not been changed.

Evidence to preserve before removal: RMM job and session history export, agent configuration and console tenant ID, partner relationship details with roles and dates, sign-in and audit logs, VPN logs, and written statements from [MSP]. Ask [MSP] in writing to preserve its own logs for [Organisation]. See the Digital Forensics (DFIR) Guide.

5. Eradication

1. Rotate everything [MSP] held or could read. This includes domain and local admin passwords, service account passwords, cloud access keys, API keys, firewall and switch credentials, Wi-Fi keys, backup encryption keys and certificates. Prioritise tier 0 and internet-facing systems.
2. Treat non-human identities as first-class. Service accounts and API keys stored in the provider's documentation platform or scripts often outlive the incident unless listed. See the Secrets Rotation Runbook Template.
3. Hunt for persistence: new local or directory accounts, scheduled tasks, additional remote tools, new OAuth apps and mail forwarding.
4. Reimage hosts where the attacker ran scripts through RMM, as for any compromised endpoint.
5. D3: Eradication complete? (Incident lead) when rotations are confirmed and no attacker activity has been seen since containment.

6. Recovery

1. D4: Restore [MSP] access? (Executive sponsor). Only after [MSP] provides a root cause, evidence of its own clean-up and an independent assessment where severity was critical.
2. Rebuild access with least privilege: new GDAP relationship with task-based roles and an end date, no Global Administrator by default, named technicians with phishing-resistant MFA.
3. Re-enrol RMM agents to a verified console tenant with script approval for actions on many devices.
4. Monitor partner activity closely for [60] days and review weekly with [MSP].
5. D5: Continue, renegotiate or exit the relationship, decided by the Executive sponsor with procurement.

7. Communication and notification

7.1 Expect social engineering. Attackers who know [MSP] support processes may phone staff or the service desk posing as technicians. In the Marks and Spencer cyberattack, impersonation through a third-party IT help desk path led to ransomware and data theft. Require call-back to a known number for any provider request during the incident.

8. Post-incident review

1. Hold the review within [15] working days, with [MSP] for the shared part and without it for the contractual part.
2. Build the timeline: provider compromise, first activity in [Organisation], detection, containment of each path, rotation complete.
3. Compare the access register to what was actually found; add any missing path.
4. Update contract terms and the Third-Party Access Policy Template as needed.

Implementation guidance

• Write the playbook into the contract: provider incident notification within [24] hours, log retention of at least [six months] accessible to [Organisation], MFA for every technician, no shared admin credentials across customers, the right to suspend access, and agent removal and key revocation at exit. CSF 2.0 GV.SC-08 and GV.SC-10 cover incident inclusion and post-relationship provisions. See the Third-Party Access Guide.
• Never depend on the provider for your own way in: keep [Organisation]-owned break-glass accounts, a copy of network and firewall credentials, and an internal list of where every agent runs.
• Monitor provider activity continuously (CSF DE.CM-06): alert on partner role grants, RMM scripts outside change windows and new remote tools.
• Small organisations often have one MSP running everything. Keep a printed sheet with the break-glass account location, the RMM block steps and a standby provider's number.
• Large organisations should tier providers by access, run this playbook as a tabletop with each tier 1 provider, and automate the RMM block and GDAP role removal as approved runbooks.

References: MITRE ATT&CK: Trusted Relationship · MITRE ATT&CK: Software Deployment Tools · Microsoft: GDAP frequently asked questions · Microsoft: Introduction to GDAP · NIST: Cybersecurity Framework 2.0 · NIST: SP 800-53 Rev. 5

This template is provided for guidance and must be adapted to your organisation. It is not legal advice. Related NHI Mgmt Group resources: GDAP and MSP Delegated Admin Access Guide · RMM Tool Security Guide · Third-Party Access Guide · Vendor SaaS Breach Response Playbook · Third-Party Risk Management Guide