In a recent r/MSP discussion, an incoming provider reported discovering malware on its first night managing a client. The previous provider’s security tools had been installed, but why the threat went undetected remained unclear.
During a transition, you inherit both the environment and its unknowns. Use the first day of the transition to verify protection, secure administrative access, check recovery options, and investigate urgent risks.
Key Takeaways
During an MSP-to-MSP client transition:
- Check for existing threats and gaps in protection during the transition.
- Assign responsibility for monitoring and responding to alerts throughout the handover.
- Remove the former provider’s access and rotate shared credentials.
- Test recovery before the outgoing backup service ends.
- Preserve evidence early and assign owners and deadlines to unresolved issues.
1. Establish What You’re Taking Over
Start with the technical handover in your client onboarding checklist. Agree on the cutover time and identify who monitors alerts before, during, and after it.
Reconcile the inventory
Compare the supplied device list and network documentation with what your tools discover. Prioritize servers, identity systems, cloud tenants, perimeter devices, and business-critical applications.
Request the security history
Collect unresolved alerts, recent incidents, approved exclusions, and documented recommendations the client declined. Verify what services were actually purchased.
Name the decision-makers
Confirm the technical incident lead, client contact, and authority to isolate systems or interrupt services.
Export available security logs and configurations before removing tools or losing access to the outgoing provider’s consoles. Record missing information as an open risk.
2. Verify Protection During the Tool Change
Coordinate removal and deployment according to both vendors’ migration guidance. Running overlapping endpoint protection tools without a supported coexistence configuration can create conflicts; removing the outgoing protection too early can leave devices exposed.
For each migrated device, verify:
- The replacement agent checks into the correct tenant and receives the intended policy.
- Protection is enabled, exclusions are justified, and required updates or restarts are complete.
- Alerts reach the responsible team, including outside business hours.
- Automatic response settings and analyst responsibilities are understood.
Reconcile the results against your inventory. Give offline devices and failed installations an owner and follow-up deadline.
An installation report alone does not establish working endpoint security monitoring. Use a vendor-supported test to verify the alert path.
3. Secure Administrative and Remote Access
From a trusted administrative device, verify your team’s named accounts, appropriate permissions, and MFA before retiring the old access paths. Confirm that the client retains administrative ownership of its identity tenant, domains, DNS, cloud subscriptions, and other critical services rather than relying on accounts controlled solely by the outgoing provider. Apply privileged access management principles from the start.
At the agreed cutover:
- Disable former provider accounts and remove delegated cloud administration rights.
- Revoke applicable sessions, tokens, VPN access, and obsolete remote-support integrations.
- Rotate shared privileged passwords and relevant API keys or service secrets known to the outgoing provider.
- Remove former RMM and remote-access agents once replacement management is verified.
Check service dependencies before changing credentials used by backup jobs, applications, or scheduled tasks. Store replacements in your controlled password management system.
Reconcile these actions with the outgoing provider’s offboarding checklist so temporary access does not remain indefinitely.
4. Check for Inherited Compromise and Urgent Exposure
Begin a focused IT security assessment with unresolved alerts and the systems that carry the greatest operational risk.
Review available endpoint, identity, VPN, and firewall logs. Investigate unexpected privileged accounts, suspicious sign-ins, unexplained remote-access software, and persistence mechanisms such as unfamiliar services or scheduled tasks.
When you identify credible indicators of compromise, search for them across other endpoints and relevant logs. A detection on one workstation does not establish the incident’s full scope.
Also check internet-facing VPNs, RDP exposure, and management interfaces. In your patch management process, prioritize security flaws attackers are already exploiting, especially on internet-facing systems, along with perimeter devices that no longer receive security updates. Where an immediate fix is impractical, agree on temporary access restrictions and a remediation deadline.
If You Find an Active Threat
Activate the incident response process immediately. Contain affected systems, engage the incident lead, and notify the client. Follow applicable contractual, insurance, legal, and regulatory notification requirements. Preserve relevant logs and forensic evidence before wiping or rebuilding, without delaying urgent containment.
Investigate potentially exposed identities, revoke compromised sessions, and reset affected credentials from a trusted system. A quarantined file does not establish that persistence, stolen credentials, or access to other systems has been addressed.
Coordinate contact with the former MSP through the client. Request specific evidence – hashes, paths, timestamps, and matching telemetry – and keep conclusions tied to verified facts.
5. Confirm That Recovery Survives the Handover
Before the outgoing backup service ends, verify access to backup consoles, repositories, encryption keys, and historical restore points. Identify licenses, storage accounts, and retention arrangements that depend on the former MSP.
Check recent job results against critical workloads, then perform a representative restore test in an isolated location. Record what you restored, whether it was usable, and how long recovery took. A successful file restore does not validate full application recovery.
Review access controls protecting backup storage, and verify any claimed immutable or offline copies. Agree on historical backup retention before the former provider deletes anything.
6. Record the Evidence and Assign the Remaining Work
Maintain a transition timeline with consistent timestamps: access changes, agent removals and installations, first detections, and response actions. Store exported logs securely and record gaps in their coverage.
Give the client a concise, readable day-one report covering verified protection, unresolved alerts, unmonitored devices, recovery test results, and outstanding access changes. Every unresolved item needs an owner, deadline, and any temporary safeguard.
Final Thoughts on Security Risks during MSP-to-MSP Client transitions
By the end of the first day, you should know what you control, what you can monitor and restore, and what still needs investigation. Over the next few days, follow up on devices that were offline, review any logs received after the handover, and work through unresolved findings. Keep the client informed about the risks that remain and the steps you’re taking to address them.
