Secure Collaboration

Cross-Tenant Collaboration covers the identity mechanics: Entra B2B guest access, Cross-Tenant Access Settings, and Teams federation. This chapter covers the data layer: what guests and external users can do with content once they're in, and how to protect sensitive projects from oversharing without blocking legitimate collaboration.

Shared Channels vs. Guest Access: Data Exposure Comparison

Teams provides two fundamentally different external collaboration models. The choice determines what data the external user can reach and how it is governed.

	Shared Channels	Guest Access (B2B)
External user account required	Yes: Entra ID (their own tenant)	Yes: Entra B2B guest in your tenant
External user can access SharePoint	Channel files only, in your tenant's SPO	All sites they are granted access to
External user sees your org's Teams	No: they work from their own Teams client	Yes: they switch into your tenant
Content stored in	Your tenant's SharePoint	Your tenant's SharePoint
Sensitivity label enforcement	Applied by your tenant's policies	Applied by your tenant's policies
DLP scope	Your tenant's DLP policies apply	Your tenant's DLP policies apply
Guest sees other guests in the team	No	Yes (unless hidden)
Suitable for	Ongoing project collaboration with known partners	Temporary or broad access needs

Recommendation: Prefer shared channels for structured partner collaboration: the external user has a narrower blast radius (one channel's files, not the whole site) and works from their familiar Teams environment. Use B2B guest access when the external user needs broader access (multiple channels, other SharePoint sites, or Exchange calendar access).

Tented Projects: Sensitivity-Labeled Containers

A "tented project" is a Teams team or SharePoint site whose container label enforces access controls independently of the files inside it. The label is applied to the container, not individual files, and the container label settings govern:

• Whether external sharing is permitted at all
• Whether users who hold a Discover private teams policy can find the team, and which other teams may be invited into its shared channels (internal only, same label only, or private team only)
• Whether unmanaged (non-enrolled) devices can access the content

Setting Up a Tented Project

1. Create a sensitivity label for the container

In the Purview portal, create a label (e.g., Project — NDA) scoped to Sites and Groups in addition to Files and Email. Configure the site and group settings:

Setting	Value
Privacy of Teams connected to this label	Private
External user access	Do not add guest users / Allow existing guests
External sharing from labeled SharePoint sites	Existing guests only
Unmanaged device access	Web-only (no download)
Default sharing link type	Specific people

2. Apply the label when creating the Team

When creating a new Team, select the sensitivity label from the Sensitivity dropdown. For an existing Team: Team settings → Edit → Sensitivity.

3. Set a default file label for new content

A site admin sets a default sensitivity label on each document library (Library settings > Default sensitivity labels). The container label never labels the files inside the site; Learn says items in labeled containers do not inherit the label. The library default applies to new and edited files only, never to files already at rest, it overrides a lower-priority automatic label but never a manually applied one, and it cannot be a label that uses Double Key Encryption, user-defined permissions, or access expiry. GCC High: Learn's Purview planning table still lists the library default label as In development; check Library settings in the tenant, and where the option is absent use the label policy's default label plus a service-side auto-labeling policy scoped to the site.

4. Govern container label changes

Only a Microsoft 365 group owner (group-connected site) or a SharePoint site admin can change a container label, and the label policy decides which labels that person can pick, so publish the project labels only to the owners who are meant to apply them and keep Internal out of their policy where a downgrade must not be possible. The policy's justification-on-downgrade setting applies to files, emails, and meetings, never to groups and sites. A label's Privacy setting locks the team's privacy until the label is removed. Watch the audit log's sensitivity label activities for sites and groups (label added, changed, removed) and the Detected document sensitivity mismatch event, which fires when a file carrying a higher-priority label lands in the site.

GCC High (CMMC)

CUI-Labeled Project Sites

For CMMC environments, the tented project pattern directly maps to the requirement to control CUI by project or contract. Create a labeled container per contract vehicle:

Container Label	External Sharing	Default File Label	Typical Use
CUI (Basic)	Existing guests only (approved prime or subcontractor guests)	CUI (Basic)	Active contract work that admits partner guests
CUI//SP-CTI	Only people in your organization	CUI//SP-CTI	Technical work under a DFARS 252.204-7012 contract: distribution-statement content
CUI//SP-EXPT	No external sharing	CUI//SP-EXPT	Export-controlled programs (ITAR or EAR)
Internal	New and existing guests	Internal	Non-CUI partner coordination

The container label is the sublabel that matches the contract, never the CUI parent (a parent cannot be applied), and the Default File Label column is the library default label to set once that feature leaves In development for GCC High; until then, the label policy default and mandatory labeling carry the file label. The per-sublabel site settings behind the External Sharing column are in Container Labels.

Container labels support AC.L2-3.1.3 (CUI flow) and AC.L2-3.1.1 (authorized access), alongside actual resource permissions, approved sharing restrictions, file labeling, and tested DLP. A label alone does not establish partner authorization or complete coverage.

Commercial

NDA-Protected Projects

For commercial organizations, tented projects are most valuable for M&A due diligence, board committee work, and external legal engagements where a small group of internal and external parties needs to collaborate on sensitive content that must not be visible to the broader organization.

Use Private team privacy and No external sharing for projects that prohibit external participation. Where a partner must take part, build the label for that case instead: External user access allowed and an external-sharing setting of existing or new guests. By default users cannot search for private teams; if the Teams policy Discover private teams is on for anyone, clear the label's Allow users to discover private teams that have this label applied checkbox so the project team stays hidden from non-members.

MIP-Protected Files and External Recipients

When a file is encrypted with a sensitivity label's Rights Management protection, the behavior for external recipients depends on whether they can be authenticated against your tenant's RMS service.

How External Decryption Works

When an external user opens a Rights Management-protected file:

1. The Office app (or Azure Information Protection viewer) contacts your tenant's RMS endpoint to request a decryption license.
2. Your tenant checks whether the user's identity is in the label's permission list.
3. If authorized, the tenant issues a use license scoped to the user's rights (View, Edit, Print, etc.).
4. The file decrypts locally in the app.

The external user must have an Entra ID account: either from their own Entra ID tenant, or a Microsoft Account (for commercial tenants only). They do not need a Purview license; the license requirement is on the tenant that issued the label.

External User Account Requirements

GCC High (CMMC)

GCC High's RMS endpoint only accepts authentication from accounts that can authenticate against Azure Government (login.microsoftonline.us). This means:

External User Account Type	Can Open GCC High RMS-Protected Files?
Entra ID account in another GCC High tenant	Yes: if added to label permissions
Entra ID account in a commercial tenant	Only if Cross-Cloud B2B trust is configured (see Cross-Tenant Collaboration)
Microsoft Account (personal)	No
Google / federated identity	No

The options are:

1. Cross-Cloud B2B: configure Entra External Identities cross-cloud trust to allow the commercial tenant's users to authenticate against GCC High (requires steps in both tenants; see 6-6).
2. Unprotect for external delivery: downgrade to a label without encryption for the specific document being shared, using a justified override, and share via a Confidential SharePoint link instead of email attachment.
3. Move the partner to GCC High: the cleanest solution for long-term DoD supply chain relationships.

Commercial

For commercial tenants, any external user with an Entra ID or Microsoft Account can be added to a label's permission list. The practical guidance:

• Add external users by email address in the label's Assign Permissions Now settings, or use a security group that includes external guests.
• External users who receive a protected file and do not have an Entra ID account will be prompted to create a free Microsoft Account: this is acceptable for low-sensitivity content but not for Restricted.
• For Restricted content, restrict permissions to your tenant's own security groups only and do not grant external access. Share via a tented SharePoint site with B2B guest access instead.

Rights Matrix for External Collaboration

When adding external parties to a label's permissions, assign the minimum rights:

Scenario	Recommended Rights
External reviewer (read-only)	Viewer (View, Print)
External co-author (active collaboration)	Co-Author (View, Edit, Save, no Print, no Copy)
External approver (must be able to forward)	Reviewer (View, Reply, Forward)
No external access ever	Do not add external users; configure label as internal-only

The Co-Author rights set (not Co-Owner) is the appropriate choice for most partner collaboration: it allows editing but prevents the external party from re-sharing or modifying permissions.

Authorized Partner File Sharing: End-to-End Workflow

The following workflow combines tented projects, DLP Allowed Domains, and label permissions into a structured process for sharing sensitive content with an authorized partner.

Setup (one-time per partner relationship):

1. Add the partner's tenant domain to the DLP Allowed Domains exception list for sensitive label policies (see DLP Policies).
2. Configure Cross-Tenant Access Settings to allow B2B guest creation from the partner tenant (see Cross-Tenant Collaboration).
3. Create a tented project site with the appropriate container label (in GCC High the sublabel that matches the contract, which for a site that admits partner guests is CUI (Basic), since the CUI//SP-CTI and CUI//SP-EXPT container settings admit no guests; Confidential in commercial).
4. Invite partner users as B2B guests or configure a shared channel.

Per-deliverable:

1. Author the document inside the tented site: it inherits the library's default file label, always a sublabel and never the CUI parent (CUI (Basic) in GCC High; Confidential in commercial).
2. If the document requires Rights Management encryption, add the specific partner users (or partner tenant domain) to the label's external permissions.
3. Share via the tented SharePoint site link (not email attachment): DLP Allowed Domains ensures only the approved partner domain can access.
4. Insider Risk Management monitors for unusual download volumes from the partner-accessible site.

Offboarding a partner:

1. Remove B2B guests from the team and site.
2. Revoke any outstanding SharePoint sharing links.
3. If RMS-protected files were shared, revoke the use license via the RMS portal (requires Azure Information Protection P2).

Bring Your Own Key (BYOK) and Double Key Encryption (DKE)

Standard Purview label encryption uses Microsoft-managed keys stored in Azure Key Vault. BYOK and DKE are advanced options for organizations that need to control or restrict Microsoft's access to encryption keys.

BYOK: Customer-Managed Keys

With BYOK, you own the tenant root key in Azure Key Vault and authorize the Azure Rights Management service to use it: a custom role carrying key read, sign, and decrypt on a vault dedicated to that service. The service then uses the key for every protection and consumption request, and the Microsoft 365 services that need plaintext (DLP, anti-malware, search, eDiscovery) keep working, so BYOK changes who can revoke and audit the key, not who can read the data. Revoking the vault permission stops the service from that moment; it does not retroactively hide content. Key Vault logging is the independent record that only the service used the key.

BYOK manages the tenant's RMS root key, not a separate key per label. Activating a new key archives the old one; content protected under the old key stays readable through the archived key and is not re-encrypted, existing clients move to the new key over a few weeks, and every protection template is re-signed, so do not rotate casually.

GCC High (CMMC)

BYOK is GA in GCC High. The key must be 2048-bit RSA; the Azure Rights Management service accepts no other length. Put the Key Vault (Premium tier for an HSM-protected key) in Azure Government; Learn pairs the rms.aadrm.us endpoint with US Gov Virginia or US Gov Arizona, and the compliance driver, not latency, decides between them. Create the key on-premises and import it (a key generated inside Key Vault cannot be exported, so there is no copy outside Microsoft), enable soft delete and purge protection before the import, and grant the Rights Management service principal 00000012-0000-0000-c000-000000000000 a custom role with key read, sign, and decrypt on a vault used for nothing else.

# Connect to AIP service (GCC High endpoint)
Connect-AipService -EnvironmentName AzureUSGovernment

# Import your BYOK key
Use-AipServiceKeyVaultKey -KeyVaultKeyUrl "https://your-keyvault.vault.usgovcloudapi.net/keys/rms-key/version"

# Inspect RMS tenant-key identifiers, then activate the intended key.
Get-AipServiceKeys
Set-AipServiceKeyProperties -KeyIdentifier "<RMS-tenant-key-identifier>" -Active $true

CMMC does not require BYOK. SC.L2-3.13.10 (establish and manage cryptographic keys) is met with Microsoft-managed keys and a written description of who holds and rotates them; BYOK moves that custody to your Key Vault, which organizations handling CUI Specified categories sometimes choose so that the key-management evidence is theirs to produce.

Commercial

BYOK is appropriate for commercial organizations subject to HIPAA (where a Business Associate Agreement with Microsoft does not fully address key access concerns), financial services firms subject to OCC or FINRA examination, and any organization whose legal counsel advises retaining exclusive key control.

The Azure Key Vault for BYOK can be in any commercial Azure region. Use HSM-backed keys (--kty RSA-HSM) for FIPS 140-2 Level 3 key protection.

Double Key Encryption (DKE)

DKE encrypts content with two keys: Microsoft's key and a second key that you host on-premises or in your own Azure infrastructure. Microsoft's RMS service cannot decrypt DKE-protected content alone: both keys are required simultaneously. This means:

• Microsoft has zero access to DKE-protected content
• Content cannot be decrypted during eDiscovery by Microsoft
• Content cannot be accessed if your DKE key server is offline

DKE is an option for unclassified content whose approved protection design requires a customer-controlled second key. It does not authorize classified information on an unclassified system. The operational costs are significant:

Limitation	Impact
No mobile access	iOS/Android Office apps cannot decrypt DKE content
No web access	Office for the web (browser) cannot decrypt DKE content
No eDiscovery	Content is opaque to Microsoft Purview eDiscovery and Compliance Search
No Copilot	Microsoft 365 Copilot cannot process DKE-protected files
Key server availability	If your DKE key service is down, no one can open DKE-protected files

DKE Architecture:

User opens DKE-protected file in Office desktop app
  → Office contacts Microsoft RMS (first key decryption)
  → Office contacts your DKE key service (second key decryption)
  → Both keys required to produce the content encryption key
  → File decrypts locally in Office

Deploy the DKE key service as an Azure App Service or on-premises IIS service using the Microsoft DKE reference implementation. The service must be reachable by all users who will open DKE-protected content.

GCC High (CMMC)

For GCC High, host the DKE key service where the System Security Plan already draws the boundary: an Azure Government App Service (*.azurewebsites.us) or an on-premises IIS server inside the CUI enclave, behind a custom hostname on a domain verified in the GCC High tenant. Reachability is not the question (a commercial App Service URL answers from a GCC High client); the questions are whether a second key that gates CUI may sit on a service outside the assessed boundary, and whether the app registration lives in the GCC High tenant with ValidIssuers and JwtAuthorization in appsettings.json pointed at that tenant's sign-in endpoints. Learn documents only the commercial endpoints for those two values, so test the Office client flow in the tenant before publishing a DKE label.

DKE is not required by CMMC Level 2. It may be appropriate for organizations anticipating CMMC Level 3 certification or handling Specified CUI (the CUI//SP-CTI and CUI//SP-EXPT sublabels) whose authority imposes statutory or regulatory key custody requirements.

Commercial

For commercial organizations, DKE is rarely warranted. The operational constraints (no mobile, no browser, no Copilot) make it impractical for most content. BYOK with a HSM-backed key in Azure Key Vault provides strong key custody guarantees without DKE's access restrictions.

Consider DKE when the approved design requires the cloud provider to lack independent decryption capability and the client/workload restrictions are acceptable. Keep classified workloads on separately authorized systems.