When competing parties share a SharePoint site collection, isolation is harder than it looks.
There’s a recurring scenario in SharePoint consulting that starts simple and gets complicated fast: an organization wants to share information with multiple external parties — competitors, claimants, suppliers bidding against each other — and none of them should know the others exist. No shared visibility. No name in a member list. No “modified by” leak. No people picker that helpfully autocompletes the rival’s email.
It sounds like a permissions problem. It isn’t. It’s an architecture problem, and most of the clever workarounds people reach for first quietly fail at one or more leak vectors. After working through this end-to-end with a real client, I’ve come to a clear conclusion: the most secure approach is also the one practitioners try hardest to avoid — provision a separate site for each external guest.
Here’s why every shortcut falls short, and why the “heavy” answer is actually the right one.
The Problem in Plain Terms
Imagine you need to share project information with two competing vendors. Each vendor must:
- See the project details
- Upload their own confidential bid documents
- Communicate with you about the project
Neither vendor can:
- See that the other exists
- See the other’s name, email, or company
- See the other’s documents, bid amount, or even the fact that another bid was submitted
This isn’t paranoia. In competitive procurement, in legal matters with multiple claimants, in mergers with multiple suitors — exposing a rival’s identity can torpedo deals, trigger lawsuits, or just damage your reputation as a trustworthy custodian of confidential information.
SharePoint can do this. The question is how, and the answer most people reach for first is wrong.
Workaround #1: Item-Level Permissions on a Single List
The classic SharePoint move: enable “Read items that were created by the user” on a list, and let each vendor see only their own submissions.
This works for the data. It’s a real, API-enforced security boundary, not just a UI trick. Vendor A genuinely cannot read Vendor B’s list items via the REST API.
This fails for everything around the data. The list lives on a site, and the site has chrome — the bar across the top, the “44 members” link, the People icon, the Share button, the Site Permissions page reachable from the gear menu. None of these respect your clever list-level configuration. A vendor who clicks the members count sees every other vendor in the group. Game over.
You can hide most of those elements with CSS injection via an SPFx Application Customizer. But CSS hiding isn’t security — it’s obscurity. Browser dev tools un-hide it in three clicks. And Microsoft updates the SharePoint UI on its own schedule, sometimes breaking your selectors and re-exposing things you’d hidden.
Verdict: Solves the data isolation problem. Leaves the identity-leak problem wide open.
Workaround #2: Disinherited Libraries per Vendor
Same site, but each vendor gets a document library with broken inheritance and per-vendor permissions.
This is actually better than item-level perms for documents (Microsoft has been quietly deprecating item-level perms on libraries for years, and the UI option doesn’t even exist there anymore — you have to set it via PowerShell, and behavior is inconsistent).
But the leak vectors are identical. Both vendors are still members of the same site. The Members panel still lists them. Site permissions still enumerates them. The people picker still autocompletes. The whole reason they can access anything is that they’re principals on a shared site, which means the platform’s built-in collaboration affordances keep trying to introduce them to each other.
Verdict: Cleaner data isolation than item-level perms. Same identity-leak problem.
Workaround #3: A Microsoft 365 Group With Suppressed UI
What if we accept the shared site model but aggressively suppress every UI element that could leak identity? Hide the members count with CSS. Remove the Members web part. Disable comments. Strip sharing rights. Build a custom permission level that blocks Browse Directories and Enumerate Permissions.
This is where many practitioners eventually land, and it can be made to work for casual users. But:
- A Microsoft 365 Group always exposes a member list through Outlook, Microsoft Graph, and the underlying group object — even if the SharePoint UI is suppressed.
- The Graph endpoint /groups/{id}/members is callable by any group member with sufficient scope. Adding vendors to the group means they can query each other.
- People pickers in modern lists, search refiners, and “shared with you” feeds all surface group membership in places you didn’t think to hide.
- Quarterly SharePoint UI updates break suppression CSS. You will spend the rest of your life patching selectors.
If you exclude vendors from the M365 Group and add them only to SharePoint groups, you reduce these leaks substantially. But you’ve now created an unusual configuration — a “Group-connected Team Site” with users who aren’t in the group — which is supported but quirky, and harder for your future self (or a successor) to reason about.
Verdict: Reduces leaks but doesn’t eliminate them. Maintenance is forever.
Workaround #4: A Hub Site With Per-Vendor Subsites
A more sophisticated pattern: put your master content in a hub site (which vendors never see), and surface project info to each vendor through a search-driven web part on their own communication site associated with the hub.
This is genuinely clever. The vendor never navigates to the hub. They land on their own site. The search web part is permission-trimmed at the index level — a real security boundary, not UI obscurity. Each vendor lives in their own world.
But notice what just happened: you’re already provisioning a site per vendor. The hub is just the back-end content store. The vendor’s experience is shaped entirely by their own site.
If you’re going to provision a site per vendor anyway, the hub adds complexity but doesn’t change the fundamental answer.
Why Site-Per-Vendor Is Actually the Right Answer
When each external guest has their own SharePoint site, almost every leak vector disappears by construction rather than by suppression:
No shared membership. The vendor is the only external user on the site. There is no “other vendor” to leak. The members panel, the people picker, the site permissions page — none of them can betray information that doesn’t exist.
No CSS suppression theater. You’re not hiding UI that’s trying to do its job. You’re letting SharePoint behave normally, because normal SharePoint behavior on a single-vendor site doesn’t leak anything.
Resilience to platform updates. Microsoft can rearrange the SharePoint UI all they want. If your security model relies on the absence of other principals rather than the hiding of references to them, UI changes don’t break you.
Honest data isolation. Bid documents, communications, drafts — everything lives in a site only that vendor can access. There is no “did I configure item-level perms correctly?” anxiety. There are no folder-permission edge cases. There is no shared list where a misconfigured view could expose the wrong column.
REST and Graph APIs don’t leak either. A sufficiently determined vendor calling /_api/web/siteusers on their own site sees themselves and the host organization. They cannot enumerate other vendors because other vendors are not present.
Auditing is straightforward. “Who accessed this content?” becomes a per-site question with an obvious answer, not a tangled query across permission scopes.
The Cost — and Why It’s Worth Paying
The honest objection to site-per-vendor is operational overhead. Provisioning a site, applying a template, configuring permissions, deploying any necessary extensions — it’s more work than adding a row to a list.
But provisioning is automatable. A PnP PowerShell script or a Power Automate flow can stand up a fully-configured vendor site in minutes. The marginal cost of vendor #5 is the same as vendor #2. And the cognitive cost is dramatically lower than maintaining a single-site design with five layers of suppression, custom permission levels, and quarterly CSS audits.
- Single-site with workarounds: Lower setup cost. High ongoing maintenance. Permanent leak risk. Quarterly UI surveys. A design only the original author can fully reason about.
- Site-per-vendor: Higher setup cost (mostly one-time, mostly automatable). Near-zero ongoing maintenance. Leaks foreclosed by structure. A design any competent SharePoint admin can audit at a glance.
For a system that will outlive its creator’s tenure — and most internal tools do — the second column wins every time.
The Takeaway
SharePoint is designed around collaboration. Almost every default behavior, every UI affordance, every API surface is built to help people find each other and share things. When your requirement is the opposite — to keep specific people from finding each other on purpose — you are working against the platform’s grain.
You can fight that fight inside a shared site, layer by layer, hiding and suppressing and configuring around what the platform wants to do. Or you can sidestep the fight entirely by giving each external guest a site that contains no one else.
One vendor, one site. Build it once, automate the provisioning, and stop hiding things that don’t exist.
