Managed service providers occupy an unusual position. An MSP typically holds broader privileged access across a client estate than any of that client's own administrators, distributed across dozens or hundreds of client environments simultaneously.
Attackers worked out what that concentration is worth some years ago, and several significant incidents have followed the pattern: compromise the provider, use its legitimate management tooling to reach every client at once.
This briefing is written for both sides of the relationship, because the risk is shared and the responses differ.
Why the Concentration Matters
The remote monitoring and management agent is the crux. It runs with high privilege on every managed endpoint and is designed to execute arbitrary code, because that is what remote management requires. It is, functionally, the most powerful thing in most client environments.
An attacker who reaches an MSP's management console does not need to defeat any client's security. They use the tool exactly as intended, from a source the client trusts implicitly, at a scale no manual intrusion could achieve.
Alongside that sit the credentials MSPs hold: domain administrator accounts in client environments, cloud tenant administrative access, backup system access and network device credentials. These are frequently held in a documentation system whose own security is worth examining closely.
For Organizations Using an MSP
The most important shift is to stop treating the MSP as a supplier and start treating their access as part of your privileged access estate, because that is what it is.
Ask how their access to you is secured. Named accounts rather than shared ones. Phishing-resistant multi-factor authentication. Granted just-in-time rather than standing. Logged in your environment, where you can see it, rather than only in theirs.
Scope their access to what they actually administer. MSP accounts frequently hold domain administrator when the work requires considerably less, because broad rights were granted at onboarding to avoid friction.
Log and review their activity yourself. If the only record of what your MSP did is held by your MSP, you have no independent visibility into your own environment.
Examine the management agent specifically. Who within the MSP can use it against your systems, how that is authorized, and whether you would know.
Get a notification commitment in days. If your MSP is compromised, your own regulatory clocks may depend on how quickly they tell you. Specify it contractually.
Test whether you can revoke their access. Organizations frequently discover that cutting off an MSP either breaks operations or takes far longer than an incident allows. Establish this before you need it, and we cover the wider pattern in supply chain and third-party risk.
For MSPs
The commercial position has shifted. Clients that never asked about security now ask, cyber insurers ask, and larger clients increasingly require evidence of independent testing before signing.
Three areas deserve testing attention.
The corporate environment. An MSP is a business with staff, email and endpoints, and the route to the management console usually runs through an ordinary phishing compromise rather than through anything sophisticated. This is where most MSP incidents actually begin.
The management platform itself. Authentication to the console, who holds administrative rights within it, whether its own access is phishing-resistant, and whether an authenticated but low-privileged staff member can reach clients they do not service.
Segregation between clients. This is the highest-consequence finding available in an MSP assessment. A path from one client's environment, through the MSP infrastructure, into another client's environment converts a single client compromise into a breach of the entire book. Testing it requires deliberately attempting to cross that boundary, which is the same discipline as tenant isolation testing in a multi-tenant SaaS product.
The Shared Responsibility Confusion
Contracts allocate work. They do not allocate consequences.
A client cannot outsource its regulatory obligations, its breach notification duties or its liability to customers. An MSP that operates controls on a client's behalf is performing work, and the client remains accountable for whether the outcome is adequate.
This gets misunderstood in both directions, and the misunderstanding produces gaps. Clients assume the MSP handles security comprehensively when the contract covers a defined scope of operational tasks. MSPs assume the client understands what is and is not included.
The fix is unglamorous: write down what each party does, specifically, including who is responsible for patching what, who monitors what, who responds to what, and what happens outside business hours. Most MSP relationships we assess have a gap that neither party believed was theirs.
Testing the Relationship
The engagement that produces the most for both sides is one that tests the client environment including the MSP's access paths, rather than treating that access as trusted infrastructure outside scope.
That is frequently uncomfortable to propose, and it is where the findings are. An assessment that excludes the most privileged access into an environment has excluded the thing most worth examining.
To discuss testing an MSP platform or a client environment including its managed access, get in touch.
Frequently asked questions
Why are managed service providers targeted?
Leverage. An MSP holds privileged access across every client it administers, usually through remote management tooling that can execute code on every managed endpoint. Compromising one MSP yields access to dozens or hundreds of organizations at once, which is a far better return than attacking each individually. Several large incidents have followed exactly this pattern.
If we use an MSP, whose responsibility is security?
Yours, ultimately, however the contract allocates work. An MSP can operate controls on your behalf and cannot assume your regulatory obligations or your consequences. The practical position is that their security is functionally part of yours, because their access is part of your environment, and it deserves the same scrutiny as your own privileged accounts.
What should we ask our MSP about their security?
How their access to your environment is authenticated and whether it is phishing-resistant, whether access is standing or granted per request, whether their staff use named or shared accounts, how their remote management tooling is secured, what independent testing they have had, and what their breach notification commitment to you is in days.
Should an MSP have its own penetration test?
Yes, and increasingly clients require it. An MSP is both a business with its own attack surface and a concentration of privileged access to other organizations. Testing should cover the corporate environment, the management tooling and the segregation between clients, since a path from one client's environment to another is the most serious finding available.
What is the highest-risk component in an MSP relationship?
The remote monitoring and management agent. It runs with high privilege on every managed endpoint and can execute arbitrary code, which makes it the most powerful thing in most client environments. Its authentication, its access controls and who within the MSP can use it deserve more scrutiny than any other single control.