MSP security checklist: harden your own house first

Every MSP sells security. Far fewer apply the same rigour to their own house, and attackers know it. Compromise one company and you get one estate; compromise an MSP and you get every estate it manages, delivered through tooling those clients are contractually required to trust. This MSP security checklist covers the six controls that decide whether one phished technician credential stays an incident or becomes a supply chain breach with your name on it.

Each item below gets a short explanation of why it matters and what tends to happen when it is skipped. Work through them in order: the first three shrink the blast radius of a compromise, the last three make sure a compromise stays survivable.

1. Put phishing-resistant MFA on everything that can touch a client estate

Your RMM, your PSA, your password manager, your documentation platform and your Microsoft partner portal are, taken together, a master key to every client you serve. ConnectWise's 2026 MSP threat report puts identity abuse at the centre of MSP risk for a reason: nobody needs to exploit software when a convincing login page and a tired technician will do. Ordinary push-based MFA is no longer enough for these accounts, because push fatigue and real-time phishing proxies defeat it routinely. For anything with cross-client reach, that means passkeys or hardware security keys, plus conditional access rules that refuse logins from unknown devices. Start by listing which accounts actually have that reach; most MSPs find the list is longer than they expected once the documentation platform, the backup consoles and the odd forgotten vendor portal are counted.

Skip this and the failure mode is brutally simple: one technician approves one prompt at the end of a long day, and an attacker is inside a console with interactive access to every device you manage. Most of the MSP breaches that make the news start exactly here, not with a zero-day.

2. Give technicians per-client identities, not one master key

Shared admin accounts and standing global access are convenient, and that convenience is precisely what makes them dangerous. Every technician should reach each client tenant through a separate, named identity with the least privilege the job requires, elevated only when needed and logged when used. Microsoft partners should have finished the move from legacy delegated admin (DAP) to granular delegated admin (GDAP) long ago; if that migration is still on your backlog, it belongs at the top. The same Microsoft 365 hardening baseline you apply to client tenants applies doubly to your own. Then review the access map quarterly, because privilege only ever accumulates: technicians change teams, temporary elevations become permanent, and a year later nobody can say who can reach what.

Skipped, this control turns any single compromise into a full portfolio event. Flat access means lateral movement between clients costs an attacker nothing, and it also means your incident report has to say "we cannot rule out access to any customer", which is the sentence that ends client relationships.

3. Inventory every remote access path, then close the ones you cannot defend

Remote access tooling is now a primary attack vector in its own right. Huntress reported a 277% jump in RMM abuse during 2025, accounting for roughly a quarter of the incidents it investigated, and CISA spent June 2025 warning about ransomware crews exploiting unpatched SimpleHelp instances. Attackers either hijack the legitimate agent you deployed or quietly install one of their own, because a signed, well-known remote access tool walks straight past most defences. The checklist item is threefold: sanction exactly one remote access product, patch it within days of a release rather than months, and alert the moment any other remote access binary appears on a device you manage.

Without this control, an intruder's access outlives every password reset you do, because the backdoor is not a credential. It is a legitimate product, running as a service, that nobody on your team remembers installing.

4. Run your own estate as client zero

The cobbler's children go barefoot in almost every MSP: internal laptops miss patch windows that client machines never would, the office server has no backup alerting, and nobody monitors the technicians' endpoints with the rigour applied to a client's finance team. That inversion is exactly backwards. A technician's laptop holds live sessions and cached tokens for your RMM, your PSA and a dozen client tenants, which makes it more valuable to an attacker than any device you manage for anyone else. The same goes for your documentation platform: a well-kept IT documentation store is a beautifully organised credential database from an intruder's point of view, and it deserves the same protection as the systems it describes.

The fix is procedural rather than technical: enrol your own company as a tenant in your own stack, with the same patch SLAs, the same endpoint protection checks and the same alerting as your best-managed client. When this is skipped, the intrusion route is depressingly consistent: the attacker never touches your hardened RMM platform at all. They compromise the unpatched, unmonitored laptop that is already logged into it.

5. Offboard leavers with the urgency of a zero-day

When a technician resigns, their knowledge and credentials span every client on your books, and every hour of delay is exposure multiplied by your whole customer list. That demands a living inventory of what each role can touch: which tenants, which consoles, which shared secrets, which client-site accounts. On their last day, named accounts get disabled everywhere, and every shared secret they knew gets rotated, from documentation-platform entries to client local admin passwords. Our IT offboarding checklist covers the general case; for an MSP, multiply every step by the number of clients involved.

Skip it and you are gambling on goodwill. Most leavers are honest, but "former employee of the IT provider" appears in breach post-mortems far too often to be a hypothetical, and even an honest leaver's stale account is a ready-made target for whoever phishes it next.

6. Rehearse the day your own tooling is the breach

Every MSP has an incident response plan for clients. Very few have one for the scenario where the incident is them: ransomware deploying through their own RMM, to every client at once. Write that plan while it is still hypothetical. It needs a tested way to mass-disable or isolate your agents, break-glass credentials stored offline where a compromised tenant cannot reach them, an out-of-band contact list for clients that does not live in the Microsoft 365 tenant you may have just lost, and an honest decision, made in advance, about who tells clients what and when. Then tabletop it twice a year, and check your own cyber insurance actually covers incidents that propagate to customers, because a policy written for a normal business often excludes exactly the third-party liability an MSP breach creates.

Without a rehearsed plan, the first hours of a real event are spent arguing about basics while the attacker uses your deployment tooling at full speed. Those hours are the difference between isolating three clients and explaining yourself to fifty.

Where this fits with Helios

Helios cannot run your tabletop exercise for you, but it makes "client zero" practical: your own company sits in the platform as a tenant like any other, so your laptops and servers get the same patching, endpoint protection checks and backup monitoring as every client estate. Protection-gap detection flags devices where security tooling is missing or silent, on your estate as much as theirs, and Helio's device investigations give you a fast answer when something on a managed machine does not look like something you deployed. An MSP security checklist only works if checking it is cheap enough to do continuously, and that is the part a platform should carry.