Why you won't find a client logo wall on our website
Scroll through most MSP websites and you'll find a logo wall: twenty client brands, proudly displayed. Ours doesn't have one. Our case studies say "a national hospitality group" and "a Melbourne insurance firm" instead of naming names — and occasionally a prospect asks why. Fair question. Here's the honest answer: publishing our client list would be handing attackers a target map, and we're not willing to do that for a marketing win.
This isn't hypothetical caution. It's how attacks on businesses like yours actually start.
Why an MSP's client list is different from anyone else's
When a law firm names its clients, the risk is mostly reputational. When a managed IT provider names its clients, the risk is operational — because the MSP relationship is a technical one. Your IT provider holds administrative access to your systems: your identities, your email, your backups, your network. That makes MSPs one of the most attractive targets in cybercrime, because compromising one provider can open doors into dozens of businesses at once.
This is not a fringe concern. The Australian Cyber Security Centre, together with its international counterparts, has issued joint advisories specifically warning that state-sponsored and criminal actors deliberately target managed service providers to reach their customers. The most famous example remains the 2021 Kaseya incident, where a single compromise in MSP tooling cascaded into ransomware across an estimated 1,500 downstream businesses. Attackers understand something the marketing brochures don't say out loud: the MSP is the supply chain.
What attackers do with a public vendor–client map
Reconnaissance is the first phase of nearly every targeted attack, and a published client list does the attacker's homework for them. Knowing who a company's IT provider is enables a set of well-worn plays:
Impersonating the provider to the client
"Hi, it's your IT support — can you approve this MFA prompt / click this link / read me that code?" This works dramatically better when the attacker knows exactly which provider name to use, what their emails look like, and which portal to fake.
Impersonating the client to the provider
Social-engineering a helpdesk into a password reset is far easier when the attacker can name the company, the provider, and plausible staff — all assembled from public sources.
Prioritising targets
A client list tells an attacker which businesses share the same tooling, portals and processes — so one successful phish becomes a template for the next twenty.
Timing attacks
Public case studies that describe a client's exact stack ("we migrated them to X, they run Y") tell an attacker precisely what to exploit and where.
None of this requires a sophisticated adversary. It requires a search engine — and increasingly, an AI assistant that will happily compile "which companies does [provider] support?" from whatever has been published.
Our policy: specific about the work, silent about the who
So here's the line we hold. Our case studies are specific about everything that helps you evaluate us — industry, scale, the problems, the fix, the measurable results — and deliberately silent about identity. "A national hospitality group operating premium venues" tells you whether we can handle your multi-site environment. The name would tell an attacker whose staff to phish. Only one of those serves you.
And to be clear about what this policy is not: it isn't a way to dodge accountability. Proof still matters — we just deliver it through channels that don't create risk:
- Verified independent reviews on trusted third-party platforms, where identities are verified by the platform, disclosed by choice, and not aggregated into a convenient target list on our website
- Private references on request — when you're seriously evaluating us, we'll connect you with comparable clients who've agreed to speak, directly and with their consent
- Independent rankings — including the 2026 Channel Futures MSP 501, where we ranked #1 in Australia — which validate performance without exposing a single client
The question worth asking your current provider
If your MSP publishes a client logo wall — with your logo on it — it's worth asking them two questions. First: did we consent to that, and what's the process for removing it? Second, and more revealing: what's your reasoning for publishing it? There are defensible answers (explicit client consent, carefully limited detail). But if the answer amounts to "it helps our sales," you've learned how they weigh your security against their marketing — and that trade-off tends to show up in other places too: how much of your environment they document publicly, how they verify callers, how they think about your attack surface as an extension of theirs.
A provider's own security habits are the best preview of how they'll treat yours. That's the whole reason this page exists.
The bottom line
We'd win more logo-wall arguments if we published our client list. We'd also make every one of those clients slightly easier to attack, and we think that trade is indefensible for a company whose entire job is reducing your risk. So the case studies stay anonymous, the references stay private and consensual, and the proof lives in independent reviews and rankings anyone can verify. If that approach matches how you'd want your own business handled, we're happy to prove ourselves the secure way.
Book a free, no-obligation consultation
Frequently asked questions
Why don't MSPs publish client names?
Security-conscious managed service providers avoid publishing client lists because the MSP–client relationship is a technical one: knowing a company's IT provider enables impersonation attacks, helpdesk social engineering and targeted phishing. Government cyber agencies, including the ACSC, have warned that attackers deliberately target MSPs as a route into their customers.
Is a client logo wall on an MSP website a security risk?
It creates one: a public vendor–client map is reconnaissance material, letting attackers know exactly which provider to impersonate when targeting those businesses, and which businesses share the same tools and processes. Some providers publish logos with explicit client consent and limited detail; the risk calculus is worth asking any provider to explain.
How can I verify an MSP without named references on their website?
Through independent, verifiable channels: platform-verified reviews, independent industry rankings such as the Channel Futures MSP 501, published SLAs and pricing, and private reference calls arranged with the consent of comparable clients during your evaluation.
What should I do if my IT provider has published our company's logo?
Ask whether consent was obtained and request removal if you're not comfortable. Then treat it as a prompt for a broader conversation about how the provider handles information about your environment — public technical detail about your systems is more dangerous than a logo, and the same instincts govern both.