External collaboration in SharePoint: guest users, B2B portals, and secure sharing

How can customers, suppliers, or project partners access SharePoint content without exposing internal areas? External collaboration in SharePoint is usually better controlled for recurring scenarios via a standalone, clearly bounded site with Microsoft Entra ID B2B guest accounts rather than through many individual file shares. Tenant and site sharing settings limit which sharing types are even possible. Group-based permissions, time-limited access, access reviews, and audit logs complement the technical model.

SharePoint external collaboration is not, however, a public website. A B2B portal targets known external identities that authenticate and see only defined content. Anonymous Jeder links can be practical in suitable individual cases, but offer less identity linkage and should not be confused with a controlled guest access.

When external collaboration in SharePoint is sensible

SharePoint is suitable when internal and external participants are to collaboratively edit documents, lists, or project information and the organization already operates Microsoft 365. Typical scenarios are:

• Project documentation with an implementation partner,
• Supplier documents and approvals,
• Customer handovers,
• Tender documentation,
• Joint quality or maintenance documentation,
• Time-limited workspaces for consultants.

SharePoint is unsuitable as a replacement for an anonymously accessible customer area with high public load, complex self-service, payment functions, or freely registrable accounts. For that, specialized portal or web applications are usually more suitable.

Distinguish three sharing patterns

Pattern: B2B guest in site/group

Identity: authenticated external user

Typical use: ongoing collaboration

Control level: high, if properly managed

Pattern: Link for specific people

Identity: authenticated named recipients

Typical use: single file or folder

Control level: medium to high

Pattern: Jeder link

Identity: no permanent guest account required

Typical use: deliberate anonymous distribution

Control level: low identity verification

Available options depend on settings at the organization and site levels. A site cannot share more openly than the tenant allows.

Architecture of a B2B portal

Separate external content in your own site

An external workspace should not simply be a substructure of an internal team site. A standalone site creates a clear security boundary, its own owners, its own sharing settings, and a separate lifecycle.

Recommended separation:

• internal work site for drafts, calculations, and internal comments,
• external project site for shared published content,
• controlled handover process between both areas.

This way, internal documents do not need to be hidden behind complex folder permissions. Separation also reduces the risk that new internal content accidentally lands in a folder already shared externally.

Keep the portal structure small

A typical external site requires only a few components:

• home page with purpose, contacts, and usage rules,
• document library for shared files,
• optionally separate libraries for different confidentiality levels,
• list for tasks, questions, or handovers,
• page with access and support instructions.

Too many libraries and nested folders make it difficult for external users to orient themselves and increase the effort required for permissions.

Guest users in Entra ID: invitation and authentication

Microsoft Entra External ID or B2B Collaboration enables you to manage external people as guest objects in your own directory. The guest authenticates using a supported identity or, depending on the configuration, a one-time code. Your organization manages which resources this guest object is allowed to access.

Invitation process

1. A qualified internal user or administrator invites the external address.
2. Entra creates a guest object or prepares the redemption.
3. The recipient opens the invitation and authenticates.
4. After successful redemption, the assigned group and site permissions apply.
5. Sign-in and audit events can be evaluated for controls.

The specific user experience depends on factors such as home tenant, identity provider, cross-tenant settings, Conditional Access, and invitation status.

A guest account is not an automatic permission

A guest object in the directory does not grant access to SharePoint. Only membership in a group or a direct sharing assignment grants rights. Conversely, a guest object can remain in the directory after a project ends, even though the site permission has been removed. Therefore, resource permissions and identity lifecycle must be controlled together.

Check license questions in advance

External identities and Microsoft 365 services are subject to product-specific licensing and billing rules that can change. Additionally, features such as Conditional Access, Identity Governance, or Access Reviews may require specific Entra licenses. The current Microsoft product documentation and the specific contract are decisive before implementation.

Sharing levels: site, library, folder, or file

Site sharing

Suitable for people who regularly collaborate throughout the entire external workspace. Permissions should be assigned through a clearly named group, for example Projekt Alpha – Externe Mitglieder.

Advantage: understandable membership and easy revocation.

Risk: New content of the site is visible to this group unless separate sections exist.

Library sharing

Suitable when external users need only a defined document area. The library receives its own permission scope.

Advantage: clear content boundary.

Risk: Multiple libraries with differing permissions increase administrative effort.

Folder sharing

Can be practical for limited handovers but should not become the standard architecture. Many individually shared folders create hard-to-audit permission silos.

File sharing

Suitable for a single, clearly named file. For ongoing collaboration, it is confusing because access is distributed across many documents.

Principle of least privilege

External users receive only the rights necessary for their task. In many cases, reading or editing without deleting or sharing rights is sufficient. Check whether members are allowed to invite other people and whether site owners must control sharing.

Model permissions for external users cleanly

Groups instead of direct access

Use groups per role, for example:

• Externe Leser,
• Externe Bearbeiter,
• Interne Projektmitglieder,
• Portal-Owner.

This simplifies onboarding, offboarding, and access reviews. Direct permissions are suitable only for justified exceptions.

Do not mix internal and external groups

A shared group may work technically but complicates control. Separate groups make visible how many guests are involved and what rights they hold. They also enable stricter policies or shorter review intervals for external users.

Do not place confidential content at the same permission level

If a library contains external editors, it must not hold internal documents that are merely "hidden" via navigation. Security relies on permissions, not invisible links.

Consciously review hub assignment

An external portal can be technically connected to a hub architecture but should not automatically be included in enterprise-wide navigation and content aggregation. SharePoint Hub Sites: Intranet Navigation, Site Hierarchy, and Permission Concept explains why hub assignment and permissions are separate concepts.

Data protection and logging

The GDPR requires, among other things, purpose limitation, data minimization, adequate security, and limited storage of personal data. For an external SharePoint portal, this means technically and organizationally:

• Document purpose and permissible content,
• Process only necessary guest data and logs,
• Legally review data processing and international data transfers,
• Restrict access based on roles,
• Define retention and deletion rules,
• Consider data subject and information request processes,
• Detect and handle security incidents.

This article does not replace legal advice. The specific legal basis, information obligations, and retention period must be reviewed for the organization, country, and scenario.

Audit and sign-in logs

Microsoft Purview Audit and Entra sign-in logs can document activities such as sharing, file operations, and sign-ins. How long events are available depends on the license, audit configuration, and data source. Check beforehand:

• which events are needed for proof,
• who can view logs,
• how long they are retained,
• how exports are protected,
• how quickly an event is searchable after an action.

An audit log does not prevent unauthorized access; it supports detection and investigation.

Limit access duration and review regularly

Expiration date

For projects with an end date, access should not be unlimited. Possible mechanisms include:

• expiration date in the guest or project register,
• scheduled Power Automate reminder to the owner,
• Entra Access Reviews,
• automated group workflows,
• periodic manual confirmation.

Automatic removal should have a documented exception process so that ongoing contract or support cases are not accidentally interrupted.

Access Reviews

Entra Identity Governance can provide Access Reviews for groups, applications, and guests. Reviewers confirm, remove, or justify access. Availability and automation scope depend on the licenses used.

Project end

A controlled conclusion includes:

1. check final handover and open tasks,
2. terminate external edit rights,
3. archive required content or transfer it to an internal system,
4. revoke sharing links,
5. remove group memberships,
6. delete or block guest objects after organization-wide review.
7. Apply retention policies,
8. Document completion.

Typical risks, tests, and fallback paths

Overly broad tenant or site sharing

Symptom: Users can create anonymous links or new guests, even though only named partners are intended.

Test: Try different sharing types with a regular member; compare admin settings at the tenant and site levels.

Fallback: Restrict site sharing level, inventory existing links, and revoke unauthorized links.

Forgotten guest access

Symptom: Former project partners remain in groups or in the directory.

Test: Evaluate groups and guests by last activity, project, and owner.

Fallback: Initially block access, obtain business confirmation, and then carefully remove group membership or the guest object.

External user sees more than expected

Causes: Membership in multiple groups, direct sharing, inherited permissions, or a library with incorrect boundaries.

Test: Perform access verification with the specific guest and conduct search tests.

Fallback: Revert permissions to the defined group; review affected content and audit events; trigger a security process if actual data access was possible.

Invitation cannot be redeemed

Causes: Wrong account, cross-tenant restriction, Conditional Access, an existing guest object, or a blocked identity provider.

Test: Check invitation status, login logs, and the identity used.

Fallback: Do not blindly create the guest object multiple times. Clean up the existing identity or resend the invitation carefully.

File remains locally after revocation

SharePoint can revoke future cloud access, but it cannot automatically retrieve already downloaded copies. Sensitivity labels, terms of use, and organizational guidelines can reduce the risk. For highly sensitive data, you must check whether downloads should be allowed at all.

Acceptance test for an external SharePoint site

• Guest can redeem the invitation with the intended identity.
• Guest sees only the intended site or library.
• Internal drafts are not accessible via navigation or search.
• Guests can only perform allowed actions.
• Guests cannot invite additional people unless explicitly provided for.
• Anonymous links are blocked or explicitly justified.
• The expiration and access review process functions correctly.
• Audit and sign-in events are discoverable by authorized reviewers.
• Offboarding removes group, site, and link access.
• Fallback for blocked identity and expired invitation was tested.

A separate data and site model for project documents is explored in the post Central Project Repository in SharePoint Instead of Paper Planning.

How to keep external SharePoint access secure, traceable, and maintainable

Secure external collaboration begins with a separate site and known B2B identities, not with scattered individual sharing. Group-based roles, restrictive sharing settings, expiration dates, access reviews, and tested offboarding steps keep access manageable. Audit and sign-in logs supplement the proof but do not replace the principle of least privilege or clear business responsibility.