Scenario: AVD — Enclave in Existing Tenant

The Problem This Solves

The standard AVD deployment treats AVD as a gateway to a GCC High tenant that secures access to CUI data. That model rests on a greenfield GCC High tenant assumption. The tenant boundary IS the enclave. If you are in the tenant, you are in the controlled environment. AVD enables secure access to this controlled environment without purchasing new laptops for everyone.

For an enclave in an existing tenant, the tenant boundary is NOT the enclave. CUI data, non-CUI workflows, managed devices, and personal devices coexist in the existing tenant. We limit assessment scope through AVD and associated CA policies, security attributes, and network controls.

	Greenfield Tenant	Existing Tenant
Isolation provided by	Tenant boundary	Policy (CA + DLP + device tags + network)
Threat model	External attackers; data residency	Internal: valid accounts on unmanaged or lightly-managed devices
AVD role	Delivery mechanism	Access control enforcement point
Device compliance requirement	Enclave data is only reachable from AVDs	Tenant data must be segmented to allow access only from AVDs

Relationship to the standard AVD deployment

Complete Scenario: Azure Virtual Desktop first. That article deploys the AVD host pool, session hosts, Azure Firewall, and the UDR that forces all session host egress through the firewall. This article builds the enclave layer on top of that foundation in two stages:

1. Precursors — Create the building blocks that enforcement policies read: device tags, Named Location, and sensitivity labels
2. CA Policies — Configure P004 (compliant device), B011/B012 (device and network blocks), and optionally B013/B014 (auth context blocks for E5 tenants)
3. DLP Policies — Configure the three Data Loss Prevention policies that enforce data-layer controls (required for E3 tenants; defense-in-depth for E5 tenants)

---

Enclave Architecture

The enclave is three interlocking layers, each targeting a distinct attack surface. Any one layer limits exposure; together they defeat primary account compromise, access from unmanaged devices, and data exfiltration risks.

Layer	Attack Surface	Mechanism	What It Defeats
Users	Account compromise during normal work	Dedicated CUI accounts separate from day-to-day identities using phishing-resistant auth	Primary account compromise reaching CUI
Devices	Access from uncontrolled endpoints	Device extension attribute (extensionAttribute15) on session host + Azure Firewall egress as Named Location, enforced by P004 (compliant device), B011 (device tag block), and B012 (network block)	CUI access from any device that is not a tagged, compliant session host routing through the firewall
Data	CUI files accessed outside the enclave or stored in non-designated locations	Purview sensitivity labels with RMS encryption (restricts decryption to enclave members), mandatory labeling, and three DLP policies (D001–D003)	Unlabeled content in CUI sites, CUI content in non-designated sites, and unlabeled email from enclave accounts

Users

Each enclave user operates with two separate Entra identities: a primary account for day-to-day work (email, Teams, non-CUI tasks) and a dedicated CUI account used exclusively to authenticate into the AVD enclave. The dedicated account:

• Is enrolled only in phishing-resistant authentication methods (FIDO2 or Windows Hello for Business) — no password fallback, no SMS
• Is not used for day-to-day activities — no email, no web browsing, no signing up for external services — which eliminates the most common credential delivery vectors (phishing, credential stuffing from breach databases)
• Is a member of AVD-Enclave-FCI-Users-MESG and scoped into enclave CA and DLP policies
• Has a login history limited to AVD broker authentication and CUI application access — anomalies stand out

The consequence: compromising a user's primary account through a phishing link opened in their daily email does not compromise their CUI account. The accounts have non-overlapping uses. The CUI account's attack surface is limited to the brief window when the user is actively working in the enclave.

Devices

Access to CUI resources is bound to AVD session hosts that are compliant (P004), carry a device extension attribute (extensionAttribute15 = AVD-CUI-Authorized), and originate from the Azure Firewall public IP registered as a Named Location in Entra. Three independent policies enforce this:

• P004 requires a compliant device for all cloud apps — excluding Azure Virtual Desktop, Azure Virtual Desktop Client, and Windows Cloud Login so the broker connection is not blocked
• B011 blocks access to all cloud apps (same exclusions) unless the request originates from a tagged session host
• B012 blocks access to all cloud apps (same exclusions) unless the traffic arrives from the Azure Firewall egress IP

P004, B011, and B012 are independent policies — a request must satisfy all three. The session host must be compliant, carry the tag, AND route through the firewall. The three AVD app exclusions allow enclave users to authenticate to the AVD broker from any device; once inside the session, the session host satisfies all three conditions.

Data

Purview sensitivity labels with RMS encryption protect CUI at the file level — only members of AVD-Enclave-FCI-Users-MESG can decrypt labeled files. Mandatory labeling ensures every document FCI users create carries the CUI - AVD label, and three DLP policies enforce data-layer controls:

• D001 blocks access to unlabeled content in designated CUI SharePoint sites — nothing without a CUI - AVD label is accessible
• D002 blocks access to CUI-labeled files that appear in any SharePoint site or OneDrive account not designated for CUI — this is the control that prevents the client admin from accidentally extending the enclave by creating a new site
• D003 blocks unlabeled outbound email from FCI accounts

RMS encryption on the CUI - AVD label restricts decryption to AVD-Enclave-FCI-Users-MESG. If CUI-labeled content is shared with or emailed to anyone outside the enclave group — internal or external — the recipient receives encrypted content they cannot open. No DLP policy is needed to block this sharing; the encryption makes the content useless to non-enclave recipients.

Combined with P004/B011/B012 restricting FCI authentication to the enclave, this creates a closed loop: FCI users can only work from the enclave, can only create labeled content, that labeled content can only persist in designated CUI sites, and labeled content is unreadable by anyone outside the enclave group.

---

Enclave Prerequisites

Enclave Licensing

Requirement	License
Device extension attributes (CA filter for devices)	Entra ID P1 (included in Microsoft 365 E3/F3 GCC High and above)
Conditional Access	Entra ID P1
Azure Firewall	Azure Government subscription
Sensitivity labels (manual + mandatory)	Microsoft Purview Information Protection Plan 1 (included in M365 E3 GCC High)
DLP for Exchange, SharePoint, OneDrive	Microsoft Purview Data Loss Prevention Plan 1 (included in M365 E3 GCC High)
Authentication context on SharePoint sites (B013/B014)	M365 E5 GCC High, SharePoint Advanced Management, or M365 Copilot license
Sensitivity labels for meetings and calendar events	M365 E5 GCC High or M365 E5 Compliance add-on
Auto-labeling	M365 E5 Compliance or Microsoft Purview add-on

What E5 adds to the enclave — and whether you need it

The enclave is fully functional at E3 licensing. P004, B011, B012, RMS encryption, mandatory labeling, and DLP policies D001–D003 close all practical access and exfiltration paths. E5 features are defense-in-depth — they add narrow protections for edge cases. Do not purchase E5 specifically for the enclave unless you need these features for other reasons.

E5 Feature	What it adds to the enclave	Without it (E3)
Authentication context (B013/B014)	Token-level enforcement: CUI files cannot be decrypted without a c1 claim obtained from within the enclave. Covers one narrow scenario — an FCI user who exfiltrates a file past all other controls and attempts to decrypt it with cached offline credentials within the 3-day offline window.	RMS encryption still restricts decryption to AVD-Enclave-FCI-Users-MESG. B011/B012 prevent FCI users from authenticating outside the enclave. The offline-credential scenario requires a successful exfiltration past Azure Firewall, DLP, and session host controls.
Sensitivity labels for meetings	Allows the CUI - AVD label to be applied to calendar events, protecting meeting invites and attachments with RMS encryption.	D003 blocks unlabeled email from FCI accounts but exempts system-generated calendar traffic (acceptance notices, cancellations) via the x-ms-exchange-calendar-originator-id header exception. Meeting invites created by the user are subject to mandatory labeling in Outlook, but calendar-generated responses are not.
Auto-labeling	Service-side policies scan CUI SharePoint sites and apply the CUI - AVD label to pre-existing or uploaded content without user action. Closes the gap for content uploaded through non-Office channels (drag-and-drop, API, migration tools).	D001 blocks access to unlabeled content in CUI sites. Combined with mandatory labeling in Office apps, the only gap is the brief DLP crawl window after a non-Office upload.
DLP for Teams chat and channels	Detects CUI-labeled content or sensitive data pasted into Teams messages, blocking delivery to non-enclave recipients. Closes the copy-paste gap where a user pastes CUI content into a chat message instead of sharing a file.	Files shared via Teams are stored in SharePoint/OneDrive and protected by RMS encryption. The gap is raw text pasted into chat, which is mitigated by session host clipboard restrictions at E3.
SharePoint Advanced Management	Site-level conditional access policies applied directly or via sensitivity labels. Data access governance reports. Restricted content discoverability.	The CUI - AVD label's Groups & sites scope blocks unmanaged device access and restricts external sharing at E3. DLP policies provide the remaining site-level controls.

Required Roles

Task	Role Required
Write device extension attributes	Device.ReadWrite.All via Microsoft Graph (Intune Administrator or Cloud Device Administrator)
Create Conditional Access policies	Conditional Access Administrator
Register Named Location	Security Administrator
Create and publish sensitivity labels	Compliance Administrator or Information Protection Administrator
Create and manage DLP policies	Compliance Administrator or DLP Compliance Management role group

Extension attribute writes are not separated from Global Admin

Unlike Custom Security Attributes, device extension attributes can be written by any identity with Device.ReadWrite.All — including Global Administrators. This means a GA could tag any device as AVD-CUI-Authorized. Mitigate this by monitoring writes to extensionAttribute15 in the Entra audit log and alerting on unexpected changes. The DLP controls (D002) provide a second layer — even if someone tags a non-enclave device, they cannot persist CUI content outside designated sites.

Dedicated CUI Accounts

Each enclave user requires a second Entra account dedicated to CUI work, separate from their primary identity.

Attribute	Guidance
UPN convention	A consistent suffix makes these accounts identifiable — firstname.lastname-secure@contoso.us
License	M365 E3 GCC High — sufficient for AVD, SharePoint, and CUI-related applications
Group membership	AVD-Enclave-FCI-Users-MESG only — do not add to distribution lists, shared mailboxes, or any group unrelated to CUI
Authentication methods	Phishing-resistant methods (FIDO2 or Windows Hello for Business) are strongly recommended — no SMS or voice call. Microsoft Authenticator push notifications are permitted if phishing-resistant authentication is not operationally feasible; enable number matching and additional context if so.

The goal is account hygiene, not account deprivation. CUI accounts can have mailboxes and Teams access for CUI-related collaboration. What they should not do is serve as the identity a user hands out to vendors, signs up for webinars with, or uses for anything that generates inbound traffic unrelated to CUI work. The smaller the account's exposure surface during normal hours, the less likely a credential compromise during those hours reaches CUI.

Entra Group

Create the following group and place it in your existing EID Restricted Management AU alongside the other CA security groups.

Group Name	Purpose
AVD-Enclave-FCI-Users-MESG	All dedicated CUI accounts that need access via the enclave. Assigned to the enclave host pool, scoped into P004/B011/B012 (and B013/B014 for E5), and targeted by DLP policies D001–D003 via the label policy.

---

Precursors

The CA and DLP policies in the following sections each evaluate one or more of these building blocks. Configure all precursors before enabling any policy.

Device Extension Attribute

Conditional Access uses a device filter to distinguish AVD session hosts from every other device in the tenant. When a user authenticates from a session host, the session host's Entra device object is evaluated by B011 (and B013 for E5 tenants). The extensionAttribute15 value is what these policies read to decide whether to pass or block.

Why extensionAttribute15 instead of Custom Security Attributes?

Custom Security Attributes (CSAs) offer built-in RBAC separation and predefined value validation, but they are only supported in Conditional Access "Filter for applications" (on service principals). The CA "Filter for devices" condition does not support CSAs — it supports extensionAttribute1-15 along with built-in device properties like trustType, isCompliant, and operatingSystem. This is a platform limitation across all clouds, not specific to GCC High.

Tag Session Hosts

Perform this step for each session host that should serve enclave users. Requires Device.ReadWrite.All permission in Microsoft Graph.

Update-MgDevice -DeviceId expects the directory Object ID, not the Windows Device ID

Despite the parameter name, -DeviceId on Get-MgDevice, Update-MgDevice, and Remove-MgDevice takes the directory Object ID (the Id property), not the Windows-issued Device ID. See Entra Device Hygiene — Two opposite ID gotchas for the full table covering the inverse case for BitLocker recovery key cmdlets.

# 1. Connect to your GCC High tenant
Connect-MgGraph -Environment USGov -Scopes "Device.ReadWrite.All"

# 2. Build the payload
$params = @{
    extensionAttributes = @{
        extensionAttribute15 = "AVD-CUI-Authorized"
    }
}

# 3. Tag the session host device object
# Replace the DeviceId with the Entra object ID of each session host
Update-MgDevice -DeviceId "<entra-device-object-id>" -BodyParameter $params

To verify the tag was applied:

Get-MgDevice -DeviceId "<entra-device-object-id>" |
    Select-Object -ExpandProperty ExtensionAttributes |
    Select-Object ExtensionAttribute15

The assignment is persistent across reboots and across the device rejoining Entra. If a session host VM is replaced, the new VM's device object must be tagged before the affected user connects — B011 will block them until the tag is present.

---

Named Location

B012 (and B014 for E5 tenants) evaluates the Named Location to enforce that all enclave traffic originates from the Azure Firewall egress IP.

Verify the UDR

Confirm that the session host subnet's route table has a default route pointing to the Azure Firewall private IP (should be in place based on the previous chapter).

Azure portal → Networking → Route tables → [route table on AVD subnet]

Route name	Address prefix	Next hop type	Next hop IP
default-to-firewall	0.0.0.0/0	Virtual appliance	Azure Firewall private IP

If this route is not present, add it before proceeding. Without it, session host traffic bypasses the firewall and the Named Location condition will not be met.

Register the Firewall IP

1. Entra admin center → Security → Named locations → + IP ranges location
2. Name: AVD Enclave Egress — AZFW
3. Mark as trusted location: Yes
4. IP range: Azure Firewall public IP in CIDR notation (e.g., 203.0.113.10/32)

---

Sensitivity Labels

Create the CUI - AVD Label

This single label carries both file/email encryption and site-level access controls. The Purview Create a sensitivity label wizard organizes settings across five tabs — fill them in the order below to match the wizard flow. The Items and Groups & sites tabs only appear after their corresponding boxes are checked on the Scope tab.

Navigate to Microsoft Purview compliance portal (compliance.microsoft.us) → Information protection → Labels → + Create a label.

Tab 1: Label details

Field	Value
Label name	CUI - AVD
Display name	CUI - AVD Enclave
Description for users	Apply to documents and files containing CUI within the AVD enclave. Access is restricted to authorized AVD enclave users. This label is separate from the organization-wide CUI label — it applies enclave-specific RMS encryption scoped to AVD-Enclave-FCI-Users-MESG.

Tab 2: Scope

Scope selections gate which subsequent tabs appear. Configure exactly:

Setting	Value	Reason
Items	Checked	Unlocks the Items tab for file/email encryption
↳ Files and emails	Checked	The primary protection target for the enclave
↳ Meetings	Unchecked	Calendar-item labeling is an E5 feature (see Enclave Licensing) and not part of the standard enclave configuration
Groups & sites	Checked	Unlocks the Groups & sites tab for site-level access controls

Tab 3: Items

The Items tab opens to a three-checkbox page. Only Control access is needed for the enclave; the other two are intentionally left unchecked:

Setting	Value	Reason
Control access	Checked — configure on the Access control sub-tab below	Drives the RMS encryption that restricts decryption to enclave members
Apply content marking	Unchecked	The enclave does not require visible CUI markings on files. If a contractual flow-down requires DODI 5200.48 markings (headers, footers, watermarks), enable this and configure the marking text separately.
Protect Teams meetings and chats	Unchecked	Out of scope — Meetings scope was disabled in Tab 2; Teams chat content protection is an E5 feature

Checking Control access expands the Items tab into two sub-tabs in the wizard navigation: Access control and Auto-labeling. Configure Access control as described below; the Auto-labeling sub-tab is intentionally skipped.

Tab 3a: Access control

Field	Value
Assign permissions now or let users decide?	Assign permissions now
User access to content expires	Never — required for co-authoring (any other value blocks it per Microsoft's documented limitations)
Allow offline access	For a number of days — 3 — shorter window limits the risk of offline decryption of exfiltrated files. Does not affect co-authoring.
Assign permissions → + Add users or groups	AVD-Enclave-FCI-Users-MESG; set permissions to Co-Author (read, modify, print — no full control)

After the encryption configuration is saved, the wizard prompts to enable tenant-wide co-authoring for sensitivity-labeled files. Accept the prompt — without it, every CUI document acts as if checked out by whoever opens it first and AutoSave is silently disabled in Office desktop apps. The setting takes effect ≈24 hours after acceptance and is effectively a one-way door (technically reversible via Set-PolicyConfig -EnableLabelCoauth:$false in Security & Compliance PowerShell, but disabling loses the new-format labeling metadata for unencrypted files). See Enable co-authoring for files encrypted with sensitivity labels for the full prerequisites, including the Office client minimum versions (Microsoft 365 Apps for Enterprise 2107+ Current/Monthly, 2202+ Semi-Annual on Windows; 16.51+ macOS).

Tab 3b: Auto-labeling — skip

Click through the Auto-labeling sub-tab without enabling anything. The toggle here configures client-side auto-labeling that fires inside Office desktop apps and OWA when sensitive content is detected as the user types — it is a separate mechanism from the service-side auto-labeling policies under Purview → Information protection → Auto-labeling policies (mechanism 3 in Labeling Content Within Designated CUI Sites below).

For the enclave we leave it off for two reasons:

1. It would compete with the mandatory-labeling + library-default flow. Mandatory labeling forces every Office document to carry an explicit CUI - AVD selection; library default applies the same label to uploads. A client-side auto-labeling recommendation firing on top of those is at best redundant and at worst introduces a different label if the content-detection rule matches a higher-priority sibling label.
2. Content-detection rules at the label level are an unnecessary attack surface for an enclave-only label. The enclave's data-protection model assumes that everything an FCI user authors is CUI by definition — there is no content-shape decision to make. The label policy already enforces that by mandatory labeling.

Auto-labeling shows up later in the chapter as an E5 service-side scan (mechanism 3) for back-labeling existing content at rest in CUI sites and for content that arrives through non-Office upload paths. That is configured separately under Purview → Information protection → Auto-labeling policies and is not the same setting as this sub-tab. See Microsoft's Apply a sensitivity label to content automatically for the distinction between the two auto-labeling mechanisms.

Tab 4: Groups & sites

Site-level controls apply when this label is attached to a SharePoint site. The encryption from Tab 3 still protects files inside the site independently.

1. On Define protection settings for groups and sites, check External sharing and Conditional Access settings
2. External sharing: Only people in your organization
3. Access from unmanaged devices: Block access — this is enforced independently of B011/B012 and provides defense-in-depth

Tab 5: Finish

Review the configuration summary and click Create label. The label is created but inactive — it must be added to a published label policy (see Publish the Label Policy below) before users can apply it.

After the wizard finishes, the label exists in your tenant but does no work yet. Two configuration steps make it operational:

1. Apply the label to each SharePoint site designated for CUI storage — this activates the site-level controls from Tab 4 (external sharing, unmanaged device access). Applying a label to a site does not automatically apply that label to files inside the site — site labels and file labels are independent scopes.
2. Configure how files within those sites get labeled — files must carry the label independently to inherit RMS encryption and the DLP enforcement that depends on it. See Labeling Content Within Designated CUI Sites below, after the label policy is published.

Publish the Label Policy

Publishing the policy follows the Create a sensitivity label policy wizard. The wizard opens on the label-selection page, walks through assignment, presents a four-checkbox policy-level Settings page, then a five-tab per-content-type defaults page (Documents, Emails, Meetings, Sites and groups, Fabric and Power BI), then naming and review. Configure as follows:

Step 1: Choose sensitivity labels to publish

1. Purview → Information protection → Label policies → + Publish label
2. Add the CUI - AVD label only — do not publish the organization-wide CUI label or any other labels to FCI users. This ensures mandatory labeling forces every document and email to carry the enclave-specific CUI - AVD label rather than a less-restrictive sibling.

Step 2: Assign admin units (optional)

Leave at default unless you've already scoped administrative units. The enclave's AVD-Enclave-FCI-Users-MESG is the assignment target, configured on the next step.

Step 3: Publish to users and groups

Publish to: AVD-Enclave-FCI-Users-MESG. Group-based assignment lets membership changes flow through without re-touching the policy.

Step 4: Policy settings (four checkboxes)

The Settings page presents four policy-level toggles before the per-content-type tabs. Configure as follows:

#	Setting	Value	Reason
1	Users must provide a justification to remove a label or lower its classification	✅ Checked	Generates an audit event capturing the user-provided reason — assessor-readable evidence for any label-removal or downgrade incident. There is no lower-classification target inside this policy (only one label), but the justification still fires on label removal — and that's the case that matters for audit narrative.
2	Require users to apply a label to their emails and documents	✅ Checked	The master mandatory-labeling toggle for the two core scopes. Closes the loop with DLP D001/D002 — every document FCI users save and every email they send carries CUI - AVD. This is the single most load-bearing setting in the policy.
3	Require users to apply a label to their Fabric and Power BI content	⬜ Unchecked	Power BI is out of scope for the FCI user role in the enclave. If Power BI on CUI data becomes in-scope later, it's a separate label-and-policy decision (Power BI sensitivity labels also require Power BI Pro/Premium and additional tenant configuration).
4	Provide users with a link to a custom help page	Optional URL	If the tenant has an intranet page on CUI handling and enclave use, paste that URL here. The Office Sensitivity bar surfaces a "Learn more" link pointing at it. Safe to leave blank if no such page exists.

Step 5: Per-content-type defaults — five tabs

The next page presents one tab per content scope. Tabs render regardless of which scopes are enabled on the label itself — settings on a tab that doesn't match the label's scope are inert and can be left at default. Our label is scoped to Files & emails + Groups & sites, so the Documents, Emails, and Sites and groups tabs do real work; the Meetings and Fabric and Power BI tabs are no-op for this policy.

The mandatory-labeling toggle for documents and emails lives on the Step 4 Settings page above (checkbox #2), not on these per-tab pages — so the Documents and Emails tabs below cover only the default label and the email-specific inheritance setting.

Tab 5a: Documents

Setting	Value	Reason
Default label for documents	None	Force explicit selection so the user is aware they're authoring inside the enclave boundary. Mandatory labeling (Step 4 #2) ensures they cannot save without picking CUI - AVD.

Tab 5b: Emails

Setting	Value	Reason
Default label for emails	CUI - AVD	Only one label is published to FCI users; setting the default eliminates a click without changing the outcome. The user can still change it before sending (mandatory labeling requires a label, not specifically this label — but CUI - AVD is the only one available).
Email inherits highest priority label from attachments	✅ Checked	When an FCI user attaches a CUI - AVD document to an otherwise-unlabeled email, Outlook applies CUI - AVD (and its RMS encryption) to the email body so the message itself is protected at the attachment's level. Without this, the body of the email goes out unencrypted while the attachment is locked down — exactly the gap the enclave is designed to close.
↳ (dropdown below the checkbox)	Automatically apply label	Two choices appear in the dropdown: Automatically apply label (the inherited label is applied without a user prompt) and Recommend users apply label (the user gets a prompt asking them to confirm the upgrade). For the enclave, choose Automatically apply label — only CUI - AVD is published to FCI users, so there is no alternative label they could legitimately retain and the prompt would be friction with no decision to make. Choose Recommend users apply label only when multiple labels are published and you want users to consciously confirm a sensitivity upgrade.

Inheritance is Outlook-for-Windows-only

Label inheritance from email attachments fires in Outlook for Windows desktop (Current Channel 2302+, Monthly Enterprise 2302+, Semi-Annual 2302+) and the new Outlook for Windows. It does not fire in OWA, Outlook for Mac, Outlook on iOS, or Outlook on Android — see the Outlook capabilities table. For the enclave this is a non-issue because FCI users access Exchange exclusively via the published Outlook desktop app inside the AVD session host. The policy-level mandatory-labeling toggle (Step 4 #2) still forces a manual selection on platforms that don't support inheritance, so the email is never sent unlabeled regardless of client.

Two other documented limitations worth knowing:

• Attachment must be a physical file. SharePoint or OneDrive share-link attachments do not trigger inheritance. The label-bound encryption on the linked document still restricts who can decrypt it, so the gap is narrower than it sounds — but it's worth knowing if you test with a share link and wonder why inheritance didn't fire.
• User-defined permissions block inheritance. If the matching label is configured for "Let users assign permissions when they apply the label," Outlook can't inherit. Our label uses Assign permissions now (admin-defined permissions to AVD-Enclave-FCI-Users-MESG), which Outlook supports.

Tab 5c: Meetings

No-op for this policy — the label is not scoped to Meetings (see Tab 2: Scope in the label-creation wizard above). Leave Default label for meetings and calendar events at None and Require users to apply a label to their meetings and calendar events unchecked. If a future contractual flow-down requires meeting-item labeling, that's an E5 feature handled by a separate label whose scope includes Meetings.

Tab 5d: Sites and groups

Setting	Value	Reason
Default label for sites and groups	None	Site-label assignment is performed deliberately, per-site, by the admin — not by default policy. See Labeling Content Within Designated CUI Sites below for the broader site-labeling discussion; the per-site CUI - AVD application is performed in the Purview compliance portal at Information protection → Labels → CUI - AVD → Apply to sites.
Require users to apply a label to their groups or sites	⬜ Unchecked	FCI users are not authorized to create SharePoint sites or Microsoft 365 Groups from within the enclave; site provisioning is an admin operation outside the FCI scope.

Tab 5e: Fabric and Power BI

No-op for this policy — Power BI in the enclave is out of scope for the FCI user role and not covered by CUI - AVD. The mandatory-labeling toggle for this scope was already left unchecked on the Step 4 Settings page (checkbox #3); leave Default label for Power BI content at None here as well.

Step 6: Name and policy order

Setting	Value
Name	AVD Enclave - CUI - AVD - FCI Users
Description	Publishes the CUI - AVD label to AVD-Enclave-FCI-Users-MESG. Mandatory labeling enforced for documents and emails; email inherits attachment label. Companion to DLP D001 / D002.
Policy order	Leave at default for initial deployment. If FCI users are also in scope for an organization-wide label policy (e.g., the standard CUI label policy), set this policy's order higher (lower number) so its label set wins. Multi-policy precedence is covered in Microsoft's label policy priority documentation.

Step 7: Review and submit

Confirm the summary matches the configuration above and click Submit. Allow ≈1 hour for the policy to propagate to client apps. If site-label application doesn't see the new CUI - AVD label after a few hours, force a container-label sync via the Execute-AzureADLabelSync step in the next callout below.

Mandatory labeling is load-bearing

Mandatory labeling ensures every document FCI users create carries the CUI - AVD label. DLP Policy D002 blocks access to CUI-labeled files in non-designated sites. Together, these two controls mean FCI users cannot persist usable content anywhere except designated CUI sites — even if the client admin grants them SharePoint permissions to other sites.

Force container-label sync into Entra ID (if needed)

Sensitivity labels created in Purview sync to Entra ID automatically so they can be applied to Microsoft Teams sites, Microsoft 365 Groups, and SharePoint sites. For tenants stood up after September 2019, this sync happens automatically — no admin action is required. For older tenants (or if site-label application doesn't see the new CUI - AVD label after a few hours), the Execute-AzureADLabelSync cmdlet in Security & Compliance PowerShell forces the sync. (Execute-AzureADLabelSync reference)

Labeling Content Within Designated CUI Sites

Applying the CUI - AVD label to a SharePoint site applies the site-level controls from Tab 4 — external sharing, unmanaged device access, default sharing link. It does not automatically label files inside the site. Site labels and file labels are independent scopes that happen to live on the same label. Without explicit configuration of file-level labeling, files uploaded to a CUI site remain unlabeled and therefore unencrypted — which defeats the enclave's data-layer enforcement.

Three labeling mechanisms apply the label to files; DLP policy D001 provides defense in depth if any file slips through:

#	Mechanism	What it covers	Where it's configured
1	Default library label	New files uploaded to the library, and existing files when they are edited	Per-library setting in SharePoint (procedure below)
2	Mandatory labeling in label policy	New documents created in Word, Excel, PowerPoint by FCI users	The published label policy — already configured in Publish the Label Policy above
3	Auto-labeling policy (E5 feature)	Existing files at rest in the site, and content uploaded through non-Office paths	Purview → Information protection → Auto-labeling policies — see E5 features
—	DLP D001 (failsafe, not a labeling mechanism)	Blocks access to unlabeled content in CUI sites — catches anything that slips past 1–3	See DLP Policies below

For an E3 tenant, mechanisms 1 + 2 + the D001 failsafe close the loop for the standard flow. Auto-labeling (mechanism 3) adds coverage for migrated content and non-Office upload paths and is the reason auto-labeling shows up as an E5 recommendation in the licensing table.

Configure the Default Library Label

For each SharePoint document library designated to hold CUI:

Prerequisites (verify before configuring):

Prerequisite	Verify
Sensitivity labels enabled for SharePoint and OneDrive	(Get-SPOTenant).EnableAIPIntegration returns True
PDF support enabled if PDFs are in scope	(Get-SPOTenant).EnableSensitivityLabelforPDF returns True — see PDF Labeling
CUI - AVD label is published	Confirm via Purview → Information protection → Label policies — required so the label appears in the library's picker
Library is not using legacy SharePoint IRM	SharePoint Information Rights Management (IRM) is mutually exclusive with library default labeling. If a library has IRM enabled, the Default sensitivity labels option does not appear.

Procedure (repeat per library):

1. Navigate to the CUI SharePoint site → the target document library
2. Click Settings (gear icon) → Library settings → More library settings
3. Under Default sensitivity labels, select CUI - AVD from the dropdown
4. Click Save

The setting takes effect within ≈15 minutes for new uploads. Existing files in the library remain unlabeled until they are edited or until auto-labeling (mechanism 3) processes them. Empty files are not labeled until they receive content.

Override behavior — when the library default does and does not overwrite an existing label, per Microsoft's documented priority rules:

File's existing label	Library default applies?
No label	Yes — CUI - AVD is applied
Manually applied label, any priority	No — manual labels always win
Auto-applied or default-policy label of lower priority than CUI - AVD	Yes — CUI - AVD overrides
Auto-applied or default-policy label of higher priority than CUI - AVD	No

Place CUI - AVD at or near the top of the label priority order in Purview (Information protection → Labels → drag-to-reorder) so the library default reliably wins over a user's default-from-policy label such as Internal or General.

Compatibility check for our label: CUI - AVD uses Assign permissions now (admin-defined permissions to AVD-Enclave-FCI-Users-MESG), expiration Never, and is not configured for Double Key Encryption — all compatible with library default labeling. The mutually-exclusive Let users assign permissions encryption option is not in use.

Audit verification: a label applied by library default fires the Applied sensitivity label file event in the unified audit log with ActionSourceDetails = 6 in SensitivityLabelEventData. Use this in Sentinel or audit search to verify the default is firing as expected during initial rollout — see Microsoft's Monitoring application of library default sensitivity labels for the full event schema.

GCC High Notes

Item	Value
Purview compliance portal	compliance.microsoft.us
Azure Rights Management endpoint	api.aadrm.us
Label policy propagation	Allow up to 24 hours after publishing before labels appear in Office apps

Verify the RMS endpoint in Office apps

GCC High Office apps must contact the sovereign RMS endpoint (api.aadrm.us) to decrypt labeled files. If the tenant is correctly provisioned in GCC High this is automatic, but verify before testing: open a labeled file in Word, then check the RMS service endpoint in the Azure Information Protection activity log. A connection attempt to api.aadrm.com (commercial) indicates a misconfiguration that will silently fail label decryption.

---

Conditional Access Policies

P004 enforces device compliance. B011 and B012 enforce device-tag and network requirements. For E5 tenants, B013 and B014 add authentication-context enforcement for CUI content. For E3 tenants without B013/B014, DLP policies D001–D003 in the next section provide data-layer enforcement.

All three AVD-related apps — Azure Virtual Desktop, Azure Virtual Desktop Client, and Windows Cloud Login — are excluded from P004, B011, and B012. This allows enclave users to authenticate to the AVD broker from any device; once inside the session, the session host satisfies all policy conditions.

Migration from the Chapter 9 baseline — what happens to the previous P004 / P005 / P006

The enclave's CA framework assumes the organization has decided to remove BYOD as a supported scenario for CUI access — every authorized path goes through the AVD session host, which is corporate-owned, Intune-enrolled, and compliant by definition. The three Chapter 9 baseline policies that exist to govern BYOD or to require compliance across a narrow resource set are migrated as follows:

Chapter 9 baseline policy	Enclave action	Why
P004 [BYOD] Enforce Limited Web Access	Delete	Read-only browser access on unmanaged devices is irrelevant when there are no unmanaged-device sessions in scope.
P005 [BYOD] Enforce Mobile App Protection	Delete	FCI users have no mobile path into CUI; B011 and B012 below block access from any device outside the AVD enclave regardless of MAM.
P006 Require compliant devices for O365, Azure, and Management	Modify in place to become the new P004 below	Old P006 required compliance against three named resource sets (Office 365, Microsoft Admin Portals, Azure Service Management) and did not exclude the AVD broker apps. New P004 broadens the target to All cloud apps and excludes the three AVD broker apps so the broker connection from the user's connecting device — intentionally not the managed endpoint — succeeds. Once inside the AVD session, the Intune-compliant session host satisfies P004 for every downstream cloud app the user touches.

If the organization needs to keep BYOD for users outside the enclave, the alternative is to leave the Chapter 9 baseline intact and scope every enclave policy (new P004, B011, B012, B013, B014) to AVD-Enclave-FCI-Users-MESG only — but the enclave's data-protection guarantees weaken to the extent that non-enclave users still have a BYOD path that the enclave's network and device controls do not cover.

ID	Policy Name	Grant/Block
P004	Require Compliant Device	Require compliant device
B011	Enclave Device Block	Block (unless tagged device)
B012	Enclave Network Block	Block (unless AZFW egress IP)
B013	Auth Context: Device Block (E5 only)	Block (unless tagged device)
B014	Auth Context: Network Block (E5 only)	Block (unless AZFW egress IP)

Enable in Report Only mode first

Enable all CA policies in Report Only before switching to Enforce. Enforcing B011 before extension attribute tags are assigned to session hosts will lock enclave users out of all cloud apps. Validate each policy in CA sign-in logs before enforcing. Similarly, enable DLP policies in Test mode before switching to Turn it on right away.

---

P004 — Require Compliant Device

Requires device compliance for all cloud apps, with exclusions for the three AVD apps so the broker connection is not blocked.

Users:

• Include: AVD-Enclave-FCI-Users-MESG
• Exclude: EID_Emergency_Admin_Exclusions

Target resources:

• Include: All cloud apps
• Exclude: Azure Virtual Desktop, Azure Virtual Desktop Client, Windows Cloud Login

Grant: Require device to be marked as compliant

Logic: "Require a compliant device for all cloud apps — except the AVD broker apps, which are accessed from the connecting device before the user reaches the managed session host."

Why exclude the AVD apps?

The connecting device — a personal laptop, a contractor's machine — is intentionally not the managed endpoint. The AVD session host is. Requiring device compliance on the broker connection defeats the enclave's purpose, which is to provide a managed session to users whose physical device is out of scope. Once inside the AVD session, the session host is a compliant, Intune-managed device that satisfies P004 for all subsequent cloud app access.

---

B011 — Enclave Device Block

Blocks all cloud app access from any device not carrying the AVD-CUI-Authorized extension attribute tag.

Users:

• Include: AVD-Enclave-FCI-Users-MESG
• Exclude: EID_Emergency_Admin_Exclusions

Target resources:

• Include: All cloud apps
• Exclude: Azure Virtual Desktop, Azure Virtual Desktop Client, Windows Cloud Login

Conditions → Filter for devices:

• Rule type: Exclude filtered devices from policy
• Filter rule:

  device.extensionAttribute15 -eq "AVD-CUI-Authorized"

Grant: Block

Logic: "Block all cloud apps for AVD-Enclave-FCI-Users-MESG — unless the request comes from a device tagged AVD-CUI-Authorized. AVD broker apps are excluded so the initial connection is not blocked."

---

B012 — Enclave Network Block

Independently blocks all cloud app access from any traffic not originating from the Azure Firewall egress IP. Together with B011, enforces AND logic.

Users:

• Include: AVD-Enclave-FCI-Users-MESG
• Exclude: EID_Emergency_Admin_Exclusions

Target resources:

• Include: All cloud apps
• Exclude: Azure Virtual Desktop, Azure Virtual Desktop Client, Windows Cloud Login

Conditions → Locations:

• Include: Any location
• Exclude: AVD Enclave Egress — AZFW

Grant: Block

Logic: "Block all cloud apps for AVD-Enclave-FCI-Users-MESG — unless the traffic arrives from the Azure Firewall public IP. AVD broker apps are excluded so the initial connection is not blocked."

Combined logic (P004 + B011 + B012): All three policies must be satisfied. A tagged device that is not compliant is blocked by P004. A compliant device without the tag is blocked by B011. A tagged, compliant device not routing through the firewall is blocked by B012. Only a request from a device that is compliant, tagged, and routing through the AZFW IP passes all three.

---

B013 — Auth Context: Device Block (E5 Only)

Fires when a resource requests the c1 auth context (CUI-labeled content or CUI SharePoint sites). Blocks the context from any device not carrying the extension attribute tag.

Users:

• Include: AVD-Enclave-FCI-Users-MESG
• Exclude: EID_Emergency_Admin_Exclusions

Target resources: Authentication context → c1 — CUI Access Required

Conditions → Filter for devices:

• Rule type: Exclude filtered devices from policy
• Filter rule:

  device.extensionAttribute15 -eq "AVD-CUI-Authorized"

Grant: Block

Logic: "Block the c1 auth context for AVD-Enclave-FCI-Users-MESG — unless the request comes from a device tagged AVD-CUI-Authorized."

---

B014 — Auth Context: Network Block (E5 Only)

Independently blocks the c1 auth context from any traffic not originating from the Azure Firewall egress IP. Together with B013, enforces AND logic for auth context access.

Users:

• Include: AVD-Enclave-FCI-Users-MESG
• Exclude: EID_Emergency_Admin_Exclusions

Target resources: Authentication context → c1 — CUI Access Required

Conditions → Locations:

• Include: Any location
• Exclude: AVD Enclave Egress — AZFW

Grant: Block

Logic: "Block the c1 auth context for AVD-Enclave-FCI-Users-MESG — unless the traffic arrives from the Azure Firewall public IP."

Combined logic (B013 + B014): Both policies must be satisfied. Only a session from a tagged device routing through the AZFW IP can obtain a c1 auth context claim and open labeled CUI files or access CUI SharePoint sites.

B013/B014 require E5 licensing — deploy if you already have it, don't buy it for this

Authentication context on SharePoint sites requires M365 E5, SharePoint Advanced Management, or a Copilot license.

If the tenant does not have E5 licensing: Omit B013 and B014. The E3 controls already close the practical attack paths: RMS encryption restricts decryption to AVD-Enclave-FCI-Users-MESG, B011/B012 prevent FCI users from authenticating outside the enclave, session host lockdown limits exfiltration vectors, and DLP policies D001–D003 enforce data-layer controls at the service perimeter. Do not purchase E5 or SAM specifically for auth context.

If the tenant already has E5 licensing: Deploy B013/B014 as free defense-in-depth alongside D001–D003. Auth context adds one narrow protection not covered by the other controls: if an FCI user exfiltrates a CUI file past the Azure Firewall, DLP, and session host controls, and attempts to decrypt it on a personal device using cached offline credentials within the 3-day offline access window, auth context blocks decryption because the cached token would not carry the c1 claim. Without auth context, RMS encryption still requires the user to be in AVD-Enclave-FCI-Users-MESG, but cached offline credentials could allow decryption during the offline window. This is a real but extremely narrow scenario — it requires a successful exfiltration past multiple layers and a motivated insider acting within a 3-day window.

---

Data Loss Prevention Policies

All three DLP policies evaluate the CUI - AVD sensitivity label configured in the Sensitivity Labels precursor section. This label has the following properties relevant to DLP evaluation:

Property	Value	DLP Relevance
Label name	CUI - AVD	The condition Content contains sensitivity label: CUI - AVD in D001–D002 matches on this name. This is distinct from any organization-wide CUI label.
RMS encryption	Enabled — decryption restricted to AVD-Enclave-FCI-Users-MESG with Co-Author permissions	Files matching the label are encrypted; non-enclave users cannot open them even if DLP does not block access
Offline access	3 days	Limits the window during which cached credentials can decrypt exfiltrated files
Mandatory labeling	Enforced via label policy — CUI - AVD is the only label published to FCI users	Ensures every document FCI users create carries the CUI - AVD label, making D002's block effective for any content written to non-designated sites

D001 enforces labeling within designated CUI sites. D002 blocks access to CUI content that reaches non-designated locations. D003 blocks unlabeled email from enclave accounts. Together with mandatory labeling and RMS encryption, these three policies ensure FCI users can only create labeled content, that labeled content can only persist in designated CUI sites, and that labeled content is unreadable by anyone outside the enclave group.

Sharing and email delivery of CUI-labeled content to non-enclave recipients is not blocked by DLP — it is rendered useless by RMS encryption on the CUI - AVD label, which restricts decryption to AVD-Enclave-FCI-Users-MESG. This eliminates the need for a separate DLP policy to block sharing.

E3 vs. E5 data-layer enforcement

E3 tenants (no B013/B014): RMS encryption and DLP policies D001–D003 are the primary data-layer enforcement mechanism, working alongside B011/B012. These controls close all practical attack paths without E5 licensing.

E5 tenants (with B013/B014): Authentication context adds a narrow additional protection for the offline-credential exfiltration scenario described in the B013/B014 section above. DLP policies D001–D003 remain required — they catch edge cases (unlabeled content, content in wrong locations, email routing) that auth context does not address.

Deploy D001–D003 regardless of licensing tier.

ID	Policy Name	Action
D001	Enforce Labeling in CUI Sites	Block unlabeled content
D002	Block CUI in Wrong Location	Block access
D003	Block Unlabeled Enclave Email	Block outbound email

Enable in Test mode first

Enable all DLP policies in Test mode with policy tips before switching to Turn it on right away. Validate each policy in the DLP alerts dashboard and Activity Explorer before enforcing. Enforcing D001 before existing CUI site content is labeled will block access to unlabeled legacy files.

---

DLP block actions do not apply to site owners or site collection administrators

SharePoint site owners, site collection administrators, and Global Administrators are exempt from DLP block actions on content within their sites. This is a platform-level behavior — Microsoft exempts these roles so they can access and remediate flagged content rather than being locked out by their own DLP policies.

What this means for the enclave:

Account type	D001/D002 block?	RMS blocks labeled content?
Global Admin / Site Collection Admin	No — exempt from DLP block actions	Yes — cannot decrypt unless RMS Super User
Site Owner	No — exempt from DLP block actions	Yes — cannot decrypt
Regular user with site access	Yes	Yes — cannot decrypt
AVD-Enclave-FCI-Users-MESG member	Yes (for unlabeled content)	Can decrypt (authorized)

The gap: Global Administrators have implicit site collection admin access to all SharePoint sites — this cannot be removed. Site owners have the same DLP exemption by design. Both roles can read unlabeled content in CUI sites because DLP doesn't block them and there's no encryption on unlabeled files. Both roles also bypass the site-level access block from the CUI - AVD sensitivity label.

What remains enforced regardless of admin role:

• RMS encryption on labeled files — admins can see filenames but cannot decrypt CUI - AVD labeled content unless they are in AVD-Enclave-FCI-Users-MESG (or are RMS Super Users)

Mitigations for unlabeled content exposure to admins:

• Mandatory labeling ensures FCI users cannot create unlabeled content in Office apps — the only unlabeled files that should exist are pre-existing content or files uploaded through non-Office channels
• Auto-labeling (E5) labels pre-existing and non-Office-uploaded content, closing this gap over time
• CUI site owners should be trusted personnel — site ownership carries the ability to read unlabeled content and should be treated as a privileged role in the enclave's RBAC documentation

D001 — Enforce Labeling in CUI Sites

Blocks access to any file in a designated CUI SharePoint site that does not carry the CUI - AVD sensitivity label. This ensures everything FCI users interact with is properly labeled and encrypted. Note that site owners and site collection administrators are exempt from this block — see the warning above.

Location: Designated CUI SharePoint sites (add each site explicitly)

Rule:

Component	Configuration
Condition group (NOT)	Content contains sensitivity label: CUI - AVD — with the NOT operand enabled on the condition group
Action	Restrict access or encrypt the content in Microsoft 365 locations → Block users from receiving email or accessing → Block everyone
Policy tip	This file has not been labeled CUI. Access is blocked until a CUI label is applied.
Incident severity	Medium
Notify	Compliance Administrator

Logic: "If a file in a designated CUI site does NOT carry the CUI - AVD sensitivity label, block access for everyone."

Timing

DLP evaluates content after upload. There is a brief crawl window (typically seconds to minutes) where a newly uploaded unlabeled file may be accessible before DLP blocks it. Mandatory labeling in Office apps mitigates this — the gap only applies to files uploaded through non-Office channels (drag-and-drop in browser, API, migration tools).

---

D002 — Block CUI in Non-Designated Locations

If a CUI-labeled file appears in any SharePoint site or OneDrive account that is not a designated CUI location, block access to the file. This is the policy that prevents the client admin from accidentally extending the enclave — even if they grant FCI users permissions to a new site, any document the FCI user creates there will be labeled CUI - AVD (mandatory labeling) and immediately blocked.

Location: All SharePoint sites and OneDrive accounts — EXCLUDE designated CUI SharePoint sites

Rule:

Component	Configuration
Condition	Content contains sensitivity label: CUI - AVD
Action	Restrict access or encrypt the content in Microsoft 365 locations → Block everyone
Policy tip	CUI content is not permitted in this location. Access has been blocked. Contact your Compliance Administrator.
Incident severity	High
Notify	Compliance Administrator and Security team

Logic: "If a CUI-labeled file appears anywhere outside the designated CUI sites, block access immediately."

The file remains in its original location but is inaccessible — no one can open, download, or share it. The Compliance Administrator receives an alert and can investigate, then either move the file to a designated CUI site or delete it.

The exclusion list is the designated site list

The list of excluded SharePoint sites in D002 is the authoritative list of designated CUI locations. Only the Compliance Administrator (PIM-gated) can modify this list. When a new CUI site is created, the Compliance Administrator must add it to D002's exclusion list and D001's included locations before CUI work can begin on that site.

---

D003 — Block Unlabeled Email from Enclave Accounts

Blocks outbound email from FCI accounts that does not carry the CUI - AVD sensitivity label. Catches system-generated email, calendar invitations, and edge cases where mandatory labeling in Office apps does not apply.

Location: Exchange — Include: AVD-Enclave-FCI-Users-MESG only (mail-enabled security group). This scopes the policy to FCI user mailboxes at the location level — non-enclave users' email is not evaluated.

Rule:

Component	Configuration
Condition (NOT group)	Content contains sensitivity label: CUI - AVD — with the NOT operand enabled on the condition group
Exception (OR in NOT group)	Header matches pattern — Header name: x-ms-exchange-calendar-originator-id, Header value: [a-zA-Z0-9] (exempts system-generated calendar items — matches any message carrying this header with an alphanumeric value)
Action	Block users from receiving email → Block everyone
Policy tip	All email from enclave accounts must carry a CUI - AVD sensitivity label.
Incident severity	Medium
Notify	Compliance Administrator

Logic: "For email sent from AVD-Enclave-FCI-Users-MESG mailboxes: if the email does NOT carry the CUI - AVD label, block it — unless it is a system-generated calendar item."

Location-level scoping vs. rule-level sender conditions

The FCI group is applied at the Exchange location level (include only AVD-Enclave-FCI-Users-MESG), not as a rule-level "Sender is a member of" condition. Location-level scoping is more reliable — it removes non-enclave mailboxes from evaluation before rule conditions are checked. This also avoids a DLP limitation where group membership conditions may not be available as rule-level conditions in all tenants.

---

Designating a New CUI Site

This procedure is performed by the Compliance Administrator (PIM-gated) — not the client admin. Until all steps are complete, CUI work cannot proceed on the site.

1. Create the SharePoint site (or confirm it exists)
2. Apply the CUI - AVD sensitivity label to the site (enables site-level sharing and access controls)
3. Add the site URL to D001's included locations (enforces labeling within the site)
4. Add the site URL to D002's excluded locations (allows CUI content to persist)
5. Configure SharePoint permissions — grant AVD-Enclave-FCI-Users-MESG access
6. Validate in DLP Test mode before enabling enforcement on the new site

---

Site Membership Audit

DLP enforces write-side controls, but FCI account membership in non-CUI SharePoint sites should be monitored as a governance control. A scheduled PowerShell script (or Azure Automation runbook) should:

1. Enumerate all SharePoint sites where members of AVD-Enclave-FCI-Users-MESG have permissions
2. Compare against the designated CUI site list (sites in D001/D002)
3. Alert the Compliance Administrator if any FCI account has permissions to a non-designated site

Run this audit weekly. Unexpected membership does not indicate a breach — DLP Policy D002 blocks access to any CUI content written to non-designated sites — but it indicates a permissions hygiene issue that should be corrected.

---

Verification

Enable all CA policies in Report Only mode and all DLP policies in Test mode before enforcing. Validate each policy before switching to enforce.

Check	How to Verify
Extension attribute assigned to session hosts	Run Get-MgDevice for the session host and expand ExtensionAttributes — ExtensionAttribute15 should return AVD-CUI-Authorized
P004 allows AVD broker connection	Sign in via AVD client from a personal (non-compliant) device — session launches because AVD apps are excluded from P004
B011 blocks direct cloud app access	From a personal device (outside AVD), open SharePoint with the CUI account — should be blocked
B011 passes from AVD session	Open SharePoint from inside the AVD session — should succeed
B012 network binding	From inside an AVD session, confirm outbound IP matches Azure Firewall public IP
B013/B014 (E5 only) auth context	From a personal device outside AVD, attempt to open a CUI-labeled file — CA sign-in logs should show B013 or B014 Block with auth context c1
CA sign-in logs	Entra → Sign-in logs → filter by AVD-Enclave-FCI-Users-MESG — B011 shows Pass (from session host) and Block (from personal device)
Mandatory labeling	From inside the AVD session, create a new document in Word — should not be possible to save without applying the CUI - AVD label
D001 blocks unlabeled content	Upload an unlabeled file to a CUI SharePoint site via drag-and-drop — after DLP crawl, access should be blocked
RMS blocks non-enclave recipients	From inside the AVD session, send a CUI-labeled email to a non-enclave internal user — email arrives but recipient cannot decrypt the content
D002 blocks CUI in wrong location	Upload a CUI-labeled file to a non-designated SharePoint site — access should be blocked for all users
D003 blocks unlabeled email	From inside the AVD session, attempt to send an email without a sensitivity label — should be blocked
Label encryption	From a personal device outside AVD, attempt to open a CUI-labeled file — should fail to decrypt (RMS encryption restricts to AVD-Enclave-FCI-Users-MESG)
RMS endpoint (GCC High)	In Office app activity log, confirm RMS calls go to api.aadrm.us, not api.aadrm.com
DLP Activity Explorer	Purview → Activity Explorer → filter by DLP rule matches — confirm D001–D003 are firing as expected in Test mode

---

Session Host Backup

Personal AVD pools assign one VM per user, and those VMs accumulate state that nothing in the deployment process captures — application configuration in %AppData%, browser profiles, signing certificates, line-of-business client caches, in-progress drafts that haven't yet been saved to OneDrive. A failed session host is a failed user, and rebuilding from the stock Windows 11 Enterprise gallery image plus the Intune baseline (per Step 10 of the runbook) means the user rebuilds their working environment from scratch.

Configure Azure Backup on the session host pool with daily snapshots and 30-day retention. The runbook step is in Appendix C.1 § Step 13. Backup is a deliberate architectural decision in this enclave — not the default for session-host pools that are nominally stateless — and the rationale is worth stating explicitly because the cost (~$15–20/VM/month) is non-trivial and the question "why are we backing up VMs in a pool that's supposed to be ephemeral?" will come up in any cost review.

#	Reason	Why it matters in this enclave
1	Undefined data and device management practices	The enclave exists because the client's data and device management practices are not fully defined — that's why we're separating CUI work onto controlled session hosts in the first place. Mandatory labeling and DLP catch policy-relevant cases; backup catches everything else. Backup is the operational corollary of the same uncertainty that justifies the enclave.
2	Compliance and forensics (CMMC IR.L2-3.6.1 / 3.6.2)	IR.L2-3.6.1 requires an operational incident-handling capability; 3.6.2 requires tracking, documenting, and reporting incidents. If a session host is compromised — credential theft, lateral movement, malware — investigators need the disk state at the time of the incident, not a freshly-rebuilt clone. Vault snapshots are the forensic baseline. Without them, the only record of what was on avd-05 last Tuesday is whatever Defender for Endpoint and Sentinel happened to capture in their event streams.
3	Recovery time objective	Rebuilding a session host from scratch — provision a fresh VM from the gallery, Entra-join, Intune-enroll, wait for baseline policies to apply, wait for compliance evaluation — is a 2–4 hour operation per VM when everything goes right, and the user still has to reinstall and reconfigure their applications afterward. Restoring from a vault snapshot is 20–40 minutes and the user's environment comes back as it was. For a personal pool where one VM equals one user, the difference is a half-day to a full day of lost productivity per incident. Backup pays for itself the first time a VM fails.
4	Unclear application requirements	Enclave users may install or rely on applications whose state lives outside Office and OneDrive — line-of-business clients, legacy CAD tools, custom CUI processing utilities, plug-ins. The provisioning baseline cannot anticipate every requirement; user-level customization fills the gap. Backup preserves that customization so a VM failure does not force the user to rebuild their working environment by hand.
5	The AppData gap	A large fraction of the per-user "feels like home" state lives in %AppData% — application configuration, browser profiles, signing certificates, Outlook signatures, in-progress drafts that the application caches before the user saves. Nothing in the provisioning pipeline reconstructs this. CUI is not in scope here (it lives in SharePoint, per the data storage policy) — but the application provisioning state is, and VM-level backup is the only mechanism that captures it consistently.

Backup runs at the Recovery Services Vault level in the same region as the session hosts (US Gov Virginia). Trusted Launch VMs (Secure Boot + vTPM, enabled at provisioning) are supported by Azure Backup with no special configuration. The vault is targeted at the AVD device group so newly-added session hosts are picked up automatically.

Backup protects user state, not the baseline

The provisioning baseline — stock Windows 11 Enterprise gallery image plus Intune-applied policy — is what every freshly-deployed session host looks like, and that baseline is reproducible at any time by re-running Step 10 of the runbook. Backup protects the delta the user accumulates on top of that baseline (AppData, application customization, in-progress work). Treat the two as complementary: provisioning gives you a known-good VM; backup preserves what the user added on top.

---

Operational Procedures

Adding a New Enclave User

1. Create a CUI account (firstname.lastname-secure@contoso.us), issue a TAP, and have the user register their authentication method
2. Add the CUI account to AVD-Enclave-FCI-Users-MESG-MESG
3. Assign the user to the AVD Host Pool Application Group: Azure Portal → Azure Virtual Desktop → Application groups → select the enclave desktop application group → Assignments → + Add
4. Grant the Virtual Machine User Login role on the Resource Group: Azure Portal → Resource Groups → select the enclave resource group → Access control (IAM) → + Add role assignment → Virtual Machine User Login → assign to the CUI account
5. Assign a personal pool session host (or confirm auto-assignment is configured)
6. Verify the session host device object has extensionAttribute15 = AVD-CUI-Authorized
7. Have the user connect and confirm successful sign-in via CA sign-in logs

Simplify with group-level assignments

If AVD-Enclave-FCI-Users-MESG is assigned to the Application Group and granted the Virtual Machine User Login role at the Resource Group level at deployment time, steps 3 and 4 are handled automatically when the user is added to the group in step 2. This is the recommended configuration — verify it at initial deployment to reduce per-user provisioning overhead.

Replacing a Session Host VM

A rebuilt or replaced session host gets a new Entra device object and does not inherit the previous VM's extension attributes.

1. Tag the new device object with extensionAttribute15 = AVD-CUI-Authorized via the PowerShell script in the Device Extension Attribute section
2. Confirm the tag is visible in Entra before notifying the user
3. Revoke or deregister the old device object

Offboarding an Enclave User

1. Remove the CUI account from AVD-Enclave-FCI-Users-MESG — P004, B011, B012 (and B013/B014 for E5) no longer apply; DLP label policy scope updates automatically
2. Deprovision the session host or reassign it
3. Disable the CUI account; delete after the applicable retention period

Handing Off to Client IT

The RBAC structure is designed for a graduated handoff. The enclave cannot be self-extended by an admin who only has conventional roles.

Role	Typical Holder	Can Do	Cannot Do
Global Administrator	Client IT	Manage users, reset passwords, basic Intune operations	Modify DLP policies or label policies (but can write device extension attributes — monitor via audit log)
Intune Administrator or Cloud Device Administrator	Your team (PIM-gated)	Write extensionAttribute15 to tag/untag session hosts	N/A
Conditional Access Administrator	Your team (PIM-gated)	Modify P004/B011/B012/B013/B014 scope and conditions	N/A
Compliance Administrator	Your team (PIM-gated)	Create, modify, and publish sensitivity labels, label policies, and DLP policies D001–D003; designate new CUI sites	N/A

As the client team matures, transition these roles via PIM with an approval workflow — not as standing assignments. The Compliance Administrator role is the highest-sensitivity handoff: it controls the DLP policies that define which sites are designated for CUI and the label policies that enforce mandatory labeling. The device tagging role (Intune Administrator or Cloud Device Administrator) is the second highest: control of which devices can access CUI. Note that Global Administrators can also write extension attributes — monitor extensionAttribute15 changes in the Entra audit log to detect unauthorized tagging.

---

AVD Enclave — CMMC Control Mapping

Control	Requirement	How the Enclave Satisfies It
AC.L2-3.1.1	Limit system access to authorized users, processes, and devices	Dedicated CUI accounts are provisioned only for users with an assessed need for CUI access, enrolled in phishing-resistant authentication only. AVD-Enclave-FCI-Users-MESG group membership is the explicit authorization gate — access is not implied by presence in the tenant.
AC.L2-3.1.2	Limit system access to types of transactions and functions authorized users are permitted to execute	P004 requires device compliance. B011 and B012 restrict CUI access to AVD-Enclave-FCI-Users-MESG members on tagged session hosts (extensionAttribute15) at the AZFW egress IP — no other device or network path can reach CUI regardless of user credentials. B013/B014 (E5) add auth context enforcement at the token level. DLP policies D001–D003 further restrict FCI users to designated CUI sites and labeled content only.
AC.L2-3.1.3	Control the flow of CUI in accordance with approved authorizations	Device tagging + location binding prevents CUI from being accessible from devices outside the Azure Firewall egress boundary. RMS encryption restricts file decryption to AVD-Enclave-FCI-Users-MESG — content shared with or emailed to non-enclave recipients is unreadable. DLP Policy D002 blocks access to CUI-labeled files that reach non-designated locations. Mandatory labeling ensures all FCI user content is labeled and subject to these controls.
AC.L2-3.1.14	Route remote access via managed access control points	All enclave session egress passes through Azure Firewall; the UDR enforces this at the network layer with no opt-out path for session hosts
SC.L2-3.13.5	Implement subnetworks for publicly accessible system components	AVD session hosts are on an isolated subnet; the UDR and Azure Firewall rules define the only permitted egress paths
SC.L2-3.13.8	Implement cryptographic mechanisms to prevent unauthorized disclosure	AVD Gateway enforces TLS 1.2+ on all RDP sessions; Purview RMS encryption protects labeled files in transit and at rest — only AVD-Enclave-FCI-Users-MESG can decrypt, and the 3-day offline access window limits exposure of exfiltrated files