Is Your MSP a Gap in Your Zero Trust?

Your company has spent real money on zero trust. MFA everywhere. Conditional access policies that check who's signing in, from what device, in what state of health, from where. Maybe a ZTNA rollout that finally retired the VPN. Every employee session is interrogated before it's trusted, and your board has seen the slide that says so.

Now trace how your MSP's technician actually reaches your CFO's laptop.

Not through any of it.

The parallel identity plane

The RMM agent your MSP installed on every machine is a persistent, SYSTEM-level access channel — authenticated to the vendor's cloud, not to your identity plane. The technician signs into the RMM console with MSP credentials your Entra tenant has never heard of, on a personal or MSP-issued machine your compliance policies have never evaluated, and lands on your endpoint with privileges higher than most of your own administrators hold.

No conditional access policy fires. No device posture check runs. Nothing appears in your sign-in logs.

The same is true of the remote-control layer — ScreenConnect, Splashtop, AnyDesk — installed as an auto-starting service on every endpoint, which is to say: standing inbound access that treats your zero trust architecture as scenery.

The blunt way to say it: you are running two identity planes. One governs your employees and is audited, conditional, and least-privileged. The other governs a third party's help desk, operates beneath your controls with higher privilege, and is secured by password policies, MFA enforcement, and offboarding discipline you cannot see, configure, or audit. When a technician leaves your MSP on bad terms, you are trusting someone else's HR process to revoke access to your entire fleet — and you will never know whether it happened.

Every agent in the stack is a hole punched through the architecture you paid to build. And the franchise model requires the holes, because the agents are the product.

When the franchise itself gets breached

It gets worse, because the hole doesn't just admit your MSP. It admits whoever compromises your MSP — or the platform your MSP rents.

These weren't flukes. They were the model expressing itself. CISA and its Five Eyes partners issued a joint advisory in 2022 warning specifically that both state and criminal actors target MSPs as force multipliers, because the economics are irresistible: why breach one company's perimeter when a single PSA login, RMM console, or vendor update pipeline opens hundreds of environments at once?

Your MSP's stack aggregates you into someone else's blast radius. You inherit the security posture of a company whose own MFA discipline, patch cadence, and technician offboarding you have never once reviewed — while it holds SYSTEM on everything you own.

The audit you can't produce

The compliance version of this problem is quieter but just as real. SOC 2, HIPAA, and CMMC all require you to attest to who accessed what, when. MSP sessions conducted through the provider's own tooling frequently generate no artifact in your SIEM, no session recording you hold, and — where technicians share console accounts, as they commonly do — no attributable identity at all.

Sit with that during your next audit prep: you are attesting to access controls that a parallel access plane bypasses by design, operated by people whose names you don't know, whose sessions you can't replay, on accounts you can't distinguish from one another.

What to demand — this quarter, in writing

None of this requires ending the MSP relationship. It requires closing the third-party-access gap inside it, and watching how the provider responds to being asked.

Bring the MSP's identity inside your identity plane. Replace standing admin credentials with GDAP — scoped roles, time-bound, granted per engagement rather than forever. Require that privileged sessions either traverse your identity controls or come with session recording and logs shipped to your SIEM. Named technician accounts only; shared console logins end this quarter.

Inventory and allow-list remote access tools. Enumerate every remote-control and RMM agent in the fleet and remove anything not contractually required — unauthorized remote tools are also one of the most common intrusion footholds, so this audit pays for itself twice. Application control policies in Intune can enforce the list going forward.

Flip the security questionnaire around. Your MSP has SYSTEM-level access to everything you own, which makes it your single largest vendor risk. Ask for its SOC 2 report, its internal MFA posture, its RMM patching SLA, and its technician offboarding process — the same questions your cyber insurer is already asking you. Put the MSP stack on your risk register where it belongs.

A provider that welcomes these demands is a partner with nothing to hide. A provider that stalls, deflects, or explains why it's complicated has just told you what the agents are really for — and given you the data you need to right-size the relationship at renewal.

The deeper structural question — who actually owns the environment, and what you're left holding if the provider goes away — is the subject of the final part of this series.