It happened on the first night.
An MDR team had just onboarded a new client — a small business that had recently switched IT providers. Within hours, they detected an active threat on one of the client's machines. The culprit? A remote access tool left behind by the previous MSP. It was still running. Still listening. And someone else had noticed.
This isn't a horror story from a decade ago. It's the kind of incident being shared right now in IT and security communities, and it illustrates something most small business owners never consider when they switch IT providers: the handoff window is one of the most dangerous moments in your security posture.
Why the Transition Window Is So Dangerous
When you part ways with an IT provider, the focus is almost always on the business side — contracts, data migration, new onboarding. Security hygiene rarely makes the checklist. That gap is exactly what attackers exploit.
According to The Hacker News, CrowdStrike data shows approximately 79% of modern attacks are now malware-free, relying instead on legitimate tools and living-off-the-land techniques to move through networks undetected. That means the remote monitoring agent your old MSP installed — the one that's still running on six endpoints — doesn't look like malware to your antivirus. It looks like normal software. Because it is. Until it isn't.
And ransomware groups are paying attention. The Hacker News reported that Qilin ransomware actors are actively exploiting authentication and access control gaps for initial access — precisely the kind of vulnerability created when old VPN configurations, remote access credentials, and MSP tooling go unreviewed during a provider switch.
7 Security Risks Your Old MSP May Have Left Behind
1. Remote Monitoring and Management (RMM) Agents Still Running
Every MSP deploys RMM software to manage your endpoints. When they leave, those agents often stay. If the previous provider's platform is still active — or if a threat actor has already compromised it — that's a live remote access channel into your network that your new provider doesn't control and may not even know exists.
What to do: Audit every endpoint for installed RMM agents (ConnectWise, Kaseya, NinjaRMM, Datto, etc.) before or immediately after onboarding your new provider. Uninstall anything not authorized by your incoming team.
2. Stale Admin Credentials
Your old MSP likely had admin accounts on your domain, Microsoft 365 tenant, firewall, and network gear. If those accounts weren't formally offboarded, they're still valid. This is compounded if the previous provider used shared credentials — a risk we've covered in detail in our post on shared credentials and MFP email security risks.
What to do: Pull a full list of admin accounts across every system. Disable or delete any account tied to the old provider on day one of the transition.
3. Unmonitored Security Tools
If your old MSP was running endpoint detection, SIEM logging, or threat monitoring, those tools may still be collecting data — but nobody's watching the alerts anymore. Attackers using fileless techniques and low-detection loaders (like Agent Tesla, Remcos, or XWorm) can persist undetected in exactly this gap, as recent reporting on evasive BEC phishing campaigns confirms.
What to do: Confirm with your new provider which security tools are active, which are monitored, and which need to be replaced or re-enrolled.
4. VPN and Firewall Access
Site-to-site VPNs, firewall management portals, and remote access configurations set up by the old MSP frequently survive the transition untouched. If the previous provider had a management tunnel into your firewall, it may still be open. Given how ransomware groups are exploiting authentication bypasses in network perimeter devices, this deserves immediate attention.
What to do: Reset all firewall admin passwords, audit VPN configurations, and remove any management tunnels or remote access rules tied to the old provider's infrastructure.
5. MFA Not Enrolled on Critical Accounts
During transitions, MFA enrollment often gets deprioritized. If your old MSP managed MFA and those configurations weren't properly handed off, you may have accounts that look protected but aren't. With Microsoft deprecating SMS-based MFA, this is an especially important moment to audit — something we've written about in our guide to SMS MFA deprecation and what small businesses should do.
What to do: Verify MFA enrollment status across all admin and privileged accounts before your new provider assumes control.
6. Forgotten Integrations and API Keys
Third-party integrations — backup tools, ticketing systems, cloud sync agents — often carry API keys or service account credentials provisioned by the old MSP. These don't expire on their own. If the previous provider's platform was breached (and MSP platforms are actively targeted), those keys may already be compromised.
What to do: Audit all third-party integrations and rotate any API keys or service credentials that were provisioned under the old provider's management.
7. No Baseline Vulnerability Scan at Transition
Your new MSP inherits whatever security posture your old one left behind — patched or unpatched, clean or compromised. Without a baseline scan at the point of transition, you have no way to know what you're actually starting with. Ransomware actors increasingly target organizations mid-transition precisely because coverage gaps create an unmonitored window.
What to do: Run a full vulnerability scan at the moment of transition — before your new provider fully onboards — so both parties have a clear picture of inherited risk.
The Offboarding Checklist Nobody Gives You
Most MSP contracts include onboarding checklists. Almost none include security-focused offboarding checklists for the outgoing side. That's a gap you have to close yourself. Use the seven categories above as your starting framework, and treat the transition window as a high-alert period — not a routine handoff.
For a related perspective on what proper access revocation looks like, our employee offboarding security checklist covers the same principles applied to departing staff — much of it maps directly to departing IT providers.
What Your New MSP Should Do on Day One
A security-conscious incoming provider should:
- Conduct an endpoint audit before deploying their own tooling
- Identify and remove legacy RMM agents
- Rotate all admin credentials before assuming management
- Run a vulnerability scan to establish a clean baseline
- Confirm MFA enrollment on all privileged accounts
If your new provider isn't doing these things, ask why. The first night shouldn't be a crisis.
Take Action: Don't Inherit a Breach
The transition window between IT providers is exactly when attackers look for an opening. A baseline vulnerability scan at the point of handoff gives you — and your incoming provider — a clear picture of what was left behind before it becomes a problem.
Oscar Six Security's Radar ($99/scan) is built for exactly this moment: a fast, affordable external vulnerability scan that surfaces inherited risks, open ports, stale configurations, and exposure before your new provider's first night on the job turns into a crisis.
👉 See how Radar works and get your scan
Focus Forward. We've Got Your Six.