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 + 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 CA policies read: device tags, Named Location, authentication context, and sensitivity labels
2. CA Policies — Configure the five policies that enforce the enclave using those building blocks

---

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	Custom Security Attribute on session host + Azure Firewall egress as Named Location, enforced by two independent block policies (E002, E002b)	CUI access from any device that is not a tagged session host routing through the firewall
Data	CUI files accessed outside the enclave or exfiltrated from the tenant	Purview sensitivity labels backed by Entra Authentication Contexts, enforced by two independent block policies (E003, E003b)	Users with valid credentials accessing labeled CUI files from outside the enclave

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 and scoped into enclave CA 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 carrying a Custom Security Attribute (EnclaveManagement.DeviceClassification = AVD-CUI-Authorized) and originating from the Azure Firewall public IP registered as a Named Location in Entra. Two independent block policies enforce this:

• E002 blocks access to Office 365 unless the request originates from a CSA-tagged session host
• E002b blocks access to Office 365 unless the traffic arrives from the Azure Firewall egress IP

E002 and E002b are independent block policies — a request must pass both. This enforces true AND logic: the session host must carry the tag AND route through the firewall. A tagged device not routing through the firewall is blocked by E002b. Traffic from the firewall IP on an untagged device is blocked by E002.

Data

Purview sensitivity labels backed by Entra Authentication Contexts protect CUI at the file level, independent of how a session was established. A CUI-labeled file requires that the decrypting token carries a specific authentication context claim — a claim that can only be obtained from within the enclave. Files downloaded outside the tenant, forwarded by email, or copied to removable media remain encrypted and cannot be opened without satisfying the enclave's auth context policy.

Two independent block policies enforce the auth context layer:

• E003 blocks the c1 auth context unless the request originates from a CSA-tagged session host
• E003b blocks the c1 auth context unless the traffic arrives from the Azure Firewall egress IP

E003 and E003b use the same AND logic as E002/E002b: both must be satisfied. A tagged device not routing through the firewall is blocked by E003b. Traffic from the firewall IP on an untagged device is blocked by E003.

---

Enclave Prerequisites

Enclave Licensing

Requirement	License
Custom Security Attributes	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)	Microsoft Purview Information Protection Plan 1 (included in M365 E3 GCC High)
Authentication context in sensitivity labels	Entra ID P1
Auto-labeling (optional)	M365 E5 Compliance or Microsoft Purview add-on

Required Roles

Task	Role Required
Create CSA attribute set and attribute	Attribute Definition Administrator
Assign CSA values to device objects	Attribute Assignment Administrator
Create Conditional Access policies	Conditional Access Administrator
Register Named Location	Security Administrator
Create and publish sensitivity labels	Compliance Administrator or Information Protection Administrator
Apply authentication context to SharePoint sites	SharePoint Administrator

CSA assignment is intentionally separated from Global Admin

The Attribute Assignment Administrator role is not included in Global Administrator. A junior admin with GA rights cannot assign the AVD-CUI-Authorized tag to a device without an explicit role grant. This is the control that prevents the enclave from being self-extended. Protect this role with PIM and limit it to the same team who owns the enclave configuration.

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-cui@contoso.us
License	M365 E3 GCC High — sufficient for AVD, SharePoint, and CUI-related applications
Group membership	AVD-Enclave-FCI-Users only — do not add to distribution lists, shared mailboxes, or any group unrelated to CUI
Authentication methods	Register phishing-resistant methods only (FIDO2 or Windows Hello for Business) — no SMS, voice call, or Authenticator app push notifications

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 Restricted Management AU alongside the other CA security groups.

Group Name	Purpose
AVD-Enclave-FCI-Users	All dedicated CUI accounts that need access via the enclave. Assigned to the enclave host pool and scoped into E001/E002/E002b/E003/E003b.

---

Precursors

The CA policies in the next section each evaluate one or more of these building blocks. Configure all precursors before enabling any CA policy.

Custom Security Attributes

Custom Security Attributes (CSAs) allow Conditional Access 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 E002 and E003. The CSA tag is what those policies read to decide whether to pass or block.

Create the Attribute Set

1. Entra admin center → Custom Security Attributes → + Add attribute set
2. Name: EnclaveManagement
3. Description: Tags for devices enrolled in the CUI secure enclave

Create the Attribute

1. Open EnclaveManagement → + Add attribute
2. Attribute name: DeviceClassification
3. Data type: String
4. Allow multiple values: No
5. Only allow predefined values: Yes
6. Predefined value: AVD-CUI-Authorized

Assign to Session Hosts

Perform this step for each session host that should serve enclave users. Requires Attribute Assignment Administrator.

1. Entra admin center → Devices → All devices → open the session host
2. Custom security attributes → Add assignment
3. Attribute set: EnclaveManagement | Attribute: DeviceClassification | Value: AVD-CUI-Authorized

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 — E002 will block them until the tag is present.

---

Named Location

E002b and E003b evaluate 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)

---

Authentication Context

E003 and E003b enforce the authentication context claim. Publishing the context here makes it available to the CA policies, SharePoint sites, and Office apps.

1. Entra admin center → Security → Conditional Access → Authentication contexts
2. Select + New authentication context
3. Name: CUI Access Required
4. Description: Required for access to CUI-labeled content. Satisfied only from AVD enclave session hosts.
5. Check Publish to apps — this makes the context available to SharePoint and Office apps
6. Note the assigned ID (e.g., c1) — you will reference it in the sensitivity label and in E003/E003b

---

Sensitivity Labels

Create the CUI Label

1. Microsoft Purview compliance portal (compliance.microsoft.us) → Information protection → Labels → + Create a label
2. Label name: CUI
3. Display name: Controlled Unclassified Information
4. Description for users: Apply to documents and files containing CUI. Access is restricted to authorized AVD enclave sessions.

Encryption settings:

5. Encrypt files and emails: On
6. Assign permissions now: Yes
7. User access to content expires: Never (or set per your data retention policy)
8. Allow offline access: For a number of days — set to 7
9. Assign permissions → + Add users or groups: AVD-Enclave-FCI-Users; set permissions to Co-Author (read, modify, print — no full control)
10. Require users to satisfy: Authentication context → c1 — CUI Access Required

Apply Authentication Context to CUI SharePoint Sites

Applying the auth context to a SharePoint site forces Entra to re-evaluate E003 and E003b for any user accessing that site, independent of whether individual files are labeled. This provides a second enforcement point at the site level.

1. SharePoint admin center → Active sites → [CUI site] → Policies tab
2. Conditional access: Select Use a specific, existing policy
3. Choose: c1 — CUI Access Required

Repeat for each SharePoint site containing CUI repositories.

Publish the Label Policy

1. Purview → Information protection → Label policies → + Publish label
2. Add the CUI label
3. Publish to: AVD-Enclave-FCI-Users
4. Default label for documents: None initially — enforce after user training
5. Require users to apply a label: Optional initially; enable once auto-labeling is validated

Extend coverage with auto-labeling

Once the label policy is stable, create an auto-labeling policy (Purview → Information protection → Auto-labeling) to scan CUI SharePoint sites and apply the label without user action. Auto-labeling requires M365 E5 Compliance or the Microsoft Purview add-on.

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

E001 is the entry gate. E002 and E002b together enforce device-layer AND logic for Office 365 access. E003 and E003b enforce the same AND logic for auth context access.

ID	Policy Name	Target Resources	Grant Control
E001	AVD Broker Access	Azure Virtual Desktop, Windows Sign In	Phishing-resistant MFA
E002	Device Block	Office 365	Block (unless CSA-tagged device)
E002b	Network Block	Office 365	Block (unless AZFW egress IP)
E003	Auth Context: Device Block	Auth context c1 — CUI Access Required	Block (unless CSA-tagged device)
E003b	Auth Context: Network Block	Auth context c1 — CUI Access Required	Block (unless AZFW egress IP)

Enable in Report Only mode first

Enable all policies in Report Only before switching to Enforce. Enforcing E002 before CSA tags are assigned to session hosts will lock enclave users out of Office 365. Validate each policy in CA sign-in logs before enforcing.

---

E001 — AVD Broker Access

Enclave users connect to the AVD broker from personal or lightly-managed devices. Without this policy, an existing device compliance policy (B009 or P006) will block the initial AVD authentication before the user ever reaches the session host.

Users:

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

Target resources: Azure Virtual Desktop, Windows Sign In

Conditions → Client apps: Browser; Mobile apps and desktop clients

Leave device state and compliance conditions unconfigured.

Grant: Require authentication strength: Phishing-resistant MFA

Why no device compliance check here?

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.

---

E002 — Device Block

Blocks Office 365 access from any device not carrying the AVD-CUI-Authorized CSA tag.

Users:

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

Target resources: Office 365

Conditions → Filter for devices:

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

  device.customSecurityAttributes.EnclaveManagement_DeviceClassification -eq "AVD-CUI-Authorized"

Grant: Block

Logic: "Block Office 365 for AVD-Enclave-FCI-Users — unless the request comes from a device tagged AVD-CUI-Authorized."

---

E002b — Network Block

Independently blocks Office 365 access from any traffic not originating from the Azure Firewall egress IP. Together with E002, enforces AND logic.

Users:

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

Target resources: Office 365

Conditions → Locations:

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

Grant: Block

Logic: "Block Office 365 for AVD-Enclave-FCI-Users — unless the traffic arrives from the Azure Firewall public IP."

Combined logic (E002 + E002b): Both policies must be satisfied. A tagged device not routing through the firewall is blocked by E002b. Traffic from the firewall IP on an untagged device is blocked by E002. Only a request that is both CSA-tagged and from the AZFW IP passes both.

---

E003 — Authentication Context: Device Block

Fires when a resource requests the c1 auth context. Blocks the context from any device not carrying the CSA tag.

Users:

• Include: AVD-Enclave-FCI-Users
• 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.customSecurityAttributes.EnclaveManagement_DeviceClassification -eq "AVD-CUI-Authorized"

Grant: Block

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

---

E003b — Authentication Context: Network Block

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

Users:

• Include: AVD-Enclave-FCI-Users
• 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 — unless the traffic arrives from the Azure Firewall public IP."

Combined logic (E003 + E003b): Both policies must be satisfied. Only a session that is both CSA-tagged and originating from the AZFW IP can obtain a c1 auth context claim and open labeled CUI files.

Retiring E002 and E002b once labeling is complete

E002 and E002b block all of Office 365 — a broad block appropriate while the label rollout is in progress. Once all CUI is labeled and E003/E003b are validated, E002 and E002b can be removed. Enclave users will then be able to access non-CUI O365 resources (email, Teams, non-CUI SharePoint) from personal devices normally. Until you are confident that all CUI is covered by the label policy, keep E002 and E002b in place.

---

Verification

Enable all policies in Report Only mode and validate each before switching to Enforce.

Check	How to Verify
CSA assigned to session hosts	Entra → Devices → [session host] → Custom security attributes
E001 passes for AVD broker	Sign in via AVD client from a personal device — phishing-resistant MFA prompt, session launches
E002 blocks direct M365 access	From a personal device (outside AVD), open SharePoint with the CUI account — should be blocked
E002 passes from AVD session	Open SharePoint from inside the AVD session — should succeed
E002b network binding	From inside an AVD session, confirm outbound IP matches Azure Firewall public IP
CA sign-in logs	Entra → Sign-in logs → filter by AVD-Enclave-FCI-Users — E002 shows Pass (from session host) and Block (from personal device)
E003 blocks outside enclave	From a personal device (outside AVD), open a CUI-labeled file with the CUI account — should fail to decrypt; CA sign-in logs should show E003 Block
E003 passes from AVD session	From inside the AVD session, open a CUI-labeled file — should open; CA sign-in logs should show E003 and E003b Pass with auth context c1
Label blocks outside enclave	From a personal device outside AVD, attempt to open a CUI-labeled file — should fail to decrypt
SharePoint site auth context	From a personal device outside AVD, navigate to a CUI SharePoint site — should trigger E003/E003b Block
RMS endpoint (GCC High)	In Office app activity log, confirm RMS calls go to api.aadrm.us, not api.aadrm.com

---

Operational Procedures

Adding a New Enclave User

1. Create a CUI account, issue a TAP, and have the user register their phishing-resistant authentication method
2. Add the CUI account to AVD-Enclave-FCI-Users
3. Assign a personal pool session host (or confirm auto-assignment is configured)
4. Verify the session host device object has the AVD-CUI-Authorized CSA attribute
5. Have the user connect and confirm successful sign-in via CA sign-in logs

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 CSA attributes.

1. Tag the new device object with AVD-CUI-Authorized (Attribute Assignment Administrator)
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 — E001, E002, E002b, E003, and E003b no longer apply
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	Assign CSA attributes to devices
Attribute Assignment Administrator	Your team (PIM-gated)	Grant/revoke AVD-CUI-Authorized on specific devices	N/A
Conditional Access Administrator	Your team (PIM-gated)	Modify E001/E002/E002b/E003/E003b scope and conditions	N/A
Compliance Administrator	Your team (PIM-gated)	Create, modify, and publish sensitivity labels and label policies	N/A
SharePoint Administrator	Your team (PIM-gated)	Apply authentication context to SharePoint sites	N/A

As the client team matures, transition these roles via PIM with an approval workflow — not as standing assignments. The Attribute Assignment Administrator role is the highest-sensitivity handoff: control of which devices can access CUI.

---

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 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	E002 and E002b restrict CUI access to AVD-Enclave-FCI-Users members on CSA-tagged session hosts at the AZFW egress IP — no other device or network path can reach CUI regardless of user credentials
AC.L2-3.1.3	Control the flow of CUI in accordance with approved authorizations	CSA + location binding prevents CUI from being accessible from devices outside the Azure Firewall egress boundary; for labeled files, RMS encryption enforces access restrictions regardless of file location — CUI downloaded, forwarded, or copied outside the tenant remains encrypted and inaccessible without a valid enclave session token
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 regardless of location