Sensitivity Labels

Sensitivity labels are the foundation of Microsoft Purview's protection strategy. The label-based controls in this part (encryption, container settings, the label-conditioned DLP rules, and the Copilot reading gate) exist only for content that carries a label, so the taxonomy is designed before any of them. Content-based controls do not wait: DLP rules on sensitive information types, Insider Risk Management scoring, and the oversharing assessments run on unlabeled content and start alongside the label work.

Label Taxonomy

Label priority numbers run opposite to DLP priority numbers

In the tables below, a higher priority number means a more sensitive label: the higher-priority label is what wins inheritance and override decisions, and it is what Copilot displays when a response draws on mixed content. The Purview portal lists labels lowest-priority-first, so your most restrictive label belongs at the bottom of the Information Protection → Labels list, least restrictive at the top; reorder with the label's priority options (move up/down/top/bottom, or assign the number directly) (label priority). DLP policies use the number the other way around: there, 0 is the highest priority and policies evaluate lowest-number-first. Keep the two conventions straight when reading any Priority column in this part of the book.

GCC High (CMMC)

CUI-Aligned Label Hierarchy

CMMC AC.L2-3.1.3 requires organizations to control the flow of CUI based on the CUI Registry categories. The GCC High taxonomy gives users three top-level choices, Public, Internal, and CUI. CUI is a parent label that opens to three sublabels, one per handling case; the parent itself is never applied to anything:

Priority	Name	Display name	Parent	Scope	Container label	Encryption
0	Public	Public	none	Files, Emails	No	None
1	Internal	Internal	none	Files, Emails, Groups and sites	Yes	None
2	CUI	CUI	none (parent; cannot be applied)	Files, Emails, Groups and sites	n/a	n/a
3	CUI-Basic	CUI (Basic)	CUI	Files, Emails, Groups and sites	Yes	All Employees Co-Author; approved partner domains Viewer; 30 days offline
4	CUI-SP-CTI	CUI//SP-CTI	CUI	Files, Emails, Groups and sites	Yes; external sharing: none	All Employees Co-Author; approved partner domains Viewer; 30 days offline
5	CUI-SP-EXPT	CUI//SP-EXPT	CUI	Files, Emails, Groups and sites	Yes; external sharing: none	sg-us-persons, Co-Author, 7 days offline

Name is the object name, the string PowerShell (Get-Label) and policy conditions reference; Display name is what users see in the picker and what the footer banner repeats. Organizations that hold Privacy Act data add a fourth sublabel, CUI//SP-PRVCY, the same way; this book does not build it out.

User-Facing Descriptions

Write label descriptions for end users, not administrators. The description appears in Office client tooltips; the color appears in the picker and on the label button:

Label	Color	User description
Public	Green	Approved for public release.
Internal	Blue	Internal business information not cleared for external release. No special handling required.
CUI (parent)	Yellow	Controlled Unclassified Information. Choose the sublabel that matches the document's marking or the contract's CUI guidance.
CUI (Basic)	Inherited from CUI	CUI whose authority does not specify handling. NIST SP 800-171 baseline applies.
CUI//SP-CTI	Inherited from CUI	Controlled Technical Information under DFARS 252.204-7012. Carries a DoD distribution statement.
CUI//SP-EXPT	Inherited from CUI	Export controlled under ITAR or EAR. US persons only.

The color lives on the CUI parent (on the modern label scheme, the CUI label group). The wizard has no color field on a sublabel, because a sublabel inherits the color of its parent or group (Learn), so all three CUI sublabels show yellow. The portal offers no separate color per sublabel (the orange and red some taxonomies assign to CTI and EXPT); the banner text tells them apart.

Basic versus Specified

Basic and Specified are the two handling classes, and the class comes from the law behind the information. Basic means the law says protect it, so the NIST SP 800-171 baseline applies; Specified means the law says how, and the sublabels exist because those rules change both the banner and the permissions.

Two categories cover most defense-contractor CUI. Controlled Technical Information is Specified under DFARS 252.204-7012 and DoD Instruction 5230.24: banner CUI//SP-CTI, carrying a distribution statement B through F (registry entry). Export Controlled is Specified under ITAR, 22 CFR 120.21: banner CUI//SP-EXPT; under some other export authorities the same category is Basic, and the registry's authority table decides per citation (registry entry). A Specified banner must carry the SP- category; a Basic banner is CUI with the category optional; when a banner carries both, Specified categories are listed first. Who marks the document, the government or your own employee, is a separate axis and does not change the class.

The CUI Registry at archives.gov/cui is authoritative. Map your specific data types to registry categories before finalizing label names.

How sublabels behave in Purview

A parent label is a grouping and cannot be applied to anything; a file, an email, a site, or a group always carries a sublabel. Each sublabel carries its own settings (scope, markings, encryption, container settings) and inherits nothing from the parent but its color, so the three CUI sublabels are configured one at a time. A label policy publishes the three sublabels explicitly: on the classic label scheme, select the CUI parent alongside them (Learn: when you select a sublabel, also select its parent label), and on the modern scheme the CUI label group is not selectable in a publishing policy, so the sublabels alone are published. Either way users see CUI in the picker as the entry that opens to the three sublabels. A DLP condition on sensitivity labels can select the parent to cover every sublabel in one rule. An auto-labeling policy is the exception: it names the sublabel to apply, and a policy that names the parent runs and labels nothing (Learn). Container labels on sites and groups are applied as sublabels. In the priority list the parent appears immediately before its sublabels, which is why CUI holds priority 2 and its sublabels 3 through 5. Learn now documents label groups as the replacement for parent labels, the modern label scheme that a tenant with no sensitivity labels yet, a tenant created from October 1, 2025, or a migrated tenant is already on: a group carries only a name, display name, description, color, and priority, users see the same two-tier picker, and a migrated tenant keeps its sublabels, so the model here reads the same under either scheme (Sublabels that use parent labels or label groups; create labels under either scheme).

Content Marking: CUI Banner and Designation Indicator

NARA 32 CFR Part 2002 requires a CUI banner and a designation indicator on documents. Configure the footer as the banner and the header as the designation indicator, per sublabel; the parent carries no markings because it is never applied:

Label	Footer (banner)	Header (designation indicator)
Internal	Internal	none
CUI (Basic)	CUI	Controlled by: [Organization]. POC: [name, email]. Add the CUI category and any dissemination control per the contract's CUI guidance when required.
CUI//SP-CTI	CUI//SP-CTI	Controlled by: [Organization]. CUI Category: CTI. Distribution Statement [B through F, per contract]. POC: [name, email].
CUI//SP-EXPT	CUI//SP-EXPT	Controlled by: [Organization]. CUI Category: EXPT. Export controlled: US persons only. POC: [name, email].

Public carries no marking. Replace the bracketed placeholders with your organization's values when you create the label. A marking is static text per label, so where the distribution statement varies by contract, keep the header generic and rely on the statement printed in the document itself, which the CUI - Distribution Statement SIT in the Classifiers chapter already detects.

Encryption (Assign permissions now)

CMMC SC.L2-3.13.16 requires protecting the confidentiality of CUI at rest, and SC.L2-3.13.8 requires cryptographic protection of CUI in transmission. For files that leave the service (contractor endpoints, partner sharing), encryption via Rights Management answers both at the file level, because the protection travels with the file, and every CUI sublabel encrypts with Assign permissions now. The sublabels differ in who holds rights and how long a use license works offline:

Sublabel	Users or groups	Permissions	Allow offline access	User access expires
CUI (Basic)	All Employees: the wizard's Add all users and groups in your organization entry, every tenant member and no guests. Second entry: each approved partner domain from the CAB's approved-domain list (Add specific email addresses or domains)	Co-Author for All Employees; Viewer for the partner domains	30 days	Never
CUI//SP-CTI	All Employees, plus each approved partner domain as a second entry, the same list as CUI (Basic)	Co-Author for All Employees; Viewer for the partner domains	30 days	Never
CUI//SP-EXPT	sg-us-persons: a mail-enabled security group (or Microsoft 365 group) of verified US persons; the wizard rejects a security group that is not email-enabled	Co-Author	7 days	Never

• Co-Author (labeled Editor in the current wizard) grants view, edit, copy, and print without Full Control, so a recipient cannot strip the encryption or change its permissions; the user who applies the label is the Rights Management issuer and always keeps Full Control.
• Never expire: CUI is retained for years, expiring keys creates a recovery burden, and an auto-labeling policy cannot write an encrypting label to SharePoint or OneDrive files unless expiry is Never.
• Offline access is the revocation lag. The use license is cached for the offline window and group membership is not re-evaluated until it lapses, so a user removed from sg-us-persons can keep opening cached CUI//SP-EXPT files for up to 7 days. The 30-day window on the other two sublabels is the tenant default.
• Why the entries differ. Delivery and decryption are two gates. The Exchange DLP rules treat the two sublabels differently in the deployed phase. For CUI//SP-CTI the rule blocks: an approved partner domain passes on the exception, anyone else is blocked, with a justified override. For CUI (Basic) the rule's action is Alert only: the message is delivered to any recipient, the approved-domain exception only suppresses the alert, and the block is deferred to the Managed phase. What keeps an unapproved recipient from opening a CUI (Basic) attachment is the label's encryption, not the DLP rule. An Assign permissions now label is a static list: a partner not on it receives the attachment and cannot open it, whatever the DLP rule allowed, and guest access to the site does not help, because All Employees excludes guests. So the same approved partner domains sit on both sublabels as a second entry with Viewer rights, and the approved-domain list is one CAB item that feeds the label entries and the Exchange exception together. A domain entry grants every verified domain and every mailbox of the partner tenant; the contract file, not the entry, is the authorization, and the distribution statement printed in the document still governs who at the partner may read it. CUI//SP-EXPT carries no partner entry: it uses sg-us-persons because ITAR treats disclosure to a non-US person inside your own tenant as an export, membership in the group is the evidence of US-person verification, and the matching DLP rule blocks with no override. Partner cloud matters: a partner in GCC High or DoD opens the file with no further setup; a partner in a Commercial tenant needs Microsoft cloud settings and the partner organization configured on both sides, and labeled files opening from GCC High in a Commercial tenant works in the lab but is not on Microsoft's supported list, so open a support case before a contract depends on it. Adding a domain to an existing label reaches files already labeled at the reader's next authentication; removing one lags up to the offline window.

Commercial

Regulatory-Aligned Label Hierarchy

For commercial organizations, labels map to data sensitivity tiers rather than government classification categories:

Priority	Label	Scope	Encryption	Auto-labeling
0	Public	Files, Email	No	No
1	Internal	Files, Email, Site, Group	No	Yes
2	Confidential	Files, Email, Site, Group	No	Yes
3	Restricted	Files, Email, Site, Group	Yes	No

Public: Data open to public inspection by law or released through public channels. No controls required.

Internal: Operational content that originates within the organization and may be shared externally when appropriate. Label is informational only; no encryption or sharing restrictions. Applied automatically as a baseline for unlabeled content.

Confidential: Content subject to regulatory requirements: GLBA, FERPA, HIPAA, PCI-DSS. Applied automatically when financial or PII SITs are detected at high confidence. No encryption by default (avoids user friction during the Foundational deployment phase), but external sharing is alerted via DLP.

Restricted: Content requiring the most stringent access controls: board materials, M&A data, HR disciplinary records, credentials. Encryption enabled with Assign Permissions Now. Not applied automatically: requires intentional user action with a mandatory justification prompt.

User-Facing Descriptions

Write label descriptions for end users, not administrators. The description appears in Office client tooltips:

Label	User Description
Public	Data that is publicly available or has been approved for public release.
Internal	For internal use. May be shared externally when appropriate. No special handling required.
Confidential	Contains sensitive personal or financial information subject to regulatory requirements. Share only with authorized parties.
Restricted	Highly sensitive. External sharing not permitted. Access from authorized devices only.

Label Scopes: Encryption vs. Container

When creating a sensitivity label in Purview, you choose one or more scopes: each scope applies the label to a different class of object. A single label can carry multiple scopes simultaneously, which is why one label can both encrypt a file AND control the SharePoint site it lives in.

Scope	What it protects	What it configures
Files & emails (encryption scope)	Individual documents, emails, and PDFs	RMS encryption with usage rights; offline access window; co-author/reader permissions; authentication context requirements
Groups & sites (container scope)	SharePoint sites, Teams, Microsoft 365 Groups	External sharing settings; unmanaged device access restrictions; privacy (public/private); default share link permissions
Schematized data assets (E5)	Azure SQL, Synapse, Data Lake	Label propagation in Purview Data Map for structured data
Meetings (E5)	Calendar events and meeting invites	RMS encryption on meeting content, watermarking

The Critical Distinction

• Encryption scope protects the content. The file travels encrypted. If it's exfiltrated, emailed externally, or copied to removable media, it remains unreadable to anyone outside the authorized group.
• Container scope protects the location. The SharePoint site enforces sharing and access policies on every file inside it, including files that don't individually carry the label yet.

These complement each other rather than duplicate.

Recommended Configuration for CUI Labels

These are the GCC High sublabel settings from the taxonomy, laid out per scope. Every setting lives on the sublabel; the CUI parent carries none.

Encryption scope (Files & emails):

Setting	Recommended Value	Why
Encrypt files and emails	On, per sublabel	RMS encryption is the non-negotiable file-level control
Assign permissions now	Yes	Policy-enforced, not user-chosen
Users or groups	All Employees (Co-Author) plus the approved partner domains (Viewer) for CUI (Basic) and CUI//SP-CTI; sg-us-persons only for CUI//SP-EXPT	Decryption rights follow the approved-domain list the Exchange exception uses; export-controlled content stays with verified US persons
Permissions	Co-Author (read, modify, print, no full control)	Co-Author prevents users from modifying label permissions themselves
User access expires	Never	Prevents lockout on older documents; auto-labeling cannot write an encrypting label in SharePoint or OneDrive otherwise
Allow offline access	30 days for CUI (Basic) and CUI//SP-CTI; 7 days for CUI//SP-EXPT	The offline window is the lag before a revoked user loses access to cached files

Container scope (Groups & sites):

Setting	Recommended Value	Why
External sharing	Existing guests only for CUI (Basic); Only people in your organization for CUI//SP-CTI and CUI//SP-EXPT	The Specified sublabels never share externally at the site level; see Container Labels
Access from unmanaged devices	Web-only for CUI (Basic); Block access for CUI//SP-CTI and CUI//SP-EXPT	Forces managed devices for CUI site access, independent of any CA policy
Default share link	Specific people	Prevents "Anyone with the link" from being the default
Privacy	Private	CUI sites should not be discoverable via search

Enabling container support requires a one-time tenant configuration

Before container labels take effect, you must enable sensitivity labels for Microsoft 365 Groups and SharePoint sites at the tenant level. See the Container Labels section for the PowerShell commands. This is a one-time step per tenant, not per label.

Label Sync Timing

Sensitivity labels created and published in Purview need to sync into Microsoft Entra ID before they become available for application to container objects: Microsoft 365 Groups, SharePoint sites, and Microsoft Teams sites. For tenants stood up after September 2019, this sync happens automatically with no admin action required. For tenants that pre-date September 2019, the Execute-AzureADLabelSync cmdlet in Security & Compliance PowerShell forces the sync.

The cmdlet's scope is narrower than people often assume. It moves labels from Purview into Entra ID for container-label application. That's all. The other two sync paths are separate, as the table shows:

Sync path	Forced by Execute-AzureADLabelSync?	How it actually works
Purview → Entra ID (container-label availability)	✅ Yes: this is the cmdlet's purpose	Automatic for tenants post-September 2019; cmdlet forces it for older tenants or as a troubleshooting step
Purview → Azure Rights Management service (encryption configuration)	❌ No	Automatic on Microsoft's schedule; no admin-runnable cmdlet exists to force it
Purview → Office client policy cache (label visibility to end users in Word/Excel/Outlook)	❌ No	Automatic ≈1 hour after publishing the policy; force per-client refresh by signing out / back in or restarting the Office app

To run the cmdlet (GCC High):

Import-Module ExchangeOnlineManagement
Connect-IPPSSession `
    -UserPrincipalName admin@yourtenant.onmicrosoft.us `
    -ConnectionUri https://ps.compliance.protection.office365.us/powershell-liveid/ `
    -AzureADAuthorizationEndpointUri https://login.microsoftonline.us/organizations
Execute-AzureADLabelSync
Disconnect-ExchangeOnline -Confirm:$false

Both sovereign URIs are mandatory for GCC High: the commercial defaults fail with unable to find tenant. See Connect to Security & Compliance PowerShell — Microsoft 365 GCC High for the canonical reference. The account needs Compliance Administrator or Compliance Data Administrator.

When to actually run it

• One-time container-labeling enablement: immediately after the EnableMIPLabels = True Graph call for the Group.Unified setting that turns on container labels for the tenant. This is the canonical use case and is captured in the Container Labels section below.
• Troubleshooting: if a newly-created label doesn't appear in the SharePoint site-label picker after several hours, run this as a remedial step. For tenants post-September 2019, this is rarely needed.
• Not "after every label change." Microsoft does not document this cmdlet as a recurring sync tool.

Policy-First Design

Before creating labels in the Purview portal, document the label policy decisions:

Question	Decision Needed
How many labels?	More labels = more user confusion. Limit to 3-5 top-level choices: the GCC High taxonomy shows three (Public, Internal, CUI), with CUI opening to its three sublabels.
Default label for new files?	Typically Internal in both clouds, not Public, and never an encrypting sublabel or the CUI parent (a parent cannot be applied, so never choose it as the default).
Default label for email?	Typically the same or one level lower than files.
Mandatory labeling?	Yes: required for regulated environments.
Justification on downgrade?	Yes: critical for audit trail. Pair with downgrade reporting script.
User ability to remove labels?	Allow with justification; track in Activity Explorer.

Incremental Rollout to a Test Group

Deploying sensitivity labels, especially with mandatory labeling and encryption, changes how users save files, send email, and access documents. A direct-to-production rollout risks user frustration, helpdesk flood, and workflow breakage. Use a three-phase rollout to surface issues before they affect the full user population.

Key concept: The label itself is tenant-wide once created, but visibility and enforcement are controlled by the label policy. You can create a label, publish it only to a test group, and the rest of the tenant sees nothing. This makes staged rollouts straightforward.

Stage 1: Create but don't publish (1 week)

1. Create the label in Purview with the target configuration (encryption scope, container scope, permissions, offline access window)
2. Do not publish it: without a label policy, the label is invisible to end users
3. Review the definition in Purview with the appropriate information-protection administrative role. That role does not automatically publish the label to Office clients.
4. To apply the label in Office and test encryption, publish it to a restricted test account through a pilot policy as described in Stage 2.

This phase catches configuration errors (wrong permission group, overly restrictive settings, missed offline access) before any end user is affected.

Stage 2: Publish to a test group (1–2 weeks)

1. Create a label policy named Label Policy - Test (or similar) and publish it to a security group, e.g., EID_Sensitivity_Label_Test_Users, containing 5–10 representative users
2. Enable mandatory labeling and justification on downgrade in the test policy: the test should reflect real production behavior, not a softer test configuration
3. Set the default label to match the production plan
4. Let test users work normally for 1–2 weeks, creating documents, sharing, collaborating, attempting external sends

What to monitor in Activity Explorer:

• Label application events: are users applying the intended labels?
• Label downgrade events: are users justifying downgrades appropriately?
• DLP rule matches: are protected documents triggering expected DLP policies?
• User notifications and policy tips: are users seeing and responding to them?

Criteria to advance to Stage 3:

• No unresolved label-related helpdesk tickets in the past 7 days
• Mandatory labeling is applying without breaking user workflows
• Encryption is working across Office apps, Outlook, SharePoint, and mobile clients
• External sharing behavior matches expectations

Stage 3: Expand to the broader population

Once the test group operates cleanly:

Approach	How	When to use
Expand the existing test policy	Edit Label Policy - Test and add the broader group (or All Users) to the publish scope	Fastest: no new policy to maintain. Use if the test policy settings match production requirements exactly.
Create a production policy	Create Label Policy - Production with the target scope, then retire the test policy	Preferred for larger deployments: keeps the test policy available for future label changes, allows different default labels or mandatory settings between test and production populations

Label policies are how you scope exposure, not labels themselves

A label is created once and exists tenant-wide. Multiple label policies can publish the same label to different groups with different defaults, mandatory settings, and justification requirements. This lets you roll out the same label progressively across departments or regions without creating duplicate labels.

Don't skip mandatory labeling in the test phase

If the test group runs without mandatory labeling but production will have it on, you're testing a different configuration than you'll deploy. Users will hit the mandatory labeling prompt for the first time when the policy expands, creating a wave of confusion at exactly the wrong moment. Test with the real settings.

Auto-Labeling

Auto-labeling applies labels based on SIT detection without user involvement. Two modes operate independently:

Client-side auto-labeling: runs in Office apps while the user is editing. Shows a notification bar recommending or applying the label. Requires the Office client to be policy-aware (M365 Apps for Enterprise, not Office LTSC).

Service-side auto-labeling: runs in the Purview backend on existing content in Exchange, SharePoint, and OneDrive. Applies labels to already-stored files without user involvement. Operates as a simulation first; review results before enabling enforcement.

Auto-Labeling Policy Design

Label	Trigger SITs	Confidence	Mode
Internal	No SITs: applied to all unlabeled Office files	N/A	Default label policy
Confidential (Commercial)	Financial SIT group or PII SIT group	High	Auto-apply. In GCC High, PII and financial data are not CUI unless the contract says so; leave them to the DLP SIT policies
CUI (Basic) (GCC High)	CUI Designation Indicator: a bare CUI token with no category	High	Simulation first, then auto-apply
CUI//SP-CTI (GCC High)	CUI - Distribution Statement or CUI - DoD Contract Number	High	Auto-apply
CUI//SP-EXPT (GCC High)	CUI - Export Control	High	Auto-apply
Restricted (Commercial)	No SIT trigger: user-applied only	N/A	Recommend only

The CUI SITs are defined in the Classifiers chapter. A service-side auto-labeling policy applies exactly one label, so the GCC High mapping is three policies, one per sublabel, each naming its sublabel and never the CUI parent. When a document matches more than one of them, the highest-priority sublabel wins (Learn), so a distribution-statement document that also cites ITAR lands on CUI//SP-EXPT. The bare-token rule is the noisy one: prose that merely mentions CUI matches it, so run that policy in simulation and review the matches before enforcing.

Service-Side Simulation

Always run service-side auto-labeling in Simulation mode for at least 7 days before enabling enforcement. Review the simulation report in the Purview portal to identify false positives before labels are written to production files.

PDF Labeling

PDF labeling is two distinct features, and both have to be enabled separately. Tenants that turn on one and assume the other follows are usually surprised when search and DLP appear to ignore PDF content.

Track	What it covers	Default in GCC High
Office desktop export	When users do File > Save As > PDF, File > Export > PDF, or Share > Send a Copy > PDF in Word, Excel, or PowerPoint, the resulting PDF inherits the source file's label and any encryption. Logged with SensitivityLabeledFileRenamed in the unified audit log.	On (assuming sensitivity labeling is enabled and labels are published)
SharePoint and OneDrive processing	Whether SP/OD can read inside encrypted PDFs to support search, eDiscovery, DLP, auto-labeling policies, and default-label-on-library for PDFs	Off: opt-in via PowerShell

Without the second track, SP/OD silently fails to process encrypted PDFs. Office files keep working, PDFs become opaque to compliance: search results, DLP matches, and eDiscovery content all exclude PDFs without surfacing an error. This is documented behavior, not a bug: until PDF support is added, Microsoft confirms that for label-encrypted files "SharePoint can't process the content of these files so coauthoring, eDiscovery, DLP, and search aren't supported." The two settings stack: EnableSensitivityLabelforPDF requires EnableAIPIntegration = $true first.

Verifying current state

# GCC High — note the .us admin URL, not .com
Connect-SPOService -Url https://<tenant>-admin.sharepoint.us

Get-SPOTenant | Select-Object EnableAIPIntegration, EnableSensitivityLabelforPDF

The most common state for a tenant that has been doing labeling for Office files is EnableAIPIntegration = True and EnableSensitivityLabelforPDF = False: labeling appears to work, but PDF processing is silently dark.

Enabling

# Parent setting — required before the PDF child can be set
Set-SPOTenant -EnableAIPIntegration $true

# PDF support
Set-SPOTenant -EnableSensitivityLabelforPDF $true

The PDF flag requires SharePoint Online Management Shell 16.0.24211.12000 or later: Update-Module Microsoft.Online.SharePoint.PowerShell if older. Older versions fail with a generic parameter not found error rather than a helpful message. Propagation takes about 15 minutes after the cmdlet returns; do not test immediately. Primary sources: Set-SPOTenant cmdlet reference and Enable sensitivity labels for files in SharePoint and OneDrive § Adding support for PDF.

Gotchas

Gotcha	What happens
Signed PDFs aren't supported	Cryptographically signed PDFs can't be labeled: Microsoft explicitly excludes them. The label apply silently no-ops.
Print-to-PDF strips the label	Office warns the user and requires confirmation. With mandatory labeling on (see Mandatory Labeling), Print-to-PDF is unavailable entirely.
PDF/A + encryption is unsupported	The long-term archival format conflicts with label encryption. Office blocks the export when both are requested.
Auto-labeling load increases	Enabling PDF support pushes existing auto-labeling policies to also evaluate PDFs. The 100,000-files-per-day cap is shared across file types: large tenants can hit it on the first sweep.
Encrypted PDFs need label-aware readers	Microsoft Edge (Windows/Mac) reads them natively. Adobe Acrobat requires the Microsoft Information Protection plug-in. Other readers fail with a generic error.

Recommended posture for CUI

Both flags $true. The risk of leaving EnableSensitivityLabelforPDF off is meaningful in a CUI tenant: a user exports a labeled Word document to PDF, the PDF inherits the label and encryption (Track 1), but SharePoint cannot see inside it for DLP scanning or eDiscovery (Track 2 disabled). Match the PDF posture to the Office-files posture: if .docx is in scope for DLP, .pdf should be too.

Schedule the enablement during a low-activity window for tenants with large PDF inventories

Auto-labeling will process the entire existing PDF corpus on first enable. A tenant with hundreds of thousands of legacy PDFs can stall Office-file labeling for days while the PDF backlog clears against the 100,000-files-per-day cap. Enable late on a Friday or before a holiday weekend so the bulk processing completes before active editing resumes.

Container Labels

Container labels apply to Microsoft Teams, SharePoint sites, and Microsoft 365 Groups. They do not encrypt files: they control site-level settings.

A site or group receives a sublabel. In GCC High that means CUI (Basic), CUI//SP-CTI, or CUI//SP-EXPT, never the CUI parent, which cannot be applied. A tented project site for contract work carries the sublabel that matches the contract, CUI//SP-CTI for technical work and CUI//SP-EXPT for an export-controlled program, and the site's library default label follows the same rule.

Prerequisites: Container labels require a one-time setup:

# Enable MIP labels for M365 Groups in Entra
Install-Module Microsoft.Graph.Beta -Scope CurrentUser
Connect-MgGraph -Scopes "Directory.ReadWrite.All"

$template = Get-MgBetaDirectorySettingTemplate | Where-Object { $_.DisplayName -eq "Group.Unified" }
$settingParams = @{
    TemplateId = $template.Id
    Values = @(@{ Name = "EnableMIPLabels"; Value = "True" })
}
New-MgBetaDirectorySetting -BodyParameter $settingParams

# Sync labels from Purview to Entra ID — one-time after enabling container labels
# For GCC High, add -ConnectionUri and -AzureADAuthorizationEndpointUri to Connect-IPPSSession
# (see Label Sync Timing section above for the full sovereign-endpoint invocation)
Import-Module ExchangeOnlineManagement
Connect-IPPSSession
Execute-AzureADLabelSync

Container Label Settings

Label	External Sharing	Default Share Link	Unmanaged Device Access
Public	Allowed (Anyone)	Anyone with the link	Full access
Internal	New and existing guests	Specific people	Full access
Confidential / CUI (Basic)	Existing guests only	Specific people	Web-only (read)
Restricted / CUI//SP-CTI and CUI//SP-EXPT	No external sharing	Specific people	Blocked

All Employees excludes guest accounts, so a guest on a CUI (Basic) site can list files but cannot open the ones the label encrypted; when a partner must read them, grant the rights on the label itself with a named address or domain entry.

Mandatory Labeling and Justification

Enable mandatory labeling in the label policy to require users to select a label before saving or sending. In the label policy settings:

• Require users to apply a label: On
• Require users to provide justification to remove a label or lower its classification: On
• Provide users with a link to a custom help page: Link to your organization's data classification policy

Justification text is captured in the Unified Audit Log under the SensitivityLabelUpdated operation and is surfaced in Activity Explorer.

In GCC High the picker shows Public, Internal, and CUI; choosing CUI expands to the three sublabels, and the user must pick one, because the parent cannot be applied. One gap to plan for: the justification prompt does not apply between sublabels of the same parent (Learn), so relabeling a file from CUI//SP-EXPT to CUI (Basic) prompts for nothing. Check in your tenant whether the audit record for that change carries LabelEventType 2; if it does not, the report below misses it, and filtering Activity Explorer on label-changed events by old and new label is the fallback.

Label Downgrade Reporting

The following PowerShell script queries the Unified Audit Log for label downgrade and removal events in the past 7 days and emails a formatted HTML report.

# Connect to Security & Compliance
Connect-IPPSSession

# Build label ID-to-name lookup
$LabelLookup = @{}
Get-Label | Select-Object ImmutableId, DisplayName | ForEach-Object {
    if ($_.ImmutableId) {
        $LabelLookup[$_.ImmutableId.ToString()] = $_.DisplayName
    }
}

# Query audit log — downgrades and removals only
$EndDate = Get-Date
$StartDate = $EndDate.AddDays(-7)
$Events = Search-UnifiedAuditLog `
    -StartDate $StartDate -EndDate $EndDate `
    -Operations "SensitivityLabelUpdated","FileSensitivityLabelChanged","SensitivityLabelRemoved","FileSensitivityLabelRemoved" `
    -ResultSize 5000

$Report = @()
foreach ($EventObj in $Events) {
    $Data = $EventObj.AuditData | ConvertFrom-Json
    # LabelEventType: 1=Upgrade, 2=Downgrade, 3=Remove
    if ($Data.SensitivityLabelEventData.LabelEventType -in 2, 3) {
        $ActionType = if ($Data.SensitivityLabelEventData.LabelEventType -eq 3) { "Removed" } else { "Downgraded" }
        $OldLabel = if ($LabelLookup.ContainsKey("$($Data.SourceLabel)")) { $LabelLookup["$($Data.SourceLabel)"] } else { $Data.SourceLabel }
        $NewLabel = if ($Data.SensitivityLabelEventData.LabelEventType -eq 3) { "(Removed)" }
                    elseif ($LabelLookup.ContainsKey("$($Data.DestinationLabel)")) { $LabelLookup["$($Data.DestinationLabel)"] }
                    else { $Data.DestinationLabel }
        $Report += [PSCustomObject]@{
            Time          = $EventObj.CreationDate
            User          = $EventObj.UserIds
            Action        = $ActionType
            File          = $Data.ObjectId
            OldLabel      = $OldLabel
            NewLabel      = $NewLabel
            Justification = $Data.SensitivityLabelJustificationText
        }
    }
}

if ($Report.Count -gt 0) {
    $Report | Export-Csv -Path ".\LabelDowngrades_$(Get-Date -Format 'yyyy-MM-dd').csv" -NoTypeInformation -Encoding UTF8
    Write-Host "$($Report.Count) downgrade/removal events exported." -ForegroundColor Yellow
} else {
    Write-Host "No downgrade events found in the past 7 days." -ForegroundColor Green
}

Schedule this script to run weekly via a Logic App or Azure Automation runbook and send results to your security team. Retain the CSV output as audit evidence for compliance assessments (satisfies CMMC AU.L2-3.3.2 audit record review requirements).