Your MSP Is the Attack Surface: Hardening the Practice You Sell Security From

There is a version of this industry’s conversation that never quite happens. Providers spend all day assessing client environments, writing risk registers for other people’s businesses, and explaining to boards why standing administrative access is dangerous. Then they go back to a practice that has one shared admin account across forty tenants, a remote-management platform reachable from the open internet, and no assessment of its own that anyone can produce on request.

This is not hypocrisy so much as economics. Provider budgets flow into the delivery platform, because the delivery platform generates revenue. The internal estate does not, so it gets whatever attention is left over. Attackers worked this out some time ago, and the pattern that follows is entirely rational: do not break into a hundred companies, break into the one company that already has privileged, trusted, pre-authorised access to a hundred companies. You are the force multiplier. Your tooling is designed to push software and run commands remotely at scale, which is precisely what an intruder wants, and it is already whitelisted in every client environment you manage.

If you run an MSP, MSSP, or security consultancy, your own practice is the highest-value target in your client base and almost certainly the least assessed. Fixing that is not a project you can outsource to the next quiet quarter, because the quiet quarter is not coming.

Blast Radius Is a Design Decision You Have Probably Not Made

Start with one question, and answer it honestly rather than aspirationally: pick a single account in your practice, assume it is fully compromised, and count how many client environments fall with it. That number is your blast radius. Most providers have never calculated it, and the ones who do are usually unpleasantly surprised.

Blast radius is not a consequence of bad luck. It is the sum of small operational conveniences that each made sense in isolation: one shared credential because per-client credentials were tedious to manage, standing domain admin because elevation requests slowed the team down, one flat management network because segmenting it would have taken a weekend nobody had. Each decision bought a little speed. Collectively they built a single point of catastrophic failure and put it in the hands of whoever clicks the wrong link first.

Four structural changes do most of the work here:

• Kill standing privilege. Administrative access should be requested, time-boxed, and logged, not permanently attached to an account. Just-in-time elevation turns a permanent skeleton key into a short-lived, auditable one.
• Use per-tenant credentials. Shared accounts across clients are the single fastest way to convert one compromise into forty. Separate identities per tenant mean lateral movement between clients requires a fresh authentication event, and that event is something you can detect.
• Separate the delivery plane from the corporate plane. Email, sales tooling, and general staff laptops should not sit on a path that reaches client production. Most provider compromises start in the corporate plane because that is where the humans are.
• Enforce phishing-resistant MFA on everything privileged. Not SMS, not push-approval fatigue. Hardware-backed or platform authenticators on every administrative path, including the break-glass accounts you never use and therefore never checked.

Add one deliberately boring practice on top: verified, tested, offline-recoverable backups of your own systems, not just your clients’. Providers who have lived through this describe the same discovery — they could restore any client in hours and could not restore themselves for days, because their own recovery had never been exercised.

Apply Your Own Baseline Internally

The frameworks you sell work perfectly well when pointed inward. Running an internal ISO 27001 or SOC 2 programme is not primarily a paperwork exercise; it forces you to inventory your own assets, scope your own access, document your own suppliers, and actually test controls you have been recommending to clients for years. It surfaces the accounts nobody owns and the systems nobody has patched because they belong to everyone and therefore to no one.

The commercial case is stronger than the risk case, which is what makes it fundable. Enterprise buyers and their procurement teams increasingly require providers to evidence their own posture before signing, and an increasing share of client questionnaires now ask about the provider’s controls rather than the client’s. A provider who can produce current evidence wins deals against one who promises to get certified next year. If you already run client programmes across multiple frameworks, pointing the same control mapping and evidence collection at your own practice costs a fraction of running it as a separate initiative — and it means your internal posture is continuously evidenced rather than reconstructed in a panic when a prospect’s security team asks.

There is a useful side effect. Living inside the same compliance workflow you sell makes you better at selling it. Practices that run their own programme on their own platform find the friction points their clients complain about, and fix them before the complaints arrive.

Your Perimeter Now Includes Everyone You Integrate With

Every tool you bolt onto the delivery stack extends your attack surface, and integration sprawl is how that happens without anyone deciding it should. The remote-management platform, the ticketing system, the documentation tool, the backup service, the security platform, the automation glue between them — each holds credentials, tokens, or tenant-wide OAuth scopes that reach into client environments. A compromise of any one of them can be functionally equivalent to a compromise of you.

Providers are rigorous about third-party risk when they are billing for it and casual about it when it is their own stack. Run the same discipline on yourself: maintain a live inventory of every vendor with access to client data or client systems, record what scope each one holds and who owns the relationship, and review those scopes on a schedule rather than at renewal. Pay particular attention to integrations granted broad permissions during a proof of concept two years ago and never revisited. The third-party risk process you run for clients is the right process; it just needs a row for yourself.

Tool consolidation helps more than it gets credit for. Every platform you remove is a set of credentials, a vendor relationship, and an integration path that stops being your problem. The economics usually favour it too — providers carrying overlapping tooling are paying twice for one capability and defending three attack paths for it.

Contracts, Liability, and the Conversation Nobody Has Until It Is Too Late

Technical hardening limits the damage. Contracts decide who pays for it. Most provider agreements were drafted when the business was smaller, the clients were less regulated, and the standard assumption was that a breach would happen to the client rather than through the provider.

Four clauses deserve a fresh read:

• Limitation of liability. Is it capped at fees paid, and does that cap survive a claim arising from your own compromise? A cap that looks generous against a monthly retainer looks very different against a client’s incident costs.
• Indemnity. Understand what you have agreed to cover and under what trigger. Providers routinely sign mutual indemnities without modelling what the exposure looks like across the whole client base simultaneously, which is exactly the scenario a provider breach creates.
• Incident notification. Whatever timeline you committed to, confirm you can actually meet it while your own systems are down. Notification obligations that assume working email and available staff do not survive contact with a real incident.
• The responsibility matrix. Write down, per service, which security tasks are yours and which are the client’s. Ambiguity here is where post-incident disputes live. “We assumed you were monitoring that” is a sentence that costs money.

On insurance, cyber liability and technology errors and omissions cover different failures. One responds to your breach; the other responds to a claim that your service was negligently delivered. Providers frequently discover the seam between them during a claim rather than before, which is the worst possible time. Get a broker who genuinely understands managed services to read both policies against your actual contracts. This is the same rigour you would apply on the insurance-readiness work you do for clients, turned inward.

Have a Plan for the Day It Is You

Every provider has an incident response plan for clients. Far fewer have one for the scenario where the provider is the incident — where the tooling used to respond is the tooling that is compromised, and every client needs to hear from you at once.

Write that plan specifically. It needs out-of-band communications that do not depend on your own email or chat, a pre-drafted client notification sequence with a clear order of contact, a decision on who is authorised to disconnect your own management access from client environments and how fast that can happen, and a legal and insurance contact reachable outside business hours. Then rehearse it, including the part where the person who normally leads the response is unreachable.

The reputational outcome of a provider breach is determined almost entirely in the first twenty-four hours, and specifically by whether clients hear it from you or from someone else. That is a preparation problem, not a communications-talent problem.

A 90-Day Hardening Plan

You can do this without stopping delivery.

Days 1 to 30 — measure. Calculate blast radius per privileged account. Inventory every vendor and integration with access to client systems, including the OAuth scopes. List every account with standing administrative access anywhere. Confirm your own backups restore, by restoring one.

Days 31 to 60 — reduce. Remove or time-box standing privilege. Split shared credentials into per-tenant identities, starting with the largest clients. Enforce phishing-resistant MFA on all administrative paths. Revoke integration scopes nobody can justify. Separate the corporate plane from the delivery plane.

Days 61 to 90 — evidence and formalise. Scope an internal control baseline against a framework you already run for clients. Update the contract templates: liability, indemnity, notification, responsibility matrix. Review insurance against those contracts. Write and rehearse the provider-breach response plan. Publish a trust page so procurement teams can self-serve.

Then keep the measurement running, because blast radius grows back. Every new client onboarded in a hurry, every integration added for one project, every temporary elevation that quietly became permanent — the number creeps up unless something checks it on a schedule.

The Part That Sells

Providers hesitate on this work because it feels like cost with no revenue attached. That reading is wrong. Buyers are getting more sophisticated about provider risk, and the security questionnaire aimed at you is becoming a standard part of procurement rather than an enterprise-only formality. A provider who can evidence its own posture — certified, documented, with a clear responsibility matrix and a tested response plan — closes deals that a provider relying on assurance cannot. It is also the cleanest differentiator against larger competitors, because you can demonstrate the specifics while they point at a brand.

The practices that survive the next few years will be the ones who treated their own environment with the same seriousness they sell. It is not a distraction from the service. It is the proof that the service is real.

If you want to run your own control programme on the same platform you use to run your clients’, GetCybr maps controls, collects evidence, and generates the reports procurement asks for — for your clients and for your practice. Book a demo and we will show you what pointing it inward looks like.