A Remote Service Provider (RSP) secures and operates your website from the outside — at the network edge and the application layer — rather than installing privileged agents inside your network the way a traditional Managed Service Provider (MSP) does. That one architectural difference is why an RSP has a smaller blast radius when something goes wrong: a provider who never held the keys to your internal systems can’t hand those keys to an attacker.
That is not a knock on the people who run MSPs. It is a statement about where the risk lives. And right now, the clearest proof of where it lives isn’t coming from vendors — it’s coming from cyber-insurance underwriters, who have quietly made the inside-the-network model one of the hardest things to insure.
What is the difference between an MSP and an RSP?
An MSP manages technology from inside your environment. To do its job — patching, monitoring, support — it installs remote management (RMM) tooling and endpoint agents that hold standing, privileged access across the systems it manages, usually for many clients at once. An RSP does a narrower job from outside that boundary: website security monitoring, protection, and reporting on the surface that faces the internet, without a privileged foothold on your internal network or endpoints.
The distinction sounds academic until you ask the only question that matters in a breach: if the provider is compromised, how far does it spread?
| Traditional MSP | Remote Service Provider (like Centry Engine) | |
| Access model | Privileged agents inside the client network (RMM, endpoints) | External / edge and application layer, scoped to the website |
| Blast radius if the provider is breached | Can cascade across every client’s internal network | Contained to website-layer access |
| Standing privileged access to your endpoints | Yes | No |
| Known supply-chain attack path | Yes — through shared management tooling | Not present in the same form |
| Cyber-insurance risk class | Among the hardest to underwrite | A materially different exposure profile |
Why is “sitting inside the network” a security risk?
Because access is shared, a single failure doesn’t stay contained. One compromised credential, or one bad update pushed through management tooling, can turn into incidents at every client that provider touches — simultaneously. Security teams call this aggregation risk, or blast radius: the damage isn’t limited to the target, it’s multiplied by everyone connected to it.
This is not hypothetical. In a joint advisory, Protecting Against Cyber Threats to Managed Service Providers and their Customers (CISA AA22-131a), CISA, the NSA, the FBI, and international partners warned that attackers deliberately target MSPs as a route to reach their customers downstream. The 2021 Kaseya VSA attack showed the mechanism at scale: attackers compromised a widely used remote-management platform and pushed ransomware through it to MSPs and, from there, to as many as 1,500 downstream businesses at once. The tool that let one provider manage many clients efficiently was the same tool that let one attacker reach them all.
Why are MSPs so hard to insure right now?
Because underwriters price aggregation risk, and the MSP model concentrates it. If a carrier insures an MSP, a single event at that provider can generate claims from a dozen clients at the same time — exactly the correlated loss insurers exist to avoid. So, MSP applications face steeper scrutiny, higher premiums, and more declines than their size alone would suggest.
The decision usually comes down to a short list of controls underwriters now expect to see enforced internally, not just sold to clients:
- Multi-factor authentication on remote access, RMM, and privileged accounts — not only email
- EDR deployed across endpoints, including the ones managed for clients
- Immutable or offline backups that are tested, not just scheduled
- Privileged access management that limits who can push changes across the client base
- A documented incident-response plan that covers a client-facing breach, not only an internal one
None of that is exotic — it’s the same stack most MSPs already sell. The gap is usually that it isn’t fully applied internally, or it’s applied but never documented in a way an underwriter can verify. That documentation gap is often the real reason for a decline: not that the risk was too high, but that the submission couldn’t prove the risk was managed.
The deeper point for a buyer is simpler. When the insurance market — an industry whose entire job is pricing risk accurately — treats the inside-the-network model as a hard risk to cover, that is an objective signal about the architecture, not a marketing claim from anyone selling an alternative.
If you run an MSP, is an RSP a competitor or an asset?
For an MSP, an RSP layer is more asset than threat. Much of an MSP’s hardest-to-insure exposure comes from one place: the deep, privileged access it holds inside client networks. You can’t remove all of it — that access is the job. But you can stop adding to it for work that doesn’t need it. Website security, monitoring, and operations don’t require a privileged foothold on a client’s endpoints, so running that surface through an edge-based RSP layer keeps it off your internal attack surface entirely.
Done that way, an RSP like Centry Engine gives an MSP three things at once: a website-security service to put in front of clients under its own brand, documented and verifiable controls on that surface for the underwriting file, and less concentrated risk to answer for when a carrier asks how far a compromise of you would spread. The point isn’t to replace what an MSP does inside the network. It’s to keep the part of the work that can live outside the network from making the inside-the-network problem any bigger.
Doesn’t a remote provider still get inside my site?
Yes — and this is the line worth drawing carefully, because it’s where the argument has to be honest. An RSP model can include software that runs inside the website — a plugin at the application layer that gives deeper detail and faster action on the site itself. What it does not do is place a privileged agent inside your corporate network and across your endpoints, which is the MSP model and the path the Kaseya attackers used.
So, the claim is not “a remote provider can never be compromised.” Nothing that touches your systems is risk-free. The claim is narrower and more durable: a provider scoped to the website layer has no standing privileged foothold in your internal network, so a compromise of that provider has a far smaller blast radius. Less access to lose is less access an attacker can take.
What should you ask any provider about their access model?
Whoever you hire, the useful questions are about reach and blast radius, not features:
- What, exactly, can you reach inside my environment — the website only, or my network and endpoints?
- Do you hold standing privileged access, and to how many other clients with the same tooling?
- If you are breached, what is the blast radius on my business — and how is it contained?
- Can you show the controls (MFA, EDR, PAM, tested backups, an incident-response plan) applied to your owns ystems, documented the way an insurer would want to verify?
A good provider will have clean answers. The answers themselves tell you which model you’re buying — the same diligence that goes into choosing a website monitoring tool in the first place.
Key takeaways
Is an MSP a security risk? An MSP is not inherently unsafe, but its architecture concentrates risk: because it holds privileged access inside many clients’ networks at once, a single compromise can cascade across all of them. That’s why regulators (CISA AA22-131a) and insurers treat it as a high-aggregation-risk model.
What is a Remote Service Provider (RSP)? A provider that secures and operates your website from the outside — edge and application layer — without a privileged foothold in your internal network, giving a smaller blast radius if the provider is ever compromised.
Why do MSPs struggle to get cyber insurance? Underwriters price aggregation risk. One event at an MSP can trigger correlated claims across many clients, so carriers scrutinize, surcharge, or decline MSP risk more than company size alone would explain.
Does an RSP need access to my internal network? No. It may run a plugin inside the website at the application layer, but it does not install privileged agents across your corporate network and endpoints.
Can an MSP use an RSP? Yes — and it can work in an MSP’s favor. Moving website security to an edge-based RSP layer keeps that surface off the MSP’s internal attack surface, adds documented client-facing controls that help the cyber-insurance underwriting story, and can be delivered under the MSP’s own brand.
Centry Engine is built as a Remote Service Provider platform — website security, monitoring, and operations run from the edge, not from inside your network. See how it works on your own sites.
Was this article helpful?
Thanks for your feedback.
Have a question about this topic?