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
• The default sensitivity label applied to new files created inside the container
• 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

In the container label's Files settings, configure Default label for documents to automatically apply a file-level label (e.g., Confidential or CUI — Basic) to all new documents created within the site. This ensures files created inside the tented project are labeled from the moment of creation rather than relying on users to label manually.

4. Lock the container label

Configure the label policy to require justification when downgrading a site's sensitivity label. This prevents a user from switching a Project — NDA site to Internal to loosen sharing restrictions.

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 — Program (Confidential)	Existing guests only (approved prime only)	CUI — Basic	Active contract work
CUI — Specified Program	No external sharing	CUI — Specified	ITAR or Privacy Act-covered work
General — Partner	New and existing guests	Internal	Non-CUI partner coordination

NIST SP 800-171 Rev. 3 3.1.3 (control CUI flow) and 3.1.1 (limit access to authorized users) are satisfied together by the container label: access is scoped to team members, external sharing is restricted to the approved partner domain, and the default file label ensures all content is labeled for DLP enforcement.

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.

Configure the container label with Private team privacy and No external sharing for the most sensitive projects, then add specific B2B guests or shared channel participants as needed. The container label's privacy setting prevents the team from appearing in Teams search results for internal users who are not 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

This is a critical constraint: a defense prime contractor in GCC High cannot simply email an RMS-protected file to a subcontractor on a commercial tenant and expect them to open it without additional configuration. 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 sensitivity label (CUI — Basic in GCC High; 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 default file label (e.g., 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 supply the root key in your own Azure Key Vault. Microsoft's RMS service uses your key for encryption operations but cannot export it. BYOK protects against:

• Compelled disclosure via legal process served to Microsoft
• Microsoft insider access to key material

BYOK applies to the entire tenant's RMS service — it is not per-label. All sensitivity label encryption in the tenant uses the customer-managed key.

GCC High (CMMC)

BYOK is available in GCC High. The Azure Key Vault instance must be deployed in an Azure Government region (usgovvirginia, usgovtexas). The key must be an HSM-backed RSA 2048 or 4096 key.

# 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"

# Set as active tenant key
Set-AipServiceKeyProperties -KeyIdentifier "https://your-keyvault.vault.usgovcloudapi.net/keys/rms-key/version" -Active $true

CMMC does not explicitly require BYOK, but NIST SP 800-171 Rev. 3 3.13.10 (employ cryptographic mechanisms) and the emerging CMMC Level 3 requirements around key management may make BYOK appropriate for organizations handling CUI Specified categories.

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 appropriate only for the most sensitive CUI Specified categories (e.g., SAP-adjacent data, classified program information handled in unclassified systems). 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)

In GCC High, the DKE key service should be deployed in Azure Government (azurewebsites.us or on-premises within the GCC High network boundary). Commercial Azure App Service URLs (azurewebsites.net) will not be accessible from within the GCC High trust boundary.

DKE is not required by CMMC Level 2. It may be appropriate for organizations anticipating CMMC Level 3 certification or handling categories of CUI Specified that are subject to 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 only if your organization is subject to a regulatory requirement that explicitly prohibits cloud-provider access to key material — for example, certain classified contract vehicles that permit only unclassified processing with DKE as the access control boundary.